Date: Thu, 09 Apr 1998 11:53:56 -0400
From: "Eric Navarro" <ericn@baptisthealth.net>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net
Subject: New mailing list - coas@baptisthealth.net

Welcome to the COAS Submitters mailing list!

This is a manually maintained list.  If anyone needs to be added,
deleted or edited on the list, please feel free to contact me at
ericn@baptisthealth.net

Current members of the list are:
ot@baptisthealth.net
medgrid@pmc.philips.com
tim@protocol.com
juggy@careflow.com

Thank You,
Eric N.
--
Eric Navarro
Systems Architect
CPR/Object Technology, IT
Baptist Health Systems of South Florida
ericn@baptisthealth.net


Sender: tim@protocol.com
Date: Thu, 09 Apr 1998 14:38:31 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Kent Wreder <kentw@bhssf.org>
CC: coas@baptisthealth.net
Subject: Re: CORBAmed Clinical Observations Access Service (COAS) Deadline

Kent Wreder wrote:
>
> Tim,
>
> I think you mentioned that the OMG rules had changed as far as having to be a
> vendor and having a commercial implementation.  What is the implication for an
> end user such as BHS to respond?  We are certainly going to implement COAS, in
> fact we are just concluding a contract negotiation that explicitly brings us
> COAS interfaces in pathology domain upon ratification of your pre-RFP
> specification :-).
>
> Kent.

Kent,

I was out of the office for two weeks and had not read your email until
yesterday.  I think it would be a good idea for BHSSF to submit to
COAS.  The LOI date has passed but we did not receive as many LOIs as I
expected so I plan to beat the bush to try and get others to submit
too.  The current LOIs are:

	3M
	CareFlow|Net
	Genesis Development Corporation
	Philips
	Protocol Systems

I plan to contact the following companies to see if we can get any of
them to submit to COAS.  I feel we need a bigger turn out for the
industry to take the resulting spec serious.

	Sunquest
	HBOC
	GE Medical
	IDX
	SMS
	Oacis
	2AB
	IONA
	Medi-Span

Regards,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard1.vcf"
Sender: tim@protocol.com
Date: Fri, 10 Apr 1998 16:19:56 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5 sun4m)
To: Eric Navarro <ericn@baptisthealth.net>
CC: dhf@alpha.sunquest.com, coas@baptisthealth.net
Subject: Re: New mailing list - coas@baptisthealth.net

Eric Navarro wrote:
>
> Welcome to the COAS Submitters mailing list!
>
> This is a manually maintained list.  If anyone needs to be added,
> deleted or edited on the list, please feel free to contact me at
> ericn@baptisthealth.net
>
> Current members of the list are:
> ot@baptisthealth.net
> medgrid@pmc.philips.com
> tim@protocol.com
> juggy@careflow.com
>
> Thank You,
> Eric N.
> --
> Eric Navarro
> Systems Architect
> CPR/Object Technology, IT
> Baptist Health Systems of South Florida
> ericn@baptisthealth.net

Eric,

Add David Foard of Sunquest (dhf@alpha.sunquest.com) to the mail list.
Sunquest will at least be a supporter and are interested in becoming a
submitter to COAS.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard2.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 15 Apr 1998 13:27:04 -0700
To: "COAS" <coas@baptisthealth.net>
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: RE: COAS Response Ideas
Cc: <corbamed_Wg@umich.edu>

Juggy,

Below is one possibility for XML.  What are the criteria for a "viewfoil"?

Disclaimer:  these are just raw ideas, not to be interpreted as endorsed by
Philips.

Consider a server which supports observations of type X, where

	ResultX 	= result type for a particular observation
	ArgX 		= encapsulation of arguments for call for X
	Octets		= typedef for sequence<octet>.

The server could have explicit calls for each observation

	// explicit call
	ResultX getX( ArgX arg );

as well as an ID for each observation, a CodedConcept, based on a
NamingAuthority:

	// uniquely identify this particular observation
	readonly attribute CodedConcept CodeX;

Parameterizing the requested observation, the server could offer
"universal" calls for any of its supported observations, with a variety for
return types, including the flavor of the week, XML.  These "universal get"
calls could be implemented by the server via straightforward calls to the
server's own explicit "getX" calls, along with the proper packaging into
XML, Any's, etc.

	//  returning Any which has ResultX inserted
	any getAny( CodedConcept reqCode, any arg );

	// returning Object by Value (superclass = Base)
	value Base getOBV( CodedConcept reqCode, value Base arg );

	// returning XML as octet sequence
	Octets getXML( CodedConcept reqCode, Octets arg );


The result of a getXML call is pictured here as a sequence of octets, which
would be the XML representation of ResultX.  In Java, implementing this XML
could be achieved with a straightforward "reflection" of the ResultX struct
(as Kent alluded to earlier) along with its data.  In other words, the DTD
for a return value would be directly derived from the IDL for the return
type.

Many questions beg for experience and a design context: what's the best
return type for getXML--would a string result be more appropriate?  Would
it be appropriate to have something besides Octets for the arg value?

I hope a viewfoil can have unanswered questions :-)

larry

Larry Hamel
Philips Medical Systems

At 10:46 PM 4/14/98 -0400, V. Juggy Jagannathan wrote:
>
>
>>
>> 	XML - This is getting a lot of interest.  Some discussions
>> have been to
>> use XML for structured reports.
>>
>>
>
>I was planning on attending the HL7/XML SIG in the upcoming meeting. Rachael
>Sokolowski, who chairs this session just requested me today if I could make
>a
>presentation on what is happening in CORBAmed in general and the COAS front
>in
>particular to enlist submitters from that
>group. Looks like a bunch of CORBAmed/HL7 efforts are underway - and I want
>to make sure that there is a consistent message...will check with Mary,
>Harold and
>Peter.
>
>Any viewfoils to help out on the COAS front appreciated... :-)
>
>- regards
>- juggy
>
>
>

Reply-To: <juggy@careflow.com>
From: "V. Juggy Jagannathan" <juggy@careflow.com>
To: "Larry Hamel" <larryh@medgrid.philips.com>,
        "COAS" <coas@baptisthealth.net>
Subject: RE: COAS Response Ideas
Date: Thu, 16 Apr 1998 12:32:48 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4


thanx, Larry. We can discuss some of these notions today in the conference
call...

- regards
- juggy


> -----Original Message-----
> From: Larry Hamel [mailto:larryh@medgrid.philips.com]
> Sent: Wednesday, April 15, 1998 4:27 PM
> To: COAS
> Cc: corbamed_Wg@umich.edu
> Subject: RE: COAS Response Ideas
>
>
> Juggy,
>
> Below is one possibility for XML.  What are the criteria for a "viewfoil"?
>
> Disclaimer:  these are just raw ideas, not to be interpreted as
> endorsed by
> Philips.
>
> Consider a server which supports observations of type X, where
>
> 	ResultX 	= result type for a particular observation
> 	ArgX 		= encapsulation of arguments for call for X
> 	Octets		= typedef for sequence<octet>.
>
> The server could have explicit calls for each observation
>
> 	// explicit call
> 	ResultX getX( ArgX arg );
>
> as well as an ID for each observation, a CodedConcept, based on a
> NamingAuthority:
>
> 	// uniquely identify this particular observation
> 	readonly attribute CodedConcept CodeX;
>
> Parameterizing the requested observation, the server could offer
> "universal" calls for any of its supported observations, with a
> variety for
> return types, including the flavor of the week, XML.  These
> "universal get"
> calls could be implemented by the server via straightforward calls to the
> server's own explicit "getX" calls, along with the proper packaging into
> XML, Any's, etc.
>
> 	//  returning Any which has ResultX inserted
> 	any getAny( CodedConcept reqCode, any arg );
>
> 	// returning Object by Value (superclass = Base)
> 	value Base getOBV( CodedConcept reqCode, value Base arg );
>
> 	// returning XML as octet sequence
> 	Octets getXML( CodedConcept reqCode, Octets arg );
>
>
> The result of a getXML call is pictured here as a sequence of
> octets, which
> would be the XML representation of ResultX.  In Java,
> implementing this XML
> could be achieved with a straightforward "reflection" of the
> ResultX struct
> (as Kent alluded to earlier) along with its data.  In other words, the DTD
> for a return value would be directly derived from the IDL for the return
> type.
>
> Many questions beg for experience and a design context: what's the best
> return type for getXML--would a string result be more appropriate?  Would
> it be appropriate to have something besides Octets for the arg value?
>
> I hope a viewfoil can have unanswered questions :-)
>
> larry
>
> Larry Hamel
> Philips Medical Systems
>
> At 10:46 PM 4/14/98 -0400, V. Juggy Jagannathan wrote:
> >
> >
> >>
> >> 	XML - This is getting a lot of interest.  Some discussions
> >> have been to
> >> use XML for structured reports.
> >>
> >>
> >
> >I was planning on attending the HL7/XML SIG in the upcoming
> meeting. Rachael
> >Sokolowski, who chairs this session just requested me today if I
> could make
> >a
> >presentation on what is happening in CORBAmed in general and the
> COAS front
> >in
> >particular to enlist submitters from that
> >group. Looks like a bunch of CORBAmed/HL7 efforts are underway -
> and I want
> >to make sure that there is a consistent message...will check with Mary,
> >Harold and
> >Peter.
> >
> >Any viewfoils to help out on the COAS front appreciated... :-)
> >
> >- regards
> >- juggy
> >
> >
> >
>


Reply-To: <juggy@careflow.com>
From: "V. Juggy Jagannathan" <juggy@careflow.com>
To: "Larry Hamel" <larryh@medgrid.philips.com>,
        "COAS" <coas@baptisthealth.net>
Subject: RE: COAS Response Ideas
Date: Thu, 16 Apr 1998 14:22:33 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4


Larry,

Henry prototyped this notion of using reflection property of Java structures
to
create XML tagged strings automatically, couple of weeks ago. It works.

Here are few discussion points:

	1. Map the structures defined in IDL's to XML
	2. have something along the lines of getXML - similar to getAny

Issues/Questions:

	it is unclear how to map attributes...it is more work to use a DTD to map
	returned structures to XML that corresponds to a DTD

- regards
- juggy


> -----Original Message-----
> From: V. Juggy Jagannathan [mailto:juggy@careflow.com]
> Sent: Thursday, April 16, 1998 12:33 PM
> To: Larry Hamel; COAS
> Subject: RE: COAS Response Ideas
>
>
>
> thanx, Larry. We can discuss some of these notions today in the conference
> call...
>
> - regards
> - juggy
>
>
> > -----Original Message-----
> > From: Larry Hamel [mailto:larryh@medgrid.philips.com]
> > Sent: Wednesday, April 15, 1998 4:27 PM
> > To: COAS
> > Cc: corbamed_Wg@umich.edu
> > Subject: RE: COAS Response Ideas
> >
> >
> > Juggy,
> >
> > Below is one possibility for XML.  What are the criteria for a
> "viewfoil"?
> >
> > Disclaimer:  these are just raw ideas, not to be interpreted as
> > endorsed by
> > Philips.
> >
> > Consider a server which supports observations of type X, where
> >
> > 	ResultX 	= result type for a particular observation
> > 	ArgX 		= encapsulation of arguments for call for X
> > 	Octets		= typedef for sequence<octet>.
> >
> > The server could have explicit calls for each observation
> >
> > 	// explicit call
> > 	ResultX getX( ArgX arg );
> >
> > as well as an ID for each observation, a CodedConcept, based on a
> > NamingAuthority:
> >
> > 	// uniquely identify this particular observation
> > 	readonly attribute CodedConcept CodeX;
> >
> > Parameterizing the requested observation, the server could offer
> > "universal" calls for any of its supported observations, with a
> > variety for
> > return types, including the flavor of the week, XML.  These
> > "universal get"
> > calls could be implemented by the server via straightforward
> calls to the
> > server's own explicit "getX" calls, along with the proper packaging into
> > XML, Any's, etc.
> >
> > 	//  returning Any which has ResultX inserted
> > 	any getAny( CodedConcept reqCode, any arg );
> >
> > 	// returning Object by Value (superclass = Base)
> > 	value Base getOBV( CodedConcept reqCode, value Base arg );
> >
> > 	// returning XML as octet sequence
> > 	Octets getXML( CodedConcept reqCode, Octets arg );
> >
> >
> > The result of a getXML call is pictured here as a sequence of
> > octets, which
> > would be the XML representation of ResultX.  In Java,
> > implementing this XML
> > could be achieved with a straightforward "reflection" of the
> > ResultX struct
> > (as Kent alluded to earlier) along with its data.  In other
> words, the DTD
> > for a return value would be directly derived from the IDL for the return
> > type.
> >
> > Many questions beg for experience and a design context: what's the best
> > return type for getXML--would a string result be more
> appropriate?  Would
> > it be appropriate to have something besides Octets for the arg value?
> >
> > I hope a viewfoil can have unanswered questions :-)
> >
> > larry
> >
> > Larry Hamel
> > Philips Medical Systems
> >
> > At 10:46 PM 4/14/98 -0400, V. Juggy Jagannathan wrote:
> > >
> > >
> > >>
> > >> 	XML - This is getting a lot of interest.  Some discussions
> > >> have been to
> > >> use XML for structured reports.
> > >>
> > >>
> > >
> > >I was planning on attending the HL7/XML SIG in the upcoming
> > meeting. Rachael
> > >Sokolowski, who chairs this session just requested me today if I
> > could make
> > >a
> > >presentation on what is happening in CORBAmed in general and the
> > COAS front
> > >in
> > >particular to enlist submitters from that
> > >group. Looks like a bunch of CORBAmed/HL7 efforts are underway -
> > and I want
> > >to make sure that there is a consistent message...will check with Mary,
> > >Harold and
> > >Peter.
> > >
> > >Any viewfoils to help out on the COAS front appreciated... :-)
> > >
> > >- regards
> > >- juggy
> > >
> > >
> > >
> >
>


X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 20 Apr 1998 09:00:11 -0700
To: coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Submitter's teleconference notes
Cc: medgrid

A teleconference was held on Thursday 16 April 1998.  The following people
were in attendance:

- Yasser alSafadi (Philips Research, Briarcliff)
- Ray Krazinski (Philips Research, Briarcliff)
- Girish Hagen (Agfa)
- Tad Davis (Care Flow Net, Inc.)
- Henry Ware (Care Flow Net, Inc.)
- V. Juggy Juggannathan (Care Flow Net, Inc.)
- Eric Butler (BHSSF)
- Eric Navarro (BHSSF)
- Enrique Urzais (BHSSF)
- Mary Kratz (University of Michigan)
- Tom Culpepper (3M)
- Dave Foard (Sunquest)
- Tim Brinson (Protocol Systems)
- Bob Glicksman (Philips Medical Systems)
- Weimin Shen (Philips Medical Systems)
- Larry Hamel (Philips Medical Systems)
- Chuck Carman (Philips Research)

1.  The group discussed the procedures for COAS submission:
  -- deadline: 18 May 1998
  -- some companies need up to 2 weeks for internal legal review
  -- initial submissions are often very sparse; just placeholders
  -- companies join and leave the team as the submission continues toward
final.  There is precedent for this (IBM in LQS).

2.  Each participant had an opportunity to discuss their interest in COAS.
A synopsis of interest is:
  -- transcription (Care Flow Net)
  -- medical imaging (Agfa, Philips)
  -- System integration, LIS-Path (BHSSF, U-MICH)
  -- Interoperability to legacy databases (3M)
  -- LIS, RIS, Pharm, A/P (Sunquest)
  -- Vital signs (Protocol Systems)

3.  A lengthy technical discussion was held about the topics that were
pre-released:
  -- "generalized get()" vs. getx():
    ---- "generalized get() more desirable than "universal get()"
    ---- tried to return an "any" but performance was terrible.  Could be a
problem with any or with a specific ORB vendor's implementation (not
determined at this time)
    ---- if generalized get() is used, should only related general
groupings (e.g. heart rate, B/P, etc.)
    ---- OBV should be looked at but can't be handled now because it is too
new.  Combines benefits of generalized get() and getx().
  -- Protocol System COBS
    ---- design for a specific problem (vital signs) but thinking when into
extensibility to other data types
    ---- query: who (patient), when (period or interval, point in time),
what (data relevant to the timed event)
    ---- used generalized get() with resultUnion.  Found that the latter
was difficult to use and caused extensibility problems.  OBV could solve this.
    ---- propose trader-like constraint language for notifications
(publish-subscribe); an SQL like language adopted for Trader.  Could query
like "select heartrate where systolic BP > 180 and last_name = "Smith" "
  -- XML:
    ---- DTD to IDL converter would allow DTD work of HL-7 and other groups
to be used.
    ---- need dynamic discovery of coded concepts (and return types) and
how to access them (e.g. filters).

4.  Next Steps:
  -- Tim will clean up the COBS and offer it to the team as the initial
submission
  -- Dave will look into adding Labs
  -- Others will look at this and make comments/suggestions as well.
  ** Another conference call will be held on Tuesday 28 April 1998 at 1:00
pm PDT (4:00 pm EDT).  Bob Glicksman will set this up.

---- end of minutes ----

_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Sender: tim@protocol.com
Date: Mon, 20 Apr 1998 10:54:04 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Bob Glicksman <bobg@medgrid.philips.com>
CC: coas@baptisthealth.net, medgrid@pmc.philips.com
Subject: Re: Submitter's teleconference notes

Bob Glicksman wrote:
>   -- companies join and leave the team as the submission continues toward
> final.  There is precedent for this (IBM in LQS).

There is also a running precedence for this through out the OMG's
history.


>     ---- tried to return an "any" but performance was terrible.  Could be a
> problem with any or with a specific ORB vendor's implementation (not
> determined at this time)

I have heard many times from ORB vendors that this was a problem by a
couple ORBs in the past but during the IDL->Java mapping submission they
all worked out a more efficient mechanism as they resolved the portable
stubs issues.  Maybe some of the ORB vendors have not fixed the problem
in their ORBs yet.  As Bob says we still need to find out if other ORBs
do a better job.


>     ---- if generalized get() is used, should only related general
> groupings (e.g. heart rate, B/P, etc.)

Not sure what this means.


>     ---- need dynamic discovery of coded concepts (and return types) and
> how to access them (e.g. filters).

I am hoping the LQS Value Domains can be used for this.  That is why
Protocol co-submittered on LQS with 3M.  We have not prototyped this
here at Protocol yet though.


> 4.  Next Steps:
>   -- Tim will clean up the COBS and offer it to the team as the initial
> submission

COBS probably deals with only about 10% of what is needed in COAS.  The
reasoning submitting it is that the document already exists.  It would
be better if we can actually pull many of the other things together into
a complete submission.  I will not have a lot of time for that before 18
May.  Can other people help out here.  At a minimum I expect to prepend
an issues list on the front of the submission.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard5.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 20 Apr 1998 20:32:27 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: pronunciation; sync/asynch?

y'all,

first a parliamentary note:  I move that we make the official pronunciation
of "COAS" such that it rhymes with "jazz".

second, a survey:  should COAS offer synchronous and/or asynchronous
interfaces?

I see some tradeoffs as follows:

sync:
+ simpler implementation
+ no firewall issues for clients
- no cancellation of outstanding requests (where response is no longer
required)
- less general (async services like DICOM not modeled well)


async:
- more complex
- firewall issues
+ cancellation
+ more general (sync services just answer fast)


Note that we can choose to have both sync & async interfaces in the same
server.

I'm curious if you have other criteria, and how you weigh the criteria.

larry

Larry Hamel
Philips Medical Systems


Sender: tim@protocol.com
Date: Wed, 22 Apr 1998 10:57:40 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COBS dialog--useful for COAS list?

Larry Hamel wrote:
>
> Tim,
>
> i have copies of our discussion last year about COBS.  do you think it
> would be beneficial to send them to the COAS list?
>
> larry

Not sure.  It may be difficult for people to understand if it is taken
out of context.  But if you feel the things need to be repeated go
ahead.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard.vcf"
Sender: tim@protocol.com
Date: Wed, 22 Apr 1998 11:03:57 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: pronunciation; sync/asynch?

Larry Hamel wrote:
>
> y'all,
>
> first a parliamentary note:  I move that we make the official pronunciation
> of "COAS" such that it rhymes with "jazz".

Sounds OK by me.  Is it pronounced as "kazz" or "ko-azz"?

> second, a survey:  should COAS offer synchronous and/or asynchronous
> interfaces?

We definitely need synchronous interfaces.  If some one (like you) needs
asynch interfaces we can add them too.  This is where the
componentization comes in (as was done in PIDS, LQS and Trader).
Servers can support one or more of the different access mechanisms
(interfaces).  I expect a query interface that uses a constraint
language would be separate too.


Tim
Attachment Converted: "c:\program files\eudora\attach\vcard1.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 22 Apr 1998 17:51:36 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: issue list

y'all,

For May 18, what issues should we list at the beginning of the RFP
regarding turning COBS into COAS?  ("ko-az", i propose.)

Below are some issues for discussion Philips has identified so far.  Some
of these have been discussed somewhat, and we may already have consensus.
Others haven't been introduced so we'll try to explain more about each item
in forthcoming discussion.  These are just in alpha order.

* Any/Union/OBV return choices
* cancellation of requests
* general arg in parameter list
* getX/getY in addition to a generalized "get"
* observation_available as separate method
* prefetching (notifying server about current or upcoming patient)
* returning sequence value with multiple types
* subscription for events  (we have some IDL to contribute)
* sync/async
* userID in parameter list
* XML


more later,

larry


Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426-2550

X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 22 Apr 1998 18:03:39 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: Any/Union/OBV return choices

y'all,

have we agreed that Object-by-Value (OBV) is the best return type for COAS?

I see some criteria as follows:

Any:
-poor performance in current Visibroker implementation
+ extensible

Union
- not extensible

