OUP user menu

The HL7-OMG Healthcare Services Specification Project: Motivation, Methodology, and Deliverables for Enabling a Semantically Interoperable Service-oriented Architecture for Healthcare

Kensaku Kawamoto , Alan Honey , Ken Rubin
DOI: http://dx.doi.org/10.1197/jamia.M3123 874-881 First published online: 1 November 2009


Context: The healthcare industry could achieve significant benefits through the adoption of a service-oriented architecture (SOA). The specification and adoption of standard software service interfaces will be critical to achieving these benefits.

Objective: To develop a replicable, collaborative framework for standardizing the interfaces of software services important to healthcare.

Design: Iterative, peer-reviewed development of a framework for generating interoperable service specifications that build on existing and ongoing standardization efforts. The framework was created under the auspices of the Healthcare Services Specification Project (HSSP), which was initiated in 2005 as a joint initiative between Health Level7 (HL7) and the Object Management Group (OMG). In this framework, known as the HSSP Service Specification Framework, HL7 identifies candidates for service standardization and defines normative Service Functional Models (SFMs) that specify the capabilities and conformance criteria for these services. OMG then uses these SFMs to generate technical service specifications as well as reference implementations.

Measurements: The ability of the framework to support the creation of multiple, interoperable service specifications useful for healthcare.

Results: Functional specifications have been defined through HL7 for four services: the Decision Support Service; the Entity Identification Service; the Clinical Research Filtered Query Service; and the Retrieve, Locate, and Update Service. Technical specifications and commercial implementations have been developed for two of these services within OMG. Furthermore, three additional functional specifications are being developed through HL7.

Conclusions: The HSSP Service Specification Framework provides a replicable and collaborative approach to defining standardized service specifications for healthcare.


In recent years, enterprises across various industries have begun to realign their information technology (IT) assets around a service-oriented architecture (SOA), in which business needs are fulfilled through the orchestration of platform-neutral, network-accessible software services that provide core business functions through well-defined interfaces.14 The use of SOA within healthcare could produce significant benefits, including improved reuse of existing IT assets and an enhanced ability to respond to new business needs in a timely manner.5 To fully achieve these benefits, however, healthcare organizations and health IT vendors will need to adopt standard service interfaces that encompass both common capabilities and common semantics, as SOA does not inherently support standard interfaces. Such standardization is critical because healthcare organizations often use a multitude of health IT systems developed by different vendors, and because patient care must often be coordinated across organizations.

To address this need, Health Level 7® (HL7; Ann Arbor, MI) and the Object Management Group® (OMG; Needham, MA) launched a joint initiative in 2005 to define standard software services important to healthcare. Health Level 7 is the leading standards development organization in health IT internationally,68 whereas OMG is an open-membership computer industry consortium with expertise in developing enterprise interoperability standards in general, and software service standards in particular.9 Through this initiative, known as the Healthcare Services Specification Project (HSSP), various healthcare stakeholders have collaborated to generate a comprehensive framework for the specification of standard service interfaces. Known as the HSSP Service Specification Framework (SSF), this framework has been used to generate several service specifications that have been adopted as HL7 and OMG standards.

In this manuscript, we (i) describe the SSF; (ii) outline how the SSF has been used to specify two HSSP services; and (iii) discuss implications and future directions. These perspectives are based on the authors' experience establishing HSSP (KR and AH), co-chairing responsible committees within HL7 and OMG (KR and AH), and serving as principal contributors to HSSP service specifications (AH and KK).

Healthcare Services Specification Project (HSSP): Vision and Design Principles

HSSP Vision

The HSSP vision is to enable the use of standard SOA services in healthcare by (i) developing standard service interfaces and (ii) providing guidance on how to leverage these services within a SOA.

Three types of services are candidates for standardization: (i) infrastructure services, which are application agnostic and provide common utility functions; (ii) business services, which encapsulate reusable business capabilities; and (iii) healthcare-specific task services, which accomplish specific tasks, often through the orchestration of business services.10 Potential infrastructure service capabilities include access and security control, event logging, notification, and exception handling. In addition, potential business service capabilities include entity identity resolution, terminology management, patient registration, resource scheduling and management, clinical documentation and data storage, data retrieval, order placement, order fulfillment, billing, and patient-level inferencing. Moreover, potential task service capabilities include aggregating and presenting data within health information systems; generating business intelligence reports for organizational leaders; and providing chronic disease management services to healthcare providers.

