Here is a possible new data type being suggested in HL7, which looks real enough to me. Original post from Lloyd McKenzie (HL7 MnM list) below. I would not agree with the exact model he has proposed (modified CE/CD) but rather a new subtype of CV, or what we call CODED_TEXT in openEHR (what was called TERM_TEXT).
It seems reasonable that we use the coding aproach to represent error or other short messages, including with the idea of parameters, since a) we want the same language translation facility and b) it would be convenient to use the coding approach to deal with such message strings, rather than having to have some other mechanism. Logically the subtype of CODED_TEXT would be called something like PARAMETERISED_MESSAGE, i.e. a message whose whole text is coded, but contains placeholder positions for parameters, similar to unix variables in strings. There are probably other, less ugly names, but I can't think of one at the moment...
Language translations are part of the terminology service from my point of
view and the text should be in the original language. I do not think that
the 'translations' should be used for language - but for different coding
systems.
I do not think this has any implications for openEHR at the moment.
I do not think this has any implications for openEHR at
the moment.
Sam
> It seems reasonable that we use the coding aproach to
represent error or
> other short messages, including with the idea of
parameters, since a) we
It would seem reasonable if we were talking about a messaging
system. But I think in this case, a specific implementation will
need to address this issue. This is where an implementer will
likely follow the HL7 message format since that is what it is
intended for.
The quantity data type has the possibility of revealing changes that are
unexpected. Let us say for example that you weigh someone and their weight
is 80 Kg - and they tell you that they weighed 100 Kg 3 months ago. Or that
a Hb was 151 and it is now 121 - still normal but has changed a lot and you
may want to have this brought to your attention.
ALSO - we have not differentiated at the RM level between information from
the clinician and that given by the patient. So OBSERVATION covers both -
sure we can say where it came from but the weight example really shows that
it may be from both.
For this reason - I would like to see the Delta (or change) attribute to
quantities to enable us to say if this measurement has gone up or down more
than expected.
The quantity data type has the possibility of revealing changes that are
unexpected. Let us say for example that you weigh someone and their weight
is 80 Kg - and they tell you that they weighed 100 Kg 3 months ago. Or that
a Hb was 151 and it is now 121 - still normal but has changed a lot and you
may want to have this brought to your attention.
ALSO - we have not differentiated at the RM level between information from
the clinician and that given by the patient.
why do you say that - ENTRY.provider does this.
So OBSERVATION covers both -
sure we can say where it came from but the weight example really shows that
it may be from both.
not sure what you mean here....
For this reason - I would like to see the Delta (or change) attribute to
quantities to enable us to say if this measurement has gone up or down more
than expected.
just one little question: when does it get turned on? What is "a lot", or "more than expected"?
-1- A measument is a measurement. It is raw data.
-2- An interpretation of raw data by a human or agent or Archetype
transforms this in Information.
Any interpretation is a view on raw data plus a (subjective) interpretation.
And systems should show this and the author of this subjective
interpretation.
Boundary problem:
A radiologist interterprets a complex x-ray. The x-ray is the raw data. The
radiology note is the attributable view on raw data plus the subjective
interpretation.
Now this note is sent to a GP.
At the receiving GP system this note is treated as raw data. Measurement.
After acceptation by the GP and submission this raw data to the record it
can be used to interterpret it. Etc, etc.
The delta-flag is not an attribute to data but a subjective interpretation
recorded in a subjective view.
Gerard
Sam Heard wrote:
Hi
The quantity data type has the possibility of revealing changes that are
unexpected. Let us say for example that you weigh someone and their weight
is 80 Kg - and they tell you that they weighed 100 Kg 3 months ago. Or that
a Hb was 151 and it is now 121 - still normal but has changed a lot and you
may want to have this brought to your attention.
ALSO - we have not differentiated at the RM level between information from
the clinician and that given by the patient.
why do you say that - ENTRY.provider does this.
So OBSERVATION covers both -
sure we can say where it came from but the weight example really shows that
it may be from both.
not sure what you mean here....
For this reason - I would like to see the Delta (or change) attribute to
quantities to enable us to say if this measurement has gone up or down more
than expected.
just one little question: when does it get turned on? What is "a lot",
or "more than expected"?
- thomas beale
-
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
The delta-flag is not an attribute to data but a subjective interpretation
recorded in a subjective view.
or at least an objectively computed difference with some previous observation - but you are right, it is not raw data. I would say it is up to an application to be looking backwards in time for previous weights or whatver, and when it gets a new one which is wildly different, it might alert the physician - but even to do that, you have to establish reference ranges etc for that person, for what are dangerous changes of weight. I imagine athletes and certain other categories of people (actors maybe?-) change weight quite a lot but can be quite healthy; others might creep to 200kg very slowly but be very unhealthy. I don't think this is as simple as it seems..
As a 'watcher' on the discussion, whilst the rationale is very
interesting , is there a repository with a draft of the overall 'record'
structure and definitions as the debate refines it that I could look at
to get an overall view please??
Thanks Jean Roberts
Watch out for 'RADICAL STEPS' in health informatics UK!!
Phoenix Associates, 19 Church Meadow, Ipstones, Staffs, ST10 2LS UK
email : jean@hcjean.demon.co.uk http://www.hcjean.demon.co.uk
tel 07771 804472 or tel/fax+44 1538 266944
As a 'watcher' on the discussion, whilst the rationale is very
interesting , is there a repository with a draft of the overall 'record'
structure and definitions as the debate refines it that I could look at
to get an overall view please?? Thanks Jean Roberts
I know intermountain already do this from their labs - the important thing
is that it can enable a clinician to do it as well - it might be the first
reading in the record but is a major change from what the patient reports as
normal - alcohol intake, weight etc.
I am thinking of the ability to flag it rather than write a lot of text to
say this is more than in the past.
But it is possible to have an objective measure of difference that might be
flagged - such as a change of > 20 standard drinks in one year in the
alcohol intake - or a change in weight of 10kg in one year..
I agree that there is a subjective element to this - but it is not cut and
dried.