OBV
+ extensible
+ can have methods for validation, etc.
- not implemented yet by ORB vendors (but looks like OBV has passed muster:
http://www.omg.org/library/faxvotes/Objects-by-Value_RFP.html )


cheers,

larry

Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426 2550

Sender: tim@protocol.com
Date: Wed, 22 Apr 1998 18:14:43 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: issue list

Larry Hamel wrote:
> For May 18, what issues should we list at the beginning of the RFP
> regarding turning COBS into COAS?  ("ko-az", i propose.)
>
> * Any/Union/OBV return choices
> * cancellation of requests
> * general arg in parameter list
> * getX/getY in addition to a generalized "get"
> * observation_available as separate method
> * prefetching (notifying server about current or upcoming patient)
> * returning sequence value with multiple types
> * subscription for events  (we have some IDL to contribute)
> * sync/async
> * userID in parameter list
> * XML

Here are some I see.  Some may over lap with the ones Larry listed
(above).

* dynamic discovery of supported observations, return types, filters,
etc.
* simple observations vs. structured reports
* Usage of LQS Value Domains
* Multiple access mechanisms
* Simple queries - 1 patient, one time frame, one observation
* Negotiating return type
* Using CDL and BOCA
* General query using constraint lanuages
* Componentization
* Information model
* Subjective vs objective observations vs interventions
* Data types for observations


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard4.vcf"
X-Mailer: Novell GroupWise 5.2
Date: Thu, 23 Apr 1998 11:45:52 -0600
From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
To: tim@protocol.com
Cc: coas@baptisthealth.net, HRSOLBRIG@wpmail.code3.com,
        JWTONKS@wpmail.code3.com
Subject: Initial Submission

Tim,
We are still working out a few internal issues but would at least like to be included on the initial submission.

Have you made any changes yet?

Thanks
Tom

Thomas C. Culpepper
Applied Technology Research Group
3M Health Information Systems
575 West Murray Blvd
Murray, Utah 84123
(801)265-4534
tcculpepper@wpmail.code3.com


X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 23 Apr 1998 19:02:12 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: general arg in parameter list

y'all,

How can a client supply info like a report ID within a COAS request?

The parameter list in the COBS prototype is fine when you can specify
observations with a patientID, a coded concept, a statistical filter, and a
time spec.

But what about a report repository, where a client would start out by
asking for a list of reports (meta information) about a given patient,
perhaps specified by a date range.   So far, so good for COBS.  But to
drill down to a particular report, the client must request a particular
report ID from the list.  Selecting a report only by date would run the
risk of ambiguity if 2 reports had the same timestamp.

Consider that most servers will be based on some kind of database which
relies on unique IDs, so this will be the natural way to request
observations.  Furthermore, some observations will require several bits of
specification (e.g., give me image 2 of imageSet 122 and use JPEG
compression and resolution 512 x 512).  Perhaps some of this info could be
squeezed into generalized filters, but it seems more intuitive to combine
observation-specific parameters into a single argument struct.

So instead of a fixed "when" in the parameter list, consider a more general
argument.  Using Object-by-Value, a Base type can be subclassed to whatever
is necessary for the given request.  A prototype for the query function
would be something like

	value Base getOBV( 	in UserId userId,
				in PatientId	patientId,
				in RequestId	requestId,
				in CodedConcept reqCode,
				in value Base arg );


where
	* UserID identifies the logged-in requesting person (security discussion
forthcoming)

	* PatientID identifies the patient

	* RequestID for this specific client request (callback IOR + sequence #;
discussion forthcoming)

	* reqCode is the coded concept being requested

	* arg is the extensible general-purpose argument

In this prototype, the "when" time spec from COBS has been subsumed by the
general "arg" because time specs seems more applicable to vital-sign
servers than to most other scenarios.

Does this make sense to you?

larry


X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 24 Apr 1998 09:07:20 -0700
To: Larry Hamel <larryh@medgrid.philips.com>, coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS: general arg in parameter list

Remember, as well, that not every query is at the patient level.  A query
for images most likely is at the study level; i.e. it is already known
(e.g. by reading the report) which study is of interest.

At 07:02 PM 4/23/98 -0700, Larry Hamel wrote:
>y'all,
>
>How can a client supply info like a report ID within a COAS request?
>
>The parameter list in the COBS prototype is fine when you can specify
>observations with a patientID, a coded concept, a statistical filter, and a
>time spec.
>
>But what about a report repository, where a client would start out by
>asking for a list of reports (meta information) about a given patient,
>perhaps specified by a date range.   So far, so good for COBS.  But to
>drill down to a particular report, the client must request a particular
>report ID from the list.  Selecting a report only by date would run the
>risk of ambiguity if 2 reports had the same timestamp.
>
>Consider that most servers will be based on some kind of database which
>relies on unique IDs, so this will be the natural way to request
>observations.  Furthermore, some observations will require several bits of
>specification (e.g., give me image 2 of imageSet 122 and use JPEG
>compression and resolution 512 x 512).  Perhaps some of this info could be
>squeezed into generalized filters, but it seems more intuitive to combine
>observation-specific parameters into a single argument struct.
>
>So instead of a fixed "when" in the parameter list, consider a more general
>argument.  Using Object-by-Value, a Base type can be subclassed to whatever
>is necessary for the given request.  A prototype for the query function
>would be something like
>
>	value Base getOBV( 	in UserId userId,
>				in PatientId	patientId,
>				in RequestId	requestId,
>				in CodedConcept reqCode,
>				in value Base arg );
>
>
>where
>	* UserID identifies the logged-in requesting person (security discussion
>forthcoming)
>
>	* PatientID identifies the patient
>
>	* RequestID for this specific client request (callback IOR + sequence #;
>discussion forthcoming)
>
>	* reqCode is the coded concept being requested
>
>	* arg is the extensible general-purpose argument
>
>In this prototype, the "when" time spec from COBS has been subsumed by the
>general "arg" because time specs seems more applicable to vital-sign
>servers than to most other scenarios.
>
>Does this make sense to you?
>
>larry
>
>
>
_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Sender: tim@protocol.com
Date: Mon, 27 Apr 1998 09:33:30 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: Any/Union/OBV return choices

Larry Hamel wrote:
>
> y'all,
>
> have we agreed that Object-by-Value (OBV) is the best return type for COAS?

I am definitely for it.  I expect it may be used for passed in
parameters as well as return types.  Any where structs, unions or enums
have been used we should consider using OBV instead.

This is new technology.  We will learn the usefull patterns for OBV over
time.


Tim
Attachment Converted: "c:\program files\eudora\attach\vcard9.vcf"
Sender: tim@protocol.com
Date: Mon, 27 Apr 1998 09:41:08 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Tom Culpepper <tcculpepper@wpmail.code3.com>
CC: coas@baptisthealth.net, HRSOLBRIG@wpmail.code3.com,
        JWTONKS@wpmail.code3.com
Subject: Re: Initial Submission

Tom Culpepper wrote:
>
> Tim,
> We are still working out a few internal issues but would at least like to be included on the initial submission.

Great!


> Have you made any changes yet?

No.  I was on jury duty the last few days and will be very buisy here at
Protocol in the next few weeks.  I have attached an email that covers
some of the issues expressed so far.  Due to time limitations the
initial submission might just be the COBS with a set of issues described
up front.  I would expect at LEAST one paragraph describing each issue.

Alternatively if someone has time to edit the COBS (or start a new
document) to include some of the ideas:

	GO FOR IT!

I would also welcome any other pieces that people want to include in the
submission.


Regards,

TimReturn-Path: <tim@protocol.com>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id SAA22270; Wed, 22 Apr 1998 18:15:27 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id SAA10156; Wed, 22 Apr 1998 18:15:45 -0700
Received: from unknown(198.160.134.26) by iwall via smap (V2.0)
	id xma010154; Wed, 22 Apr 98 18:15:23 -0700
Received: from protocol.com ([205.238.1.53]) by cobra.baptisthealth.net
          (Netscape Messaging Server 3.01)  with SMTP id 279
          for <coas@baptisthealth.net>; Wed, 22 Apr 1998 21:10:35 -0400
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id SAA10152; Wed, 22 Apr 1998 18:15:15 -0700
Received: from mailhost(199.2.200.200) by iwall via smap (V2.0)
	id xma010150; Wed, 22 Apr 98 18:14:45 -0700
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id SAA22133; Wed, 22 Apr 1998 18:14:24 -0700
Sender: tim@protocol.com
Message-ID: <353E9603.8A3210F9@protocol.com>
Date: Wed, 22 Apr 1998 18:14:43 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: issue list
References: <3.0.2.32.19980422175136.00a6b860@med10.medgrid.philips.com>
Content-Type: multipart/mixed; boundary="------------500BD4CA94EFF2FCCE292A4C"

Larry Hamel wrote:
> For May 18, what issues should we list at the beginning of the RFP
> regarding turning COBS into COAS?  ("ko-az", i propose.)
>
> * Any/Union/OBV return choices
> * cancellation of requests
> * general arg in parameter list
> * getX/getY in addition to a generalized "get"
> * observation_available as separate method
> * prefetching (notifying server about current or upcoming patient)
> * returning sequence value with multiple types
> * subscription for events  (we have some IDL to contribute)
> * sync/async
> * userID in parameter list
> * XML

Here are some I see.  Some may over lap with the ones Larry listed
(above).

* dynamic discovery of supported observations, return types, filters,
etc.
* simple observations vs. structured reports
* Usage of LQS Value Domains
* Multiple access mechanisms
* Simple queries - 1 patient, one time frame, one observation
* Negotiating return type
* Using CDL and BOCA
* General query using constraint lanuages
* Componentization
* Information model
* Subjective vs objective observations vs interventions
* Data types for observations


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard11.vcf"

Attachment Converted: "c:\program files\eudora\attach\vcard12.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 27 Apr 1998 11:55:42 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: cancellation of requests

y'all,

When we click the "stop" button on our web browsers, the HTTP server
realizes that the information originally requested is no longer needed.
This "notification" occurs because the browser closes the TCP connection
with FIN or RST.  As a result, network bandwidth is saved, and the server
has more cycles for other tasks.

Should COAS provide an interface for a client to cancel a request?

CORBA clients retain one TCP connection with a server, so cannot close this
connection and use the "RST" packet as a cancellation of a single request.

It seems like a good idea to provide cancellation for a COAS server which
maps DICOM, where a requested image could be on a CD jukebox, or otherwise
take a long time to retreive (and server resources to downsample and
cache).  The user may not want to wait.

The semantics of the cancellation should leave it up to the server--a
cancellation should be a courtesy notice from the client.  A server may
choose to "no-op" the implementation, ignoring the cancellation notice and
always returning a value for every request.  The client has the duty to
ignore any reply that might come from a cancelled request.

Even fast synchronous requests have the potential for cancellation if we
again look at the web analogy--there may be intermediate factors (e.g., a
COAS middleware server collating several results) which slow the reply to
the client.  Providing the client with a cancellation interface gives
server implementers the option to implement cancellation if they perceive
benefit from doing so.

The interface could be something like

	void cancelRequest( 	in UserId userId, in RequestId requestId );

where UserId identifies the logged-in user for security purposes (separate
discussion forthcoming) and where RequestId is discussed below.


REQUEST IDs

Request identification is relatively easy in CORBA using an IOR, and a
callback IOR is necessary for an async interface.

If each client registers a callback object with its local ORB, each client
then can use the unique IOR from this callback object for client
identification.  For async clients, a callback is mandatory, while for sync
clients, an unused callback is just a few lines of code in order to get a
unique IOR.

With the callback IOR as a "nonce", or unique identifier for the session,
adding a sequence value or timestamp for each successive call from a client
makes for a request ID:

	struct RequestId {
		string nonce;		// IOR of client (unique via ORB)
		string reqSequence;	// request counter and/or timestamp
	};


CANCELLATION IMPLEMENTATION

A server wishing to implement the cancelRequest() with more than a no-op
would have to keep a table of each outstanding request thread ("worker
thread") and its associated RequestId.  For a simple stateless server,
killing an outstanding thread would suffice.  For a more complex server
with resource allocation (e.g., a database session), the server would
create a semaphore with cancellation information.  Worker threads would
have responsibility to check the semaphore periodically, releasing
resources and quitting if cancelled.


Debugging/Auditing

A RequestId could also provide an auditing trail for tracing an individual
request as it flows though different process boundaries from front to back.

Let me know what you think about this.

larry



Sender: tim@protocol.com
Date: Mon, 27 Apr 1998 13:47:11 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: general arg in parameter list

Larry Hamel wrote:
> How can a client supply info like a report ID within a COAS request?
>
> The parameter list in the COBS prototype is fine when you can specify
> observations with a patientID, a coded concept, a statistical filter, and a
> time spec.

The current COBS was designed to work for raw, independent
observations.  The COAS needs to handle reports as well.  Should these
be handled by different IDL?  What is the meta data in reports that
could be filtered on (tags in XML, Keywords, indexed values)?  Should a
report be a separate (remote) object similar to the Clinical Image
Access Service (CIAS)?  Are reports structured after DICOM supplement
23?  Can reports be just plain text?  Can reports be transfered as XML
and/or OBV and/or MIME?  Are nursing notes treated as reports or are
they a separate type?  Do we think COAS servers will typically contain
only raw observations or (logical XOR) structured reports or (logical
OR) they will normally have both?  What is our object/information model
for reports?

I figure the answers to questions like these may influence the direction
of our COAS response.  I would think there are other types of queries a
client would want to do with reports that they would not do with raw
observations.


> But what about a report repository, where a client would start out by
> asking for a list of reports (meta information) about a given patient,
> perhaps specified by a date range.   So far, so good for COBS.  But to
> drill down to a particular report, the client must request a particular
> report ID from the list.  Selecting a report only by date would run the
> risk of ambiguity if 2 reports had the same timestamp.
>
> Consider that most servers will be based on some kind of database which
> relies on unique IDs, so this will be the natural way to request
> observations.

It does seem that reports may need to be given unique IDs but raw
observations are likely not to need these.  The unique ID for a report
could be of different forms:

	An ID that is unique within that server

	A globally unique ID

	An IOR to a Report object

	Possibly others


> Furthermore, some observations will require several bits of
> specification (e.g., give me image 2 of imageSet 122 and use JPEG
> compression and resolution 512 x 512).  Perhaps some of this info could be
> squeezed into generalized filters, but it seems more intuitive to combine
> observation-specific parameters into a single argument struct.

The filters in COBS was tested for vital signs where pseudo-continuous
data collection needs to be decimated, interpolated, etc.  We found that
filters need to be more complex at times and speciallized to the type of
data being accessed (as you point out).


> So instead of a fixed "when" in the parameter list, consider a more general
> argument.  Using Object-by-Value, a Base type can be subclassed to whatever
> is necessary for the given request.  A prototype for the query function
> would be something like
>
>         value Base getOBV(      in UserId userId,
>                                 in PatientId    patientId,
>                                 in RequestId    requestId,
>                                 in CodedConcept reqCode,
>                                 in value Base arg );
>
> where
>         * UserID identifies the logged-in requesting person (security discussion
> forthcoming)

This is not needed.  It is handled with CORBAsec.

>         * PatientID identifies the patient

Looks good.

>         * RequestID for this specific client request (callback IOR + sequence #;
> discussion forthcoming)

I'll respond to the forthcoming message on this topic but basically I
think it gets in the way of synchronized access.

>         * reqCode is the coded concept being requested

Looks OK too.  Is this suppose to work for reports too?  I'm not sure if
reports would be this simple.

>         * arg is the extensible general-purpose argument

I see an extensible filter like this being needed for some opertions.
Of course we would also define some of extensions to be used.

> In this prototype, the "when" time spec from COBS has been subsumed by the
> general "arg" because time specs seems more applicable to vital-sign
> servers than to most other scenarios.

Not sure.  At some point as the query gets more and more general
shouldn't we consider using constraint languages (like ODL and Trader)?


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard13.vcf"
Sender: tim@protocol.com
Date: Mon, 27 Apr 1998 13:53:16 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Bob Glicksman <bobg@medgrid.philips.com>
CC: Larry Hamel <larryh@medgrid.philips.com>, coas@baptisthealth.net
Subject: Re: COAS: general arg in parameter list

Bob Glicksman wrote:
>
> Remember, as well, that not every query is at the patient level.  A query
> for images most likely is at the study level; i.e. it is already known
> (e.g. by reading the report) which study is of interest.

As I understand it you are creating a separate (remote) object for the
study that gets queried.  Is that correct?

I was thinking that reports might also be separate interface objects.
Their object references could get returned from the initial query to the
base service.  Does this make any sense?


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard14.vcf"
Sender: tim@protocol.com
Date: Mon, 27 Apr 1998 15:34:02 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: cancellation of requests

Larry Hamel wrote:
>
> y'all,
>
> When we click the "stop" button on our web browsers, the HTTP server
> realizes that the information originally requested is no longer needed.
> This "notification" occurs because the browser closes the TCP connection
> with FIN or RST.  As a result, network bandwidth is saved, and the server
> has more cycles for other tasks.
>
> Should COAS provide an interface for a client to cancel a request?

This makes sense on asynchronous requests.  There are other means to
handle it for synchronous requests.


> CORBA clients retain one TCP connection with a server, so cannot close this
> connection and use the "RST" packet as a cancellation of a single request.

The ORB handles canceling an outstanding (syncronous) request.  It uses
a CancelRequest IIOP message type.  I know ORBs typically have a request
timeout period and maybe a way for it to be called by a separate thread
too.


> It seems like a good idea to provide cancellation for a COAS server which
> maps DICOM, where a requested image could be on a CD jukebox, or otherwise
> take a long time to retreive (and server resources to downsample and
> cache).  The user may not want to wait.

Makes sense - a separate operation on the IDL for asynchronous and using
your local ORB for synchronous.


> The semantics of the cancellation should leave it up to the server--a
> cancellation should be a courtesy notice from the client.  A server may
> choose to "no-op" the implementation, ignoring the cancellation notice and
> always returning a value for every request.  The client has the duty to
> ignore any reply that might come from a cancelled request.

The server might be able to return some indication to the client such as
CANCELED, CANCEL_PENDING, ATEMPTING_CANCEL or NOT_CANCELED.


> The interface could be something like
>
>         void cancelRequest(     in UserId userId, in RequestId requestId );
>
> where UserId identifies the logged-in user for security purposes (separate
> discussion forthcoming) and where RequestId is discussed below.

The UserId is passed as part of the Principle within the IIOP message.
It is not needed in the IDL.

For asynchronous requests you should also look at the asynchronous
messaging RFP that is in the final submission stage.  It will likely
provide cancelations as well but I have not looked at it.

	ftp://ftp.omg.org/pub/docs/orbos/98-03-11.pdf
 	http://www.omg.org/docs/orbos/98-03-11.pdf


> With the callback IOR as a "nonce", or unique identifier for the session,
> adding a sequence value or timestamp for each successive call from a client
> makes for a request ID:
>
>         struct RequestId {
>                 string nonce;           // IOR of client (unique via ORB)
>                 string reqSequence;     // request counter and/or timestamp
>         };

It would be preferable if the format of the request ID is implementation
specific and still provide interoperability.  This could be done in a
couple ways.  One is to use the NamingAuthority::QualifiedName.

I don't think we need to be quite so structured as either of these
though.  The RequestId only needs to be unique for the server.  The
server can return the RequestId as the return type from an asynchronous
request.  For example:

	typedef long RequestId;

	RequestId async_request( ... );

	void cancel_request( in RequestId request_id );


> CANCELLATION IMPLEMENTATION
>
> A server wishing to implement the cancelRequest() with more than a no-op
> would have to keep a table of each outstanding request thread ("worker
> thread") and its associated RequestId.  For a simple stateless server,
> killing an outstanding thread would suffice.  For a more complex server
> with resource allocation (e.g., a database session), the server would
> create a semaphore with cancellation information.  Worker threads would
> have responsibility to check the semaphore periodically, releasing
> resources and quitting if cancelled.

Good - This shows some thinking through the feasibility.  Of course it
is as we say 'implementation specific' and would not be in the spec.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard17.vcf"
X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 27 Apr 1998 17:33:34 -0700
To: Tim Brinson <tim@protocol.com>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS: general arg in parameter list
Cc: Larry Hamel <larryh@medgrid.philips.com>, coas@baptisthealth.net

At 01:53 PM 4/27/98 -0700, Tim Brinson wrote:
>Bob Glicksman wrote:
>>
>> Remember, as well, that not every query is at the patient level.  A query
>> for images most likely is at the study level; i.e. it is already known
>> (e.g. by reading the report) which study is of interest.
>
>As I understand it you are creating a separate (remote) object for the
>study that gets queried.  Is that correct?

Correct.  This separates order objects from report objects from image
objects, allowing for the legay situation where orders come from HIS,
reports come from RIS, and images come from PACS.  Of course, this is not a
requirement -- a single device can offer multiple objects.

>
>I was thinking that reports might also be separate interface objects.
>Their object references could get returned from the initial query to the
>base service.  Does this make any sense?

Yes - see above.  I foresee some sort of "order entry/tracking service"
which knows about orders (radiology and others) and can provide references
to a transcription/report repository service (for report status and/or
text) and an image access service (for images).  COAS provides a "parent"
mechanism for the latter two.  Specific IDL for these latter two services
will use COAS for general functions such as discovery, object movement,
etc.  COAS can also provide the patient --> ordering doctor --> order ID
relationships and queries, which can then be inherited by these more
specific services, e.g. to provide report lookup by ordering physician,
date, etc. and not just by study ID.

>
>
>Cheers,
>
>Tim
>Attachment Converted: "c:\eudora\attach\vcard5.vcf"
>
_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 27 Apr 1998 17:47:17 -0700
To: Tim Brinson <tim@protocol.com>, Larry Hamel <larryh@medgrid.philips.com>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS: general arg in parameter list
Cc: coas@baptisthealth.net

At 01:47 PM 4/27/98 -0700, Tim Brinson wrote:
>Larry Hamel wrote:
>> How can a client supply info like a report ID within a COAS request?
>>
>> The parameter list in the COBS prototype is fine when you can specify
>> observations with a patientID, a coded concept, a statistical filter, and a
>> time spec.
>
>The current COBS was designed to work for raw, independent
>observations.  The COAS needs to handle reports as well.  Should these
>be handled by different IDL?  What is the meta data in reports that
>could be filtered on (tags in XML, Keywords, indexed values)?  Should a
>report be a separate (remote) object similar to the Clinical Image
>Access Service (CIAS)?  Are reports structured after DICOM supplement
>23?  Can reports be just plain text?  Can reports be transfered as XML
>and/or OBV and/or MIME?  Are nursing notes treated as reports or are
>they a separate type?  Do we think COAS servers will typically contain
>only raw observations or (logical XOR) structured reports or (logical
>OR) they will normally have both?  What is our object/information model
>for reports?
>
>I figure the answers to questions like these may influence the direction
>of our COAS response.  I would think there are other types of queries a
>client would want to do with reports that they would not do with raw
>observations.

Please see my previous response to Tim's e-mail.  From the CORBAmed
perspective, there are currently activites underway to define an Image
Access Service (CIAS) and a transcription/report repository service (Tad is
drafting this RFP).  So, COAS should not preemt these but rather provide
common services which these can inherit.  One such common service could be
"return object" for those situations where the "client" is just a pipe and
doesn't care what kind of observation is being delt with (i.e. the
universal get() ).  Other common services might be discovery, reflection,
and query -- the latter relating patient, ordering physician, dates and
study ID.  This could return a study ID based on various other queries.
The study ID is then used to retireve a report or image or waveform or
...... via a more specific service (e.g. CIAS for image).

>
>
>> But what about a report repository, where a client would start out by
>> asking for a list of reports (meta information) about a given patient,
>> perhaps specified by a date range.   So far, so good for COBS.  But to
>> drill down to a particular report, the client must request a particular
>> report ID from the list.  Selecting a report only by date would run the
>> risk of ambiguity if 2 reports had the same timestamp.

See above.  I see COAS as providing the basic mechanisms for relating
patients, docs, dates, etc. to studies which have observations.  COAS
(because of the requirements) may also be defined to return specific
observation types (e.g. vital signs) and status' and is extended (by
inheritance) to add other observation types (e.g. images, reports, labs,
etc.).  COAS may also contain the "universal get()" where the "client", in
this case, is just a pipe and doesn't care about the object's actual type
(perhaps returns the object itself using OBV).

>>
>> Consider that most servers will be based on some kind of database which
>> relies on unique IDs, so this will be the natural way to request
>> observations.
>
>It does seem that reports may need to be given unique IDs but raw
>observations are likely not to need these.  The unique ID for a report
>could be of different forms:
>
>	An ID that is unique within that server
>
>	A globally unique ID
>
>	An IOR to a Report object
>
>	Possibly others
>

All DICOM images have globally unique IDs.  All observations of any time
should be able to be uniquely specificed by site, location, date/time and
local ID.

  >
>> Furthermore, some observations will require several bits of
>> specification (e.g., give me image 2 of imageSet 122 and use JPEG
>> compression and resolution 512 x 512).  Perhaps some of this info could be
>> squeezed into generalized filters, but it seems more intuitive to combine
>> observation-specific parameters into a single argument struct.
>
>The filters in COBS was tested for vital signs where pseudo-continuous
>data collection needs to be decimated, interpolated, etc.  We found that
>filters need to be more complex at times and speciallized to the type of
>data being accessed (as you point out).

The specific services (e.g. CIAS) which derive from COAS can add their own
filter types, appropriate to the data types they manage.  COAS needs only
specify filter types for the specific data types handled within COAS itself
and not a subclass of COAS.


>
>
>> So instead of a fixed "when" in the parameter list, consider a more general
>> argument.  Using Object-by-Value, a Base type can be subclassed to whatever
>> is necessary for the given request.  A prototype for the query function
>> would be something like
>>
>>         value Base getOBV(      in UserId userId,
>>                                 in PatientId    patientId,
>>                                 in RequestId    requestId,
>>                                 in CodedConcept reqCode,
>>                                 in value Base arg );
>>
>> where
>>         * UserID identifies the logged-in requesting person (security
discussion
>> forthcoming)
>
>This is not needed.  It is handled with CORBAsec.
>
>>         * PatientID identifies the patient
>
>Looks good.
>
>>         * RequestID for this specific client request (callback IOR +
sequence #;
>> discussion forthcoming)
>
>I'll respond to the forthcoming message on this topic but basically I
>think it gets in the way of synchronized access.
>
>>         * reqCode is the coded concept being requested
>
>Looks OK too.  Is this suppose to work for reports too?  I'm not sure if
>reports would be this simple.
>
>>         * arg is the extensible general-purpose argument
>
>I see an extensible filter like this being needed for some opertions.
>Of course we would also define some of extensions to be used.
>
>> In this prototype, the "when" time spec from COBS has been subsumed by the
>> general "arg" because time specs seems more applicable to vital-sign
>> servers than to most other scenarios.
>
>Not sure.  At some point as the query gets more and more general
>shouldn't we consider using constraint languages (like ODL and Trader)?
>
>
>Cheers,
>
>Tim
>Attachment Converted: "c:\eudora\attach\vcard7.vcf"
>
_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Date: Tue, 28 Apr 1998 00:31:03 -0400
From: Tad Davis <tad@careflow.com>
Organization: CareFlow|Net, Inc.
X-Mailer: Mozilla 4.04 [en] (Win95; I)
To: Bob Glicksman <bobg@medgrid.philips.com>
CC: Tim Brinson <tim@protocol.com>, Larry Hamel <larryh@medgrid.philips.com>,
        coas@baptisthealth.net
Subject: Re: COAS: general arg in parameter list

Tim,

Just wanted to backup Bob's response.  I am indeed drafting a "Report Management
Service" which will need to deal with all of the report issues you raise.
Eventually then, we hope to push a "Transcription/Dictation Workflow Service"
which will address support for the transcription/dictation process directly.  This
will more than likely cause waves from the Workflow group, but I see this
happening more and more as we continue to define these lower level building
blocks, such as PIDS, COAS, IAS, RMS, demographics, orders, etc. the need will
then become support for specific processes which use these lower level service in
a very specific ordered manner.  I must apologize that I have been fairly silent
on the COAS front, not from lack of opinion (between Juggy and I we've got plenty
of that), but simply lack of time.  Regardless, I agree completely with Bob's
suggestions that we not preempt these service but provide common functionality and
provide the framework these other services can build upon.  I would only differ
from Bob in the specifics, study id for example, I see as a fairly specific
attribute meant to support a specific function.  I would argue that it is not
generic to all clinical observations.  Also, physician should be more generic as
well, I would argue that a clinical observation generically has a recorder and an
observer (or some such terminology).  In terms of reports I am thinking the
transcriptionists and the dictator, in terms of lab results, I can think of the
person taking the reading, the person interpreting it.  These roles can then be
subclassed to specific terminology in the IAS, RMS and other sub-COAS services.
Wherever possible we should err on the side of generality and allow the
sub-services to define the specifics.  With this in mind it may be useful to
include in the COAS response a roadmap/implementation guide of sorts which
explains where we see the COAS fitting into the grand scheme of things and how
these sub-services that will continue to pop-up (I doubt images and reports is an
exhaustive list) should utilize the COAS in a consistent manner.

tad

> >I figure the answers to questions like these may influence the direction
> >of our COAS response.  I would think there are other types of queries a
> >client would want to do with reports that they would not do with raw
> >observations.
>
> Please see my previous response to Tim's e-mail.  From the CORBAmed
> perspective, there are currently activites underway to define an Image
> Access Service (CIAS) and a transcription/report repository service (Tad is
> drafting this RFP).  So, COAS should not preemt these but rather provide
> common services which these can inherit.  One such common service could be
> "return object" for those situations where the "client" is just a pipe and
> doesn't care what kind of observation is being delt with (i.e. the
> universal get() ).  Other common services might be discovery, reflection,
> and query -- the latter relating patient, ordering physician, dates and
> study ID.  This could return a study ID based on various other queries.
> The study ID is then used to retireve a report or image or waveform or
> ...... via a more specific service (e.g. CIAS for image).
>




Sender: tim@protocol.com
Date: Tue, 28 Apr 1998 11:08:15 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: cancellation of requests

Larry Hamel wrote:
>
> Tim,
>
> >
> >  I know ORBs typically have a request
> >timeout period and maybe a way for it to be called by a separate thread
> >too.
> >
>
> i see no interface for this in Visigenic nor Iona.  do you?  a TCP timeout
> is available as an initialization parameter.

I don't know about Visigenic but OrbixWeb has something that might work:

	IE.Iona.OrbixWeb.CORBA.Request.reset()

You can check with Iona but it seems that should send a CancelRequest
out as it resets the Request object.  That operation is OrbixWeb
specific.

I would suggest requesting a cancel() operation from each of the ORB
vendors since it seems like a usefull thing.  Even post a message to
issues@omg.org about it.  That will get them to consider standardizing
it in the Revision Task Force.  I believe it is a language mapping
issue.

I looked over the asynchronous messaging RFP response yesterday and it
does not seem to have a cancel either.  If this is important to you post
a message to orbos@omg.org requesting this operation is put into the
asynchronous messaging response.  Or contact the submitters directly
(they are listed in the submission).


> >> where UserId identifies the logged-in user for security purposes (separate
> >> discussion forthcoming) and where RequestId is discussed below.
> >
> >The UserId is passed as part of the Principle within the IIOP message.
> >It is not needed in the IDL.
> >
>
> using the principal is an alternative; would you support a standardization
> of the format for this userID in a principal?

I think they already have a standard format for it.  My guess the
Security Service spec is where that would be defined.  If you can't find
it post a messaeg to orbos@omg.org.


Regards,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard19.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 28 Apr 1998 15:29:18 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: getX/getY in addition to a generalized "get"

y'all,

Consider a specification that COAS servers publish "getX/getY" interfaces
along with the generalized interface which uses ConceptCodes to specify the
request.

In other words, a server would have both types of interface, such as:

	value Base get( ConceptCode c, ..., value Base arg );  // generalized

	X getX( ..., XArg arg);	// specific
	Y getY( ..., YArg arg);

PRO

* Designers get to choose the interface that best fits their goals.  They
can pick a general interface that accomodates all types, and will not
change as types evolve, or they can pick a getX interface that is fragile
to change, but may offer higher efficiency since there is no wrapping or
casting.  (In our experience, ANY wrapping was expensive!)

* With getX/getY exposed, the data model is explicitly defined in the IDL
of the server.  Otherwise, the data model may not be physically tied to the
IDL of the server.

* Generalized-get servers will often publish a getX/getY interface anyway,
in order to make implementation of the dispatch easy.  Why not mandate it?

* For a given ConceptCode, the client knows exactly where to look for the
types for return and argument values.  The attribute for the ConceptCode
for X itself would be listed in the IDL right next to the "XReturn" and
"XArg" structs.


CON (with attempts to answer)

"There are too many concepts to specify at once."
This is true for both "getX" and generalized-get.  The latter assumes a
data model for interoperability, which will be incomplete, given the large
number of potential concepts.   An incremental approach seems sensible.

"Servers can expose getX/getY if they choose, but don't mandate it."
This is an alternative, but a server which doesn't expose getX/getY will
not have its data model physically tied to the server interface.



thanks for the feedback,

larry

Sender: tim@protocol.com
Date: Tue, 28 Apr 1998 17:29:58 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: getX/getY in addition to a generalized "get"

Larry Hamel wrote:
>
> y'all,
>
> Consider a specification that COAS servers publish "getX/getY" interfaces
> along with the generalized interface which uses ConceptCodes to specify the
> request.
>
> In other words, a server would have both types of interface, such as:
>
>         value Base get( ConceptCode c, ..., value Base arg );  // generalized
>
>         X getX( ..., XArg arg); // specific
>         Y getY( ..., YArg arg);

For your getX/getY style have you considered a middle ground?  For
example I can not see any use of having a separate operation for each
ConceptCode but maybe for those that fall into certain classes.  In
other words I would not want to see operations like:
	get_heart_rate(),
	get_noninvasive_blood_pressure_systolic(),
	get_sa02(),
	get_ecg_II(),
	get_invasive_blood_pressure_waveform(),
	etc.

But I could see operations for the different types of observations:

	get_measurement( in ConceptCode c, ... ),
	get_waveform( in ConceptCode c, ... ),
	get_events( in ConceptCode c, ... ),
	get_images( in ConceptCode c, ... ),
	get_notes( in ConceptCode c, ... ),
	etc.

In fact these might all be on separate interfaces.  Notice you still
have to pass in the ConceptCode.  Maybe this is what you meant anyway
but forgot the ConceptCode in your example.  Please show an actual
example of what X and Y are in your mind.  Are they really codes or are
they different data types?


> PRO
>
> * Designers get to choose the interface that best fits their goals.  They
> can pick a general interface that accomodates all types, and will not
> change as types evolve, or they can pick a getX interface that is fragile
> to change, but may offer higher efficiency since there is no wrapping or
> casting.  (In our experience, ANY wrapping was expensive!)

I don't think you would have to use wrapping int he case I just
presented.


> * With getX/getY exposed, the data model is explicitly defined in the IDL
> of the server.  Otherwise, the data model may not be physically tied to the
> IDL of the server.

I think in the above presented IDL the data model would become explicate
to some degree.


> * Generalized-get servers will often publish a getX/getY interface anyway,
> in order to make implementation of the dispatch easy.  Why not mandate it?

I don't think many servers would actually have an internal get for each
possible ConceptCode they support.  I know ours would not.  They may for
each basic type of data though.

Take a look at the LOINC codes for example.  They not only have codes
for blood pressure but different codes for different techniques of
measuring blood pressure and from different points on the body - tens to
hundreds of codes just for blood pressures.  If someone wanted to create
operations for each of these they can always do that.  Since their use
is so speciallized I don't understand why we should create a standard
for them though.

Coding systems are so large and complex I don't think we should be
duplicating all that work done by professionals in this area.  There are
also many coding schemes that use different classifications.  Which one
would we chose to represent heart rate (as an example)?  Coding systems
change over time as well.  How do we keep up with their changes?  By
using ConceptCodes these decisions are independent of the IDL.


> * For a given ConceptCode, the client knows exactly where to look for the
> types for return and argument values.  The attribute for the ConceptCode
> for X itself would be listed in the IDL right next to the "XReturn" and
> "XArg" structs.

This also applies to the IDL I presented above.


> CON (with attempts to answer)
>
> "There are too many concepts to specify at once."
> This is true for both "getX" and generalized-get.  The latter assumes a
> data model for interoperability, which will be incomplete, given the large
> number of potential concepts.   An incremental approach seems sensible.

The generalized get and the IDL I present above breaks observations into
different data types as opposed to trying to individually address each
medical concept with special IDL.  These are scalable but having special
IDL for each medical concept is neither scalable nor manageable.


> "Servers can expose getX/getY if they choose, but don't mandate it."
> This is an alternative, but a server which doesn't expose getX/getY will
> not have its data model physically tied to the server interface.

When you describe it this way it does sound like you are refering to X
and Y being different data types as opposed to different ConceptCodes.
Or are you suggesting the data model also shows the relationships
between the coded concepts like a terminology service exposes?


I'm just trying to get our thinking lined up here.  I suspect we are
using the same terms for different things and different terms for the
same thing.  In PIDS it took us a while to get our terminology
synchronized so we could all communicate.  I expect we will be doing the
same here.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard20.vcf"
Date: Wed, 29 Apr 1998 00:01:46 -0400
From: "Eric Butler" <ericb@baptisthealth.net>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net
Subject: Re: COAS: getX/getY in addition to a generalized "get"

see inline comments...

Tim Brinson wrote:

> Larry Hamel wrote:
> >
> > y'all,
> >
> > Consider a specification that COAS servers publish "getX/getY" interfaces
> > along with the generalized interface which uses ConceptCodes to specify the
> > request.
> >
> > In other words, a server would have both types of interface, such as:
> >
> >         value Base get( ConceptCode c, ..., value Base arg );  // generalized
> >
> >         X getX( ..., XArg arg); // specific
> >         Y getY( ..., YArg arg);
>
> For your getX/getY style have you considered a middle ground?  For
> example I can not see any use of having a separate operation for each
> ConceptCode but maybe for those that fall into certain classes.  In
> other words I would not want to see operations like:
>         get_heart_rate(),
>         get_noninvasive_blood_pressure_systolic(),
>         get_sa02(),
>         get_ecg_II(),
>         get_invasive_blood_pressure_waveform(),
>         etc.
>
> But I could see operations for the different types of observations:
>
>         get_measurement( in ConceptCode c, ... ),
>         get_waveform( in ConceptCode c, ... ),
>         get_events( in ConceptCode c, ... ),
>         get_images( in ConceptCode c, ... ),
>         get_notes( in ConceptCode c, ... ),
>         etc.

I support this idea for the reason that it fits well with a specification that
describes 'conformance classes' which can be seen in PIDS and other specs as well.
This provides logical grouping of operations that can be seen to be connected with
specific types of systems that will have CORBA interfaces.  E.g., Protocol would
implement a 'waveform conformance class'  which consisted of all the operations
relating to waveforms.  As operations become more fine grained and also have
alternate methods of performing the same functionality the number of permutations
of conformance classes becomes unmanageable.  Interopablilty may suffer as a client
will be challenged to discover the available operations implemented by a server
rather than 'knowing' that if a server supports a particular conformance class,
certain operations will be available for use.

My understanding of coas is that it is to provide a framework for access to
clinical observations...the who/when/what as Tim says.  Additionally it will
provide a default set of observation types which is what each co-submitter is
proposing here.  These observations types could also be done seperately from COAS
as is the case of Clinical Imaging and Transcription. This would provide
implementors of new COAS observation types a core set of functionality upon which
they can build.  These services would include
    basic mechanisms for identifying the observation of interest (study id, time
period, order number)
    patterns for designing interfaces to access these observations.
        eg get_x (where x = {waveform, notes, image})
    "negotiating the return type" (maybe this is not part of this rfp but it
definately related)

Also, my $.02 on operation granularity

There is a lot of space between
    get ( in ConceptCode c ) and
    get_ecg_II ()

The date model/semantics of the operations need to exist somewhere.  They can be
(implicit) in the operation name or can be described by text in the specification
or somewhere in between.  It seems to be common that specs end up being in the
middle as this balances the technology/performance issues with purist OO design.

> In fact these might all be on separate interfaces.  Notice you still
> have to pass in the ConceptCode.  Maybe this is what you meant anyway
> but forgot the ConceptCode in your example.  Please show an actual
> example of what X and Y are in your mind.  Are they really codes or are
> they different data types?
>
>
> > PRO
> >
> > * Designers get to choose the interface that best fits their goals.  They
> > can pick a general interface that accomodates all types, and will not
> > change as types evolve, or they can pick a getX interface that is fragile
> > to change, but may offer higher efficiency since there is no wrapping or
> > casting.  (In our experience, ANY wrapping was expensive!)
>
> I don't think you would have to use wrapping int he case I just
> presented.
>
> > * With getX/getY exposed, the data model is explicitly defined in the IDL
> > of the server.  Otherwise, the data model may not be physically tied to the
> > IDL of the server.
>
> I think in the above presented IDL the data model would become explicate
> to some degree.
>
> > * Generalized-get servers will often publish a getX/getY interface anyway,
> > in order to make implementation of the dispatch easy.  Why not mandate it?
>
> I don't think many servers would actually have an internal get for each
> possible ConceptCode they support.  I know ours would not.  They may for
> each basic type of data though.
>
> Take a look at the LOINC codes for example.  They not only have codes
> for blood pressure but different codes for different techniques of
> measuring blood pressure and from different points on the body - tens to
> hundreds of codes just for blood pressures.  If someone wanted to create
> operations for each of these they can always do that.  Since their use
> is so speciallized I don't understand why we should create a standard
> for them though.
>
> Coding systems are so large and complex I don't think we should be
> duplicating all that work done by professionals in this area.  There are
> also many coding schemes that use different classifications.  Which one
> would we chose to represent heart rate (as an example)?  Coding systems
> change over time as well.  How do we keep up with their changes?  By
> using ConceptCodes these decisions are independent of the IDL.
>
> > * For a given ConceptCode, the client knows exactly where to look for the
> > types for return and argument values.  The attribute for the ConceptCode
> > for X itself would be listed in the IDL right next to the "XReturn" and
> > "XArg" structs.
>
> This also applies to the IDL I presented above.
>
> > CON (with attempts to answer)
> >
> > "There are too many concepts to specify at once."
> > This is true for both "getX" and generalized-get.  The latter assumes a
> > data model for interoperability, which will be incomplete, given the large
> > number of potential concepts.   An incremental approach seems sensible.
>
> The generalized get and the IDL I present above breaks observations into
> different data types as opposed to trying to individually address each
> medical concept with special IDL.  These are scalable but having special
> IDL for each medical concept is neither scalable nor manageable.
>
> > "Servers can expose getX/getY if they choose, but don't mandate it."
> > This is an alternative, but a server which doesn't expose getX/getY will
> > not have its data model physically tied to the server interface.
>
> When you describe it this way it does sound like you are refering to X
> and Y being different data types as opposed to different ConceptCodes.
> Or are you suggesting the data model also shows the relationships
> between the coded concepts like a terminology service exposes?
>
> I'm just trying to get our thinking lined up here.  I suspect we are
> using the same terms for different things and different terms for the
> same thing.  In PIDS it took us a while to get our terminology
> synchronized so we could all communicate.  I expect we will be doing the
> same here.
>
> Cheers,
>
> Tim
>
>   ------------------------------------------------------------------------
>
>   Tim Brinson <tim@protocol.com>
>   Systems Software Lead
>   Protocol Systems, Inc.
>
>   Tim Brinson
>   Systems Software Lead    <tim@protocol.com>
>   Protocol Systems, Inc.   HTML Mail
>   8500 SW Creekside Place  Work: 503 526 4392
>   Beaverton                Fax: 503 526 4200
>   Oregon                   Netscape Conference Address
>   97008-7107               Netscape Conference DLS Server
>   USA
>   [Image]
>   Additional Information:
>   Last Name     Brinson
>   First Name    Tim
>   Version       2.1



--
----------------------------------------------------
Eric Butler  EricB@BaptistHealth.Net
Senior Systems Architect
Baptist Health Systems of South Florida
----------------------------------------------------



X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 28 Apr 1998 21:02:15 -0700
To: Larry Hamel <larryh@medgrid.philips.com>, coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS: getX/getY in addition to a generalized "get"

Another CON -- there are now TWO sets of standards to maintain (the cocepts
as codes and as IDL)!  A burden, but I still kinda like the idea of choise.

At 03:29 PM 4/28/98 -0700, Larry Hamel wrote:
>y'all,
>
>Consider a specification that COAS servers publish "getX/getY" interfaces
>along with the generalized interface which uses ConceptCodes to specify the
>request.
>
>In other words, a server would have both types of interface, such as:
>
>	value Base get( ConceptCode c, ..., value Base arg );  // generalized
>
>	X getX( ..., XArg arg);	// specific
>	Y getY( ..., YArg arg);
>
>PRO
>
>* Designers get to choose the interface that best fits their goals.  They
>can pick a general interface that accomodates all types, and will not
>change as types evolve, or they can pick a getX interface that is fragile
>to change, but may offer higher efficiency since there is no wrapping or
>casting.  (In our experience, ANY wrapping was expensive!)
>
>* With getX/getY exposed, the data model is explicitly defined in the IDL
>of the server.  Otherwise, the data model may not be physically tied to the
>IDL of the server.
>
>* Generalized-get servers will often publish a getX/getY interface anyway,
>in order to make implementation of the dispatch easy.  Why not mandate it?
>
>* For a given ConceptCode, the client knows exactly where to look for the
>types for return and argument values.  The attribute for the ConceptCode
>for X itself would be listed in the IDL right next to the "XReturn" and
>"XArg" structs.
>
>
>CON (with attempts to answer)
>
>"There are too many concepts to specify at once."
>This is true for both "getX" and generalized-get.  The latter assumes a
>data model for interoperability, which will be incomplete, given the large
>number of potential concepts.   An incremental approach seems sensible.
>
>"Servers can expose getX/getY if they choose, but don't mandate it."
>This is an alternative, but a server which doesn't expose getX/getY will
>not have its data model physically tied to the server interface.
>
>
>
>thanks for the feedback,
>
>larry
>
>
_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

From: Bart Degreef <degreef@medgrid.philips.com>
Date: Wed, 29 Apr 1998 11:29:00 -0700 (PDT)
To: coas@baptisthealth.net
Subject: Re: "Any" overhead measurements
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid

Hi Dave,

 > At:
 > http://www.kav.cas.cz/~buble/corba/comp/test/through/concl.html
 >
 > "Encapsulating an argument within any adds a substantial overhead. Hence, when passing an
 > array or a sequence of anys, the invocation time primarily depends on the number of anys.
 > For 1024 anys of octets, relative invocation times are omniORB 100% (146 00us), VisiBroker
 > 420%, Orbix 2800%."
 >
 > Is this consistent with the observations people have reported with Any?

Interesting. A while ago I ran some test to get an idea of Any's
overhead. I modified the (VisiBroker) Bank example to transfer an
array of bytes via an Any or directly. You can try for yourself, see
attachment.

Today I repeated them with the following results (jdk1.1.6, vbj 3.2).

    For each run the Client requests the Server a number of bytes,
    split in chunks of 128*128*2 (e.g., typical size for a particular
    kind of medical images). Other chunk sizes can be passed as argument.
    The default is a Megabyte; other sizes can be passed as argument.
    In all cases, the measured results are averages of ten runs.

    Start the server with:

	    vbj Server

    To run a test with Any do:

	    vbj -Dany=true Client

    To run without Any just do:

	    vbj Client


    With these programs I ran tests on Ultra-1 Sparcs:

        Single host (e.g., no real network traffic):

	    Any:   38 KB/s	without Any: 2744 KB/s  (72)

        Between two Ultra1 Sparcs via 10Mb/s (switched) Ethernet:

	    Any:   38 KB/s	without Any:  877 KB/s  (23)

        Between two servers, connected via 100 Mb/s FastEthernet
        (an Ultra-2 (Server) and an Ultra-Enterprise (Client)):

	    Any:   62 KB/s      without Any: 2896 KB/s  (46)


    Reducing the chunk size to 1024 bytes I got:

        Single host (e.g., no real network traffic):

	    Any:   34 KB/s	without Any:  328 KB/s  (10)

        Between two Ultra1 Sparcs via 10Mb/s (switched) Ethernet:

	    Any:   33 KB/s	without Any:  216 KB/s  (7)

        Between two servers, connected via 100 Mb/s FastEthernet
        (an Ultra-2 (Server) and an Ultra-Enterprise (Client)):

	    Any:   48 KB/s      without Any:  480 KB/s  (10)


    [vbj -version:
     VisiBroker Developer for Java [03.02.00.C2.05] (FEB 18 1998 19:52:02)
     Java: Version 1.1.6 from Sun Microsystems Inc.
     OS:   Solaris version 2.x; CPU: sparc]

We suspect that the fact that the insert and extract methods use
unbuffered streams (which are far less efficient than buffered ones,
see also the Orfali book in the chapter on sockets) is the main cause
of the performance loss using Anys (Anies?).

Cheers,

