editing disabled

Active Projects

Last Updated: May 22, 2016 7:48 pm
Please select a Project name to go directly to its page. Select one of the buttons to the right to view HSSP Activity Planning and Recent Updates.

Modeling and Notation Projects



Archetype Modeling Language (Active)

The objective of this work item is to provide a standard for modeling Archetype Models (AMs) using UML, to support the representation of Clinical Information Modeling Initiative (CIMI) artifacts in UML.

Service Specification Projects (in alphabetical order)


Care Coordination Service (Active)
  • Work is commencing on specifying a service to manage coordination of care, particularly relating to transfers of care across locations or tiers of care. Strong emphasis will be placed upon survey of existing industry work and how it can be applied to this problem space in the context of a SOA architecture.

Clinical Research Filtered Query (CRFQ) (Active)

Cloud Blueprint White Paper
More and more healthcare institutions are looking toward cloud-based deployment approaches to leverage shared infrastructure and to more effectively enable IT across institutions and business partners. While HL7 has standards that have utility and potential benefit in this space, nothing has been documented and published to address this need or to help provide guidance on how such an implementation approach might be realized.

This white paper will examine cloud environments and relate HL7 standards into those settings, illustrating where and how HL7 standards add value to cloud-based solutions. It will include an organizational self-assessment to determine readiness for cloud, and a maturity model to help for strategic planning.

CTS2 (Common Terminology Services 2) (Active)
CTS 2 will be a commonly accepted standard for terminology services that enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, and classification.

Cross Paradigm Interoperability Implementation Guide for Immunization (Active)
  • This implementation guide will explore the Service-Aware Interoperability Framework (SAIF) methodology to show how various HL7, IHE and OMG immunization-related artifacts can be deployed to satisfy immunization interoperability use cases. The project will provide feedback to the MnM SAIF Implementation Guide project regarding artifacts
  • and governance necessary to develop this projects deliverables. It will build upon existing artifacts rather than create anything new. Previous work includes: The Practical Guide to SOA in Healthcare Part II: the Immunization Case Study; the Immunization DAM; V2 immunization messages; V3 POIZ messages; V3 Care Record document; V3 Care Record message; vMR; IXS (Service Functional Model and Technical Specification); RLUS; DSS; hData; Arden Syntax; GELLO; IHE profiles including PIX, PDQ, and Immunization Content; IHE SOA White Paper. The scope of the immunization use case will be limited to use cases specifically related to interoperability; primarily patient identification, immunization data exchange and decision support (recommendations, adverse reactions, contraindications).

DSS (Decision Support Service) (Complete)
  • A commonly accepted standard for the DSS would make it more attractive for service consumers to invest in the infrastructure required for using the DSS to meet its patient evaluation needs, as they would be able to use the same interface to interact with multiple service vendors.

Event Publication & Subscription Service Interface Specification Project

hData Record Format (Complete, DSTU)

This project was transfered by the TSC and ArB from the HL7 ITS WG to SOA in April 2011. It establishes a simple hierarchical organizational model for clinical content and attaches data provenance meta data to this information. Through the HSSP collaboration, OMG is working on an RFC submission for a RESTful transport of hData content. The project was originally sponsored by MITRE, and has some additional videos and historical information at the Project hData website.

Healthcare and Community Services Provider Directory (See ServD)


Interdependent Registries Project (Pre-planning, Active)


IXS (Identity Cross-Reference Service, formerly known as Entity Identification Service) Normative (Complete)
  • Adopted as a current standard.

Medication Statement Service (Active)
  • The Medication Statement Service provides a list of active medications for a given patient. This project is co-sponsored by the Pharmacy WG.

  • Last Update: 2012-SEP-24

Order Service Interface Specification Project

PASS (Privacy, Access and Security Services)
  • The goal of PASS is to define a suite of services that will provide a simple interface for all privacy, access control, consent, identity management and other security services that are needed in a service-oriented health information architecture.
  • Access Control Service (Sustainment)
  • Audit Service (Active)


Practical Guide to SOA in Healthcare Volume II: Immunization Management Case Study (Complete)
  • The Practical Guide for SOA in Healthcare Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned.

RLUS SFM (Retrieve, Locate, Update Service Functional Model) Normative (Complete)
  • HL7 Normative Ballot effort for the HL7 RLUS SFM Normative Standard.
RLUS OMG Specification (Complete)

ServD (Formerly the Healthcare and Community Services Provider Directory, HCSPDIR) (Active)
  • HCPDS is required to provide an online facility that will enable Practitioners, via a set of parameters, to locate other practitioners, to assist in the continuum of care.

SOA Services Ontology (Active)
  • In order to support the effective description, discovery, and navigation among SOA services being specified within HL7, appropriate metadata about these services must be determined to support these needs, followed by the appropriate taxonomy and ontology work.

Unified Communications Service Interface Specification Project




