Vincent McCauley <vincem at mccauleysoftware.com>, > 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?
If there is a lifecycle or other marker on Entries then the marker can be set to an appropriate value, either "superseded" as I suggested before, or perhaps something like "exclude from automatic processing" as Sam has suggested. Whatever the marker, this result will still be visible to queries that ignore this marker (i.e. queries that get results for display on the screen), and the result will still be available as a part of the record until such time as someone decides to do a repeat test to replace it, in which case it remains a previous version of a new correct result. Probably in the archetypes for blood tests there should be place to put the "haemolysed" classifier next to the value. Not sure exactly where this should go at the moment... - thomas > > Regards > Vince > > Dr Vincent McCauley > CEO McCauley Software Pty Ltd > > ----- Original Message ----- > From: "Christopher Feahr" <chris at optiserv.com> > 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 > > > > -- Deep Thought: http://www.deepthought.com.au openEHR: http://www.openEHR.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