To date, HSSP has focused on infrastructure services with requirements unique to healthcare (e.g., access and security control services) and business services with significant potential for reuse (e.g., data management and analysis services). Moreover, HSSP focuses on services for which there is both a community demand for standardization and a committed team for leading the standardization effort, an approach that fosters activity in areas of applied industry need and business relevance. While the standard services that HSSP defines over the near term will only represent a portion of potential services, a SOA can support incremental addition of other standard service interfaces as they are developed.

The definition of standard SOA interfaces is the primary focus of HSSP and this manuscript. However, HSSP recognizes that an effective SOA requires more than well-defined services; it requires effective coordination, use, and monitoring of these services. For example, healthcare organizations adopting a SOA must support robust audit trails; support high levels of concurrency, load balancing, and failure recovery; and incorporate testing and debugging procedures that account for the possibility that a system leveraging multiple services may fail even when component services are working properly. To address these needs, HSSP provides a Practical Guide on how to leverage HSSP-defined services within an overall SOA strategy.11 Moreover, one of the authors has previously outlined how HSSP services could be leveraged to fulfill the strategic objectives of the United States Roadmap for National Action on Clinical Decision Support.4

Design Principles

The SSF incorporates design principles that are accepted as industry standard practices.10 Table 1 describes these principles and how HSSP services fulfill these principles.

View this table:
Table 1

SOA Design Principles10 and Application within HSSP Services

Design PrincipleDescriptionApplication Within HSSP Services
Standardizationsimilar services should use standardized service interfacesthe purpose of all HSSP service specifications is to standardize service interfaces across implementations
Loose couplingservices should be as independent as possible from other services and from client applicationsHSSP services are designed to allow for efficient coordinated use. However, there are no formal dependencies among HSSP services.
Abstractioninformation that is not needed by a client to use a service is hidden from the clientHSSP services hide unnecessary implementation details, such as the programming language and database structures used
Reusabilityservices should be context-agnostic and be reusable across diverse use scenariosHSSP service specifications are designed using diverse use scenarios, to help ensure usability across multiple deployment contexts
Autonomyservices should exercise significant control over their execution environmentHSSP services are defined within well-demarcated, self-contained functional boundaries amenable to significant control by service implementations
Statelessnessservices should minimize the need to maintain state information across interactionsHSSP services are stateless whenever possible. Intermediate state information is passed back to the client if needed for a future interaction.
Discoverabilityservices should provide appropriate metadata for discovering available capabilitiesHSSP services provide metadata that describe their capabilities, including semantic profiles and semantic signifiers supported by the service
Composabilitysystems should be able to effectively leverage the service as a system componentHSSP services are designed to be well-defined, functionally complete, and independent services that can be effectively leveraged as components of larger systems
  • HSSP = Healthcare Services Specification Project; SOA = service-oriented architecture.

Leveraging Prior Work

The HSSP leverages relevant prior work where appropriate. Leveraged resources include the standards development processes of HL7 and OMG, including the HL7 Development Framework12 and OMG's Model-Driven Architecture.12 Furthermore, infrastructure standards such as the Web Services Description Language,3 XML Web services,3 and UML13 are used as the foundation of service specifications. Service semantics are specified using standard terminologies and information models, such as SNOMED CT® (Copenhagen, Denmark),14 LOINC® (Indianapolis, IN),14 HL7 information models,7 OpenEHR archetypes,15 and ASTM International's Continuity of Care Record model.16 As appropriate, HSSP service specifications explicitly identify their relationships to relevant existing industry work.

Approach to Semantics

Overview and Rationale