Project Candidates (or "To Do" List)


Throughout the course of our activities, a number of great ideas for potential work items or emergent projects are often identified. The list below is a collection of some of these potential activities, which will reside here until they have reached critical-mass and the initiation criteria to advance to being formal work items under this program.

Care Coordination Service White Paper: With the work underway to create a service to assist with shared care plan management, and with the increasing attention and interest in effective solutions to address handoffs-of-care or transition of care between organizations or tiers of care, the idea was raised that an informative guide should be authored to illustrate how HSSP services can be used collectively to address this problem space. Whether an implementation guide, white paper, or other form has not yet been decided, but the general notion that services can add tremendous value to this problem space was widely agreed.

FHIR Ballot Document - Service Oriented Architecture Section: In joint discussions with FHIR and the HL7 ITS workgroup, it was agreed that we would take on "ownership" or reviewing the ballot content and providing enhancements/revisions to that text. Also discussed would be a "lite" application of SAIF to relate FHIR to SOA.

"FHIR Starters" -- It was generally agreed among the FHIR and SOA communities that these work items are not inherently conflicting, and in fact they are largely complimentary. One notable item was that FHIR does not on its own take care of usage contracts, behavior beyond basic CRUD type operations, and context-for-use. These are areas where SOA can provide valued guidance, and in a way make FHIR easier to implement.

The idea of creating implementation "design patterns" to address these planned omissions from the FHIR specifications were mututally viewed as valuable, and that should SOA be interested in taking this work on it would both help FHIR adoption and indicate relevance and fit to the existing SOA specifications. These "FHIR Starters" would serve as quick-start implementation guides, applying SOA patterns for FHIR based implementation.

Two activities would be associated with this. First, the creation of the "template" itself, and then creation of instances of FHIR Starters for SOA services that do exist.





Archived Projects

Projects listed in this section are not presently active, but may be re-prioritized as active projects if interest or demand dictates.


Infrastructure Subgroup
  • The Infrastructure Subgroup is charged with ensuring that HSSP remains operationally capable, providing guidance and documentation where it is needed so as to ensure that the process of standardization, alignment of objectives with host SDO organizations, and consistency and repeatability in execution as standards are developed.

EHR-S CI-IM EHR System Computationally-Independent Information-Model (Started Jun2010)
  • This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.

EHR-SD RM EHR System Design Reference Model aka H-SOA-RA (Healthcare SOA Reference Architecture)
  • This project matures and integrates the April 2008 Healthcare Services Oriented Reference Architecture (H-SOA-RA) into an EHR System Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware Enterprise Architecture Framework (SAIF), HITSP interoperability specifications, EHR System Functional Model (EHR-S FM) and ARRA artifacts. Emphasis is placed on maintaining HITSP, ARRA, NHIN and CCHIT conformance by maintaining EHR-S FM traceability. Mapping and analysis of the HL7 product portfolio against the EHR-S FM is used to integrate the reference architecture with HL7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model.


HF&EA Harmonization Framework and Exchange Architecture (Started Jun2010)
  • The first objective of this HL7 Harmonization Framework and Exchange Architecture (HF&EA) project is to define a notional set of architectural artifacts for HL7 projects and EHR System (EHR-S) development or acquisition projects. The second objective is to define the relationships among HL7 architectural artifacts and how they relate to other healthcare related standards and architectural artifacts, which can support a Model Driven Architecture (MDA) waterfall, spiral, agile or other development methodology. The third objective is to be an implementation guide for the use of the HL7 Development Framework (HDF) process and HL7 Service Aware Interoperability Framework Enterprise Compliance and Conformance Framework (SAIF ECCF) structure by which architectural work products are reused or developed, are organized into an Interoperability Specification and used throughout an architecture development project, the governance that should be enacted on these work products, and the scope of the standardization effort itself. The fourth objective is to define a Healthcare Information Exchange Model (HIEM) for model-driven Healthcare Information Exchange Package Documentation (H-IEPD) and exchange architecture. The fifth objective is to demonstrate how the HDF and ECCF can complement other frameworks such as TOGAF, Agile Scrum, DODAF and Zachman.

HSSP Process Refresh Project
  • This project is refresh existing documentation on the HSSP process, providing and overview of the processes within both HL7 and OMG. This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.

RASCI Planning
  • In an attempt to clarify ownership and responsibility between committees, the Foundation and Technology Steering Division (FTSD), agreed to review a candidate RASCI chart and to bring it forward to the HL7 Technical Steering Committee for consideration.


SAIF-HSSP Artifact Alignment Project
  • Given efforts currently underway to identify the artifacts that the HL7 community will produce that are SAIF-compliant, the SOA workgroup has elected to engage to shape those products that will be used by our committee. This project will harvest from existing boilerplate and process documentation in use by HSSP and meld them into SAIF artifacts as appropriate.