Vince The notion of superceded applies to compositions and is inherent in the versioning approach. Exclude from automatic processing is for entries.
Sam > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Vincent > McCauley > Sent: Monday, 27 October 2003 7:44 PM > To: Openehr-Technical > Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > > > I think there is a need for both "superceded" and "exclude from automatic > processing". > > Wherever the "haemolysed" marker ends up in the archetype/EHR it won't be > the only such beast. > Some other examples are "clotted" and "clumped" for full blood counts, > "incorrectly collected" (specimen in wrong type of tube etc e.g not a > fluoride tube for a blood glucose), "warmed" (where specimen has > to be keep > cold for correct results), > "cooled" where specimen has to be kept at body temp. (cold > agglutinins etc) > and so on ... > > Regards > Vince > > ----- Original Message ----- > From: "Thomas Beale" <thomas at deepthought.com.au> > To: "Openehr-Technical" <openehr-technical at openehr.org> > Sent: Monday, October 27, 2003 18:54 > Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > > > > 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 > > > > > > > - > 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
