IHE ITI Web Services Glossy

From IHE Wiki
Jump to navigation Jump to search

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: IHE WS.png

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 is one important piece of the syntactic interoperability puzzle. Only when web services are used in conjunction with specifications which bring semantic interoperability to health information exchange, the resulting combination provides a powerful mechanism for healthcare interoperability. This fits perfectly in the general approach IHE follows in fulfilling its mission.

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

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

Profile WS-Addressing MTOM/XOP WS-Security WS-Trust
Cross-enterprise Document Sharing-b (XDS.b)
A natural evolution of the original XDS.a specification, 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 existing web services framework implementations. 		X X
Request Form for Data Capture (RFD)
The RFD profile provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application. The SOAP transport option for the RFD transactions provides a web services implementation of the profile according to the guidelines in Appendix V.
Patient Identifier Cross-referencing HL7 V3 (PIXV3)
The PIXV3 profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. These cross-referenced patient identifiers can then be used by “identity consumer” systems to correlate information about a single patient from sources that “know” the patient by different identifiers. Using the HL7 V3 XML format and the HL7 Web Services Profile, the transactions follow the guidelines of Appendix V. 		X
Patient Demographics Query HL7 V3 (PDQV3)
The PDQV3 profile provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic and identifier information directly into the application. Using the HL7 V3 XML format and the HL7 Web Services Profile, the transactions follow the guidelines of Appendix V. 		X
Query for Existing Data (QED) X
Cross Community Access (XCA) X X
Cross-enterprise User Assertions (XUA)
The XUA profile provides a means to communicate claims about the user identity of an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries. WS-Security and WS-Trust can be used in the implementation of this profile. 		X X

Future Directions

<<General discussion, including relationship with HSSP, how new standards are to be adopted (fully vetted, broad base of support, provide efficient support for specific healthcare use cases, mention UDDI>>

New profiles using web services

<<SVS>>

New web services features

<<Asynchronous Web services>>

<<Quality of Services - WS-Reliable Messaging, WS-Security, WS-Transaction>>

Retrieved from "http://wiki.ihe.net/index.php?title=IHE_ITI_Web_Services_Glossy&oldid=15852"