DV_WORLD_TIME and timezone

Technical (archive)
1

A few weeks ago, we inserted the class DV_WORLD_TIME into the data types, as a parent of all date & time types measuring real world (absolute) time, i.e. all of the types except DV_DURATION which just measures a time difference or length, however you like to think of it.

Currently DV_WORLD_TIME has only one feature of its own - timezone:DV_DURATION. (To see a UML diagram of what I am talking about, go to section 6.1 of http://www.deepthought.com.au/health/openEHR/data_types_1_5_3_clean.pdf). Sam Heard has pointed out that timezone does not make any sense for pure dates (DV_DATE), only for DV_DATE_TIME or DV_TIME, since DV_DATE has an implied "error" of 24h, and there is no possibility of comparing two DV_DATEs and taking into account their timezone (except in the probabilistic sense, if you were to compare many of them). For example, there is nothing useful you can do with the timezone information in the dates 1/1/1940 +1000 (Australian eastern std timezone) and 1/1/1940 +0000 (London).

For comparison, I guess this is true. But for correctness' sake, recording of a date without its timezone still seems erroneous to me.

This is a fine point, and Sam's main concern is to reduce complexity for implementors, always a laudable cause. I am unsure of whether the argument about faithfulness is worth it, or whether there are other reasons to record timezone in a pure date.

Thoughts, anyone?

- thomas beale

2

Dear Thomas,

I happened to note your email below. I do not follow in detail the
project you are involved with, but noted the format you intend to
use for date and time notation.
This format at ill feet with the international standard on
this subject: ISO 8601. In that standard the example in your
email would be 1940-01-01+10:00 (or 19400101+1000)

My suggestion would be that for this topic your group considers the
applicability of the existing international standard before introducing

a new (and substantially different) format.

Kind regards,
Louis Visser

Thomas Beale <thomas@deepthought.com.au> 08/28/02 08:41am >>>

A few weeks ago, we inserted the class DV_WORLD_TIME into the data
types, as a parent of all date & time types measuring real world
(absolute) time, i.e. all of the types except DV_DURATION which just
measures a time difference or length, however you like to think of it.

Currently DV_WORLD_TIME has only one feature of its own -
timezone:DV_DURATION. (To see a UML diagram of what I am talking about,

go to section 6.1 of
http://www.deepthought.com.au/health/openEHR/data_types_1_5_3_clean.pdf).

Sam Heard has pointed out that timezone does not make any sense for
pure
dates (DV_DATE), only for DV_DATE_TIME or DV_TIME, since DV_DATE has an

implied "error" of 24h, and there is no possibility of comparing two
DV_DATEs and taking into account their timezone (except in the
probabilistic sense, if you were to compare many of them). For example,

there is nothing useful you can do with the timezone information in the

dates 1/1/1940 +1000 (Australian eastern std timezone) and 1/1/1940
+0000 (London).

For comparison, I guess this is true. But for correctness' sake,
recording of a date without its timezone still seems erroneous to me.

This is a fine point, and Sam's main concern is to reduce complexity
for
implementors, always a laudable cause. I am unsure of whether the
argument about faithfulness is worth it, or whether there are other
reasons to record timezone in a pure date.

Thoughts, anyone?

- thomas beale

3

Louis Visser wrote:

Dear Thomas,

I happened to note your email below. I do not follow in detail the
project you are involved with, but noted the format you intend to use for date and time notation.
This format at ill feet with the international standard on this subject: ISO 8601. In that standard the example in your
email would be 1940-01-01+10:00 (or 19400101+1000)

Actually, the text rendering of all dates and times in openEHR is ISO 8601 compliant, although I can't remember if we have stated this in the text (it's in the XML schema for example). I'll check this. My use of dates like "1/1/1940" below is purely informal.

My suggestion would be that for this topic your group considers the
applicability of the existing international standard before introducing
a new (and substantially different) format.

we have no interest in introducing a new format, but one thing to realise is that the ISO8601 format is for _representation_ not computation. The classes we have defined in the model are agnostic about representation internally, they are there to define semantics. But I should definitely improve the explanation in the text.

4

I should also mention that ISO 8601 is also specified in the TIME_SPECIFICATION types, which are based on HL7's work in this area, which is itself based on 8601.

- thomas beale

Louis Visser wrote:

5

Louis,

Implied in your post is the idea that pure dates do indeed have timezones. Do you agree that this is the case in ISO8601? If so, then I think it is better if all date/time types have a timezone.

- thomas

Louis Visser wrote:

6

Thomas Beale wrote:

Louis,

Implied in your post is the idea that pure dates do indeed have
timezones. Do you agree that this is the case in ISO8601? If so, then I
think it is better if all date/time types have a timezone.

I certainly do not speak for Louis but have been meaning to take
time to comment on this issue.

I wish I could support my argument with a 'solid' example. :slight_smile:
All I can say is that, I can imagine an instance (and it only takes
one to break a model) where a person is traveling from Los Angles to
Sydney and has just had an injection of some type before leaving
LA. They get to Sydney and seem to be having a reaction and are
taken to the Emergency Dept. Since we have this really cool world
wide accessible electronic health record, the staff gains proper
authority and reviews the patient's treatment before leaving LA. Do
they instantly know the time difference between LA and Sydney?
There must be a universal reference point if we are to envision
world wide access to a single record (virtual or physical) for care
and health tracking.

Given the fact that there are known duplicates in the abbreviations
used in timezones the offset to UTC should be used as a five
character string; -0600 or +1000 etc.
This also accomodates the various DST rollovers also.

Cheers,

7

Tim Cook wrote:

I certainly do not speak for Louis but have been meaning to take
time to comment on this issue.

I wish I could support my argument with a 'solid' example. :slight_smile:
All I can say is that, I can imagine an instance (and it only takes
one to break a model) where a person is traveling from Los Angles to
Sydney and has just had an injection of some type before leaving
LA. They get to Sydney and seem to be having a reaction and are
taken to the Emergency Dept. Since we have this really cool world
wide accessible electronic health record, the staff gains proper
authority and reviews the patient's treatment before leaving LA. Do
they instantly know the time difference between LA and Sydney?

ok - two things -
1. the time in this instance will have been recorded as a date/time - i.e. with time as well (not just a date)
2. if we do have timezone info in date/times, I think we are covered - assuming of course that the correct timezone values are written into the data items in each place

But I have to say that the kind of scenario you mention was also what I was thinking of. But then Sam brought up the point that if you were indeed jsut comparing two dates (no time info, but with timezone info) then the timezone info doesn't help you, since any pure date has a buil-in 24h window of "error" .

For the operation of comparison, I guess this is true. But for faihfulness of recording, I think we should have timezone on all date/times anyway, and one argument at least is that if you are doing it in the software for DV_DATE_TIME, DV_TIME, DV_PARTIAL_TIME, etc then it's easier just to do it for DV_DATE as well and be done with it. In any case, when I or some kind soul gets round to it, we will formally add the semantics of comparison of all date/time types.

There must be a universal reference point if we are to envision
world wide access to a single record (virtual or physical) for care
and health tracking.

so I think UTC expressed in one of the ISO 8601 formats fits the bill. Now, just looking at the explanatory pages at http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html and http://www.cl.cam.ac.uk/~mgk25/iso-time.html, I cannot actually see whether ISO8601 supports timezones on pure dates or not. Can anyone verify this for us?

Given the fact that there are known duplicates in the abbreviations
used in timezones the offset to UTC should be used as a five
character string; -0600 or +1000 etc.

I think you are saying we should nail it down to be one of the allowed ISO8601 formats. I think I would agree. And now that I think about it, the timezone limits whcih I set to be -1200 to +1200 are probably wrong - the customary way to do it is to go positive till you hit the dateline which is sometime after NZ or fiji, so I guess about +1400, and the max the other way must be -1000. Anyone got a firm answer on this?

This also accomodates the various DST rollovers also.

My understanding of this, is that you always record the timezone with the DST included. Your software also has to know the fixed timezone map of the world, and if it sees a +1100 where it expected a +1000 (e..g Sydney during daylight savings) it knows that DST is on at the moment in that place.

- thomas beale

8

Hello Thomas,

The standard has the implication that time and date
are concepts with "local" values.
For time this is explicit in the name of the representation:
"local time of the day";
for "date" it is not explicit, but the description of the
system can hardly be interpreted otherwise.

In reviewing the example I gave you, I noted that I responded
somewhat too quickly. That representation is actually not allowed
by the standard (sorry for the confusion I may have caused).
The current wording of the standard implies that "if a representation
contains a 'difference with UTC'-component", it must have a
time component (possibly with reduced precision).
So 2002-09-01T10+05 is allowed;
2002-09-01+05 is not allowed.
It would not be difficult to add (in a technical sense);
but nobody requested it at the time. So, one may
doubt if the need for that representation is internationally felt.

With this restriction the standard supports the representation of time
zones,
in addition to the representation of "local time". My feeling is that
the
removal of "local time" (something you seems to suggest in your letter)
would alienate
the standard from many users: the "local time" representation is
so much in use that is seems inappropriate to remove it.

Kind regards,
Louis Visser

Thomas Beale <thomas@deepthought.com.au> 08/30/02 02:52am >>>

Louis,

Implied in your post is the idea that pure dates do indeed have
timezones. Do you agree that this is the case in ISO8601? If so, then I

think it is better if all date/time types have a timezone.

- thomas

Louis Visser wrote:

Dear Thomas,

I happened to note your email below. I do not follow in detail the
project you are involved with, but noted the format you intend to
use for date and time notation.
This format at ill feet with the international standard on
this subject: ISO 8601. In that standard the example in your
email would be 1940-01-01+10:00 (or 19400101+1000)

My suggestion would be that for this topic your group considers the
applicability of the existing international standard before

introducing

a new (and substantially different) format.

Kind regards,
Louis Visser

Thomas Beale <thomas@deepthought.com.au> 08/28/02 08:41am >>>

A few weeks ago, we inserted the class DV_WORLD_TIME into the data
types, as a parent of all date & time types measuring real world
(absolute) time, i.e. all of the types except DV_DURATION which just
measures a time difference or length, however you like to think of

it.

Currently DV_WORLD_TIME has only one feature of its own -
timezone:DV_DURATION. (To see a UML diagram of what I am talking

about,

go to section 6.1 of
http://www.deepthought.com.au/health/openEHR/data_types_1_5_3_clean.pdf).

Sam Heard has pointed out that timezone does not make any sense for
pure
dates (DV_DATE), only for DV_DATE_TIME or DV_TIME, since DV_DATE has

an

implied "error" of 24h, and there is no possibility of comparing two
DV_DATEs and taking into account their timezone (except in the
probabilistic sense, if you were to compare many of them). For

example,

there is nothing useful you can do with the timezone information in

the

9

Dear Thomas,

ISO 8601 has a UTC format. But (as for the "difference with UTC")
only in case that the notation has a time component.
"Z" is the corresponding designator
so 16:00Z or 2002-09-02T16:00Z

You are right is saying the the differential component
is not limited to be between + and - 12:00
occasionally it can be larger.

Regards,
Louis Visser

Thomas Beale <thomas@deepthought.com.au> 08/30/02 08:30am >>>

Tim Cook wrote:

I certainly do not speak for Louis but have been meaning to take
time to comment on this issue.

I wish I could support my argument with a 'solid' example. :slight_smile:
All I can say is that, I can imagine an instance (and it only takes
one to break a model) where a person is traveling from Los Angles to
Sydney and has just had an injection of some type before leaving
LA. They get to Sydney and seem to be having a reaction and are
taken to the Emergency Dept. Since we have this really cool world
wide accessible electronic health record, the staff gains proper
authority and reviews the patient's treatment before leaving LA. Do
they instantly know the time difference between LA and Sydney?

ok - two things -
1. the time in this instance will have been recorded as a date/time -
i.e. with time as well (not just a date)
2. if we do have timezone info in date/times, I think we are covered -

assuming of course that the correct timezone values are written into
the
data items in each place

But I have to say that the kind of scenario you mention was also what I

was thinking of. But then Sam brought up the point that if you were
indeed jsut comparing two dates (no time info, but with timezone info)

then the timezone info doesn't help you, since any pure date has a
buil-in 24h window of "error" .

For the operation of comparison, I guess this is true. But for
faihfulness of recording, I think we should have timezone on all
date/times anyway, and one argument at least is that if you are doing
it
in the software for DV_DATE_TIME, DV_TIME, DV_PARTIAL_TIME, etc then
it's easier just to do it for DV_DATE as well and be done with it. In
any case, when I or some kind soul gets round to it, we will formally
add the semantics of comparison of all date/time types.

There must be a universal reference point if we are to envision
world wide access to a single record (virtual or physical) for care
and health tracking.

so I think UTC expressed in one of the ISO 8601 formats fits the bill.

Now, just looking at the explanatory pages at
http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html

and http://www.cl.cam.ac.uk/~mgk25/iso-time.html, I cannot actually see

whether ISO8601 supports timezones on pure dates or not. Can anyone
verify this for us?

Given the fact that there are known duplicates in the abbreviations
used in timezones the offset to UTC should be used as a five
character string; -0600 or +1000 etc.

I think you are saying we should nail it down to be one of the allowed

ISO8601 formats. I think I would agree. And now that I think about it,

the timezone limits whcih I set to be -1200 to +1200 are probably wrong

- the customary way to do it is to go positive till you hit the
dateline
which is sometime after NZ or fiji, so I guess about +1400, and the max

the other way must be -1000. Anyone got a firm answer on this?

This also accomodates the various DST rollovers also.

My understanding of this, is that you always record the timezone with
the DST included. Your software also has to know the fixed timezone map

of the world, and if it sees a +1100 where it expected a +1000 (e..g
Sydney during daylight savings) it knows that DST is on at the moment
in
that place.

- thomas beale

10

Dear all,

I have been working hard to get an ontology of archetypes developed that
will show the health domain mapped into the openEHR architecture. I have
found a couple of things:

1. That there is often a link between an instruction and subsequent
observations - which I think will be more important as knowledge bases are
developed in the future. I have called the link an action specification and
at present it is modelled as part of the instruction. Let me give a real
example.

If you prescribe a medicine then there are a number of attributes of that
medication order - dose, form, route etc - and there is the frequency of
administration. When you record that a medication has been administered -
then you record the dose, form, route etc - but not the frequency. The link
is the specification of the action - but not the conditional elements of the
instruction.

Many other things may be specified at the time that they are ordered and
there may be protocols etc that are to be followed.

For this reason - I have two new subclasses in the ontology (not in
openEHR) - "openEHR Observation - action" and "openEHR action
specification". This allows me to say which action specification applies to
an instruction and which obeservations it applies to.

2. It might be necessary to state the sequence of different instructions.
The French oncologists wish to state this for Surgery, Radiotherapy,
Chemotherapy etc. Clearly each of these will have a complex action
specification. How then to make it clear about the order of the
instructions - should one finish before the other starts?

I welcome your ideas. I have put the zipped (45K) protege files on
www.gehr.org in the Watch this space section.

Cheers, Sam

11

Sam,

Could the following be another example?

The Blood pressure.
The RR as an act, a measurement, a procedure.
And the RR as a set of values, the result of the act, the measurement
results, the result of a procedure.

The act is one thing, an intention.
The value as the result of the execution of the intention.

The intention can exist without a real value.

In ENV 13606 part 2 there are the possibilities to add modifiers
(attributes) to 'things' that can express concepts like these.

The question is:
Will we need a new Concept Information Model (archetype) to distinguish
between the two or is one attribute enough?

Gerard

Dear all,

I have been working hard to get an ontology of archetypes developed that
will show the health domain mapped into the openEHR architecture. I have
found a couple of things:

1. That there is often a link between an instruction and subsequent
observations - which I think will be more important as knowledge bases are
developed in the future. I have called the link an action specification and
at present it is modelled as part of the instruction. Let me give a real
example.

If you prescribe a medicine then there are a number of attributes of that
medication order - dose, form, route etc - and there is the frequency of
administration. When you record that a medication has been administered -
then you record the dose, form, route etc - but not the frequency. The link
is the specification of the action - but not the conditional elements of the
instruction.

Many other things may be specified at the time that they are ordered and
there may be protocols etc that are to be followed.

For this reason - I have two new subclasses in the ontology (not in
openEHR) - "openEHR Observation - action" and "openEHR action
specification". This allows me to say which action specification applies to
an instruction and which obeservations it applies to.

2. It might be necessary to state the sequence of different instructions.
The French oncologists wish to state this for Surgery, Radiotherapy,
Chemotherapy etc. Clearly each of these will have a complex action
specification. How then to make it clear about the order of the
instructions - should one finish before the other starts?

I welcome your ideas. I have put the zipped (45K) protege files on
www.gehr.org in the Watch this space section.

Cheers, Sam
____________________________________________
Dr Sam Heard
The Good Electronic Health Record
Ocean Informatics, openEHR
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard@bigpond.com
www.gehr.org
www.openEHR.org
__________________________________________

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

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

+31 252 544896
+31 654 792800

12

Gerard

As we are working on an EHR this is not such a dilemma. There are two
things - an instruction to record that something should get done. A blood
pressure is fully specified as an archetype so there is only the need to say
a BP in this instance. This might be part of the care plan - but it could be
to do vital signs every hour. This is an organiser.

I do not see the HL7 or 13606 approaches as appropiate as they are overly
complex for an EHR and are appropriate for messaging.

Cheers, Sam

13

Gerard

The idea in messaging usually is that there is an attribute that changes the
meaning of an entry from an intention to an action. This works for a few
things like - I am going to do these tests - or write this letter - to I
have done it.

Instructions in openEHR have a state machine - something that can allow you
to do this and record the instruction as having been completed - a proxy for
completing the act in the situation above.

A medication order will be carried out - usually - on many occasions - and
the batch number and site of administration (with insulin for example) may
be added.

An instruction may lead to a notification - at the user level (EHR open) or
system level (Recall).

Some actions are fully specified as entries already. A BP recording is fully
specified as an Observation and does not need to be specified in the
instruction to do it.

So instructions are not just a different expression of the action.

I hope this is helpful?

Cheers, Sam

14

What happens when messaging is used for query. I view messaging as any
interchange between two or more entities. I view pier to pier
communications as messages, and I have found nothing to contradict that. I
would be interested in any references that suggest otherwise.

Why is the definition of messaging important? Messaging is different from
syntax. Whether I use ER7, XML, SOAP or whatever, the trigger events and
message content is what is important and what will be persistent. strongly
agree that messages are different than the EHR. However, I populate much
of my EHR from messages I receive from other components of the health care
institution - lab, radiology, ADT, pharmacy, clinic, etc.

Ed

15

This ontology of archetypes discoveries sound an awful lot like the nursing project of the early-mid 1990's on classification. The result of this project produced three classification schemes and defined the linkages between the three. These classifications include:

Nursing Interventions Classification (NIC)
Nursing Outcomes Classification (NOC)
North American Nursing Diagnosis Association (NANDA)

From Sam's example below, the Diagnosis is roughly equivalent to an observation (NANDA), the intervention is the action (NIC)...and expected outcomes are not discussed...but seemingly might also be an action in Sam's example.

The nursing classifications are comprehensive, but specific to nursing. I suspect the openEHR definition are targeted at the general practitioner, at least initially. Still, there may be some level of re-use possible from the Nursing classifications. The bottom line is we should look at the structure of the nursing classification scheme, and associated linkages between the classification. It provides a very organized way to represent clinical actions and reactions. It is roughly in keeping with the Archetype ontology Sam describes, but not an exact fit.

For those who want further detail, here's a brief go at describing NIC and NOC in short. The publications do much more justice than this short synopsis.

Each intervention has a succinct definition followed by a detailed listing of activities for that particular intervention (sequencing accounted for). Actions for openEHR and NIC activities appear roughly equivalent. An example of an intervention is Fluid Management defined as "Promotion of fluid balance and prevention of complications resulting from abnormal or undesired fluid levels". Activities for Fluid Management are two pages long, but include "Monitor vital signs, as appropriate; Maintain accurate intake and output record; Weigh daily and monitor trends; etc.

Each outcome has a succinct definition followed by a detailed listing of indicator categories (and a 1 - 5 "level" for setting indicator severity). An example of a outcome is Electrolyte & Acid/Base Balance defined as "Balance of electrolytes and non-electrolytes in the intracellular and extracellular compartments of the body". Indicators for this outcome include (only a few from the page of indicators) Heart rate IER; Heart rhythm; respiratory rate; Serum Na; Serum K; Serum Cl; Serum Ca; Serum pH; BUN; Urine pH; mental alertness; etc. For each indicator a level of "1" for Extremely Compromised - to - "5" Not Compromised is indicated.

There are interesting software packages that take the input of the nursing practices and provide disease and materials management capabilities.

I believe that openEHR will find these classification schemes useful. It will require a fairly significant amount of research to duplicate such and effort, so it might be worth taking a looksee.

16

William E Hammond wrote:

What happens when messaging is used for query. I view messaging as any
interchange between two or more entities. I view pier to pier
communications as messages, and I have found nothing to contradict that. I
would be interested in any references that suggest otherwise.

I don't want to get into any serious debate on the issue (since for many people it is an argument of whether 6 eggs is the same as "half-a-dozen" or not), but one differentiator is that people tend to use the word "message" more when the structure of the messages themselves have been defined - i.e. that is what is being standardised, and nothing is being said about the communicating systems. People talking about peer-peer or other configurations of distributed systems are usually thinking more along the lines of information/service model defintions of the systems, while the messages are not defined explicitly - they come out automatically from the tools, based on the service models, as happens in CORBA, COM, .net, OSF/DCE, XML/SOAP and other such technologies.

Some people will call everything that goes between two nodes a "message", which is literally true, but not that useful for explaining what kind of message, or how it was put together, or what rules it obeys. So I tend to use the word to mean communications which have been specified by defining message contents, rather than the semantics of information or services available in systems.

So in openEHRor CEN, if there were two nodes sending part of an EHR to each other, and XML/SOAP/WSLD (essentially the web version of Corba or RPC) was being used, I would not explain it to someone as being a message, since there is no need to specify the message, even though in literal terms, a "message" (= string of bytes) is being sent. However, if an EHR node was receiving a pathology result in HL7 form, I would call it a "message".

Why is the definition of messaging important? Messaging is different from
syntax. Whether I use ER7, XML, SOAP or whatever, the trigger events and
message content is what is important and what will be persistent. strongly
agree that messages are different than the EHR. However, I populate much
of my EHR from messages I receive from other components of the health care
institution - lab, radiology, ADT, pharmacy, clinic, etc.

That's true, but it is more than likely that a) a lot of messages are of no interest to the EHR (e.g. they are destined for an orders management, prescription, or admin service) and b) messages which are of interest will not go into the EHR in their message form. They will be validated, sifted, filtered, reformatted into EHR form, have links back and forward to other EHR items added, be classified this way and that, during the process of being added to the EHR. As soon as one starts thinking about what has to happen to turn messages into EHR content, it becomes clearer and clearer that the EHR is nothing like a compendium of messages; for from it - it is a time-based accumulator of EHR information, some of which is sourced from messages, much of which is created by human users of GUI applications.

- thomas beale

17

Thomas,

Somewhat to my surprise I find myself agreeing with most of your points in the discussion below.

However, the final statement "... As soon as one >starts thinking about what has to happen to turn messages into EHR >content, it becomes clearer and clearer that the EHR is nothing like a >compendium of messages; for from it - it is a time-based accumulator of >EHR information, some of which is sourced from messages, much of which >is created by human users of GUI applications." seems like a gross oversimplification of the reality.

It is true a "readable" EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR.

As well as a clarification of scope, it would seem to be important to clarify at what level of context/granularity we are seeking to produce the EHR.

Sorry if I've missed anything - but the recent discussions would seem to indicate that I'm not alone if I have.

Regards,

Melvin Reynolds.

In mail of Tue, 10 Sep 2002 17:10:14, Thomas Beale

18

Melvin

I agree with you - but the EHR efforts are not doing this.

I think that your response is a 'paper-based' response - that we have to see
all these things - because they are accessible. One great advantage of the
EHR is that things can be presented to us as we require - we have a lot to
learn about this.

The reality is that in primary care I might need the 24hr Urinary Protein
result done 2 years ago in Hospital - I might not. Why limit the access of
people to information that is helpful at the design stage. Sure I only want
to see it if I need it.

We do need an audit trail that meets privacy, accountability and medicolegal
requirements - everywhere. It should be completely behind the scenes.

Cheers, Sam

19

Melvin Reynolds wrote:

Thomas,

Somewhat to my surprise I find myself agreeing with most of your points in the discussion below.

he he he, that's the kind of reply I like to see;-)

However, the final statement "... As soon as one >starts thinking about what has to happen to turn messages into EHR >content, it becomes clearer and clearer that the EHR is nothing like a >compendium of messages; for from it - it is a time-based accumulator of >EHR information, some of which is sourced from messages, much of which >is created by human users of GUI applications." seems like a gross oversimplification of the reality.

It is true a "readable" EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR.

Well, that's probably fair enough (although I am not sure I believe that GPs are any less required to have medico-legal protection than any other clinician), but consider that even in a local GP EHR, modifications to things like Current Medications, Family history, Social History, Vaccination record, Therapeutic precautions , Problem list, will generally not come from messages - there is no other place for this data to come from but the GP application. It will instead come through the application / EHR kernel API, and create EHR data on the fly.

Now... try to imagine how useful the GP EHR would be minus the items I mention....

As well as a clarification of scope, it would seem to be important to clarify at what level of context/granularity we are seeking to produce the EHR.

do you want to expand on this?

Sorry if I've missed anything - but the recent discussions would seem to indicate that I'm not alone if I have.

just point it out, and I'll try to explain more what I think, if at least that can help...

- thomas

20

In mail of Fri, 13 Sep 2002 16:14:26, Thomas Beale

Melvin Reynolds wrote:

Thomas,

Somewhat to my surprise I find myself agreeing with most of your points in the discussion below.

he he he, that's the kind of reply I like to see;-)

Well, we all need a bit of humour ...

However, the final statement "... As soon as one >starts thinking about what has to happen to turn messages into EHR >content, it becomes clearer and clearer that the EHR is nothing like a >compendium of messages; for from it - it is a time-based accumulator of >EHR information, some of which is sourced from messages, much of which >is created by human users of GUI applications." seems like a gross oversimplification of the reality.

It is true a "readable" EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR.

Well, that's probably fair enough (although I am not sure I believe that GPs are any less required to have medico-legal protection than any other clinician), but consider that even in a local GP EHR, modifications to things like Current Medications, Family history, Social History, Vaccination record, Therapeutic precautions , Problem list, will generally not come from messages - there is no other place for this data to come from but the GP application. It will instead come through the application / EHR kernel API, and create EHR data on the fly

Now... try to imagine how useful the GP EHR would be minus the items I mention....

Once again I agree (mostly!) - and certainly did not want to imply different levels of medico-legal requirement within any particular jurisdiction.
The integrated healthcare record is very usefully regarded as a single repository which contains, either directly or by reference, all the data that relates to the process of actually clinical care (not the facilitating aspects of the healthcare infrastructure*) - but upon which there are appropriate "views" according to the use context. However, the difficulty I have is with the "throwaway" statements (perhaps just intended as 'shorthand' but if so not sufficiently specific to be helpful at this stage of development and email communication) which if taken literally will result in flawed design:

"generally not come from messages - there is no other place for this data to come from but the GP application"
"generally" and "there is no other place" is the problem here, "often" would be more accurate because, as an example, the giving of vaccinations to children in school is not likely to be noted through the multiple GP systems related to the children - but through a Community system (of whatever sort) - and then "messaged" back to the EHR as seen by the GP - so there's clearly an "other place". Similarly Social history information may well arrive from the Social services system ...

"instead come through the application / EHR kernel API,"
fine, so long as this means:
"through *an* application *and/or* the kernel API"

"and create EHR data on the fly."
fine, so long as this means, for example:
"receive (and store) message data,
acknowledge message data if appropriate according to implementation requirements,
assign message data to EHR as agreed by all users of EHR *or*
reject message data for EHR as agreed by all users of EHR (but in this case log receipt of message data even if not available for 'default display')."

As well as a clarification of scope, it would seem to be important to clarify at what level of context/granularity we are seeking to produce the EHR.

do you want to expand on this?

No. I think that we've clarified my understanding of your meaning - and I agree totally# with Sam's response to my mail (with the exception of the comment about thinking in paper terms - my concern is precisely that some of the words lead me to think that the EHR is being thought of in those terms). The appropriate view of the 'full granularity repository' lies in the local implementation to fulfil the requirement for a particular user/set of users.

Sorry if I've missed anything - but the recent discussions would seem to indicate that I'm not alone if I have.

just point it out, and I'll try to explain more what I think, if at least that can help...

This should have read "Sorry if I have missed *something*". I guess from mails on another thread that these issues will get another airing in Baltimore. What it underlines for me is the need for precision in our use of terms - and I plead guilt to imprecision when doing/saying things in haste, and sometimes at other times too :).

- thomas

*# If you want a review of these concepts see Figures 12* and 8# in CEN TC251 Strategic Study on Health Information Infrastructure,
http://www.centc251.org/TCMeet/doclist/TCdoc00/N00-074.pdf
subsequently refined in BS8421-1.