CCOW Technical Committee Meeting Minutes

CCOW Technical Committee Meeting Minutes

10/2/01

Attendees:

Rob

Rob

Tim

Paul

George

Michael

Kendza YenHL7

Dan

Darrell

Eric

Barry

Jeff

Mark

1. Reviewed agenda

Tuesday:

1. Elect co-chair

2. Review CCOW V1.4 ballots and reconcile

3. Summarize discussion topics for Wednesday

Wednesday Morning:

(After discussion, separated item 6 into two items (6 and 7) and added items 1 and 8.)

1.CCOW status in the industry

2.Review Duke proposal for additional context annotation subjects (User Info, Device Info)

3. Discuss various comments/issues pertaining to the existing CCOW specification documents

4. Explore SOAP technology mapping

5. Relationship of CCOW to HL7 V3

6. Discuss CCOW for multi-facility uses

7. Discuss CCOW for mobile devices

8. Conformance statement for component replaceability

Wednesday Afternoon:

1. Continue morning discussions as necessary

2. Discuss plans for CCOW demonstration at HIMSS 2002

3. Develop plan to complete CCOW V1.4

4. Develop plan to begin CCOW V1.5

.

2. Review of Ballot Comments/Reconciliation

2a. Ballot closed with following vote count:

Total:43(71% of pool of 61)

Yes:36(84% of yes/no)

No:5

Abstain:2

2a. Issue raised by Jon Farmer – Reference to PID-2 as opposed to PID-3 for certain patient context data items is out of date.

Reconciliation proposal presented to CCOW TC:

1.The existing references to PID-2 will be retained for backward compatibility for those who have already implemented CCOW-compliant applications.

2.Will clarify that the data definition for the newly defined for CCOW V1.4 patient context item Patient.Id.Idlist is based upon PID-3. Presently the specification does not refer to any PID segment in describing this data item.

3.Will note in the specification that patient context items representing MRN, MPI, and NationalIdNumber, all of which refer to PID-2, will be deprecated at some point in the future.

Vote:Favor – 12No – 0Abstain – 1

Jon Farmer was not present at the meeting. He will contacted to determine if he wishes to alter his ballot vote in light of the reconciliation proposal.

2b. The issue raised by Siemens in its negative ballot concerned the potential for context actions to overlap with existing general computing and healthcare standards. Siemens indicated its willingness to change vote to affirm if the following are agreed to:

1.Always must be a relationship between an action subject and at least one identity subject

2.A context action must always be triggered by direct user action.

3.An agent that implements an action then must present a user-interface when it services the action, known in CCOW V1.4 as a continuation.

The CCOW TC proposed the following response to Siemens:

1. Action subjects taken under consideration by the CCOW TC for standardization must solve a problem that is consistent with CCOW purpose of supporting “front-end” integration at the “desktop”.

2.Agreement on Siemens proposal item #1.

3.Agreement on Siemens proposal item #2.

4.Agreed with the spirit of Siemens proposal item #3, but with the caveat that certain actions may not necessarily have a user-interface (i.e., continuation). The specification will be modified to emphasize continuations, but will allow applications to not implement a continuation if (a) it does not make functional sense for the application to do so or (b) the specific circumstances in which the action is being performed do not require a continuation.

The CCOW TC unanimously voted to recommend this response to Siemens:

Vote:Favor – 13No – 0Abstain – 0

This vote included Barry Royer as the Siemens representative, who also verbally indicated that Siemens would now change its ballot to affirm.

2c. Rob introduced an issue surrounding the definition of the use of existing Mapping Agents as part of the Context Action via the use of defined aliases between the Context Action context items and Identity context items. Agreed to add to CCOW V1.4 by committee.

Proposal for deprecating the Mapping Agent interface, given the added definition of CA interface. Agreed to add to CCOW V1.4 by committee.

2d. An issue regarding the behavior of session mgmt not being well defined is raised by McKesson (see McKesson document). Concern is over a vendor wiring in the Session Manager to their specific application suite in a manner that goes beyond the scope of the CCOW specification. The result would be that the Session Manager would be tied to the applications and could not be replaced with a different Session Manager. It was recognized that the issue of CCOW component interchangeability is of general concern and applies to all of the CCOW-specified components.

One suggestion specifically for Session Managers was to issue an RFI and compare the response to determine pertinent commonalities that could be defined as part of the CCOW standard. However, it was observed that having more specificity about the Session Manager would not necessarily be well received by vendors and could hamstring creativity and innovation. Further, additional specificity would not necessarily address the interchangeability issue.

