[COAS-List] Summary of Helsinki COAS related meetings

[Charles Carman <ccarman@medgrid.philips.com>]

Minutes of the COAS Submitters Meeting at CORBAmed in Helsinki, Finland
			7/27 & 7/30, 1998

Present:
Submiters
	Tim Brinson, Protocol
	Chuck Carman, PMS
Contributors
	Konstantin - BHSSF (for the security discussion)
	Mary Kratz - U. Michigan (for most of the day)
	Wayne Wilson - U. Michigan (for most of the day)
	Richard Dixon - U. of Hull, England
	Etienne Saliez - Medical Informatics Consultant, France
	Peter Nicklin - English NHS
	Brian Love - Management, English NHS (for the afternoon)

We started with introductions and some brainstorming on the categories of
observations, observation data types, and queries for observations,
reviewing the results of the brainstorming from the COAS submitters meeting
last week as we proceeded.
Etienne is interested in gaining access to medical items from a physician's
workstation.
Richard and Peter are interested in compatibility between COAS and the
various European information models and implementations.
Mary and Wayne are interested in architecting and implementing clinical ISs
at the U. of Michigan. 

Konstantin gave an overview of HRAC in relation to COAS [the HRAC RFP is
CORBAmed98-02-23, initial submission is 10/19/98 and final submission is
3/1/99.]
The submission team he is a member of includes 2AB, CareFlow|Net, BHSSF,
and IBM as submitters and C5, Inprise, NSA, U. Michigan, TIS, Philips
Medical, and NIST as supporters.
The design involves an Access Decision Object (ADO) server, an ADO client
(such as a COAS server) and a  "consulting" interface for configuring the
ADO.  An example of an access control method is:
	boolean access_allow(...)
with the following types of parameters
	resource, e.g. what is being accessed, sensitivity level
	operation, ie. read, write, create, delete, use
	credentials, e.g. definition of who, in what role
COAS may need to define the COAS specific resources or a COAS resource space.
An example policy is
If relationship(user, r.pid) == attending_physician then allow read_operation

The HRAC submitters team is still working on the definitions / designs of
the "resource" attributes and the policy definitions.  We had some
questions, and example queries against the ADO, to better understand the
thinking about the operation of the ADO.  There may be some methods that
return more than just a "boolean", such as a sequence of "boolean", or a
sensitivity level, or a list of valid operations, or …
Konstantin formally asked the COAS submitters to give the HRAC submitters
(or at least the team that he represented) some use cases that could be
used in designing the HRAC.

Following the security discussion, we spent a lot of time discussing
information / object modeling issues.  The primary issues were
1. The desire to have an information / object model of Clinical
Observations from which the COAS IDL can be derived [Richard Dixon plus the
direction of COAS submitters in Denver],
2. The assertion that there is NO international agreement within the
clinical modeling communities on a model of Clinical Observations, and that
COAS should work for all existing models without imposing any restrictions
on those models [Brian Love, with some support from Wayne], and
3. The assertion that relationships between Observations should be made
explicit and should be described explicitly (such as with a concept code)
[Peter Nicklin].

We ended up with a model, based strongly on the arguments of Brian and
Peter, that contains an Observation, sub-classed to Text, Measurement,
Blob, etc., with an associated Context, and two 0..N links to an
Association object.  [A diagram of this model is available upon request,
with the understanding that this is a very preliminary model that has not
been discussed by all of the submitters.]

During the CORBAmed meeting, the relationship between COAS and the Record
Locator Service (RLS) was discussed.  Although nothing was resolved, it
appears that COAS has included most of the clinical items of interest
within its scope, and with the federation of COAS servers and the ability
to return meta-data instead of just observation values, the COAS provides
most of the envisioned functionality of RLS.  There is still some
functionality, that was not strictly part of locating patient records, that
was still of interest to members of CORBAmed and is not within the scope of
COAS.  CORBAmed will review the functionality provided by COAS at the next
meeting and determine if additional RFIs or RFPs are needed.  The sense of
the group was that COAS might be renamed to broaden Clinical Observations
to Patient Items (PIAS?).

Tim and Chuck met Thursday afternoon to start composing IDL.  We defined a
set of component interfaces, a definition for the Observation object, and a
set of methods for each component interface.  We modified the model
slightly in order to simplify the design of the Observation object (so we
did not have to define / create an Association object) which has the side
effect of restricting the space of supported graphs of associated
Observations.  This IDL will be distributed for review in the following
three stages: first by the submitters, then by the active supporters, and
then more widely to all interested parties.