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


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


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.


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.


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?”


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.”



#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?”



#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.”


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.”




#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.”




#25 -- “The dialog for a user to “push-down”, i.e., suspend /retain/restore, a context for higher-priority work needs to be added.”


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.


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.


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.


HIS Proxy Applications

Recommendation:

Ask SMS for clarification.

Rationale:

Reconciliation Committee, and SMS representative, did not understand the comment.


Access to Proposed Context

Recommendation:

Keep as is.

Rationale:

Enables an application to use the proposed context as part of its survey decision.


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.


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.


Abolish Context Dialog

Recommendation:

Do not specify.

Rationale:

Maintain the philosophy of minimizing user interface look-and-feel requirements.


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.


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.


Secure SIG

Recommendation:

Out of scope.

Rationale:

Motive for raising this issue is unclear. This is an HL7 organizational issue.


“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.


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.


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.


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.


Suffix Format

Recommendation:

Alphanumeric, underscore only. No white space.

Rationale:

A reasonable clarification.


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.


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.


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.


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


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.


Web-Centric Context Management

Windows, etc, DesktopBrowser

Context Manager

Vs.

Clients are context participants Servers are context participants

Thick Client Thin Client

Context Manager


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


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?


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)

health level seven/ sigvi agenda monday, april 26 - main topic: ballot reconciliation 8:30 - 9:00...

Documents