The Simple Object Access Protocol and an Online Health Information Infrastructure

Wayne Brandes, DO MPH and Phil Sagan, PhD
American Institutes for Research
Silver Spring, MD

Introduction

On June 22 Microsoft Corporation unveiled “.Net”, its Web-based strategy for the future of the company.  At the heart of .Net is a newly developed remote procedure call (RPC) technology named the Simple Object Access Protocol (SOAP).  SOAP, which was developed jointly by Userland.com, Microsoft, and DevelopMentor, creates a Web messaging paradigm in which virtually every computer connected to the Web will be able to share data and resources with virtually every other computer connected to the Web.  SOAP may enable the most significant advance in functionality of the World Wide Web since the initial development of the Web itself.  Of significance for healthcare, SOAP may also become a key enabling technology in the long-awaited development of a nationwide networked health information infrastructure. 

SOAP will move the Web away from its current server-centric Web model, with relatively few servers and vastly greater numbers of clients (browsers), and towards a distributed peer-to-peer model in which every connected device can share its resources with every other connected device.  The network will indeed become the computer.

The implications of a peer-to-peer World Wide Web for on-line health records are profound.  In a SOAP-enabled world, any doctor’s office or hospital Web-connected computer will be able to share its stored records, via automated machine-to-machine processes, with any other doctor’s office or hospital Web-connected computer (with appropriate authorization, confidentiality, and security measures of course).  An individual’s medical records, maintained in a distributed fashion across the Web, will be able to be obtained and aggregated into a complete whole automatically, immediately, and on-demand, by any authorized Web-connected computer anytime and anywhere.  In a SOAP-enabled world patients will no longer need to carry their medical records to each new doctor's office or emergency department visit.  Doctors will have always-available access to complete medical records wherever there is an Internet connection.

Importantly, SOAP enables this functionality using two existing Web standards, Hypertext Transfer Protocol (HTTP) and eXtensible Markup Language (XML).  Because SOAP is based on Web standards, the worldwide infrastructure needed to operationalize this SOAP-enabled functionality is already in place. 

It will obviously be many years and many dollars before this vision can be realized, but it may be useful to start now to understand and think about the implications of this new Web model.  Support for SOAP as a Web standard currently has the backing of industry heavyweights including Microsoft, Dell, IBM, Lotus, Sun, Intel, and Compaq.  In fact, Microsoft has such faith in the technology that, according to Chairman Bill Gates, it has “bet the company” on its SOAP-based .Net strategy.  With that kind of commitment it is likely that SOAP will be having a major impact on the Web, and possibly on on-line health information, in the not-too-distant future. 

A Little Bit of SOAP

SOAP is a protocol (a set of rules) for sending machine-to-machine messages across the Web.   Web messages are electronic files that are automatically generated and sent back and forth between Web browsers and Web servers to carry out the work that is done on the Web, e.g., Web searches.  The standard format for Web messages is established by the rules in the Hypertext Transfer Protocol (HTTP).  Every Web-connected computer, no matter what operating system (e.g., Windows, Mac, Unix) understands and accepts HTTP messages, although only Web servers can respond to HTTP messages.

A HTTP message has two major parts, a header and a payload.  The header contains, among other things, the sender’s Web address, the recipient's address, and the type of action (e.g., POST) that is being requested.  The payload carries the information needed to carryout the request, e.g., a term to search for.  A reply message payload contains the requested information, usually in the form of a Web page.  Three significant limitations of the HTTP messaging paradigm are: 1) only relatively simple actions can be carried out via HTTP messages, 2) only relatively simple data can be carried in HTTP payloads, and 3) only Web servers can respond to HTTP requests. 

SOAP was designed to overcome these obstacles, and to do so using existing Web infrastructure and standards.  A SOAP message is essentially an HTTP header with an XML-payload.  Use of the HTTP standard allows SOAP messages to pass through firewalls and be accepted by any Web-connected computer.  The use of XML in the payload greatly increases the types and complexity of services and data that can be requested via a SOAP message.

XML, which is rapidly replacing HTML as the standard language of Web programming, allows machine-understandable meaning or context to be encoded with data.  This meaning can take a number of forms.  It can include the instructions necessary for running programs on other machines.  Additionally, it can indicate the context of data, e.g., that “pneumonia” is an instance of the data type  “diagnosis”.  Providing context turns data into information.

