Re: [COAS-List] SGML Thread on Report Types

[Tim Brinson <tim@protocol.com>]

Wayne Wilson wrote:
> BUT, one movement afoot is to provide each report with structure, ala a
> DTD.  Then one can standardize on DTD's (or not!).  Another approach
> with XML is based on HyTime where any number of reports can be
> dynamically defined according to a standardized meta-structure
> represented by a DTD! (this is the architecture Rachel refers to in her
> discussion with Wes.)  In fact, I would submit this a crux of the
> discussion thread:  should we exhaustively enumerate and standardize
> DTD's for all medical reports or should we standardize on a mechanism
> allowing us to dynamically create and define and use any number of
> reports (and their labels)?

I have seen Rachael present on Kona a number of times (but some time
ago).  I never understood the "architecture" thing except that it is
suppose to provide the ability to transform content between documents
with different formats/structure (i.e. DTDs).  Now that I can read DTDs
I need to revisit it.  One of the things I'm missing is how SGML
architectures are suppose to work operationally.  I understand how
normal DTDs are suppose to work with XML but is seems these
architectural DTDs are more meta information and I don't know when they
come into play (e.g. compile time, run time, rendering time, document
creation time, only when a translation between known DTD are needed, or
what ever).


>   Another issue here is that if reports have structure, treating them as
> a single thing from COAS's perspective will be the logical equivalent of
> BLOB's in RDBMS's, not very useful at the end of the day. So you need a
> generic mechanism to represent parts and then structure.

My sense is that COAS does not need to treat them as BLOBs.  COAS it's
self has a structuring mechanism.  I believe a COAS Observation is
sematically similar (but not quite identical) to an XML Element.  

 - The observationType in COAS is semantically equivalent to the an XML
Element Name.  

 - An Observation may contain other Observations OR it can contain a
SINGLE ObservationValue.  This is similar to how an Element can contain
other Elements AND it can contain MULTIPLE CDATA.  The structuring
capabilities of XML is a superset of COAS.  Under various contexts I
have brought up the issue whether the COAS model needed the extra
generality of structuring and every time people have indicated no.

 - The ObservationQualifier is semantically identical to an XML
Attribute (e.g. they are name/value pairs that qualify the main
Observation/Element).  

- An Element or CDATA instance is contained by exactly one other Element
(unless the Element is the root Element of the document).  An
Observation or ObservationValue is contained by exactly one other
Observation (unless the Observation is a root Observation).


> > Another part of the thread that was interesting was the discussion on
> > headings/catagories.  It sounds like a patient record may have things
> > like lists of alergies, history, problems, etc.
> >
> >         One question I pose to ALL of us - are these Observations?
> >
> This point and the discussion which followed it highlight the issue of
> what structure a medical record for a person would take.  One answer, is
> that a medical record will contain whatever the care providers and
> administrative folks want to put in it and store as a legal document.
> This will most likely be quite open ended.

I figure the documents in an EMR could be one of the sources a COAS
server uses to find the data being queried for by a COAS client.


>  A quite different discussion ensues when one wishes to present
> clinically useful information in the context of patient care at a point
> in time.  This is almost always a sub-set of what constitutes a medical
> record and in many cases is not a proper sub-set at all because it
> includes things like preliminary lab results and unsigned/unedited
> dictation.  While there is certain commonality across all care
> providers, the constant theme that arises is customization of this
> presentation to the care task of the provider.

Of course COAS does not do the presentation (rendering) but it is a
mechanism that can be used to access clinically relevant information a
provider needs at the point of care.


>   It had been my understanding that COAS attempted to provide a
> universal access mechanism to satisfy this latter scenario.

I believe it does too. 


Tim
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