Bart de Greef


Attachment Converted: "c:\program files\eudora\attach\AnyPerfTest.tar1.gz"

--
+-------------------------------------------------------------------+
| Bart L. de Greef                      Philips Medical Systems     |
| degreef@medgrid.philips.com           Sr. Member Technical Staff  |
| Phone     : +1 650 426 2557           Fax : +1 650 426 2550       |
| Snail mail: Philips Medical Systems,                              |
|             2171 Landings Drive, Mountain View CA 94043-0837, USA |
+-------------------------------------------------------------------+
    "Experience is the name everyone gives to their mistakes."
Sender: tim@protocol.com
Date: Wed, 29 Apr 1998 11:30:06 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: David Forslund <dwf@lanl.gov>
CC: coas@baptisthealth.net
Subject: Re: "Any" overhead measurements

David Forslund wrote:
>
> At:
> http://www.kav.cas.cz/~buble/corba/comp/test/through/concl.html
>
> "Encapsulating an argument within any adds a substantial overhead. Hence, when passing an
> array or a sequence of anys, the invocation time primarily depends on the number of anys.
> For 1024 anys of octets, relative invocation times are omniORB 100% (146 00us), VisiBroker
> 420%, Orbix 2800%."
>
> Is this consistent with the observations people have reported with Any?
>
> Dave

Thanx Dave, I checked it out.  I noticed they used old versions of
IONA's and Visigenic's C++ orbs.  On:

	http://www.kav.cas.cz/~buble/corba/comp/test/through/

It says:

> Please note: Orbix2.2c01 and VisiBroker for C++ 3.0 (which were
> evaluated) are not the latest versions of IONA's and Borland's
> ORBs, and do not reflect the performance of the current versions.

I have heard from multiple sources (orb vendors and AB members) that
some orbs (at the time I took it they meant Orbix and Visi.) did not
know how to handle 'anys' efficiently.  I also heard from these same
people that during the IDL->Java mapping the other orb vendors taught
them the way to do it.  This was critical since in the java mapping they
also standardized the interface between the stubs and the orb library.

Last summer (during PIDS development as this same issue came up) I heard
a key person in IONA say they have fixed the any problem in OrbixWeb and
we should not let the efficiency of anys hold us up.  From what he
didn't say made me think that Orbix (C++) was not fixed (at least at
that time).

Hope this helps.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard22.vcf"
Sender: tim@protocol.com
Date: Wed, 29 Apr 1998 13:47:36 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: coas@baptisthealth.net,
        Fabiane Bizinella Nardon <fabiane.nardon@hcnet.usp.br>
Subject: [Fwd: COAS list]

Eric,

Please add Fabiane to the COAS mail list.

Thanx,


-------------------------------------------------------------

Fabiane,

Should we also add Sao Paulo Hospital das Clinicas as a supporter to
COAS?


Regards,

TimReturn-Path: <fabiane.nardon@hcnet.usp.br>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id NAA09781; Wed, 29 Apr 1998 13:29:22 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id NAA25992; Wed, 29 Apr 1998 13:29:20 -0700
Received: from vibora.hcnet.usp.br(143.107.176.6) by iwall via smap (V2.0)
	id xma025974; Wed, 29 Apr 98 13:28:52 -0700
Received: from [143.107.176.66] by vibora.hcnet.usp.br; (5.65v3.2/1.1.8.2/01Oct96-0633PM)
	id AA29336; Wed, 29 Apr 1998 17:28:33 -0300
Message-Id: <3.0.5.32.19980429173043.0079dd80@vibora.hcnet.usp.br>
X-Sender: fbnardon@vibora.hcnet.usp.br
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 29 Apr 1998 17:30:43 -0300
To: tim@protocol.com
From: Fabiane Bizinella Nardon <fabiane.nardon@hcnet.usp.br>
Subject: COAS list
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"



Hi Tim,

How are you ?

I was talking to Beatriz Leao about COAS and she told me that you have a
mail list about it. Can I subscribe this list ? I'm very interested in COAS.

By the way, I changed job and I'm working in Sao Paulo now, at Hospital das
Clinicas, with Lincoln.

Best wishes,

Fabiane.

-----------------------------------------------
Fabiane Bizinella Nardon, MSc.
University of Sao Paulo Medical School Hospital
Av. Dr. Ovidio Pires de Campos, 225
05403.010 Sao Paulo, SP, BRAZIL
Phone: 55 11 3069-7104 - Fax: 55 11 280.0867
http://www.hcnet.usp.br/
e-mail: fabiane.nardon@hcnet.usp.br
-----------------------------------------------

Attachment Converted: "c:\program files\eudora\attach\vcard23.vcf"
Sender: tim@protocol.com
Date: Wed, 29 Apr 1998 16:42:35 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: Enterprise Java Beans / CORBA proposal]

Larry,

It looks like there have been some changes that Dave and I were not
aware of.  This issue deserves a thread on the CORBA security mail
list.  I don't know how they expect to pass user information now.  It
looks like Jishnu is implying there might be a Service Context for the
Security Service, but I'm not sure.

TimReturn-Path: <jis@fpk.hp.com>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id OAA17370; Wed, 29 Apr 1998 14:37:03 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id OAA28275; Wed, 29 Apr 1998 14:36:29 -0700
Received: from emerald.omg.org(192.67.184.65) by iwall via smap (V2.0)
	id xma028272; Wed, 29 Apr 98 14:36:25 -0700
Received: from palrel1.hp.com by emerald (SMI-8.6/SMI-SVR4)
	id QAA06304; Wed, 29 Apr 1998 16:52:04 -0400
Received: from sleepy.fpk.hp.com (sleepy.fpk.hp.com [15.73.10.16])
	by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id NAA24372;
	Wed, 29 Apr 1998 13:45:53 -0700 (PDT)
Received: from fpk.hp.com (atlm0116.atl.hp.com) by sleepy.fpk.hp.com with ESMTP
	(1.39.111.2/16.2+CNS 4.0 ) id AA197002749; Wed, 29 Apr 1998 16:45:49 -0400
Message-Id: <354790A6.97B4716A@fpk.hp.com>
Date: Wed, 29 Apr 1998 16:42:15 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Reply-To: jis@fpk.hp.com
Organization: Hewlett-Packard New Jersey Laboratories
X-Mailer: Mozilla 4.03 [en] (Win95; I)
Mime-Version: 1.0
To: Andrew Watson <andrew@omg.org>
Cc: ab@omg.org
Subject: Re: Enterprise Java Beans / CORBA proposal
References: <v03130307b16cc65b909a@[202.135.13.115]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Andrew Watson wrote:

> Good Evening,
>
> Javasoft has recently published version 1.0 of an Enterprise Java Beans /
> CORBA mapping specification:
>
>      ftp://ftp.javasoft.com/docs/ejb/ejb-corba.10.pdf
>
> Javasoft is soliciting comments from interested parties; I'd encourage
> everyone with an interest in CORBA to respond (the address is on the
> specification).

Did a quick skim through it. Noticed one glaring error on Page 15, Section 6
first bullet "plain IIOP" where it talks of the client identity being the
CORBA::Principal. Effective CORBA 2.3 there is no CORBA Principal in GIOP
Request header, so the proposed scheme does not work. Even before that there
was no standardized representation of CORBA::Principal so there is no way of
making this work in an interoperable way.

If EJB reaquires the carrying of a identity in plain IIOP it should go about
it by getting OMG to define a Service Context for EJB and carry the EJB
identity in it.

Jishnu.
jis@fpk.hp.com


Attachment Converted: "c:\program files\eudora\attach\vcard24.vcf"
Sender: tim@protocol.com
Date: Wed, 29 Apr 1998 16:51:16 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: jis@fpk.hp.com, secsig@omg.org, COAS <coas@baptisthealth.net>
Subject: Re: Enterprise Java Beans / CORBA proposal

Jishnu Mukerji wrote:
> Did a quick skim through it. Noticed one glaring error on Page 15, Section 6
> first bullet "plain IIOP" where it talks of the client identity being the
> CORBA::Principal. Effective CORBA 2.3 there is no CORBA Principal in GIOP
> Request header, so the proposed scheme does not work. Even before that there
> was no standardized representation of CORBA::Principal so there is no way of
> making this work in an interoperable way.

Jishnu (or some else), could you please explain how user (client)
information (identity) is passed.  This issue came up in a discussion
among submitters to a CORBAmed RFP.  Some of us thought the Principle
was the way to get the client identity to the server in operation calls
so we don't have to pass a UserId as a parameter in the IDL.

So the real question is do we need to pass the UserId as a parameter or
is there some other way of getting it.  My guess is that there is some
other way but wanted the experts to respond to the people requesting
such a capability.


> If EJB reaquires the carrying of a identity in plain IIOP it should go about
> it by getting OMG to define a Service Context for EJB and carry the EJB
> identity in it.

Is there a CORBA Security Service Context?  Is that how the information
is transmitted in IIOP?


Thanx,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard25.vcf"
Date: Thu, 30 Apr 1998 10:49:43 -0600
From: David Forslund <dwf@acl.lanl.gov>
To: coas@baptisthealth.net
Subject: Re: IDL
Reply-To: "David W. Forslund" <dwf@lanl.gov>

I assume everyone received the two sets of IDL I sent out.  The mailer
on my PC handles dates differently than others, and may not show my
email as being current, and thus may dissappear off of you stack.  If
you haven't seen it, please let me know.

Thanks,

Dave Forslund

X-Sender: ejs@relay.ba.tis.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 30 Apr 1998 12:03:41 -0700
To: Tim Brinson <tim@protocol.com>, jis@fpk.hp.com, secsig@omg.org,
        COAS <coas@baptisthealth.net>
From: John Sebes <ejs@tis.com>
Subject: Re: Enterprise Java Beans / CORBA proposal


Tim,

Your note boils down to three related questions:

At 04:51 PM 4/29/98 -0700, Tim Brinson wrote:
>please explain how user (client)
>information (identity) is passed.

>So the real question is do we need to pass the UserId as a parameter or
>is there some other way of getting it.

>Is there a CORBA Security Service Context?  Is that how the information
>is transmitted in IIOP?

Briefly, the answers are: transport of client ID data is performed by CORBA
security mechanisms. One does not need to pass user IDs as parameters, and
even if one did, there would still be the authentication issue.
Authentication functionality is part of the CORBA security mechanism for
transporting client ID. There is no CORBA Security Service Context in IIOP
per se, because the context data is carried as part of a security protocol
for IIOP-- either SSL or SecIOP.

As an example of how such things are done today, consider a typical
IIOP/SSL implementation. There is no identity or authentication data in
IIOP at all. The SSL session setup protocol includes authentication and
exchange of digital certificates that include identity information.
Security-aware applications can obtain client identity information either:
(a) via CORBAsec interfaces for accessing the "Current" object, or (b)
proprietary or ORB-specific interfaces for accessing data in X.509
certificates passed via SSL.

This should answer your questions with respect to mechanisms. However,
there are several open issues for actually using these mechanisms, for
example: availability of FSP from ORB vendors, implementation of CORBAsec,
SSL, and/or SecIOP; integration/bundling of public-key infrastructure
elements (e.g. certificate management); facilities for trust management in
certificate evaluation (how can you control which certificates you actually
believe?)

In summary, the mechanisms exist, but may not be available in FSP, and in
any case require some careful thought for safe and effective use.


E. John Sebes
-----------------
Trusted Information Systems, Inc.
444 Castro Street, Suite 800
Mountain View, CA 94041
650/962-8885 x 3003
ejs@ba.tis.com

Sender: tim@protocol.com
Date: Thu, 30 Apr 1998 17:40:49 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COBS Revision 0.3 Avaliable

I have updated the COBS spec to utilize patient identifiers and concept
codes from the adopted PIDS and LQS specs.  Yuo can find the spec and
the new IDL at:

	http://www.protocol.com/engineering/corbamed/coas/

Tomorrow we will try to get some descriptions of our issues and use
scenerios out.  Hope other will do the same.  Thanx Tad for the ones you
already sent - well done!

Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard27.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 30 Apr 1998 17:44:40 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: prefetch

y'all,

Consider a prefetch function for the COAS server.  Prefetch() would
typically be called when a caregiver first selected a patient from a list,
or perhaps when some logic triggered a call from the patient schedule for
the day.

COAS servers receiving this courtesy notice could choose to prefetch
patient data into caches, for increased performance.

For example, an image service could acquire any recent images for this
patient and prepare images for transmission to this particular client, all
in advance of any specific request.

>From a "middleware" perspective, prefetch() is useful for non-image
information also.  Anywhere in the chain of "pipes" between data source and
its presentation, caching may be used to increase performance.   Prefetch()
supports caching.

The interface could be something like:

		//
		// preFetch is a courtesy notification to server
		//
		oneway void prefetch(
			in UserId	userId,	// may be in security context
			in PersonId	patientId );


Let me know what you think.

larry

X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 01 May 1998 10:31:45 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: event mechanism

y'all,

How will clients receive "pushed" information from COAS servers?

The CosEvent Service seems a good place to start, where servers can supply
events, clients can consume events, and the event channel handles
distribution and decouples the client and server.  With the introduction of
the Notification Service, channels can also filter events during
distribution, assuming the events are "structured" with some name/value
attributes in the header.

As goals for a COAS event mechanism, consider the following:

* Compatibility: define the interface so that CosEvent service references
are allowed, but a Notification references may be passed (a Notification
channel subclasses a CosEvent channel).

* Testability:  the event mechanism needs some test convention since real
events can cause state changes in servers (persistence).  Furthermore,
clients need to know if a firewall prevents callbacks.  With a test
function, clients send a test event to themselves (this could be noisy if
the channel doesn't support filtering to one client, but we are assuming a
Notification channel in the 80% case).

* Scalability:  the design should account for case where many presentation
clients want to receive filtered events from a single server, as well as
case where one middleware server wants all events from a backend server.

* Minimize client responsibility: if we assume that the server both creates
the channel and continuously supplies events, things get easier.  We can
dispense with requests to start/stop the supply of events, and the
responsibility for channel creation is squarely on the shoulders of the
server.

Consider the following IDL for a COAS server.

	//
	// list of ConceptCodes which can be subscribed for
	//
	readonly attribute ConceptCodeSeq 	subscribable;


	//
	// return reference of existing channel for
	// "reqCode" type of events, creating channel if necessary,
	// throwing exception if not possible or unsupported code
	//
	CosEventChannelAdmin::EventChannel   getChannel(
		in UserId		userId,
		in ConceptCode	reqCode );

	//
	// push a test event of standard type into channel, with userID in
	// structure (filtered to one recipient if Notification service)
	//
	void pushTestEvent( in UserId userId );


where
	* userId identifies user (in sec. context? discussion ongoing)
	* exceptions are omitted for brevity
	* structure of "test" event is omitted for brevity
	* clients type-check (narrow) at runtime to determine whether a
getChannel() reference is a Notification channel, and subscribe accordingly.

Note that one channel may be used for all types of events, which is
appropriate if clients can subscribe with filters.

An alternative to the getChannel() call would be for a client to find the
channel via a Trader (indexed by server & ConceptCode).  However, the
server has the responsibility to maintain the list of pairs (channels,
ConceptCode), and keeping this list exposed in a Trader seems to offer
unneeded transparency at the cost of added complexity.


MORE FLEXIBILITY?

What if we decide that servers should not be solely responsible for channel
creation?  For example, what if a middleware server wishes that a backend
server use a particular channel?  Or a separate entity was the "channel
manager"?   We could supply a setChannel() function:

	//
	// if channel is new, server starts pushing
	// events of type "reqCode" into this channel
	// if channel is same as existing AND reqCode is new,
	// start pushing reqCode events
	// if channel already exists for reqCode events, throw exception
	//
	void setChannel(
		in UserId			userId,
		in ConceptCode		reqCode,
		in CosEventChannelAdmin::EventChannel channel );


At this point, I think setChannel() is not required, assuming the 80% case
is  where the server instantiates a channel at startup and continuously
supplies events thereafter.  In a pinch, a server B could call another
server via A.getChannel() in order to reuse the channel from A, assuming A
had been initialized first.

Let me know what you think.

larry

Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426 2550

From: David Forslund <dwf@lanl.gov>
Date: Tue Apr 28 22:18:23 1998
To: coas@baptisthealth.net
Subject: "Any" overhead measurements
X-Mailer: Pronto97 E-Mail [ver 4.01]

At:
http://www.kav.cas.cz/~buble/corba/comp/test/through/concl.html

"Encapsulating an argument within any adds a substantial overhead. Hence, when passing an
array or a sequence of anys, the invocation time primarily depends on the number of anys.
For 1024 anys of octets, relative invocation times are omniORB 100% (146 00us), VisiBroker
420%, Orbix 2800%."

Is this consistent with the observations people have reported with Any?

Dave

From: David Forslund <dwf@lanl.gov>
Date: Tue Apr 28 18:03:54 1998
To: larryh@medgrid.philips.com, coas@baptisthealth.net
Subject: Re: COAS: getX/getY in addition to a generalized "get"
X-Mailer: Pronto97 E-Mail [ver 4.01]

> y'all,
>
> Consider a specification that COAS servers publish "getX/getY" interfaces
> along with the generalized interface which uses ConceptCodes to specify the
> request.
>
> In other words, a server would have both types of interface, such as:
>
>       value Base get( ConceptCode c, ..., value Base arg );  // generalized
>
>       X getX( ..., XArg arg); // specific
>       Y getY( ..., YArg arg);
>
> PRO
>
> * Designers get to choose the interface that best fits their goals.  They
> can pick a general interface that accomodates all types, and will not
> change as types evolve, or they can pick a getX interface that is fragile
> to change, but may offer higher efficiency since there is no wrapping or
> casting.  (In our experience, ANY wrapping was expensive!)

I hate to have a design that is driven by the performance of a single component from a
vendor that is known to be deficient.  I think others have demonstrated that the overhead
of Any isn't necessarily large.  If it is, how do we know that OBV won't be equally
expensive?
>
> * With getX/getY exposed, the data model is explicitly defined in the IDL
> of the server.  Otherwise, the data model may not be physically tied to the
> IDL of the server.
>
> * Generalized-get servers will often publish a getX/getY interface anyway,
> in order to make implementation of the dispatch easy.  Why not mandate it?
>
> * For a given ConceptCode, the client knows exactly where to look for the
> types for return and argument values.  The attribute for the ConceptCode
> for X itself would be listed in the IDL right next to the "XReturn" and
> "XArg" structs.

Nested objects need to be dealt with, so that only some of the data is brought over,
unless more is needed.  Interfaces have worked well for this.
>
>
> CON (with attempts to answer)
>
> "There are too many concepts to specify at once."
> This is true for both "getX" and generalized-get.  The latter assumes a
> data model for interoperability, which will be incomplete, given the large
> number of potential concepts.   An incremental approach seems sensible.
>
> "Servers can expose getX/getY if they choose, but don't mandate it."
> This is an alternative, but a server which doesn't expose getX/getY will
> not have its data model physically tied to the server interface.
>
>
>
> thanks for the feedback,
>
> larry

Dave

From: David Forslund <dwf@lanl.gov>
Date: Thu Apr 30 21:45:16 1998
To: larryh@medgrid.philips.com, coas@baptisthealth.net
Subject: Re: COAS: prefetch
X-Mailer: Pronto97 E-Mail [ver 4.01]

I think this is a good idea, but I wonder if some additional information isn't needed such
as suggested duration of the prefetch (in other words, when this hint expires).  Other
constraints such as the time period over which observations should be prefetched could be
useful, too.

Dave

> y'all,
>
> Consider a prefetch function for the COAS server.  Prefetch() would
> typically be called when a caregiver first selected a patient from a list,
> or perhaps when some logic triggered a call from the patient schedule for
> the day.
>
> COAS servers receiving this courtesy notice could choose to prefetch
> patient data into caches, for increased performance.
>
> For example, an image service could acquire any recent images for this
> patient and prepare images for transmission to this particular client, all
> in advance of any specific request.
>
> >From a "middleware" perspective, prefetch() is useful for non-image
> information also.  Anywhere in the chain of "pipes" between data source and
> its presentation, caching may be used to increase performance.   Prefetch()
> supports caching.
>
> The interface could be something like:
>
>               //
>               // preFetch is a courtesy notification to server
>               //
>               oneway void prefetch(
>                       in UserId       userId, // may be in security context
>                       in PersonId     patientId );
>
>
> Let me know what you think.
>
> larry

From: David Forslund <dwf@lanl.gov>
Date: Mon May 04 16:32:58 1998
To: degreef@medgrid.philips.com, tim@protocol.com
Subject: Re: COAS: userID in parameter list?
Cc: coas@baptisthealth.net
X-Mailer: Pronto97 E-Mail [ver 4.01]

> Hi Tim,
>
>  > > Like Larry, I think it would not be good to make COAS dependent on the
>  > > presence of a security layer (How was the issue of client
>  > > identity/security handled in the PIDS?).
>  >
>  > I think we would be going up against a big battle if we are not careful
>  > how we do this.  We are to be extending the OMA.  The OMG expects us to
>  > extend it not duplicate capability that already exists.  The AB is the
>  > overseer of this.
>
> Just to clarify myself: I do agree that security is an orthogonal
> issue for COAS as well -- Larry and my concern here is that we don't
> want to have a COAS that mandates the presence of a security layer.
> If people want to have security, then by all means via CORBASec,
> SECIOP etc. Our impression was that piggybacking the userID on a
> security protocol might inadvertently make the presence of such a
> layer mandatory for the proper functioning of COAS.
>
> Cheers,
>
> Bart.

The identification of the user via elements such as the prinicpal, can be done even
without security, if you want (just not very rigorously).  The presence of userid in the
IDL is redundant and can lead to the confusion you describe above.

Dave

From: David Forslund <dwf@lanl.gov>
Date: Mon May 04 16:30:31 1998
To: tim@protocol.com, degreef@medgrid.philips.com
Subject: Re: COAS: userID in parameter list?
Cc: coas@baptisthealth.net
X-Mailer: Pronto97 E-Mail [ver 4.01]

To throw in my two cents, we now have some experience implementing security with CORBA. We
have the IDL I sent out earlier (with no specification of userid), working with security
under CORBA.  We have added some additional features, too, but they aren't relevant to the
security question.  We basically have an authentication server that does a public/private
key exchange to identify the individual and an access level specified by an additional
(fully encrypted) password.  When the individual then tries to connect to a server (both
PIDS and our MedLib), the server verifies through the authenticator that the person is who
they say they are (currently through the prinicpal, although this will evolve as the CORBA
spec evolves).  We would have no use for the userid (especially if it isn't encrypted) if
it were in the IDL.  The procedure we are using is consistent with CORBAsecurity but is
being done while we await a Java Corba Security implementation.  However, it has NO impact
on the IDL, and only on some implementation code on the server (and some on the client to
create public keys, cipher objects, etc.) I'll be talking about this at the DOCSEC'98
meeting in Baltmore this week.  We are still testing what we've done, but believe that it
is about as secure as you can do at this point.  Obviously key management and managing
security on the server itself are important issues in the overall security of the system.
We can use either software key encryption or hardware encryption (via the iButton from
Dallas Semiconductor).

So I'm strongly in favor of not including any specific security elements into the COAS
spec, with the exception of providing proper separation of interfaces so that when
security is added, it makes sense.  This was the philosophy used in PIDS, and I believe it
is basically correct.  We may get some corrections to this coming in from the Security RFP
we have issued, but we can take those into account at the time.

Dave

> Bart de Greef wrote:
> > Like Larry, I think it would not be good to make COAS dependent on the
> > presence of a security layer (How was the issue of client
> > identity/security handled in the PIDS?).
>
> I think we would be going up against a big battle if we are not careful
> how we do this.  We are to be extending the OMA.  The OMG expects us to
> extend it not duplicate capability that already exists.  The AB is the
> overseer of this.
>
> In PIDS, security was one of the most discussed issues among the
> submitters starting way before the Initial Submission.  Every time it
> came up the concensus was that it is an orthogonal concern.  There is a
> good section in the PIDS appendix that describes how to use CORBAsec
> with PIDS.  It was written by someone that makes his living from
> consulting on Security matters (many related to CORBA), Polar Humenn.
>
> We had some people envolved with PIDS that had deep security
> backgrounds.  It sounds like we should see if we can get them involved
> here.
>
>
> Now with all that said I think there is a problem with the current state
> of the art - it is not widely implemented.  The Secure IIOP spec was
> suppose to create a base for out of the box interoperability but I don't
> know if it really does.  We really need people with CORBA security
> background involved such as Polar Humenn, Wayne Wilson, Fred Druseikis,
> or other CORBAsec people.  Can anyone talk to these people to get them
> involved?
>
> Cheers,
>
> Tim

From: David Forslund <dwf@lanl.gov>
Date: Mon May 04 22:48:28 1998
To: larryh@medgrid.philips.com, coas@baptisthealth.net
Subject: Re: COAS: userID in parameter list?
X-Mailer: Pronto97 E-Mail [ver 4.01]

> y'all,
>
> Omitting the UserID from the COAS parameter list would be elegant, but
> raises some questions with regard to certificates in a security layer:
>
> * COAS dependence on security layer?
> * multi-tier identification?
> * user info available from existing certificate server?
>
> First, if userID is only in the security layer like SSL, will every COAS
> server require a security layer in order to pass userID?   What about
> institutions where certain COAS servers, behind a firewall, are rated
> "secure enough" for the institution's security policy?  For these backend
> servers, removing an encryption layer might offer higher performance.  But
> encryption is different than access control.  Institutions are not likely
> to forego access control for sensitive data even if they trust that the
> communication between servers does not require encryption.

This is fairly straightforward. We have example implementations demonstrating ways of
doing this.   I think this is a common situation. I think it should be easy to control
encryption between the client and server to facilitate tradeoffs between performance and
security.  We have found that the "Any" approach allows selected encryption to be added in
a simple manner.

>
> Second, what about COAS servers involved in a multi-tier system?  How will
> the client's userID be transmitted between remote layers, if each layer has
> its own certificate?
>
> For example, consider a 3-tier system, where a GUI client queries some
> middleware COAS server, which in turn call as backend server:
>
>       GUI client --> middleware --> backend
>
> Say a client with userID = "Dr. Smith" requests an observation from a
> middleware COAS server.  This middleware server can decode the client
> certificate into "Dr. Smith", but the link between the middleware and the
> backend server is secure, with its own certificate (userID = "Middle").  So
> the middleware requests the observation from the backend, and the backend
> decodes the certificate as "Middle" rather than "Dr. Smith".  The backend
> server cannot do access control in this scenario.

The middleware should be "transparent" in this scenario.  That is it has to provide a
mapping between the GUI client and the user on the backend.   Since the middleware can
determine who the user is via principal or something similar in CORBA, this isn't hard to
implement, although the mapping could become complex, if the granularity of the data on
the client is different from the backend.
>
> Third, do certificate servers have a function which translates between
> certificate and userID, something like "getUserFromCertificate()"?   Is
> this available now?  How will this perform, if each observation request in
> each tier must access this function?

Absolutely.  We do this to validate the user and cache the user data for performance so
the call doesn't have to be done for every method call from every client.  In addition,
the server can impose some additional policy on top of this.  This only invoves a single
method on the server which calls the security service functions.
>
> I'm not familiar with security layers and certificates, so perhaps these
> questions are easily put to rest.  Thanks in advance for your answers.
>
> larry

Thanks,

Dave



From: David Forslund <dwf@lanl.gov>
Date: Tue Apr 28 22:05:20 1998
To: coas@baptisthealth.net
Subject: Earlier IDL
X-Mailer: Pronto97 E-Mail [ver 4.01]

Attached is another set of IDL for our earlier version of TeleMed.  It actually has a
richer of set observations than the one I sent out earlier today, although not everything
was implemented.

It has a flavor of the the get_X that has been discussed, at least for some of the
observations.

Dave
Attachment Converted: "c:\program files\eudora\attach\idl.zip"
From: David Forslund <dwf@lanl.gov>
Date: Tue Apr 28 16:26:50 1998
To: coas@baptisthealth.net
Subject: TeleMed IDL
X-Mailer: Pronto97 E-Mail [ver 4.01]

Here is the IDL for our version of TeleMed from last fall.  It supports some simple report
management and the concept of ImageStudies and ImageSeries.

It supports the ability to add data as well as read it, has some flaws that we know about,
and has some connections to one of the early PIDS versions.

So with these caveats, I hope it can help in reaching agreement on a COAS submission.  I
think it is highly complementary to the COBS IDL.



David Forslund                        Voice:(505) 665-1907
Advanced Computing Laboratory         FAX: (505) 665-4939
MS B287                               EMAIL: dwf@lanl.gov
Los Alamos National Laboratory        WWW: http://www.acl.lanl.gov/~dwf
Los Alamos, NM 87545
Attachment Converted: "c:\program files\eudora\attach\medtraits.idl"
From: David Forslund <dwf@lanl.gov>
Date: Tue Jun 02 22:46:33 1998
To: tim@protocol.com, coas@baptisthealth.net
Subject: Re: Response to COAS Submission Draft 3.1
Cc: R.M.Dixon@comhealth.hull.ac.uk
X-Mailer: Pronto97 E-Mail [ver 4.01]

Here is an RTF version of Dixon's document.  Perhaps this is more readable by others?

Dave
Attachment Converted: "c:\program files\eudora\attach\gehr.rtf"
X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 01 May 1998 10:48:45 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Submitter's teleconference notes
Cc: medgrid-list@medgrid.philips.com

A teleconference was held on Tuesday, 28 April, 1998.  The following people
were in attendance:

- Tad Davis (CareFlow|Net, Inc.)
- Henry Ware (CareFlow|Net, Inc.)
- V. Juggy Jaggannathan (CareFlow|Net, Inc.)
- Eric Butler (BHSSF)
- Tom Culpepper (3M)
- Dave Foard (Sunquest)
- Tim Brinson (Protocol Systems)
- Chris (Protocol Systems)
- David Forslund (Los Alamos National Lab)
- Larry Hamel (Philips Medical Systems)
- Chuck Carman (Philips Medical Systems)
- Mary Kratz (University of Michigan) [joined us for part of the discussion
  from the HL7 meetings in Baltimore]

1. The group discussed what we were looking for from a COAS.
  -- we agreed to share "use senarios" to seed our seach for common
     functionality (we agreed to contribute these as soon as possible)
  -- divide the COAS into components, using PIDS, LQS, and Trader as examples
  -- provide at least one generalized query that supports the use of contraint
     language similar to the Trader service
  -- provide the ability to register for / subscribe to published clinical
     observations (primarily physiologic measurements?)
  -- [and the complement] provide the ability to publish clinical observations
     when they occur / at some specified event

2. Mary moved the discussion to comparing and contrasting HL7/XML and
CORBA/IDL
   in preparation for a presentation she was going to make to the HL7 SIG on
   XML the next day.
  -- HL7 provides a very good clinical data model
  -- XML provides a useful data storage format that enables
    ** display format customization (using style sheets)
    ** data mining
    ** interoperability in data semantics (via the data model)
  -- CORBA provides a rich set of distributed system services
  -- IDL provides a useful means of specifying (service) object interfaces
    ** grouping and encapsulation of related data
    ** definition of functions / methods that can operate / transform the data
  Summary: XML is an interoperable data container, IDL defines interoperable
    processing of the data.  [I welcome corrections to this discussion, as I
    am not completely up to speed on XML or IDL yet.]

3. The publishers of issues to the COAS e-mail list were asked to give
   a brief description of each issue, with some discussion following.
   (I will not try to summarize this discussion as an action point from the
    teleconference call was that the originator of each issue would write
    a paragraph to be included in the initial submission, and be posted to
    this mailing list.)

4. Gap between new OMG standards and usable implementations
  -- In our discussion on OBV, the fear was raised that, although it would
     be ideal to base our COAS submission on the latest OMG standards, we
     would most likely not be able to make a working implementation of our
     proposed IDL because the ORB venders may not support the most recent
     OMG standards, such as OBV, the Notification Service, passing the
     UserID via the CORBA Security Service, particularily for the non-Java
     language bindings.
  -- one proposed solution, at least for OBV, was to design for OBV, but
     implement using Any for the moment.

5. Miscelaneous
  -- Tad Davis mentioned that they had almost finished their Report
     Management Service RFP to CORBAmed.  He promissed to submit it to the
     COAS mailing-list when it was completed.
  -- It was mentioned that BOCA had just passed the OMG approval process,
     and that HBOC was likely to submit a COAS proposal with a CDL/BOCA flavor

6. Next Steps
  -- Chuck Carman agreed to collate and wrap the groups contributions to the
     initial submission, as Philips appeared to be the only one needing the
     long lead time before the submission due date.
  -- Most of the group agreed to share their IDL to contribute to the
     proposal, several members had to deal with Intellectual Property issues
     first.
  -- Submitters of issues were asked to submit one paragraph descriptions /
     discussions of their issues for the initial submission.
  -- David Forslund volunteered to share the TeleMed IDL they developed
     last year, which included some support for images and reports.
  -- We agreed to hold another teleconference call on Tuesday, May 12, 1998
     at 1:00 pm PDT (4:00 pm EDT).  Philips will set this up.

Chuck Carman
MedGRiD Program
Philips Medical Systems
2171 Landings Drive
Mountain View, CA 94043
ccarman@medgrid.philips.com


X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 01 May 1998 10:48:45 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Submitter's teleconference notes
Cc: medgrid-list@medgrid.philips.com

A teleconference was held on Tuesday, 28 April, 1998.  The following people
were in attendance:

- Tad Davis (CareFlow|Net, Inc.)
- Henry Ware (CareFlow|Net, Inc.)
- V. Juggy Jaggannathan (CareFlow|Net, Inc.)
- Eric Butler (BHSSF)
- Tom Culpepper (3M)
- Dave Foard (Sunquest)
- Tim Brinson (Protocol Systems)
- Chris (Protocol Systems)
- David Forslund (Los Alamos National Lab)
- Larry Hamel (Philips Medical Systems)
- Chuck Carman (Philips Medical Systems)
- Mary Kratz (University of Michigan) [joined us for part of the discussion
  from the HL7 meetings in Baltimore]

1. The group discussed what we were looking for from a COAS.
  -- we agreed to share "use senarios" to seed our seach for common
     functionality (we agreed to contribute these as soon as possible)
  -- divide the COAS into components, using PIDS, LQS, and Trader as examples
  -- provide at least one generalized query that supports the use of contraint
     language similar to the Trader service
  -- provide the ability to register for / subscribe to published clinical
     observations (primarily physiologic measurements?)
  -- [and the complement] provide the ability to publish clinical observations
     when they occur / at some specified event

2. Mary moved the discussion to comparing and contrasting HL7/XML and
CORBA/IDL
   in preparation for a presentation she was going to make to the HL7 SIG on
   XML the next day.
  -- HL7 provides a very good clinical data model
  -- XML provides a useful data storage format that enables
    ** display format customization (using style sheets)
    ** data mining
    ** interoperability in data semantics (via the data model)
  -- CORBA provides a rich set of distributed system services
  -- IDL provides a useful means of specifying (service) object interfaces
    ** grouping and encapsulation of related data
    ** definition of functions / methods that can operate / transform the data
  Summary: XML is an interoperable data container, IDL defines interoperable
    processing of the data.  [I welcome corrections to this discussion, as I
    am not completely up to speed on XML or IDL yet.]

3. The publishers of issues to the COAS e-mail list were asked to give
   a brief description of each issue, with some discussion following.
   (I will not try to summarize this discussion as an action point from the
    teleconference call was that the originator of each issue would write
    a paragraph to be included in the initial submission, and be posted to
    this mailing list.)

4. Gap between new OMG standards and usable implementations
  -- In our discussion on OBV, the fear was raised that, although it would
     be ideal to base our COAS submission on the latest OMG standards, we
     would most likely not be able to make a working implementation of our
     proposed IDL because the ORB venders may not support the most recent
     OMG standards, such as OBV, the Notification Service, passing the
     UserID via the CORBA Security Service, particularily for the non-Java
     language bindings.
  -- one proposed solution, at least for OBV, was to design for OBV, but
     implement using Any for the moment.

5. Miscelaneous
  -- Tad Davis mentioned that they had almost finished their Report
     Management Service RFP to CORBAmed.  He promissed to submit it to the
     COAS mailing-list when it was completed.
  -- It was mentioned that BOCA had just passed the OMG approval process,
     and that HBOC was likely to submit a COAS proposal with a CDL/BOCA flavor

6. Next Steps
  -- Chuck Carman agreed to collate and wrap the groups contributions to the
     initial submission, as Philips appeared to be the only one needing the
     long lead time before the submission due date.
  -- Most of the group agreed to share their IDL to contribute to the
     proposal, several members had to deal with Intellectual Property issues
     first.
  -- Submitters of issues were asked to submit one paragraph descriptions /
     discussions of their issues for the initial submission.
  -- David Forslund volunteered to share the TeleMed IDL they developed
     last year, which included some support for images and reports.
  -- We agreed to hold another teleconference call on Tuesday, May 12, 1998
     at 1:00 pm PDT (4:00 pm EDT).  Philips will set this up.

Chuck Carman
MedGRiD Program
Philips Medical Systems
2171 Landings Drive
Mountain View, CA 94043
ccarman@medgrid.philips.com


Sender: tim@protocol.com
Date: Fri, 01 May 1998 12:42:47 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Issues

I have started writing up some of the COAS issues we discussed on the
conference call.  I have to work on something else for a while so
thought I would send out what I have now, in case it helps Philips out
as they are collating information for the COAS pre-submission.  See the
attached text file.

I will try to complete it later on today.  Your comments and suggestions
are welcome.


Cheers,

TimCOAS Issues for Discussion
==========================

There are a number of issues to be considered in developing the COAS
specification.  The submitters on this proposal come from different
backgrounds and are working to integrate our different perspectives
into a flexible framework that affords interoperability.  The
submitters are just starting the consensus process on many of these
issues which will be developed over time.

The issues invlove things like:

	previous experiences with observations and with distributed
	objects;

	integrating information models;

	utilizing newer OMG technologies;

	remote access mechanisms;

	providing a basis for future CORBAmed work;


Previous Work
-------------

A number of the submitters and supporters of this proposal have used
CORBA for various observations access mechanisms.

	Philips Medical - Observations are a major component of the
	Miracle project.

	Los Alamos National Laboratory - Observations are a major
	component of the the Telemed project.

	CERC - Observations are part of the Artemis project.

	CareFlow|Net - Observations are part of a transcription system.

	Protocol Systems - An observation service (COBS) is the major
	component of the Acuity Communications Option (ACO) vital signs
	server.

Each of these projects bring different perspectives which will effect
the COAS specification.


Information Model
-----------------

There are a number of information models that deal with observations
data.  Some are associated with standards groups and openly available.
Others are the proprietary property of individual companies.

	HL7 - The version 3.0 project is taking the knowledge developed
	during the previous HL7 standards and describing it in an
	information model.  This is a generalized model for healthcare
	that does includes observations data.  This model is subject to
	change over the next year or two.

	DICOM - The Structured Reporting document (supplement 23) of DICOM
	contains an implied information model for clinical reports which
	contain observations data.

	UK NHS - The UK National Health Service has developed a general
	information model for healthcare called COSMO.  It contains
	observations data.


Objects By Value
----------------

CDL & BOCA
----------

Dynamic Discovery
-----------------

Value Domains
-------------

Type Negotiation
----------------

Simple vs Structured
--------------------

XML Usage
---------

Use Scenerios
-------------

Access Mechanisms
-----------------

The variety of systems that may need to implement COAS have widely
differing requirements for the patterns of access.  For this reason
there needs to be multiple interfaces with different responsibilities
and ways of accessing information from a server.

To handle the wide variety of servers each needs to be able to only
implement those interfaces that it needs.  Each interface needs to be
optional.


Conformance
-----------

Since each server may implement a different combination of interfaces
it may be difficult for clients to seamlessly interoperate with
multiple servers.  There should be multiple conformance classes for
COAS where each mandates a certain set of interfaces that must be
implemented.  Each server could implement the conformance classes that
makes sense to it.

This pattern was also used by the Trader Service, Person
Identification Service, and Lexicon Query Service.


Componentization
----------------

In order to manage the optional interfaces that a COAS server
implements a base component should be utilized that indicates which
interfaces have been implemented.  The component must also have a
mechanism to traverse to those interfaces that are implemented.

This pattern has been used by the Trader Service, Person
Identification Service, and Lexicon Query Service.  Other component
architectures have existed such as in COM/OLE and Java Beans.  The OMG
is in the process of defining a standard component model which is
expected to be finished in the summer of 1998.  The COAS proposal will
consider that OMG Component Model if it becomes standardized within
time.


Constraint Languages
--------------------

One of the generalized mechanisms being considered for this COAS
proposal uses constraints that are specified by a client in the
queries.  A separate interface should be used for queries based on
constraints.  A server should be able to determine what constraint
language(s) it supports and these should be exposed for a client to
find out.

The flexibility for a server to support the constraint languages it
needs should be balanced with the need for interoperability.  A
default constraint language should be mandatory for some particular
conformance class.

This pattern was also used by the Trader Service, Notification
Service, and Lexicon Query Service.


Publish/Subscribe
-----------------

One of the mechanisms for accessing observations needed is for clients
to subscribe to certain observations to be pushed to them when certain
events occur, such as when they become available.  The client needs to
be able to be notified of the event as well as having certain data
delivered with the notification.

The Notification Service provides a flexible mechanism for a separate
service that handles delivering events.  COAS servers should be able
to use a Notification Service to deliver events.

The Notification Service specification does not contain a mechanism
for event filters to be applied at the source (original supplier) of
the event.  This capability is needed for sources that publish a large
number of events where very few are subscribed to.


Scope of Observations
---------------------

Roadmap for Extentions
----------------------


Attachment Converted: "c:\program files\eudora\attach\vcard28.vcf"
To: Tim Brinson <tim@protocol.com>
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS Issues
Cc:
Bcc:
X-Attachments:
In-Reply-To: <354A25B7.59545040@protocol.com>
References:

Tim,

Thanks for the nicely formated issue list and explanations.  One item caught my eye:

>The Notification Service specification does not contain a mechanism
>for event filters to be applied at the source (original supplier) of
>the event.  This capability is needed for sources that publish a large
>number of events where very few are subscribed to.
>


see pg 64 of .pdf for Notification, section 2.6.2 Subscription Change

Suppliers may also discover the current set of event types that consumers of a channel require by calling the obtain_subscription_types operation on the ProxyConsumer interface.


Looks like the Notification service does it all :-)

