xds_development_stages

Stages of XDS Development

There have been three stages of the development of the XDS profile. I call them: XDS.a, early XDS.b, and late XDS.b.

XDS.a

This was the original XDS. It was based on OASIS ebXML Registry standard version 2.1. It used an SQL query and an earlier version of SOAP. This was abandoned for two reasons: most attributes were constrained to 128 characters and SQL query is pretty tough to build an interoperability spec on top of.

XDS.b (early)

This was based on OASIS ebXML Registry standards version 3.0. It offered an upgraded version of SOAP, 256 character attribute length, and a Stored Query (aka ITI-18) facility. Stored Query was much easier to leverage looking towards interoperability.

In profiling both the 2.1 and 3.0 versions of the standard we had some very difficult choices to make. This standard was very complex and hard to read. On top of that many developers at the time were unfamiliar with XML (not to mention XML namespaces). On top of this standard we layered the healthcare requirements. We were looking to cut corners to make things easier for developers.

The Public Registry server implements XDS.b (early). Underneath the server is an XDS.a compliant Registry. An adaption layer was added to allow XDS.b transactions. It supported the transition from XDS.a to XDS.b.

XDS.b (late)

I define the transition between XDS.b (early) and XDS.b (late) as the introduction of Metadata Update. (There was also an Icelandic volcano that stranded me in Europe for two weeks but I digress.)

Metadata Update forced the focus on a few attributes that were not yet used in XDS.b. The big one is VersionInfo.

This has caused many headaches. VersionInfo is poorly described in ebXML Registry 3.0. We had to invent XDS-specific semantics to construct Metadata Update. One thing that ebXML Registry did specify is that the field is optional on write and required on read. In IHE terminology this means optional in the Register request and required in the Stored Query response. The standard defined a default value so we added it to the profile.

How to handle tooling?

The tooling has to reflect what implementers are doing in products since the tooling is used to test the products. So, the solution had to start in ITI-Tech with how the Metadata Update Supplement was written. It says, more or less, that an XDS Registry can continue operating but needs to return the VersionInfo attribute with the default value. Registry developers got through this transition well since few Document Consumers cared to validate this attribute. Until Metadata Update it was not used.

Back to tooling...

This offered a conflict on how to configure tools so that implementers could handle the transition gracefully. Here is what I settled on.

The Public Registry server would remain on XDS.b (early). Those who do not implement Metadata Update can continue to use it well. It does not return VersionInfo and in fact does not accept it in the Register transaction.

The Registry simulator in toolkit would move on to XDS.b (late) and offer support for Metadata Update. It accepts VersionInfo in submissions and supports Metadata Update in general (except for updating Patient ID - so far).