Re: [COAS-List] COAS - Various

["Richard Dixon" <R.M.Dixon@comhealth.hull.ac.uk>]

>I might suggest looking at DICOM Structured Reporting too.


Will do - is there a reccomended URL?

[...]
>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.

I follow your point entirely.  One interesting question, which I was
reminded about a couple of days ago when reading an early ethico-legal GEHR
deliverable, is:
If a system is storing information about a patient, it can be argued that it
*should/must* require clinical authority/approval to be there and
*should/must* be secure and have a certain amount of additional information
as required of patient record fragments.  i.e. even if when queried the
system returns "clinically authorised by = noone", this kind of information
should be returned.  Patient data comes under the data protection act (at
least) and there are a huge number of generally small and ad hoc systems out
there which ignore such facts.
Now, I'm not saying that these systems are going to change overnight, but
IMHO, it is only right of a COAS service to *request* the necessary
ethico-legal information, even (or especially) if that forces the system to
return its shortcomings..

>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.
[...]

A very good point to take into account.

[...]
>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

Your point is well made - Bob's too (see next response) - let's take it a
bit at a time and see what can be done.

Richard