larrySender: tim@protocol.com
Date: Fri, 01 May 1998 14:43:17 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: prefetch

Larry Hamel wrote:
> COAS servers receiving this courtesy notice could choose to prefetch
> patient data into caches, for increased performance.

Seems like a useful capability.  Another way to control this could be
with something similar to the Identity interface in PIDS.  Something
like:

	interface CoasIdentity {  // Or what ever you want to call it.
		readonly attribute QualifiedPersonId id;

		MeasureValue get_measurements( ... );
		ImageValue get_images( ... );
		ReportValue get_reports( ... );
		// etc.

		void done();
	};

	CoasIdentity get_identity( in PersonId id );

The CoasIdentity instance returned corresponds to exactly one patient -
the one passed in.  The prefetching can be done at that time.  The
done() operation sort of ends the session and can be useful if the
actual object is temporary or permanent.

While this pattern can be used for prefetching it is also useful for
other things as well.  That way a separate prefetch() operation is not
needed.  The prefetching itself is a server side issue that gets
encapsulated.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard29.vcf"
Sender: tim@protocol.com
Date: Fri, 01 May 1998 16:51:05 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS Issues

Larry,

First I would like to commend you on the depth you are working on these
issues.  It is great to have someone else with substantial thought on
the subject to brainstorm ideas.  I am learning quite a bit about the
kinds of problems you are dealing with.  We have some in common and
others that are different.

Sometimes if I respond too quickly to ideas I reread them and see how
they may be taken different then intended.  I hope no offense is taken -
it definitely is not meant.  I enjoy very much having these discussions
and coming up with solutions that meet everyone's needs.  That seems to
be a big part of the battle - understanding what each of our needs are.


> Looks like the Notification service does it all :-)

Not for some scenerios we have.  The Notification Service has both type
based and content based filtering.  Only the former can be done at the
source.

The other problem is that the ProxyConsumer is on the channel.  There
are times when we need some (but definitely not all) of those
capabilities at the end points.  We also have scenerios where the
subscription of events would NOT go through a channel and others when it
should.

What we have worked on before is a way to use as much as we can from the
Notification Service but provide these other capabilities.  For example
making the channel transparent to the connection set up and tear down
process.  That way a channel could be used in the implementation but is
not required.

I will post a response to your message about this subject and include
the IDL we developed.  There is quite a bit of it.  Maybe we could have
a phone call to discuss.  I'm not saying it is the way to go though.  I
have tried many other styles for events too.  Each has pros and cons.

Have a good weekend.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard31.vcf"
Sender: tim@protocol.com
Date: Fri, 01 May 1998 18:51:30 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Issues

I have finished the first cut at describing the COAS issues I have
brought up.  They are included as an attachment.


Cheers,

TimCOAS Issues for Discussion
==========================

There are a number of issues to be considered in developing the COAS
specification.  The submitters on this proposal come from different
backgrounds and are working to integrate our different perspectives
into a flexible framework that affords interoperability.  The
submitters are just starting the consensus process on many of these
issues which will be developed over time.

The issues invlove things like:

	Previous experiences with observations and with distributed
	objects;

	Integrating information models;

	Utilizing newer OMG technologies;

	Remote access mechanisms;

	Providing a basis for future CORBAmed work;


Previous Work
-------------

A number of the submitters and supporters of this proposal have used
CORBA for various observations access mechanisms.

	Philips Medical - Observations are a major component of the
	Miracle project.

	Los Alamos National Laboratory - Observations are a major
	component of the the Telemed project.

	CERC - Observations are part of the Artemis project.

	CareFlow|Net - Observations are part of a transcription system.

	Protocol Systems - An observation service (COBS) is the major
	component of the Acuity Communications Option (ACO) vital signs
	server.

Each of these projects bring different perspectives which will effect
the COAS specification.


Information Model
-----------------

There are a number of information models that deal with observations
data.  Some are associated with standards groups and openly available.
Others are the proprietary property of individual companies.  The
following lists the openly available information models that we know
of including observations data.

	HL7 - The version 3.0 project is taking the knowledge developed
	during the previous HL7 standards and describing it in an
	information model.  This is a generalized model for healthcare
	that does includes observations data.  This model is subject to
	change over the next year or two.

	DICOM - The Structured Reporting document (supplement 23) of DICOM
	contains an implied information model for clinical reports which
	contain observations data.

	UK NHS - The UK National Health Service has developed a general
	information model for healthcare called COSMOS.  It contains
	observations data.


Objects By Value (OBV)
----------------

The OBV capabilities are a recent addition to CORBA that have some
very desireable features for COAS.  Being able to pass data as objects
provides a major improvement to defining services that can be extended
in the future.

We expect that OBV will be used for many of the data types passed into
operations and returned from operations.  Since OBV is a new OMG
specification it may be difficult to find tools that support it.
Early prototypes of COAS will likely need to define the data that gets
passed as structured types and pass these as an 'any' type in
operations, until appropriate tools are obtained.

Since OBV is a new OMG technology we have not had a chance to discover
the patterns of usage that are appropriate for particular scenerios.
During the development of the COAS specification it is expected that
OBV related IDL is subject to change as we discover these patterns.


BOCA & CDL
----------

The Buisness Object Component Architecture (BOCA) is in the process of
being adopted as an OMG spec.  It also includes an extention to IDL
call the Component Definition Language (CDL).

There is interest in defining COAS such that it can be used as a stand
alone service and also as a buisness object compatible with the BOCA.
Since this is new ground it will take some experimentation to
determine the way to accomplish this.


Dynamic Discovery
-----------------

Clinical observations covers a very wide set of data and types of
systems that deal with them.  Servers are likely to have widely
different kinds of data they handle, data formats supported, etc.
COAS servers need to expose to clients meta information, such as the
patient population they deal with, the time window observations are
available for, what kinds of observation types are supported, what
kind of data formats are supported, which interfaces are implemented
etc.

By using dynamic discovery of capabilities interoperability can be
determined at run by smart clients.


Value Domains
-------------

The Lexicon Query Service (LQS) contains the ability to query for
Value Domains.  Value Doamins are the set of possible codes that can
be used for a particular parameter or field.  It is expected the LQS
Value Domains can be used by COAS for publishing meta information
about the particular service implementation.


Type Negotiation
----------------

Servers may support multiple formats for the same type of information
such as images in gif, tiff, and jpeg.  COAS may need a way for
clients to not only determine what formats are supported but also
select which one(s) the server is to use.


Simple vs Structured
--------------------

Clinical observations can be as simple as just a Heart Rate reading or
as complicated as a multimedia report.  COAS needs to be able to
handle both of these extremes and anything in between.

Accessing raw (simple) observations may have filters based on the
existence of the observation and/or the content/value of the
observation.  Accessing reports are likely to need filtering by
selected contents (plural) of the report as well as the report's
existence.  Querying for reports may need to be done where only parts
of the report is returned or the whole report is returned.


XML Usage
---------

The Extended Markup Language (XML) is gaining wide support as a
flexible format for describing highly structured information
(documents).  HL7 is looking into using XML as a format for heathcare
content including observations data.  Tools are being developed for
XML and popular web browsers are expected to support XML shortly.

Some people are using XML on the server side and others on the client
side.  On the server side XML data bases are being developed for
storing XML documents.  Advances in XML data bases are expected as
they are becoming popular.  XML is being used on the client side
similar to web pages being displayed in web browsers.  Since XML is a
more general form than HTML style sheets are used to map XML contents
into different user views.

While some COAS clients and servers may also deal with XML it is not
clear if it needs to be defined in the COAS IDL.  XML based COAS
servers could translate XML contents into IDL and the clients could
translate recieved IDL from a server back to XML (if it needs to).
Alternatively XML could be one format for clinical observations to be
transfered between COAS clients and servers.


Use Scenerios
-------------

Clinical observations may be used by many kinds of systems and for
many purposes.  Use scenerios need to be compiled to understand the
wide variety of patterns of usage.  From this understanding the
different mechanisms for accessing observations via COAS will be
defined.


Access Mechanisms
-----------------

The variety of systems that may need to implement COAS have widely
differing requirements for the patterns of access.  For this reason
there needs to be multiple interfaces with different responsibilities
and ways of accessing information from a server.

To handle the wide variety of servers each needs to be able to only
implement those interfaces that it needs.  Each interface needs to be
optional.


Conformance
-----------

Since each server may implement a different combination of interfaces
it may be difficult for clients to seamlessly interoperate with
multiple servers.  There should be multiple conformance classes for
COAS where each mandates a certain set of interfaces that must be
implemented.  Each server could implement the conformance classes that
makes sense to it.

This pattern was also used by the Trader Service, Person
Identification Service, and Lexicon Query Service.


Componentization
----------------

In order to manage the optional interfaces that a COAS server
implements a base component should be utilized that indicates which
interfaces have been implemented.  The component must also have a
mechanism to traverse to those interfaces that are implemented.  This
pattern has been used by the Trader Service, Person Identification
Service, and Lexicon Query Service.

Other component architectures have existed such as in COM/OLE and Java
Beans.  The OMG is in the process of defining a standard component
model which is expected to be finished in the summer of 1998.  The
COAS proposal will consider that OMG Component Model if it becomes
standardized within time.


Constraint Languages
--------------------

One of the generalized mechanisms being considered for this COAS
proposal uses constraints that are specified by a client in the
queries.  A separate interface should be used for queries based on
constraints.  A server should be able to determine what constraint
language(s) it supports and these should be exposed for a client to
find out.

The flexibility for a server to support the constraint languages it
needs should be balanced with the need for interoperability.  A
default constraint language should be mandatory for some particular
conformance class.

This pattern was also used by the Trader Service, Notification
Service, and Lexicon Query Service.


Publish/Subscribe
-----------------

One of the mechanisms for accessing observations needed is for clients
to subscribe to certain observations to be pushed to them when certain
events occur, such as when they become available.  The client needs to
be able to be notified of the event as well as having certain data
delivered with the notification.

The Notification Service provides a flexible mechanism for a separate
service that handles delivering events.  COAS servers should be able
to use a Notification Service to deliver events.  Some COAS clients
and servers may need to have events delivered directly without going
through a separate service.  For this reason the Notification Channel
should be transparent to the subscription process.

The Notification Service specification does not contain a mechanism
for event filters to be applied at the source (original supplier) of
the event.  The capability to filter at the source is needed for
sources that publish a large number of events where very few are
subscribed to.


Scope of Observations
---------------------

Observations can be a lot of things.  We need to determine the scope
of observations that COAS deals with and how to handle them.  For
example:

	There are subjective and objective observations (from the SOAP
	process);

	There are simple (raw) observations and structured reports;

	There are observations from devices such as monitors and MRI
	machines but also observations from an Electronic Medical Record
	that have been reviewed and confirmed by a healthcare
	professional.

	The characterization of observations (e.g. patient, provider,
	time, data) could also be applied to interventions.


Roadmap for Extentions
----------------------

COAS needs to provide a basis for future CORBAmed standards.  The COAS
RFP does require some data definitions but it is expected that future
CORBAmed RFPs will continue to fill in other data types that can be
used by COAS or will be extensions to COAS.

There are people currently drafting RFPs for a Clinical Image Access
Service (CIAS) and a Report Management Service (RMS).  These are
expected to utilize COAS and/or extend it.  Potential responders to
the CIAS and RMS RFPs are involved with this COAS submission which
should help craft COAS as a basis for these services.


Attachment Converted: "c:\program files\eudora\attach\vcard33.vcf"
Sender: tim@protocol.com
Date: Mon, 04 May 1998 11:34:48 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Use Scenerios - Protocol

See them attached - Cheers, TimVital Signs Use Scenerios
=========================


Nurse Station
-------------

A Nurse is doing his charting on a Clinical Information System (CIS).
The CIS collects vital signs from the vital signs server (patient
monitoring system) every minute.

The CIS polls the vital signs server every minute for the most
representative vital signs values (median filter) over the last
minute.  This data is cached up for 24 hours for immediate access by
the Nursing staff.  Because this polling is done so often it is
important the calls are efficient.  For example it should only require
a single call to acquire the data for all vital signs on all 16
patients in that unit.

The CIS also has the ability to show waveforms from the patient.
Instead of storing the high volume of waveform data for the 24 hours
it only requests them when a Nurse wants to view them.

The Nursing staff sometimes want to see the very latest vital signs
values where as the stored data on the CIS is only one value per
minute and at any time the last shown coul dbe as much as 1 minute
old.  The CIS provides a function for the Nurse to request the very
latest data.  The CIS polls the vital signs server but asks for the
very latest data available for each vital sign as long as it is no
older then 15 seconds.  The Nurse verifies these values with the
monitoring system display and enters them into the patient record with
a simple button push.


Doctor Office
-------------

A Doctor has multiple patients admitted to a hospital and needs to
make her rounds every day.  Before going to the hospital she wants to
review the patients condition over the last day.

A local application (or a web browser is used to download an applet)
connects up to the hospital intranet and queries the vital signs
server for for a 24 hour trend on the first patient.  The trend is a
sampling of the vital signs numerics (heart rate, blood pressure,
etc.) the 24 hours.  Since the vital signs may be collected
continuously with changes on the order of every second or two
(60*60*24=86400 samples per vital sign) it would take a long time to
download.  Instead the client application askes for only one sample
every 5 minutes (12*24=288 samples) since the trend display area is
only 288 pixels wide.  A median filter is requested over each 5 minute
period so that the most representive value is returned.

The Doctor notices a sudden drop in the blood pressure around 3:00 am
and zooms in around that time.  The application changes to a 30 minute
view and does another query to the vital signs server.  This time it
asks for a trend over the 30 minutes with a resolution of 5 seconds.

The Doctor wants to see what the ECG and blood pressure waveforms are
doing during this time and changes views.  The cursor was set at
3:05:20 am.  When the Doctor changed to the waveform view the
application queried the vital signs server for the waveforms around
3:05:20, requesting 20 seconds before through 20 seconds after that
point in time.  It centers the waveform on the sreen which shows a
window of 10 seconds for each waveform.

After scrolling through the waveform the Doctor notices a short
arrhythmia starting at 3:05:43.  The doctor uses the application to
see when other arrhythmias might have occurred through out the night
and sees a half dozen others.

She looks a couple to make sure they really are problems and decides
to put this patient high on her list to visit first during her rounds.


Remote Monitoring
-----------------

A hospital has installed monitors through the enterprise but reallizes
that most Nurses are not familiar with many of the difficulties that
can be exposed with the monitor.  They implement a central monitoring
group (scope techs) that provides this functionality.  Since there are
so many monitors they can not watch each one continuously as is
usually done with monitor techs.

The scope tech's applications are registered with the vital signs
servers to be notified when alarms start and end.  The application
filters these alarms with a different algorithm for each vital sign in
order to reduce false alarms.  The alarms that get through the filter
are displayed to the scope tech.

The application then polls the vital signs server for the waveforms
(ECG, etc) starting at the beginning of the alarm event up to the
present.  This information is shown to the scope tech immediately.
The application also registers with the vital signs server to be
updated every second with the latest vital signs and the waveforms for
the last second.  As this data arrives the application appends the
waveforms to that already displayed in a continuous manner.

It appears to the scope tech the data is being acquired and displayed
continously but the data is always one second behind.  This small
delay is acceptable for the job of the scope tech.  The delay is used
so that only one packet of data is sent on the network per second,
reducingthe network bandwith required.


Paging System
-------------

A hospital has a nurse paging system that is used for sending messages
to nurses through out the day as well as notifying them of code
situations they may need to attend to immediately.  They choose to
connect the vital signs server to the paging system so that life
threatening alarms can cause the responsible Nurse to be paged.

The paging system is registered with the vital signs server to have
critical data pushed to it when certain events occur (life threatening
arrythmias and apnea).  Since there is a possibility of false alarms
other clinical information needs to be passed to the paging system as
well so the Nurse can triage the severity of the alarm.  A snap shot
of the waveform associated with the alarm (ECG or Respiration) is sent
along with the latest vital signs values.  Some Nurses carry large
screen pagers that can display this extra data.

Due to the time criticality of the alarm the data must be delivered to
the Nurse quickly.  From the point of view of the vital signs server
it is just delivering (pushing) the requested data to a client at the
times they registered interest in.  it knows nothing about the client
except that it can accept the pushed data.


Logging System
--------------

Due to potential legal actions a hospital has implemented an
enterprise wide logging system of information that may be needed in
case a law suit occurs.  It does not have an electronic medical record
system so it prints these out on paper that gets put into the
patient's record.

The most critical information needed is when certain alarms occur but
also periodically during a shift.  The period is determined by what
unit they are on.  The information collected includes an ECG snapshot
of 7 seconds and certain vital signs (heart rate, oxigen saturation,
blood pressure, respiration rate), if they are available.  Since the
blood pressure in taking sporatically only values within the last 15
minutes are included.  All other vital signs are taken continuously
and are inlcuded if a value exists within 5 seconds of the event.

There are several ways the logging system could get the information
from the vital signs server - by polling, querying and registering.

Since the vital signs server keeps all data for 24 hours the logging
system could query for the infomation every 24 hours (or less).  It
could query for the times the alarms it is interested in had occured
through out the day.  It could then query for the required vitals
signs and ECG at these times and at the periodic times for that unit.

The logging system could be registered with the vital signs server to
send the required vital signs and ECG at the periods in which data is
logged for that unit.  It could also register to have the same
information sent when the alarms of interest occur.

Alternatively the logging system could poll for the needed vital signs
and ECG at the periodic times assigned to that unit.  At those same
points in time it could query for which of the important alarms had
occured since the last period and query for the vital signs at those
times.
Attachment Converted: "c:\program files\eudora\attach\vcard34.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 04 May 1998 11:49:12 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: userID in parameter list?

y'all,

Omitting the UserID from the COAS parameter list would be elegant, but
raises some questions with regard to certificates in a security layer:

* COAS dependence on security layer?
* multi-tier identification?
* user info available from existing certificate server?

First, if userID is only in the security layer like SSL, will every COAS
server require a security layer in order to pass userID?   What about
institutions where certain COAS servers, behind a firewall, are rated
"secure enough" for the institution's security policy?  For these backend
servers, removing an encryption layer might offer higher performance.  But
encryption is different than access control.  Institutions are not likely
to forego access control for sensitive data even if they trust that the
communication between servers does not require encryption.

Second, what about COAS servers involved in a multi-tier system?  How will
the client's userID be transmitted between remote layers, if each layer has
its own certificate?

For example, consider a 3-tier system, where a GUI client queries some
middleware COAS server, which in turn call as backend server:

	GUI client --> middleware --> backend

Say a client with userID = "Dr. Smith" requests an observation from a
middleware COAS server.  This middleware server can decode the client
certificate into "Dr. Smith", but the link between the middleware and the
backend server is secure, with its own certificate (userID = "Middle").  So
the middleware requests the observation from the backend, and the backend
decodes the certificate as "Middle" rather than "Dr. Smith".  The backend
server cannot do access control in this scenario.

Third, do certificate servers have a function which translates between
certificate and userID, something like "getUserFromCertificate()"?   Is
this available now?  How will this perform, if each observation request in
each tier must access this function?

I'm not familiar with security layers and certificates, so perhaps these
questions are easily put to rest.  Thanks in advance for your answers.

larry


From: Bart de Greef <degreef@medgrid.philips.com>
Date: Mon,  4 May 1998 13:46:50 -0700 (PDT)
To: coas@baptisthealth.net
Subject: Re: COAS: userID in parameter list?
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid

Larry Hamel writes:

 > Omitting the UserID from the COAS parameter list would be elegant, but
 > raises some questions with regard to certificates in a security layer:
 >
 > * COAS dependence on security layer?
 > * multi-tier identification?
 > * user info available from existing certificate server?

Like Larry, I think it would not be good to make COAS dependent on the
presence of a security layer (How was the issue of client
identity/security handled in the PIDS?).


 > Second, what about COAS servers involved in a multi-tier system?  How will
 > the client's userID be transmitted between remote layers, if each layer has
 > its own certificate?
 >
 > For example, consider a 3-tier system, where a GUI client queries some
 > middleware COAS server, which in turn call as backend server:
 >
 >      GUI client --> middleware --> backend
 >