The HSSP defines services using coarse-grained, generalized interfaces that leverage constructs called semantic signifiers and semantic profiles to constrain payload semantics. This approach was taken for several reasons. First, this approach allows common interfaces to serve multiple semantic needs. Second, no universal consensus exists on the best information models to use for all aspects of healthcare. Third, preferred healthcare semantics have changed over time and are likely to continue to evolve. Finally, key stakeholders (e.g., the United States Veterans Health Administration) had internally specified semantics that were based on standards but were not recognized standards themselves. To promote the durability of the specifications under these circumstances, a decision was made to bind semantics to services at the level of service profiles rather than at the level of the core service definition. This approach allows organizations with unique semantic requirements to use HSSP services, while still enabling the use of consensus semantics across organizations should such consensus exist.

Semantic Signifiers

In HSSP services, a semantic signifier is the manifestation of a computable information model, tagged with a name and version and capable of being used and enforced by reference. Within XML Web service implementations, the information model of a semantic signifier can be defined by an XML Schema Definition17 and optional Schematron18 rule-based constraints. Information models that can be referenced via semantic signifiers include HL7 version 2 and version 3 information models. Terminology can be bound to these information models directly in the schema definition. Also, rule-based constraints can be applied to constrain the allowed terminology within model elements.

For example, consider the HSSP Retrieve, Locate, and Update Service (RLUS), which may be used to locate, retrieve, and update patient data.19 In this example, an RLUS client desires a patient's most recent serum creatinine data, communicated using LOINC codes and HL7 version 3 semantics for laboratory results.20 To obtain the desired data using the RLUS capability for data retrieval, the client provides the following inputs: (i) the semantic signifier denoting the information model to be used to return the data (the HL7 version 3 information model for laboratory test results,20 constrained to use LOINC codes); (ii) the semantic signifier denoting the information model used to express query parameters (the HL7 query model associated with the laboratory data model21); and (iii) the query parameters represented in the above format, where PatientID = the patient identifier and ObservationType.value = LOINC codes for serum creatinine.

Semantic Profiles

Semantic profiles provide a mechanism for restricting the semantics allowed within HSSP services. Typically, a semantic profile will define which semantic signifiers—and therefore which information models—can be used as input and output parameters within specific service operations. For example, an RLUS semantic profile may require that the information models used in the example above be supported for retrieving laboratory tests results.

Framework Formulation Process

Following the launching of HSSP in March 2005, the SSF was developed in an open, interactive, and peer-reviewed manner by members of the HL7 SOA Working Group and the OMG Healthcare Domain Task Force through regular teleconferences and face-to-face meetings. Moreover, relevant expertise from the wider HL7 and OMG community was obtained through joint sessions with other committees and well-attended general information sessions.

A working draft of the SSF was completed within several months. Since then, the SSF has served as the framework for developing HSSP service specifications, and lessons learned have continually been fed back into the SSF. The SSF therefore represents a stable but continually improving framework for developing service interface standards for healthcare.22 In the remainder of this manuscript, we describe the SSF and illustrate its use in the specification of interface standards for two healthcare services.

Framework Description


The SSF delineates a multistep framework in which HL7 defines the functional requirements for healthcare services in Service Functional Models (SFMs) and OMG defines derivative technical specifications. The SSF, as with all HSSP work products, is available on the HSSP Web page.22,23 This section outlines each step of the SSF (Figure 1).

Figure 1

Overview of HSSP Service Specification Framework (SSF).

Step 1: Identification of Standardization Candidates

First, candidates for service standardization are identified within HL7. As a practical matter, service candidates are limited to those which align architecturally with the HSSP conceptual architecture, are of similar granularity, and represent efforts for which HL7 members can commit sufficient effort for driving the specification process.

Step 2: Specification of HL7 Service Functional Model (SFM)

For each service selected for standardization, a host HL7 committee and a project leader are identified. The preference is to have standardization work hosted by the HL7 committee with the most relevant domain expertise regarding the service being specified. Then, project members specify the SFM as a technology-neutral, business-centric specification of service capabilities. The SFM is developed collaboratively, with peer review occurring through conference calls, face-to-face meetings, and e-mail communication. A standard SFM template is used to facilitate consistency among SFMs.