It was also observed that the CCOW V1.4 specification is missing a conformance statement for Session Managers. It was agreed that one will be added.

It was then suggested that the wording for all of the CCOW conformance statements be enhanced to assert that each CCOW-compliant component must be compatible with any other CCOW-compliant component. It was agreed to revisit this on Wednesday.

2e. Concern over authentication as it refers to logging out versus exiting an application. It was pointed out that the specification of how to deal with this exists, but that it is deep in the text of the standard. Potential work item for future is an overall index / checklist of things applications need to do in order to be compliant, as culled from the various sections of the standard. Revisit as potential work-item for future version of the CCOW specification.

2f. Note: 14.9 of the Architecture document has a reference with a page gap in the middle of it.

2g. Note: Subsequent to the meetings, both Siemens and Care Data Systems officially changed their ballots to affirm. This means that the CCOW V1.4 Committee Ballot has passed unanimously with 41 affirm and 2 abstain.

3. Election of Co-Chairs

Rob’s term of co-chair had expired. Michael Macalusso, a former co-chair, previously resigned when he left the healthcare industry. Rob had been previously nominated for a new term. Rob nominated Dr. Michael Russell, a physician and associate CIO at Duke University Health System, for the third co-chair slot. Both candidates were unanimously elected. Barry Royer, a present co-chair, remains in his term.

10/3/01

Attendees:

Rob

Rob

Tim

Paul

George

Michael

Kendza YenHL7

Dan

Darrell

Eric

Barry

Jeff

Mark

Blair CockerlineU of

Ed LarsenER Larsen,

Jim LongHL7

1. CCOW Industry Status

General discussion on CCOW Status in Industry. The end result is the market is driving uptake at a fairly aggressive rate.

2. Duke Proposal for New Annotation Subjects

User Info Annotation – Role, Application-Specific Access Privileges; Dependent on User and Patient:

.

Issue would be for each vendor to externalize access privileges that is appropriate for their application. This would eliminate establishing access rights in each application through independent user interfaces. Instead the HCO could control this centrally via one administration tool. Agreed that this idea warrants further discussion. Request to Duke to present use cases.

Access Device Annotation – Location, Security Class, Time Zone; Device Identity Subject:

Issues:

1. Dependencies on multiple parent subjects
2. Definition of Device Identity Subject

The idea was floated to make the device info an annotation on the User subject. This would eliminate issue #1 and possibly issue #2. The concern was raised about what happens if there is no user. It was observed that there can still be a valid annotation on the “empty” user.

Action Item:Request use case and explanation from Boyd Carlson, et. Al. for User Info Annotation Subject.

Action Item:Pass back feedback to Duke on Device Annotation Subject potentially consider as items for User Info Subject. Request feedback from Boyd Carlson, et. Al.

3. Miscellaneous Document Issues

3a. Darrell Hansen presented the following issues:

The following issues pertain to the Architecture specification:

1. Some inconsistencies in initiating a session, want to make sure that is consistently stated throughout the document.

1. Deactivated session allowed to process change transaction – What is the user interface – Session Manager only app to manipulate deactivated sessions.

1. “Issue of if for a context change transaction the data has not changed the apps will not be surveyed…” add comments reflecting that for context items that are case sensitive a change in case constitutes data change.

The following issues pertain to the Web specification:

1. 10.1.3.1 context participant parameter why need URL for the call to Locate?

Answer: Clarify that use of this URL can enable optimization of CMR, and affect its response to the Locate call. For example, if caller is using a HTTPS connection and passes in an HTTPS URL, then the response will be on a secure URL, if the call is made on a non-secure URL then the response is on a non-secure URL.

1. Why isn’t cpURl parameter to JoinCommonContext required?

Answer: It was required in CCOW V1.3. Looks like a documentation error in V1.4. Will be corrected.

1. 10.2.4.1 Create method’s output newContextCanager … how to deal with with an HTTPS URL?

Answer: Same as for #4 above.

1. 6.1.5 Interface Reference Management - Issue is that is this too specific for the CMA and only addressed in the ActiveX.

Answer: Stateful components have a way of managing interface references whereas stateless components release the reference due to the nature of HTTP connections. So, there is indeed a way to manage interface references in web implementations of CCOW.

1. Clarify whether the URL encoding characters are used in computing digital signatures.

Answer: Clarify that it, per the Architecture specification, only the characters that represent the data values are used in computing the signature.

