Pathology requirements TIMED MEASUREMENTS

Technical (archive)
1

TIMED MEASUREMENTS

The timed nature of specimens is dealt with in the history and event model
of the RM and available in the archetype editor. This deals with timed
measurements and interval measurements. The idea of a 21 day progesterone is
covered in state information relating to the time since the last menstrual
period - BUT there is still the idea of an untimed sequence of events where
the order is critical. There are also sequenced events when it comes to
looking for stool microscopy, occult blood - but these are reported
separately and really are administrative rather than of the nature I will
describe here.

The best examples of this seem to occur in sampling - three samples of CSF -
the first, second and third - or shavings for histology looking for depth of
tumour. There are more, such as respiratory function tests with particular
challenges - and timing is not an issue. These occur one after the other but
the sequence is the only thing that is important - not the time - and time
would probably be made up. The question is, how do we deal with this. I
think we have two choices:

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.

Comments?

Cheers, Sam

2

The ability to capture the order of a sequence of events is fundamental in a whole
range of health domains. Don't forget to allow for ties i.e. two or more events with
the same sequence number.

Also, time deltas are necessarily zero-based. Will sequences be zero-based?
There are cogent arguments both ways...but I suspect that they shouldn't be (in
EHRs).

Tim C

3

Further to what you have stated there will also be events such as sample is
single time is same and the test is same but method of reporting and or
conducting test is different. Blood Sugar is one example sample is taken and
tested on the bedside and sent to a lab also. These events and results need
to be accommodated.

Bhupinder

4

Bhupinder

The protocol describes the methods of measurement - each measure can only
have one protocol - so this means that the measurement would be entered
twice - quite appropriate because it is unlikely that a different method
will lead to exactly the same result.

Cheers, Sam

5

Tim

This is a good point - and we need to look at it. The sequence I am talking
about here is not an administrative sequence but an single entry - so it is
not possible to have a tie (as in an array). For the others the number is
not critical as it is dated and timed anyway.

Sam

6

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

7

Sam,
I agree. But there will be the situation when the method is the same and the
sample date and time is the same( this I am suggesting as this is a common
practice in clinical practice to have and ask for two reports where the
method is the same and the sample is drawn twice. there is to be the ability
to record these values and display them.

BHUPINDER

8

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)

9

Bhupinder Singh said:

Further to what you have stated there will also be events such as sample is
single time is same and the test is same but method of reporting and or
conducting test is different. Blood Sugar is one example sample is taken and
tested on the bedside and sent to a lab also. These events and results need
to be accommodated.

If I understand correctly, we are talking about the same sample, but being
tested twice? These are separate tests, and could take place a quite different
times (e.g. hours apart); they are done by different methods, and probably
different providers/people. They will become available in the EHR at different
times, so the only thing in common really is the source of the sample - and
this should be reported in the test data.

- thomas beale

10

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

11

One should take care never to obscure the "reality" of the fact that you have two separate test results. That reality needs to be captured somewhere, at some level of the EHR. The algorithm that the clinician or researcher applies to these two results would be another matter.
-C

12

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

13

Bhupinder Singh <bobdog@sancharnet.in>, 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

14

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

15

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

16

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

17

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. 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.

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.

For any successful system once the report has been released there is to be
no way that result can be withdrawn by the releasing department in this case
the pathology department so that it is no longer visible. It is essential
that ability to modify / alter/ change shall be through an audit trail and
the old and new values are to be available within the pathology module. The
ability to modify should how ever be restricted to the pathology department
till the time the report has not been released. Once released they(pathology
Dept) will also have no rite to cancel it in anti time. This report can
then be acted upon through a way that could be that the value is to be
blocked would be through a date and time stamp and marking the result with a
flag that says for example " to be ignored". This will cover the clinician
in case any action has been taken by him and the lab has corrected itself
and maintain the sanctity of the record being generated.

RGDS
Bhupinder

18

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

19

Bhupinder Singh <bobdog@sancharnet.in>

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

20

Dear colleagues,
in the OpenEHR web site there is written that open source java components will be released during 2003. Apart that we are now in 2004 (happy new year!), is there any possibility that they will be released in a short time, or is better not to take into account this possibility to do some OpenEHR experimentation in the near future?

Thank you,

Vincenzo