Within each SFM, Section 1 provides an introduction. Section 2 then provides an overview of the service in business terms and explains why a standard interface specification is needed. Section 3 provides high-level business storyboards supported by the service, and Section 4 outlines assumptions and dependencies. In Section 5, service functionality is specified in terms of technology-neutral business capabilities grouped within interfaces.

In Section 6, an initial set of service profiles is defined. Profiles allow generic service interfaces to be reused in many different scenarios through the placement of additional constraints. Profiles come in three forms: functional profiles, semantic profiles, and conformance profiles. Functional profiles identify named groupings of supported operations, whereas semantic profiles specify the semantic content supported by a service instance. Finally, conformance profiles are named combinations of functional profiles, semantic profiles, and usage context that can be used to assert and test conformance. In addition to profiles included within the SFM, further profiles can be adopted within HL7 and OMG at a later date to provide additional required capabilities.

The final sections of the SFM provide supplemental information. These sections include non-normative examples of how the service can be used; recommendations to the OMG community on issues to consider in generating the technical specification; and a description of how relevant standards and other resources have been incorporated by or otherwise relate to the SFM.

Step 3: Adoption of SFM as HL7 Draft Standard for Trial Use

Within HL7, the most important milestone is the adoption of the SFM as a Draft Standard for Trial Use. To be adopted as a draft standard, an HL7 specification must be presented to the HL7 membership and receive affirmative ballots from at least two-thirds of the voters. Moreover, all critiques raised must be formally addressed through a ballot reconciliation process. Further details of the HL7 balloting process, which conform to the requirements of the American National Standards Institute, can be found on the HL7 Web site.24

Step 4: Issuance of OMG Request for Technical Specifications

Following the adoption of an SFM as an HL7 draft standard, the SSF uses the standard OMG process for generating and adopting interoperable service specifications, known as the Model-Driven Architecture.12,25 In brief, this process involves the generation of a Request for Proposals (RFPs) for a technology-neutral Platform Independent Model as well as one or more technology-specific Platform Specific Models for the service; the generation of a conforming specification and reference implementation by one or more vendors; and the adoption of the specification through a formal balloting process.

All HSSP RFPs require a Platform Independent Model of service capabilities based on the HL7 SFM and expressed as UML models, as well as a Platform Specific Model for XML Web services. Following endorsement by the Healthcare Domain Task Force and approval by the OMG Architectural Board, the RFP is issued and publicized to the HL7 and OMG communities.

Step 5: Generation of Common Service Interface Specification by Vendors

In response to the RFP, interested vendors submit letters of intent to specify a technical service interface specification and to make available a service implementation based on the specification. While not required by the OMG, participating vendors typically form a single submitters' group to work collaboratively on a common specification. This common specification is then subjected to successive levels of review and balloting, starting with the Healthcare Domain Task Force and ending with the OMG's Board of Directors.

Step 6: Availability of Service Implementations

The OMG Board of Directors will not vote to adopt a specification unless the specification's implementability has been demonstrated through the availability of a commercial or noncommercial (e.g., open source) reference implementation. Thus, the OMG process guarantees the implementability of the OMG specification and the availability of at least one standards-compliant implementation.

Step 7: Revision of Specifications Based on Implementation Experience, and Adoption of Revised Specifications by HL7 and OMG

The final step of the SSF involves the revision of the adopted HL7 and OMG standards based on actual implementation experiences. Within HL7, the SFM is harmonized with the OMG standard and then balloted as full HL7 standards, in which adoption requires a 90% affirmative vote. Within OMG, a task force collects issues regarding the adopted standard from both OMG members and the public, so that any issues arising from the early phases of adoption can be formally tracked and addressed in a first revision of the specification.

Validation through Example: HSSP Retrieve, Locate, and Update Service (RLUS) and HSSP Entity Identification Service (EIS)

At present, two HSSP services have completed both the HL7 and OMG standardization processes. Moreover, two additional service specifications have been adopted as HL7 draft standards and are undergoing the OMG standardization process, and three additional SFMs are being specified within HL7. Table 2 outlines the current status of these services. In this section, we describe how the SSF has been applied to the specification of two services: the HSSP RLUS, which specifies a common approach to the location, retrieval, and updating of health information within and across healthcare organizations;19 and the HSSP EIS, which specifies how to resolve the identity of patients and other entities across systems.26 The RLUS and EIS SFMs were adopted as HL7 draft standards in 2006, and the technical specifications for these services were adopted as OMG standards in 2008.