1. Question about whether CCOW should specify specific tools and/or APIs to use when implementing CCOW web components.

Answer: Not in CCOW’s scope or interest to specify specific vendors web tools or APIs as there are so many to chose from.

1. Question about CCOW’s position on denial of service attacks.

Answer: CCOW has concluded that it is not able to defend against denial of service attacks, and that this must be done at the network layer. Therefore, attacks that can deny services but which in of themselves do not violate security or corrupt the context are not defended against. No reasonable way of protecting against this. At there is an article on denial of service attacks.

3b. What are the HIPAA implications from CCOW? REVISIT in future meeting.

3c. In Web Mapping, Sect. 10.1.1, InterfaceInformation the Argument Name “interface” has been duplicated.

1. Define new interface and deprecate existing.
2. Change the context item name.

Consensus that we will change the context item name “interface” to “interfaceName” Note: make sure we highlight this change in the change summary section.

4. Soap Technology Mapping

SOAP technology mapping – last time it was visited we were to recalibrate with further knowledge gained. There was no additional or current use of SOAP amongst the participants. The remaining argument was that tools are starting to be delivered by Microsoft with .Net and IBM, and their tools would be key if adoption is to be significant.

Decided to continue with wait-and-see process. Specifically, consensus on waiting until the absence of a SOAP mapping for CCOW becomes a barrier for a vendor to implement CCOW capability to their application.

5. Relationship to HL7 V3

It was agreed that aligning CCOW with V3 could mean one or more of the following things:

1. Compliance with the RIM
2. Use of V3 data types
3. Use of V3 messaging mechanisms (SOAP?,ebXML)
4. Use of V3 modeling methodology

Suggestion was made to look at personnel and security committee activities as also parts of harmonization with V3. There seems to be an opportunity to add CCOW “infrastructure classes” to the RIM, although the advantages of doing so were not clear. There also seemed to be the opportunity to refine the RIM’s domain classes based upon CCOW needs.

General consensus to start with data types used in existing CCOW context item data definitions, and to evaluate how to fit into CCOW’s programming model a representation of these data types in XML.

Concern was expressed about CCOW potentially getting ahead of the industry use of V3. Question was posed as to the current status of uptake or plans of uptake amongst vendors for V3?

6. Multi-Facility

The issue was raised that a caregiver may need to access different facilities from a single physical device (e.g., PC), where each facility has its own context-sharing application and associated CCOW infrastructure (e.g., context manager, mapping agents, etc.). Problems can arise with this scenario because the CCOW specification only allows a single context session per device. It was observed that the CCOW V1.4 draft capability for multiple sessions may address this. It was decided that additional use cases are needed, for the next meeting.

7. Mobile Devices

Duke implemented prototyping of CDR client viewer on the handheld whereby there was regular polling to sync clinician with specific patient data.

Two scenarios

1. PDA / Handheld with multiple applications using CCOW to sync applications.
2. PDA with current user / patient being passed to clinical workstation.

A second implementation is a traditional PDA sync scenario.

Action Item: Request of participation from handheld application vendors at January meeting.

Users practicing in multiple institutions with likely having different CM infrastructures. It was proposed that this might be a part of the Session Manager functionality.

Action Items for January – Investigate / document use cases for multi facility environment

8. Conformance Statement for component replaecability.

Making the implied explicit.

Action Item: Propose some wording for the component replacability statement for email review by next submission of documents for January Ballot of 1.4

Note to Rob: Section 18.2 of CMA is blank.

Afternoon ----

1. Continue Morning Discussion

Discussion incorporated into notes above.

2. HIMSS

Demo for HL7 for HIMSS is planned. Includes a CCOW demo.

Potential CCOW participants:

CmoreProvalent (app)

DukePatient Browser (app)

SentillionContext Manager

InnovisionPMA, Action Agent

CernerPowerChart (app)

McKessonPhysician Portal (app)

GEMUSE (app - Dan S. to investigate with GE colleagues)

3. Version 1.4 Modifications

Edits will be made and reviewed over email – goal to be over by middle of November. Goal to go to full membership ballot in December.

4. Version 1.5

HL7 V3

Start information model of CCOW infrastructure classes – Barry R.

Start Model for Domain components of CCOW that may be missing – Rob S.

Comparison of Data Items to V3 data types – Rob S.

Arrange for training on V3 for CCOW TC – Paul S.

Define multi-facility use cases for CM – Darrell H.

Define use cases for handheld devices – Mike R.

Call for participation among handheld vendors for use cases at next CCOW meeting – Mike R.