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.

Here's a great comparison from an article comparing SOAP and REST.

SOAP

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.