View this table:
Table 2

Overview of HSSP Services

Service NameDescriptionStatus
Entity Identification Service (EIS)enables resolution of entities (e.g., patients) across systemsSFM adopted as HL7 draft standard; technical specification adopted as OMG standard; commercial implementation available
Retrieve, Locate, and Update Service (RLUS)allows location, retrieval, and updating of patient data across systemsSFM adopted as HL7 draft standard; technical specification adopted as OMG standard; commercial implementation available
Decision Support Serviceanalyzes patient data and generates patient-specific inferencesSFM adopted as HL7 draft standard; OMG specification under development
Clinical Research Filtered Query Servicesupport clinical trials, e.g., by identifying patients eligible for clinical trialsSFM adopted as HL7 draft standard; OMG specification under consideration
Common Terminology Serviceprovides access to various terminology capabilitiesversion 1 adopted as HL7 standard; version 2 SFM under development
Privacy, Access, and Security Servicesprovides suite of capabilities for managing privacy, access control, and securitySFM under development
Healthcare Provider and Services Directory Servicefacilitates identification of healthcare providers offering needed servicesSFM under development
  • HSSP = Healthcare Services Specification Project; OMG = Object Management Group; SFM = Service Functional Models.

Development and Adoption of HL7 SFMs

Table 3 provides an outline of the relevant sections of the 70-page RLUS SFM19 and the 96-page EIS SFM.26 At the core of each SFM is the specification of the service's functionality in terms of capabilities organized within interfaces. In RLUS, capabilities are provided within an administrative and management interface; a semantic interface; and a run-time interface for locating, retrieving, and updating patient health data. Table 4 provides an example functional specification for retrieving health data from an RLUS instance. An example query request against this RLUS capability was provided earlier in this paper. The EIS SFM specifies interfaces and capabilities in a similar manner to allow for the administration of the service as well as the querying of the service to identify entities that match client-provided search criteria.

View this table:
Table 3

Outline of RLUS and EIS SFMs

SFM SectionSubsectionSummary of Core RLUS ContentSummary of Core EIS Content
Service overview and business caseservice description and purposeRLUS allows health data to be located, accessed, and updated through a common service interfaceEIS allows various entities (e.g., patients, providers) to be uniquely identified across disparate systems
reason standard is neededa standard RLUS interface is needed because health data must be shared across multiple systemsa standard EIS interface is needed because relevant data on important entities reside across multiple systems
Storyboards and interaction detailsprimary scenariosscenarios and interaction details for locating, retrieving, and updating patient datascenarios and interaction details for identifying and managing entities within and across systems
Assumptions and dependenciesassumptionspatients can be uniquely identified within an RLUS deploymentthe relevant attributes and optimal entity resolution algorithms may differ by entity type
dependenciesRLUS instances may depend on other capabilities such as those provided by the EISthe generalized EIS interface will require specialized semantic payloads for different entity types
Detailed functional modeladministrative and management interfaces
  • capabilities for creating, updating, and deleting pointers to available health data

  • capabilities for identifying supported profiles

  • capabilities for creating, updating, inactivating, merging/unmerging, and linking/unlinking entities

  • capabilities for managing entity attributes in use

semantic interfacecapabilities for identifying semantic signifiers in usecapabilities for identifying entity attributes in use
run-time interfacescapabilities for locating, retrieving, and updating health datacapabilities for finding entities matching query criteria and for obtaining information on entities
Profilesfunctional profilesprofiles for location, retrieval, update, and administrationprofiles for updating, linking, merging, and querying for entities
semantic profileprofile for using HL7 Clinical Document Architectureprofile for using HL7's version 3 data model for patients
Recommendations for RFP issuancesemantics and conformanceRFP should require detailed specifications on how semantic signifiers are to be usedRFP should specify what additional semantic profiles are preferred for specification and standardization
RFP should require specification of conformance testing methodsRFP should allow submitters to re-engineer operations to more efficiently fulfill required capabilities
  • EIS = Entity Identification Service; RFP = Request for Proposals; RLUS = Retrieve, Locate, and Update Service; SFMs = Service Functional Models.

