CCOW Meeting, April 30 & May 1, 2002
Attendees:
Robert Seliger, Sentillion [email protected]
Mike Russell, Duke [email protected]
Barry Royer, Siemens [email protected]
Darrell Hansen, Carefx [email protected]
David Fusari, Sentillion [email protected]
Fred Owens, Affinitex [email protected]
Dan Soule, Cerner [email protected]
Eric Weaver, Sentillion [email protected]
Andrew Woyak, GE Medical [email protected]
Prashila Dullabh, Lexign [email protected]
Ray Langford, Lexign [email protected]
John Baldasaro, Eclipsys [email protected]
John Minetos, Eclipsys [email protected]
Jack Harrington, Philips [email protected]
B.J. Lawson, Mercury MD [email protected]
Ivan Cveuic, A.L.I Technologies [email protected]
Geoff Pascoe, Philips [email protected]
Tim Barry, Innovision [email protected]
Rob Wilmot, Innovision [email protected]
Pete Routey, VA [email protected]
Bill Moroz, Sybase [email protected]
Amy Page, VA [email protected]
Tuesday May 01, 20002
Review Annotation/Action subjects
Roles/Privileges Annotation
Duke proposal not changed much from October.
Enforcing rules in the context management system.
HIPAA and other needs will make the administrative issues of managing users will be a
significant task.
Externalizing privileges from apps may be more of an administrative need. CCOW
typically has not addressed admin needs, this may be useful but probably outside the
scope of CCOW.
Roles taxonomy standards are not well defined in an industry standard.
Within different apps you may have different roles so a single role in context may be
difficult.
Defining roles in a standard way is a large and daunting task.
Little value in putting the role in the context.
Roles in apps are typically configured based on sites needs. Role is only one aspect that
an app uses to determine privileges (others things used to determine privileges are
position, location)
If apps start with a blank sheet of configured roles then a site could create a common
taxonomy among apps to create a consistent representation of role.
Does HL7 v3 have role definitions that may be useful for defining a role?
App vendors should consider whether this is useful and would make use of it?
Can a role morph based on need/workflow and is there value in conveying this change to
all other apps?
Patient Demographics Annotation
Doc presented by Eric Weaver from Sentillion.
Not mapped to v3 datatypes, do this as part of general effort for mapping to v3.
Seen as a secured subject (needs a secure agent) and secure “gets”.
Dependent on patient.
Agent represents single master source (i.e. registration system) for this info.
Data based on PID segment in 2.4.
Does not include deprecated items in 2.4.
CCOW in general may need to create some consistent conventions for describing “lists”
in a data definition.
What is use case for this subject?
There is likely other clinical data that is more useful (height, weight, etc) Is this a
different annotation subject to contain this info.
Only make use of patient demographics if nothing available in app. If app already has
this info then it should ignore it, even if in conflict.
ADT messages already facilitate passing this info around to other systems.
Rob described a small departmental system where the amount of HL7 data was
overwhelming to the apps database.
What about if an app modifies demographics, should that be conveyed through CCOW –
probably not.
Allergy Update Action
Presented by Mike R. from Duke
Need consistent source for allergy data and all systems need to have access to allergy
data.
No consistent method for encoding/representing allergy information.
Use Allergy update Action to cause “Gold Standard” allergy app to appear in patient
context and then add allergy. When updated the “Gold Standard” would send through
HL7 to all other systems to store allergy info themselves as needed.
There could be a latency issue by the time you get back to the instigating app and it
receives the HL7 update.
Allergy action reply could include the allergies entered so no latency.
Mapping/conversion of info so instigating app can understand the response. Difficult
task is getting instigating app to apply these as needed.
Is there a larger clinical CCOW theme that encompasses a number of action and
annotation subjects?
Order Entry Action
Andy Woyak’s domain expert is no longer available
Is working with a POE something more significant than an action?
Is using a CCOW action going to provide a more timely response to the order placer.
How can apps be structured to be flexible to run in environments that may or may not
have the action agents?
Is there a synergy between web services, presentation, workflow – what does this mean to
the SOAP binding?
Signature Action
Presented by Prashila from Lexign (see slides at end of this document).
Mike R. raised issue of how will a digital signature stand the test of time, paper records
can be understood forever. The signature format is standardized and all data to verify the
signature is stored as part of the signature blob.
Workflow issue that there may need to be a grouping documents to sign so the user does
not have to re-enter pin code for each doc.
Discussed issue of possible overlap between authentication for logon purposes and the
needs for electronic signature. These appear to be separate needs but could they be one
in the same.
App responsible to clearly convey to user what is being signed.
Agent does all signature computation.
Reviewing actual subject definition:
input - practioner should be changed to be similar to what is specified in
authenticate action subject.
input – purpose, does list of possible values need to be described in the standard,
also may need users role as an additional param (or should role come from
context)
input – manifest should be a hash of data, not the raw data
may need another action for verification/validation
output – need to revisit outputs for type/representation and format. Also need to
output of the signature itself
SOAP Review
Representing repeating values other than using bar encoding
There may be value for clients for using soap because of tools availability
When is XML schema needed, during run time or only development time – HL7 will
need to host reliable services
How should data items be represented – hl7 xml style or the current ascii encoding,
thinking is XML all the way.
SOAP does not obviates the need for client side applets
SOAP may be more complex for the client side needs of CCOW because all is sent as
HTTP Post rather than a simple URL.
HL7 V3 Datatypes
No fully ratified 3.0 spec available
CCOW for Multi Facility
Physician can admit to 2 different hospital, each hospital has 2 different infrastructures.
Need for the desktop CMR needs to be different for each app.
What is the users experience to make the selection to determine which site to use. Likely
that user deals with one site at a time.
Barry proposed idea of multiple ports for the CMR that can be configured based on the
web servers that may be calling the CMR relative to the particular site
CCOW for Mobile Devices
BJ – pass context as apps come into focus, no need for CCOW 2-phase commit.
only one window is visible at a time (for pocket pc and palm), some tablets may obviate
this restriction.
Palm is very restrictive, perhaps lean more towards pocket pc platform.
Agents may need to be remote or only keep a limited amount of data based on users
needs.
Wednesday May 2, 2002
Can collections of new subjects be correlated under themes like a security theme or a
patient safety theme.
Try to target January 2003 for a 1.5 release focused on no new architectural concepts but
content only (new subjects).
CCOW will need to see if the new Java SIG has any relevance to CCOW.
CCOW may need to tie into activities of security SIG.
Annotation/Action Subjects
Roles/Privileges Annotation
Role may change relative to patient or situation (emergency situation), not just based on
the user.
Is it really role or is it workflow oriented (not who individual is but rather what they are
trying to do).
Perhaps a way of thinking about role is “purpose”, not an annotation but an identifying
subject.
There may be a need for a consistent taxonomy so the “purpose” can be commonly used
by apps but this could be unreasonable to accomplish
The taxonomy should be abstracted through a mapping agent and configurable. The
mapping occurs on site. Apps document the different views they support then site
configures.
What to call this capability, not workflow subject?
Is there a thrashing problem of potential context change switches. Is this a nonsurveyable task?
Roles and Privileges do not feel like a good fit for CCOW. Apps may not make use of
this as privileges are closely tied to app behavior. Administrative issues for managing
roles/privileges may be taken on by other group
Will pursue the idea of a “View” context.
Demographics Annotation
Possible kinds of data safety items: height, weight, lab results, prior doses, age, gender,
allergies are data items related to filling a patient order for patient safety.
Perhaps look to the “Leap Frog” group for core set of patient safety data items.
Annotations by nature should always come from the trusted source and it is the
enterprises choice to select that trusted source. This may be a mindset shift.
Barry voiced concerns that annotations push the boundaries of CCOW context. Perhaps
an HL7 messaging action agent would suffice so an app can perform a query for
annotation type data.
Andy likes it!
Update Allergy Action
Still need to solve the synchronization timing issue between when agent updates its store
and the instigating app, and other apps, have been updated. In a CCOW environment a
user may perceive apps running as one big suite so it may be expected that data should be
available and updated in all app instances immediately.
Can there be an annotation tickler subject that forces only the annotation subject to be
refreshed – subject dependencies are an acyclic graph.
Order Entry Action
The need is for simple control flow to the POE app with the appropriate context and the
Action request and response are fairly simple.
This may be more of a “view” style context described earlier under role/privileges.
A site may have many different ordering apps (inpatient and outpatient). Is there a
different action for every type of order? CCOW implies a single agent for a single
action.
Signature Action
Per HIPAA it is likely that the signing agent will need to keep a log of what it has done.
Dan thinks vendors are likely to trust this as a service and many will want to delegate all
of the robustness and management capabilities to another service.
Try to support only a single user authentication but in some instances the agent may need
to force a re-authentication using the same means as logon. CCOW may need to support
nested actions or the instigating app can force the authentication action before calling the
signing agent (not the preferred approach).
Agent inputs may need to consider processing a batch (list) of manifests to process in one
call.
After some discussion it appears that supporting nested can be accommodated with little
CCOW architectural changes.
no context changes can occur while actions are in progress
actions do not have to be re-entrant, this should be enforced by the CM
errors are propagated all the way back through the stack.
User Certificate annotation should probably stay and not be deprecated.
A concern was stated if there might be a need for a signing agent needing to invoke a
different authentication action agent other than the one the user logs on with. There is
currently nothing in the CCOW spec that precludes a CM system from allowing it to
determine from the context, using all available information to route the action request to
the appropriate action agent. In the absence of providing this in the CM, CCOW would
need to define at a fine grain the possible set of all actions that might need to be
supported.
App synchronization relative to annotations
Described in previous meeting notes there seems to be a fundamental need for apps to
display common information consistently. If app A changes the phone number then app
B should show the new phone. Getting to data synchronization is a significant effort
beyond context id sharing.
There are and will be visual inconsistencies that CCOW cannot solve. This problem
exists today without CCOW.
The rule for using annotation data may be: “if your app can receive this information
through some automated means then it should never pull or reference the information
from the annotation”. This is the original conception and the standard should clearly
state this.
Action Plan
May be able to create a draft standard from CCOW to encompass the new subjects being
explored and decouple them from the need for a full version 1.5 ballot.
Roles/Privileges and Order Entry will not be pursued – lack of interest and feasibility
The group discussed the basic requirements that are needed in order for CCOW ideas to
be pursued:
an application interested in the capability
the proposed cm changes (if needed),
agent support (if needed)
a venue where pieces would come together.
Without these critical pieces (and a coalition) there “may” not be enough relevant interest
to pursue a CCOW concept or CCOW subject.
HL7 V3 datatypes – continue using 2.x for now. Maybe use consultant to examine how
v3 datatypes map to CCOW, if funding becomes available
Assignments:

