XDS-I Using XDS.b Technology
1. Proposed Workitem: Maintain Consistency of XDS-I with the latest XDS Specification (XDS.b)
- Proposal Editor: Paul Seifert
- Editor: TBD
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
2. The Problem
The current XDS-I profile is based upon technical solution (and technologies) specified in what is now called ITI's XDS.a Integration Profile. Subsequent to the final text publication of XDS-I, the ITI domain has published the specification of XDS.b which updates the technology(ies) used in the XDS profile while maintaining semantic equivalence. For a list of the differences, see ITI's XDS.b Supplement at: XDS.b Supplement
While it is technically possible to have hybrid environments (with a mix of XDS.a and XDS.b based systems), it complicates the deployment and integration activity by requiring "broker" type systems to bridge the gap between the XDS.a and XDS.b technologies. Since IHE's goal is to simplify integration of healthcare systems, it seems counter to that goal to NOT create an updated version of XDS-I that is based on the XDS.b specification.
3. Key Use Case
The original XDS-I use cases remain the same. The purpose of this change in technologies is to maintain close alignment between XDS-I and XDS (XDS.b in this case) allowing for simpler deployments. Furthermore, clear direction and acceptance of an XDS.b-based version of XDS-I will help vendors to focus their efforts on a single technology, since XDS.b is being "pushed" more heavily by the ITI domain.
4. Standards & Systems
The actor most affected by this change is the Imaging Document Source (XDS-I), and the standards involved in this profile are the same as those identified for XDS.b:
- ebRIM - OASIS/ebXML Registry Information Model v3.0
- ebRS - OASIS/ebXML Registry Services Specifications v3.0
- SOAP12 - SOAP 1.2 Recommendation 
- SOAP11 - SOAP 1.1 Note 
- WSDL11 - WSDL 1.1 Note 
- MTOM - SOAP Message Transmission Optimization Mechanism 
The question: "If/ when (and how) to update XDS-I to leverage 'XDS.b technology'?" was raised in the past (shortly after the TI publication of XDS.b by ITI), and at the time the Radiology Committee's position was: "let's wait and see how stable the XDS.b specification is before doing anything."
- The following feedback was solicited and recently received from Lynn Felhofer (IHE Project Manager - MIR) on the question of XDS.b stability:
- "We had widespread adoption of XDS.b at Chicago (17 Consumers, 5 Registries, 7 Repositories, 14 Sources); also for Oxford (13 Consumers, 14 Registries, 17 Repositories, 12 Sources)."
- "In Chicago, the vast majority of systems tested successfully. The biggest struggle we had in the fall was that the NIST tools were being developed in parallel with vendors doing their implementation. This is because ITI finishes their specs in Aug, leaving no time for advanced tool development. So, all of the implementers learned together, and Bill released updates to the toolkit as vendors found problems. If you subscribe to the XDS implementers google group, you witnessed this churn. That has largely subsided now, and I think the tools are pretty stable."
- "The other caveat is that we really just tested the 'simple case' for XDS.b this year (doc submit/retrieve). Features like Folder Management, and Document Lifecycle (append, replace) aren't tested in the tools and were made optional connectathon tests for this year. Next year they will be required."
- "Overall, XDS.b testing went better than I anticipated it would when the profile was finished back in August. My personal opinion would be the profile is solid enough to consider it as a base for XDS-I. This fall's experience did result in several CPs against XDS.b; the TF documentation will remain a bit of a challenge for implementers to assimilate until those CPs are incorporated into the profile. Steve and I tried to address the documentation problem a bit by compiling a page that points to all of the pieces of documentation needed for XDS.b (and other profiles):"