Re: [COAS-List] Re: Questions about COAS

[Bob Glicksman <bobg@medgrid.philips.com>]

Another answer:

COAS was NEVER intended to address every issue in every type of clinical
observation.  If you think Labs are a challenge, try radiological imaging
or, better yet, pathology.

COAS was intended to provide a FRAMEWORK to answer GENERAL questions about
observations -- who has them, what are they, what types of data do they
contain, how can I access them, how can I know when the status changes,
etc?  The OMG's AB apparently does not like frameworks, so they required
that the RFP contain (at least) one concrete type.  Our submitter team
opted for vital signs since our partner, Protocol Systems, had already done
a lot of work in this area.  

CORBAmed's intent is to issue additional RFPs regarding other observational
data types. The CIAS RFP was issued in Orlando; for access to
non-diagnostic quality images.  A working group is working on transcribed
report access -- an RFP is expected soon.  The message here is htat if you
are interested in standardizing access to lab information (and I certainly
think this is important), please help us to get an RFP together which
requests such a standard.  The RFP should ask the questions that you are
asking here -- so that submitters can respond appropriately.

Your questions are GREAT ONES, but please help by working through the
process.  Since it is too late for you to form your own submitter team with
interest and expertise in the Labs area, I suggest that you work to get an
RFP through CORBAmed for this.  I don't think the process will be too long
or difficult, based on work in related domains to date.  Then there will be
a vehicle for submitters to get together and answer these rather
interesting questions.  However, I would not want to hold up the current
COAS effort for this -- or there will never be a COAS (the reason we split
things up this way in the first place).


At 12:08 PM 7/13/98 -0700, Tim Brinson wrote:
>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
>Attachment Converted: "c:\eudora\attach\vcard10.vcf"
>
_____________________________________
Bob Glicksman  
Director, MedGRiD Program 
Integrated Clinical Solutions
                   
bobg@medgrid.philips.com              Philips Medical Systems   
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736