Difference between revisions of "ITI Tech 2006 2007 Meetings"
Line 5: | Line 5: | ||
# Review New Proposals from Planning Committee | # Review New Proposals from Planning Committee | ||
#* Cross Community location service (Karen W.) (Profile) | #* Cross Community location service (Karen W.) (Profile) | ||
− | #* XUA | + | #* [[Cross-Enterprise User Authentication (XUA)]](John M.) (Profile) |
#* MTOM (Vassil/Roberto) (Profile) | #* MTOM (Vassil/Roberto) (Profile) | ||
#* Non-Patient Document Sharing (???) (Profile) | #* Non-Patient Document Sharing (???) (Profile) |
Revision as of 10:49, 26 January 2007
Meeting December 5-6, 2006
Agenda December 5-6
- Review New Proposals from Planning Committee
- Cross Community location service (Karen W.) (Profile)
- Cross-Enterprise User Authentication (XUA)(John M.) (Profile)
- MTOM (Vassil/Roberto) (Profile)
- Non-Patient Document Sharing (???) (Profile)
- Web Services specialized bindings (Vassil) (Appendix(s))
- PIX/PDQ V3
- EMR Query
- Configuration Management (Rob) (White Paper)
- Aggregate Data (Charles, Floyd) (White Paper/Profile???)
- Carry-over from last season
- RFD (George) - PCC work dependent on new ITI Profile Proposal 'Investigator Identity and Authentication' which did not get forwarded to tech from planning
- PIX/PDQ V3 (???)
- Web service bindings (see above)
- Other????
- Cardiology/Patient Care Devices Presentation
- Tue 1-2
- IHE Cardiology and IHE PCD Profiles presentation - requesting ITI vendor implementations
- Feedback on the IDCO Profile (use HLv2 or XML payload?)
- Discuss use of new IHE wiki
- Discuss CPs
Schedule December 5-6
Day | Time | Topic |
---|---|---|
Tues | 930 | Organize/Breakfast/wiki discussion |
1000 | XUA (John M) | |
1100 | Non-Patient Doc Sharing (??) | |
1200 | Lunch | |
100 | Cardiology/Patient Care Devices (?) | |
200 | Aggregate Data (Charles) | |
300 | XC Location Service (Karen) | |
400 | Web Services Bindings (Vassil) | |
430 | CP Discussion | |
530 | Adjourn | |
Wed | 830 | Breakfast |
900 | RFD (George) | |
930 | PIX/PDQ V3 (????) | |
1000 | MTOM (Vassil/Roberto) | |
1100 | Config Mgmt White Paper (Rob) | |
1200 | Lunch | |
100 | Overflow | |
200 | Review Plans/Assignments | |
230 | Adjourn |
Minutes December 5-6
Attendance
Randy Fusco Microsoft
David Heaney McKesson
Rob Horn Agfa
Don Jorgensen Inpriva
Bill Majurski NIST
Glen Marshall Siemens
John Moehrke GE Healthcare
Vassil Paeytchev Epic
LaVerne Palmer HIMSS Staff
Charles Parisot GE Healthcare
Lori Reed-Fourquet eHealthSign
Roberto Ruggeri Microsoft
Harry Soloman GE
Nicholas Steblay Boston Scientific
Karen Witting IBM
General Discussion
Discussion of developing an active member list Proposal was made regarding process for creating and maintaining an active member list. Includes tracking attendance at every face-to-face and teleconference. Members would be considered active if within the prior 12 months they a) attended a face-to-face b) authored a change proposal c) authored a profile. A first draft of the list will be published on the wiki for review.
Encryption ciphers (ATNA) for Connectathon - 3des is required for all servers at Connectathon. Rob will open a CP to initiate discussion of a final solution to this yearly problem.
Discussion of Profiles sent from Planning
XUA - Look at XDS Query first year, XDS Retrieve second year. Does query need to be field-able after 1 year? For ATNA purposes, document patient ID can be retrieved by looking up URI in registry. With ATNA there may be an issue with automated pre-fetch. Handle ED differently - different cert per service with different policies. Would MTOM force f-bit encoding (data expansion)?
May want to look at 3 different environments: high, medium, low policy scopes. Should include Roles and Affinity Domain type information. Do not include authentication. What are the interoperability issues? Assertions?
IBM implementation for NHIN - Since Repository doesn't know patient ID, Registry issues timed token for retrieval (illegal in XDS). Thus the Registry acts like an intermediary for repositories. Registry controls access. -- This is not a recommended solution for IHE as the URIs returned by the registry can not be used in documents or in the future. The IHE design is such that the URIs returned can be embedded in documents or used as references in the future (likely by other people).
Discussion on the priority of our transactions to use XUA to help scope the amount of work to do this year (both profile development and product engineering). This discussion focused around using the AHIC Emergency usecase, and recognizing that data use is more important than data export. Thus the query and retrieve are the focus. The query is already a web-service, and thus should be the top priority. But it is recognized that the Retrieve is the more interesting one for two reasons. First it is the one that exposes the high-fidelity data (document vs metadata), second it is the one where the original-enterprise would still be in control as they could be using a local repository. Thus they want to know to whom they are sending the document.
The query is more likely to be automated (pre-fetch) based on an ADT, Order, or Schedule and thus less likely to be able to provide a human user identity. The Retrieve however is more likley to be a human selecting from previously pre-fetched query.
If we update the XDS-Retrieve transaction to a Web-Service, then the XUA work should include both the query and the retrieve.
For development notes and plan see Cross-Enterprise User Authentication (XUA)
Non-Patient Documents - Need to define OID - URN format. For style sheets and schemas, URL is good enough. TLS needed for spoofing. Overall needs are:
- URN to URL mapping
- Retrieval of Policy Documents
Should be defined as a web services in case it is needed that way in the future. General agreement that all services defined by ITI in the future should be based on Web Services unless there is a reason not to. Where should WSDL be published? Is the wiki/web site stable enough. General assumption is that it will be there a very long time.
Decided to use RID to support this proposal. Volume 1 will need new use cases. Volume 2 will need discussion on schema location issues. Don agreed to author.
Presentation by ACC members (Harry Soloman and ...) - There prime focus is on inter-departmental profiles. General concern about uptake. Looking for assistance from other domains.
Displayable Reports - contains a PDF document carried with a HL7 v2 MDM message. Does this work belong in ITI instead of CARD? This is an intra-enterprise/cross-departmental report. It has not been shown at HIMSS. Published as TI last year and withdrawn this year. There is a possibility that it is based on the wrong HL7 message. Should this be architected as a transfer of a report or as a pointer to a report? It should feed XDS for Cross Enterprise work. Transaction [CARD-8] - Report Notification should be transfered to ITI. This is PDF specific now and could be content neutral. Looking for guidance on how to proceed with this profile.
It was proposed that ITI should maintain a list, similar to Content Profiles, of profiles from other domains that define document formats that could feed XDS.
It was generally agreed that more liaison effort is needed with PCD.
Implantable Cardiac Devices (IDCO Profile) - This profile is labeled as IT and has gotten very little EMR/EHR or device attention from industry. Devices in this category include pace makers, defibrillators, and cardiac resynchronization. The issue is getting results into the patient record.
Is this defining a common capability with Lab? Note that Lab is also transitioning from HL7 V2 to V3
Cross-Community (XC) Access - The Federation White Paper from last season is being moved forward as a pair of profile proposals this season: Cross-Community Access and Cross-Community Location.
Issues/concerns:
- will too much data be transfered? Do we need a filtering capability? summaries? How will requests from ED be handled?
- Latency, impact on audit, transport, asynchrony
- Trust mitigation - inter Affinity Domain trust
- Should cause minimum impact to Doc Consumers. Query and XC (Cross-Community) query should be very similar.
- Look into Grid Services
- Responses should be screened for privacy concerns - distributed authentication issues. Should provide minimal information until I know why I should provide more.
- Managing controlled vocabularies across Affinity Domains
- Patient ID management - use merge or link? How should demographics be managed?
It was generally agreed that the XC Access profile should be written before the XC Location profile.
Cross-Community (XC) Location - May need to keep this profile as a white paper another year until XC-Access is written and understood. There is good technical work in this area that is not standards-based. One approach is to merge location information into PIX. How often would information be updated? What are the important security/privacy issues?
Aggregate - There are several possible technical approaches available: subscription/notification in ebXML Registry v3, capture the Register Document transaction, MEP - message exchange patterns in HL7. Are the XPath and/or XQuery standards useful? If accepted, this would be a multi-year effort. One global organizing prinicple that could be applied is to specify the rules to be implemented globally but implement them locally. This would put off the need for a query/rule language. A possible schedule would be: year 1 - define overall structure; year 2 - deal with rule specification issues.
Problem is bigger than �XDS. XDS only sees documents that are published in cross enterprise environment. Another attach point is needed especiallly considering that labs might not be archived. Part of this overall effort may belong in PCC or Lab.
No editor has been identified.
Web Services - Need WSDL for PIX/PDQ V3 (this was written last season but not reviewed or published). The general appendix applies to PIX/PDQ V3. PCC will be producing WSDL for EMR Query.
Is the IHE web site the right place to publish WSDL? Is it/will it be stable enough? Since we do not write schemas, we should point to SDO web sites for the schemas when possible.
How important is WSDL style? Should all WSDL be produced by a single committee to guarantee a similar style? No general agreement.
MTOM - We agreed that the introduction of MTOM should be handled as a new collection of optional transactions. The new transactions would specify a new MTOM binding but carry the existing content. The following specifics are proposed:
- Upgrade from SOAP 1.1 to SOAP 1.2
- Use MTOM instead of SOAP with Attachments on Provide and Register transaction
- Introduce ebRIM 3.0 encoding on all transactions (currently used in Stored Query only): Provide and Register, Register and Query.
- Define a Web Services based Retrieve transaction that would use SOAP 1.2 and MTOM. This has a slightly larger scope than the other parts since a document would not be referred to by URI but instead by uniqueId. Document Repository actor, as defined today, does not manage this attribute.
- PIX/PDQ V3 already is already bound to Web Services
- Should the Audit Trail portion of ATNA have a Web Services binding?
It is a big plus that WS-I already performs the profiling of Web Services and conducts their own interoperability testing events.
Web-Service version of XDS Retrieve This project fell out of the MTOM proposal. Simply stated this is a new transaction that functionally is the same as the current XDS Retrieve but uses web-services (SOAP) rather than simple HTTP GET. This new flavor would be very useful for XUA, and would likely be the only form of XDS Retrieve for which XUA would be applied. The result would be the old HTTP GET that would not provide a user identity, while the new web-services one would provide a user identity.
Doing this now would have less impact on installed base than if we delayed this into the future. BUT there is now installed base (Rob).
This work is linked to MTOM and XUA.
Configuration White Paper Organized into sections: DICOM, Web Services, HL7 V2, Hl7 V3, 1073. Locating editors for each section. Agreed that other domains should review this white paper as part of the development process. Karen to discuss in co-chair committee.
Other Business
Change Proposals - Discussed new Change Proposals that have been submitted in the last few months. Karen has taken over the task of managing change proposals.
PIX/PDQ V3 - No feedback yet from the testing effort to know how much effort this will take in the next year. No other effort has been requested in this area.
National Extensions of XDS for metadata Scheduled April 2 teleconference to review any received submissions. Submissions required by March 20. Charles to contact appropriate parties about submitting documents for review. Expectation is that approved versions would be available July timeframe.
Scheduled t-cons for future discussions Scheduled t-cons for Jan. 29, Feb. 6, Feb. 15 which will be used for discussion of profiles selected for development this year (and possibly CPs). Scheduling of which profile to address on which call will be done by co-chairs once final decision is made by planning committee.
Response to Planning Committee
A letter will be sent to the Planning Committee detailing the Technical Committee's response to the new profile proposals.
Profile Selection Recommendations
Detailed Profile Proposals were discussed at the Dec 5-6 meeting. Based on technical evaluation we recommend the following projects for this season. A more detailed discussion supporting our recommendations is available in the [ITI_Tech_2006_2007_Meetings#Minutes_.28DRAFT.29_December_5-6 | ITI Tech meeting minutes]
Profiles/White Papers to be developed this season
- Web Services Infrastructure for HL7 V3 - this work, left over from last season, should be completed. This is not new profile work and should be submitted as a Change Proposal. Tech Editor: Vassil Paeytchev. Profile Development Effort: very small.
- XUA (Detail Proposal) - should be promoted from White Paper to Profile. The scope for the effort this season should be to profile SAML bindings for XDS Stored Query and XDS Retrieve transactions. Tech Editor: John Moehrke. Profile Development Effort: medium.
- MTOM (renamed to XDS Web Services) (Detailed Proposal) - should be profiled this year as a binding for the Provide & Register, Register and Retrieve transactions in XDS. This will introduce new versions of these transactions which will be published as Optional transactions. Tech Editor: Roberto Rugggieri. Profile Development Effort: medium.
- Configuration Management White Paper - should be developed within Technical Committee. Tech Editor: Rob Horn. Development Effort: small/medium.
- Cross-Community Access (Detailed Proposal) - This effort will be the first step of a two year profile. The Cross Community Access profile contains the first step and will be completed this year. The Cross Community Location profile (see below) will be the next step of the process and is deferred to next year. Because of this phased approach there may be limited connectathon testing since complete functionality will not be available this year. For a complete description of the direction see the 2006 White Paper on Cross Community at: (White Paper) Tech Editor: Karen Witting. Profile Development Effort: large.
Profiles/White Papers not chosen by the technical committee
- Cross-Community Location Service - should be held back and started in one year so the initial efforts on Cross-Community Access are available.
- Policy and Configuration Document Sharing (XDS for non-patient-centric data) - the committee agreed that a small update to the RID profile will accomplish the major elements required in this profile. Although this is a small effort it was judged least important when ranked against other work. Given the extensive other work the committee believes this should be defered to a future year.
- Aggregate Data - this topic is not ready for profiling in Technical Committee. We recommend the following options:
- Planning Committee take on the task of refining the Use Cases and re-submit to Technical Committee next season
- If the New Directions style of profile development is approved by the Co-Chairs Committee, we would consider taking on this profile as a New Directions effort. This would mean that Technical Committee would commit meeting time to discuss Use Cases and technology to meet them. At the end of year 1 (of a two year effort) we would anticipate a demonstration at HIMSS but no Connectathon testing. Detailed management of this effort would come from a separate project manager (not the Committee Co-Chairs) and involve a separate TCON/development tract much in the style of RFD and PIX/PDQ V3 last season. The project manager would take on the effort of identifying interested parties to participate in the development effort, manage the TCONs (with ITI Co-Chair support), and promote the development of demonstration implementations for HIMSS. Project Manager: none
Change Proposal TCON November 15, 2006
Minutes November 15
Attendees
- Rob Horn - AGFA
- Karen Witting - IBM
- Bill Majurski – NIST
- Glen Deen – IBM
- Yongjian Bao – GE
- Josh – Misys
- Mark Sinke – ForeCare
- Vassil Peytchev - Epic
- John Moehrke – GE
- Laurie Williams – IBM
- George Cole - Allscripts
pixpdq_170_09
item #4 became new CP 204
- 5 no change - added example
- 6 fixed
ask for response from Isabelle
xds_164_05- atna and xds - rob, mark
Emmanuel offered the following:
1) We effectively decided not to create an "import" event on a consumer side for a retrieve document, because the nature of the protocol (HTTP Get) making probable that the retrieve itself is directly performed by the Web browser. When we evolve this protocol (WS...) it must be reconsidered. 2) The name of the Studies / DICOM Studies is not consistent for Import/Export events. We have definitly to tell to people what is the corresponding "study" for the XDS/XDR/XDM profiles. I would recommend that it is the XDSSubmissionSet (referenced by its uniqueId) for XDS Register, XDS/XDR Provide&Register and XDM Distribute, and the XDSDocumentEntry for the XDS Retrieve. 3) Similarly, we have to precise the ParticipantObjectID in the Query event to be set to the UUID of the type of XDS object queried (document, submission set or folder) 4) There are some typos in the CP. For example you did not end the Query section, or errors in parentheses.
Long discussion – Mark and Rob to merge their independent writings.
xds_136_02 - John M - No need to discuss
xds_144 - long URI - need status on ballot #3 from LaVerne - not present on call
Action items
CP 164 includes codes that need to be registered. Who does this?
Mark and Rob submitted updated at the same time. They are working to reconcile. Schedule next review.
Many questions have floated about this season regarding audit. Suggest creating an Implementers Guide on generating audit messages.
Ask for review and comments from Isabelle on CP 170
Long URI CP in Ballot #3 - Get in touch with LaVerne
Next call noon (central) on Dec 19