CCOW Meeting Minutes – 5/23/00
Minutes recorded by Jon Farmer and Mark Morwood
Rob Seliger
Brian Bishop
Mark Morwood
Gunnar Klein
Melvin Reynolds
Jon Farmer
Barry Royer
Mohamed Oukani
Paul Biron
Cameron Moore
Andrew Woyak
Gary A. Bartlett
Michael Russell
Luis Edwards
Kathy Kemper
Hennie du Plessis
Ed Larson
Sentillion
University of Alabama at
Birmingham Health System
Sentillion
Karolinsua Institute, SW
AMS Consulting
Care Data Systems
SMS
IDX
Keiser Permanente
3M
MedicaLogic/Medscape
Emory Healthcare
Duke Univ Health System
Gettysburg Hospital
Group Health Co-op
PQ Africa, South Africa
E R Larsen Inc
robs@sentillion.com
bebishop@uabmc.edu
markm@sentillion.com
gunnar@klein.se
melvin_r@amsc.demon.co.uk
jfarmer@ic.net
barry.royer@smed.com
oukani@idx.com
paul.v.biron@kp.org
ckmoore@mmm.com
andy.woyak@medicalogic.com
gary_bartlett@emory.org
michael.russell@duke.edu
ledwards@gettysburghosp.org
kemper.k@ghc.org
hennie@qedi.co.za
elarsen@erlinc.com
Discuss CCOW web-specification negative Ballot issues

Discussion on use of term W3C vs. “web” in CCOW web-spec.; decided to simply search and
replace with “web”.

Likewise, for Negative Ballot pg.28 line 1 suggestion to use “web” rather than W3C.

Will give Unicode codepoint values to define characters.

Agreed to add document references rather than (or in addition to) summaries

Agreed to take no action on overly-conservative inclusion of hex characters

P37, line 10-11: Characters set: replace each “Unicode character” with “Unicode codepoint” and
strike the “(UTF-8)”
P9 line 1: correct by removing statement that connections are broken and reestablished for each
HTTP message.
Unicode vs. ISO xxxxx vs. UCS: will say “Unicode”.
URL vs URI: URLs are locators. URIs are generic identifiers (and are not necessarily
dereferenceable to find their location), URNs are names. We should be using URLs not URIs
(and we are). We agreed our spec is concerned with “Absolute Dereferenceable URLs”.
Will use URLs to the exclusion of URIs.
Section 6 first paragraph will be clarified regarding requirements of posts and gets.
Side-effects issue: \
CCOW is using native HTTP Gets and POSTS as a remote procedure call mechanism, but is
subject to concerns regarding caching side effects. We agreed to require use of “nocache”
parameter on both gets and posts so as to eliminate vulnerability of receiving cached responses.









URL encoding of literal CCOW as part of filepath – agreed NOT to required it.
Method names – parsers should ignore parameters they do not recognize. Also remove the
implication of a required order of parameters, since they are named
Web Spec comment resolution continued:




ParticipantCoupon needed for secure get: Agree – Arch spec now state as optional dependent upon
mapping. Web requires.
CP URL as data for CMR::Locate. Agree.
Clarify the use of the URL returned by CMR::Locate, Resolution: return two args, the base URL
plus optional args. These must be appended to the URL or sent as POST data.
Dependent subjects: clarify wording. DAGs allowed. Directed Acyclic Graph.
Vote in favor of accepting changes 9 yes, 2 abstain. (Paul Biron agreed changes met his requirements and
will send an email changing his vote to affirm)
CCOW 1.2 is passed! CCOW 1.3 goes to full ballot.
Discussion:
CCOW uptake.
Lunch.
Review CCOW Roadmap from last April and compare with current status.
Ideas discussed:

















CCOW Longitudinal View, Summary View, … (John Farmer)
CCOW + wireless
XML
SOAP
Role-based access privileges
Multi-device context sharing
Multiple concurrent context sessions
Sharing context across a co-located workgroup (e.g. herd of doctors on rounds)
Trusted environment context
ACLs for Context Subjects
Session management (SMS), single sign off, activity monitoring
Context Events
Workflow Context (Macro/Micro)
Person context – (edu person – U. of Michigan; c.f. RIM’s person object)
Stacked Contexts
Addition contexts
HIPAA
For tomorrow assess next steps based on some criteria:
e.g.




Simplifies app integration
Providing end-user features
Leveraging existing CMA
Time to market


Backwards compatability
Leverage/complement existing standards
Agenda for tomorrow:
CORBA technology mapping draft
SOAP technology mapping
Roadmap discussion and refinement
Action plan for next meeting
Minutes for CCOW session Wednesday 5/24/00.
Minutes recorded by Jon Farmer and Mark Morwood
Attendees:
Barry Royer
Gary A. Burtlett
William Eckels
Simon Curtis
Mark Morwood
Jon Farmer
Michael Russell
Melvin Reynolds
Cam Moore
Alan Chan
Andrew Woyak
Mohamed Oukani
SMS
Emory Healthcare
IDX Systems Corp
IDX/Channelhealth
Sentillion
Care Data Systems
Duke
AMS Consulting
3M
VA
Medicalogic/Medscape
IDX
Barry.royer@smed.com
Gary_Burtlett@emory.org
William_eckels@idx.com
Simon.curtis@channelhealth.com
markm@sentillion.com
jfarmer@ic.net
Michael.Russell@duke.edu
Melvin_r@amsc.demon.co.uk
Cmoore@mmm.com
Alan.chan@med.va.gov
Andy_woyak@medicalogic.com
oukani@idx.com
CCOW CORBA Technology Mapping

