Enterprise Archive: Standards and SOA - A Mount Everest? | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Enterprise Archive: Standards and SOA - A Mount Everest?

May 30, 2008
by Joe Marion
| Reprints

From my involvement in a couple current engagements, a key dilemma facing anyone considering an enterprise image archive is the question of architecture, and is it possible to “reach the pinnacle” of a truly vendor-neutral, patient centric solution that can receive input from multiple service areas, and provide accessibility to a number of applications?

I am reminded of some recent computer technology battles that might well be bell weathers for healthcare image archiving. One example is the 802.11 N Wireless standard. In the words of Wikipedia, “…market demand has led the Wi-Fi Alliance to begin certifying products before amendments to the 802.11 standard are completed.” In other words, in the zeal for faster networking, people are willing to gamble on hardware in the hope that it can meet the eventual final standard.

Another good example is the Blu-Ray versus HD DVD format war. Some elements of consumers were willing to pluck down large sums of money to be pioneers before one or the other became the de facto standard. In this case, Blu-Ray won. And what about all those who bet on HD DVD? At least one retailer is capitalizing on it – Best Buy is offering gift cards to help clear out HD DVD inventory, and trade-ins to convert to Blu-Ray. Smart retailing!

The “lesson-learned” for healthcare imaging: Is there a horse race brewing in terms of enterprise image archival? A lot is made over industry standards efforts such as HL7, DICOM, and IHE as the answer to an enterprise archive. In a perfect world, everyone will interpret the standard and vendor A’s device will easily interoperate with vendor B’s device. Unfortunately, it’s not a perfect world, and vendors still strive for some competitive advantage. Hence, in DICOM there are fields that can support proprietary data! So, is the industry really behind the standards, or merely giving lip service to them and looking for any chance they can to gain a competitive advantage? In the case of an enterprise archive, there are those that would propose force-fitting everything into DICOM, so a non-DICOM object would be handled by enveloping it in a DICOM wrapper.

At the opposite end of the spectrum are those who subscribe to a patient-centric service oriented architecture (SOA). The SOA concept has broad IT appeal in terms of interoperability, and might be considered as a mechanism to supplant standards, and enable different services to cope within the environment. Those that would subscribe to this approach argue that the objective is to create a “vendor-neutral” solution that can interoperate in multiple services. This sounds like a great answer, but, where is the incentive to make it work? Is it market pressure alone that will force vendors toward solutions that interoperate? Will competitiveness get in the way such that proprietary hooks preclude true interoperability?

What is the answer? I am sure there are multiple viewpoints. Having raised this issue, I would like to propose this as a forum for sharing ideas – from both users and vendors, with the objective of educating those for whom this is a concern. I welcome your comments. What do you think? Should the enterprise archive wait and be driven by standards? Or, is SOA an alternative that will win out from market pressure just as Blu-Ray has?

I welcome your thoughts!



Hi Charles,

I'm the Lead Architect at TeraMedica, and co-Administrator of the dcm4che.org open source DICOM/IHE project.

Regarding the wrapping of non-DICOM with DICOM: I agree wholeheartedly with your assessment. One of the biggest values of DICOM is the standardization of object metadata and demographic information (all of the header attributes). From an archive perspective the choice is whether or not to store non-DICOM objects in a DICOM-wrapped format or in their native format. The thing to keep in mind is that not all producers and consumers of clinical objects (images, video files, documents, tar files, etc.) understand DICOM. Likewise, not many DICOM applications would understand a Word document, tar file, or AVI video file even if it were wrapped in DICOM. So, I think it is necessary to offer a means of retrieving (and storing) non-DICOM content in their native format - regardless of how the content is stored internally within the archive. Obviously this would be in addition to standard DICOM services if the archived content has been wrapped in DICOM.

Regarding SOA: You're right. I think that SOA is an overused buzz word (and has been for years). It is not a silver bullet and the implementation of an SOA is very much open to interpretation. A service oriented architecture is a collection of technologies, patterns and practices which follow some general guidelines. There are many of these guidelines, but I think the following are two of the most important:
* the services are accessible to heterogeneous consumers
* the services have well defined interfaces/contracts which are published

