Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Friday, January 9, 2009

Cool Technology of the Week

Recently, while discussing standards with a group of colleagues, I received the following email:

"Having a simple web service interface for problems, medications, allergies, etc. is a great goal. We have seen the value of this as this is what Google Health has done using the CCR and ATOM standards. Since it is a RESTful service and not SOAP, there is no WSDL. Creating a web service interface does not solve the underlying problem though. One still needs to clearly and simply define the XML structure of a problem, medication, and allergy. WSDLs point to XML Schemas to define the inputs and outputs of the services."

I realized that the array of acronyms in this paragraph merited a blog on it's own. The gist of the discussion is how to use the web and HTTP to send structured data from application to application. SOAP and REST are two approaches to web services. Here's a brief overview of the pros and cons of these two cool technologies:

The Simple Object Access Protocol (SOAP) was developed at Microsoft in 1998 as a platform neutral alternative to middleware techologies like CORBA and DCOM. It was first introduced in 1999, modified in May 2000 when it was submitted to the W3C and the current version was finalized in 2005. Since then, SOAP has become the most popular approach for exchanging XML message.

The basic structure of SOAP is similar to HTML itself - a header and body. Here's a fictitious example of a SOAP exchange for requesting a patient's hematocrit from a lab system:Typically, there are tools available to help generate valid SOAP messages, because the syntax can be a bit complex.

Representative State Transfer (REST) was first described in Roy Fielding's Thesis in 2000. REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) which act upon the resources available on the network (Uniform Resource Identifiers - URIs). REST is easier to implement than SOAP for programmers familiar with the basic techniques of the web itself. Here's a fictitious example of a REST exchange for requesting a patient's hematocrit from a lab system:REST is similar to the way you request a web page from a browser, but instead of unstructured data, the response is computer readable discrete data. REST does lack some of the advanced features of SOAP such as security, policy, and reliable messaging.

Pros:* Langauge, platform, and transport agnostic* Designed to handle distributed computing environments* Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors* Built-in error handling (faults)* Extensibility

Cons:* Conceptually more difficult, more "heavy-weight" than REST* More verbose* Harder to develop, requires tools

REST

Pros:* Language and platform agnostic* Simpler to develop than SOAP* Small learning curve, less reliance on tools* Concise, no need for additional messaging layer* Closer in design and philosophy to the Web

Cons:* Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries* Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")* Tied to the HTTP transport model

Like everything in the standards world, requirements and use cases suggest the best approach to implement.

Now let's decode the email that was sent to me. The author suggests using a simple representation of medical data sent over a simple REST approach as means to easily transmit problem lists, medications, and allergies. Certainly there are some use cases, such as what Google Health is doing, where that works well.

As I've said in my 2009 Goals, I hope to work with all interested stakeholders this year to ensure the US has a clear path for transmission of clinical summaries between applications that meets complex and simple use cases. My hope is that the next generation of the Continuity of Care Document and the Continuity of Care Record will be developed jointly so that all the requirements are defined and met in a harmonious process.

11 comments:

I think your comparison is framed a little bit from the SOAP point of view. In the REST world, being "tied" to HTTP is not a negative, it's a significant benefit. HTTP provides built-in mechanisms for caching, compression, extensibility, resource relocation, error messages, and more. Extensive HTTP libraries are built into just about every language out there. Why build a complete SOAP stack, which 90+% of the time will be run on top of HTTP, without utilizing the power of HTTP and instead reinventing it in higher layers?

What's the point of a Web-based system for data that doesn't speak HTTP today? The flexibility of "any transport" is likely unnecessary complexity.

(It's worth noting too that there are important "mostly REST but not quite" approaches that continue to utilize the power of HTTP without sticking to just the 4 verbs.)

SOAP 1.2 has a feature known as the "Web Method Specification Feature". This exposes the HTTP method through the binding which allows, among other things, for SOAP users to use GET to retrieve SOAP envelopes that encapsulate the state of the resource identified by the URI. This is radically different than with the common use of SOAP 1.1

Does this mean SOAP 1.2 applications will suddenly become more RESTful? No, probably not. Most SOAP users will probably continue to use SOAP...

John - I'm interested in your comments on MD FIRE/MD PnP interoperability standards for medical devices. I was intrigued by the Dec 29th Boston Globe article "Medical devices lag in iPod age" (http://www.boston.com/news/science/articles/2008/12/29/medical_devices_lag_in_ipod_age/). After a little searching, found a paper by Dr. Julian Goldman, et. al. that describes an initiative to conform to purchasing standards for medical devices that comply with MD PnP.(http://mdpnp.org/uploads/ASA_2008_Exhibit_Handout_Contract_Reqmnts_MD_PnP_.pdf) Is BIDMC participating? If so, do you have any success stories to share with your blog readers?

What I'm seeing with respect to REST versus SOAP (and don't forget it's companion WSDL) is the increasing rule of "good enough" (something you've discussed in other threads) which is questioning the need for the sheer complexity of SOAP. Of course there were good reasons and intentions for the complexity in SOAP, but I believe we'll see it go the way of CORBA which, like SOAP, disappeared under the weight of the "kitchen sink" that became attached to it! REST by comparison is quick, dirty, fast and loose and....well, just plain "good enough" and works.

Other than the Pfizer manufactured anti-impotency medicine viagra, you can also avail of other various other natural erectile dysfunction cures such as herbs, amino acid, body steroid supplement et al to relieve yourself from the grip of impotency. All these treatment procedures are termed as natural Viagra and to known more on these natural erectile dysfunction treatments, log in to the website http://www.viagraforce.com.

Want to earn some money online? Free paid surveys are an ideal way to get started. You can find several websites which provide such an opportunity. All you require doing is registering with these sites with and providing them with authentic information, regarding education, career.

I thought this an interesting comparison from your perspective. Do you have any thoughts on web services in general vs. older mechanisms like EDI files exchanged via ftp for claims processing and such?