[COAS-List] Re: COAS proposal

[Tim Brinson <tim@protocol.com>]

Angelo,

I had an action item to contact you about reviewing COAS.  You beat me
to it.  Please see my comments in line below.  Welcome to the COAS
development team.


Angelo Rossi Mori wrote:
> 
> Dear colleagues,
> I'm the Project Leader of a Team for the production of a CEN
> standard about "Domain Termlist" for Communication of Patient Record
> (see attachement).

Thank you.  I am on the HL7 Templates mail list (where you had posted
this earlier) and I have already pulled down the draft spec.  I'm glad
to see you are addressing this important issue that does have a relation
to what we are doing in COAS.

 
> I was aware of your proposal (revised submission, 98-09-01, draft 5)
> from the discussion on templates in HL7.
> I know I'm late to join the group, but nevertheless I would like to contribute
> to the evolution of the proposal in the next future.
> 
> What are the next steps ?

An Information Model has evolved over the last few months.  We just had
a meeting last week and resolved most of the remaining critical issues. 
I am working to update the document and put it out for review.

I will be bringing up some issues for discussion on the COAS discussion
mail list.  To subscribe send email:

	To: coas-request@cs.fiu.edu
	Subject: 
	Body: subscribe


> In the meanwhile, please consider the potential synergies with the CEN standard.
> I see many points of overlap:

I have looked at both PT27 and PT26 and am working to be synergistic. 
We see COAS as solving one part of the interoperability problem (a
standard access mechanism) that complements the other great work being
done by other organizations (e.g. CEN, HL7, etc.).


> 1. the scope of "observation".
> I think it should be limited to situations (see 3.4 and the subtypes from
> DF01 to DF05, in table A.3, i.e.
> 
> DF01 situation
> DF02 - physiopathological condition or state
> DF03 - - allergy state
> DF04 - events and accidents
> DF05 - life features
> 
> and excluding what we called elsewhere "secondary categories",
> e.g. drugs, devices, methods, etc.
> In fact, they are important characteristics for a situation,
> but not a situation in itself, i.e. they cannot exist in a record
> in isolation, but the must be in the context of an action of or a state).
> 
> In other words, I agree with the definition you provide in §3.1,
> and in my view this definition excludes such items as
> a drug, a prosthesis, a method in isolation.
> 
> The CEN standard includes also the activities
> (the standard is about "clinical information").
> I don't have an opinion is a description of an activity
> is or not an "observation".

This is an area where we have made progress.  After gaining input from a
number of people (especially clinicians) we are taking the broader
definition of 'Observations' as it applies to COAS.  Many people have
asked us to broaden it to 'Health Record Item' and the such.  When
asking other Medical Informaticists what an Observation is they tend to
reply "anything in the patient record".  I was surprised the timeliness
of the discussion you started on the SGML list about patient record
categories/headings.  We had been discussing the same issue in the last
couple months where I believe compatible results were achieved.

I'm not sure if 'Observations' is the best term for what we are doing. 
No one has suggested a different term (yet).  In some ways it still
seems to fit since all these entries in the health record are assertions
(observations) being made by an entity (the observer - human or machine)
about another entity (ObservationSubject).


> 2. the idea of "context"
> please give a look at the "status concepts" in 3.7 and in 4.2.2
> and in tables A3 and C2.
> They are a kind of instantiation context, complementary to other kinds of context
> (e.g. to a "clinical interpretation context" = orders, encounters and problems,
> and to a "documenting context"= author, date of registration,
> and to a "performance context"= patient name, hospital location, names of professionals, etc)
> 
> I feel the distinction between clinical concept and status concept
> is one of the most important features of the proposed CEN standard.

Luckily I had seen this before the COAS meeting last week and brought it
up as an important issue.  In our Information Model we had something
called ObservationQualifier.  When we started listing out the various
qualifiers that would need codes (aka termlist) it became appearant it
was a grass catcher for many things including status, observation type
modifiers, external context, observation value modifiers, etc.  Your
draft prestandard pointed this out to me as it mentioned 'clinical
concept' and 'status concept'.

We discussed whether each of these things should be shown explicitly in
the model.  By the end it looks like there are no international
agreements for these categories of status/context information.  For this
reason we will probably remove them from being explicitly shown in the
model but provide a mechanism to support various organizations of this
information.  That way COAS can support different structures as defined
by CEN, HL7, DICOM, etc.  Hopefully over the next few years those groups
will be able to come to a consensus on the strucure.

As Brian Love had mentioned to us this last summer "There are no
international agreements on the strucure of the health record".  He
emphasised that COAS will provide value by having a standard access
capability but should shy away from putting it's stake (yet another
stake) in the ground on the structure of health records.

Stan Huff has presented the argument that (from past experience) any
hard coded structure (no matter how much you believe it to represent
reality) has a potential to change over time.  If the strucure is
defined in the API then the SW has to be recompiled and distributed
which can be expensive.  


> 3. the tentative list of links
> we tried to make explicit (and then standard) a detailed list of
> potential links. (are they corresponding to your "IemRelation" ?)
> Without an explicit list, the usability of those links by "any"
> record system will be very limited.

We had planned to document codes for these as well.  Our intention has
been to reference other coding schemes where possible as opposed to
creating our own.  I was pleased to see your draft CEN prestandard PT27
has already started to create a list of these (Table A.5).  It appears
they are not treated as codes though.  Are you considering giving them
codes in order to address the interoperability of systems exchanging
such information?


> I have to confess that I'm lost in your proposal, and I'm not able
> to find where the peculiarity of clinical observations is involved.
> 
> What happens if we deal with other kinds of patient-related information,
> e.g. an appointment ?
> Do we need to change only the set of codes, or also other items
> in your proposal ?

The intent is to make sure you only have to change the codes.  As I
mentioned above we have taken the broader definition of Observations. 
Many people pointed out the complexity and breadth of observations
covers that of other information in the health record.  We also found
that many people had the view prescriptions and treatments which are
interventions get documented as observations (facts) as well.


Glad you initiated this discussion.  I hope you will join the COAS mail
list and are able to help with the futher development of COAS.


Regards,

Tim Brinson
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