[COAS-List] Questions about COAS specification

[David Foard <dhf@alpha.sunquest.com>]

Sunquest has a project developing a result query service to
access Sunquest products for results. The lead developer has
reviewed the COAS specification and has some questions.
Please review and respond as appropriate. We plan to use these
questions and the response to received to produce and maintain
an FAQ. The file is attached as a text file. Thanks!

Dave
dhf@alpha.sunquest.com
Comments for the review of the Clinical Observations Access Server (COAS) Draft 5 document dated 1 Sept 1998.
David Geis
9/15/98

The data objects and service interfaces described in this document seem like a good start.  However, several issues should be addressed before we can consider basing our middle-tier services for GUI IQ on these definitions.  My initial concerns are outlined below in no particular order.  I didn't really go over the Publish and Subscribe interfaces in any detail because I didn't see an immediate need for them yet.


1.  Clinical context is not included in this model.
The management of clinical context information (orders, encounters, etc.) is not considered to be in the domain of the COAS server, yet clinical laboratory results are included in the definition of observations.  This context information is very important to the display of the observation for full identification, presentation grouping, and navigation to linked observations.  If only the observation values come from the COAS server, there must be another server somewhere to provide the context information.  How much duplication of effort would be required to retrieve the complete clinical picture from the different servers?


2.  Valued versus non-valued observations.
What is the difference between PatientAccess.get_clinical_items_by_time() and ...get_available_clinical_items() if it is beyond the scope of COAS to manage clinical context information?  Both methods return BaseItemSeq.  Is the observation context information only the BaseItem level members?  That is, does get_clinical_items_by_time return a set of BaseItem derived objects (BranchItems and LeafItems) and does get_available_clinical_items return a set of BaseItem objects (no 'DataElement the_value' or 'BaseItemSeq member_items' members)?

In order to use the PatientAccess.get_clinical_item() method, the caller must have an OID.  Presumably, this comes from a previous call to PatientAccess.get_available_clinical_items().  What is the difference between the BaseItem object returned by get_available_clinical_items() and the BaseItem object returned by get_clinical_item?  Is it simply the derivation down to BranchItem or LeafItem and the additional data member or are additional context values returned as well?


3.  Unbounded query supported?
Is the concept of an unbounded or empty TimeSpan supported?  How would one designate a request for all observations later than a given date, all earlier than a given date, or simply, all observations?  Must one dummy up some arbitrary far-distant date?

Is the concept of an empty QualifiedCodeSeq supported so that the 'what' parameter of the queries can be unbounded?


4.  Objects are not fully defined by their interfaces.
Use of the NVPair implies a known vocabulary of context names that must remain synchronized between the COAS server and the client in the BaseItem.shared_context.the_context and BaseItem.other_context observation data members, and the ContextSeq parameter in PatientAccess.get_clinical_item_by_context() calls.  This technique was implemented in Intellicare as the VENamedAttrSet model and was subsequently shot-down for use in COM because there is not a real contract between the server and the client for what the object is. (See Vince and Dave T.'s critique of the Patient Finder Service component.)  Is this technique more prevalent or acceptable in CORBA?  What would determine that a particular piece of context information would be managed in the shared_context rather than in the other_context.


5.  Get _by_policy not defined.
PatientAccess.get_clinical_item_by_policy() - It is unclear how the activity described in Chapter 7 (Appendix - Usage Patterns) is represented in the NVPairSeq that is supposed to contain the set of policies.


6.  Observation or result modeled as a time span, not a single moment in time.
The model assumes that an observation is for a time span rather than for a unique moment in time.  Is this the usual case for observations?  All clinical results that I have seen are associated with the specimen collection time-a single moment in time.  It seems like a lot of overhead to have to compare begin_time and end_time values to ensure a single event time when organizing the data by date (a common presentation sequence)


7.  QualifiedCode value is severely overloaded.
The OID (object ID) uses a TerminologyServices::QualifiedCode  value for the code.  It appears that the QualifiedCode can represent any of the following things:

* An object type (OID.code).  Does the code indicate that the object is an order, or result, or test/procedure?  The key is used to define which order, result, or test in an implementation-specific manner (e.g., an ORDX, or a test code like NA or GLUC, or some combination like ORDX\AN\BT\TC).  Is that a correct understanding of how this should work for the OID?
* A relationship type (ItemRelation.relationship).  Perhaps there is a code that equates to 'contains' or 'is the primary item for the associated secondary items'?
* A concept code (BaseItem.name, DataElement.name).  This seems equivalent to a lab procedure code like GLUC or an observation like Temperature.  How does this relate to the QualifiedCode which is part of the OID in BaseItem.oid?  How are the concept codes related between the derived class LeafItem and its public DataElement the_value member?  That is, what is the difference between LeafItem.the_value.name, LeafItem.name, and LeafItem.oid.code?
* A observation value modification code (BaseItem.modifiers).  Does mean codes for things like 'Preliminary', or include QA flags like 'above normal'?
* A code for Units of Measure (typedef TerminologyServices::QualifiedCode Units;)  Is there support for equivalence of terms (i.e., mg/ml is equivalent to grams per liter)?
* A clinical observation code used in query criteria (PatientAccess.get_clinical_items_by_time(), et.al.  Is this the same as a concept code

What are the rules for defining these code values?  Are standard codes defined across the industry?  Do users (sites) have the ability to define unique codes for themselves?  What prevents collisions of QualifiedCode values in different domains (e.g., object type versus relationship versus concept code versus units code)?

What is the representation of a QualifiedCode?  Is it an enumerated value, abbreviated character string, or full descriptive text?  What mechanism converts the code to a user-friendly term for presentation?


8.  Non-patient centric query supported?
It is not clear how a query that is not based on a known patient would be supported.  Many of the FlexiLab functions support a query based on system identifier that is not directly associated with a patient (e.g., lab accesion number, AP case number, requisition number).  How would this type of query be supported?


9.  Time format.
Does the OMG intend to wrap the TimeT, TimeStamp, TimeSpan, TimeDelta structures with classes that provide user-friendly formatting or will it be up to each implementation to deal with yet another date/time representation?  Of course, this spec must be written for cross-platform implementation, but consider how Microsoft provides the COleDateTime and COleTimeSpan classes for the DATE representation to extract the calendar year, month, day values or the length of a time span in days, hours, minutes, seconds.  Will something like that be provided or defined?


C:\TEMP\COAS 5 Review.doc		9/15/98 11:40 AM

		Page 3 of 3