So, I could in theory take those points and say that my DICOM archive can participate in an SOA because my DICOM (and HL7) services are available to heterogeneous consumers regardless of the programming language used to implement the consumers. My DICOM interfaces are well defined by the DICOM and HL7 standards and the product's DICOM/HL7/IHE conformance/integration statements. While all of that is true, I think it is a stretch to say that this type of system (common in medical imaging) can participate in a traditional SOA - unless there is an enterprise service bus which understands DICOM and HL7, and can translate service calls from non-DICOM consumers. XML based services (SOAP and RESTful) have been the norm in SOA implementations for years because of the ability to use a common internet protocol (HTTP/HTTPS) and an industry spanning representation of data (XML).

I'll give you an example from one of our main products - Evercore. We offer all of the DICOM and HL7 services that you would expect an enterprise healthcare archive to implement. However, we also offer a Web Service API (SOAP in some cases, RESTful in others, XDS, WADO, etc.) so that consumers and producers who do not understand "edge protocols" such as DICOM and HL7 (quoting Paul Chang there) can perform the equivalent of a C-FIND, C-MOVE, ADT, ORU, ORM, etc. Behind the scenes, it is the same business logic. However, offering these services via Web Services opens the door to a wider usage. For example, we have clients with their own web portals, intranets, RIS, HIS, etc. systems which are web based. Using our Web Service APIs they can securely initiate a number of queries, actions, and administrative functions within our system from a web page using AJAX (Java), Flash, PHP, etc. This is also useful to partners who want to embed our archiving capabilities within their own application and expose archive functionality within their own user interface.

I came into healthcare IT 6 years ago, coming from a very large financial transaction processing company. Back at my previous employer, if we would have told Amazon.com that they could only perform payment verification and processing with us using the VISA2 protocol we would not have landed that account. Having Web Service APIs that allow a web based portal application to make service calls makes a huge difference and opens up a lot of doors. We have similar situations today at TeraMedica with some of our deployments and partner integrations.

So, anyway, I am in agreement with you. I am all about DICOM, HL7, IHE, etc. That is very important to us as a company in our products, and is personally one of the reasons why I am so heavily involved with Gunter Zeilinger on the dcm4che.org project (providing an open source implementation of DICOM and IHE actors to the public), and why I assisted the open source Mirth project with adding DICOM capabilities to their interface engine. I definitely advocate the use of standards as much as possible and am a big fan of XDS (especially XDS.b), WADO, and the direction of things in general (as you state with regards to Web Service access to Persistent DICOM Objects and other works in progress). However, there is a wider usage of the TeraMedica Evercore product that has prompted us to implement a public Web Service API so that we can integrate into a traditional SOA.

Thank you,

Damien Evans
Lead Architect, TeraMedica
Administrator, dcm4che.org

Joe, interesting topic that of enterprise image archival, two comments:

The issue may not be to "force fit everything into DICOM, so a non-DICOM object would be handled by enveloping it in a DICOM wrapper". DICOM value is to provide consistent metadata about the image, both general purpose metadata and modality specific metadata. That is not "simply wrapping". DICOM has gone a long way to standardize this metadata across over 30 imaging specialties among which radiology is just. That common semantics and its support across the enterprise IT systems make the medical value of an Enterprise Image Archive. If each enterprise cooks it and bake it their own way, there will not be much interoperability achieved, or at a very low level of technology and clinical practice. As you know the pixels of a medical image value is quite limited without the image acquisition context.

SOA is an overreaching approach to link IT and the supported business processes, with much appeal and only early realizations. You may be misreading the value of SOA in term of interoperability. It is only a set of software tool and a framework within which interoperability standards such as DICOM may be deployed. SOA does not replace or supplant interoperability standards. This may be a disappointment to you and some of your readers, but defining and standardizing in a consistent way the semantics of metadata associated with images in an enterprise archive remains a challenge where DICOM is and may remain of central value.

DICOM has been created as a "service-oriented" standard rather than a messaging standard (Hence the concept of Service Class). This makes embedding DICOM communication services into an SOA software and business architecture quite natural. So the gap between those two worlds is really small and will disappear with the new Web Services access to DICOM persistent objects under development.
Hope this adreeses most of your concerns.