Hi Thomas, The issue here is that Pathology labs will produce a numeric result for say Potassium but when it is high willl look at the specimen, decide it is haemolysed and actually report "Haemolysed" as the result. The Lab will store two results, the numeric value e.g. 7.0 and the reported result "Specimen haemolysed". The value 7.0 should never be returned as the result to a query "show me all potassium results" but has to be recorded in the Labs EHR for the patient. How should this be modelled?
Regards Vince Dr Vincent McCauley CEO McCauley Software Pty Ltd ----- Original Message ----- From: "Christopher Feahr" <[email protected]> To: "Thomas Beale" <thomas at deepthought.com.au>; "Openehr-Technical" <openehr-technical at openehr.org> Sent: Monday, October 27, 2003 01:26 Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > Hi Thomas, > I'm not sure I like the notion of "superceded". Is the first test an > error? If so, the first result should simply be marked "wrong" and voided > or removed. If the first result just looked a little goofy to the > clinician, but there was nothing to indicate with certainty that it was > erroneous... and the second result comes back with more reasonable-looking > values... perhaps both results should be left in the record. The > time-stamps will suggest to the clinician that the later one probably > "supercedes" the earlier, goofy-looking result. > > (Did I understand your scenario correctly?) > Regards, > -Chris > > At 07:26 PM 10/24/2003 +1000, Thomas Beale wrote: > >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 > > Christopher J. Feahr, O.D. > Optiserv Consulting (Vision Industry) > http://Optiserv.com > http://VisionDataStandard.org > Office (707) 579-4984 > Cell (707) 529-2268 > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
