WPA 11-03-0628!00!000i Proposed Changes to Annex to Resolve Ballot Comments
Health Level Seven/ SIGVI Agenda Monday, April 26 - Main Topic: Ballot Reconciliation 8:30 - 9:00...
-
Upload
elmer-hill -
Category
Documents
-
view
212 -
download
0
Transcript of Health Level Seven/ SIGVI Agenda Monday, April 26 - Main Topic: Ballot Reconciliation 8:30 - 9:00...
Health Level Seven/ SIGVI
AgendaMonday, 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
Health Level Seven/ SIGVI
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
Health Level Seven/ SIGVI
Reconciliation Process• Reconciliation Committee formed in March by Wes and Rob:
John Hall, HBOCKyle Marchant, 3MMark 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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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?”
Health Level Seven/ SIGVI
Comments Deserving CommentThe 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.”
Health Level Seven/ SIGVI
Comments Deserving CommentThe 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?”
Health Level Seven/ SIGVI
Comments Deserving CommentThe 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.”
Health Level Seven/ SIGVI
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.”
Health Level Seven/ SIGVI
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.”
Health Level Seven/ SIGVI
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.”
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
HIS Proxy Applications
Recommendation:
Ask SMS for clarification.
Rationale:
Reconciliation Committee, and SMS representative, did not understand the comment.
Health Level Seven/ SIGVI
Access to Proposed Context
Recommendation:
Keep as is.
Rationale:
Enables an application to use the proposed context as part of its survey decision.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
Abolish Context Dialog
Recommendation:
Do not specify.
Rationale:
Maintain the philosophy of minimizing user interface look-and-feel requirements.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
Secure SIG
Recommendation:
Out of scope.
Rationale:
Motive for raising this issue is unclear. This is an HL7 organizational issue.
Health Level Seven/ SIGVI
“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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
Suffix Format
Recommendation:
Alphanumeric, underscore only. No white space.
Rationale:
A reasonable clarification.
Health Level Seven/ SIGVI
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
Candidate New Work Items14. 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.
Health Level Seven/ SIGVI
Candidate New Work Items 20. HIPPA (characterize and extend?).
Health Level Seven/ SIGVI
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.
Health Level Seven/ SIGVI
Web-Centric Context Management
Windows, etc, DesktopBrowser
Context Manager
Vs.
Clients are context participants Servers are context participants
Thick Client Thin Client
Context Manager
Health Level Seven/ SIGVI
A Web Use Case
Page A Page B Server A Server B Context MgrUser
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
Health Level Seven/ SIGVI
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?
Health Level Seven/ SIGVI
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)