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