Update Allergy action – For now Duke will pursue this as a custom action subject
but potentially role this into a draft standard. [Mike Russell]

Crisp definition for annotation usage in the standard [Rob, Barry]

Patient Demographics will be pursued under the constraints of the crisp
annotation definition. This will be part of a larger patient security
theme/grouping of annotation subjects. [Eric, Dan]

Pursue signature action and adopt nested action capability [Prashila, David F.]

Pursue SOAP binding [Rob Wilmot, Tim, David F.]

Pursue “view subject concept to see if something materializes. [Darrell and John
B.]

CCOW for multi-facility – use cases need to be refined and should make sure
technology solutions are not part of the use case. [Darrell, Dan]

Mobile platform – target pocket pc platform, adapt CCOW concepts to this
platform. [BJ, Rob]
******
Signature is part of context
• “authentication” aspect of signature is a property
of the user, e.g.
– user private key, user’s assigned ‘computer code’,
biometric
• electronic signatures are implemented per
enterprise policy which generally is not
application specific
– driven by regulatory, business and legal necessity
• at least some electronic signatures are required
persist independent of the application which
created them
Motivation
• Variety business and regulatory requirements for
some form of signature upon
– medical record entries, H&P, operative notes, discharge
summaries
• Electronic signatures can be used to satisfy all legal
and regulatory requirements for signature ~ US
Public Law 106-229 (E-Sign)
– preemptive of contrary state law
– regulators can impose ‘performance requirements’ on
electronic signature implementations
• Electronic signatures provide new opportunities for
improved compliance, simplified workflow, and cost
reduction
Electronic Signature
Requirements
• By definition, electronic signatures involve:
– explicit action of the part of the signer
– a mechanism to authenticate the signer
– some procedure to bind signer to manifest (document)
• Additional requirements are implied by document
purpose
– compliance to various medication and med rec
regulation ~ unique signer authentication
– demonstration of medical necessity and conformity to
plan protocol in support of claim ~ transportability and
independent verifiability
– liability defense and other litigation purpose ~ ‘nonrepudiation’ and long term persistence
Need for Abstraction
• Electronic signature requirements are derived for document & signature
purpose which is a function of:
– regulation, both state and federal
– enterprise policy
• Multiple methods of implementation
– different classes of practitioner and document types
– digital signatures, signature by computer code entry , biometrics,
digitized signature pad to name a few
• Developers of clinical applications cannot anticipate all policy options or
signature methodologies
• HIPAA does not mitigate
– per the NPRM, Rule applies only to HIPAA transactions
• not preemptive of state / Fed medication / med rec regulation
– per E-Sign, Rule must be technology neutral
CCOW Signature Action Agent
• Implements enterprise electronic signature policy
as a function of user, signature purpose
• Shared signature responsibility
–
–
–
–
clinical application displays document
signature agent captures user’s ‘signature act’
signature agent computes signature representation
clinical application records signature / retains
representation
Some Issues
• Mechanism to enforce ‘conformance’ between
document rendered by clinical app and manifest
over which signature representation computed
• Identification of signer. Typically this will not be
an assigned user name, rather ‘legal’ name as
appears on medical license and the like. How
does the context make this available to agents?
• HL7 data types for signature manifest and
signature representation
• Coding of reasons for failure to obtain signature
• Bandwidth
*****