[COAS-List] Last Week's Meeting

[Tim Brinson <tim@protocol.com>]

Hello Gang,


At last week's COAS meeting we covered many topics.  Thank you to those
that attended the meetings for helping address the issues.  In addition
to the two day meeting Tom and I met with Stan Huff and Harold Solbrig
to discuss the HL7 Template work and harmonization between CORBAmed and
HL7.  We ended up spending most of the time discussing COAS related
issues since they were fresh in our minds.  While resolutions will show
up in the specification I thought I would mention some of the more
important points and bring up a couple more issues.  In another message
I plan to start a thread on one of the major issues that came up but has
not been resolved (use of DOM).

We crafted (word-smithed) a definition for ObservationTime - "Denotes
the time when the Observation reflects a characteristic of the
ObservedSubject."

We also found a pretty good definition of ObservationValue (stolen from
a description in COSMOS) - "The manifestation of forms of biological
phenomena."

We discussed the RecordedTime and the Observer role attributes of an
Observation.  We realize there are multiple times and roles that can be
associated with an observation.  For example:

	Times:

            dictation
            transcribed
            sign-off
            attestation
            recorded
            observation
            onset
            procedure
            projection
            consultation
            specimen drawn
            lab processing times
            verification
            QA review
            collection
            results become available

      Roles:

            originator
            collector
            legal authenticator
            technician/tester
            treater
            transcriptionist
            auditors
            observer
            observed subject


I believe Tom is removing the Observer and RecordedTime from the model. 
Part of the context information that could be stored with an observation
would be a set of Role/Time pairs.

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).


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.


At the meeting we mentioned combining the AsynchAccess capability and
the Consumer/SupplierFactory.  We did not discuss it a lot but no
negative comments were made about it so I will attempt to do so.  I have
already done the analysis and it appears the same functionality can
easily be supported.  On a related note we discussed whether we should
subclass from the Event Service consumer/supplier types instead of the
Notification Service types.  There was no resolution that I recall so I
will investigate it more.


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:

      Observation Type Modifier:

            Body site [where observed]
            Subject/Objective
            projection [in time]
            hypothesis

      Observation Instance Status:

            outside alarm limits [high/low]
            outside mesurement range [high/low]
            critical alarm [high/low]
            completion status
            QA status
            prelim/final status
            Normalcy
            Confidence
            report status
            active/inactive/remission
            rejected/current

      Observation Context:

            Source system
            Patient record categories
            Facility/Location [where]
            Equipment used
            Algorithm/Formula used [Source data]
            Protocol/Procedure/Method
            Order#/Requisition#
            Encounter#
            EncounterType
            Verifier
            Episode of care
            Accession#
            Specimen#
            AP case# (assessment plan case#)
            Health record transaction

      Observation Value/Type:

            allergen
            reaction
            prognosis
            diagnosis
            treatment related
              - pharmacy
              - expiration date
              - refills
              - dose/give rate
              - intervention type/time

      Don't know:

            How it was collected
            Comments
            Coded comments
            normal value
            normal range
            Version
            Recorded Time/attestation time
            Observer
            rule out
            Severity
            persistence/recurrance
            onset (time?)
            procedure time
            trans

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.  

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

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.


In another message I will discuss the use of DOM (Document Object Model)
by COAS.


Regards,

Tim Brinson
begin:vcard 
n:Brinson;Tim
x-mozilla-html:TRUE
org:Protocol Systems, Inc.
adr:;;8500 SW Creekside Place;Beaverton;Oregon;97008-7107;USA
version:2.1
email;internet:tim@protocol.com
title:Systems Software Lead
tel;fax:503 526 4200
tel;work:503 526 4392
note:<img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt:;0
fn:Tim Brinson
end:vcard