Part 19 of the DICOM Standard

DICOM Plugin Model

While preparing for a meeting with a new customer I took some time to review part 19 of the DICOM standard that I haven't red yet. Actually I should have done it before even it went out but being busy with other issues, it got ever delayed. Part 19 of the DICOM standard carries a prominent name, "Application Hosting". For me, Application Hosting immediately associates with Amazon EC2, Google App Engine, Cloud Computing and Grid. You can imagine my disappointment when I found out that behind the cover page I couldn't find anything of that kind. Instead, part 19 is a very detailed software specification document of a plugin model for two applications collaborating with one another over SOAP. It includes WSDL's and call sequencing diagrams that explains how the host application can invoke (or connect to) the plugin and exchange Web Services URL's that each application can then work with to collaborate with one another. The model is well defined and when I got few days ago an email Ad from Aunt Minnie about the Philips IntelliSpace PACS API I immediately went to look if it uses the DICOM plugin API Model. The Ad went to Philips Medical web site and as far as I could figure out their API is not based on DICOM's Application Hosting part. As of this moment I don't know of any vendor that does implement DICOM Application Hosting and if one of the reader does know such vendor, please comment and share this info with me.

When I do consulting work related to application design, I always advise to learn the existing DICOM, IHE and other resources before taking architecture decisions. It's not that these standards are 'The Bible' but they are good resources that a lot of time and effort was invested into them by professionals, much more resources that a single company, specially a small start-up can invest. I always say something like "you have a design document addressing the exact issues that you are facing, why not at least read it. If you adopt it, it can save you months of design and implementation work". But there's another side to this story.

I think that DICOM has completed very successfully its mission sometime during the first years of the previous decade. Year 2002 can maybe set as a landmark for that. Since then, instead of maintaining its great success and perfecting its achievements, many parts were added that are either too complicated or not really required and many parts were erased too. 

IHE have made tremendous work of house keeping and cleaning by defining the integration profile that DICOM and HL7 did not went into and then went on to define larger scale integration profiles, namely XDS. When doing so, they took from DICOM and HL7 the transactions that are already common practice and added to them new internet protocols. 

At the same time HL7 got carried into the version 3.0 RIM adventure that eventually evolved into a handful of monstrous XML's (most known is the CDA) that almost nobody bothered to implement because they were just too complicated. Gartner published a number on that stating that HL7 v3 adoption rate is less then 5% (how much less? I guess a lot).

The JPEG standard, for example, did not make this mistake. After publishing the JPEG file format and finalizing it in 1992, JPEG did not go seeking other domains. They have published the JPEG LS format and eventually the JPEG 2000.

Like HL7, DICOM too got carried away with the promise for structured reporting. If DICOM is a forest then SR is a jungle but DICOM's driving force did make vendors implement SR's and many of them do create syntactically valid SR DICOM objects. Still, the chances that one vendor's workstation will make sense out of other vendor' SR are, up to now, slim. Specific SR's with very well defined SOP Classes like Key Images Notes and the latest buzz Radiation Dose SR do gain popularity and may signal a change.

Getting back to part 19, I suggest that you do go over just to get ideas and maybe find something you didn't think of if you're just in the process or plan to do one of the following:

• If you are developing a new system and would like to provide API for other vendors to integrate with you, provide them with previous screen area and sharing data, I do suggest that you read part 19 and maybe decide to adhere to it.
• If you develop an advanced visualization or CAD and still don't know who is going to be your customers and would like to have some reference mode.