If the ORBs implement Common Secure Interoperability there are three
possibilities, depending on the Common Secure Interoperability (CSI)
level (from orbos/96-06-20):

        CSI level 0: no delegation
        (principal's id passed to middleware, not to back-end)

        CSI level 1: unrestricted delegation
        (impersonation: all attributes can be passed from middleware
         to back-end)

        CSI level 2: controlled delegation
        (initiating principal can control the use of its
         sec. attributes by the middleware)

and from orbos/97-02-04:

        SSL provides CSI level 0 functionality only.


 > Third, do certificate servers have a function which translates between
 > certificate and userID, something like "getUserFromCertificate()"?   Is
 > this available now?  How will this perform, if each observation request in
 > each tier must access this function?

Such information is usually contained in the certificate (part of the
distinguished name). The only thing you may want to contact a
certificate server for is to verify the validity of the certificate
(e.g., that is is not on a certificate revocation list). Typically,
you'd know the public key of the CA you have chosen to trust and that
is sufficient to verify certificates signed by that CA without
actually contacting the CA.

The API of Visigenic's SSL Pack includes a method public String
distinguishedName() for objects of the class X509CertificateChain.
Other vendors will probably have their own APIs.


Regards,

Bart

--
+-------------------------------------------------------------------+
| Bart L. de Greef                      Philips Medical Systems     |
| degreef@medgrid.philips.com           Sr. Member Technical Staff  |
| Phone     : +1 650 426 2557           Fax : +1 650 426 2550       |
| Snail mail: Philips Medical Systems,                              |
|             2171 Landings Drive, Mountain View CA 94043-0837, USA |
+-------------------------------------------------------------------+
    "Experience is the name everyone gives to their mistakes."

Sender: tim@protocol.com
Date: Mon, 04 May 1998 14:12:33 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: event mechanism

Larry Hamel wrote:
> As goals for a COAS event mechanism, consider the following:
>
> * Compatibility: define the interface so that CosEvent service references
> are allowed, but a Notification references may be passed (a Notification
> channel subclasses a CosEvent channel).

I would prefer if we could hide the actual channel so the client and
consumer would not have to negotiate it.  But at some point they have to
agree since the supplier and consumer interfaces for the Event Service
and Notification Service are different.  Further more the Notification
Service has three styles of suppliers and consumers (structured,
sequence of structures, and 'any').


> * Testability:  the event mechanism needs some test convention since real
> events can cause state changes in servers (persistence).  Furthermore,
> clients need to know if a firewall prevents callbacks.  With a test
> function, clients send a test event to themselves (this could be noisy if
> the channel doesn't support filtering to one client, but we are assuming a
> Notification channel in the 80% case).

This sounds like more of an implementation issue.  I don't understand
the need for standardizing it.


> * Scalability:  the design should account for case where many presentation
> clients want to receive filtered events from a single server, as well as
> case where one middleware server wants all events from a backend server.

Yes!


> * Minimize client responsibility: if we assume that the server both creates
> the channel and continuously supplies events, things get easier.  We can
> dispense with requests to start/stop the supply of events, and the
> responsibility for channel creation is squarely on the shoulders of the
> server.

I do agree with this.  Further more I think it is important that whether
a channel is used or not can be hidden.  For example the client
subscription goes directly to the server but it could deliver the events
its self or connect the client to a channel that delivers them.

In fact when the client connects up to the server it could pass in a
reference to itself or to its own channel (which is uses as a queue to
pull the events out of).


> Consider the following IDL for a COAS server.
>
>         //
>         // list of ConceptCodes which can be subscribed for
>         //
>         readonly attribute ConceptCodeSeq       subscribable;

In Notification Service parlance these would be 'offers' and would be in
terms of event types.  Something like:

		CosNotifyComm::CosEventTypeNameSeq get_offers();

>         // return reference of existing channel for
>         // "reqCode" type of events, creating channel if necessary,
>         // throwing exception if not possible or unsupported code
>         //
>         CosEventChannelAdmin::EventChannel   getChannel(
>                 in UserId               userId,
>                 in ConceptCode  reqCode );

In order to encapsulate the use of channels in earlier PIDS submissions
we crafted a component the server (and client) would use to expose its
ability to supply and/or consume events using push and/or pull
semantics.

	interface EventComponent
	{
		readonly attribute PullConsumerFactory pull_consumer_factory;
		readonly attribute PushConsumerFactory push_consumer_factory;
		readonly attribute PullSupplierFactory pull_supplier_factory;
		readonly attribute PushSupplierFactory push_supplier_factory;
	};

The mechanisms not supported on the component would be NULL.  Each
factory has operations to create and access the appropriate supplier or
consumer.  It also has an indication of the maximum connections allowed
- those applications designed to connect to an external channel would
likely have this value set to one.


>         //
>         // push a test event of standard type into channel, with userID in
>         // structure (filtered to one recipient if Notification service)
>         //
>         void pushTestEvent( in UserId userId );

Do we really need a separate operation for this?  I think we could use a
special Event Type for a test event.  Somehow it has to be converted
into an event type before delivery by a Notification Service any way.


> An alternative to the getChannel() call would be for a client to find the
> channel via a Trader (indexed by server & ConceptCode).

This is a very good idea.  Although I think it is the COAS they would
actually find in the Trader.  One of the parameters it would be
registered with would be the event interfaces it used.  We did something
very similar to this with PIDS.


> MORE FLEXIBILITY?
>
> What if we decide that servers should not be solely responsible for channel
> creation?  For example, what if a middleware server wishes that a backend
> server use a particular channel?  Or a separate entity was the "channel
> manager"?   We could supply a setChannel() function:
>
>         //
>         // if channel is new, server starts pushing
>         // events of type "reqCode" into this channel
>         // if channel is same as existing AND reqCode is new,
>         // start pushing reqCode events
>         // if channel already exists for reqCode events, throw exception
>         //
>         void setChannel(
>                 in UserId                       userId,
>                 in ConceptCode          reqCode,
>                 in CosEventChannelAdmin::EventChannel channel );

I think the event management style I mention above addresses this need
but in a different manner.  If the middleware server creates channels it
could register its channel (instead of itself) with the back end
server.  The back end server may supply events directly to it or it too
might have its own channel.

Notice the management of the channel is only local to the server without
any bilatteral agreements.  I think it is important to give
implementation freedom to each server and have as few cross constratints
between them.


I have attached the entire Notification.idl file from the work we did
during PIDS.  It may look fairly long but the requirements for the
simplest supplier or consumer is very small.  It sets up a very flexible
framework that is scalable from very simple end points to very complex
ones.  For example a supplier could do content based filtering at the
source (which may need more work) but does not have to.

BTW, this IDL was removed out of PIDS before the final submission since
the Notification Service had not been adopted yet.  I'm sure it needs
further consideration too.  For example how might it benefit from OBV?
The registration also needs to consider a description of the events
interested in separate from what information should be delivered with
the event.


Cheers,

Tim// Notification.idl

#ifndef Notification_idl
#define Notification_idl

#include "NamingAuthority.idl"
#include "CosNotifyComm.idl"
#include "CosEventChannelAdmin.idl"

#pragma prefix "org/omg"

module Notification
{
	typedef NamingAuthority::QualifiedNameStr GrammarName;
	const GrammarName Trader1_0 = "Trader1.0";

	typedef unsigned long ConstraintID;
	typedef sequence<ConstraintID> ConstraintIDSeq;

	typedef string ConstraintExp;
	typedef sequence<ConstraintExp> ConstraintExpSeq;

	struct ConstraintInfo {
		ConstraintExp constraint_expression;
		ConstraintID constraint_id;
	};
	typedef sequence<ConstraintInfo> ConstraintInfoSeq;

	typedef unsigned long ConnectionID;
	typedef sequence< ConnectionID > ConnectionIDSeq;

	exception InvalidGrammar {};
	exception InvalidConstraint {ConstraintExp constr;};
	exception DuplicateConstraintID {ConstraintID id;};
	exception ConstraintNotFound {ConstraintID id;};

	exception IdNotFound {};
	exception MaxConnectionsExceeded {};


	interface Filter
	{
		readonly attribute GrammarName constraint_grammar;

		ConstraintInfoSeq add_constraints (
				in ConstraintExpSeq constraint_list )
			raises (
				InvalidGrammar,
				InvalidConstraint );

		void modify_constraints (
				in ConstraintIDSeq del_list,
				in ConstraintInfoSeq modify_list )
			raises (
				InvalidGrammar,
				InvalidConstraint,
				ConstraintNotFound,
				DuplicateConstraintID );

		ConstraintInfoSeq get_constraints(
				in ConstraintIDSeq id_list )
			raises (
				ConstraintNotFound,
				DuplicateConstraintID);

		ConstraintIDSeq get_all_constraints();

		void remove_all_constraints();

	}; // Filter

	interface EventParticipant
	{
		readonly attribute Filter the_filter;
	};

	interface Consumer :
		EventParticipant,
		CosNotifyComm::NotifyPublish
	{
		CosNotifyComm::CosEventTypeNameSeq get_subscriptions();
	};

	interface Supplier :
		EventParticipant,
		CosNotifyComm::NotifySubscribe
	{
		CosNotifyComm::CosEventTypeNameSeq get_offers();
	};

	interface PullSupplier;

	interface PullConsumer :
		Consumer,
		CosNotifyComm::SequencePullConsumer
	{
		void connect_pull_supplier(
				in PullSupplier ps )
			raises(
				CosEventChannelAdmin::AlreadyConnected );
	};

	interface PushSupplier;

	interface PushConsumer :
		Consumer,
		CosNotifyComm::SequencePushConsumer
	{
		void connect_push_supplier(
				in PullSupplier ps )
			raises(
				CosEventChannelAdmin::AlreadyConnected );
	};

	interface PullSupplier :
		Supplier,
		CosNotifyComm::SequencePullSupplier
	{
		void connect_pull_consumer(
				in PullConsumer ps )
			raises(
				CosEventChannelAdmin::AlreadyConnected );
	};

	interface PushSupplier :
		Supplier,
		CosNotifyComm::SequencePushSupplier
	{
		attribute unsigned long max_number;

		void connect_push_consumer(
				in PullConsumer ps )
			raises(
				CosEventChannelAdmin::AlreadyConnected );
	};

	interface PullConsumerFactory;
	interface PushConsumerFactory;
	interface PullSupplierFactory;
	interface PushSupplierFactory;

	interface EventComponent
	{
		readonly attribute PullConsumerFactory pull_consumer_factory;
		readonly attribute PushConsumerFactory push_consumer_factory;
		readonly attribute PullSupplierFactory pull_supplier_factory;
		readonly attribute PushSupplierFactory push_supplier_factory;
	};

	interface Factory :
		EventComponent
		{
			readonly attribute unsigned long max_connections;
			readonly attribute ConnectionIDSeq current_connection_ids;
		};

	interface PullConsumerFactory :
		Factory
	{
		PullConsumer create_pull_consumer(
				out ConnectionID id )
			raises(
				MaxConnectionsExceeded );

		PullConsumer get_pull_consumer(
				in ConnectionID id )
			raises(
				IdNotFound );
	};

	interface PushConsumerFactory :
		Factory
	{
		PushConsumer create_push_consumer(
				out ConnectionID id )
			raises(
				MaxConnectionsExceeded );

		PushConsumer get_push_consumer(
				in ConnectionID id )
			raises(
				IdNotFound );
	};

	interface PullSupplierFactory :
		Factory
	{
		PullSupplier create_pull_supplier(
				out ConnectionID id )
			raises(
				MaxConnectionsExceeded );

		PullSupplier get_pull_supplier(
				in ConnectionID id )
			raises(
				IdNotFound );
	};

	interface PushSupplierFactory :
		Factory
	{
		PushSupplier create_push_supplier(
				out ConnectionID id )
			raises(
				MaxConnectionsExceeded );

		PushSupplier get_push_supplier(
				in ConnectionID id )
			raises(
				IdNotFound );
	};

};

#endif // Notification_idl

Attachment Converted: "c:\program files\eudora\attach\vcard36.vcf"
Sender: tim@protocol.com
Date: Mon, 04 May 1998 14:36:08 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS Issues

Larry Hamel wrote:
> >The Notification Service has both type
> >based and content based filtering.  Only the former can be done at the
> >source.
>
> hmm, the source can filter by content and decide what to put into the
> channel.  The source can ask the channel what clients have subscribed for.
>  That seems like enough for most designs...

Hopefully there will be some pattern like this can help but I'm not
sure.  There is not a convienent way for the supplier to get the content
based subscription information (constraints) from the channel.  Besides
what if the client and server are connected directly together without a
channel in between (the Event Service hinted this coul dbe done but did
not give enough IDL to do it).

I further problem is that many of the event scenerios I know of the
client and server have the ability to consume and supply events but it
is some other logic that ties them together and configures the specifics
of the connection.  The Event and Notification Services do not solve
this problem, that is how can the end points (suppliers and consumers)
publish this capability so that some other application can manage the
connection?  It currently does not exist.


> >
> >The other problem is that the ProxyConsumer is on the channel.  There
> >are times when we need some (but definitely not all) of those
> >capabilities at the end points.  We also have scenerios where the
> >subscription of events would NOT go through a channel and others when it
> >should.
>
> with the getChannel() call on the server, you can customize the channel you
> give out.  can you accomplish what you want with some internal object that
> implements the CosEvent channel interface?

I have (many times) looked at implementing only half or quarter of an
Event Channel but it was not designed that way.  This seems to be the
first thing everyone suggests (but few have tried).  You could implement
just the proxy interface of choice but the channel admin interfaces
don't do much for you since you would have to throw NOT_IMPLEMENTED on
most of the operations.  This breaks the interoperability model
substantially since it does not allow you to manage the optional
capabilites in a predictable way.

Now the Notification Service is even worse such that I would not suggest
even using the proxy interfaces.  They have additional channel specific
capabilities (QoS, mapping filters, etc.).  In the Notification.idl I
just posted it does reuse as much of the Notification Service as
possible.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard37.vcf"
Sender: tim@protocol.com
Date: Mon, 04 May 1998 14:53:56 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Bart de Greef <degreef@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: userID in parameter list?

Bart de Greef wrote:
> Like Larry, I think it would not be good to make COAS dependent on the
> presence of a security layer (How was the issue of client
> identity/security handled in the PIDS?).

I think we would be going up against a big battle if we are not careful
how we do this.  We are to be extending the OMA.  The OMG expects us to
extend it not duplicate capability that already exists.  The AB is the
overseer of this.

In PIDS, security was one of the most discussed issues among the
submitters starting way before the Initial Submission.  Every time it
came up the concensus was that it is an orthogonal concern.  There is a
good section in the PIDS appendix that describes how to use CORBAsec
with PIDS.  It was written by someone that makes his living from
consulting on Security matters (many related to CORBA), Polar Humenn.

We had some people envolved with PIDS that had deep security
backgrounds.  It sounds like we should see if we can get them involved
here.


Now with all that said I think there is a problem with the current state
of the art - it is not widely implemented.  The Secure IIOP spec was
suppose to create a base for out of the box interoperability but I don't
know if it really does.  We really need people with CORBA security
background involved such as Polar Humenn, Wayne Wilson, Fred Druseikis,
or other CORBAsec people.  Can anyone talk to these people to get them
involved?

Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard38.vcf"
From: Bart de Greef <degreef@medgrid.philips.com>
Date: Mon,  4 May 1998 15:24:33 -0700 (PDT)
To: Tim Brinson <tim@protocol.com>
CC: larryh, coas@baptisthealth.net
Subject: Re: COAS: userID in parameter list?
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid

Hi Tim,

 > > Like Larry, I think it would not be good to make COAS dependent on the
 > > presence of a security layer (How was the issue of client
 > > identity/security handled in the PIDS?).
 >
 > I think we would be going up against a big battle if we are not careful
 > how we do this.  We are to be extending the OMA.  The OMG expects us to
 > extend it not duplicate capability that already exists.  The AB is the
 > overseer of this.

Just to clarify myself: I do agree that security is an orthogonal
issue for COAS as well -- Larry and my concern here is that we don't
want to have a COAS that mandates the presence of a security layer.
If people want to have security, then by all means via CORBASec,
SECIOP etc. Our impression was that piggybacking the userID on a
security protocol might inadvertently make the presence of such a
layer mandatory for the proper functioning of COAS.

Cheers,

Bart.

X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 05 May 1998 00:42:40 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Proposal for definition of observations

I would like to propose the following definition of clinical observations.
I welcome all comments, suggestions, etc.

Chuck
========
The definition of a clinical observation involves several levels of
meaning.
On the surface, a clinical observation is any result of observing
the
anatomical, physiological, and/or pyschological state of a human being
within
the context of the delivery of health care.

All observations share
a few common features:
- they are made on a specific individual, the
patient;
- they represent a snap-shot of that individual in time, either at
a particular
  time, or over some specified interval of time (time in this
context includes
  the notion of both date and time);
- they have an
associated time interval of clinical relevance;
- they are made, or
ordered, by a health care professional; and
- they are given (either by the
patient, the health care institution,
  or society) some degree of
confidentiality.

Observations can be divided into two classes:
1) direct
observations (e.g. systolic blood pressure, and a chest x-ray), and
2)
indirect observations derived from sets of direct observations,
   (e.g.
blood pressure trends, and densities in the lung spaces).

Direct
observations are either:
* quantitative measurements (e.g. fasting blood
sugar),
* recordings (e.g. ultrasound images), or
* qualitative impressions
(e.g. palpation of the liver).
Measurements are typically reported using
numbers, or a fixed number of
states.  Recordings are typically either
audio, static images,
or video sequences.  Impressions are either
descriptive text, or one
of a fixed number of states.  Impressions are
commonly documented
in structured text reports.
Direct observations have
several features in common, in addition to
the features that all
observations share:
+ they have a preferred data format, and
+ they have a
well defined name within some standard lexicon.

Indirect observations can
also be quantitative, qualitative, and
recordings, e.g. numerical trends in
measured values, correlation of
several qualitative impressions, and
digital image subtraction angiography.
As mentioned in one of the Issues to
be Discussed, it is not always clear
when an indirect "observation" is a
true observation rather than say a
conclusion, decision, or problem
statement derived from observations.
Also, it is not always clear if a
clinically significant event
(e.g. a stroke, or a heart attack) is an
observation.
For example, is a surgical note an observation?
Are nursing
notes observations?
Are diagnoses observations?
Are the results of a
Healthcare Data Interpretation Facility observations?
(The RFP for the HDIF
is given in OMG document corbamed/98-03-29.)


Sender: tim@protocol.com
Date: Tue, 05 May 1998 09:11:23 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Polar Humenn <polar@cat.syr.edu>
CC: Mary Kratz <mkratz@umich.edu>, Wayne Wilson <wwilson@umich.edu>,
        coas@baptisthealth.net
Subject: Re: [Fwd: COAS: userID in parameter list?] (fwd)

Polar Humenn wrote:
> What is COAS?
>
> If this is an OMG thing, I cannot be a submiiter in the formal sense since
> I am no longer a "paying" member of OMG.
>
> In what capacity can I be of assistance?

Polar,


COAS is the Clinical Observations Access Service RFP.  The submitters
are opening it up to include any 'supporters' as well, similar to how we
did with PIDS.

Over the last couple weeks there have been some issues come up about
passing a UserId in all operations.  Remembering similar issues came up
in PIDS brought up some of the resolutions we had then but the requests
continued.  Since I do not have the security background (e.g. never read
the CORBAsec spec) I suggested we see if some people with a security
background might be able to assist (e.g. you, Wayne, etc.).

Yesterday Dave Forslund posted his experience being able to pass UserIds
with out defining them as parameters to operations.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard39.vcf"
Sender: tim@protocol.com
Date: Tue, 05 May 1998 10:06:29 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5 sun4m)
To: Charles Carman <ccarman@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: Proposal for definition of observations

Charles Carman wrote:
>
> I would like to propose the following definition of clinical observations.
> I welcome all comments, suggestions, etc.

Great.  Thanks for starting this out.  The following small definition
might somehow be useful too.  It came from the Clinical Observations RFI
CORBAmed issued last year.  CORBAmed spent quite a bit of time word
smithing it.

            Observations - This term is used through out the RFI to
            indicate any information that has been captured about a
single
            patient's medical/physical state and relevant context
            information.  This may be derived by instruments such as in
            the case of images, vital signs and lab results or it may be
            derived by a health professional via direct examination of
the
            patient.  This term applies to information that has been
            captured whether or not it has been reviewed by an
appropriate
            authority to confirm its applicability to the patient
record.
            The term is used independent of any particular information
            representation format.


I have other comments in line below.


> All observations share
> a few common features:
> - they are made on a specific individual, the
> patient;
> - they represent a snap-shot of that individual in time, either at
> a particular
>   time, or over some specified interval of time (time in this
> context includes
>   the notion of both date and time);
> - they have an
> associated time interval of clinical relevance;

It seems this last one might only be of secondary importance since its
clinical relevance may depend on the situation and may degrade over time
(as opposed to just stopping cold).  Maybe a better way to say is that
the clinical relevance varies according to the problems being addressed
and length of time since the observation was made.

> - they are made, or
> ordered, by a health care professional; and

While I think this is true I just wanted to make the point that
sometimes it is not an explicate order.  For example there is a standing
order to monitor certain functions in the ICU, etc.  In this case the
order is not from an explicate professional but from the organization
which consists of providers.

Also note that a subjective observation is really made by the patient
but recorded by the provider.


> - they are given (either by the
> patient, the health care institution,
>   or society) some degree of
> confidentiality.
>
> Observations can be divided into two classes:
> 1) direct
> observations (e.g. systolic blood pressure, and a chest x-ray), and
> 2)
> indirect observations derived from sets of direct observations,
>    (e.g.
> blood pressure trends, and densities in the lung spaces).

I'm not exactly sure how to interpret what you mean by indirect.  Maybe
some more examples would help.  It seems there are a lot of ways they
might be divided into classes.


> Direct
> observations are either:
> * quantitative measurements (e.g. fasting blood
> sugar),
> * recordings (e.g. ultrasound images), or
> * qualitative impressions
> (e.g. palpation of the liver).
> Measurements are typically reported using
> numbers, or a fixed number of
> states.  Recordings are typically either
> audio, static images,
> or video sequences.  Impressions are either
> descriptive text, or one
> of a fixed number of states.  Impressions are
> commonly documented
> in structured text reports.
> Direct observations have
> several features in common, in addition to
> the features that all
> observations share:
> + they have a preferred data format, and
> + they have a
> well defined name within some standard lexicon.

Sounds like we should have definitions of Measurements, Recordings,
Impressions too.  I get a sense of the definition you are using but
still not sure yet.


> Indirect observations can
> also be quantitative, qualitative, and
> recordings, e.g. numerical trends in
> measured values, correlation of
> several qualitative impressions, and
> digital image subtraction angiography.
> As mentioned in one of the Issues to
> be Discussed, it is not always clear
> when an indirect "observation" is a
> true observation rather than say a
> conclusion, decision, or problem
> statement derived from observations.
> Also, it is not always clear if a
> clinically significant event
> (e.g. a stroke, or a heart attack) is an
> observation.

Good point.


> For example, is a surgical note an observation?

I would think yes.


> Are nursing notes observations?

I would think yes.


> Are diagnoses observations?

Not sure.


> Are the results of a
> Healthcare Data Interpretation Facility observations?

Not sure.


I was wondering if the direct vs indirect actually has multiple levels
of gray.  By indirect do you mean derived?  It seems most everything is
derived from something.  Maybe a common characteristic of an observation
is 'how it was derived'.  Each may be based on some evidence and
assumptions.  With this reasoning it starts sounding like diagnoses' are
observations too.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard40.vcf"
X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 06 May 1998 13:58:09 -0700
To: coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Submitter's Teleconfence 5/12

I have arranged for a dial-in teleconference for Tuesday 12 May 1998, as
follows:

Time:  1 pm PDT (4 pm EDT)
Number: 1-888-232-0370
Code: 626853
Time: 2 hours

I have arranged for 12 ports, so I request that all participants from a
single facility dial-in from one location (phone).

The meeting will discuss and finalize plans for the 5/18 initial
submission.  I will not be able to participate in this meeting; Chuck
Carman will be the host.

If you have any problems, please call the PMS operator at 1-650-426-2500.


_____________________________________
Bob Glicksman
Chief Scientist, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 07 May 1998 09:37:28 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Re: Submitter's Teleconfence 5/12

In preparation for our teleconference call (and a discussion of our
initial submission), I have placed my current draft of the initial
submission document at http://www.protocol.com/engineering/corbamed/incoming

The document name is coas.rtf
(I appologize if you can not read an .rtf file,
we just purchased Adobe Acrobat, so tomorrow I will be able to create
a coas.pdf file if any of you need / want that format.)
All comments, suggestions, chapters, etc. are welcome.

Chuck Carman

At 01:58 PM 5/6/98 -0700, Bob Glicksman wrote:
>I have arranged for a dial-in teleconference for Tuesday 12 May 1998, as
>follows:
>
>Time:  1 pm PDT (4 pm EDT)
>Number: 1-888-232-0370
>Code: 626853
>Time: 2 hours
>
>I have arranged for 12 ports, so I request that all participants from a
>single facility dial-in from one location (phone).
>
>The meeting will discuss and finalize plans for the 5/18 initial
>submission.  I will not be able to participate in this meeting; Chuck
>Carman will be the host.
>
>If you have any problems, please call the PMS operator at 1-650-426-2500.
>
>
>_____________________________________
>Bob Glicksman
>Chief Scientist, MedGRiD Program
>Integrated Clinical Solutions
>
>bobg@medgrid.philips.com              Philips Medical Systems
>voice:  (650) 426-2551                2171 Landings Drive
>fax:    (650) 426-2550                Mountain View, CA 94043-0837
>Pager:  800-759-7243, PIN# 4856736
>
>

Sender: tim@protocol.com
Date: Thu, 07 May 1998 10:00:22 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Charles Carman <ccarman@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: Submitter's Teleconfence 5/12

Charles Carman wrote:
>
> I have placed my current draft of the initial
> submission document at http://www.protocol.com/engineering/corbamed/incoming

Make that:

	http://www.protocol.com/engineering/corbamed/coas/incoming/
Attachment Converted: "c:\program files\eudora\attach\vcard41.vcf"
X-Mailer: Novell GroupWise 5.2
Date: Thu, 07 May 1998 13:14:09 -0600
From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
To: coas@baptisthealth.net, ccarman@medgrid.philips.com
Cc: HRSOLBRIG@wpmail.code3.com
Subject: Re: Submitter's Teleconfence 5/12

Charles,
I will be in the air and unavailable. However, Harold Solbrig stated that he may be able to dial in.
Thanks
Tom

>>> Charles Carman <ccarman@medgrid.philips.com> 05/07 10:37 AM >>>
In preparation for our teleconference call (and a discussion of our
initial submission), I have placed my current draft of the initial
submission document at http://www.protocol.com/engineering/corbamed/incoming

The document name is coas.rtf
(I appologize if you can not read an .rtf file,
we just purchased Adobe Acrobat, so tomorrow I will be able to create
a coas.pdf file if any of you need / want that format.)
All comments, suggestions, chapters, etc. are welcome.

Chuck Carman

At 01:58 PM 5/6/98 -0700, Bob Glicksman wrote:
>I have arranged for a dial-in teleconference for Tuesday 12 May 1998, as
>follows:
>
>Time:  1 pm PDT (4 pm EDT)
>Number: 1-888-232-0370
>Code: 626853
>Time: 2 hours
>
>I have arranged for 12 ports, so I request that all participants from a
>single facility dial-in from one location (phone).
>
>The meeting will discuss and finalize plans for the 5/18 initial
>submission.  I will not be able to participate in this meeting; Chuck
>Carman will be the host.
>
>If you have any problems, please call the PMS operator at 1-650-426-2500.
>
>
>_____________________________________
>Bob Glicksman
>Chief Scientist, MedGRiD Program
>Integrated Clinical Solutions
>
>bobg@medgrid.philips.com              Philips Medical Systems
>voice:  (650) 426-2551                2171 Landings Drive
>fax:    (650) 426-2550                Mountain View, CA 94043-0837
>Pager:  800-759-7243, PIN# 4856736
>
>


X-Mailer: Novell GroupWise 5.2
Date: Thu, 07 May 1998 15:12:55 -0600
From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
To: coas@baptisthealth.net, ccarman@medgrid.philips.com
Cc: HRSOLBRIG@wpmail.code3.com
Subject: Re: Submitter's Teleconfence 5/12

Charles,
Since I will be unavailable for the teleconference on 5/12/98 I have made some comments in the doc. Can you please look them over and see if they seem reasonable.
Thanks
Tom

>>> Charles Carman <ccarman@medgrid.philips.com> 05/07 10:37 AM >>>
In preparation for our teleconference call (and a discussion of our
initial submission), I have placed my current draft of the initial
submission document at http://www.protocol.com/engineering/corbamed/incoming

The document name is coas.rtf
(I appologize if you can not read an .rtf file,
we just purchased Adobe Acrobat, so tomorrow I will be able to create
a coas.pdf file if any of you need / want that format.)
All comments, suggestions, chapters, etc. are welcome.

Chuck Carman

At 01:58 PM 5/6/98 -0700, Bob Glicksman wrote:
>I have arranged for a dial-in teleconference for Tuesday 12 May 1998, as
>follows:
>
>Time:  1 pm PDT (4 pm EDT)
>Number: 1-888-232-0370
>Code: 626853
>Time: 2 hours
>
>I have arranged for 12 ports, so I request that all participants from a
>single facility dial-in from one location (phone).
>
>The meeting will discuss and finalize plans for the 5/18 initial
>submission.  I will not be able to participate in this meeting; Chuck
>Carman will be the host.
>
>If you have any problems, please call the PMS operator at 1-650-426-2500.
>
>
>_____________________________________
>Bob Glicksman
>Chief Scientist, MedGRiD Program
>Integrated Clinical Solutions
>
>bobg@medgrid.philips.com              Philips Medical Systems
>voice:  (650) 426-2551                2171 Landings Drive
>fax:    (650) 426-2550                Mountain View, CA 94043-0837
>Pager:  800-759-7243, PIN# 4856736
>
>


Attachment Converted: "c:\program files\eudora\attach\coasTCC.rtf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 11 May 1998 13:21:31 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: data model for imaging

y'all,

Enclosed is the IDL for a data model from a Philips imaging prototype.
This model is directly related to the Image Access Service, a COAS
"subclass".  It is appropriate for COAS discussion as part of the overall
data model of observations (more forthcoming on the larger model).

The goals of this image model are to

* shield users from the DICOM query/retreive mechanism
* abstract a common hierarchy from the various image-set possibilities in
DICOM
* add transform services on the server for resolution and color-bit-depth,
as well as user-selectable choices for compression, format, and other
attributes.

With the common hierarchy for image sets, the model allows a query to
specify an image without exposing the remote CORBA references which might
represent study objects or image objects.  This allows the server to
control the lifecycle of these objects and avoids a remote
garbage-collection issue when clients are finished with studies or get
traumatically disconnected.  The latter case would require some kind of
timeout thread in the server.

Let me know what you think.

larry


Attachment Converted: "c:\program files\eudora\attach\ImageStruct5.idl"

Attachment Converted: "c:\program files\eudora\attach\ImageObject4.idl"

Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426 2550From: Bart de Greef <degreef@medgrid.philips.com>
Date: Mon, 11 May 1998 14:35:23 -0700 (PDT)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: data model for imaging
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid

Hi Larry,

 > With the common hierarchy for image sets, the model allows a query to
 > specify an image without exposing the remote CORBA references which might
 > represent study objects or image objects.  This allows the server to
 > control the lifecycle of these objects and avoids a remote
 > garbage-collection issue when clients are finished with studies or get
 > traumatically disconnected.  The latter case would require some kind of
 > timeout thread in the server.

This may be a VisBroker-specific option, but using interceptors (e.g.,
via Event handlers (nothing to do with event service) it is possible
to find out whether a client has disconnected (see java_examples/event_bank).

Also, both the ORB and the BOA have tcpTimeount options to set a
timeout for client connections. If no activity occurs within this
period the connection will be closed by the server.
(default = 0, i.e., infinite)

I'll be looking deeper into this w.r.t general perforamce and
scalability issues, but you can easily try the example right 'out of
the box.'

Probably vbj's ORB or the Handler(Registry) implements the timer you
mention.

Bart.

Date: Tue, 12 May 1998 14:03:21 -0700
From: David Foard <dhf@alpha.sunquest.com>
Organization: Sunquest Information Systems
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net
Subject: URL for Cosmos Project

The URL I sent out previously has changed. Here is the new URL:

 http://smwww1.med.ic.ac.uk/dm/dmgm/ccpm2pt1.doc

This is the actual Word document.

Dave Foard
Sr Software Developer
dhf@alpha.sunquest.com

Sunquest Information Systems
4801 E. Broadway
Tucson, Az  85711


Sender: tim@protocol.com
Date: Tue, 12 May 1998 15:26:56 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Mary Kratz <mkratz@umich.edu>
CC: coas@baptisthealth.net
Subject: Re: [Fwd: Transcription/Dictation Scenarios]

Mary Kratz wrote:
>
> Is anyone capturing the COAS scenario's in UML?
>
> The HL7 XML SIG presentation on COAS went very well.  Ed Barkmeyer of NIST
> popped down to Baltimore to offer technical support for the presentation.
> We may pick up a couple more LOI's on this effort from the Healthcare XML
> vendors.  I think they will add a significant piece to the final
> specification.  In addition we will pick up a couple supporters from
> Kaiser, as individuals.  They are approaching the Kaiser CIO for
> organizational support of CORBAmed.
>
> The fun just never ends ;-)
>
> -Mary

Mary,

Can you tell us who these other supporters are and check on the status
of Kaiser?  We would like to include them into the Initial Submission
for Monday.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard42.vcf"
Sender: tim@protocol.com
Date: Tue, 12 May 1998 15:38:39 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Submitters & Supporters

I indicated during the conference call that I would provide this
information for the Initial Submission.  Thanx to Chuck at Philips for
putting the submission together.


The current list of submitters are:

	3M

	CareFlow|Net

	Philips

	Protocol Systems, Inc.

	Sunquest

I have questions out to HBOC and IDX as well and still plan to talk to
others.


The current list of supporters are:

	Baptist Health Systems of South Florida

	Los Alamos National Laboratory

	University of Michigan Medical Center

	AGFA

	Universidade federal de Sao Paulo

	Sao Paulo Hospital das Clinicas

	GE Medical Systems


I have questions out to others including Kaiser.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard43.vcf"
Date: Tue, 12 May 1998 17:31:12 -0700
From: David Foard <dhf@alpha.sunquest.com>
Organization: Sunquest Information Systems
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: "coas@baptisthealth.net" <coas@baptisthealth.net>
Subject: Another URL for Cosmos Project documentation

The Cosmos Project is divided into 2 documents. The URL I sent out
previously was part 1; here is the URL for part 2 document

 http://smwww1.med.ic.ac.uk/dm/dmgm/ccpm2pt2.doc


Dave Foard
Sr Software Developer
dhf@alpha.sunquest.com


From: Fred Druseikis <fredd@HealthMagic.com>
To: coas@baptisthealth.net
Subject: subscribe
Date: Wed, 13 May 1998 08:24:22 -0400
X-Mailer: Internet Mail Service (5.0.1458.49)

subscribe fredd@healthmagic.com

________________________________________________________________________
_
Frederick C. Druseikis
Chief Architect
HealthMagic, Inc.
1901 Main Street, Suite 1570 M/S 504
Columbia, SC 29201
Vox: (803) 748 - 9444 x101
Fax: (803) 748 - 9986


X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 13 May 1998 12:16:01 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Re: Submitter's Teleconference 5/12

<x-rich><fontfamily><param>Times New Roman</param><bigger>A teleconference was
held on Tuesday, 12 May, 1998.  The following people were in
attendance:


- Henry Ware (CareFlow|Net)

- Dave Foard (Sunquest)

- Tim Brinson (Protocol Systems)

- Larry Hamel (Philips Medical Systems)

- Chuck Carman (Philips Medical Systems)


The meeting covered the following topics:

1. Small detailed changes needed in the existing draft of the initial
COAS submission.

2. The addition of several sections to the initial COAS submission

3. Clarification discussions on various topics from Section 2, Issues for
Discussion

4. Proposals for the next couple of meetings (Tuesday or Thursday, May 26
or 28, and Monday eve, June 8 at the CORBAmed meetings).


The following are more detailed notes of the teleconference.


1. Detailed changes to the distributed draft of the initial COAS
submission

* Put Draft/revision info on the front page

* Rewrite all sentences in the first person (that use "I")

* Add URLs to existing object models where available

* Change the "pragma prefix" IDL lines to "omg.org"

* Change the format of the headers in Section 9.1, Report Management
Service

* Add the word "Scenario" to the headings in Section 9.2, Vital Sign
Service

* Change LANL from Submitter to Supporter

* Add Contact info for Sunquest

* Add additional Supporters (to be forwarded by Tim Brinson)


2. Additional sections/discussions to be added to the initial
submission.

* Add a section on data models

* Add a section on Events, and Subscribe/Publish interfaces

* Add sections for Image Access scenarios, Lab Data Access scenarios, and
event registration scenarios

* Update the Introduction to include a discussion of the definition/scope
of COAS and a disclaimer that the IDL included is for discussion and
illustration purposes only, and should not be taken as our proposed
interface design.


3. The following topics were discussed, some at great length, and others
only briefly.

* UserId / Access to confidential data

  - There is still some difference of opinion on the matter of making the
UserId an explicit parameter in the COAS access methods, or having it be
implicit, i.e. a matter for the CORBA security services to communicate
and enforce.

  - There is agreement that in general, IT security and access control
should be set by local institution policies, and that these should be, in
general, enforced by CORBA security services.

  - It is not clear to all whether

    1) the COAS should require the use of CORBA security services, and

    2) the CORBA security services may not support data level access
control without data level access methods in the COAS interfaces.

* Interface components

  - There was some discussion how the COAS interfaces might be split up
into option components.

  - The following is a summary of the proposed components, with most
requiring more discussion, etc.

    1. A synchronous interface, for data already in the back-end
systems.

    2. An asynchronous interface, to subscribe to future events/data from
the back-end systems.

    3. A constraint language based query interface.

    4. A list or sequence oriented list to support batching of queries
and data.

    5. An interface tuned to the specifics of "continuously" sampled
vital-signs data.

* Event/Notification services

  - How does a server know which clients have subscribed to a
Notification service, and what events they are looking for?

  - What mechanisms should be used for events and notifications (and
should COAS define specific interfaces or just pass objects from the
CORBA Event or Notification services)?

  - What is the difference between queries for past observations, current
observations, and future observations?

* Access mechanisms and data type specific interfaces

  - There is clearly the need to support different types of queries for
the different types of observations, what is not clear are the mechanisms
that should be used to support this capability.

  - There was some discussion of making interface components for each
type of observation, and (at the other extreme?) having a single access
mechanism with a generalized argument for type specific parameters.

  - Design decisions on this issue are fundamental to the overall COAS
design, and input from all members of this team are needed, encouraged,
and welcome.


4. Future meetings.

It was proposed that, even after the initial submission deadline, we
continue our regular biweekly teleconferences.  Philips Medical Systems
has been regularly inconvenienced by their lawn service during the last
few teleconferences, and they will investigate having the lawn service
come at a different time.

If that is not possible, then it was proposed that we move our
teleconferences to Thursdays at the same time.  Thus, until further
notice, the next call will be on Tuesday, May 26, 1998 at 1:00 PM PDT.

It was also proposed that we hold a COAS team meeting at the CORBAmed
meetings in Orlando.  We agreed that would be a good thing, and it was
tentatively set for Monday evening, June 8, 1998.

Further details for both "meetings" will be distributed before the
meetings are held.

</bigger></fontfamily>

</x-rich>
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: data model from HL7 v.3
Cc:
Bcc:
X-Attachments: E:\COASdataModel\datamod.zip;
In-Reply-To:
References:

y'all,

Enclosed is a healthcare data model in both .idl and Rational Rose .mdl.  The Rose picture is prettier and shows the inheritance graphs.  But Rose 4.0.4 produces ugly "8.3" filenames for .idl files--sorry.

This model stems from a prototype by Philips & CareFlow|Net, and was adapted from the HL7 v.3 RIM model.

The goals of this data model are to

* translate the HL7 v.3 RIM model into objects.
* specify attributes, not operations (fitting COAS main intent with OBV)

Some potential discussion topics:

* Is HL7 v.3 the best starting point?
* Is this a good mapping of HL7 to objects?
* How do we fill in gaps?

Let me know what you think.

larry


X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 13 May 1998 14:52:18 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: data model from HL7 v.3

y'all,

Enclosed is a healthcare data model in both .idl and Rational Rose .mdl.
The Rose picture is prettier and shows the inheritance graphs.  But Rose
4.0.4 produces ugly "8.3" filenames for .idl files--sorry.

This model stems from a prototype by Philips & CareFlow|Net, and was
adapted from the HL7 v.3 RIM model.

The goals of this data model are to

* translate the HL7 v.3 RIM model into objects.
* specify attributes, not operations (fitting COAS main intent with OBV)

Some potential discussion topics:

* Is HL7 v.3 the best starting point?
* Is this a good mapping of HL7 to objects?
* How do we fill in gaps?

Let me know what you think.

larry



Attachment Converted: "c:\program files\eudora\attach\datamod.zip"

Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426 2550To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: getX/getY examples
Cc:
Bcc:
X-Attachments:
In-Reply-To:
References:

y'all,

As requested in the last teleconference, below are some examples of the "getX" concept, where each individual concept has an individual function on the server.  The two extremes for server design are "getX" at one end of the spectrum, and "generalized-get" at the other.  At the bottom is the original email with reasons why "getX" adds value when offered _in addition to_ a "generalized-get" function.  In the COAS first submission, we have IDL only for a "generalized-get" server.

Let's say that we want to get information about an image study, represented by the struct "Study":

    struct Study {
        ObjectID            studyObjectID;
        sequence<string>    modality;
	...
        sequence<ImageSet>  sets;
    };

On a server with "getX" functions, there would be a function call to retrieve a study, something like

	Study getStudy( ..., StudyID id );

Likewise, if you wanted to get an image, you'd call something like

	Image getImage( ..., StudyID id, ImageID id );

Each function returns a specific type, without a union, Any, or base classs.  There is no ConceptCode in the parameter list of these functions.  The parameter list of each function is "custom" to the function.

Let me know if this isn't clear.


larry

-------------------------------
y'all,

Consider a specification that COAS servers publish "getX/getY" interfaces
along with the generalized interface which uses ConceptCodes to specify the
request.

In other words, a server would have both types of interface, such as:

	value Base get( ConceptCode c, ..., value Base arg );  // generalized

	X getX( ..., XArg arg);	// specific
	Y getY( ..., YArg arg);

PRO

* Designers get to choose the interface that best fits their goals.  They
can pick a general interface that accommodates all types, and will not
change as types evolve, or they can pick a getX interface that is fragile
to change, but may offer higher efficiency since there is no wrapping or
casting.  (In our experience, ANY wrapping was expensive!)

* With getX/getY exposed, the data model is explicitly defined in the IDL
of the server.  Otherwise, the data model may not be physically tied to the
IDL of the server.

* Generalized-get servers will often publish a getX/getY interface anyway,
in order to make implementation of the dispatch easy.  Why not mandate it?

* For a given ConceptCode, the client knows exactly where to look for the
types for return and argument values.  The attribute for the ConceptCode
for X itself would be listed in the IDL right next to the "XReturn" and
"XArg" structs.


CON (with attempts to answer)

"There are too many concepts to specify at once."
This is true for both "getX" and generalized-get.  The latter assumes a
data model for interoperability, which will be incomplete, given the large
number of potential concepts.   An incremental approach seems sensible.

