Sam Heard <sam.heard at bigpond.com>, wrote: > CONTRIBUTION - 2 versions at once > > There is a particular problem with results that are deemed to be incorrect > as the specimen is damaged - haemolysed blood samples being the most common > (See textural results to quantities thread). If the machine read data is to > be preserved in openEHR then this would need to be over written with the > correct result and both compositions saved at the same time - otherwise some > other agent might base some process on the interim situation where the first > composition is saved even for a microsecond. We think this relates to > machine processed data - but keeping medical student entries might be dealt > with in some environments in the same manner.
I don't see the problem here. This is the classic version control situation which the model deals with. The preliminary result comes into the EHR and is recorded as an ENTRY in some COMPOSITION. This is the result that is available for say a couple of days. Presumably it should be marked "PRELIMINARY!" in red...one might argue that there is a need for an attribute to support this (in old GEHR days, there was the idea of a Nota Bene field). Anyone who makes a clinical decision on this result is safe, as long as it is accepted that any actions at all are allowed based on preliminary results. When the true resulst comes in two lays later, it replacs the original as a new version of the same COMPOSITION. Accessors of the EHR now see the latest version (not marked preliminary...), and things go on as normal. I think a problem that could occur is if lab A does a test and sends the result in (and it goes in the EHR), then a clinician decides to get a second test because they are surprised by the result (either same type, but different lab, or some other kind of test) - and this 2nd test is done and the result comes in, and clearly shows that there was some error in the first test. Since they are not the same test/lab/protocol, the second result should not be a new version of the first result, but logically its addition to the record has to obsolete the first one (assuming all the relevant docs agree that this is the case). So when it is added to the EHR as a first version of a COMPOSITION, there has to be a LINK back to the original result with type="supersedes"; the link in the other direction has type="superseded by". Now the problem is to ensure that results which are superseded or obsoleted by some such process are marked as being so, or else marked in some other way that will ensure that querying does not find them. Currently this is not supported, other than if the query engine knows it has to look for links of type "superseded by", which is not particularly nice.... Do we need a new attribute in say the LOCATABLE class, e.g. a lifecycle status attribute? > ACCESS CONTROL to interim reports > > There will be times when the access to an interim report needs to be > controlled - such as an abnormal result from a lab that has not been signed > off by the final arbitor...but it may need to be available to a particular > team. Our access control models need to deal with this. If you think this should be done by access control, then there will definitiely need to be a computable attribute such as lifecycle status or similar. But I am not sure that this needs special treatment. Currently there is obviously a known process to follow if early, possibly fallible results are acted upon; one view would say that all the EHR has to do is make the same preliminary status visible to the clinicians, and then it is up to them to follow the usual process. Which might argue for a "nota bene" comment field. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
