IHE ITI Web Services Glossy

Introduction

Web services can be commonly defined as a set of protocols, which are based upon the computer network technology powering the World Wide Web. The goal of implementing web services is to provide a stable, vendor neutral infrastructure platform for data exchange, upon which various products can differentiate themselves by providing value added benefits. This allows better interoperability among systems, which benefits both users, and vendors. From the user's perspective, a vendor-neutral infrastructure allows them to chose the best systems to serve their needs. From the vendor's perspective, using a standards-based and platform-neutral technology lets them concentrate on their core competencies, and lowers the cost of research and development.

The web services standards are developed in two main SDOs: the Organization for the Advancement of Structured Information Standards (OASIS), and the World Wide Web consortium (W3C). These standards are designed to work with each other, and build upon each others' features. The Web Services Interoperability organization (WS-I) further profiles existing standards and provides validation tools to ensure interoperability between implementations. The following illustration provides a view on the various Web Services and the relationship among them:

The Role of Web Services in Health Care Interoperability

As with any other technology, the use of web services has benefits and costs. It is important to understand where web services fit in the overall framework for the meaningful exchange of health care information, which is the basis of health care interoperability. The what and how of that exchange is sometimes described as semantic and syntactic interoperability. Standards-based web services provide a SOAP-based messaging infrastructure and transport mechanism, which are important pieces of the syntactic interoperability puzzle.

Web services are applicable to a variety of use cases, workflows, and business contexts. This flexibility is provided by the ability to layer various web services components on top of each other. Among the benefits of such general applicability are reusability of tools, reusability of established infrastructure, gradual implementation of features, and gradual specification of features. At the same time, among the costs of generality are implementation of the underlying infrastructure, and handling the relative heavy-weight payload of web services transactions.

The following snippets illustrate how web services can be layered.

<s:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope”>
  <s:Body>
     ...
  </s:Body>
</s:Envelope>

Simple SOAP message

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <S:Header>
    <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
    </wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://business456.example/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To S:mustUnderstand="1">mailto:joe@fabrikam123.example</wsa:To>
    <wsa:Action>http://fabrikam123.example/mail/Delete</wsa:Action>
    <wsa:FaultTo>
      <wsa:Address>http://business456.example/client1</wsa:Address>
    </wsa:FaultTo>
  </S:Header>
  <S:Body>
	…
  </S:Body>
</S:Envelope>

SOAP message with WS-Addressing

<<Add additional illustration of layering of web services>>

IHE strives to evaluate the trade-off between benefits and costs of using web services protocols as the underlying infrastructure for IHE transactions, and provides specificity in order to reduce the generality of the existing standards. The latter uses a similar approach to WS-I in profiling web services specifications, with universally applicably guidelines presented as part of the Technical Framework. As various use cases add new requirements to the use of web services, these guidelines continue to evolve. Individual profiles use the universal guidelines and further clarify them within their specifications.

Web Services and Service Oriented Architecture

A Service Oriented Architecture (SOA) is an architectural style for creating and using business processes packaged as services.[[1]] As a business practice, SOA improves organizational agility. Web services are often used as the underlying technology of SOA implementations. IHE's use of web services enables healthcare organizations to adopt SOA while using IHE profiles and transactions.

Use of Web Services Across existing IHE Profiles

<<<Table>>>

IHE provides general guidelines for using web services in Appendix V, which is currently a Technical Framework supplement for trial implementation [[2]]. The guidelines are formulated similarly to the profiles developed by the WS-I and the HL7 Web Services profile, and define Web Services as SOAP-based messaging infrastructure and transport mechanism. The Appendix covers the use of both SOAP 1.1 and SOAP 1.2, with SOAP 1.2 being the preferred implementation due to the direct dependencies of related specification like XOP, MTOM, WS-Addressing, and WS-Security on that version.

The web services in the IHE technical framework are defined using Web Services Definition Language version 1.1 (WSDL 1.1) descriptions. In addition of specifying the different parts of the WSDL within the transaction definition, a reference WSDL file is provided on the IHE FTP site for each actor participating in a particular IHE profile, as well as full definitions of the message contents via XML Schema Definition files.

The following integration profiles are currently using the guidelines in their transaction definitions:

Cross-enterprise Document Exchange-b (XDS-b)

The XDS-b profile uses web services in all transactions defined for its actors. In addition to the specifications described in Appendix V, this profile's use of MTOM (with XOP) brings the set of transactions for XDS in line with most web services implementations. <<Mention XDS-a>>

Request Form for Data Capture (RFD)

<<need description>>

Patient Identifier Cross-referencing (PIXV3)

The PIXV3 profile provides a web services based alternative to the existing PIX profile. While the semantics of the transactions are identical, this profile can take advantage of an existing web services infrastructure.

Patient Demographics Query HL7 V3 (PDQV3)

The PDQV3 profile provides a web services based alternative to the existing PDQ profile. While the semantics of the transactions are identical, this profile can take advantage of an existing web services infrastructure.

Future Directions

New profiles using web services

<<SVS>>

New web services features

<<Asynchronous Web services>> <<Quality of Services - WS-Reliability, WS-Security, WS-Transaction>>