IHE ITI Web Services Glossy: Difference between revisions
| Line 126: | Line 126: | ||
IHE also collaborates with the Healthcare Services Specification Project (HSSP) [[http://hssp.wikispaces.com/]]. Several of the IHE profiles can be used as implementations of some of the services specifications developed by the HL7 and OMG processes. | IHE also collaborates with the Healthcare Services Specification Project (HSSP) [[http://hssp.wikispaces.com/]]. Several of the IHE profiles can be used as implementations of some of the services specifications developed by the HL7 and OMG processes. | ||
===New profiles using web services=== | ===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. Designed similarly to the XDS profile, the transactions used in this profile follow the IHE ITI web services guidelines established in Appendix V. | 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. Designed similarly to the XDS profile, the transactions used in this profile follow the IHE ITI web services guidelines established in Appendix V. | ||
| Line 136: | Line 135: | ||
Other 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 Web Services'' is also part of the current development cycle. | Other 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 Web Services'' is also part of the current development cycle. | ||
Another emerging area of interest is | 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 to more efficient solutions, IHE members will undertake the task of adding the necessary web services functionality. | ||
Revision as of 02:06, 9 April 2008
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 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.
The following example illustrates how web services can be composed to work together The SOAP header contains elements from WS-Addressing, WS-Security, and WS-ReliableMessaging.
|
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 IHE ITI web services guidelines of Appendix V. |
X | |||
| Query for Existing Data (QED) 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 | |||
| Cross Community Access (XCA) 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. When the XDS Affinity Domain option is implemented, the use of MTOM/XOP is part of the Retrieve Document Set transaction. |
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
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. An example of a specification which
IHE also collaborates with the Healthcare Services Specification Project (HSSP) [[3]]. Several of the IHE profiles can be used as implementations of some of the 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. Designed similarly to the XDS profile, the transactions used in this profile 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. Since the WS-Eventing specification is still under development by the W3C, 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 transaction to solve healthcare use cases, adding new web services functionality can enhance existing profiles and also help solving new use cases. 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 makes it unsuitable for inclusion in IHE profiles at this time.
Other 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 Web Services 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 to more efficient solutions, IHE members will undertake the task of adding the necessary web services functionality.