Re: [COAS-List] COAS - Various

[Tim Brinson <tim@protocol.com>]

Richard and all,


Thanks for the insights and the information about the EHCR-SupA
project.  I recall hearing you mention this in Orlando but it didn't
sink in.  See a couple replies to your comments below.


> The requirements, use case scenarios and models are/will be drawn from GEHR,
> CEN, SYNAPSES, I4C, STAR, RICHE, NUCLEUS and many other projects and bodies
> (also taking into account things coming out of e.g CORBAmed and HL-7).

I might suggest looking at DICOM Structured Reporting too.


> It has been mentioned before that (in COAS) we are not just considering
> observations which are in a patient record.  Well, although in a sense
> that may be true, equally I believe one could consider that any observation
>  recorded about a patient anywhere in what ever format is part of a Health
> Care Record Fragment. 

Your point is well taken.  In case there was any misunderstanding of
things I have said let me explain a couple differences I have identified
between systems.  Some systems are collecting observations data from
devices (vital signs comes to mind as well as imaging equipment).  This
data has not been reviewed by a clinician and does not have their
official (legal?) approval to be part of the medical record.  There are
some servers that will ONLY be dealing with data of this type.  COAS (or
a subset) should be useable by these systems so clients can access this
data.  These systems should not be burdened with ALL the requirements of
a Health Care Record Fragment.

Another common characteristic of these systems (as well as other
systems) is that the data is only available for a relatively short
period of time (24 hours, 96 hours, for the encounter, etc.).  That is,
not all systems that contain observations data (hence could expose the
data via COAS) have permanent storage.  I do agree this data will be
used (looked at) for the care of the patient during the length of stay
and will need to meet SOME requirements of a Heath Care Record Fragment.

One of the issues we will need to deal with in COAS is how systems can
express these differences.  Just in the last couple days I have been
thinking about this.  A long phone call with Dean Bidgood helped me with
this as he has considered this problem in the DICOM SR.  Also staying up
till 2:00 this morning reviewing some healthcare
standards/projects/papers gave me time to think about it.  I will bring
this up in Denver and Helsinki.


> The question of grouping of data was one that, as I understand it, gave
> CEN and implementors of their pre-standard, some headaches.  The EHCR-SupA
> model for this (similar to the GEHR one) apparently allowed them to solve
> many of these.  It is important to distinguish the levels at which things
> could or should be grouped and the consequences of so doing.  

I look forward to understanding this.  From my interpretation of HL7 2.3
OBX it suffers from the same problem.  I figure they will be working on
this for version 3.0 but 2.3 allows grouping but it is up to every
application to group the way they want.  This gives a lot of flexibility
at the expense of interoperability.


> Certianly COAS must take careful note of access controls.  The Information
> may well have access rights attached to them which may prevent queriers from
> returning the full information, as well as rights which may have been
> imposed at the system, place or country level.

Yep.  We crossed this issue in the development of PIDS too.  The nice
thing is that by specifying the interface in COAS as an object the true
implementation is encapsulated.  The implementation can filter the
contents before it returns it.


> The question was raised as to how best to represent the QualifiedConcept
> of LQS, as well as the question of guaranteeing or otherwise access to an
> LQS.  A similar question arose on the way to EHCR-SupA and a compromise
> position was arrived at.

I will be interested in hearing your solution.  For those that are not
familiar with this, the problem is a client may want all instances of a
general kind of information (e.g. all hemodynamic measurements).  Does
the client have to pass in all specific codes (e.g. arterial blood
pressure, cardiac output, oxygen saturation, etc.) or can the server do
the expansion of the concept.  There are scenerios where each solution
is the most appropriate.


> My experience suggests that eventually the modellers will start to converge
> but that this is a process that simply takes time  time to discuss the
> issues with one another and to go away and think about them.  Attempts to
> rush this process in the past have seen people dig their heels in and end up
> with a fragmented solution.  Progress is occurring and I can see no reason
> to rush with COAS.  I concur with Jon Farmers comment that the pure
> analyst in us likes to exhaustively model the world and believe that we see
> it all perfectly  and nobody will come up with a structure that breaks our
> model  The realist always accomplishes more in the long haul.  There are
> inevitably purists involved in all decent modelling efforts, as well as
> realists  but we will not get purists to become realists overnight!

I strongly agree that it will be some time before this is ALL solved. 
However that does not mean we can't solve SOME of it now.  For those
that don't know, let me explain a little how the OMG works and the
direction COAS will take (as asked for in the COAS RFP).  The OMG solves
small problems at a time as opposed to massive problems.  RFPs are
normally targeted that way (including COAS).  Those that have followed
the recent discussions about BOCA should realize it is the one RFP I
know of that did not try to solve a small piece of technology and it has
been around for 30 months with a document of ~300 pages.  It is still
controversial since it is hard to get agreement on BIG
problems/solutions.

The COAS RFP asks for an access service that is EXTENSIBLE and has SOME
of the data defined that can be accessed.  You have heard Bob mention
this a few times on this list.  COAS will NOT solve the whole problem of
clinical observations and/or the healthcare record (called patient
record in the US).

I have been driving to get the various standards and modeling efforts to
assist in developing the information/object model for COAS.  I have been
vague (on purpose) about how much of this I think we will be able to
agree on for COAS.  We will have a better idea for that after the next
couple weeks.  I think there are some basic things we can agree on
quickly and other things will take longer.  As Jon said we can use the
80/20 rule (or 90/10 rule, which ever).  When we have something useful
and it seems it will take a while to get further consensus then we claim
success.  Other activities will address the rest (such as EHCR-SupA and
HL7 3.0 RIM).


I hope this helps explain where (IMHO) COAS is coming from.  I only
speak for one of the submitters.  If others disagree please indicate so.

See you in Helsinki Richard.


Cheers,

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