"Servers can expose getX/getY if they choose, but don't mandate it."
This is an alternative, but a server which doesn't expose getX/getY will
not have its data model physically tied to the server interface.



thanks for the feedback,

larry

X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Wed, 13 May 1998 15:39:55 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: getX/getY examples

y'all,

As requested in the last teleconference, below are some examples of the
"getX" concept, where each individual concept has an individual function on
the server.  The two extremes for server design are "getX" at one end of
the spectrum, and "generalized-get" at the other.  At the bottom is the
original email with reasons why "getX" adds value when offered _in addition
to_ a "generalized-get" function.  In the COAS first submission, we have
IDL only for a "generalized-get" server.

Let's say that we want to get information about an image study, represented
by the struct "Study":

    struct Study {
        ObjectID            studyObjectID;
        sequence<string>    modality;
	...
        sequence<ImageSet>  sets;
    };

On a server with "getX" functions, there would be a function call to
retrieve a study, something like

	Study getStudy( ..., StudyID id );

Likewise, if you wanted to get an image, you'd call something like

	Image getImage( ..., StudyID id, ImageID id );

Each function returns a specific type, without a union, Any, or base
classs.  There is no ConceptCode in the parameter list of these functions.
The parameter list of each function is "custom" to the function.

Let me know if this isn't clear.


larry

-------------------------------
y'all,

Consider a specification that COAS servers publish "getX/getY" interfaces
along with the generalized interface which uses ConceptCodes to specify the
request.

In other words, a server would have both types of interface, such as:

	value Base get( ConceptCode c, ..., value Base arg );  // generalized

	X getX( ..., XArg arg);	// specific
	Y getY( ..., YArg arg);

PRO

* Designers get to choose the interface that best fits their goals.  They
can pick a general interface that accommodates all types, and will not
change as types evolve, or they can pick a getX interface that is fragile
to change, but may offer higher efficiency since there is no wrapping or
casting.  (In our experience, ANY wrapping was expensive!)

* With getX/getY exposed, the data model is explicitly defined in the IDL
of the server.  Otherwise, the data model may not be physically tied to the
IDL of the server.

* Generalized-get servers will often publish a getX/getY interface anyway,
in order to make implementation of the dispatch easy.  Why not mandate it?

* For a given ConceptCode, the client knows exactly where to look for the
types for return and argument values.  The attribute for the ConceptCode
for X itself would be listed in the IDL right next to the "XReturn" and
"XArg" structs.


CON (with attempts to answer)

"There are too many concepts to specify at once."
This is true for both "getX" and generalized-get.  The latter assumes a
data model for interoperability, which will be incomplete, given the large
number of potential concepts.   An incremental approach seems sensible.

"Servers can expose getX/getY if they choose, but don't mandate it."
This is an alternative, but a server which doesn't expose getX/getY will
not have its data model physically tied to the server interface.



thanks for the feedback,

larry



To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: event mechanism
Cc:
Bcc:
X-Attachments:
In-Reply-To: <354E2F41.391F9B9A@protocol.com>
References: <3.0.2.32.19980501103145.00ade6a0@med10.medgrid.philips.com>

<x-rich>Tim,


Thanks for the feedback on events and new suggestions.  The design direction you outline is coherent, but it seems to rest on the assumption that most COAS servers will want to specialize the Notification service.  Is that the best guess?



>I would prefer if we could hide the actual channel so the client and

>consumer would not have to negotiate it.



In order to hide the channel, COAS servers would have to implement, or proxy, the core functionality of the Notification service.  This extra work would make sense if most COAS servers needed to override the behavior of the Notification service.  But I suggest that the 80% case is simple: COAS servers will make good use of the basic Notification service, and not need to specialize it.


Furthermore, it isn't clear to me how to proxy the PIDS "Notification" IDL with an instance of an off-the-shelf Event Service or Notification service.  Will it be very easy?  The difference seems to indicate considerable work for a COAS server that just wants a "vanilla" event mechanism.


For the relatively small number of COAS servers that want to specialize, they can implement/override the Channel that they hand out with a "getChannel()" call.  (See below for some implementation details of such a specialization**.)



>

>> * Testability:  the event mechanism needs some test convention ...

>>	void pushTestEvent( in UserId userId );

>

>This sounds like more of an implementation issue.  I don't understand

>the need for standardizing it.



Testing pushed events is more complex than testing a query mechanism, and requires some standarization.  In the first step of the pushed-event mechanism, the consumer subscribes for events of interest, and begins listening.  What if this client is behind a firewall, where an incoming (new) TCP connection cannot reach?  The client may listen in vain, ignorant of the problem, assuming that there have been no events of interest.


To test across heterogeneous servers, COAS needs a standard test event, and clients need a standard way of causing a COAS server to generate that test event.


It can be considered an implementation issue, but if this standard infrastructure is not present, how will clients know their runtime setup is capable of receiving requested events?


I suggest that a test will be "de rigueur" at the first connection of every COAS client.



>>>> (from Coas.rtf)

<excerpt>The Notification Service specification does not contain a mechanism for event filters to be applied at the source (original supplier) of the event.  The capability to filter at the source is needed for sources that publish a large number of events where very few are subscribed to.

</excerpt><<<<<<<<


As I interpret the Notification spec. from pg. 63, the service seems to provide access to subscription & filter information:


	In order to convey end-to-end the knowledge of what is required

	from suppliers, and what might be produced by them, we introduce two

	complementary operations, offer_change and subscription_change.


Pg. 64 continues:


	Suppliers may also discover the current set of event types that

	consumers of a channel require by calling the obtain_subscription_types

	operation on the ProxyConsumer interface.

	Suppliers that are not interested in the event types currently

	subscribed to will not invoke obtain_subscription_types, and will

	raise the NO_IMPLEMENT exception in their implementation of the

	subscription_change operation.



I joked earlier that the Notification service "does it all".  Of course there are cases where it falls short, and we are anxious to see a real implementation of the service.  However, the main point I seek to make is that we need to estimate the universe of COAS servers and design for the majority.


As always, I look forward to hearing from you and benefiting from your explanations.


larry


----------------------


**DETAILS ON IMPLEMENTING/OVERRIDING EVENT SERVICE


Here is the code for a client to subscribe to an event channel, from Philips' working prototype.  "channel" below could be the result of a getChannel() call in some COAS server.


           EventsListener listener = new EventsListener( "EventsListener", orb );


    	    boa.obj_is_ready( listener );


    	    try

    	    {


    	      	ProxyPushSupplier proxySupplier =

    	      					channel.for_consumers().obtain_push_supplier();


    	        proxySupplier.connect_push_consumer( listener );



    	    } catch ( Exception e ) {

        		Debug.dbg( 1, "Trouble with channel registry: " + e);

    			Debug.printStackTrace( e );

    	    }


So in order to "spoof" a simple event service, a COAS server would have to implement the EventChannel interface at least enough to provide a ProxyPushSupplier and intermediate object in response to a for_consumers().obtain_push_supplier() call.


This is a minimum, but seems a reasonable direction for a COAS server that wants to do some behavior beyond what an Event or Notification service offers.</x-rich>X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 15 May 1998 10:21:42 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: event mechanism

<x-rich>Tim,


Thanks for the feedback on events and new suggestions.  The design
direction you outline is coherent, but it seems to rest on the assumption
that most COAS servers will want to specialize the Notification service.
Is that the best guess?



>I would prefer if we could hide the actual channel so the client and

>consumer would not have to negotiate it.



In order to hide the channel, COAS servers would have to implement, or
proxy, the core functionality of the Notification service.  This extra
work would make sense if most COAS servers needed to override the
behavior of the Notification service.  But I suggest that the 80% case is
simple: COAS servers will make good use of the basic Notification
service, and not need to specialize it.


Furthermore, it isn't clear to me how to proxy the PIDS "Notification"
IDL with an instance of an off-the-shelf Event Service or Notification
service.  Will it be very easy?  The difference seems to indicate
considerable work for a COAS server that just wants a "vanilla" event
mechanism.


For the relatively small number of COAS servers that want to specialize,
they can implement/override the Channel that they hand out with a
"getChannel()" call.  (See below for some implementation details of such
a specialization**.)



>

>> * Testability:  the event mechanism needs some test convention ...

>>	void pushTestEvent( in UserId userId );

>

>This sounds like more of an implementation issue.  I don't understand

>the need for standardizing it.



Testing pushed events is more complex than testing a query mechanism, and
requires some standarization.  In the first step of the pushed-event
mechanism, the consumer subscribes for events of interest, and begins
listening.  What if this client is behind a firewall, where an incoming
(new) TCP connection cannot reach?  The client may listen in vain,
ignorant of the problem, assuming that there have been no events of
interest.


To test across heterogeneous servers, COAS needs a standard test event,
and clients need a standard way of causing a COAS server to generate that
test event.


It can be considered an implementation issue, but if this standard
infrastructure is not present, how will clients know their runtime setup
is capable of receiving requested events?


I suggest that a test will be "de rigueur" at the first connection of
every COAS client.



>>>> (from Coas.rtf)

<excerpt>The Notification Service specification does not contain a
mechanism for event filters to be applied at the source (original
supplier) of the event.  The capability to filter at the source is needed
for sources that publish a large number of events where very few are
subscribed to.

</excerpt><<<<<<<<


As I interpret the Notification spec. from pg. 63, the service seems to
provide access to subscription & filter information:


	In order to convey end-to-end the knowledge of what is required

	from suppliers, and what might be produced by them, we introduce two

	complementary operations, offer_change and subscription_change.


Pg. 64 continues:


	Suppliers may also discover the current set of event types that

	consumers of a channel require by calling the obtain_subscription_types

	operation on the ProxyConsumer interface.

	Suppliers that are not interested in the event types currently

	subscribed to will not invoke obtain_subscription_types, and will

	raise the NO_IMPLEMENT exception in their implementation of the

	subscription_change operation.



I joked earlier that the Notification service "does it all".  Of course
there are cases where it falls short, and we are anxious to see a real
implementation of the service.  However, the main point I seek to make is
that we need to estimate the universe of COAS servers and design for the
majority.


As always, I look forward to hearing from you and benefiting from your
explanations.


larry


----------------------


**DETAILS ON IMPLEMENTING/OVERRIDING EVENT SERVICE


Here is the code for a client to subscribe to an event channel, from
Philips' working prototype.  "channel" below could be the result of a
getChannel() call in some COAS server.


           EventsListener listener = new EventsListener(
"EventsListener", orb );


    	    boa.obj_is_ready( listener );


    	    try

    	    {


    	      	ProxyPushSupplier proxySupplier =

    	      					channel.for_consumers().obtain_push_supplier();


    	        proxySupplier.connect_push_consumer( listener );



    	    } catch ( Exception e ) {

        		Debug.dbg( 1, "Trouble with channel registry: " + e);

    			Debug.printStackTrace( e );

    	    }


So in order to "spoof" a simple event service, a COAS server would have
to implement the EventChannel interface at least enough to provide a
ProxyPushSupplier and intermediate object in response to a
for_consumers().obtain_push_supplier() call.


This is a minimum, but seems a reasonable direction for a COAS server
that wants to do some behavior beyond what an Event or Notification
service offers.

</x-rich>
Sender: tim@protocol.com
Date: Fri, 15 May 1998 14:15:15 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: getX/getY examples

Larry Hamel wrote:
> Let's say that we want to get information about an image study, represented
> by the struct "Study":
>
>     struct Study {
>         ObjectID            studyObjectID;
>         sequence<string>    modality;
>         ...
>         sequence<ImageSet>  sets;
>     };
>
> On a server with "getX" functions, there would be a function call to
> retrieve a study, something like
>
>         Study getStudy( ..., StudyID id );
>
> Likewise, if you wanted to get an image, you'd call something like
>
>         Image getImage( ..., StudyID id, ImageID id );

This is consistent with what I was thinking.  Looks like words got in
the way of us communicating ;-)

> Each function returns a specific type, without a union, Any, or base
> classs.  There is no ConceptCode in the parameter list of these functions.
> The parameter list of each function is "custom" to the function.

The ConceptCode or medical concept would likely be logically connected
to the StudyId.  Maybe not explicately but implicately.

> Let me know if this isn't clear.

It is clear for me now.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard.vcf"
Sender: tim@protocol.com
Date: Fri, 15 May 1998 15:58:33 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
CC: coas@baptisthealth.net
Subject: Re: COAS: event mechanism

Larry Hamel wrote:
>
> Tim,
>
> Thanks for the feedback on events and new suggestions. The design direction you outline is coherent, but it seems to rest on the assumption that most COAS servers will want to specialize the Notification service. Is that the best guess?


What we worked on in PIDS does inherit from some of the Notification
Service endpoints.  For COAS we might be able to take a different angle
on it.

The last revision of the Notification Service I read all the way through
did not indicate the semantics of mapping between anys and structured
events from incoming to outgoing connections (and vice versa).  If we
use anys for COAS maybe we should say the any carries a structured event
or something like that so that filtering can be done on it.


Tim
Attachment Converted: "c:\program files\eudora\attach\vcard1.vcf"
X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 15 May 1998 16:30:15 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: COAS: event mechanism

At 03:58 PM 5/15/98 -0700, Tim Brinson wrote:

>If we use anys for COAS maybe we should say the any carries a structured
event
>or something like that so that filtering can be done on it.
>


I agree, structured events seem superior.  They have a name-value section
at the top, for filtering, and an "Any" for the variable content.

struct StructuredEvent {

   EventHeader header;
   FilterableEventBody filterable_data;
   any remainder_of_body;

};


larry

X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 18 May 1998 00:48:09 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Final(?) draft of initial submission

I have placed the final(?) draft of our initial COAS submission document
at http://www.protocol.com/engineering/corbamed/coas/incoming
I welcome all suggestions for [small] changes, etc. if they arrive
before 12:00 noon Pacific Daylight Time (3:00 pm EDT, 8:00 pm GDT).
I have to submit the document to the OMG (electronically) before 5:00 pm
EDT (2:00 pm PDT).

The document name is coas.rtf
(I appologize if you can not read an .rtf file,
I have not been able to get Word and Adobe Acrobat to work together
on my NT 4.0 system in order to generate a .pdf file.  I will
continue to try on Monday.
a coas.pdf file if any of you need / want that format.)

All comments, suggestions, chapters, etc. are welcome.

Chuck Carman


Sender: tim@protocol.com
Date: Tue, 19 May 1998 08:39:05 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Bill Billings <ebillings@Oceania.com>
CC: COAS <coas@baptisthealth.net>
Subject: Re: Government CPR project kicks off

Bill Billings wrote:
>
> Tim
>
> We met a while back and I would like to re-connect with you regarding
> Oceania's work and getting more involved with CORBAmed.  Let me know how
> I can reach you via telephone.
>
> Edmund Billings, MD
> VP, Product Management
> Oceania
> 415-812-3016

Bill,

As per our discussion yesterday I am sending you the information you
asked for.  The URL for the Clinical Observations Access Service (COAS)
RFP status is at:

	http://www.omg.org/library/schedule/Clinical_Observations_RFP.htm

As you can see at that URL there is one initial submission team.  You
can access the initial submission from that URL too.  As I mentioned
there is still a lot to do and your involvement with the HL7 SGMLSIG
could help us incorporate that work.  CORBAmed has a formal liaison with
HL7 but the true liaison work is having members in common.  We do have
many members in common with HL7 SIGOBT, MPISIG, Control/Query, SECSIG,
etc. but not as many from SGMLSIG.  I did hear that at the last HL7
meeting some people from Sequoia and L&H are interested in contributing
but I have not heard from them directly.

The COAS submission team has an open door policy for allowing others to
participate.  If you or someone else at Oceania would like to be
involved with the COAS submission just send an email to
coas@baptisthealth.net indicating so.  Everyone involved is listed in
the submission under their company/organization name or individual name
as they wish.


Regards,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard12.vcf"
Date: Wed, 20 May 1998 12:24:09 -0400 (EDT)
From: Mary Kratz <mkratz@umich.edu>
X-Sender: mkratz@seawolf.rs.itd.umich.edu
To: coas@baptisthealth.net, Charles Carman <ccarman@medgrid.philips.com>
cc: Tim Brinson <tim@protocol.com>
Subject: Re: Time for our International Teleconference calls

Well, to answer Chuck's question...no time like the present to get the
next COAS Conference Call scheduled.

I have set up a call for May 26, 1998 from 1100 EDT (0800 PDT and I think
1600 GMT) until 1300 EDT.

This service is a "meet-me" conference service.  Your number will be
charged for a phone call to participate in the conference call.

The number to dial into is +1 (734)647-2802.  We are currently under the
area code change, so if the (734) exchange does not work try
(313)647-2802.  (734) should work, but just in case try (313).

May 26 is a very busy day for conference calls.  There is a call scheduled
from 0900-1100 EDT.  If we dial in and they are still on the line, we can
let them know that we have the line scheduled at 1100.

Feel free to contact me with any further questions or concerns.  I trust
one of the submittors will be putting together the agenda for the call.

Thanks,
Mary

-----------------------------------------------------------------
Mary E. Kratz
University of Michigan Health System
Medical Center Information Technology - Special Projects Division
4251 Plymouth Road, Suite 3300
Ann Arbor, MI 48105-2785
mkratz@umich.edu
v:(313)763-6871 f:(313)763-0629


On Wed, 20 May 1998, Charles Carman wrote:

> Tim and Mary,
>
> Thank you for proposing/offering to have the COAS teleconference calls
> use the UMich service.  Philips is not interested in controlling the
> process to the extent of paying for all of the teleconference calls.
> We gladly accept the offer, and propose that we use the service for
> the call tentatively scheduled for Tuesday, 26 May, 1998 at 8:00 am PDT,
> 10:00 am CDT, 11:00 am EDT.
> I have heard affirmative responces about the new time from only Tim,
> and the two British contributors.
> By what point should we just say, "This is when it is scheduled!"?
>
> Chuck
>
> At 12:09 PM 5/19/98 -0700, you wrote:
> >Chuck,
> >
> >See the attached messages.  Mary has set up many conference calls for
> >corbamed related stuff.  It is free and I don't think anyone minds
> >having to pay for their call into the conference.  On the otherhand if
> >Philips does not mind carrying the cost in order to have more direct
> >control continue to use the service you are.
> >
> >Cheers,
> >
> >TimReturn-Path: <mkratz@umich.edu>
> >Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
> >	id LAA24988; Tue, 19 May 1998 11:41:08 -0700
> >Received: by  protocol.com (SMI-8.6/SMI-SVR4)
> >	id LAA15717; Tue, 19 May 1998 11:41:07 -0700
> >Received: from berzerk.rs.itd.umich.edu(141.211.63.17) by iwall via smap
> (V2.0)
> >	id xma015701; Tue, 19 May 98 11:41:02 -0700
> >Received: from qbert.rs.itd.umich.edu (smtp@qbert.rs.itd.umich.edu
> [141.211.63.94])
> >        by berzerk.rs.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id
> OAA27060
> >        for <tim@protocol.com>; Tue, 19 May 1998 14:41:00 -0400 (EDT)
> >Received: from localhost (mkratz@localhost)
> >	by qbert.rs.itd.umich.edu (8.8.8/5.1-client) with SMTP id OAA02668
> >	for <tim@protocol.com>; Tue, 19 May 1998 14:41:00 -0400 (EDT)
> >Precedence: first-class
> >Date: Tue, 19 May 1998 14:41:00 -0400 (EDT)
> >From: Mary Kratz <mkratz@umich.edu>
> >X-Sender: mkratz@qbert.rs.itd.umich.edu
> >To: Tim Brinson <tim@protocol.com>
> >Subject: Re: [Fwd: Time for our International Teleconference calls]
> >In-Reply-To: <3561B624.B2431E8@protocol.com>
> >Message-ID: <Pine.SOL.3.95.980519143901.6778H-100000@qbert.rs.itd.umich.edu>
> >MIME-Version: 1.0
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Tim-
> >
> >Not a problem.  The service at the University is free of charge (at least
> >to our department).  The operator tells me it is a University wide service
> >and not a problem to set up the "meet-me" conference calls.  The Philips
> >system is an 800 service, I think...so the call participants don't have to
> >pay.  With the Meet-Me system, each participant has to pay to phone in.
> >
> >Just let me know, it only takes a moment to set up a call with the
> >operator.
> >
> >-Mary
> >
> >-----------------------------------------------------------------
> >Mary E. Kratz
> >University of Michigan Health System
> >Medical Center Information Technology - Special Projects Division
> >4251 Plymouth Road, Suite 3300
> >Ann Arbor, MI 48105-2785
> >mkratz@umich.edu
> >v:(313)763-6871 f:(313)763-0629
> >
> >
> >On Tue, 19 May 1998, Tim Brinson wrote:
> >
> >> Cm,
> >>
> >>
> >> When I hosted a concall for PIDS it cost a few hundred dollars and that
> >> was by using a discount service.  I don't know if that is of any concern
> >> for Philips.  If it is could umich do it?  Knowing how crazy it is there
> >> I hate to even suggest such a thing.  Don't worry about it now as I have
> >> not heard Philips complain yet.  Just keep it in mind.
> >>
> >>
> >> thanx,
> >>
> >> Ct
> >
> >Attachment Converted: "c:\program files\eudora\attach\vcard56.vcf"
> >
>


Sender: tim@protocol.com
Date: Wed, 20 May 1998 10:24:33 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: Orlando meeting

At the last conference call we talked about having a submitters meeting
on the Monday evening in Orlando (8 June) sometime around 5:00 or 6:00.
This would be to prepare for the presentation on Wednesday.

Does this sound like a good time?  Should we use this time to discuss
the issues too or just prepare for the presentation?  Should this just
be the submitters or also include the other contributors/supporters?

It now sounds like we may not need to delay the LOI and Initial
Submission deadline.  Does anyone know of another organization
interested in submitting?

We should plan to have a submitters meeting for 2-3 days toward the end
of June or in July before Helsinky.  When is a good time for others and
where would be the preferred location?  I have talked to Steve Tufty
(Pop) my Manager about Protocol hosting the meeting.  If people would
not mind coming to Portland we might be able to do that.  We will try to
find a nice place in the mountains that would be a short drive from the
airport.

Would people be interested in that?  I will start collecting information
about it on this end and see what Protocol could spring for.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard.vcf"
Sender: tim@protocol.com
Date: Wed, 20 May 1998 14:08:04 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: The COAS voter list closes 1 June!!!

Everyone PLEASE sign up if your organization is an OMG member.  Just
send a message to juergen@omg.org asking him to put your organization on
the COAS voter list.

If you do not do this you will not be able to vote for COAS in CORBAmed
when it comes down to a final submission.Return-Path: <juergen@omg.org>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id KAA17390; Wed, 20 May 1998 10:19:20 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id KAA22583; Wed, 20 May 1998 10:19:19 -0700
Received: from emerald.omg.org(192.67.184.65) by iwall via smap (V2.0)
	id xma022579; Wed, 20 May 98 10:19:18 -0700
Received: from bronze.omg.org by emerald (SMI-8.6/SMI-SVR4)
	id LAA03834; Wed, 20 May 1998 11:53:15 -0400
Message-Id: <3.0.32.19980520114327.009f7278@emerald.omg.org>
X-Sender: juergen@emerald.omg.org
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 20 May 1998 11:43:28 -0400
To: ptc@omg.org, dtc@omg.org, bom@omg.org, corbamed@omg.org, finance@omg.org,
        ec@omg.org
From: Juergen Boldt <juergen@omg.org>
Subject: A Reminder
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Another reminder from OMG staff:


The following deadlines will pass prior to the Orlando Meeting:

June 1 1998:

Risk Management RFI		Responses due
BOCA RTF			Comments due
Calendar Facility RFP	Voting List closes
Clinical Observatios RFP	Voting List closes


The following deadlines will pass during the Orlando meeting:

June 8 1998:

Negotiation Facility RFP		Initial Submissions due
Healthcare Claims Facility RFP	Initial Submissions due

June 12 1998:

Healthcare data Interpretation RFP		LOIs due
Pharmacy Interaction RFP			Voting List closes
================================================================

Juergen Boldt
Technical Process Manager

Object Management Group		Tel. +1-508-820 4300  ext. 132
Framingham Corporate Center		Fax: +1-508-820 4303
492 Old Connecticut Path		Email: juergen@omg.org
Framingham, MA 01701

================================================================

Attachment Converted: "c:\program files\eudora\attach\vcard1.vcf"
X-Mailer: Novell GroupWise 5.2
Date: Wed, 20 May 1998 16:08:47 -0600
From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
To: coas@baptisthealth.net, tim@protocol.com
Subject: Re: Orlando meeting

Answers are interlaced below

>>> Tim Brinson <tim@protocol.com> 05/20 11:24 AM >>>
At the last conference call we talked about having a submitters meeting
on the Monday evening in Orlando (8 June) sometime around 5:00 or 6:00.
This would be to prepare for the presentation on Wednesday.

Does this sound like a good time?  Should we use this time to discuss
the issues too or just prepare for the presentation?  Should this just
be the submitters or also include the other contributors/supporters?

> This is a good time for me.
> I would suggest that we handle the presentation stuff first, and then if we have time run over any issues.

It now sounds like we may not need to delay the LOI and Initial
Submission deadline.  Does anyone know of another organization
interested in submitting?

> None.

We should plan to have a submitters meeting for 2-3 days toward the end
of June or in July before Helsinky.  When is a good time for others and
where would be the preferred location?  I have talked to Steve Tufty
(Pop) my Manager about Protocol hosting the meeting.  If people would
not mind coming to Portland we might be able to do that.  We will try to
find a nice place in the mountains that would be a short drive from the
airport.

> End of June is good for me. Your place sounds good especially the mountains.

Would people be interested in that?  I will start collecting information
about it on this end and see what Protocol could spring for.


Cheers,

Tim


X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 20 May 1998 18:57:06 -0700
To: Tim Brinson <tim@protocol.com>, COAS <coas@baptisthealth.net>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: Orlando meeting

At 10:24 AM 5/20/98 -0700, Tim Brinson wrote:
>At the last conference call we talked about having a submitters meeting
>on the Monday evening in Orlando (8 June) sometime around 5:00 or 6:00.
>This would be to prepare for the presentation on Wednesday.

Good time.  Chuck and I will be there.

>
>Does this sound like a good time?  Should we use this time to discuss
>the issues too or just prepare for the presentation?  Should this just
>be the submitters or also include the other contributors/supporters?

Let's do the presentation first, then issue discussion s time permits.
>
>It now sounds like we may not need to delay the LOI and Initial
>Submission deadline.  Does anyone know of another organization
>interested in submitting?

Not I.

>
>We should plan to have a submitters meeting for 2-3 days toward the end
>of June or in July before Helsinky.  When is a good time for others and
>where would be the preferred location?  I have talked to Steve Tufty
>(Pop) my Manager about Protocol hosting the meeting.  If people would
>not mind coming to Portland we might be able to do that.  We will try to
>find a nice place in the mountains that would be a short drive from the
>airport.

We can come to Portland.  Or we'll be glad to host the meeting in Mountain
View, CA.  Mid-July is best.  It's questionable about going to Helsinki,
however.  Too far, too costly, too many vacations, and the turnout in
Manchester does not fill me with hope about a productive meeting there.

>
>Would people be interested in that?  I will start collecting information
>about it on this end and see what Protocol could spring for.
>
>
>Cheers,
>
>Tim
>Attachment Converted: "c:\eudora\attach\vcard13.vcf"
>
_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

X-Sender: bobg@mailhost.medgrid.philips.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 25 May 1998 14:08:07 -0700
To: coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: PIDS and COAS

Hi All,

I've been out of the loop for a bit, so pardon me if this has already been
discussed/addressed in our submitter's group:

A fully distributed CPR may grow to have a very large number of COAS server
objects; potentially one or more of any type (e.g. vital signs) in a given
hospital, clinic or other provider setting.  Any given patient, however,
will only have records in a small subset of these "domains", and it will be
useful to use the PIDS service (correllation  manager) to determine up
front (i.e. at patient selection time) which domains have relevant data.
This leads to two conclusions:

1.  PIDS domains should ideally be defined so that there is only one COAS
server object for any given type of data per domain.  This is not an
absolute requirement, but would be quite helpful in the above scenario.

2. COAS should recognize PIDS domains, so that only COAS objects in the
relevant domains need be accessed for clinical data.  This means that COAS
should support a PIDS-compliant domain interface, and that all other
instances of clinical observations type interfaces (e.g. CIAS) should use
this COAS service to present the domain that they represent to clients, to
the naming service, and to the trader service.  There should also be a
notification interface when a new patient's observation data is first known
witin a domain.  All clients can subscribe to this interface filtered by
the patient(s) they are concerend eith; therefore, clients may know about
new domains after patient selection time within any one "session".

With these features, a client application need not poll every object in the
universe which handles say vital signs data to see if they have any data
for the patient(s) that the client is concerned with.  Rather, the client
first uses PIDS to establish which domains the patient(s) is(are) known in,
and then uses some COAS service to attach only to those servicers of vital
signs data that have information relvant to that patient(s) (i.e. without
having to poll every such object instance in the universe).

What do you all think?  Any ideas on how to implement this?

_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Sender: tim@protocol.com
Date: Tue, 26 May 1998 11:15:15 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Conference Call Notes

Thanx to Mary Kratz for setting up the call.

Attendees:
	Mary Richards (HBOC);
	Tim Brinson (Protocol Systems);
	Juggy and Tad (CareFlow|Net);
	Howard Chase (IDX);
	Paul Biron (Kaiser Permanente);
	Tom Culpepper (3M).

On the conference call today we discussed Bob's new scenerio about
federation and we discussed some ideas about the XML work being done in
HL7.  We determined that a major goal for Orlando is to get a scoping on
COAS from the submitters as well as the whole CORBAmed body.  It was
proposed that getting use scenerios and melding the various object/data
models are two key things we need to do early on (read 'NOW').

The following action items were brought up on the conference call:

- Everyone should provide use scenerios and/or use cases before the
Orlando meeting.  These are CRITICAL in order to make sure COAS meets
various needs.

- There will be a COAS submitters meeting on Monday 8 June in Orlando
(to prepare for the Wednesday afternoon presentation to CORBAmed).  I
will contact Cheryl at the OMG to see if they can arrange a room.

- Tom Culpepper and Mary Richards are going to see if they can share
their corporate models with the group.

- Mary is going to see if Ted Klein (HBOC) can participate to represent
the HL7 3.0 modeling work.

- Bob Glicksman will share Philips observations model with the group,
which is a trimmed down HL7 model supplemented by some DICOM aspects.

- Bob Glicksman will add the federation as one of the issues in the
submission and/or add it as one of the use scenerios.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard2.vcf"
Sender: tim@protocol.com
Date: Tue, 26 May 1998 11:27:20 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: Richard Dixon's Email

Does any one know if Richard Dixon is having email problems or do we
have the wrong address for him?  Four messages I had sent to the COAS
list bounced on his name.  The address said:

	<R.M.Dixon@comhealth.hull.ac.uk>
Attachment Converted: "c:\program files\eudora\attach\vcard3.vcf"
Sender: tim@protocol.com
Date: Tue, 26 May 1998 12:15:05 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: Re: PIDS and COAS

Bob Glicksman wrote:
> A fully distributed CPR may grow to have a very large number of COAS server
> objects; potentially one or more of any type (e.g. vital signs) in a given
> hospital, clinic or other provider setting.  Any given patient, however,
> will only have records in a small subset of these "domains", and it will be
> useful to use the PIDS service (correllation  manager) to determine up
> front (i.e. at patient selection time) which domains have relevant data.

I think the Correlation Mgr could be used to determine which domains
MIGHT have data by the fact they can identify the person.  I'm not sure
that it can determine that it ACTUALLY has data for the patient though.
And if it does have data whether it is RELEVANT for the user's purpose.

On the conference call I wasn't sure if you meant that COAS would use
PIDS for doing federation or that COAS might also be able to do
federation in a way similar to how PIDS does it.  I think it would use
PIDS but also might do some of its own federation.  Just like in PIDS,
where a correlation domain implements its own ID Domain that is the
superset of the source domains, a client talking to a high level COAS
might (under some implementations) just see it as a single COAS.  The
COAS might be able to hide the fact there are other systems out there
that it is getting information from.