Health Level 7, the leading organization for the development of healthcare data exchange standards, is utilizing XML in the development of the newest version of its healthcare data messaging standard (Version 3.0) and its Clinical Document Architecture (CDA).  When HL-7 Version 3.0 and the CDA are adopted and widely deployed, electronic health record systems will encode their data with XML.

By utilizing XML, SOAP payloads can carry vastly more complex service and data requests than what can be done with HTML, e.g., a XML-encoded health care record.  A paraphrasing of such a detailed request might be “send me the lab results for person X for all visits for which the primary diagnosis was pneumonia”.  A computer running SOAP-enabled and HL-7 compliant software will be able to respond to such a request. 

In a SOAP-enabled Web it will not be necessary to create a national electronic medical records database.  XML-encoded healthcare records will be able to be maintained in a distributed fashion across the Web, at the various locations that have custody of the different components of an individuals’ lifelong health record, yet still be collected and aggregated into a complete whole via automated Web-based processes on an as-needed basis.  Additionally, by using what is known as Intelligent Agent software, it will not even be necessary for the requesting computer to know ahead of time the addresses of the different computers across the Web that contain an individual’s information.  It will be simply a matter of entering the appropriate patient identification (and authorization) information and an Intelligent Agent “bot” will search the Web and find the locations storing the information; similar to how a Web search engine works.  The computer operator will only need to enter the patient information, the software will take care of the rest.

RPCs and the Web

Why hasn’t something like SOAP been thought of before?  It has.  Other than HTTP, the most widely deployed Web messaging, or remote procedure call (RPC), technologies are the Common Object Request Broker Architecture (CORBA) and the Distributed Common Object Model (DCOM).  Similarly to SOAP, these RPC technologies can also enable complex resource and data sharing via the Web.  However they suffer from a number of drawbacks that limit their potential relative to SOAP.   Probably the most significant drawbacks are that 1) Internet security features such as firewalls block their messages, and 2) they are platform-specific, which means that they can only run on machines with certain operating systems.  Again, SOAP overcomes these obstacles.

SOAP messages are not blocked by firewalls.  Corporate firewalls typically are configured to allow only traffic on port 80 (and a few others), which is the standard port for HTTP messages.  CORBA messages travel via ports other than port 80, and therefore are blocked by most firewalls.  SOAP messages, on the other hand, utilize the HTTP standard, and thus port 80, and so are able to pass through most firewalls. 

SOAP is platform independent.  CORBA and DCOM only work with Microsoft Windows-based software.  SOAP is built on platform-independent Web standards.  It is compliance with these standards that allows machines running Unix, Windows, Macintosh, Linux and just about any other operating system to all communicate via the Web.

The future of SOAP

Obviously SOAP by itself will not be enough to enable a national on-line health information infrastructure; but it may get us a lot closer, a lot sooner, then we would be without it.  There are significant obstacles inherent in SOAP and in the other components of a health information infrastructure that will need to be worked out.

SOAP will need to be adopted as an official Web standard.  SOAP was recently submitted to the World Wide Web Consortium (W3C), the powers-that-be for Web standards, for the consideration of the formation of a working group in the area of XML-based protocols.  Even if SOAP is accepted as a Web standard though, it will take years for the technology to mature and to be widely adopted and deployed.  In addition, other needed standards, such as HL-7 3.0, will also need to be finalized and deployed.

Other software, that will provide the interface between SOAP messages and electronic health records systems, will likewise need to be developed and deployed.  Lastly, there are significant technical and regulatory issues surrounding the privacy, security, and confidentiality of individually identifiable health information that will need to be settled. 

In the meantime, though, it is useful to begin to understand and work with SOAP and to think through the potentially revolutionary possibilities it holds for the Web and for a health information infrastructure.

More information about SOAP can be found at many sites on the Web including the Microsoft Web site at http://msdn.microsoft.com/xml/general/soap_webserv.asp and at the W3C Web site at http://www.w3.org/TR/SOAP/.  SOAP toolkits can be downloaded from Microsoft at http://www.microsoft.com/downloads/ and from the Apache XML Project at http://xml.apache.org/soap/index.html.