Review Annotation Subjects
CCOW Meeting, April 30 & May 1, 2002
Attendees:
Robert Seliger, Sentillion
Mike Russell, Duke
Barry Royer, Siemens
Darrell Hansen, Carefx
David Fusari, Sentillion
Fred Owens, Affinitex
Dan Soule, Cerner
Eric Weaver, Sentillion
Andrew Woyak, GE Medical
Prashila Dullabh, Lexign
Ray Langford, Lexign
John Baldasaro, Eclipsys
John Minetos, Eclipsys
Jack Harrington, Philips
B.J. Lawson, Mercury MD
Ivan Cveuic, A.L.I Technologies
Geoff Pascoe, Philips
Tim Barry, Innovision
Rob Wilmot, Innovision
Pete Routey, VA
Bill Moroz, Sybase
Amy Page, VA
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 non-surveyable 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]
******
*****