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 and locating documents. Further, the Imaging Document Source is required to support the Provide & Register Imaging Document Set transaction.

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.

<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

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

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 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 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 Document Set [RAD-54] transaction. Each section would simply refer to the appropriate base XDS.a/ XDS.b Provide and Register transaction 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 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.

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

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