On the other hand the high level COAS might be able to give summary
information about the information and pass back an object reference to
the low level COAS that has the actual information (and probably the
patient's ID in that domain).

I feel the COAS specification should allow both scenerios and
implementers choose the best one for a particular problem.  Does this
fit into what you were thinking?


> This leads to two conclusions:
>
> 1.  PIDS domains should ideally be defined so that there is only one COAS
> server object for any given type of data per domain.  This is not an
> absolute requirement, but would be quite helpful in the above scenario.

Within a hospital there are typically multiple vital signs monitoring
systems by different vendors and hopefully each would be in one ID
Domain.  I think what you are saying there could be a separate system
that might federate over them to make it be perceived as one server.

Yes I believe COAS should support such an architecture.  As you say COAS
would not have to require that a hospital architect it that way.


> 2. COAS should recognize PIDS domains, so that only COAS objects in the
> relevant domains need be accessed for clinical data.  This means that COAS
> should support a PIDS-compliant domain interface, and that all other
> instances of clinical observations type interfaces (e.g. CIAS) should use
> this COAS service to present the domain that they represent to clients, to
> the naming service, and to the trader service.

This is a question I started asking myself over the weekend - 'Should
each COAS instance belong to exactly one ID Domain?'.  In our
specification of COBS it was associated with exactly one ID Domain.  For
our use as a vital signs server that has worked out good.  I don't know
what is the best when we get into these very large domains that are
being federated.  It seems elegant if we could keep it to one ID Domain
per COAS instance.


> There should also be a
> notification interface when a new patient's observation data is first known
> witin a domain.  All clients can subscribe to this interface filtered by
> the patient(s) they are concerend eith; therefore, clients may know about
> new domains after patient selection time within any one "session".

Agree.  The Notification Service has a way to define parameterized Event
Types.  I believe this would be one of the Event Types we need to define
in COAS.


> With these features, a client application need not poll every object in the
> universe which handles say vital signs data to see if they have any data
> for the patient(s) that the client is concerned with.  Rather, the client
> first uses PIDS to establish which domains the patient(s) is(are) known in,
> and then uses some COAS service to attach only to those servicers of vital
> signs data that have information relvant to that patient(s) (i.e. without
> having to poll every such object instance in the universe).

I think this is one of the scenarios COAS needs to support as well.
This is a little different scenario from the one I talked about above,
where a COAS server might do some of that for the client (such as know
what kinds of records are located at the different locations for the
patient).


> What do you all think?  Any ideas on how to implement this?

Hopefully I have helped answer a little of both (maybe generated more
questions than I answered ;-)


Regards,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard4.vcf"
Sender: tim@protocol.com
Date: Tue, 26 May 1998 12:49:51 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>, COAS <coas@baptisthealth.net>
Subject: Re: COAS Conference Call Notes

Larry Hamel wrote:
>
> Tim,
>
> it looks like you missed attendee Bob Glicksman.  Chuck and I were there
> also, but not at the opening bell...

Thank for catching that one.  Yes Bob was there but I didn't know you
and Chuck made it.

> also, the Philips/Caredata model was already emailed to this list.  didn't
> you get it?  i can reforward if you like.  it should probably sit on your
> COAS http server...  along with archives of these messages...

I just looked back in my inbox and found it.  thanx.
Attachment Converted: "c:\program files\eudora\attach\vcard6.vcf"
X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 26 May 1998 16:34:40 -0700
To: Tim Brinson <tim@protocol.com>, COAS <coas@baptisthealth.net>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: PIDS and COAS

Some comments back from bobg:

At 12:15 PM 5/26/98 -0700, Tim Brinson wrote:
>Bob Glicksman wrote:
>> A fully distributed CPR may grow to have a very large number of COAS server
>> objects; potentially one or more of any type (e.g. vital signs) in a given
>> hospital, clinic or other provider setting.  Any given patient, however,
>> will only have records in a small subset of these "domains", and it will be
>> useful to use the PIDS service (correllation  manager) to determine up
>> front (i.e. at patient selection time) which domains have relevant data.
>
>I think the Correlation Mgr could be used to determine which domains
>MIGHT have data by the fact they can identify the person.  I'm not sure
>that it can determine that it ACTUALLY has data for the patient though.
>And if it does have data whether it is RELEVANT for the user's purpose.

Finding out which domains MIGHT have data is OK, it's actually just fine as
long as it includes all domains which DO have data (plus a few others).
This is probably right, as the usual use of PIDS will be in conjunction
with registrations.  A patient may of course be registered at a site but
not have any clinical data (no tests taken), but the converse should not be
true (it will be true, of course, in the real world, but oh well ....).

>
>On the conference call I wasn't sure if you meant that COAS would use
>PIDS for doing federation or that COAS might also be able to do
>federation in a way similar to how PIDS does it.  I think it would use
>PIDS but also might do some of its own federation.  Just like in PIDS,
>where a correlation domain implements its own ID Domain that is the
>superset of the source domains, a client talking to a high level COAS
>might (under some implementations) just see it as a single COAS.  The
>COAS might be able to hide the fact there are other systems out there
>that it is getting information from.
>

The issue is that a client, having found out which domains MIGHT have
clinical data, now must find out which domains actually have clinical data,
what data they have, and how to access this data.  This is the
functionality that I was proposing for COAS.  Whether or not COAS is used
to actually obtain the data, or another deata-type specific service is
used, is an open point for discussion (part fo the generalized get()
discussion).


>On the other hand the high level COAS might be able to give summary
>information about the information and pass back an object reference to
>the low level COAS that has the actual information (and probably the
>patient's ID in that domain).


I half agree.  A patient's ID in a domain should come from PIDS.  On the
other hand, the first part is correct.

>
>I feel the COAS specification should allow both scenerios and
>implementers choose the best one for a particular problem.  Does this
>fit into what you were thinking?
>

I think that we need to come to terms with how COAS fits in with CIAS, the
report RFP that Tad is working on, etc.

>
>> This leads to two conclusions:
>>
>> 1.  PIDS domains should ideally be defined so that there is only one COAS
>> server object for any given type of data per domain.  This is not an
>> absolute requirement, but would be quite helpful in the above scenario.
>
>Within a hospital there are typically multiple vital signs monitoring
>systems by different vendors and hopefully each would be in one ID
>Domain.  I think what you are saying there could be a separate system
>that might federate over them to make it be perceived as one server.

No.  I THINK that I am happy with each monitoring system being its own
domain.  Why -- because a patient isn't likely to have vital signs data in
many different monitoring systems, even if there are many such systems in
the hospital.  Note:  I'm not talking here about monitoring devices; I'm
talking about persistent data storage servers (e.g. your Accuity server).
If a patient is moved form an acute unit to a sub-acute unit and get vital
signs recorded in both, and if these have different vital signs servers,
well what the heck -- there's two server objects just for this "encounter"
for vital signs (as well as one or more for images and one for labs, etc.
The point here is to avoid having to poll thousands of COAS objects in an
enterprise to find the few that actually have anything useful.


>
>Yes I believe COAS should support such an architecture.  As you say COAS
>would not have to require that a hospital architect it that way.
>
>
>> 2. COAS should recognize PIDS domains, so that only COAS objects in the
>> relevant domains need be accessed for clinical data.  This means that COAS
>> should support a PIDS-compliant domain interface, and that all other
>> instances of clinical observations type interfaces (e.g. CIAS) should use
>> this COAS service to present the domain that they represent to clients, to
>> the naming service, and to the trader service.
>
>This is a question I started asking myself over the weekend - 'Should
>each COAS instance belong to exactly one ID Domain?'.  In our
>specification of COBS it was associated with exactly one ID Domain.  For
>our use as a vital signs server that has worked out good.  I don't know
>what is the best when we get into these very large domains that are
>being federated.  It seems elegant if we could keep it to one ID Domain
>per COAS instance.

The let's do this for now.  It might mean a 2x or even 3x hit on the number
of objects to be queried to get all of a patient's data, but this is not a
big deal.  What I'm trying to avoid is querying thousands of server objects
just to get to the ten or so that actually have data in them.  This would
be an untenably bit hit!!!!

>
>
>> There should also be a
>> notification interface when a new patient's observation data is first known
>> witin a domain.  All clients can subscribe to this interface filtered by
>> the patient(s) they are concerend eith; therefore, clients may know about
>> new domains after patient selection time within any one "session".
>
>Agree.  The Notification Service has a way to define parameterized Event
>Types.  I believe this would be one of the Event Types we need to define
>in COAS.
>
>
>> With these features, a client application need not poll every object in the
>> universe which handles say vital signs data to see if they have any data
>> for the patient(s) that the client is concerned with.  Rather, the client
>> first uses PIDS to establish which domains the patient(s) is(are) known in,
>> and then uses some COAS service to attach only to those servicers of vital
>> signs data that have information relvant to that patient(s) (i.e. without
>> having to poll every such object instance in the universe).
>
>I think this is one of the scenarios COAS needs to support as well.
>This is a little different scenario from the one I talked about above,
>where a COAS server might do some of that for the client (such as know
>what kinds of records are located at the different locations for the
>patient).
>
>
>> What do you all think?  Any ideas on how to implement this?
>
>Hopefully I have helped answer a little of both (maybe generated more
>questions than I answered ;-)
>
>
>Regards,
>
>Tim
>Attachment Converted: "c:\eudora\attach\vcard18.vcf"
>
_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Date: Wed, 27 May 1998 12:58:28 +0900
From: Robb Keayes <keayes.robb@nikon.co.jp>
Reply-To: keayes.robb@nikon.co.jp
Organization: Nikon Corportation
X-Mailer: Mozilla 4.05 [en] (Win95; I)
To: coas@baptisthealth.net
Subject: COAS?

Hello (Kent?),

I'd like some more information on the COAS submission, such as its
status and so on.  I understand that we (Nikon) are too late to join the
submission, but we would like to be able to contribute to the
intellectual process, even at this late date.  Please let me know where
I should look (URLS), and what mailing lists I should join.

Thanks

Robb Keayes
Nikon Corporation

Attachment Converted: "c:\program files\eudora\attach\vcard8.vcf"
Sender: tim@protocol.com
Date: Wed, 27 May 1998 08:31:01 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: keayes.robb@nikon.co.jp, Eric Navarro <ericn@baptisthealth.net>,
        COAS <coas@baptisthealth.net>
Subject: Re: COAS

Robb Keayes wrote:
>
> Tim,
>
> Thatnks for the document.  Could you send me info about joining the
> email list?  I will evaluate the document tomorrow (i hope) and get the
> LOI in, if I can review it with my manager, ASAP.

Eric,

Here is another person to add to the mail list.

	keayes.robb@nikon.co.jp


Rob,

That sounds great if you can get the LOI in.  Last week I heard of
another company that might put in a late LOI.  If either of you do
CORBAmed will have to vote in Orlando to extend the LOI deadline and
Initial Submission deadline to at least two weeks after Orlando.  We
have done that before in CORBAmed.  The only other requirement is that
your company needs to be a Domain Contributing member of OMG as well.
If you have any questions talk to the Jon Siegel or someone else at the
OMG.

Glad to see you are joining the submission.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard9.vcf"
Sender: tim@protocol.com
Date: Wed, 27 May 1998 09:01:24 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: FW: Internet PSIG Agenda for Orlando]

See the attached.  XML related.Return-Path: <wwilson@umich.edu>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id HAA14096; Wed, 27 May 1998 07:10:54 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id HAA03387; Wed, 27 May 1998 07:10:52 -0700
Received: from emerald.omg.org(192.67.184.65) by iwall via smap (V2.0)
	id xma003382; Wed, 27 May 98 07:10:51 -0700
Received: from runningman.rs.itd.umich.edu by emerald (SMI-8.6/SMI-SVR4)
	id JAA07577; Wed, 27 May 1998 09:50:59 -0400
Received: from umich.edu (wwilson-nt.mcit.med.umich.edu [141.214.64.72])
	by runningman.rs.itd.umich.edu (8.8.5/2.3) with ESMTP id JAA14605; Wed, 27 May 1998 09:44:34 -0400 (EDT)
Message-ID: <356C18A9.A64B834F@umich.edu>
Date: Wed, 27 May 1998 09:44:09 -0400
From: Wayne Wilson <wwilson@umich.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: juggy@careflow.com
CC: corbamed@omg.org
Subject: Re: FW: Internet PSIG Agenda for Orlando
References: <000001bd896e$00426100$404ef5cd@juggy.careflow.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

V. Juggy Jagannathan wrote:
>

> Folks,
>
> We have a tool kit called XML|IT which automatically tags CORBA service
> calls. Uses DII and Java and
> has utilities to convert Java structures to XML and back. Let me know if
> there is any interest in a presentation
> on this approach at Orlando.
>
Well, I for one am interested.  I am still trying to understand how XML
and objects are supposed to be related to one another.  My prelimnary
take is that XML via DOM can act as container for object based
components...is that substantially correct or is it totally ridiculous?

  By the way, what is DII, seems like I remember it being part of the
ORB plumbing for dynamic invocations.

Attachment Converted: "c:\program files\eudora\attach\vcard11.vcf"
Date: Thu, 28 May 1998 11:03:33 +0900
From: Robb Keayes <keayes.robb@nikon.co.jp>
Reply-To: keayes.robb@nikon.co.jp
Organization: Nikon Corportation
X-Mailer: Mozilla 4.05 [en] (Win95; I)
To: Kent Wreder <KENTW@BHSSF.ORG>, COAS <coas@baptisthealth.net>
Subject: Re: COAS? -Reply

Hello all,

I expect that many of you know me already, but for those who do not, my name is
Robb Keayes, and I am working with Nikon Corporation in Tokyo, Japan.  As a
manufacturer of precision microscopy equipment, we are interested in lab
results.  We see CORBA (distributed objects) as the future of computing and
thus see the COAS submission as important to our business.

At this point, I can't say that we are an *official* sumitter - I need to clear
this with my direct superiors and so on.  However, I wanted to join this
mailing list so that I can understand the goals of the COAS submission, and
where it is going. I need some ammunition to convince management that Nikon
needs to be involved in this, and this seemed like the best forum to do it in.
If you will allow me to lurk for a short time, I should be able to get things
moving over here (fingers crossed).

I notice that the submission has very general decriptions of results and that
sort of thing.  Is there any thinking going on about domain specific reports?
We of course are interested in pathology reporting and would be willing to
contribute to efforts to develop data content models for pathology.

BTW, I can't seem to find the LOI form on the OMG web site (actually, i usually
can't find *anything* on that site, so this comes as no surprise to me).  Does
anyone have a copy of the LOI form that they could email me?

Best  Regards,

Robb

PS - Kent, yes I am in Tokyo these days.

Attachment Converted: "c:\program files\eudora\attach\vcard12.vcf"
X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 28 May 1998 09:01:36 -0700
To: keayes.robb@nikon.co.jp, Kent Wreder <KENTW@BHSSF.ORG>,
        COAS <coas@baptisthealth.net>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS? -Reply

<<snip>>
>
>I notice that the submission has very general decriptions of results and that
>sort of thing.  Is there any thinking going on about domain specific reports?
>We of course are interested in pathology reporting and would be willing to
>contribute to efforts to develop data content models for pathology.
>
<<snip>>

Welcome to the team in any capacity, Robb.  The history behind COAS is that
we all realized that an attempt to standardize a clinical observations
interface for ALL of healthcare would be an emormous task and would
probably never reach fruition if we did it all at once.  Therefore, there
are separate RFPs in the works in CORBAmed for Image Access (CIAS), report
transcription (including report access), etc.  However, we thought that
there are certain common elements between these which ought to be the
subject of a single standard -- hence, COAS.

The original RFP called ONLY for these common elements (discovery,
notification, generalized get(), etc.) but the AB balked, saying that
without at least ONE concrete example, there could be no interoperability.
So, the final RFP asked for at least one concrete example, along with this
generic stuff.

So -- there is a choice to be made for pathology:  is this:

1. a second concrete example in our COAS submission (we are already
proposing vital signs),
2. the subject of another RFP (would you volunteer to draft up one?), or
3. perhaps already covered by CIAS or the TS (structured reporting), or
both -- so you might want to join the submitter(s) team(s) for one or both
of these after they are released.

>From my own experience working on the CAP image working group where DICOM
extensions for pathology were worked out (of which Nikon was an active
member -- John Harcourt?), I would say that CIAS and TS OUGHT to cover the
needs of pathology -- but I am not a domain expert here.  So, if you will
be in Orlando, PLEASE help out in these working groups and join an
appropriate submitter's teams for each!

P.S. LOI format is enclosed.

Attachment Converted: "c:\program files\eudora\attach\LOI.rtf"

_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 28 May 1998 11:48:51 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS: "from where" as part of return

y'all,

Should COAS return values have a "from where" attribute?

For example, consider a physician who brings up all the recent lab values
for patient Jones.  Jones has been seen recently at Baptist Hospital as
well as an emergency visit to Homestead Hospital.  The COAS reply to the
physician's client program, from a middleware COAS server acting as a
"router", combines the results from the hospitals, and the physician finds
it useful to see which result came from which source.

more later on federating COAS servers,

larry




X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 28 May 1998 13:06:26 -0700
To: Larry Hamel <larryh@medgrid.philips.com>, coas@baptisthealth.net
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS: "from where" as part of return

If there is one COAS per domain, this is not necessary.  If we elect a
federating model for COAS, then this will be quite important.  There are
many uses for having domain information with each item of clinical data.
For one, some domains may use use differing vocabularies than other
domains, so knowing the domain source of a data element will gove a pointer
to use with LQS to normalize the vocabulary.

 At 11:48 AM 5/28/98 -0700, Larry Hamel wrote:
>y'all,
>
>Should COAS return values have a "from where" attribute?
>
>For example, consider a physician who brings up all the recent lab values
>for patient Jones.  Jones has been seen recently at Baptist Hospital as
>well as an emergency visit to Homestead Hospital.  The COAS reply to the
>physician's client program, from a middleware COAS server acting as a
>"router", combines the results from the hospitals, and the physician finds
>it useful to see which result came from which source.
>
>more later on federating COAS servers,
>
>larry
>
>
>
>
>
_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

X-Sender: larryh@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 28 May 1998 18:41:51 -0700
To: coas@baptisthealth.net
From: Larry Hamel <larryh@medgrid.philips.com>
Subject: COAS email archive?

y'all,

is there any way to establish an email archive for the COAS list?  i have
all the old email, i think, in my fat eudora folders...

thanks,

larry

Sender: tim@protocol.com
Date: Fri, 29 May 1998 10:51:18 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: Your mail address]

Eric,

It looks like there is a problem getting from your ISP to Richard
Dixon's.  See the attached message from Richard.  Can you talk to your
ISP?  Do you have some of the bounced message replies?  Remember I had a
problem getting messages to the coas list a couple week ends back but
Philips messages got through OK.  Maybe this new problem is related
somehow to the old?

TimReturn-Path: <R.M.Dixon@comhealth.hull.ac.uk>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id EAA18565; Thu, 28 May 1998 04:16:13 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id EAA04743; Thu, 28 May 1998 04:16:12 -0700
Received: from lehar.ucc.hull.ac.uk(150.237.196.3) by iwall via smap (V2.0)
	id xma004739; Thu, 28 May 98 04:16:08 -0700
Received: from humus.ucc.hull.ac.uk by lehar.ucc.hull.ac.uk; Thu, 28 May 1998 12:16:07 +0100
Received: from w301 [150.237.79.180]
	by humus.ucc.hull.ac.uk with smtp (Exim 1.60 #1)
	id 0yf0fE-0007aR-00; Thu, 28 May 1998 12:16:04 +0100
From: "Richard Dixon" <R.M.Dixon@comhealth.hull.ac.uk>
To: "Tim Brinson" <tim@protocol.com>
Cc: <peter.nicklin@newcastle.ac.uk>
Subject: Re: Your mail address
Date: Thu, 28 May 1998 12:16:47 +0100
Message-ID: <01bd8a2a$1a89f430$b44fed96@w301.health.hull.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3

>I have attached the bounce messages that I received.  These were going
>through the COAS mail server in Florida.
>
>Hopefully this will work as I am sending directly to you.  Have you
>recieved a lot of messages from the COAS list in the last couple days?
>If not then there must still be a problem.  It looks like the messages
>queued up for ~4 days before finally bouncing.

I have had nothing from the COAS list since 19th May.  Clearly I have got
this one, and indeed anyone who sends direct to me seems to get through ok -
guess there must be a problem with the list server.  Any chance of
forwarding me anything I may have missed that's relevant?

I will download your document shortly and try to work on it tonight.

Richard

Attachment Converted: "c:\program files\eudora\attach\vcard13.vcf"
Sender: tim@protocol.com
Date: Fri, 29 May 1998 11:00:51 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: coas@baptisthealth.net
Subject: Re: COAS: "from where" as part of return

Bob Glicksman wrote:
>
> If there is one COAS per domain, this is not necessary.  If we elect a
> federating model for COAS, then this will be quite important.

The responsibilities for single domain access and federation would
likely be separate interfaces.  This way single domain servers don't
have to deal with concepts of federation.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard15.vcf"
Sender: tim@protocol.com
Date: Fri, 29 May 1998 11:04:53 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: Larry Hamel <larryh@medgrid.philips.com>
Subject: Re: posting models on Protocol site?

Larry Hamel wrote:
>
> Tim,
>
> can i post the philips data models sent out earlier on your COAS FTP site?
>
> larry

Yes.  Post any COAS relavent material there.
Attachment Converted: "c:\program files\eudora\attach\vcard14.vcf"
Date: Fri, 29 May 1998 11:09:27 -0700 (PDT)
From: Larry <larham@yahoo.com>
Subject: Re: [Fwd: Your mail address]
To: coas@baptisthealth.net

Mr. Dixon et al.,

a short-term workaround might be to get a free email account from any
of the "web browser email" suppliers, like yahoo.com, and subscribe
with that.  note that these accounts (at least the yahoo variety) can
be forwarded, so that if yahoo.com can get to you, (if this email
reaches you from this yahoo account) your forward will work.

i wonder if the dots on the left-hand side of the @ sign in address
"R.M.Dixon@comhealth.hull.ac.uk" are confusing the sendmail routers...

larry

philips medical


At 10:51 AM 5/29/98 -0700, Tim Brinson wrote:
>Eric,
>
>It looks like there is a problem getting from your ISP to Richard
>Dixon's.  See the attached message from Richard.  Can you talk to your
>ISP?  Do you have some of the bounced message replies?  Remember I
had a
>problem getting messages to the coas list a couple week ends back but
>Philips messages got through OK.  Maybe this new problem is related
>somehow to the old?
>
>TimReturn-Path: <R.M.Dixon@comhealth.hull.ac.uk>
>Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
>	id EAA18565; Thu, 28 May 1998 04:16:13 -0700
>Received: by  protocol.com (SMI-8.6/SMI-SVR4)
>	id EAA04743; Thu, 28 May 1998 04:16:12 -0700
>Received: from lehar.ucc.hull.ac.uk(150.237.196.3) by iwall via smap
(V2.0)
>	id xma004739; Thu, 28 May 98 04:16:08 -0700
>Received: from humus.ucc.hull.ac.uk by lehar.ucc.hull.ac.uk; Thu, 28
May 1998 12:16:07 +0100
>Received: from w301 [150.237.79.180]
>	by humus.ucc.hull.ac.uk with smtp (Exim 1.60 #1)
>	id 0yf0fE-0007aR-00; Thu, 28 May 1998 12:16:04 +0100
>From: "Richard Dixon" <R.M.Dixon@comhealth.hull.ac.uk>
>To: "Tim Brinson" <tim@protocol.com>
>Cc: <peter.nicklin@newcastle.ac.uk>
>Subject: Re: Your mail address
>Date: Thu, 28 May 1998 12:16:47 +0100
>Message-ID: <01bd8a2a$1a89f430$b44fed96@w301.health.hull.ac.uk>
>MIME-Version: 1.0
>Content-Type: text/plain;
>	charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 4.71.1712.3
>X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
>
>>I have attached the bounce messages that I received.  These were going
>>through the COAS mail server in Florida.
>>
>>Hopefully this will work as I am sending directly to you.  Have you
>>recieved a lot of messages from the COAS list in the last couple days?
>>If not then there must still be a problem.  It looks like the messages
>>queued up for ~4 days before finally bouncing.
>
>I have had nothing from the COAS list since 19th May.  Clearly I have
got
>this one, and indeed anyone who sends direct to me seems to get
through ok -
>guess there must be a problem with the list server.  Any chance of
>forwarding me anything I may have missed that's relevant?
>
>I will download your document shortly and try to work on it tonight.
>
>Richard
>
>Attachment Converted: "c:\program files\eudora\attach\vcard13.vcf"
>

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


Sender: tim@protocol.com
Date: Mon, 01 Jun 1998 13:20:46 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: A friendly reminder]

The COAS voting list closes today.  If you haven't already please sign
up your organization by sending a message to juergen@omg.org.Return-Path: <juergen@omg.org>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id HAA10394; Mon, 1 Jun 1998 07:52:44 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id HAA13721; Mon, 1 Jun 1998 07:52:39 -0700
Received: from emerald.omg.org(192.67.184.65) by iwall via smap (V2.0)
	id xma013693; Mon, 1 Jun 98 07:52:25 -0700
Received: from bronze.omg.org by emerald (SMI-8.6/SMI-SVR4)
	id JAA13994; Mon, 1 Jun 1998 09:53:56 -0400
Message-Id: <3.0.32.19980601094336.009fe280@emerald.omg.org>
X-Sender: juergen@emerald.omg.org
X-Mailer: Windows Eudora Pro Version 3.0 (32)
X-Priority: 2 (High)
Date: Mon, 01 Jun 1998 09:43:37 -0400
To: ptc@omg.org, dtc@omg.org, bom@omg.org, corbamed@omg.org
From: Juergen Boldt <juergen@omg.org>
Subject: A friendly reminder
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is a reminder from OMG staff:

The folowing deadlines will pass today, June 1 1998:

Risk Management RFI:			Responses due

Calender Facility RFP:		Voting List closes
Clinical Observations RFP		Voting List closes

BOCA RTF:				Comments due


-Juergen
================================================================

Juergen Boldt
Technical Process Manager

Object Management Group		Tel. +1-508-820 4300  ext. 132
Framingham Corporate Center		Fax: +1-508-820 4303
492 Old Connecticut Path		Email: juergen@omg.org
Framingham, MA 01701

================================================================

Attachment Converted: "c:\program files\eudora\attach\vcard18.vcf"
Sender: tim@protocol.com
Date: Tue, 02 Jun 1998 14:52:32 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: Response to COAS Submission Draft 3.1]

See attached message from Richard Dixon.  BTW, I started looking over
the GEHR object model last night.  It seems to have some usefulness as
does the COSMOS model , HL7 RIM, DICOM SR, etc.  Maybe the COAS
object/data model should pull out the common characteristics of each and
a few of the more useful exceptional characteristics of each.

TimReturn-Path: <R.M.Dixon@comhealth.hull.ac.uk>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id LAA05862; Tue, 2 Jun 1998 11:13:51 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id LAA26974; Tue, 2 Jun 1998 11:13:49 -0700
Received: from puccini.ucc.hull.ac.uk(150.237.196.2) by iwall via smap (V2.0)
	id xma026954; Tue, 2 Jun 98 11:13:11 -0700
Received: from humus.ucc.hull.ac.uk by puccini.ucc.hull.ac.uk; Tue, 2 Jun 1998 19:13:01 +0100
Received: from w301 [150.237.79.180]
	by humus.ucc.hull.ac.uk with smtp (Exim 1.60 #1)
	id 0ygvYQ-00001c-00; Tue, 2 Jun 1998 19:12:58 +0100
From: "Richard Dixon" <R.M.Dixon@comhealth.hull.ac.uk>
To: "Tim Brinson" <tim@protocol.com>
Cc: "Peter Nicklin" <peter.nicklin@newcastle.ac.uk>,
        "Mary Kratz" <mkratz@umich.edu>
Subject: Response to COAS Submission Draft 3.1
Date: Tue, 2 Jun 1998 19:13:42 +0100
Message-ID: <01bd8e52$2d3dcfd0$b44fed96@w301.health.hull.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_017B_01BD8E5A.8FAA37A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3

Tim et al,

Well, sorry this took longer than anticipated - too many other things
happening at once.
I have attached my comments on the draft (3.1) including some GEHR stuff and
diagrams of the relevant part of the model (now updated with the results of
other work).

It seems that things are really beginning to pull together on the EHCR side
of things in Europe.  GEHR work, CEN work, EHCR-SupA are starting to agree
on the way forward.  It's going to be a while yet, but hopefully everyone
will eventually agree on a single global standard (that's certainly what me
and my colleagues are aiming at).

Back dowm to reality for now, though, feel free to use as many or few bits
of the attached notes as you like.  I'll be seeing you in Orlando, so we can
discuss the detail more then as suits you.  More words are available, but I
thought this was probably enough for now.

Best wishes,
Richard


Attachment Converted: "c:\program files\eudora\attach\Response to COAS  Draft 3.doc"

Attachment Converted: "c:\program files\eudora\attach\vcard19.vcf"
Date: Tue, 02 Jun 1998 17:04:36 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net
CC: Richard Dixon <R.M.Dixon@comhealth.hull.ac.uk>
Subject: Re: Response to COAS Submission Draft 3.1

I had some probolems reading the full document Richard sent out.  Here is the
main part I was able to pull out.

-----------------------------------------------------

COAS Submission Draft 3.1
R. Dixon
31/5/98
Doc Ref: m:\mig\research\projects\omg\corbamed\coas\response to coas draft 3.1

General Issues
The attributes associated with each entry should reflect their use as parts of
an ethico-legal record of care of the patient.  That is to say, if an item of
medical information (an ‘observation’) is retrieved, there should be sufficient
information with it that if a clinical decision or inference is taken based upon
it, the precise details, context and source of that information should be
known.

The observation must also be a correct piece of information, suitably
time-stamped and attributed such that if it is uniquely identifiable and cannot
be confused with any other similar observation.  Once retrieved, the end-user
may choose to process or ignore whatever parts of the information they wish
there is no way currently of preventing this.  However, access services should
encourage good practice and not allow ‘incomplete’ data to be retrieved.

Clinical data varies enormously from the simple (e.g. no of children = 3) to the
complex (e.g. a full physical examination, a set of lab results, an ECG).  Any
model of the information should accurately preserve the data (and meaning)
recorded by the clinician but without restricting his freedom to record as he
chooses.

The context in which information (observations) are recorded is in many ways as
important as the observation itself.  For example, whether a blood pressure was
taken while sitting or running or just after explaining that a family member had
died, affects the interpretation of the data.  It is therefore essential that
the full context of the observations retrieved by any access service is
unambiguously identifiable.

To this end, (from a GEHR perspective) the ‘Transaction’ (i.e. the full set of
observations committed to a record by a clinician at a particular session)
should be identifiable as well, as the patient and record from which the
observation came.

It may be important (for epidemiology for example) that the identification of
the patient is not directly possible.  Filters that allow/disallow patient
identification must require carefully gauranteed authority.  Rights placed on
individual observations (or groups of them) must also be respected when the
information is requested, retrieved, exchanged and presented.

The GEHR philosophy has not been to try to classify the huge range of types of
clinical information (observations), but to treat them all generically.  How
they are related depends either on implied knowledge, for which a terminology
service is required, or explicit cross-referencing, for which there must be
provision.
Specfic Sections of the Draft

2.2 Information Model

The Good European Health Record (GEHR) project intro para could go in here – its
on the CORBAmed document list somewhere.
Also intro paras for EHCR-SupA, CEN TC251 WGI, SYNAPSES
(probably all obtainable from the CORDIS web site, else from ours
http://www.enc.hull.ac.uk /CS/Medicine (a little out of date at the moment, but
being redone) or CHIME’s http://www.chime.ucl.ac.uk)

2.9 XML Usage

The use of XML should IMHO not be the concern of COAS.

2.11 Access Mechanisms / 2.12 Conformance

Again, a sentence from SYNAPSES probably ought to go here

2.14 Constraint Languages

Uh?

2.16 Scope of Observations

(See general para above and the bit below)

2.17 Roadmap for Extensions

I reckon this ought to include extensions to full Electronic HealthCare Records
(EHCRs).

3.1 Definition and Scope of Clinical Observations

I accept the definition.

Since GEHR was dealing with observations generically, it defined them to include
any piece of information recorded in a health record (including administrative
information).  (They are likely to be renamed ‘Health Record Entry’ or something
such).    It studied many existing clinical records (electronic and paper) and
defined three types of entry: ‘ HealthRecordItems’ (HRI) – each of which is
single’ piece of data in the record; ‘HRICollections’ (or ‘HRICompounds’)  which
are more substantial entries composed of several parts; and ‘Headings’ which
merely serve to label (or group) a number of otherwise disconnected
observations.

[This is explained much more fully in various other documents – I can dig them
out if necessary, although face to face explanations are far quicker and easier
as a rule!]

In the final paragraph you conjecture as to whether various things are
Observations.  My view (and I believe in line with that of GEHR, CEN, EHCR-SupA
to date) is that this is the wrong way round.  All those things are things we
should be dealing with in the same way, the question is: is ‘Observation’ a good
enough term for them?  As I mentioned above, in the GEHR and CEN world they will
probably be called ‘Health Record Entry’ – they are pieces of recorded health
related information.  It could be said that these are all ‘observed’, regardless
of what they are, so  ‘Observation’ will do for now.

I include at this point, a model of Observations which is based upon the GEHR
v1.0 model but includes further modifications and extensions in the light of
implementation experiences and discussions with CEN and EHCR-SupA.  EHCR-SupA
will be producing a new (concensus) model in due course (probably not too much
different), the results of which I will endeavour to feed back into CORBAmed
when possible.

Sender: tim@protocol.com
Date: Wed, 03 Jun 1998 15:47:30 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: COAS Submitters Meeting

A few weeks ago I proposed having a COAS submitters meeting in June or
July (or both?).  I have gotten permission for Protocol to host a
meeting in Oregon.  As opposed to meeting in town I have found a nice
place in the mountains that is a short drive from the airport.

	The Resort at the Mountain
	66010 E. Fairway Avenue
	Welches, Oregon  97067
	503-622-3101
	http://www.theresort.com
	information@theresort.com

	$105 - 2 double beds
	$119 - 2 queens, fridge, wetbar
	$140 - 2 kings, fridge, wetbar, fireside suite

	Available 7, 8, 9 July

	30-45 minutes from airport
	Maps available

	Check out the web page!


Protocol will pay for:

	meeting rooms,
	breakfast,
	lunch,
	refreshments for AM and PM breaks.

Each participant will arrange and pay for:

	room,
	car,
	travel,
	dinner.

Do the prices seem reasonable?  They are similar to what we paid in
Atlanta for the PIDS submitters meetings ($121 and $101).  While we
might be able to find something cheaper (in every sense of the word) in
town hopefully the environment will enhance out creativity.  Some of us
may want to car pool from the airport.  The resort also mentioned that
shuttles are available for ~$15 per person.  I don't know if there is a
minimum number of people for that price.  The resort can refer you to a
shuttle service.

Do you mind coming to Portland?  The weather should be good that time of
year.

I propose we meet for 3 days.  For PIDS submitter meetings we barely got
through in 2 days and COAS is substantially more complex.  I checked
other weeks in July but the 7-9 was the only midweek available for ~12
rooms.  June is not a good time for us to host a meeting.  I figured
Tuesday-Thursday is best so people could travel on Monday and/or Friday
(or stay the weekend and enjoy the mountains).  Are other days better?

We need to make arrangements soon while the resort still has rooms
available on 7-9 July.  Please respond ASAP if you can make it or if we
need to change the dates or location.


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard20.vcf"
X-Sender: bobg@mailhost.medgrid.philips.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 03 Jun 1998 16:32:04 -0700
To: Tim Brinson <tim@protocol.com>, COAS <coas@baptisthealth.net>
From: Bob Glicksman <bobg@medgrid.philips.com>
Subject: Re: COAS Submitters Meeting
Cc: ccarman, larryh

Tim, et. el,

Charles Carman and Larry Hamel will both attend this meeting, representing
Philips.  I will be available in the office on thise days for telephone
consultation if needed.

Larry/Chuck: please make your travel arrangments as soon as Tim confirms
the dates/location.


At 03:47 PM 6/3/98 -0700, Tim Brinson wrote:
>A few weeks ago I proposed having a COAS submitters meeting in June or
>July (or both?).  I have gotten permission for Protocol to host a
>meeting in Oregon.  As opposed to meeting in town I have found a nice
>place in the mountains that is a short drive from the airport.
>
>	The Resort at the Mountain
>	66010 E. Fairway Avenue
>	Welches, Oregon  97067
>	503-622-3101
>	http://www.theresort.com
>	information@theresort.com
>
>	$105 - 2 double beds
>	$119 - 2 queens, fridge, wetbar
>	$140 - 2 kings, fridge, wetbar, fireside suite
>
>	Available 7, 8, 9 July
>
>	30-45 minutes from airport
>	Maps available
>
>	Check out the web page!
>
>
>Protocol will pay for:
>
>	meeting rooms,
>	breakfast,
>	lunch,
>	refreshments for AM and PM breaks.
>
>Each participant will arrange and pay for:
>
>	room,
>	car,
>	travel,
>	dinner.
>
>Do the prices seem reasonable?  They are similar to what we paid in
>Atlanta for the PIDS submitters meetings ($121 and $101).  While we
>might be able to find something cheaper (in every sense of the word) in
>town hopefully the environment will enhance out creativity.  Some of us
>may want to car pool from the airport.  The resort also mentioned that
>shuttles are available for ~$15 per person.  I don't know if there is a
>minimum number of people for that price.  The resort can refer you to a
>shuttle service.
>
>Do you mind coming to Portland?  The weather should be good that time of
>year.
>
>I propose we meet for 3 days.  For PIDS submitter meetings we barely got
>through in 2 days and COAS is substantially more complex.  I checked
>other weeks in July but the 7-9 was the only midweek available for ~12
>rooms.  June is not a good time for us to host a meeting.  I figured
>Tuesday-Thursday is best so people could travel on Monday and/or Friday
>(or stay the weekend and enjoy the mountains).  Are other days better?
>
>We need to make arrangements soon while the resort still has rooms
>available on 7-9 July.  Please respond ASAP if you can make it or if we
>need to change the dates or location.
>
>
>Cheers,
>
>Tim
>Attachment Converted: "c:\eudora\attach\vcard7.vcf"
>
_____________________________________
Bob Glicksman
Director, MedGRiD Program
Integrated Clinical Solutions

bobg@medgrid.philips.com              Philips Medical Systems
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736

Sender: tim@protocol.com
Date: Wed, 03 Jun 1998 17:17:12 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: Paul Cooper <pcooper@imsgrp.com>
CC: COAS <coas@baptisthealth.net>
Subject: Re: [EM / RLS] Enterprise Management & Record Location Service

Paul Cooper wrote:
> However it is surely related to COAS, Demographics and
> Encounter Management (and others?) and therefore perhaps the best option for
> Orlando is for the RLS session to discuss how the different services should
> interwork and where the delineation of functionality should lie.

I agree.  It does seem the Record Locator Service may be related to
these other services.  Maybe this is a subject that should be brought up
in both the COAS and Encounter Management sessions?  On some of the COAS
conference calls we wondered if some of the COAS federation ideas might
over lap with RLS.

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard21.vcf"
From: "Jon Farmer" <jfarmer@caredatasystems.com>
To: "COAS" <coas@baptisthealth.net>
Cc: "John Landers" <jcl@lightspeed.net>
Subject: Please add John Landers to list
Date: Thu, 4 Jun 1998 13:31:35 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

<x-html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.2106.6"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>Hello all,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT><FONT size=2>I regret I have been unable
to participate in COAS so far except as to scan the mail.&nbsp;&nbsp; I want to
introduce John Landers of Care Data (<A
href="mailto:jcl@lightspeed.net">jcl@lightspeed.net</A>) to the process and ask
that you add him to the mail list.&nbsp; Please name him as our COAS point of
contact for the submission.&nbsp; </FONT><FONT size=2>John is our PIDS wrapper
programmer and also our technical liaison with Philips.&nbsp; He will be
interested in COAS from the perspective of a) configurable access to COAS from
our integration engine and b) permitting configuration of a COAS wrapper around
a SQL CDR.&nbsp; </FONT><FONT size=2>You will probably get to meet him in
Oregon.&nbsp; Hopefully I'll make that meeting as well.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>You all may get to meet Scott Powers (our Pres and CEO) in
CORBAmed mid week in Orlando.&nbsp; I hope to start showing may face back in
CORBAmed after Orlando</FONT><FONT size=2>.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT><FONT color=#000000 size=2>Bye</FONT></DIV>
<DIV><FONT size=2>Jon</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>
</x-html>Sender: tim@protocol.com
Date: Fri, 05 Jun 1998 10:22:35 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>, "David A. Schramm" <dschramm@ipworld.com>
Subject: Important! - COAS Presentaion

