Agenda

1. Agenda Monday, April 26 - Main Topic: Ballot Reconciliation 8:30 - 9:00 Introductions, Agenda Review, Elect Co-Chairs 9:00 - 5:00 Ballot Reconciliation Tuesday, April 27 - Main Topic: Next Steps 9:00 - 9:30 Review Candidate Next-Steps & Agree on Agenda 9:30 - 2:00 Technical Discussion About Next Steps Agenda 2:00 - 3:00 SMS Ballot Reconciliation Discussion 3:00 - 4:30 Planning for Future Demonstrations 4:30 - 5:00 Decide Upon Logistics for Interim Meetings

2. Ballot Summary • Virtually Unanimous. • Several significant comments. • Triplet of identical negative ballots from SMS: • 27 comments • 5 classified as negative major • 15 dropped since teleconference

3. Reconciliation Process • Reconciliation Committee formed in March by Wes and Rob: • John Hall, HBOC Kyle Marchant, 3M Mark Stega, GE/Marquette • Two teleconferences (4/19 and 4/22). • Monitoring of ballot responses. • Investigation of issues reconciliation proposals. • Proposals to vote by SIGVI at April meeting.

4. Comments Deserving Comment • Bas Van Poppel, HISCOM, commented about localizability concerns that arise from the use of the HL7 PN data type to represent patient name. • John Hall, Rob Seliger, commented that the SecureBinding interface does not quite implement the capabilities described in the text. • Karen Keeter, IBM, commented that a web-centric/thin-client context management solution is needed.

5. Comments Deserving Comment The following comments are from SMS: #10 -- “Some current HIS transaction applications serve as proxies for asynchronous activities, store/forward EDI, etc. How are these to be accommodated?” #11 -- “What requirements are addressed by allowing applications to query the context data during phase 1 of the notification process? Shouldn’t participants respond based on their own state?”

6. Comments Deserving Comment The following comments are from SMS: #13 -- “Please be more explicit about the relationship between the ContextData and SecureContextData interfaces. Can User subject data be communicated through ContextData interface? Conversely, can Patient subject data be communicated via the SecureContextData interface?” #22 -- “When a participant is informed that the common context is being terminated, it should properly leave the context by calling CM:LeaveCommonContext and release all references. This will allow the ContextManager to properly and completely shutdown.”

7. Comments Deserving Comment The following comments are from SMS: #24 -- “The dialog for a user to abolish a context, with appropriate dialogs, needs to be added.” #26 -- “The ability for a user to establish, change, or abolish a context must be a securable gesture. What dialogs should be displayed (assumed?) in cases where user’s authority does not allow context joining, changing, or abolishing?”

8. Comments Deserving Comment The following comments are from SMS: #27 -- “It may be desirable to allow the specification default responses for context change faults. Some might be policy-level; some might be user-set options.”

9. Comments Requiring Comment The following Negative-Major comments are from SMS: #5 -- “(Discussion about the Crypto32 API is) Architecturally misplaced. Should be balloted separately by the Security SIG.” #9 -- “Some current HIS applications provide “push down” of context, i.e., saving a context to do higher-priority work, then restoring the original context once that work is done. This must be accommodated.”

10. Comments Requiring Comment The following Negative-Major comments are from SMS: #16 -- “(Specification of security) is misplaced architecturally. It should be separated from patient context and balloted by the Security SIG.” #23 -- “The User Context Subject is architecturally misplaced. It should be separated from patient context and balloted by the Security SIG. Separate the user context from the relegating security engine for VI.”

11. Comments Requiring Comment The following Negative-Major comments are from SMS: #25 -- “The dialog for a user to “push-down”, i.e., suspend /retain/restore, a context for higher-priority work needs to be added.”

12. PN Data Type Recommendation: Change PN to XPN (per HL7 V2.3.1). Rationale: XPN is compatible with PN. Transparent to PN-based applications, yet enables localized patient names.

13. Web-Centric/Thin-Client Recommendation: Pursue as major SIGVI work item in 1999. Rationale: The use of clinical context management for web-centric/thin-client solutions has long been an interest of the “CCOW” community.

14. SecureBinding Recommendation: Add return value to FinalizeBinding itemizing an application’s security privileges. Rationale: It is stated in the specification that applications may have no security privileges, or may get, or may set & get secure context data. The proposed return value reflects these words w/o changing the use or function of the SecureBinding interface.

15. HIS Proxy Applications Recommendation: Ask SMS for clarification. Rationale: Reconciliation Committee, and SMS representative, did not understand the comment.