View this table:
Table 4

Functional Specification for RLUS Capability of Retrieve Resources by Resource Parameter

Capability FacetSpecification for Facet
Descriptiongiven a unique identifier and a semantic signifier, returns a particular resource transformed to the semantic structure in the semantic signifier.
  • resources are available and accessible to RLUS

  • submitter has agreed to exchange data via RLUS with the organization

  • semantic signifiers are being used, are describable and available, and are able to be modeled logically

  • query by example (for example, patient identifier), OR

  • semantic signifier identifying the information model for returning the resource of interest (resource semantic signifier); semantic signifier identifying the information model that is used to express the query parameters (query parameter semantic signifier); and query parameters, expressed in conformance with the query parameter semantic signifier

Outputsthe resource, transformed into the semantic model identified as an input parameter
  • a read-only representation of the resource is available to the requester's system

  • the resource has been transformed using the semantic signifier

Exception conditionsthe resource is unavailable; the resource ID is unable to be resolved; the semantic transformation is invalid; the semantic signifier is invalid or unavailable
  • RLUS = Retrieve, Locate, and Update Service.

With regard to conformance, the RLUS SFM specifies functional profiles that provide named groupings for functions needed for data location, retrieval, updating, and administration, as well as a semantic profile for the use of HL7 Clinical Document Architecture, Release 1 semantics (later updated to the HL7-ASTM International Continuity of Care Document27 semantics in the OMG technical specification). Similarly, the EIS SFM specifies functional profiles for updating, associating, and querying for entities, as well as a semantic profile for patient identification using the HL7 version 3 information model for patients. Following iterative revisions based on peer review and feedback, the RLUS SFM and EIS SFM were adopted as HL7 draft standards in September 2006.

Development and Adoption of OMG Technical Specifications

The RFPs for the OMG technical specifications for RLUS and EIS were issued in December 2006.28,29 As with other RFPs for HSSP services, these RFPs requested submitters to provide a platform-independent, UML-based technical specification for the service as well as a platform-specific specification for XML Web services. Six companies worked together on both the RLUS and EIS technical specifications [Intel® Corporation (Santa Clara, CA), Software Partners, Oracle Corporation® (Redwood City, CA), Ocean Informatics, WebReach, and Kaiser Permanente]. Technical specifications based on the HL7 SFMs were adopted as OMG standards for both RLUS30 and EIS31 in 2008, and commercial implementations are available for both services.


The widespread use of standard SOA services could lead to significant benefits for individual healthcare organizations as well as for the healthcare system as a whole. In this manuscript, we have described a methodology for defining standard service interfaces for healthcare, as well as two examples of how that methodology has been used.


Given the multitude of healthcare organizations that may be involved in the care of a single patient, the full promise of SOA can only be achieved in healthcare if services within and across healthcare institutions are capable of exchanging health data through standard interfaces. Thus, the significance of the HSSP SSF is that it provides a mechanism for allowing the full benefits of SOA to be achieved in healthcare. Moreover, the SSF validation described in this manuscript demonstrates that the SSF can be successfully used to develop standard SOA service interfaces for healthcare.


HSSP and the SSF have several strengths. First, HSSP and the SSF leverage existing resources. Second, the SSF ensures the availability of compliant services at the end of the standard adoption process. Third, the SSF has been demonstrated to be generalizable across multiple services (Table 2). Finally, the SSF and the resulting standard specifications have been peer reviewed and actively shaped by a wide range of interested stakeholders.


