[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COAS-List] Last Week's Meeting - modelling
some comment about the model and the definitions.
Angelo
At 14.11 21/12/98 -0800, Tim Brinson wrote:
...
>We crafted (word-smithed) a definition for ObservationTime - "Denotes
>the time when the Observation reflects a characteristic of the
>ObservedSubject."
a generic "observation time" and a generic "recording time"
seem to me very risky.
why not a compound attribute, eg.
("kind-of-time", "time value")
or something like:
("kind-of-event", "time")
for a clinical event, eg. sampling
("kind-of-documenting", "time")
for a documenting event, eg. recording
>We also found a pretty good definition of ObservationValue (stolen from
>a description in COSMOS) - "The manifestation of forms of biological
>phenomena."
hummm...
1. "observation" has at least two meanings:
- statement regarding a patient (including status of activities)
- result of physical examination (and perhaps history taking)
this is not clear in the proposal.
And it is not clear if it is only the result of experience or if it also includes:
- expected value without intervention
- goal of intervention
- setting on a device
- risk for a condition
2. still remaining in the realm of assessment
(i.e. without including activities),
there are also non-biological phenomena,
e.g. occupational, travel, social phenomena and environment
related to the subject of care.
3. it is not clear in the model that the subject of care
may be different from the observed entity
(e.g. a relative, the environment).
4. "observation type" at page 7 of the proposal seems to refer
to the value type.
Observation value in the model seems to be the result.
I was not able to find the name of the observation.
The definition above could apply to a particular case of
"name of observation".
"observation value" in the model seems to refer to the results
(e.g. the numeric value of a laboratory test)
I think that a list of examples will help a lot in clarifying.
>I believe Tom is removing the Observer and RecordedTime from the model.
I suggest to add the kind of observer and the kind of documenting event.
>Part of the context information that could be stored with an observation
>would be a set of Role/Time pairs.
Perhaps the above sentence is a different phrase for
my suggestion ?
>ISSUE - Should we add an Action/Event subtype of ObservationValue? It
>would hold things like a timestamp, an action type (QualifiedCode) and a
>performer (ID).
as above.
>Another issue discussed last week was that of a special root observation
>or transaction (ala GEHR). Tom Culpepper and I discussed this and have
>added a new object in the Information Model called "HealthRecordEntry"
>that holds information like RecordedTime, AuthorizingCliniction,
>Originator, etc. We have determined that it will not show up in the
>Service Model since that would hard code in the API a particular
>structure of (assumption about) the health record. The
>HealthRecordEntry would be supported in the Service Model as a special
>ObservationType and would be given a QualifiedCode to represent it.
>This brings up the following issue:
>
>ISSUE - What things in the Information Model should show up directly in
>the Service Model API and which should show up as special
>ObservationType codes? Alternatively, what extra information should the
>Information Model contain outside what is given explicit support in the
>Service Model API? Are there rules to go by?
>
>Please help address this issue. I have conflicting feeelings myself.
>It would be good to get other people's insights.
the issue is not clear to me.
An interpretation could be:
the record-keeping information will be embedded in a particular entry,
that is available on request as an independent entry.
Is it correct ?
>One of the items we spent a lot of time on was analyzing the
>ObservationQualifiers. After creating a list of the things these might
>be used for it was obviously a grasscatcher (aka hodge podge :-). Here
>are the examples from our first level analysis:
...
(please look at PT27 for a similar approach, at
http://www.centc251.org/WItems/PT/27/PT27FWD23c.PDF )
>The suggestion is to support the qualifiers as special ObservationTypes
>instead as hard coded attributes of an Observation. One characteristic
>of these does make them different then the other ObservationTypes - they
>don't make sense instantiated by themself - they
>modify/characterise/qualify other observations.
why the present ObservationQualifier is inadequate ?
>While it was discussed removing them from the Information Model it is
>more important they are not hard coded in the Service Model. This
>brings up the following issues:
>
>ISSUE - Should ObservationQualifiers be shown explicitly in the
>Information Model or not? They will not be supported directly in the
>Service Model API but could be supported as special ObservationTypes
I see different types of qualifiers:
- details as body part or laterality
- status concepts as family history of "risk for",
- other circumstances
that can be well characterized.
The COAS proposal is not obliged to be aware of the actual codes,
but codes provided by external organizations can obey to simple rules,
e.g. the above subdivision.
>
>ISSUE - How should these qualifiers be indicated? With just the generic
>term "ObservationQualifier" or more specificly as "ObservationStatus",
>"ObservationTypeModifier", "ObservationValueModifier",
>"ObservationContext", etc.? This is independent on whether they show up
>explicitly as attributes or implicitly as codes.
I see different, well-specified kinds of qualifiers.
---------------------------------
Angelo Rossi Mori, Reparto Informatica Medica,
Istituto Tecnologie Biomediche, CNR
viale Marx 15, I-00137, Roma, Italy
http://gift.irmkant.rm.cnr.it/termhome.htm
NOTE NEW NUMBERING SYSTEM IN ITALY:
tel. + 39 - 06 827 71 01; fax + 39 - 06 827 36 65