16. Access to Proposed Context Recommendation: Keep as is. Rationale: Enables an application to use the proposed context as part of its survey decision.

17. ContextData vs. SecureContextData Recommendation: Clarify the distinction: Non-secure data via ContextData; Non-Secure and/or Secure data via SecureContextData. Rationale: Deserves to be stated more clearly.

18. Call LeaveCommonContext Recommendation: Explicitly state that this should not be done. Application should only dispose its references to the context manager. Rationale: Context manager may not be around to handle the call.

19. Abolish Context Dialog Recommendation: Do not specify. Rationale: Maintain the philosophy of minimizing user interface look-and-feel requirements.

20. Additional User Dialogs Recommendation: Do not specify. However, in a future UI implementation guide to enumerate UI issues, including the types of dialogs, menu structures, etc. applications should consider implementing. Rationale: Maintain the philosophy of minimizing user interface appearance requirements.

21. Context Change Fault Default Responses Recommendation: Good idea. Consider as a work item for next version of the specification. Rationale: Now is the time to begin identifying additional capabilities for the next version of the Context Management Architecture.

22. Secure SIG Recommendation: Out of scope. Rationale: Motive for raising this issue is unclear. This is an HL7 organizational issue.

23. “Push Down” Context Recommendation: Interesting idea, but out of scope. Recommend as a work item for a work item for next version of the specification. Rationale: Similar capabilities have been deferred in the past on the basis that they were more sophisticated than what is needed for a “Version One” specification.

24. Bitmaps Recommendation: Add 16x16, 32x32, and 48x48 pixel images for each icon. Post the icons on the HL7 web site. Rationale: “Standard” icon sizes should be presented.

25. Suspend/Resume Recommendation: Clarify that Suspend/Resume can be use as a way to implement break-link. Rationale: Specification already allows this, but could be stated more clearly.

26. HL7 Characters Recommendation: Add table and/or reference HL7 encoding characters and escape sequences that are used, stipulate must be these characters/sequences. Rationale: A reasonable clarification.

27. Suffix Format Recommendation: Alphanumeric, underscore only. No white space. Rationale: A reasonable clarification.

29. Candidate New Work Items 1. Additional context subjects. 2. Stacked contexts. 3. Context-sensitive application launching. 4. Common look-and-feel. 5. 1.0 for other component technologies. 6. 1.0 for other UI technologies. 7. Web-centric/thin-client context management. 8.Additional data items for existing subjects.

30. Candidate New Work Items • 9. Secure “gets”. • 10. “Micro” subjects and non-negotiated changes. • 11. Other visual integration capabilities (esp. by taking advantage of Web): • “Context management” for finer-grain components. • Windowing + clinical context. • 12. Non-standard context subjects (“zz” subjects) plus process for standardizing. • 13. Conformance testing/process.

31. Candidate New Work Items 14. Comprehensive bookmark. 15. Demonstrations of desktop context management utilities. 16. CCOW for “legacy” systems (perhaps using HL7 messaging? Using wrappers/proxies?) 17. Incorporation of common vocabulary into clinical context. 18. Use of 1.0 in DCOM & Windows Terminals Server settings. 19. CCOW for telemedicine.

32. Candidate New Work Items 20. HIPPA (characterize and extend?).

33. Context Management for the Web • Context preserved as traverse URLs. • Context preserved as page forward/backward. • User can be anywhere. • Web servers can be anyone’s. • No code pre-loaded on client other than browser. • Respects accepted applet security policies. • Is independent of browser host platform. • Communication via HTTP.

34. Web-Centric Context Management Thick Client Thin Client Windows, etc, Desktop Browser Vs. Context Manager Context Manager Clients are context participants Servers are context participants

35. A Web Use Case Page A Page B ServerA ServerB ContextMgr User Select Pt XYZ Open URL (pt = XYZ) StartContextChanges SetItemValues(Pt, “XYZ) EndContextChanges ContextChangesPending, etc. Web page with apply/cancel/break-link dialog if necessary Open URL (pt = current) Web page with Pt XYZ’s data

36. Observations • Leverages existing Context Management Architecture. • Enables extreme flexibility in applet/server architecture. • Minimizes (eliminates?) need for true server push communication. • Need for encryption between servers and context manager? • State management challenges between applets and their servers?

37. New Subjects/Items? Encounter Point in Time Episode/Problem Desktop Facility/Location of Care Activity/Task/Workflow State Order Claim Data Mining Subjects (My Patient List) (Patient’s Providers/CareGivers)