As one limitation, while we have demonstrated the generalizability of the SSF, there are clearly more business capabilities in healthcare whose service interfaces would merit standardization, such as for capturing clinical orders or for processing claims for payment. While our experiences to date indicate the SSF will be generalizable for these and other services, we have yet to demonstrate this level of generalizability. Furthermore, as with any formalized and peer-reviewed standardization process, the SSF requires a minimum of 2–3 years to complete (Figure 1). Given this limitation, HSSP undertook an effort known as SOA4HL7 to create a methodology for consistently creating “interim” service definitions using HL7 version 3 information models and other appropriate content. This methodology, whose creation was led by one of the authors (AH), was adopted as an Informative Document by HL7 in January 2007.32

Future Work

Moving forward, HSSP will continue its work on the currently active service specification projects. In addition, HSSP members are actively assisting the HL7 leadership in its efforts to transition HL7's primary work efforts from a message-centric framework to a services-oriented framework known as the HL7 Services Aware Enterprise Architecture Framework. The HL7 SOA Working Group has designated a formal liaison who is actively monitoring these activities and contributing HSSP community experiences. In addition, several HSSP projects have been accepted as early adopters of the HL7 Services Aware Enterprise Architecture Framework. Moving forward, HSSP seeks to foster a deeper alignment and bidirectional learning between these two complementary efforts.

Also, HSSP plans to deepen its collaboration with Integrating the Healthcare Enterprise (IHE), which defines profiles of how existing standards should be used to complete particular tasks.33 To date, most IHE profiles have focused on the coordinated use of messaging and document standards rather than service standards. Because IHE and HSSP have had a shared interest in several business domains (e.g., the domains covered by EIS and RLUS), IHE and HSSP members have met regularly over the past several years to discuss how best to coordinate efforts, and HSSP specifications have explicitly referenced and considered relevant prior work conducted by IHE. Moving forward, HSSP intends to work with IHE to develop implementation profiles based on the use of HSSP services.

Finally, HSSP will continue to provide a methodology and organizational home for individuals and organizations interested in shaping the future of SOA for healthcare through the standardization of relevant service interfaces.


The widespread use of standard SOA services may bring many benefits in healthcare. HSSP's SSF methodology represents an interdisciplinary, peer-reviewed process for generating standard interface definitions and reference implementations for services important to healthcare. The SSF has been used to generate service interface specifications that have been adopted as HL7 and OMG standards, and the specifications for two of these services were discussed as illustrative examples. Moving forward, HSSP and its members will continue to actively work together to generate service specifications and implementations that will facilitate the healthcare industry's ability to realize the full promise of SOA in healthcare.


  • KK's effort on HSSP and related projects has been supported by National Institute of Health grants T32-GM07171, F37-LM008161, K01-HG004645, R41-LM009051, and R42-LM009051; Agency for Healthcare Research and Quality grants R01-HS10472, R01-HS015057, and R03-HS10814; and Health Resources and Services Administration grant H2ATH00998. The other authors' efforts were supported by their employers [KR–EDS, an HP Company; AH—Kaiser Permanente until 2008; currently an independent consultant contracted to the International Institute for Safety in Medicine (II4SM)]. All authors contributed to the conception and design of the manuscript, and KK drafted the manuscript. All authors contributed to the critical revision of the manuscript.

  • The authors are members of HL7 and OMG. KR is co-chair of the OMG Healthcare Domain Task Force. AH and KR are or have been co-chairs of the HL7 SOA Working Group. KK is the project lead of the HL7 Decision Support Service project, AH was the main author of the HL7 EIS SFM, KR was the main author of the SSF, and all authors were coauthors of the HL7 RLUS SFM.

    KK holds intellectual property rights to a CDS technology known as SEBASTIAN that can provide its capabilities through an HSSP Decision Support Service interface. These intellectual property rights are held in a holding company known as Kedasys, LLC, and the technology has been licensed to Religent, Inc. for commercialization through the assistance of Small Business Technology Transfer grants R41-LM009051 and R42-LM009051 from the National Library of Medicine. KK and Duke University may benefit financially if products using the SEBASTIAN technology are commercially successful. Of note, the OMG process requires that any intellectual property required for implementing to the interface standards are made available to others for free or on nondiscriminatory and commercially reasonable terms.

    The views expressed in this manuscript are those of the authors alone and do not necessarily reflect the official opinions of the organizations with which the authors are affiliated.


View Abstract