IHE ITI Web Services Glossy

Introduction

IHE uses web services to solve common healthcare interoperability problems. This paper gives an overview of the utilization of this technology in the IHE process.

Overview of IHE

Integrating the Healthcare Enterprise® is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines a technical framework for the implementation of established messaging standards to achieve specific clinical goals. It includes a rigorous testing process for the implementation of this framework. And it organizes educational sessions and exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users.

The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards, HL7, DICOM, IETF, OASIS, W3C and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. IHE maintain formal relationships with several standards bodies including HL7, DICOM and refers recommendations to them when clarifications or extensions to existing standards are necessary.

Overview of Web Services

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)[1], and the World Wide Web consortium (W3C)[2]. These standards are designed to work with each other, and build upon each others' features. The Web Services Interoperability organization (WS-I)[3] further profiles existing standards and provides validation tools to ensure interoperability between implementations. The following illustration provides one possible view on various Web Services and their scope:

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 well with 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.

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.[4] 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 [5]. 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	SOAP	WS-Addressing	MTOM/XOP	WS-Security	SAML 2.0
Cross-enterprise Document Sharing-b (XDS.b) [6] 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/XOP brings the set of transactions for XDS in line with most existing web services framework implementations.	X	X	X
Cross-Enterprise Document Reliable Interchange (XDR) [7] The XDR profile is focused on providing a standards-based specification for managing the interchange of documents that healthcare enterprises have decided to explicitly exchange using a reliable point-to-point network communication. It is a natural complement to the IHE ITI XDS Integration Profile (for cross-enterprise document sharing) when a sharing infrastructure (repositories and registry) is not needed. The on-line mode option of this profile uses a subset of the transactions introduced by the XDS.b profile.	X	X	X
Request Form for Data Capture (RFD) [8] 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.	X
Patient Identifier Cross-referencing HL7 V3 (PIXV3) [9] 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	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 IHE ITI web services guidelines of Appendix V.	X	X
Query for Existing Data (QED) [[10]] The Query for Existing Data Profile (QED) supports dynamic queries for clinical data, including vital signs, problems, medications, immunizations, diagnostic results, procedures and visit history. It leverages the existing content modeling defined previously in other IHE document profiles and the HL7 CCD implementation guide to deliver information that is semantically equivalent as a web service using the HL7 Web Services Profile, and following the IHE ITI web services guidelines.	X	X
Cross Community Access (XCA) [[11]] The XCA profile supports the means to query and retrieve patient relevant medical data held by other communities. The transactions defined in this profile use web services according to the IHE ITI web services guidelines. The use of MTOM/XOP is part of the Cross-Community Retrieve transaction in this profile.	X	X	X
Cross-enterprise User Assertions (XUA) [[12]] 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 allows the receiver to make access decisions and proper audit entries. The WS-Security SAML Token profile provides a way to transmit the user identity assertion, and WS-Trust can be used to obtain the SAML identity assertion.	X			X	X

Future Directions

The IHE process relies on standards developing organizations (SDOs) to produce standards which are fully vetted, and have broad base of support among implementors. As OASIS and the W3C approve new web services specifications which provide efficient support for specific healthcare use cases, IHE committees will continue to widen and deepen the use of web services in integration profiles.

IHE also collaborates with the Healthcare Services Specification Project (HSSP) [[13]]. Several of the IHE profiles can be used in implementations of services specifications developed by the HL7 and OMG processes.

New profiles using web services

During the current development cycle, IHE committees are working on several new profiles and white papers which use web services. The Shared Value Sets (SVS) profile provides a means through which healthcare facilities can receive a common, shared terminology managed in a centralized fashion. One of the goals of this profile is for its transactions to follow the IHE ITI web services guidelines established in Appendix V.

The addition of publish/subscribe capabilities to XDS is described in a white paper, which is being developed by the IHE ITI Technical Committee. The goal of the white paper is to build upon established web services standards. As there are several options under consideration, the web services described in the white paper may change before this becomes a profile on its own. One of the goals of the white paper is to provide a blueprint for using publish/subscribe in other profiles.

New web services features

In addition to creating new profiles and transactions to solve healthcare use cases, adding new web services functionality can enhance existing profiles and also help solve new use cases.

New functionality which will benefit different workflows, and cross community access (XCA) in particular, is the ability to receive web service responses asynchronously. This work on specifying Asynchronous XDS-b is also part of the current development cycle.

Another emerging area of interest is the set of specifications regarding assurance of delivery, including reliable messaging and atomic transactions. As additional healthcare use cases are presented where these specifications can contribute, IHE committees will profile their use.

Among anticipated new capabilities for web services-based transactions is the automation of configuration, or "auto-discovery", of web services. While the UDDI specification partially addresses this particular topic, insufficient uptake among the major web services infrastructure frameworks and vendors, and having no particular use cases brought up for discussion, makes it unsuitable for inclusion in IHE profiles at this time.

Conclusion

IHE technical committees continue to investigate and evaluate existing web services specifications and their implementations. Building upon these standards provides a solid interoperable foundation for healthcare data exchange, and allows implementers to concentrate on using the data within healthcare IT applications.

References

1. Organization for the Advancement of Structured Information Standards (OASIS) - http://www.oasis-open.org/
2. World Wide Web Consortium (W3C) - http://www.w3.org/
3. Web Services Interoperability Organization - http://www.ws-i.org/
4. Wikipedia: Service-Oriented Architecture - http://en.wikipedia.org/wiki/Service-oriented_architecture
5. IHE IT Infrastructure Technical Framework, Volume 2, Appendix V: Web Services for IHE Transactions - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Appendix_V_TI_2007_08_15.pdf
6. Cross-enterprise Document Sharing-b (XDS.b) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDS-2.pdf
7. Cross-Enterprise Document Reliable Interchange (XDR) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDR_TI_rev2.pdf
8. Request Form for Data Capture (RFD) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_RFD_TI_2007_08_15.pdf
9. Patient Identifier Cross-Reference HL7 V3 (PIXV3) and Patient Demographic Query HL7 V3 (PDQV3) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_PIX_PDQ_HL7v3_TI_2007_08_15.pdf
10. IHE PCC Technical Framework, Volume 2: Query for Existing Data - http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Vol_2_TI_2007_08_15.pdf
11. Cross Community Access (XCA) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XCA_TI_2007_08_15.pdf
12. Cross-enterprise User Assertions (XUA) - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XUA_TI_2007_08_15.pdf
13. Healthcare Services Specification Project (HSSP) - http://hssp.wikispaces.com/