[COAS-List] Blob related scenarios for COAS

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

Fellow COAS Submitters,

Karen here raises a bunch of largely client side issues, but one theme
comes up which is recurrent in lots of like messages that we get.  Most
people, both inside and outside of CORBAmed, seem to think that COAS is
going to solve all problems for all healthcare clinical data domains.  I
think that we realize that this is not possible.  The aim is to define the
COMMON services that create a FRAMEWORK under which deparmental data types
can be added under separate RFPs (e.g. CIAS).  If you agree (I think we all
agreed -- at one time, at least) then we need to re-educate the world about
this, somehow.  Any ideas?

>Return-Path: <owner-coas@cs.fiu.edu>
>From: kdolan@lhs.com
>X-Lotus-FromDomain: LHS
>To: coas@cs.fiu.edu
>Date: Mon, 13 Jul 1998 22:14:54 -0400
>Subject: [COAS-List] Blob related scenarios for COAS
>Content-Disposition: inline
>Sender: owner-coas@cs.fiu.edu
>
>COAS group,
>
>I have not been paying as close attention to the COAS work as I'd like,
>but, I jotted down a couple of scenarios which our company has battled at
>various levels, which may be able take advantage of a COAS interface.
>Basically, my thoughts centered around being able to do more with an object
>than just what is described in the interface. Some of the complexity of
>interpreting the data would be located outside of the interface, on both
>the client and server sides. This "post-processing" would still require
>some level of mutual understanding between the client and server
>applications.  I don't have enough experience with the OMG to know if this
>goes directly against the goals of the IDL. If, by implying that the client
>will perform interpretative processing on object data, it means the object
>is not really encapsulated.
>
>Anyway, here they are...
>
>1)  A care giver has patient identifying information, such as a name,
>social security number, age, gender, photo ID, etc. The care giver wants to
>locate a patient's current medication, allergies, chronic problems, lab
>tests, etc. The care giver uses patient identifying information to locate
>the desired lists. Once the list is located, the user is able to view the
>lists in some user friendly soft of way (web browser, green screen columns,
>etc). Hopefully, the viewing application will be granted the ability to
>distinguish between discrete items within these list, such as
>differentiating the prescribed medication's name from the medication's
>frequency and duration, thereby helping the application display information
>more logically to the user.
>
>The client application is able to function appropriately with a variety of
>exposed formats. Examples of possible exposed list formats may include a
>collection of discrete measurements, unstructured strings, structured
>string (marked up in a standard way such as HTML, XML, or SGML), etc.
>
>2) A specialized application has the sole duty of enabling a user to create
>complex structured (clinical) reports. These reports may include embedded
>links to external sources of electronic and non-electronic data (images,
>tissue samples, etc). The structure and complexity of the report vary from
>report to report. The representation of the values within a report and
>their relationship to each other, must remain constant, they may only be
>altered explicitly by the user.
>
>Despite the potential complexity of a report, the primary purpose of the
>report is to be utilized by other clinical information systems which
>perform other specialities. For example, a report creating application may
>cooperate with a clinical information management system that specializes in
>document archiving and manages access to reports and information within
>reports. This archiving system may not have the ability, or desire, to use
>all of the structure within the report, but is able to expose the report to
>other applications (such as a data mining type of application) which can.
>
>The report is to be communicated between the creating application and the
>managing application without having to either raise the awareness of the
>client application up to the level where it understands all of the
>complexity of the report, or, collapse the complexity out of the report
>down to the level where the client can understand all of it.  (Applies to
>the interface supporting this communication).
>
>-Karen Dolan
>
>
>
>
_____________________________________
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