Pathology requirements TIMED MEASUREMENTS

2003-10-27 Thread Sam Heard
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 TIMED MEASUREMENTS

2003-10-27 Thread Thomas Beale
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

2003-10-27 Thread Sam Heard
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 thomas at deepthought.com.au
 To: Openehr-Technical openehr-technical at openehr.org
 Sent: Friday, October 24, 2003 4:29 AM
 Subject: Re: Pathology requirements TIMED MEASUREMENTS


  Bhupinder Singh bobdog at sancharnet.in 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 TIMED MEASUREMENTS

2003-10-27 Thread Gerard Freriks
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


--  private --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


 From: Sam Heard sam.heard at bigpond.com
 Reply-To: Sam Heard sam.heard at bigpond.com
 Date: Mon, 27 Oct 2003 11:41:47 +0930
 To: Bhupinder Singh bobdog at sancharnet.in, Thomas Beale
 thomas at deepthought.com.au, Openehr-Technical openehr-technical at 
 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 TIMED MEASUREMENTS

2003-10-27 Thread Thomas Beale
Bhupinder Singh bobdog at 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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



Pathology requirements TIMED MEASUREMENTS

2003-10-26 Thread Christopher Feahr
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

At 06:20 AM 10/26/2003 -0800, 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
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 thomas at deepthought.com.au
To: Openehr-Technical openehr-technical at openehr.org
Sent: Friday, October 24, 2003 4:29 AM
Subject: Re: Pathology requirements TIMED MEASUREMENTS


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

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



Pathology requirements TIMED MEASUREMENTS

2003-10-26 Thread 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. 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



- Original Message - 
From: Sam Heard sam.he...@bigpond.com
To: Bhupinder Singh bobdog at sancharnet.in; Thomas Beale
thomas at deepthought.com.au; Openehr-Technical
openehr-technical at openehr.org
Sent: Sunday, October 26, 2003 6:11 PM
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

  -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 thomas at deepthought.com.au
  To: Openehr-Technical openehr-technical at openehr.org
  Sent: Friday, October 24, 2003 4:29 AM
  Subject: Re: Pathology requirements TIMED MEASUREMENTS
 
 
   Bhupinder Singh bobdog at sancharnet.in 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

Pathology requirements TIMED MEASUREMENTS

2003-10-24 Thread Sam Heard
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

 -Original Message-
 From: owner-openehr-technical at openehr.org
 [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh
 Sent: Thursday, 23 October 2003 1:12 PM
 To: Sam Heard; Openehr-Technical
 Subject: Re: Pathology requirements TIMED MEASUREMENTS



 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


 - Original Message -
 From: Sam Heard sam.heard at bigpond.com
 To: Openehr-Technical openehr-technical at openehr.org
 Sent: Wednesday, October 22, 2003 4:02 PM
 Subject: Pathology requirements TIMED MEASUREMENTS


  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
  
  Dr Sam Heard
  Ocean Informatics, openEHR
  Co-Chair, EHR-SIG, HL7
  Chair EHR IT-14-9-2, Standards Australia
  Hon. Senior Research Fellow, UCL, London
 
  105 Rapid Creek Rd
  Rapid Creek NT 0810
 
  Ph: +61 417 838 808
 
  sam.heard at bigpond.com
 
  www.openEHR.org
  www.HL7.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



Pathology requirements TIMED MEASUREMENTS

2003-10-24 Thread Thomas Beale
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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



Pathology requirements TIMED MEASUREMENTS

2003-10-24 Thread Thomas Beale
Bhupinder Singh bobdog at sancharnet.in 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



Pathology requirements TIMED MEASUREMENTS

2003-10-23 Thread Sam Heard
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

Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-9-2, Standards Australia
Hon. Senior Research Fellow, UCL, London

105 Rapid Creek Rd
Rapid Creek NT 0810

Ph: +61 417 838 808

sam.heard at bigpond.com

www.openEHR.org
www.HL7.org
__


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



Pathology requirements TIMED MEASUREMENTS

2003-10-23 Thread Bhupinder Singh
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


- Original Message - 
From: Sam Heard sam.he...@bigpond.com
To: Bhupinder Singh bobdog at sancharnet.in; Openehr-Technical
openehr-technical at openehr.org
Sent: Thursday, October 23, 2003 6:36 PM
Subject: RE: Pathology requirements TIMED MEASUREMENTS


 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

  -Original Message-
  From: owner-openehr-technical at openehr.org
  [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh
  Sent: Thursday, 23 October 2003 1:12 PM
  To: Sam Heard; Openehr-Technical
  Subject: Re: Pathology requirements TIMED MEASUREMENTS
 
 
 
  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
 
 
  - Original Message -
  From: Sam Heard sam.heard at bigpond.com
  To: Openehr-Technical openehr-technical at openehr.org
  Sent: Wednesday, October 22, 2003 4:02 PM
  Subject: Pathology requirements TIMED MEASUREMENTS
 
 
   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
   
   Dr Sam Heard
   Ocean Informatics, openEHR
   Co-Chair, EHR-SIG, HL7
   Chair EHR IT-14-9-2, Standards Australia
   Hon. Senior Research Fellow, UCL, London
  
   105 Rapid Creek Rd
   Rapid Creek NT 0810
  
   Ph: +61 417 838 808
  
   sam.heard at bigpond.com
  
   www.openEHR.org
   www.HL7.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


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org