XDS-I Using XDS.b Technology - Detailed Proposal

From IHE Wiki
Revision as of 13:13, 20 October 2008 by Pseifert (talk | contribs) (→‎9. Tech Cmte Evaluation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

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


XDS-I depends on XDS, primarily for registering and locating 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 right down to the semantic details.

The challenge is making sure the specification changes ensure clear communication to both vendors and users and preferably maintain compatibility with existing XDS-I implementations and deployments.

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 did not tell them how to do that.

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

XDS-I provided it's own document retrieval mechanisms for studies, and the XDS actors were referenced but not formally included in the profile, so the "technical specification work" needed to allow XDS-I to take advantage of the XDS.b transport mechanisms is mostly limited to the contents of the Provide & Register Imaging Document Set transaction.

For a list of the differences between XDS.a and XDS.b, see ITI's XDS.b Supplement at: XDS.b Supplement.

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.

This will allow existing product implementations to still "comply" with the XDS-I profile while requiring only a minor change to, and republication of their Integration Statement.

New product implementations would be strongly encouraged to select/support the XDS.b option.

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

Alternative Approaches

  • 1) a/b Options - As described above
  • 2) New XDS-I.b Profile - Leave current XDS-I profile. Add XDS-I.b profile that uses XDS.b
  • 3) Rewrite old XDS-I - Remove/Retire XDS.a-based material in XDS-I, replace with XDS.b
  • 4) Downscope XDS-I - Remove Register transaction, Find new home for Submission Set text, declare XDS-I only addresses retrieval, does not address registration/query, must be grouped with XD* for that.

Breakdown of tasks that need to be accomplished

  1. Solicit input/ feedback from CHI on XDS-I.a vs. XDS-I.b
  2. Discuss and decide on the exact approach to take. One possible approach is outlined, but has its drawbacks. Other alternatives are possible each with its own drawbacks.
  3. Determine Timeline
  4. Pick a 'format' for the changes (CP or supplement)
  5. Write up the selected approach (e.g., changes) as decided upon
  6. Since the suggested changes will likely alter how support for the profile is claimed, it is expected 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

Dr. David Mendelson, (Chief of Clinical Informatics, The Mount Sinai Medical Center; Co-Chair IHE International Board; Chairman IHE subcommittee of the RSNA RIC) provided the following letter of support via email:

Recently there have been several overtures and opportunities with regard to raising the priority of image sharing within the United States. The Radiology Informatics Committee (RIC) of the RSNA has also been actively discussing this subject over the last few months. The RSNA, as the largest organization representing imaging in the US, has been approached by many different venues with regard to image exchange. The RIC committee has been charged to recommend and to help enact solutions. Below we would like to share our conclusions with you.
We wish to pursue the avenues opening to us. We should not let the opportunity to establish mechanisms to share imaging exams pass us by nor be delayed. It is the consensus of the RIC committee that a proper solution in the current timeframe would invoke portions of both XDS-I and XDS-b. We believe that much like XDS-a, XDS-I developed to fill a need in the midst of a very dynamic environment. XDS-b has quickly evolved to supplement the XDS-a profile by incorporating newer and more robust technologies to enable document and information exchange, while preserving much of the XDS-a defined workflow. XDS-b appears to embrace solutions, particularly transport mechanisms, that we believe would apply and improve upon XDS-I.
We would like to engage the IHE Radiology community in prioritizing work that would in essence either establish an XDS-I/b or move image sharing into the XDS-b world. In the long run, making the image just another document type, treated in a similar fashion to other documents, might foster the integration of images into the generic electronic health record (EHR). There may be enough special features requiring the persistence of an XDS-I/b, but any effort that moves us in the direction of converging with XDS-b is desirable.
Thus, to accelerate the acceptance of IHE based image exchange standards on both the US national and international levels we ask this subject be worked on at an accelerated pace by the relevant IHE Radiology committees. The EHR community is asking for our solutions. We wish to provide a realistic modern solution in the very near future. We request your help in this regard and will work with the IHE committees to produce an optimal solution.

Several Canadian Projects related to sharing of images have also expressed interest in seeing this work progress.

Finally, the high volume of email discussion from various Committee members on this topic provides a some indication of the level of willingness/ desire to work this through to resolution.

7. Risks

Depending on how this is done, risks may include:

  • complicating deployment/confusing users
  • unintentionally purchasing incompatible equipment
  • alienating/invalidating existing XDS.a product implementations
  • alienating/isolating existing XDS.a deployments
  • incompatibilities and changing transports creating the impression that IHE is unstable

Risk: This could generate additional XDS-I "thrashing" this year (XDS-I.a vs. XDS-I.b) ...see Q6 in Open Issues section below).

Risk: XDS.b Stable enough to adopt? (raised by Rad Plan shortly after TI publication of XDS.b by ITI)

  • Recently solicited feedback from Lynn Felhofer (IHE Project Manager - MIR)
    "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):"
  • Based on this the Rad Plan Cmte felt the stability risk was likely manageable
  • How stable is do the XD* roadmap? Will we have to do this again.

