I am writing my diploma thesis at the Vienna Medical University. I have
two questions concerning the openEHR-EHR-OBSERVATION.blood_pressure.v1
Archetype (Date 22/03/2006) and would be very thankful if someone could
answer them briefly.
1st:
I read in the "The openEHR Reference Model - EHR Information Model"
(openehr_ehr_im.pdf Revision: 5.1.0) in chapter "8.2.3.4 Two ways of
Recording State" that there are two ways to record States inside a History.
In this Blood pressure measurement Archetype they have chosen the way
where the state is recorded outside data History.
Isn´t it necessary to correlate a blood pressure measurement [at0003] to a
position [at0008] (Systolic: 120, Diastolic: 80, Position: Standing)?
What is the medical reason for modelling it like that? Even if it is made
the other way the problem still occurs with the protocol. When we try to
match an Instrument [at0012] (from Protocol) to a certain blood pressure
measurement (Systolic: 120, Diastolic: 80, Instrument: XYZ) we don´t know
which instrument belongs to which blood pressure. Am I wrong? Is there a
way to correlate them? Is there no need to correlate them?
I am writing my diploma thesis at the Vienna Medical University. I have
two questions concerning the openEHR-EHR-OBSERVATION.blood_pressure.v1
Archetype (Date 22/03/2006) and would be very thankful if someone could
answer them briefly.
1st:
I read in the "The openEHR Reference Model - EHR Information Model"
(openehr_ehr_im.pdf Revision: 5.1.0) in chapter "8.2.3.4 Two ways of
Recording State" that there are two ways to record States inside a History.
In this Blood pressure measurement Archetype they have chosen the way
where the state is recorded outside data History.
Isn´t it necessary to correlate a blood pressure measurement [at0003] to a
position [at0008] (Systolic: 120, Diastolic: 80, Position: Standing)?
Actually, this archetype has been remodelled using the other method.
Both methods make sense, depending on what you are doing, but the
state-on-Event method is more likely with normal GP and hospital
recording, whereas the other one would be more likely used in sport
medicine, or maybe in conjunction with ECG etc in general fitness testing.
What is the medical reason for modelling it like that? Even if it is made
the other way the problem still occurs with the protocol. When we try to
match an Instrument [at0012] (from Protocol) to a certain blood pressure
measurement (Systolic: 120, Diastolic: 80, Instrument: XYZ) we don´t know
which instrument belongs to which blood pressure. Am I wrong? Is there a
way to correlate them? Is there no need to correlate them?
No, protocol (i.e. method of measurement) is the same for the whole
history - this is definitional. You can't safely change how you record
something in mid-series - you have to record a new time series.
2nd:
Why does the "state" begin with an ITEM_LIST[at0007] and not with a
History? In the documentation it looks as if "state" and "data" have the
same structure.
they do; this was an error in the Archetype Editor which has now been
fixed, but the archetypes have not being upgraded yet.
Christoph
Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version.
The result is attached, Sam
I should point out that the embedded state within each event isn't
supported by the Java Archetype Editor (only separate state with
history), but a new version that supports this will probably be out
soon...
Actually, when the Java editor finds a state defined at the root level
it is transformed to a state with history because that is the closest
thing it resembles.
Another question related to this. Is there any need in an archetype
editor to specify different data and state for some events instead of
always creating them in the first event in the history and then let
all the succeding events reference (use_node) the data and state in
the first event? If a user decides to edit ADL manually and sets
different data and state for some events, it is not supported by
neither of the current archetype editors...
Mattias Forss wrote:
>
>>
>>> Christoph
>>> Some things have been around for a long time in our development and one was
>>> to have state defined at the root level even though it applied to each
>>> event. The current editor should read both but saves the correct version.
>>> The result is attached, Sam
>>>
>> I should point out that the embedded state within each event isn't
>> supported by the Java Archetype Editor (only separate state with
>> history), but a new version that supports this will probably be out
>> soon...
>>
>> Actually, when the Java editor finds a state defined at the root level
>> it is transformed to a state with history because that is the closest
>> thing it resembles.
>>
>>
>
> Another question related to this. Is there any need in an archetype
> editor to specify different data and state for some events instead of
> always creating them in the first event in the history and then let
> all the succeding events reference (use_node) the data and state in
> the first event? If a user decides to edit ADL manually and sets
> different data and state for some events, it is not supported by
> neither of the current archetype editors...
>
In general this should not happen, since the phenomenon being recorded
in each event is supposed to be the same one, just at different time-points.