XDS-I Using XDS.b Technology - Detailed Proposal

1. Proposed Workitem: Maintain Consistency of XDS-I with the latest XDS Specification (XDS.b) - Detailed Proposal

• Proposal Editor: Paul Seifert
• Editor: TBD
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

Summary

XDS-I depends on XDS for registering, locating and storing documents (or document manifests). Further, the XDS-I Imaging Document Source is currently required to support the Provide & Register Imaging Document Set [RAD-54] that is based on the Provide & Register Document Set [ITI-15] from the XDS Profile in the ITI Technical Framework.

IHE ITI has renamed XDS to XDS.a and introduced XDS.b which replicates the functionality with different protocols. Some vendors would like to combine XDS-I with XDS.b. The current RAD framework does not tell them how.

2. The Problem

The current XDS-I profile is based on what is now called ITI's XDS.a Integration Profile. Subsequent to the final text publication of XDS-I, the ITI domain published XDS.b which uses newer technology(ies) to do the same thing and maintain semantic equivalence with the XDS profile. For a list of the differences, see ITI's XDS.b Supplement at: XDS.b Supplement. It is generally agreed that the "technical specification work" needed to allow XDS-I to take advantage of the XDS.b transport mechanisms is minimal.

The bigger challenge is making sure that the specification changes are done in such a way as to ensure clear communication to both vendors and users and preferably maintain compatibility with any existing XDS-I implementations and deployments that may exist. For example that following "problems" should be considered/ addressed:

Problem #1: If a vendor implements an Imaging Document Source using the XDS.b Provide & Register transaction without supporting the XDS.a Provide & Register transaction, they cannot currently claim compliance with the XDS-I profile. If they implement both XDS.a and XDS.b versions of the transaction, they have done extra work.

Problem #2: If XDS.b Document Repositories were required to accept XDS.a Provide & Register transactions, existing XDS-I implementations would integrate transparently into XDS.a or XDS.b environments, however this was not required. So users may buy and try to deploy systems for XDS-I and find that they do not interoperate.

Problem #3: Some vendors have implemented a hybrid of XDS-I and XDS.b Provide & Register. The current Technical Framework does not describe how this should be done.

IHE faces conflicting goals:

• Make it simple for users to acquire systems that interoperate compatibly.
• Choose a single IHE way to solve each integration problem.
• Avoid making vendors implement more capabilities than necessary for interoperability.

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). This will pave the way for retirement of XDS.a and consolidation on XDS.b, 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.

According to Charles Parisot: "(XDS-I using XDS.b mechanisms) has been assumed and endorsed by HITSP in the US (requires XDS.b in all of its new Interoperability Specifications that leverages with XDS-I) not even waiting for the IHE XDS-I modification work."

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 [1]
• SOAP11 - SOAP 1.1 Note [2]
• WSDL11 - WSDL 1.1 Note [3]
• MTOM - SOAP Message Transmission Optimization Mechanism [4]

5. Technical Approach

There has been much discussion and debate about whether or not this work should be processed as a Change Proposal (CP) or a Profile Supplement within the Radiology Committees. Though a CP on the subject has been submitted, it does not provide any suggestions for text modifications to the existing Technical Framework, and thus is difficult to judge whether the amount and nature of the changes envisioned are "CP in nature" or would be better suited as a Supplement.

Hopefully the technical approach described here will provide sufficient information and detail needed to make that determination.

Existing actors