Risk: References to xds.b add difficulty due to it's current trial implimentation state.

  • May need CPs in Radiology later
  • Should educate implementers early to avoid confusion

8. Open Issues

A big open issue is the "packaging" of this work and which IHE "Process" is used (CP or Supplement) to get the changes incorporated into the Technical Framework.

Though a CP has been submitted, it does not provide suggested text modifications to the Technical Framework, and thus it 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.

The following is taken from RAD TF-1: 1.10:

Generally, new functionality is published in the form of a Supplement. The scope of a Supplement is to make one of the following additions to the Technical Framework:
  • A new Integration Profile, usually including the introduction of new Actors and Transactions.
  • New Actors in an existing Integration Profile: These may be either Actors previously defined elsewhere in the Technical Framework, or new ones not yet defined. Transactions identifying the new actors responsibilities in this profile are identified or defined and may be designated as required or optional. To avoid causing compatibility problems for systems that have already implemented that profile, no new required Transactions are added for existing Actors in the profile.
  • New Options in an existing Integration Profile: These usually add optional Transactions for existing actors in the profiles, or add optional features within existing Transactions.
  • Major conceptual changes: They do not change the behavior of existing Integration Profiles but may imply changes or additions to Actors or Transactions in the future.


Despite the best efforts of the Technical Committee, a published current version of the Technical Framework or Trial Implementation documents may contain text that is incorrect, incomplete or unclear. Such issues are handled as Change Proposals and cover:
  • Corrections: technical issues causing non-interoperability of implementations are fixed without introducing changes in functionality of a stable Integration Profile.
  • Clarifications: text that can be misunderstood or is ambiguous is made easier to understand or disambiguated, without introducing any technical changes.
The publication process is the same for both Corrections and Clarifications, and addresses both changes to Trial Implementations and changes to a current version of the Technical Framework.

The main justifications for having the above statement in the TF is to make changes that affect how IHE support is claimed/ described by users more visible by allowing for public comment on those changes. At that point, the additional functionality moves to Trial Implementation state where it becomes a candidate for organized testing at a connect-a-thon.

Since the changes suggested alter (slightly) how support for the XDS-I 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 would typically be given to a CP -- which generally is processed within the given domain's Technical Committee).

It may also be beneficial to allow for some form of "Trial Implementation Testing".

Other Questions:

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

  • A1: The current proposal indeed limits the scope to pairing XDS-I with the XDS.b transport mechanisms.
  • XCA is another proposal
  • XDM replicates PDI? Do we need to address/avoid overlap/differences
  • XDR focusses on point-to-point of submission sets. Isn't that sort of what we're suggesting for XDS-I in Alternative 4)?

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

  • A2: No. The current proposal allows multiple alternative technologies (XDS.a and XDS.b). When ITI deprecates/retires XDS.a, Radiology can change the profile again to deprecate/retire this XDS.a option.

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

  • A3: Action Item: Chris L. will collect and report on feedback from those who have published XDS-I Integration Statements
  • Some integration statements claim XDS.b (typically claim XDS.a as well)
  • There are no XDS.b repositories in the field that we are aware of
  • Further investigation is needed

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

  • A4: Action Item: Planning Committee to engage user adopters and gather their experience
  • There are XDS-I.a deployments reported in Canada, and a couple in France, Philadelphia
  • Some are finding issues with federating repositories
  • Further investigation is needed

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

  • A5: Good question!

Q6: At some point there will likely be a need/desire to address Web services-based transfer protocols for images in coordination with DICOM WG10 and ITI. What are the benefits of upgrading XDS-I to use current XDS.b transport mechanisms without replacing the DICOM object retrievals with their to-be-developed web services counterparts?

  • A6: Based on the input from Dr. Mendelson and others, the answer appears to be 'yes'.
  • Web Services in DICOM will take a while. We have WADO. If the Reg/Query infrastructure moves to XDS.b, we need to work on that if it's dominant.

Q7: Should PHR use cases be considered? If so, we'll need to engage clinicians to help describe it.

  • A7: No. The current proposal does not include this. PHRs are welcome to use XDS-I and XD* as is.

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

  • A8: TBD

Q9: How do we handle this year's connect-a-thon registration and testing?

  • Breakdown of tasks and lateness of date (everyones signed up) means we can't add this as official testing (no results)
  • Consider adding tests for XDS.b based XDS-I
  • Cmte would need to publish a spec at least in draft. Lynn could draft some separate optional tests that would allow anyone who is registered for XDS-I could do it although pass or fail that test would not affect your results
  • Would need to reach out to implementers to find out who wants to try this
  • Link up XDS-I Sources to XDS.b Repositories to XDS-I Consumers/Displays
  • Group construction/fishing for partners may be awkward
  • We'll work in this direction and see if we can get something defined by December.

Issue: How do we package re: Trial Implementation

  • Probably have to bump XDS-I back to TI status since XDS.b is TI so having XDS-I as FT is asking for trouble.

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

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

  • 20% (considering the levels of controversy)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

P. Seifert (availability assumes a non-accelerated timeline)