Pathology requirements TIMED MEASUREMENTS
Thomas I am not sure that we need to do such a major rework. These samples are time ordered but have no sensible time. So they could appear in the history list without an offset, labelled in what ever way was helpful, recognising they are part of the same measurement. On thinking about this (if you wanted to keep all the measurements) a simple office based measurement like peak flow is a candidate - you might do three measurements in a row. At the moment the history demands an offset - the set of measurements would still be timed - but only the sequence of each would be known, not the time of each individual. This seems more appropriate. The query could return them all at the same time or, as I have suggested, with a nominal offset 1,2,3 etc This would allow for the fuzziness of a series to be captured. Another alternative is just to allow the application to put in what ever time it likes as the offset, and label them Sample 1, Sample 2. This would require no changes, and would not upset the query model. I probably favour this approach as there is no doubt there is a time element to sampling, otherwise it is not a sequence. Cheers, Sam > -Original Message- > From: Thomas Beale [mailto:thomas at deepthought.com.au] > Sent: Friday, 24 October 2003 5:58 PM > To: Sam Heard; Openehr-Technical > Subject: Re: Pathology requirements TIMED MEASUREMENTS > > > > > 1. We recognise this is a sampling issue and there should be a > label on each > > sample which is transfered to the report - we have sample 1, 2 > and 3 with > > three separate microscopies and cultures in a single > composition. This would > > get around the confusion of trying to deal with this as a > timing issue - it > > would work for any sampling including location. We do not want > to compare > > these CSF samples in queries as equals but we would have some > sort of label > > associated. So, the sample label and order might be part of > this - in the > > request and then in the result. I guess this goes on at the moment. > > > > 2. We have a sequence idea in the event model, by using the offset but > > having 'sequence' as the unit rather than time. This would mean > that people > > did not have to enter spurious times in the data and name the event as > > Sample 1, which could be misleading. > > I guess there are a few possibiities. > > a) we change HISTORY to SEQUENCE and make it general enough to > cope with other > sequences, not just time > > b) we add a type SEQUENCE and make the current HISTORY a subtype > of it. The > only reason to do this, rather than to have two disjoint types would be to > enable software re-use (less code; better code) and to allow runtime > substitutability. I am not sure what query could sensibly request all > sequences, including histories, so I am not sure if this is an argument > > c) we add a type SEQUENCE as another subtype of STRUCTURE. > > Without having done the analysis, I would favour b), since there > appears to be > a fair overlap of semantics and therefore argument for reuse. > > What we need is a nice statement of a new model for history, > which includes > means, maxima, minima etc as Sam has been modelling, and a > similar model for > sequence. Then we can see what to do about changing the Data Structures > Information Model > > - thomas > > > - thomas > > > > c) > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
Thomas My approach to this, which is expressed in the editor, is to standardise only on the base and maximum values of the ordinal. The terms that are used are not an issue and standardisation is really way beyond scope when people use all sorts of terms for this purpose. Apgar is a classic - 0,1,2 is quite clear - how these points are described varies enormously - but that is OK. Nurses may want something different than doctors - for example. It is the tightly defined context that is important and the fact that it is ordered. This does allow comparisons and normal values to be determined. So, Urinalysis - NORMAL can be something that an archetype can express. Blood = 0, Protein = 0 ... You are always worried about the non-standardisation but we do not need it in this world to make interoperability a reality - ordinal values are, on the whole, too gross for a great deal of concern. Reflex of +/- can be normal if the person is healthy and the finding is consistent. Sam > -Original Message- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale > Sent: Friday, 24 October 2003 6:22 PM > To: Openehr-Technical > Subject: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES > > > > Tim Churches wrote: > > > Sam Heard wrote: > > > > > > TEXTURAL RESULTS TO QUANTITIES > > > > ?TEXTUAL? > > > > This raises the general issue of how mixed categorical/ordinal/scalar > quantities > > are handled eg (made up example) haematuria: Trace->x RBC/ml -> Gross > > haematuria. Conceivably some use might be made of the numbers, > as opposed > > to the ordinal categorical extrema? > > The current DV_ORDINAL data type consists of an integer value > representing the > ordinal position in a range of values, and a symbol, which is the > symbol given > to that position. Ordinals are treated as being comparable (< operator is > defined) but not quantified (the magnitude is unknown). We currently think > that the correct way to express the symbol is as a term in a > vocabulary (maybe > subsetted). This means that each set of symbols comes from its own > micro-vocabulary, and even if the same symbols (like "trace", > "+", "++") are > used for unrelated things, they cannot get mixed up in comparisons. > > Examles: > > pain: > Value Symbol > 1+ > 2++ > 3+++ > > reflex > Value Symbol > 1+ > 2++ > 3+++ > > haemolysed blood in urinalysis > 1 ?neg? > 2 ?trace? > 3 ?small? > 4 ?moderate? > 5 ?large? > > OR - haemolysed blood in urinalysis (unit=cells/ml) > 1 ?neg? > 2 ?trace (10)" > 3 ?small (<25)" > 4 ?moderate (<80)" > 5 ?large (>200)" > > I am not sure if we need more sophistication to deal with this. The main > problem I see is the lack of vocabularies, and/or > non-standardisation of them. > I guess LOINC has the kinds of values we want, but how to specify > the correct > subsets? > > - thomas beale > > - > 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
Pathology requirements UNITS
Thomas
It is more that units match "Force"/"Length"^2 for pressure and it is an
expression that the property of pressure is the property of "Force" per
property of "area" - this does allow a very wide range of units to be used
if that is the requirement.
I am starting to see that things do get complicated out there in Unitsville.
Cheers, Sam
>
> > Can we not work on a UNITS module where a test can be attached
> to a number
> > of units where the conversion is not available. A clinician
> does not want to
> > have to relearn the unit for the convenience of the application.
> >
>
> I wonder if units should be considered part of a localsation profile?
> Currently you can specify units in an archetype in two ways:
>
> a) as the actual units you want to allow, e.g. units matches
> {"mm[Hg]"}, units
> matches {"km", "mi"}
>
> b) property matches {"pressure"}, property matches {"length"}
>
> A nice alternative that Sam has thought of is:
>
> c) property matches {FORCE/LENGTH^2} -- same as pressure
> property matches {LENGTH/TIME}
>
> We are currentl working on including this in ADL.
>
> - thomas
>
> -
> 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
Pathology requirements CONTRIBUTION - 2 versions at once
Christopher Feahr wrote: > 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. the clinician or the lab people (who might ring or email) should decide if the first test is erroneous in the same way as they do today. If they do decide, they mark it as superseded, or in error or whatever - it must be hidden from querying. However, the actual result must not be removed from the system - it si medico-legal evidence and may have been used to make a decision in the interim period. That is why I am suggesting that all such Entries havea lifecycle marker. This is somehting which I think our colleagues at UCL have long had in their system, and I have never seen a scenario which I thought justified it until now... - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
Bhupinder Singh , wrote > What you say is one possibility. > What is important is when there are two results out of the scenario and the > readings are different. Would it be correct to take a mean. The difference > in the reading may be on account of a number of causes starting from > --Machine error > --Human Error etc. > The question is that there is a difference and this needs to be gone into in > fact this requires to be highlighted and not covered through a mean value I completely agree - it is up to the same professional decisional processes as exist now to assess what the results really represent. If two markedly different results come back for he same ivestigation from the same sample, there must be a problem somewhere, and it has to be investigated, and eventually at least one of the results will be foudn to be in error, for one or more of the reasons you mention. So I am certainly not advocating that humans stop using their expert judgement - just that once they have done so, we have a way of recording what that judgement was... - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
Sam wrote: > Thomas > > I am not sure that we need to do such a major rework. These samples are time > ordered but have no sensible time. So they could appear in the history list > without an offset, labelled in what ever way was helpful, recognising they > are part of the same measurement. On thinking about this (if you wanted to > keep all the measurements) a simple office based measurement like peak flow > is a candidate - you might do three measurements in a row. > > At the moment the history demands an offset - the set of measurements would > still be timed - but only the sequence of each would be known, not the time > of each individual. This seems more appropriate. But I think the whole idea of History is about time. Having a sequence type would not be much work. The abstraction seems quite simple, but we need to do more analysis... > > The query could return them all at the same time or, as I have suggested, > with a nominal offset 1,2,3 etc > > This would allow for the fuzziness of a series to be captured. > > Another alternative is just to allow the application to put in what ever > time it likes as the offset, and label them Sample 1, Sample 2. This would > require no changes, and would not upset the query model. I probably favour > this approach as there is no doubt there is a time element to sampling, > otherwise it is not a sequence. but maybe even though sequential samples were done at different times, time is not the variable of the sequence - it could be position (in a limb being scanned for example) or separate tissue samples as you mention below. Then the fact that the results were generated (slightly?) separated in time is irrelevant - in fact the proper ordering of the series might be different from the time-ordering of the result generation...also, imaging equipment might generate sequences of results in a spatial dimension at the same moment. I think we have to analyse this further Any other sequence examples anyone? - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
This is dealt with by most pathology systems by keeping at least 5 date/times related to a result 1. Date/Time ordered 2. Date/Time specimen taken 3. Date/Time order entered in Pathology Lab. computer system 4. Date/Time result entered 5. Date/Time result authorised for release In the scenario you describe, the 2 results can be "seen" to be identical because they are the same analyte on the same specimen taken at the same time Regards Vince Dr Vincent McCauley CEO McCauley Software Pty Ltd - Original Message - From: "Thomas Beale" To: "Openehr-Technical" Sent: Friday, October 24, 2003 23:29 Subject: Re: Pathology requirements TIMED MEASUREMENTS > Bhupinder Singh wrote: > > > Dear Sam, > > What you say is correct. > > In clinical practice it is also possible that the same sample is sent to two > > labs for the same test and the protocol followed by both the labs is same so > > is the est method and the unit of reporting. The sample date and time is the > > same. These two results have to be viewed and stored. Thus there should be a > > method to store and retrieve values where the date and time of sample and > > the test type and method and the UOM is the same needs to be available. > > Eg Blood Sugar reporting unit and test method are the same so is the date > > and time of the sample. > > Bhupinder > > this is an inteersting scenario actually, since even if there are two > perfectly legitimate test results (let's say submitted to the EHR a day after > each other) they don't really represent distinct results - they are the same > result (presumably) submitted at same or different times. Wen doing > statistical or other queries we have to be careful - if we draw the values on > a graph for example of bsl over last five days, there might be two values at > the one timepoint (where the timepoints are the times of taking samples, not > doing the test - i.e. the biologically significant point in time). One way to > look at thist situation is to say that all test results where there is just a > single result are just a special case of a statistical testing situation in > which at any point in "body time", a sample might be tested any number of > times (and more than one sample might be made as well) - giving a > constellation of results. Where there are multiple results for the one > biological timepoint, we could consider it as a statistical strengthening of > the confidence in the result. Probably what applications processing the > results should do is consider N results at the same biological timepoint to be > the same as one, whoe value is the mean of the N, and whose confidence is some > higher value than that attributed to single value samples. > > - thomas beale > > - > 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
Pathology requirements CONTRIBUTION - 2 versions at once
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" To: "Thomas Beale" ; "Openehr-Technical" 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 , 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 t
Pathology requirements TIMED MEASUREMENTS
Bhupinder The only values we are not wanting to show are those that are wrong - and have been changed in a later version. The idea behind this is to store the information in an openEHR system inside the Pathology service and then send an extract - rather than develop a lot of messages. Cheers, Sam > -Original Message- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh > Sent: Sunday, 26 October 2003 11:50 PM > To: Thomas Beale; Openehr-Technical > Subject: Re: Pathology requirements TIMED MEASUREMENTS > > > What you say is one possibility. > What is important is when there are two results out of the > scenario and the > readings are different. Would it be correct to take a mean. The difference > in the reading may be on account of a number of causes starting from > --Machine error > --Human Error etc. > The question is that there is a difference and this needs to be > gone into in > fact this requires to be highlighted and not covered through a mean value > generated. Graphical representation should show both values and > leave it to > the clinician to decide what action he prefers to take. Textual display > should show both values too. > > Bhupinder > > - Original Message - > From: "Thomas Beale" > To: "Openehr-Technical" > Sent: Friday, October 24, 2003 4:29 AM > Subject: Re: Pathology requirements TIMED MEASUREMENTS > > > > Bhupinder Singh wrote: > > > > > Dear Sam, > > > What you say is correct. > > > In clinical practice it is also possible that the same sample > is sent to > two > > > labs for the same test and the protocol followed by both the labs is > same so > > > is the est method and the unit of reporting. The sample date > and time is > the > > > same. These two results have to be viewed and stored. Thus > there should > be a > > > method to store and retrieve values where the date and time of sample > and > > > the test type and method and the UOM is the same needs to be > available. > > > Eg Blood Sugar reporting unit and test method are the same so is the > date > > > and time of the sample. > > > Bhupinder > > > > this is an inteersting scenario actually, since even if there are two > > perfectly legitimate test results (let's say submitted to the EHR a day > after > > each other) they don't really represent distinct results - they are the > same > > result (presumably) submitted at same or different times. Wen doing > > statistical or other queries we have to be careful - if we draw > the values > on > > a graph for example of bsl over last five days, there might be > two values > at > > the one timepoint (where the timepoints are the times of taking samples, > not > > doing the test - i.e. the biologically significant point in > time). One way > to > > look at thist situation is to say that all test results where there is > just a > > single result are just a special case of a statistical testing situation > in > > which at any point in "body time", a sample might be tested any > number of > > times (and more than one sample might be made as well) - giving a > > constellation of results. Where there are multiple results for the one > > biological timepoint, we could consider it as a statistical > strengthening > of > > the confidence in the result. Probably what applications processing the > > results should do is consider N results at the same biological timepoint > to be > > the same as one, whoe value is the mean of the N, and whose > confidence is > some > > higher value than that attributed to single value samples. > > > > - thomas beale > > > > - > > 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
Pathology requirements CONTRIBUTION - 2 versions at once
Vincent McCauley , > 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" > To: "Thomas Beale" ; "Openehr-Technical" > > 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 , 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". > > >
Pathology requirements TIMED MEASUREMENTS
HI, On one hand there is the notion as used in HL7 where series of messages update databases producing a list of updated measurements. On the other hand there is the notion as used in CEN/TC251 and OpenEHR where documents are used to enhance the raw data by providing a human interpretation and advice by an expert using the updated measurements in the database. Gerard -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 > From: Sam Heard > Reply-To: Sam Heard > Date: Mon, 27 Oct 2003 11:41:47 +0930 > To: Bhupinder Singh , Thomas Beale > , Openehr-Technical openehr.org> > Subject: RE: Pathology requirements TIMED MEASUREMENTS > > Bhupinder > > The only values we are not wanting to show are those that are wrong - and > have been changed in a later version. The idea behind this is to store the > information in an openEHR system inside the Pathology service and then send > an extract - rather than develop a lot of messages. > > Cheers, Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements CONTRIBUTION - 2 versions at once
Hi, Only an attribute will not be enough. It has to be accompanied by rules. Information will be stored in various contexts and not always in the same system. The same information will be stored in separate contexts. A change in the status of the 'Lifecycle marker' in one machine will not result in changes in other machines, unless there is a replication service. It is unlikely that all systems will be able to deal with such a service. In order to handle this we need rules. My suggestion for a rule would be: the 'Lifecycle marker' is valid (maintained) in one system only. Moving from one jurisdiction to an other means that the person that takes responsibility for the admission of this information into a new jurisdiction/system sets the marker to: received and admitted. Part of the rules is a state machine that provides all the states of the 'Lifecycle marker'. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 > From: "Thomas Beale" > Reply-To: "Thomas Beale" > Date: Mon, 27 Oct 2003 08:16:55 +1000 > To: Openehr-Technical > Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > > That is why I am suggesting that all such Entries havea lifecycle > marker. This is somehting which I think our colleagues at UCL have long had in > their system, and I have never seen a scenario which I thought justified it > until > now... - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
Bhupinder Singh > Hi Sam, > > What yo usuggest is OK . But the issue is who is to decide what is right > and what is wrong. Should it not be the prerogative of the clinician. > > There are situations where medical decisions are based upon results which > trigger clinical decisions. How would you hide a wrong result once it has > been acted upon by the clinician. Example a report of Serum Potassium of say > 6.0 has been sent to the clinician. This is a medical emergency and the > clinician has to act upon it to reduce the high level. His action is based > upon the result. If he does not act it will be an act of medical negligence. > The lab thereafter does a correction and replaces the result of the test > say Potassium of 4.0. In the scenario suggested by you this would mean that > the result will be filtered out and not be available to the clinician. what he means here is that in normal processing, using the latest historical state of the record, the 6.0 will no longe be picked up in queries, the 4.0 will. But the versions are still there, and in the case of a medico-legal investigation, a snapshot of the EHR exactly as it was at the time of the clinician's decision can be generated (just like getting a prior version of Linux kernel from a CVS server) and it can be shown what evidence the clinician's actions were based on. So the version control system does two things: it enables the current cut of the record to reflect the curent information about the patient, plans etc, and it allows any prior decision to be investigated medico-legally by going backwards in time and reconstructing the record as it was at that moment - i.e. it enables one to know what the EHR looked like at any prior moment in time. So whatever the outcome (even adverse) the clinician can be shown to have acted reasonably, given the information at his/her disposal. > The > question that will arise is the support for the action taken by the > clinicians would in the absence of the report be an act of negligence. In > reality the result has been withdrawn. This would raise the possibility of > a malpractice suit. Alternatively the patient has an adverse event because > of the action of the doctor and the support team views the results and find > that there is no Result to support the clinicians action the clinicians > action giving rise to another conflict situation. As I say, this can't happen - that's what the whole version control/chnage management system is all about. > > All reports which have been released shall not be available for being > withdrawn and replaced for legal and professional standpoint a report can be > appended to and not cancelled. The audit trail is necessary and a mandatory > keeping in mind the laws that are coming into place to deal with electronic > transaction. correct - all this is still available - nothing in the EHR is ever deleted. What is visible at a moment in time depends on the semantics of versioning. It's just like a bug in software - go back through the CVS server and you can find the version with the bug (in case someone wants to prove that the software used to act differently), but today, in teh current snapshot, the bug is gone, since we don't want it operationally affecting us now. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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" To: "Openehr-Technical" Sent: Monday, October 27, 2003 18:54 Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > Vincent McCauley , > > > 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" > > To: "Thomas Beale" ; "Openehr-Technical" > > > > 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 , 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. > > > > > > > >
Pathology requirements CONTRIBUTION - 2 versions at once
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" > To: "Openehr-Technical" > Sent: Monday, October 27, 2003 18:54 > Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once > > > > Vincent McCauley , > > > > > 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" > > > To: "Thomas Beale" ; "Openehr-Technical" > > > > > > 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 , 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. Th