Mark Morwood presented draft spec created by T. Haug and A. Klingler
CCOW SOAP Technology Mapping



start mapping work when market looks ready and when somebody wants to work on it
Will assess benefits – are there particular benefits, or, “just another mapping”
SOAP implementation would likely might be be less complex than the HTTP mapping. Maybe
will permit integrating the component’s security infrastructure by holding chain of trust
Function Activation




A high-demand application of this is for participant to ask for the ”patient search” function to be
surfaced.
o Not clear whether CM will delegate or just give the caller a pointer
o Apps register the functions they implement (like patient search)
o Any participant can activate the “patient-search” app through the context manager. This
is powerful because the participant would not have to know which app can do the search.
o Many departmental systems would rather not implement patient search themselves
(radiology system doesn’t want or have the whole patient population in its local MPI)
Also would be useful for an app to ask for activation of the user authentication.
In both cases, the common concept is that a participant is asking for an instigator for a subject.
We should still keep it generic and extensible for use with other services.
Use Model for Multiple Device, Shared Contexts, Stacked
Contexts

Presently, the device and the context have a 1:1 relationship. How to support multiple contexts on
a device? How to adequately decouple the devices from contexts? PDAs might be an important
device to address soon – to get context from a workstation, or PDA patient gets set from bed; But
the PDA should set patient as approach monitor at nursing station. Probably need to specify rules.
While approach device – join its context and then instigate or be instigated, by subject. A location
context subject? With dependency rules?











Does the mobile device have its own context (at least user – so user need not reauthenticate as he
walks to different device)
How does a device put a location into context? And it persists (or reinstates) when the PC is
turned off. What does a “location” look like? A Facility/Unit/Room/Bed might be an 80/20
starting point that specifically addresses the use case of caregivers approaching beds. How will
the bed context change drive the patient change?
How to coordinate multiple context managers? Sharing subjects?
Physician (user) can be in two organizations and two contexts
Multiple concurrent contexts for one user in multiple enterprises (e.g. doctor doing referrals)
enterprise
Context “stack” for interruption-contexts
Allow apps to store any application state to be restored when appropriate
Multiple concurrent contexts with shared and unshared subjects – is this a context item with
multiple instances? Or a separate context?
When joining, how does a participant specify which subjects of which contexts?
Context spawning – inheriting a “starting context” with the same user.
Usability issues – determine differentiation and establish defaults. – Maybe use color and fonts.
Barry volunteered to do a white paper on mult-context-single-device
Single Signoff - means set user context to null
ACLs for Context Subjects – Private subjects – that only certain
apps can see

Since Confidentiality policies are not commonly expressed in terms of which apps can see what,
we are not sure this is adequate popular demand, or that it is an appropriate HL7 problem to solve.
Trusted Environment Context
Those present didn’t feel qualified to discuss this one without having the idea-originating person present.
Context Events
Publish & Subscribe – not significant priority for more dicussion today
Workflow Context
Sync all apps to the “todo” lists? User’s workflow? Sounds like an application.
Person Context
As opposed to patient or user – we think we should address this when we do V3-RIM-based subjects or
stakeholders
Additional Contexts
Example – be able to propagate current insurances for the selected patient.
HIPAA
Given user context and and patient context – useful to enforce access controls?
Session is the user plus the consent policy
CCOW provides security parameters (user identities and roles) to apps
Security – Authentication, Auditing of Accesses as a context trail
Identifiers – mapping agent can permit national identifiers to be moved into the context for the apps.
Groupings
Security
Context Complication
S HIPA
e A
c
M H
PRIORITY
CCOW + wireless
Longitudinal View
XML
SOAP
Role base access
x x
privileges
Multi-device context x
sharing
Multiple concurrent
contexts
Context sharing
x
across workgroup
Trusted envt context x
ACLs for Context
x
Subjects
Session
x
Management, single
signoff
Context events
Workflow ctxt
Person context
Stacked context
Additional context
HIPPA
x x
Dynamic context
x
definition (Ken
Rubin)
*Subject to stability of RIM items
More
Complex
Context
M
Device
Support
Tech
mapping
M
x
L
x
XML
/
v3
H*
Funct
Activ
ation
M
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Next Steps
Due to the lack of a quorum after lunch, it was decided to establish follow up action items for the next
meeting using email to the CCOW list.
Before he had to leave to catch a plane, Barry indicated interest in producing a white paper for the next
meeting on the requirements and issues associated with supporting multiple contexts per desktop and
multiple desktops per context.