Summary: Users and commercial and open source DICOM developers can be reassured that they may continue to use the subset of SNOMED concepts in the DICOM standard in their products and software, globally and without a fee or individual license.
Long Version.
The news from IHTSDO and a summary of the relationship can be found at this IHTSDO DICOM Partnership page, including links to the text of the agreement and a press release.
DICOM has used SNOMED since the days of the SNOMED DICOM Microglossary in the mid-nineties. This was the work of Dean Bidgood, who was not only very actively involved in DICOM but also a member of the SNOMED Editorial Board. As SNOMED evolved over time, it became necessary to reach an agreement with the original producers, the College of American Pathologists. This allowed DICOM to continue to publish and use SNOMED codes in software and products without a fee, and in return DICOM continued to contribute imaging concepts to be added to SNOMED.
This has worked out really well so far, so it is reassuring that we now have a similar agreement in place with the new owners, IHTSDO.
The subset of SNOMED concepts that DICOM may use includes all concepts that are currently in the standard as of the 2016a release and that are active in the SNOMED 2016 INT release, as well as those in some upcoming Supplements and CPs. I have been going through and cleaning up any concepts that have been inactivated in SNOMED (due to errors, duplicates, ambiguities, etc.) and adding them to CP 1495 to replace them and mark them as retired. This is pretty tedious but with the XML DocBook source of the standard, a lot of the checking can be automated, so this process should converge pretty soon. Note that per both the original agreement with CAP and the new agreement with IHTSDO, there is recognition that products and software that use retired inactive codes may continue to do so if necessary.
A small subset of codes (for non-human applications) have been handed off by IHTSDO to the maintainers of the Veterinary Extension of SNOMED CT, and we have been reassured by those folks that it is OK for us to continue to use them too.
If anyone actually needs a tabulated list of all the concepts in the SNOMED DICOM subset in some more convenient form than the PDF that lists the concept identifiers, just let me know and I can send you some of my working files. I also have some XSLT style sheets that can be used to trawl the source for both coded tuples and codes in tables, so if you need to do that sort of thing, just let me know (I will add these to the source and rendering archive file in the next release of the DICOM standard).
David
Wednesday, March 2, 2016
Tuesday, March 1, 2016
How many (medical image exchange) standards can dance on the head of a pin?
Summary: There are too many alternative standards for sharing images. For the foreseeable future, traditional DICOM DIMSE services will remain the mainstay of modality and intra-enterprise image management, perhaps with the exception of viewers used internally. The WADO-URI and WADO-RS services are attractive in their simplicity and have sufficient features for many other uses, including submission of other 'ology images using STOW (WIC). If one has not already deployed it (and even then), one might want to give serious consideration to "skipping over" XDS-I as a dead-end digression and going straight to the more mobile and ZFP friendly WADO-RS instead (including potentially revised MHD-I). The RSNA Image Share Validation program for XDS-I is perhaps not such a cool idea, and should be refocused on validating WADO-RS-based services. How/if FHIR ImagingStudy and ImagingObjectSelection fit in remains to be determined.
Long Version.
Do standards have location in space, but not extension, so the answer is an infinite number? Or no location at all, so, perhaps none?
We certainly have no shortage of standards in general, as the sarcastic quote from Andy Tanenbaum ("The nice thing about standards is that you have so many to choose from") illustrates. This xkcd cartoon explains one among many reasons for their proliferation.
Some of the drivers that encourage excessive proliferation of multiple standards for the same thing include:
If we just consider DICOM image and related "payloads" for the moment, and focus strictly on the exchange services, currently one has a choice of several overlapping mainstream "standard" services:
At the other end of the spectrum, there is the closest thing to a "raw socket" (the network developers' ideal), which is an HTTP GET or POST from/to an endpoint specified by a URL. In terms of medical imaging standards this means WADO-URI or WADO-RS for fetching stuff, STOW-RS for sending stuff, and QIDO-RS for finding it. FHIR's ImagingStudy resource also happens to have a means for actually including the payload in the resource as opposed to using WADO URLs.
Nothing is ever as simple as it seems though, and many committee hours have been spent on the low level details, like parameters, accept headers, character sets, media types and transfer syntaxes. There is insufficient experience to know whether the lack of a SOP Class specific negotiation mechanism really matters or not. But certainly for the simple use cases of getting DICOM PS3.10 or rendered JPEG "files", a few examples probably suffice to get a non-DICOM literate developer handwriting the code on either end without resorting to a toolkit or the need for too many dependencies. If one puts aside the growing "complexity" of HTTP itself, especially HTTP 2.0 with of its optimizations, in its degenerate form, this WADO-URI and WADO-RS stuff can be really "simple". Theoretically, WADO-RS is also supposed to be "RESTful", whatever that is, if anyone actually cares.
But its main claim to fame is there is no SOAP involved. On the subject of which ...
Somewhere in the middle (or off to one side) we have the old-fashioned SOAP Web Services based XDS-I.b, and the retrospectively DICOM-standardized and extended version of its transfer mechanism, WADO-WS. XDS-I.b includes SOAP services to interact with a registry to find stuff (documents and image manifests), and then the image manifest can be used to fetch the DICOM images, either using another SOAP transaction (RAD 69 based on ITI 42) or various DICOM or WADO mechanisms.
Born of a well-intentioned but perhaps misguided attempt to leverage the long defunct OASIS ebXML standard, and built on the now universally-despised SOAP-based web services, the entire XDS family suffers from being both complex and not terribly developer friendly. Though, the underlying XDS standards are gaining some traction (perhaps because there really weren't too many competing standards for moving documents around), there are not that many XDS-I.b implementations actually being used, though certainly some vendors have implemented it (and a few aggressively promote it).
Or to put in another way, with the benefit of 20-20 hindsight, XDS-I.b is beginning to look like the worst of all worlds - excessively complex, bloated, dependent on a moribund technology and with a negligible installed base.
What XDS-I.b does bring to the table is an architectural concept with registries and repositories and sources. So, rather than throw the baby out with the bathwater, there is ongoing IHE work to get rid of the SOAP stuff and make FHIR-based MHD the new profile on which to implement the same architecture (though it is not phrased in terms of "getting rid" of anything, of course, at least not yet). In IHE Radiology there is ongoing work to redo the first try at MHD-I to use WADO-URI and WADO-RS and the FHIR ImagingObjectSelection resource as a manifest.
Of course, it is very easy to be critical of XDS-I.b in retrospect.
Long before it became "obvious" (?) that simple HTTP+URL was sufficient for most use cases, as long as XDS-I, and later XDS-I.b, were the "only" non-DICOM-protocol approaches sanctioned by IHE, we all ran around promoting it as preferable to proprietary solutions, myself included. There was tacit acceptance that DICOM protocol detractors would never be satisfied with a non-port 80 solution, and so XDS-based image exchange was the only theoretical game in town.
Fortunately, hardly anybody listened.
I am oversimplifying, as well as eliding numerous subtleties (e.g., difficulties of cross-community exchange without URL rewriting, or benefits for caching, concerns about how to pass SAML assertions, benefits of leveraging same services and architecture as documents). And I am probably underestimating the size of the installed base (just as protagonists probably exaggerate it).
But the core message is important ... should we abandon XDS-I.b now, before it is too late?
I am increasingly convinced that for every objection some XDS-loving Neanderthal raises against using a light-weight HTTP non-SOAP no-action-semantics-in-the-payload URL-only pseudo-RESTful solution (LWHNSNASITPUOPRS), there is a solution somewhere out in the "real" (non-healthcare) world. Religious wars have been fought over less, but I think I have finally come around to the SOAP Sucks camp, not because XDS-I.b can't be made to work, obviously it can, but because nobody in this day and age needs to be burdened with trying to do so.
Since DICOM and HL7 embraced the RESTful way, it really seems like a waste of time to be swimming against the current, so to mitigate the issue of standards proliferation leading to barriers to interoperability, something has to be sacrificed, and the older less palatable approach may need to die.
Unfortunately, some folks are pulling in the wrong direction. One major imaging vendor (GE) is totally obsessed with XDS, and some (though not all) of its representatives jump up and down like Cartman having a tantrum whenever it is suggested that we retire the no-longer-useful and potentially harmful standards like WADO-WS (and even XDS-I.b itself perhaps). A few small vendors who have bet the farm on XDS join the chorus, to prove the point that somebody somewhere has actually used XDS-I.b for something. Right now there is a discussion in IHE Radiology about extending XDS-I.b to include more of the WADO-WS transactions like fetching rendered images, etc., which is quite the opposite of retirement.
So, as usual, the standards organizations like DICOM and IHE go back to the cycle of developing and promoting the union of alternatives, not the intersection, and almost everyone suffers. Not least of whom is the customer who has to (a) pay for the all the development and testing effort for their vendors to maintain all of these competing interfaces, (b) endure poor performance from any one of these interfaces on which insufficient effort has been devoted to optimization, and (c) is restricted in their choice of products when incompatible choices of competing standards have been implemented. Once upon a time the value proposition for IHE was navigating through the morass of standards but now it is an equal opportunity offender.
Some folks make out like bandits amongst this chaos, of course, including the more agile newbie VNA vendors who make it their bread and butter to try and support every imaginable interface (some even claim to support MINT). Whether they work properly or add any actual value is another matter, but there will always be an opportunity for those who make the glue. Can you say "HL7 Interface Engine?
Sadly, RSNA has recently jumped on the XDS-I.b bandwagon with the announcement of their RSNA Image Share Validation program. To be fair, I was among those who years ago encouraged the RSNA Image Share developers to use out-of-the-box XDS-I.b transactions to implement the original Edge Server to Clearinghouse and PHR connections, in lieu of any standard alternatives (given that they wouldn't just use DICOM). But the government handout from the Recovery Act is drying up, it is clear that patient's aren't rushing to pay to subscribe to PHRs, much less image-enabled ones, and frankly, this project has run its course. I am not really sure why RSNA wants to get involved in the image sharing certification business in the first place (which is what the prospectus describes), but in XDS-I.b they may have picked the wrong standard for this day and age.
Of course, may be we should just give up now and start making a new even simpler completely different universal standard that covers everyone's use cases :)
Oops, that was FHIR, wasn't it? Subject for another day perhaps.
David
PS. You may respond that my complaining about the "complexity" of XDS-I.b is a case of the pot calling the kettle black: I am an advocate of DICOM, and DICOM is hardly "simple" in terms of either its encoding or its information model (which is why the official DICOM XML and more recently DICOM JSON representations are, at the very least, superficially attractive), or the size of its documentation (which we have been trying to improve in terms of navigability).
And I would agree with you. But trying to simplify the payload, it turns out, is a lot harder than trying to simplify the exchange and query protocols, and if we can do the latter before yet another bloated and excessively complicated standard is inflicted on the developers and users, why not?
PPS. Few people notice it, but there is actually yet another DICOM standard for exchanging images, and that is in PS3.19 Application Hosting interfaces, which define SOAP-based WS transport intended for interoperability between host and applications written in different languages and running on the same machine. It is theoretically usable across multiple machines though. Using SOAP to pass parameters seemed like the best alternative at the time to making up something new, particularly given the tooling available to implement it in various popular languages. There has been talk in WG 23 of revisiting this with REST instead, but nothing has got off the ground yet; but think JSON with JAX-RS and JAXB, or similar. Since "API" is the buzzword du jour, maybe there is life in that idea!
Long Version.
Do standards have location in space, but not extension, so the answer is an infinite number? Or no location at all, so, perhaps none?
We certainly have no shortage of standards in general, as the sarcastic quote from Andy Tanenbaum ("The nice thing about standards is that you have so many to choose from") illustrates. This xkcd cartoon explains one among many reasons for their proliferation.
Some of the drivers that encourage excessive proliferation of multiple standards for the same thing include:
- extension of an existing successful standard into a new domains to compete with an incumbent
- "technology refreshment" (wanting to use the latest and greatest trendy buzzword compliant mechanisms that may or may not offer real benefit)
- simpler solutions to address real or perceived complexity of existing standards
- "not invented here"
- laziness (easy to write than read)
- pettiness (we hate your standard and the horse it rode in on)
- low barrier to entry (anyone can use the word "standard")
- bad standards (seemed like a good idea to someone at the time)
If we just consider DICOM image and related "payloads" for the moment, and focus strictly on the exchange services, currently one has a choice of several overlapping mainstream "standard" services:
- the original DICOM PS3.4/3.7/3.8 "DIMSE" services (C-STORE, C-MOVE, C-GET) over ULP
- the first form of Web Access to persistent DICOM Objects (WADO), now called WADO-URI
- IHE XDS-I.b (and WADO-WS) and the related XCA-I
- the new WADO-RS services (branded as DICOMWeb), which evolved out of MINT
- FHIR's ImagingStudy resource
- JPEG Interactive Protocol (JPIP) using the DICOM Pixel Data Provider Service
- the PS3.19 Application Hosting interfaces (vide infra)
- installed base (for various scenarios)
- intra-enterprise (LAN) capability
- extra-enterprise (remote, WAN) capability
- cross-enterprise (WAN, cross identity and security domain) capability
- performance (bandwidth and latency)
- functionality (to support simple and advanced use cases)
- complexity (from developer, deployment and dependency aspect)
- security support
- scalability support (server load, load balancing, caching)
- reliability support
- ...
- between traditional acquisition modalities and the PACS or VNA
- for pushing stuff around inside an enterprise
- for pushing (over secure connections) to central/regional/national archives (like Canadian DIrs)
- for interfacing to traditional "workstations" for RT, advanced image processing, etc.
At the other end of the spectrum, there is the closest thing to a "raw socket" (the network developers' ideal), which is an HTTP GET or POST from/to an endpoint specified by a URL. In terms of medical imaging standards this means WADO-URI or WADO-RS for fetching stuff, STOW-RS for sending stuff, and QIDO-RS for finding it. FHIR's ImagingStudy resource also happens to have a means for actually including the payload in the resource as opposed to using WADO URLs.
Nothing is ever as simple as it seems though, and many committee hours have been spent on the low level details, like parameters, accept headers, character sets, media types and transfer syntaxes. There is insufficient experience to know whether the lack of a SOP Class specific negotiation mechanism really matters or not. But certainly for the simple use cases of getting DICOM PS3.10 or rendered JPEG "files", a few examples probably suffice to get a non-DICOM literate developer handwriting the code on either end without resorting to a toolkit or the need for too many dependencies. If one puts aside the growing "complexity" of HTTP itself, especially HTTP 2.0 with of its optimizations, in its degenerate form, this WADO-URI and WADO-RS stuff can be really "simple". Theoretically, WADO-RS is also supposed to be "RESTful", whatever that is, if anyone actually cares.
But its main claim to fame is there is no SOAP involved. On the subject of which ...
Somewhere in the middle (or off to one side) we have the old-fashioned SOAP Web Services based XDS-I.b, and the retrospectively DICOM-standardized and extended version of its transfer mechanism, WADO-WS. XDS-I.b includes SOAP services to interact with a registry to find stuff (documents and image manifests), and then the image manifest can be used to fetch the DICOM images, either using another SOAP transaction (RAD 69 based on ITI 42) or various DICOM or WADO mechanisms.
Born of a well-intentioned but perhaps misguided attempt to leverage the long defunct OASIS ebXML standard, and built on the now universally-despised SOAP-based web services, the entire XDS family suffers from being both complex and not terribly developer friendly. Though, the underlying XDS standards are gaining some traction (perhaps because there really weren't too many competing standards for moving documents around), there are not that many XDS-I.b implementations actually being used, though certainly some vendors have implemented it (and a few aggressively promote it).
Or to put in another way, with the benefit of 20-20 hindsight, XDS-I.b is beginning to look like the worst of all worlds - excessively complex, bloated, dependent on a moribund technology and with a negligible installed base.
What XDS-I.b does bring to the table is an architectural concept with registries and repositories and sources. So, rather than throw the baby out with the bathwater, there is ongoing IHE work to get rid of the SOAP stuff and make FHIR-based MHD the new profile on which to implement the same architecture (though it is not phrased in terms of "getting rid" of anything, of course, at least not yet). In IHE Radiology there is ongoing work to redo the first try at MHD-I to use WADO-URI and WADO-RS and the FHIR ImagingObjectSelection resource as a manifest.
Of course, it is very easy to be critical of XDS-I.b in retrospect.
Long before it became "obvious" (?) that simple HTTP+URL was sufficient for most use cases, as long as XDS-I, and later XDS-I.b, were the "only" non-DICOM-protocol approaches sanctioned by IHE, we all ran around promoting it as preferable to proprietary solutions, myself included. There was tacit acceptance that DICOM protocol detractors would never be satisfied with a non-port 80 solution, and so XDS-based image exchange was the only theoretical game in town.
Fortunately, hardly anybody listened.
I am oversimplifying, as well as eliding numerous subtleties (e.g., difficulties of cross-community exchange without URL rewriting, or benefits for caching, concerns about how to pass SAML assertions, benefits of leveraging same services and architecture as documents). And I am probably underestimating the size of the installed base (just as protagonists probably exaggerate it).
But the core message is important ... should we abandon XDS-I.b now, before it is too late?
I am increasingly convinced that for every objection some XDS-loving Neanderthal raises against using a light-weight HTTP non-SOAP no-action-semantics-in-the-payload URL-only pseudo-RESTful solution (LWHNSNASITPUOPRS), there is a solution somewhere out in the "real" (non-healthcare) world. Religious wars have been fought over less, but I think I have finally come around to the SOAP Sucks camp, not because XDS-I.b can't be made to work, obviously it can, but because nobody in this day and age needs to be burdened with trying to do so.
Since DICOM and HL7 embraced the RESTful way, it really seems like a waste of time to be swimming against the current, so to mitigate the issue of standards proliferation leading to barriers to interoperability, something has to be sacrificed, and the older less palatable approach may need to die.
Unfortunately, some folks are pulling in the wrong direction. One major imaging vendor (GE) is totally obsessed with XDS, and some (though not all) of its representatives jump up and down like Cartman having a tantrum whenever it is suggested that we retire the no-longer-useful and potentially harmful standards like WADO-WS (and even XDS-I.b itself perhaps). A few small vendors who have bet the farm on XDS join the chorus, to prove the point that somebody somewhere has actually used XDS-I.b for something. Right now there is a discussion in IHE Radiology about extending XDS-I.b to include more of the WADO-WS transactions like fetching rendered images, etc., which is quite the opposite of retirement.
So, as usual, the standards organizations like DICOM and IHE go back to the cycle of developing and promoting the union of alternatives, not the intersection, and almost everyone suffers. Not least of whom is the customer who has to (a) pay for the all the development and testing effort for their vendors to maintain all of these competing interfaces, (b) endure poor performance from any one of these interfaces on which insufficient effort has been devoted to optimization, and (c) is restricted in their choice of products when incompatible choices of competing standards have been implemented. Once upon a time the value proposition for IHE was navigating through the morass of standards but now it is an equal opportunity offender.
Some folks make out like bandits amongst this chaos, of course, including the more agile newbie VNA vendors who make it their bread and butter to try and support every imaginable interface (some even claim to support MINT). Whether they work properly or add any actual value is another matter, but there will always be an opportunity for those who make the glue. Can you say "HL7 Interface Engine?
Sadly, RSNA has recently jumped on the XDS-I.b bandwagon with the announcement of their RSNA Image Share Validation program. To be fair, I was among those who years ago encouraged the RSNA Image Share developers to use out-of-the-box XDS-I.b transactions to implement the original Edge Server to Clearinghouse and PHR connections, in lieu of any standard alternatives (given that they wouldn't just use DICOM). But the government handout from the Recovery Act is drying up, it is clear that patient's aren't rushing to pay to subscribe to PHRs, much less image-enabled ones, and frankly, this project has run its course. I am not really sure why RSNA wants to get involved in the image sharing certification business in the first place (which is what the prospectus describes), but in XDS-I.b they may have picked the wrong standard for this day and age.
Of course, may be we should just give up now and start making a new even simpler completely different universal standard that covers everyone's use cases :)
Oops, that was FHIR, wasn't it? Subject for another day perhaps.
David
PS. You may respond that my complaining about the "complexity" of XDS-I.b is a case of the pot calling the kettle black: I am an advocate of DICOM, and DICOM is hardly "simple" in terms of either its encoding or its information model (which is why the official DICOM XML and more recently DICOM JSON representations are, at the very least, superficially attractive), or the size of its documentation (which we have been trying to improve in terms of navigability).
And I would agree with you. But trying to simplify the payload, it turns out, is a lot harder than trying to simplify the exchange and query protocols, and if we can do the latter before yet another bloated and excessively complicated standard is inflicted on the developers and users, why not?
PPS. Few people notice it, but there is actually yet another DICOM standard for exchanging images, and that is in PS3.19 Application Hosting interfaces, which define SOAP-based WS transport intended for interoperability between host and applications written in different languages and running on the same machine. It is theoretically usable across multiple machines though. Using SOAP to pass parameters seemed like the best alternative at the time to making up something new, particularly given the tooling available to implement it in various popular languages. There has been talk in WG 23 of revisiting this with REST instead, but nothing has got off the ground yet; but think JSON with JAX-RS and JAXB, or similar. Since "API" is the buzzword du jour, maybe there is life in that idea!
Subscribe to:
Posts (Atom)