The CORBAmed agenda has changed.  It now has us presenting COAS on
Monday at 1:00.  We were planning on meeting Monday evening to prepare
for the presentation.

	http://www.omg.org/corbamed/agenda_98_5.html

Can anyone meet Sunday or Sunday evening to prepare?  The other
alternative is to try changing times with the HL7 presentaion by Dave
Schram on Tuesday at 1:00.


Tim
Attachment Converted: "c:\program files\eudora\attach\vcard24.vcf"
Sender: tim@protocol.com
Date: Fri, 05 Jun 1998 10:30:53 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: [Fwd: COAS Submitters Meeting]

3M can not make the 7-9 June meeting - see attached.  I can see about
the following week.  It sounds like 3M can not meet until Thursday.  The
rest of us could start meeting on Wednesday 15 June and continue to meet
through Friday 16 June.  I could even meet on Saturdays and Sundays if
others can.

Lets discuss this in Orlando.  After I get back I can check out other
facilities since I think The Resort at the Mountain is full on 15-16
June.  That may depend on the number of people we expect though.

Would someone else want to host a meeting in June?


TimReturn-Path: <tcculpepper@wpmail.code3.com>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id KAA09963; Fri, 5 Jun 1998 10:02:05 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id KAA19681; Fri, 5 Jun 1998 10:02:04 -0700
Received: from ozone.hsi.com(192.43.235.18) by iwall via smap (V2.0)
	id xma019664; Fri, 5 Jun 98 10:01:55 -0700
Received: by ozone.hsi.com; id NAA25158; Fri, 5 Jun 1998 13:01:50 -0400 (EDT)
Received: from mercury.hsi.com(143.122.1.91) by ozone.hsi.com via smap (3.2)
	id xma025128; Fri, 5 Jun 98 13:01:39 -0400
Received: from code3.code3.com by mercury.hsi.com (5.65v4.0/1.1.10.5/25Jul97-0203PM)
	id AA04663; Fri, 5 Jun 1998 13:01:39 -0400
Received: from wpmail.code3.com by code3.code3.com (8.6.13/200.17.1.3)
	id LAA09353; Fri, 5 Jun 1998 11:01:38 -0600
Received: from 3MHIS-Message_Server by wpmail.code3.com
	with Novell_GroupWise; Fri, 05 Jun 1998 11:01:35 -0600
Message-Id: <s577d00f.046@wpmail.code3.com>
X-Mailer: Novell GroupWise 5.2
Date: Fri, 05 Jun 1998 11:01:05 -0600
From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
To: tim@protocol.com
Cc: HRSOLBRIG@wpmail.code3.com
Subject: Re: COAS Submitters Meeting
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

Tim,
Harold and I are both out until July 13. We will be coming back from Australia and would most likely not be in any shape to provide anything of substance for at least a day or two.
Possible dates prior to Helsinki for me are:
July 16-17
July 22-24

3M would very much like to be there if possible.
Thank
Tom

>>> Tim Brinson <tim@protocol.com> 06/03 6:09 PM >>>
Tom Culpepper wrote:
>
> Tim,
> I am afraid I will be out of town July 3-13. I would like very much to attend but if there is a majority for that date then so be it.
> Tom

Actually I would not want to have it without 3M being there.  Any chance
meeting right after you get back on 14-16 July?  I know that venue is
full on the 15-16 but I can look for others.  What about any other
dates?  Is there anyone else at 3M that knows this domain and could
contribute?

Tim

Attachment Converted: "c:\program files\eudora\attach\vcard23.vcf"
Sender: tim@protocol.com
Date: Fri, 05 Jun 1998 16:43:58 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
To: COAS <coas@baptisthealth.net>
Subject: Oops! [Fwd: COAS Submitters Meeting]]

Chuck pointed out that in my message about the COAS submitters meetings
I indicated the wrong month.  I was referring to JULY not JUNE.  Here it
is corrected:



3M can not make the 7-9 JULY meeting - see attached.  I can see about
the following week.  It sounds like 3M can not meet until Thursday.  The
rest of us could start meeting on Wednesday 15 JULY and continue to meet
through Friday 16 JULY.  I could even meet on Saturdays and Sundays if
others can.

Lets discuss this in Orlando.  After I get back I can check out other
facilities since I think The Resort at the Mountain is full on 15-16
JULY.  That may depend on the number of people we expect though.

Would someone else want to host a meeting in June (YES, I REALLY MEAN
JUNE FOR THIS ONE)?


THANKS CHUCK,

TimReturn-Path: <ccarman@medgrid.philips.com>
Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
	id LAA23641; Fri, 5 Jun 1998 11:52:52 -0700
Received: by  protocol.com (SMI-8.6/SMI-SVR4)
	id LAA25535; Fri, 5 Jun 1998 11:52:50 -0700
Received: from medmail.pmc.philips.com(206.101.165.150) by iwall via smap (V2.0)
	id xma025496; Fri, 5 Jun 98 11:52:30 -0700
Received: from med106 by medgrid.philips.com (SMI-8.6/SMI-SVR4)
	id LAA27028; Fri, 5 Jun 1998 11:52:29 -0700
Message-Id: <3.0.2.32.19980605115151.00952d40@med10.medgrid.philips.com>
X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 05 Jun 1998 11:51:51 -0700
To: Tim Brinson <tim@protocol.com>
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Re: [Fwd: COAS Submitters Meeting]
In-Reply-To: <35782B4D.C237CEF6@protocol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

If someone else has not mentioned it already,
in most of your message you say JUNE when I think you mean JULY.
I hope that changes the availablility of the meeting place.

Chuck

At 10:30 AM 6/5/98 -0700, you wrote:
>3M can not make the 7-9 June meeting - see attached.  I can see about
>the following week.  It sounds like 3M can not meet until Thursday.  The
>rest of us could start meeting on Wednesday 15 June and continue to meet
>through Friday 16 June.  I could even meet on Saturdays and Sundays if
>others can.
>
>Lets discuss this in Orlando.  After I get back I can check out other
>facilities since I think The Resort at the Mountain is full on 15-16
>June.  That may depend on the number of people we expect though.
>
>Would someone else want to host a meeting in June?
>
>
>TimReturn-Path: <tcculpepper@wpmail.code3.com>
>Received: from protocol.com by protocol.com (SMI-8.6/SMI-SVR4)
>	id KAA09963; Fri, 5 Jun 1998 10:02:05 -0700
>Received: by  protocol.com (SMI-8.6/SMI-SVR4)
>	id KAA19681; Fri, 5 Jun 1998 10:02:04 -0700
>Received: from ozone.hsi.com(192.43.235.18) by iwall via smap (V2.0)
>	id xma019664; Fri, 5 Jun 98 10:01:55 -0700
>Received: by ozone.hsi.com; id NAA25158; Fri, 5 Jun 1998 13:01:50 -0400 (EDT)
>Received: from mercury.hsi.com(143.122.1.91) by ozone.hsi.com via smap (3.2)
>	id xma025128; Fri, 5 Jun 98 13:01:39 -0400
>Received: from code3.code3.com by mercury.hsi.com
(5.65v4.0/1.1.10.5/25Jul97-0203PM)
>	id AA04663; Fri, 5 Jun 1998 13:01:39 -0400
>Received: from wpmail.code3.com by code3.code3.com (8.6.13/200.17.1.3)
>	id LAA09353; Fri, 5 Jun 1998 11:01:38 -0600
>Received: from 3MHIS-Message_Server by wpmail.code3.com
>	with Novell_GroupWise; Fri, 05 Jun 1998 11:01:35 -0600
>Message-Id: <s577d00f.046@wpmail.code3.com>
>X-Mailer: Novell GroupWise 5.2
>Date: Fri, 05 Jun 1998 11:01:05 -0600
>From: "Tom Culpepper" <tcculpepper@wpmail.code3.com>
>To: tim@protocol.com
>Cc: HRSOLBRIG@wpmail.code3.com
>Subject: Re: COAS Submitters Meeting
>Mime-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Disposition: inline
>
>Tim,
>Harold and I are both out until July 13. We will be coming back from
Australia and would most likely not be in any shape to provide anything of
substance for at least a day or two.
>Possible dates prior to Helsinki for me are:
>July 16-17
>July 22-24
>
>3M would very much like to be there if possible.
>Thank
>Tom
>
>>>> Tim Brinson <tim@protocol.com> 06/03 6:09 PM >>>
>Tom Culpepper wrote:
>>
>> Tim,
>> I am afraid I will be out of town July 3-13. I would like very much to
attend but if there is a majority for that date then so be it.
>> Tom
>
>Actually I would not want to have it without 3M being there.  Any chance
>meeting right after you get back on 14-16 July?  I know that venue is
>full on the 15-16 but I can look for others.  What about any other
>dates?  Is there anyone else at 3M that knows this domain and could
>contribute?
>
>Tim
>
>Attachment Converted: "c:\program files\eudora\attach\vcard50.vcf"
>

Attachment Converted: "c:\program files\eudora\attach\vcard25.vcf"
From: Howard_Chase@idx.com
X-Lotus-FromDomain: IDX1
To: coas@baptisthealth.net
Date: Thu, 11 Jun 1998 08:29:31 -0400
Subject: Notes from CORBAmed presentation


To:   coas

To the submitters: Nice work on the presentation, everybody.

Here are a few notes/issues after the initial submission presentation at
the larger CORBAmed meeting:

(name???):No mention of support for Decision Support Systems.  COAS needs
to support DSS.  Response: submitters don
?t know of use cases.  Open issue:
what is an observation?

Etienne commented to widen the scope to Clinical _Item_ Access Service.

Jerome: DSS issues: 1. Performance  2. How to access the information (by
value, xml, by reference)  3. Non-clinical data; can COAS be used to get
any type of data?  If not, there may be duplicated effort.  4. Need
certainty/confidence factor feedback from services.

Konstantine: Collaborate with HRAC submitters to develop a good model for
secure access that will work well for COAS & others.

Peter: models; have modelers come up with a model offer to present to COAS.
Harold noted associated OMG process issues.

Wayne: Q re: where server lives and architectures.  Response: COAS needs to
be architecture independent.

(name???): Scope:

Bob: Some issues raised are not requirements of the RFP.  The RFP _does_
require extensibility.  The next presentation needs to address the
extensibility issue.  Others need to contribute information/expertise to
arrive at a workable response/service, etc.

Howard
Date: Mon, 15 Jun 1998 12:38:19 -0400
From: "Eric Navarro" <ericn@baptisthealth.net>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net
Subject: COAS list additions

As a result of the Orlando OMG meeting, the following people have been
added to the COAS joint submitter's mailing list:

        William J. Chimiak <chim@bgsm.edu>
        Gene Mitelman <gmitelman@ksminc.com>
        Russell C. Eirich <reirich@ksminc.com>
        Karen Dolan <kdolan@lhs.com>
        Michael M. Wagner <mmw@med.pitt.edu>

Welcome aboard!  If you have any questions about
subscribing/unsubscribing, please feel free to contact me:
ericn@baptisthealth.net

Thanks,
Eric N.

Attachment Converted: "c:\program files\eudora\attach\vcard1.vcf"
X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 15 Jun 1998 11:23:50 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Presentation of COAS initial submission to CORBAmed

The PowerPoint slides of the COAS initial submission presentation to
CORBAmed given by the group on Wednesday, 10 June 1998, can be found in
several places.
It has been submitted to the OMG, and should appear on the OMG web-site as
CORBAmed/98-06-10 within a couple of days.
I have also placed it on the COAS "web-site", i.e.
http://www.protocol.com/engineering/corbamed/coas/incoming

For those who were not at the presentation, please do not hesitate to ask
questions regarding the COAS meetings or the presentation.  If I can not
answer your questions, others of us should be able to.

Chuck Carman

Reply-To: <juggy@careflow.com>
From: "V. Juggy Jagannathan" <juggy@careflow.com>
To: <coas@baptisthealth.net>
Subject: RE: Presentation of COAS initial submission to CORBAmed
Date: Mon, 15 Jun 1998 14:48:19 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3


Tim/COAS submitters:

We talked about having COAS submitters meeting on July 21-23. I am trying to
make
reservations - so please confirm this trip! Also what hotel is appropriate
for staying to attend this meeting?

- regards
- juggy


Sender: tim@protocol.com
Date: Tue, 16 Jun 1998 11:58:45 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4m)
To: juggy@careflow.com, coas@baptisthealth.net
Subject: COAS Submitters Meeting

V. Juggy Jagannathan wrote:
>
> Tim/COAS submitters:
>
> We talked about having COAS submitters meeting on July 21-23. I am trying to
> make
> reservations - so please confirm this trip! Also what hotel is appropriate
> for staying to attend this meeting?

My understanding from the Orlando meeting is that we decided there WILL
be a COAS submitters meeting in the Denver area on 21-23 July.  Mary
Richards was going to check on the possibility of holding the meeting at
their Boulder division.  I'm sure there are plenty of other options as
well.  Meeting rooms in hotels probably run ~$500 per day which we could
all split.  Dave Forslund also talked about finding one of their
partners to possibly host the meeting.

For those that were not at the meeting last week, we had some good COAS
sessions on Monday night, Tuesday afternoon and the CORBAmed
presentation on Wednesday morning.
We all understood our different perspectives better after the Monday and
Tuesday meetings.  Chuck Carmen put together the main presentation for
CORBAmed and each submitter that attended presented their more specific
views.  I think most people saw our differening views as complimentary.

The reason we picked the Denver area for the submitters meeting was
because 2-3 of the participants were going to be there for OOPSLA on
19-21 July anyway.  None of them had to attend OOPSLA on the 22nd so we
started the meeting on that day.

Some of the proposed agenda items for the meeting are:

	Discuss extensibility mechanisms

	Determine scope of COAS

	Define 'Clinical Observations' and other terms

	Start integrating the various object/data models

	Understand more use scenerios


The object/data models are of concern since there have been so much work
done by various groups (HL7, DICOM Structured Reporting, GEHR, NHS
Cosmos, Synapses, DOD, etc.).  Some of us are hoping to get HL7 and
DICOM modeling experts to attend the Denver meeting and GEHR, NHS, and
Synapses modeing experts to attend the Helsinki meeting.


The Denver submitter meeting is one week before the Helsinky
OMG/CORBAmed meeting.  There are a number of people attending CORBAmed
from European projects dealing with distributed health records.  They
have proposed trying to get their experts involved with COAS at
Helsinki.  I figure this should be outside the CORBAmed meeting as it
involves submitter issues.

On Friday night some of us were talking about this and the issue of cost
came up.  There was discussion about having a COAS submitters meeting in
Dublin, Amsterdam or the UK instead.  It would be easier for them to get
their experts to attend than if it were in Helsinki.

What do others think of this?  COAS is the most critical reason I would
be attending Helsinki anyway.  It was not clear from the agenda Peter
put together for Helsinki what the value is for going there.


There was also talk about reuming our conference calls every other
week.  The last I recall is to have them on Tuesday 8:00 am PDT (11:00
am EDT) so that Europeans could attend if they want.  Does that sound
right Chuck?  Mary, is the Umich line available for 23 June?


Cheers,

Tim
Attachment Converted: "c:\program files\eudora\attach\vcard3.vcf"
X-Mailer: Novell GroupWise 4.1
Date: Tue, 16 Jun 1998 15:56:52 -0400
From: Mary Richards <Mary.Richards@hboc.com>
To: coas@baptisthealth.net, juggy@careflow.com, tim@protocol.com
Subject: COAS Submitters Meeting -Reply

Folks,

I just got approval to use HBOC's facility in Louisville, CO which is
outside Boulder.  If you want me to proceed, I'll send hotels and
directions to the list server.

Mary

>>> Tim Brinson <tim@protocol.com> 06/16/98 02:58pm >>>
V. Juggy Jagannathan wrote:
>
> Tim/COAS submitters:
>
> We talked about having COAS submitters meeting on July 21-23. I am
trying to
> make
> reservations - so please confirm this trip! Also what hotel is
appropriate
> for staying to attend this meeting?

My understanding from the Orlando meeting is that we decided there WILL
be a COAS submitters meeting in the Denver area on 21-23 July.  Mary
Richards was going to check on the possibility of holding the meeting at
their Boulder division.  I'm sure there are plenty of other options as
well.  Meeting rooms in hotels probably run ~$500 per day which we could
all split.  Dave Forslund also talked about finding one of their
partners to possibly host the meeting.

For those that were not at the meeting last week, we had some good COAS
sessions on Monday night, Tuesday afternoon and the CORBAmed
presentation on Wednesday morning.
We all understood our different perspectives better after the Monday and
Tuesday meetings.  Chuck Carmen put together the main presentation for
CORBAmed and each submitter that attended presented their more specific
views.  I think most people saw our differening views as complimentary.

The reason we picked the Denver area for the submitters meeting was
because 2-3 of the participants were going to be there for OOPSLA on
19-21 July anyway.  None of them had to attend OOPSLA on the 22nd so we
started the meeting on that day.

Some of the proposed agenda items for the meeting are:

	Discuss extensibility mechanisms

	Determine scope of COAS

	Define 'Clinical Observations' and other terms

	Start integrating the various object/data models

	Understand more use scenerios


The object/data models are of concern since there have been so much work
done by various groups (HL7, DICOM Structured Reporting, GEHR, NHS
Cosmos, Synapses, DOD, etc.).  Some of us are hoping to get HL7 and
DICOM modeling experts to attend the Denver meeting and GEHR, NHS, and
Synapses modeing experts to attend the Helsinki meeting.


The Denver submitter meeting is one week before the Helsinky
OMG/CORBAmed meeting.  There are a number of people attending CORBAmed
from European projects dealing with distributed health records.  They
have proposed trying to get their experts involved with COAS at
Helsinki.  I figure this should be outside the CORBAmed meeting as it
involves submitter issues.

On Friday night some of us were talking about this and the issue of cost
came up.  There was discussion about having a COAS submitters meeting in
Dublin, Amsterdam or the UK instead.  It would be easier for them to get
their experts to attend than if it were in Helsinki.

What do others think of this?  COAS is the most critical reason I would
be attending Helsinki anyway.  It was not clear from the agenda Peter
put together for Helsinki what the value is for going there.


There was also talk about reuming our conference calls every other
week.  The last I recall is to have them on Tuesday 8:00 am PDT (11:00
am EDT) so that Europeans could attend if they want.  Does that sound
right Chuck?  Mary, is the Umich line available for 23 June?


Cheers,

Tim

X-Sender: ccarman@med10.medgrid.philips.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 16 Jun 1998 14:30:37 -0700
To: coas@baptisthealth.net
From: Charles Carman <ccarman@medgrid.philips.com>
Subject: Re: COAS Submitters Meeting

Tim,

Thanks for the summary and objectives, it helps to have the context
repeated regularily.

About the meeting in Colorado, Philips is willing to pay part of the shared
meeting expenses.  We may send two people (Larry and Chuck), although that
may depend on the decisions about the Helsinki meeting.

While we (Philips) agree with you, Tim, that we would probably not go to
the CORBAmed meetings in Helsinki if we did not have a COAS meeting there
at the same time.  We also feel that, if Philips/MedGRiD is spending the
time and resources to be in Europe at the time of the CORBAmed meetings,
that Philips/MedGRiD should support and contribute to the CORBAmed meetings
in conjunction with the COAS meeting.  In other words, we want to encourage
having the COAS meeting at Helsinki (or possibly postponing a Europe
meeting until later, although with the final submission deadline on August
24, 1998, it is hard to get much later).
Any other ideas?

About the bi-weekly COAS teleconference calls, my recollection is that we
had agreed to hold them on Tuesdays at 8:00 am PDT, 11:00 am EDT, 4:00 pm
GDT (Greenwich Daylight_savings??? Time).

Chuck Carman

At 11:58 AM 6/16/98 -0700, you wrote:
>V. Juggy Jagannathan wrote:
>>
>> Tim/COAS submitters:
>>
>> We talked about having COAS submitters meeting on July 21-23. I am
trying to
>> make
>> reservations - so please confirm this trip! Also what hotel is appropriate
>> for staying to attend this meeting?
>
>My understanding from the Orlando meeting is that we decided there WILL
>be a COAS submitters meeting in the Denver area on 21-23 July.  Mary
>Richards was going to check on the possibility of holding the meeting at
>their Boulder division.  I'm sure there are plenty of other options as
>well.  Meeting rooms in hotels probably run ~$500 per day which we could
>all split.  Dave Forslund also talked about finding one of their
>partners to possibly host the meeting.


>
>The Denver submitter meeting is one week before the Helsinky
>OMG/CORBAmed meeting.  There are a number of people attending CORBAmed
>from European projects dealing with distributed health records.  They
>have proposed trying to get their experts involved with COAS at
>Helsinki.  I figure this should be outside the CORBAmed meeting as it
>involves submitter issues.
>
>On Friday night some of us were talking about this and the issue of cost
>came up.  There was discussion about having a COAS submitters meeting in
>Dublin, Amsterdam or the UK instead.  It would be easier for them to get
>their experts to attend than if it were in Helsinki.
>
>What do others think of this?  COAS is the most critical reason I would
>be attending Helsinki anyway.  It was not clear from the agenda Peter
>put together for Helsinki what the value is for going there.
>
>
>There was also talk about reuming our conference calls every other
>week.  The last I recall is to have them on Tuesday 8:00 am PDT (11:00
>am EDT) so that Europeans could attend if they want.  Does that sound
>right Chuck?  Mary, is the Umich line available for 23 June?
>
>
>Cheers,
>
>Tim
>Attachment Converted: "c:\program files\eudora\attach\vcard63.vcf"
>

X-Mailer: Novell GroupWise 4.1
Date: Wed, 17 Jun 1998 15:59:03 -0400
From: Laura Winckler <Laura.Winckler@hboc.com>
To: coas@baptisthealth.net
Subject: Directions to Louisville office

Mary Richards requested that I send you directions to our Colorado
office and a list of hotels.

>From Denver International Airport (DIA):
 take Pena Boulevard to I-70 West
 I-70 West to I-270 North (I-270 only goes in  one direction)
 I-270 to I-76 West
 I-76 less than ½ mile to I-25 North
 I-25 less than ½ mile to State Route 36 to Boulder
 State Route 36 to the Louisville/Superior Exit    at the top of the
exit ramp, turn right on  McCaslin Boulevard  turn left on Centennial
Parkway (Prominent sculpture at intersection)
 turn right on Century Place turn left into parking lot

Hotels:
La Quinta Inn & Suites
902 Dillon Road
Louisville, CO  80027
303-664-0100

Courtyard Louisville
948 West Dillon Road
Louisville, CO  80027
303-604-0007

X-Mailer: Novell GroupWise 4.1
Date: Wed, 17 Jun 1998 16:06:57 -0400
From: Dona Naysnerski <Dona.Naysnerski@hboc.com>
To: coas@baptisthealth.net
Subject: Directions/Hotel info

Attached are directions to the HBOC-Boulder office (Louisville, CO).
The main hotel in this area is the Marriott Courtyard.  Mention HBOC and
you should receive our corporate rate.


Attachment Converted: "c:\program files\eudora\attach\HBOC_LSV.DOC"
Sender: tim@protocol.com
Date: Thu, 18 Jun 1998 10:10:27 -0700
From: Tim Brinson <tim@protocol.com>
Organization: Protocol Systems, Inc.
X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4m)
To: Frank Manola <fmanola@objs.com>, coas@baptisthealth.net
Subject: Re: XML in the Clinical Observations Access Service

Frank,

Juggy copied the COAS submitters on his response to your message.  I am
very glad you saw the XML related discussion in the COAS RFP
submission.  I am the person that wrote it (from my limited
understanding of XML) and hoped to get feedback from people with more
experience.  I know you are that person as I have read most of 'Towards
a Web Object Model'.

>From reading your comments about the COAS submission I think we are in
agreement on things and you have shed more light on how things could
work.  Sorry if my descriptions of the issues were misinterpreted.  I
will try to explain my thoughts below and ask for more clarification on
some of your points.


> Frank wrote:
> > The paragraph in question reads:
> >
> > "While some COAS clients and servers may also deal with XML, it is not
> > clear if XML support needs to be defined in the COAS IDL.  XML based COAS
> > servers could translate XML contents into IDL, and the clients could
> > translate received IDL from a server back to XML (if they need to).
> > Alternatively, XML could be one format for clinical observations to be
> > transferred between COAS clients and servers."
> >
> > The second sentence seems to suggest, by talking about translating "XML
> > contents into IDL", and translating "received IDL from a server back into
> > XML", that XML and IDL are alternative data transfer formats, and that
> > clients could possibly receive IDL from a server.  Clearly this isn't the
> > case.  Servers don't send IDL to clients;  rather, they provide access to
> > object operations (which may return data in various formats) via IDL
> > interfaces. So a client wouldn't need to translate received IDL to XML.
> > Similarly, a server receiving XML contents from a client (e.g.,
> > for storage
> > purposes) wouldn't translate it into IDL.

Sorry for only using a single sentence to pack so much semantics.  I was
trying to briefly give use scenarios where XML could be used internally
by servers and clients but where it is not used in the interactions
between them.

Let me give some examples to better describe what I meant.  If one of
the access mechanisms for COAS supported searching for particular data
such as a Heart Rate measurement the data would naturally be returned as
an IDL data type (not as IDL itself).  There might be an IDL 'struct' or
'value' called Measurement that would have fields/state for things like
units, time of measurement, value, measurement name, etc.

The COAS server may be implemented over a relational data base, an XML
data base, flat files, federating over multiple other COAS servers,
etc.  In this scenario the IDL interface for the COAS server would
ENCAPSULATE what kind of data base is being used and where the data is
coming from.  If the COAS server had an XML data base it could search
the XML documents for Heart Rate measurements that met the the search
criteria (what patient, time frame, observer, etc.).  The COAS server
would pull the Heart Rate measurement out of the XML document and return
it to the client as the 'Measurement' IDL type.  The client never sees
XML in this scenario.

On the client side the Heart Rate measurement could be used for a lot of
different things such as storing it, updating a field on a display,
embedding it within some XML document it is creating, using it in
calculations, etc.  Since this is a client side consideration it does
not impact the interface between the COAS server and the client.

All this sounds pretty obvious.  The reason I mentioned it is to
differentiate between where XML is used for something (on clients and
servers) and when it is needed in the interaction between clients and
servers.  COAS needs to support the latter but allow the former.


> > It seems to me that realistic scenarios for using XML in this environment
> > would include:

This gets into the scenarios where XML would show up in the interactions
between the client and server which is what I was really interested in
getting feedback on - thank you!


> > 1.  an XML based COAS server could provide access to server-located XML
> > documents via a set of generic IDL interfaces defined to allow remote
> > client access to generic XML documents.  The W3C's Document
> > Object Model is
> > an example of such a set of interfaces, supporting interfaces of
> > types like
> > Document, Element, and so on.  With these interfaces, the client
> > would have
> > to search the document's element structure in order to find the elements
> > with the tags it needs.

Just for clarification here I think you are referring to a COAS server
that contains XML documents.  The COAS interface could have operations
that allowed clients to browse/search the structure of the XML
document.  The IDL operations might return things like what tags exist
within the document, values within those tags, subsections of the XML
document, etc.

Is this what you are referring to?  As Juggy mentioned we feel this is a
valuable capability that the COAS submitters want to allow for future
extensions of COAS by additional CORBAmed RFPs.  This capability does
not sound specific to healthcare so we could also leverage any work done
by other groups.  The current COAS scope is likely not to EXPLICITLY
support these kind of operations unless one of the submitters find a
special need for it now.


> > 2. an XML based COAS server could provide remote client access to
> > documents
> > of predefined types, understood by both clients and servers, by supporting
> > specialized IDL interfaces generated from the tag sets of those document
> > types. For example (I'm making this up), a document of type "Patient
> > Record" might have tags like <NAME>, <SEX>, and so on, and the
> > corresponding IDL interface might have operations getNAME, getSEX, etc.
> > This as opposed to using the generic interfaces in (1), where you would
> > have to go through a set of objects of generic types (DOCUMENT or
> > ELEMENT),
> > looking at their tags to see if they were what you wanted (Patient Record
> > documents, NAME elements), and then extracting the values.  In
> > the specific
> > case of COAS, you could also do things the other way around:  define the
> > XML tag sets to correspond to the IDL interfaces you've already
> > defined for
> > COAS.  The code implementing those interfaces, when dealing with documents
> > represented in XML, would respond to operations requesting specific data
> > elements by simply picking out the corresponding tagged data.

This is a good scenario that raises a number of questions I have been
considering.  Many of these are questions to the other COAS
submitters/contributors as opposed to you.

1) Does XML even come into play for the interactions between the client
and server?  Maybe this is the same scenario I presented above when I
explained that a COAS server may be running over an XML data base and
return Heart Rate measurements?

2) Are there hard definitions of the structure for XML documents?  One
of the strengths of XML over IDL data types is the flexibility and the
ease to represent optional fields/tags.

3) Who defines the DTD for these standard XML documents?  The HL7
SGMLSIG has been doing work to encode HL7 messages as XML documents.
The work on version 3.0 of HL7 might not be done for another few years.
We hope that at least some aspects of the COAS interfaces will be
generic enough that XML documents for HL7 3.0 can be accessed once they
are standardized, without having to update the COAS specification.

4) Since HL7 is used for data interchange will the DTD for an XML format
of HL7 messages be anything like the DTD for XML documents that are part
of a patient record?  If not then who defines the DTD(s) for patient
records?  COAS?

5) It seems COAS does need some fundamental information/object model
that supports attributes/operations as in your example.  How does COAS
work in environments that have other information/object models?  For
example the Good European Health Record (GEHR), HL7 version 3.0, etc.


> > 3.  an XML based COAS client could incorporate an XML parser (just like
> > many Web browsers either do now or will do shortly--they are not that
> > large) and ancillary software to support the DOM or more specialized
> > interfaces, and simply have the server ship the XML documents to
> > the client
> > for local access via the IDL interfaces. (Alternatively, the client could
> > simply access the raw XML as text, and do its own searching and
> > extraction,
> > but that seems less realistic).

This seems to be the one scenario that I could see the COAS
specification supporting explicitly.  It really seems pretty simple as
far as the IDL goes.  How would XML be represented as an IDL data type?
The simplest is as a sequence of octet.  It could be more complicated if
we wanted to have a structure containing values for some of the standard
tags/fields found in every XML document (or every clinical observation
XML document).  This would be redundent information but may be useful if
it is found that the information is needed without having to parse the
document.  For example would some federating server want to filter over
XML documents without parsing them?  I am posing this question to the
other submitters/contributors.

COAS needs to be able to handle many different data types any way (e.g.
measurements, plain text, waveforms, images, audio clips, coded
elements, etc.).  It seems an XML document might just be another one of
those data types.  This is similar to how COAS could directly support
retrieving simple images as JPEG, GIF, TIFF, etc., but CORBAmed has
issued another RFP for more sophisticated image access (sets of images,
regions of interest, resolution of interest, etc.).


Thanx again Frank for your feedback.  I would be pleased to hear any
ideas this message might have triggered.


Tim Brinson
Attachment Converted: "c:\program files\eudora\attach\vcard7.vcf"
X-Mailer: Novell GroupWise 4.1
Date: Fri, 19 Jun 1998 10:24:56 -0400
From: Mary Richards <Mary.Richards@hboc.com>
To: coas@baptisthealth.net
Subject: Directions/Hotel info -Forwarded

Our message is getting bounced back.  I'm trying one more time, if it
doesn't get through I"ll have to fax to everyone?

gotta love the technologyMessage-ID: <s587e969.051@OFFSMTP.hboc.com>
X-Mailer: Internet Mail Service (5.5.1960.3)
X-MS-Embedded-Report:
Date: Wed, 17 Jun 1998 16:06:57 -0400
From: Dona Naysnerski  <Dona.Naysnerski@hboc.com>
To: coas@baptisthealth.net
Subject: Directions/Hotel info
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_D5816776.49286326"

Attached are directions to the HBOC-Boulder office (Louisville, CO).
The main hotel in this area is the Marriott Courtyard.  Mention HBOC and
you should receive our corporate rate.




Attachment Converted: "c:\program files\eudora\attach\HBOC_LSV1.DOC"
Date: Mon, 22 Jun 1998 09:43:30 -0400
From: "Eric Navarro" <ericn@baptisthealth.net>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
To: coas@baptisthealth.net, coas@cs.fiu.edu
Subject: New Mailing List server for COAS

Hi all,
  In an effort to improve mailing list administration, decrease bounced messages and provide an archive for our e-mail discussions, Florida International University School of Computer Science in
conjunction with Baptist Health Systems has agreed to host a majordomo-based mailing list for the COAS submitters.  For all of you already on the list, I will take the liberty of adding your e-mail
address to the new list server.  If you know of anyone who wants to subscribe to the list, they can send a subscribe message to coas-request@cs.fiu.edu

In a short period you will be recieving a welcome message to the list.  You can save this message for a later date as it will have instructions on subscribing/unsubscribing to the list.

The new mailing list address will be coas@cs.fiu.edu but we will still be able to send messages to coas@baptisthealth.net

If you have any questions/concerns, please feel free to contact me at ericn@baptisthealth.net

Thank You,
Eric N.