blood film observation archetype
Dear Colleague, Archetypes are clinical concept models. They communicate and express domain information models about clinical concepts. Archetypes are ways to express clinical knowledge on what has to be recorded documenting the provision of healthcare. Archetypes (at this moment) are not designed to deal with clinical knowledge about the interpretation of documented clinical facts. Decision support. Fields in archetypes that are specified are containers to be used for documentation. One type of the family of archetypes is the Observation. One of the possible observations is the Lab-test. For each lab-test the following things will have to be (can be) recorded about the test itself and its results: - name of the test - value/outcome/result - units of measurement - normal values - interpretation - comment -relevance- Each healthcare provider that is using this archetype will be able to record the indicated information about any lab-test. The name of the test plus units of measurement are linked to each other. Result is the number that is the result of a measurement that is recorded and can vary. Normal values are dependent on local circumstances. Each lab has its own normal values for all of the tests they perform. The interpretation of the test result and its normal values are dependent on local arrangements, clinical speciality, and patient related contexts. The comment is additional information that has to be recorded about the test. Thinking about it I foresee the need for a flag indicating that this lab test result is considered relevant or irrelevant by the Observer. The reason for this is: Suppose all fields are filled but the comment field states that the blood was not collected properly. Then all data that is recorded is interpreted as less relevant/reliable but can not (must not) be disregarded fully. Perhaps all Archetypes of the Observation Type need this extra field I call Relevance. To answer your e-mail. I think that the normal value and the interpretation are NOT part of the archetype definition. Within the archetype specification one can not deal with all situations that influence the normal values dependent on local contexts that vary from point in time to point in time, from place to place and from context to context. Normal values have to be provided by the lab. The interpretation has to be provided by the Observer (e.g. the lab or the physician). Or in the case of Clinical decision Support the module that handles this type of clinical knowledge. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 25-okt-2006, at 0:27, Rodrigo Filgueira wrote: We've been running throuh the normal and possible ranges of values for lab tests and found that the archetype I mention in the subject does not state but a bigger than 0 restriction for Haemoglobin, RCC, etc. I decided to take a look because ranges provided to me indicated diferent possible ranges for male and female patients and was wondering how would archetypes model this issue. This is a very similar question to another one I did some time ago regarding normal, abnormal, dangerous, etc. ranges. But in this case my question refers to the possible values the test may return. In order to differentiate male from female ranges assertions would need to be introduced? Or do you believe this is too a matter of decission support? thank you. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/d4aeb5ab/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
blood film observation archetype
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/ced2740d/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Updated Architectural overview
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/6e6c7e6a/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/e09599a4/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Updated Architectural overview
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/5781bae1/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
This is not sensible to have in an archetype - otherwise it would not be
there! It is a requirement for templates in use.
I don't understand why it is not sensible to have in an archetype?
Couldn't it be useful to say that for this particular observation
we want to explicitly disallow the recording in of state information?
OBSERVATION matches {
state existence matches {0} matches {*}
}
Would be an observation that has 'data' but is not
allowed to contain 'state' information.
what about a DV_MULTIMEDIA value where a thumbnail
makes no sense so we want to explicitly stop people
from storing data there
DV_MULTIMEDIA matches {
media_type matches { audio/wav }
thumbnail existence matches {0} matches {*}
}
I can accept that there may not be any clinical situations where
this has been encountered and therefore there are no obvious
use cases for it - but I don't see why its not sensible
to be able to state an attribute is not merely optional, but in
this archetype is disallowed.
If it is indeed not sensible, then the existence grammar in
ADL can be simplified - currently 0 is allowed - it really should
just be 0..1 (default) or 1 as the allowable existence ranges.
(which could all be simplified to a simple 'mandatory' keyword
and the whole existence bit could be removed!).
OBSERVATION matches {
data matches { ... }
state mandatory matches { ... }
}
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
How about specialised archetypes? Wouldn't there be occasions when a
parent archetype has some attribute, which a child (specialisation) of
that archetype don't want to deal with?
Mattias
2006/10/25, Sam Heard sam.heard at oceaninformatics.biz:
This is not sensible to have in an archetype - otherwise it would not be
there! It is a requirement for templates in use.
Sam
Thomas Beale wrote:
Andrew Patterson wrote:
For the case where an attribute is constrained to '0'
existence i.e.
state existence matches {0} .
what should follow as the rest of the attribute
constraint? Technically, the rest of the definition
is superfluous as we have already stated that the
attribute must not exist, but the
'matches' clause needs to exist in the grammar. Should
it be matched to *, or should it be empty?
state existence matches {0} matches {*}
or
state existence matches {0} matches {}
(I'm not sure the grammar allows this)
we certainly have not allowed for it yet; indeed, no-one has ever wanted
to do it in an archetype, it has only come up as a need in templates
(which simply quote path names and then add an existence constraint).
Possible responses that come to mind:
- in openEHR we try never to include a feature that is not justified by
at least one known use case. So we should try to find a real use case
before doing anything.
- there is in fact already a way to do this: by adding an invariant to
an archetype of the form
not exists (/path/to/some/attribute/that/we/dont/want)
- if we had to add more syntax to the cADL part of ADL, I would probably
opt for the second proposal above.
Buta credible use case needs to be found first.
- thomas beale
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr. Sam Heard
MBBS, FRACGP, MRCGP, DRCOG, FACHI
CEO and Clinical Director
Ocean Informatics Pty. Ltd.
Adjunct Professor, Health Informatics, Central Queensland University
Senior Visiting Research Fellow, CHIME, University College London
Chair, Standards Australia, EHR Working Group (IT14-9-2)
Ph: +61 (0)4 1783 8808
Fx: +61 (0)8 8948 0215
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
Hi Andrew
I think that the right place to say for this usage of this archetype I want
to explicitly exclude something is in the template. The archetype should
be a representation of a concept that can be used for all conceivable
requirements of that concept and then constrained in the template.
Regards Hugh
__
Dr Hugh Leslie
MBBS, Dip. Obs. RACOG, FRACGP, FACHI
Director and Senior Clinical Consultant
Ocean Informatics Pty Ltd
M: 0404 033 767 E: hugh.leslie at oceaninformatics.biz Skype: hughleslie
-Original Message-
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
Andrew Patterson
Sent: Wednesday, 25 October 2006 4:24 PM
To: For openEHR technical discussions
Subject: Re: a zero existence constraint
This is not sensible to have in an archetype - otherwise it
would not
be there! It is a requirement for templates in use.
I don't understand why it is not sensible to have in an archetype?
Couldn't it be useful to say that for this particular
observation we want to explicitly disallow the recording in
of state information?
OBSERVATION matches {
state existence matches {0} matches {*} }
Would be an observation that has 'data' but is not allowed to
contain 'state' information.
what about a DV_MULTIMEDIA value where a thumbnail makes no
sense so we want to explicitly stop people from storing data there
DV_MULTIMEDIA matches {
media_type matches { audio/wav }
thumbnail existence matches {0} matches {*} }
I can accept that there may not be any clinical situations
where this has been encountered and therefore there are no
obvious use cases for it - but I don't see why its not
sensible to be able to state an attribute is not merely
optional, but in this archetype is disallowed.
If it is indeed not sensible, then the existence grammar in
ADL can be simplified - currently 0 is allowed - it really
should just be 0..1 (default) or 1 as the allowable existence ranges.
(which could all be simplified to a simple 'mandatory'
keyword and the whole existence bit could be removed!).
OBSERVATION matches {
data matches { ... }
state mandatory matches { ... }
}
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
I think that the right place to say for this usage of this archetype I want
to explicitly exclude something is in the template. The archetype should
be a representation of a concept that can be used for all conceivable
requirements of that concept and then constrained in the template.
I haven't seen any template specification, hence I tend to think
of things in terms of how I would do them in an archetype.
Personally, I think there will be cases where the very existence
of an attribute makes no sense in any conceivable requirement
of that concept - or needs to be explicitly denied to prevent misuse
of the archetype.. just looking briefly at the OBSERVATION
RM, it has comments saying that 'state' data should be
stored either per event, or per observation - but not both. Surely
the choice of which strategy is being used would be made by
constraining out the existence of the 'other' state attribute?
If zero existence constraints are not to be used in archetypes then
the section dealing with them in ADL should be updated.
In particular, page 48
Existence is shown using the same constraint language as the rest of
the archetype definition. Existence constraints can take the values
{0}, {0..0}, {0..1}, {1}, or {1..1}. The first two of these constraints
may not seem initially obvious, but may be reasonable in
some cases: they say that an attribute must not be present
in the particular situation modelled by the archetype. The default existence
constraint, if none is shown, is {1..1}.
On a related note, whilst I understand the general concept of
a template in openehr I am yet to see any spec of what
they look like.. are there any specs out there?
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Template definition
Hi Andrew
Ocean has a quite sophisticated template designer which is still in Beta,
but which currently allows you to build templates from multiple archetypes
and then constrain nodes further. It also allows you to drag and drop nodes
onto a form designer where they become the appropriate windows controls and
also to map templates to other data. The form designer allows you to
produce code and to compile and build executables.
Currently the templates are serialized as xml by this tool, however openEHR
is working on the release of a TDL which is based on ADL. Not sure when
this will be available.
Regards Hugh
__
Dr Hugh Leslie
MBBS, Dip. Obs. RACOG, FRACGP, FACHI
Director and Senior Clinical Consultant
Ocean Informatics Pty Ltd
M: 0404 033 767 E: hugh.leslie at oceaninformatics.biz Skype: hughleslie
-Original Message-
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
Andrew Patterson
Sent: Wednesday, 25 October 2006 6:55 PM
To: For openEHR technical discussions
Subject: Re: a zero existence constraint
I think that the right place to say for this usage of this
archetype
I want to explicitly exclude something is in the template. The
archetype should be a representation of a concept that can
be used for
all conceivable requirements of that concept and then
constrained in the template.
I haven't seen any template specification, hence I tend to
think of things in terms of how I would do them in an archetype.
Personally, I think there will be cases where the very
existence of an attribute makes no sense in any conceivable
requirement of that concept - or needs to be explicitly
denied to prevent misuse of the archetype.. just looking
briefly at the OBSERVATION RM, it has comments saying that
'state' data should be stored either per event, or per
observation - but not both. Surely the choice of which
strategy is being used would be made by constraining out the
existence of the 'other' state attribute?
If zero existence constraints are not to be used in
archetypes then the section dealing with them in ADL should
be updated.
In particular, page 48
Existence is shown using the same constraint language as the
rest of the archetype definition. Existence constraints can
take the values {0}, {0..0}, {0..1}, {1}, or {1..1}. The
first two of these constraints may not seem initially
obvious, but may be reasonable in some cases: they say that
an attribute must not be present in the particular situation
modelled by the archetype. The default existence constraint,
if none is shown, is {1..1}.
On a related note, whilst I understand the general concept of
a template in openehr I am yet to see any spec of what they
look like.. are there any specs out there?
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
On 10/25/06, Andrew Patterson andrewpatto at gmail.com wrote:
I should also note that after I had posted my initial query
about existence constraints last month I found a section in the ADL spec
that actually deals with this
section 4.3.5 Any constraints
however, it also provides an opportunity to specify an existence
constraint
which might be narrower than that in the information model.
So my interpretation would be that the correct syntax
for a zero existence constraint would be therefore
attribute existence matches {0} matches {*}
Hi Andrew
It's valid only if the attribute is optional in the containing class from
the reference model.
/ Rong
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/a202d66e/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
