[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[COAS-List] Re: Questions about COAS



Jean-François,

I am copying this to the other COAS submitters/contributors too.  See
comments below.

Tim


Jean-François Declercq wrote:
> 
> Hello,
> 
> I'm currently working on a prototype made of components inspired by the PIDS, the COAS and XML.
> 
> I am now facing a problem I cannot find an issue in the COAS. In the world of Clinical observations , there are the measurements. But sometimes these measurements are tidly grouped in what we call here "a group".
> Example of group is a Glycemia.  You have to take several measurements every 5 minutes. These 5 measurements are, I think, a unique observation.
> How can the COAS cope with that ?

There are two answers to your question.  The first is that the IDL
presented in the COAS RFP response was taken from an existing system
(for vital signs) and we have not determined the actual IDL we expect
COAS to have.  Grouping was not done on that system except grouping by
time.

The second answer is that I reallize this is important but the COAS
submitters have not come up with a solution yet.  HL7 has the concept of
groups but each vendor can interpret what to group together.  This
leaves a whole in the interoperability.  The COAS submitters/supporters
are meeting a couple times in the next few weeks where I hope we will
have some answers for things like this.  We are looking at many modeling
efforts for observations that should help in this area.


> I mean, it should be able to answer "Give me all Glycemia for this patient"

Yes, COAS definitely needs to be able to answer queries like that.  Of
course there might be other (optional) qualifiers too such as "during
this encounter" or "within the last five years", etc.


> Is the answer in the LQS ?

We are still wrestling with how the LQS should be used.  On the one hand
a client may want to specify a general observation type and have the
server convert (expand) that to any subtypes of that type.  This could
be done via an LQS on the server side.  Can we require that all servers
do some kind of expansion like this?  How can a server expose to a
client what kinds of expansions it can do?  Is there a simple way to do
that?

Alternatively the client could ask for each subtype individually.  One
problem here is that a general type could correspond to hundreds or
thousands of subtypes which would be excessive to be passed into the
server.


> An other question: in the ObservationData::Measurement structure, there are no reference values.  Is it done on purpose.

We (Protocol Systems, the developer of the IDL) did think about that a
little but never got a conclusive definition of reference values.  For
vital signs measuring equipment a reference value might be the measuring
range (which varies from device to device).  Vital signs monitors also
have a user settable alarm limit range.  Then there is the general
physiological range for the measurement (which may depend on the age of
the patient or the condition they have).

Is this what you meant by reference values?


Thanx for your comments.  I would like to understand your questions a
little more as measurements are the life blood of Protocol's work with
observations.  I want to make sure what we come up with for measurements
in COAS work for lab values, I/Os, etc. too.  Please provide input.


Regards,

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