The Imaging Document Source is the only XDS-I actor that should be affected by this change. (Note: the Document Repository, Document Registry and Document Consumer Actors are not strictly part of XDS-I but are inherited from the XDS Profile (which XDS-I is dependent on) and are only included in the Actor Transaction diagram to provide context.

Impact on existing integration profiles

Two new options can be created for the Imaging Document Source in the current XDS-I Profile:

1. XDS.a Provide and Register Option (Obviously needs a better name)
2. XDS.b Provide and Register Option (Obviously needs a better name)

Support for at least one of the two options would be required.

New integration profiles needed

None expected

New actors

None expected

Existing transactions

It should be possible to modify the existing Provide and Register Imaging Document Set [RAD-54] allow it to be based on either ITI's Provide and Register Document Set [ITI-15] (XDS.a based) or Provide and Register Document Set-b [ITI-41] (XDS.b based).

Two new sections (one to describe each option mentioned above) can be added to the existing Provide and Register Imaging Document Set [RAD-54] transaction. Each section would simply refer to the appropriate base XDS.a/ XDS.b Provide and Register transaction depending upon which transport mechanism is used in each case (e.g., SOAP with attachments for the XDS.a base, and MTOM/XOP for the XDS.b based flavor).

New transactions (standards used)

Alternatively, a new radiology Provide and Register Imaging Document Set-b [RAD-xx] transaction could be created that is nearly identical to the current radiology Provide and Register Document Set [RAD-54] that refers to ITI's Provide and Register Document Set-b [ITI-41] (XDS.b based) transaction (rather than [ITI-15]). This new transaction would be associated with the XDS.b Provide and Register Option named option mentioned above.

The standards used, either in this new transaction or modification ofthe existing transaction, are listed in section 4 above: Standards and Systems

Breakdown of tasks that need to be accomplished

1. Pick a 'format' for the changes (CP or supplement)
2. Write up the changes described above
3. Since the suggested changes alter how support for the profile is claimed, it is recommended that the changes (in whatever form they're documented in) are published for public comment and made available to other IHE domains for comment before being finalized. (This allows for broader scrutiny than is typically given to a CP).

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

The following question/ risk was initially identified, but the current/ residual level of "risk" has been deemed manageable by the Radiology Planning Committee.

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):"

• http://ihewiki.wustl.edu/wiki/index.php/Summary_Of_IHE_Technical_Requirements

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

Q. Is the scope of the work item limited to pairing XDS-I with XDS.b, or will it also address XCA, XDR, XDM, etc.

Q. The Use Case section makes the case for focusing efforts on a single technology and the resulting simplification. Can we commit to removing XDS.a from XDS-I and adding XDS.b to achieve this?

Q. What impact would this have on existing XDS.a based XDS-I implementations?

• Action Item: Chris L. will collect and report on feedback from those who have published XDS-I Integration Statements

Q. What impact would this have on existing XDS.a based XDS-I deployments?

• Action Item: Planning Committee to engage user adopters and gather their experience

Q. Will updating XDS-I to XDS.b lead to dramatic improvement in adoption (both from vendors implementing and from customers requesting systems)?

Q. At some point there will likely be a need/ desire to address Web services-based transfer protocol for images in coordination with DICOM WG10 and ITI. Is there enough benefit in upgrading XDS-I to use current XDS.b transport mechanisms without replacing the DICOM object retrievals with their to-be-developed web services counterparts?

Q. During Planning Committee discussion, the question was raised whether PHR use cases should be considered. Do we add this use case? If so, we'll need to engage clinicians to help use describe it.

Q. What effect (if any) will the roadmap of image sharing (eg, XDS-I, XCA, PDI) under development by the Planning Committee have on the development/modification of the XDS-I profile?

Q. Since the suggested changes alter (slightly) how support for the profile is claimed, it is recommended that the changes (in whatever form they're documented in) are published for public comment and made available to other IHE domains for comment before being finalized. (This allows for broader scrutiny than is typically given to a CP).

Other Miscellaneous Comments made during Planning Committee discussion on September 17, 2008

• Within a given PACS environment, Web access is a feature already typically available
• Canadian model is to establish centralized architecture for DI: regional PACS
• Need to assess current priority of addressing networked model vs. upgrading PDI solutions for removable media (driven by AMA, ACR concerns)
• Need to engage referring physicians in working on practical solutions for image exchange

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA