Dear Nigel
It is good to see someone reviewing an archetype - this one has really
had very little feedback so far. You immediately raise design issues
which are exactly what is needed and what we need to think about is how
it is best to do this.
Archetypes should be inclusive - if the HCO3 is different from the one
measured in electrolytes then this should be included here - it is
possible to repeat the same item in 2 archetypes but should be
discouraged. Rather, use both archetypes within a blood gas report.
This sounds a little weird at first but makes the world much simpler.
It is really for a group of experts to decide and then commit on.
It is worth considering the issue of moving the problem elsewhere - it
is exactly that - we can use one schema for all data and so everyone
can receive all information if they use the openEHR reference model.
Knowing what the data means requires knowledge of the archetype - so
systems which want to process information need to know what arechetypes
mean. They can deal with this later (as the applications become more
sophisticated) or use third-party tools which do know about the unknown
information (eg decision support tools).
Surprisingly, it is quite possible to receive, edit and display complex
information in the openEHR environment about which the system knows
nothing - through use of archetype enabled components. This should mean
that the cardiologist who wants to take part in an internation study
does not need to alter his system in order to do so - just get some
archetypes and templates going in the application that supports the
archetype enabled tools.
Cheers, Sam
Dr Nigel Brown wrote:
-----Original Message-----
From: Hugh Leslie [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 3 January 2006 9:25 PM
To: 'General Practice Computing Group Talk'
Subject: RE: GP Requirements - was [GPCG_TALK] Re: The Dreaming
.. This leads to ever expanding and inflexible
schemas that have to be added to or changed whenever our
clinical understanding grows or changes. It means that we as
clinicians have to try to describe clinical concepts to
programmers so that they can build systems that work.
I don't know that the concept of archetype isn't just shifting the
inflexible schema elsewhere.
Below is an extract from the archetype for blood gases
http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ
ation/openEHR-EHR-OBSERVATION.blood_gases.v1.html
A few comments:
I note the site of collection (arterial vs venous) produces a (partial)
doubling of the archetype
- why not one set of analytes with a slot for site of origin? While what
has been chosen is one way to go how is the choice arrived at? How does it
cope with reporting an arterial blood gas bicarbonate - or is that part of
another electrolyte archetype? So do you need a super-archetype to bring
together commonly co-reported information?
How does it cope with local practice differences e.g. some use Base Excess
while others may prefer Standard Bicarbonate as a derived parameter.
I realise all these sorts of questions have been (or are being) agonised
over with LOINC coding and SNOMED-CT with no one answer - so are archetypes
related to these or another bite of the same cherry?
I also note the "copyright (c) 2004 Ocean Informatics" on the archetype.
The basic question in this is perhaps "What is the process for archetype
creation, stabilisation and updating?".
Regards
Nigel
openEHR-EHR-OBSERVATION.blood_gases.v1
concept
[at0000] -- Blood gas assessment
description
original_author = <
["name"] = <"Sam Heard">
["organisation"] = <"Ocean Informatics">
["date"] = <"2004-09-01">
>
details = <
["en"] = <
language = <"en">
purpose = <"Report blood gas measurement result and protocol">
keywords = <"blood gases", ...>
copyright = <"copyright (c) 2004 Ocean Informatics">
>
>
lifecycle_state = <"draft">
definition
OBSERVATION[at0000] ∈ { -- Blood gas assessment
data ∈ {
HISTORY[at0002] ∈ { -- history
events cardinality ∈ {1..*; ordered} ∈ {
EVENT[at0003] occurrences ∈ {0..*} ∈ { -- Any event
data ∈ {
TREE[at0001] ∈ { -- structure
items cardinality ∈ {0..1; ordered} ∈ {
CLUSTER[at0011] occurrences ∈ {0..*} ∈
{ -- Arterial
items cardinality ∈ {0..1; ordered}
∈ {
ELEMENT[at0004] occurrences ∈
{0..1} ∈ { -- PaO2
value ∈ {
C_QUANTITY <
property =
<"pressure">
list = <
["1"] = <
units =
<"kPa">
magnitude =
<|>= 0.0|>
>
>
>
}
}
ELEMENT[at0005] occurrences ∈
{0..1} ∈ { -- PaCO2
value ∈ {
C_QUANTITY <
property =
<"pressure">
list = <
["1"] = <
units =
<"kPa">
magnitude =
<|>= 0.0|>
>
>
>
}
}
ELEMENT[at0006] occurrences ∈
{0..1} ∈ { -- pH
value ∈ {
C_QUANTITY <
property =
<"concentration">
list = <
["1"] = <
units = <"">
magnitude =
<|0.0..14.0|>
>
>
>
}
}
ELEMENT[at0007] occurrences ∈
{0..1} ∈ { -- Base excess
value ∈ {
C_QUANTITY <
property =
<"concentration">
list = <
["1"] = <
units =
<"mmol/l">
magnitude =
<|-30.0..30.0|>
>
>
>
}
}
ELEMENT[at0008] occurrences ∈
{0..1} ∈ { -- Alveolar-arterial pO2 difference
value ∈ {
C_QUANTITY <
property =
<"pressure">
list = <
["1"] = <
units =
<"kPa">
magnitude =
<|0.0..1000.0|>
>
>
>
}
}
ELEMENT[at0015] occurrences ∈
{0..1} ∈ { -- SaO2
value ∈ {
C_QUANTITY <
property =
<"concentration">
list = <
["1"] = <
units =
<"%">
magnitude =
<|0.0..1000.0|>
>
>
>
}
}
ELEMENT[at0012] occurrences ∈
{0..1} ∈ { -- Site
value ∈ {
CODED_TEXT ∈ {
code ∈ {[ac0005]}
-- Any term that 'is_a' artery or cavity
}
}
}
ELEMENT[at0018] occurrences ∈
{0..1} ∈ { -- CaO2
value ∈ {
C_QUANTITY <
property =
<"concentration">
list = <
["1"] = <
units =
<"{VOLUME/VOLUME}">
magnitude =
<|>= 0.0|>
>
>
>
}
}
}
}
CLUSTER[at0013] occurrences ∈ {0..*} ∈
{ -- Venous
items cardinality ∈ {0..1; ordered}
∈ {
ELEMENT[at0016] occurrences ∈
{0..1} ∈ { -- PvO2
value ∈ {
C_QUANTITY <
property =
<"pressure">
list = <
["1"] = <
units =
<"kPa">
magnitude =
<|0.0..1000.0|>
>
>
>
}
}
ELEMENT[at0017] occurrences ∈
{0..1} ∈ { -- PvCO2
value ∈ {
C_QUANTITY <
property =
<"pressure">
list = <
["1"] = <
units =
<"kPa">
magnitude =
<|0.0..1000.0|>
>
>
>
}
}
ELEMENT[at0014] occurrences ∈
{0..1} ∈ { -- Site
value ∈ {
CODED_TEXT ∈ {
code ∈ {[ac0003]}
-- Any term that 'is_a' vein or cavity
}
}
}
use_node ELEMENT
/[at0000]/data[at0002]/events[at0003]/data[at0001]/items[at0011]/items[at000
6]/
}
}
}
}
}
}
}
}
}
state ∈ {
LIST[at0009] ∈ { -- state structure
items cardinality ∈ {0..1; ordered} ∈ {
ELEMENT[at0010] occurrences ∈ {0..1} ∈ { -- FiO2
value ∈ {
C_QUANTITY <
property = <"qualified real">
list = <
["1"] = <
units = <"">
magnitude = <|0.0..1.0|>
>
>
>
}
}
}
}
}
}
ontology
primary_language = <"en">
languages_available = <"en", "de">
term_definitions = <
... [truncated, below this are English and German versions of ontology
(where is the Tamil?)]
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
|
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
