Dear all,
There are several types of models:
-first order: models about what really happened
-second order: models about observations of what happened in real
life (perhaps). The direct observation.
-third order: models about what somebody (something) observed and
reports about. The indirect observation.
In our discussion about Observation Archetypes we need to be clear
what we are talking about.
In contrast to HL7 (they mix all three in one bag and create chaos)
we CEN, OpenEHR, never talk about first order models.
We talk about second and third order models.
The Observation archetype must have two distinct variants: the direct
observation and the indirect observation.
A Blood pressure measurement by a clinician recorded in his ICT-
system is a direct observation.
A Blood pressure measurement by a patient recorded by the clinician
in his ICT-system is an indirect observation.
A Blood pressure measurement by an automatic device recorded in the
ICT system of the patient or clinician is an indirect measurement.
In all cases the origin and its characteristics of the observation
must be recordable.
In many cases these actors (entities) are to be found in a registry
where this resource is managed.
When information is exchanged between jurisdictions (that do not use
the same resource registries) this information ends up in a message/
template.
In the example of the Blood Pressure Archetype we see aspects from
the second and third order models.
Second order models do not describe the source explicitly because
this is the author.
Third order models define the actors in one level of more detail. The
source and its characteristics must be described.
The characteristics of persons differ from those of machines.
Machines have device dependent characteristics but many times include
persons as operators.
This brings me to a cascade of archetypic building blocks.
These building blocks I would like to call atomic archetypes.
And many GPICS (an European CEN standard) will provide input to
archetypes.
1 Observation
a- first order (implicit actor)
b- second order (explicit actors)
I- Person characteristics
II- Medical device
i- Hardware, software characteristics
ii- Person as operator characteristics
Based on all recorded objective characteristics each author allowing
data in his ICT-system must make a subjective value judgement.
Next to each entry it must be possible to indicate at a certain time
the value judgement.
Many times this indication will be empty, some times it will indicate
its trust value.
Gerard Freriks
conexis
---------------------------
Gerard Freriks, MD
Huigsloterdijk 378
2158LR Buitenkaag
the Netherlands
M: +31 620347088
E: gf at conexis.nl
On Jul 13, 2007, at 11:23 AM, Thomas Beale wrote:
> Stef Verlinden wrote:
>>
>>
>> So I guess I have several questions, which I try to separate.
>>
>> The first part is: how/where can we add the accessory data that
>> necessary to establish data quality. As Thomas pointed out, most of
>> these things are already recorded. In would like to have clarity
>> on to
>> things:
>>
>> 1. device information (calibration, maintained etc, etc.). Thomas
>> suggested that one should store those in the protocol part of an
>> observation. That?s a possibility but then one has to fill out that
>> data every time an observation is made.
> do
> an INR competently.
>> Form what I understood form the demographic IM , there is a
>> capability
>> class in which ? the qualifications of the performer of the role for
>> this capability?. I guess my question is, is there a role self/
>> citizen/ non-professional (I don?t know how we should call that role)
>> and can we attach capabilities to that role?
> I can see you are already ahead of me;-)
>>
>> The second part is about the data quality criteria. Although these
>> criteria are subjective, they?re real and useful for the parties who
>> agreed upon those criteria. Look for instance at the ?report of the
>> independent advisory group on blood pressure monitoring in clinical
>> practice? by the MHRA. This is an example of quality criteria one
>> could agree upon. Based on such criteria one could rate the recorded
>> data as good or poor (or even an more refined scale if required)
>> Now my question. Where can/ should we store such a data quality
>> marker. I figured that since these are local/subjective criteria you
>> don?t want to put them in the original/ root archetype that?s
>> intended
>> for ?worldwide? use. So my suggestion is to create a ?local?
>> specialization of this root archetype in which both the criteria and
>> the data quality label are added (see my previous mail).
>> Is this a good suggestion and if not where can I store that data
>> after
>> all. I don?t want to create a second system for this and in my
>> opinion
>> this type of data belong somewhere in an EHR.
> Various places it could go in the current openEHR model:
> - in the protocol (it is essentially meta-data to do with 'how' the
> measurement was done)
> - in the 'data' art of the archetype, which might be sensible,
> particularly for patient questionnaires
>
> but this is assuming that you don't want to use the Quantity.accuracy
> approach. You could already record +/-20% (95% confidence, normal
> distribution) in a Quantity. Some people here e.g. Tim Churches who
> has
> a population health perspective - have correctly suggested that to be
> comprehensive, we should allow for other distributions, and
> therefore a
> more elaborate model of 'accuracy'. If the community indeed sees the
> added complexity (over and above the simple approach of recording
> accuracy = +/-5% etc) is worth it, then we will add it to the model.
>
> - thomas
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
conexis
---------------------------
Gerard Freriks, MD
Huigsloterdijk 378
2158LR Buitenkaag
the Netherlands
M: +31 620347088
E: gf at conexis.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070713/9d263b45/attachment.html>
