Page tree

NOTE : To use Track Changes, turn off “protection” by clicking on (pre-MS Word 2007) Tools > Unprotect Document or (MS Word 2007 and higher) Review > Protect Document.

PSS-Lite/Investigative Projects:  Sections surrounded by a BOLD OUTLINE must be completed for approval of "Investigative Projects" (a.k.a PSS-Lite).

  1. Project Name and ID



HL7 Health Service Reference Architecture (HL7-HSRA)

Project ID: 1407



TSC Notification Informative/STU to Normative          

Date : 



Investigative Project

Date : 

  1. Sponsoring Group(s) / Project Team

2.a. Primary Sponsor/Work Group

Primary Sponsor/Work Group
(1 (And Only 1) Allowed)


2.b. Co-sponsor Work Group(s)

Co-sponsor Work Group(s)

(Enter co-sponsor approval dates in Section 6.d Project Approval Dates)

  • ArB

Indicate the level of involvement that the co-sponsor will have for this project:


Request formal content review prior to ballot


Request periodic project updates. Specify period: 

at WGMs


Other Involvement. Specify details here: 


2.c. Project Team

All names should have confirmed their role in the project prior to submission to the TSC.

Project facilitator ( 1 Mandatory )

Stefano Lotti, Vincent McCauley

Other interested parties and their roles


Multi-disciplinary project team (recommended)


Modeling facilitator

Stefano Lotti

Publishing facilitator


Vocabulary facilitator


Domain expert rep

Vincent McCauley

Business requirement analyst


Conformance facilitator (for IG projects)


Other facilitators (SOA, etc)

Jerry Goodnough



Implementers (2 Mandatory for STU projects

1) [US] Veterans Health Administration

2) Telstra Health (Australia)

3) Cognitive Medical Systems

  1. Project Definition

3.a. Project Scope


The objective of the HL7 Health Service Reference Architecture (HL7-HSRA) is to support the design of medium/large scale eHealth architectures based on HL7 services and standards.


This project organizes adopted HL7 Service Functional Models, Functional Profiles and Domain Models as a basis for:

  • a formalized Enterprise Service Inventory (Normative)
  • an Architectural Patterns Catalog (Normative)
  • Methods for [enterprise] Service Discovery and Orchestration (Implementation guidance)

The document will extend to describe the role of well recognized HL7 related, healthcare services, to include but not limited to HL7-FHIR, OMG/HL7 Soap services, and the IHE XD* family of specifications. Moreover, there are existing sources of relevant work that will be considered and leveraged as part of this effort. This will include:


Open Group:

  • Archimate
  • The Open Group Architecture Framework (TOGAF)

Object Management Group (OMG):

  • SOAml
  • Business Process Modeling Notation (BPMN)
  • Case Model Management and Notation ( CMMN)
  • Structured Patterns Metamodel(SPMS)
  • Unified Architecture Framework(UAF)


  • SOA Repository Artifact Model and Protocol (S-RAMP). 

While the primary audience of the HL7-HSRA will be focused mainly on architects and CIOs that need to design, plan and evaluate enterprise wide solutions for complex organizations, the content is also relevant for the internal HL7 audience. The HSRA outcome verify the consistency of HL7 standard and potential area not fully covered or with relevant overlapping. The Pattern Catalog can also support the mapping between different HL7 standard for the behavioural aspects (e.g. V2-V3-FHIR)


3.b. Project Need

HL7’s work relating to services and service standards has historically focused on developing specifications for individual services themselves.  This included their functionality, inputs, outputs, expected behavior, exception handling, and so on.  What has been missing is the guidance expressing how those services fit together, how they are intended to be used, and the documentation of essential patterns that are demonstrated solution approaches to solving identified business problems. 


The use of these services in healthcare organizations is predicated upon an understanding of composite solutions that include different services that interact with one another (e.g., choreographies and/or orchestrations). It is when composite services are included within a services architecture that they begin to realize their true benefit, and this is the intent of the HL7-HSRA.  HL7-HSRA will support the process of architectural design with a map of building blocks and solution patterns based on existing HL7 Standards. 


For those organizations interested in achieving true “business” interoperability and not just data sharing, work such as HSRA is essential to realizing the consistency necessary for to achieve eHealth interoperability, and ultimately support for health interoperability. 


Addressing what has been a void in guidance to support business-to-business health needs manifests as increased design and planning barriers adversely affecting HL7-based architectures. This can lead to unintended, insufficient, or incomplete solutions based upon HL7 work products, falling short of their potential to adequately meet needs, particularly for medium and large-scale environments or institutions.


This project takes into consideration the needs of architects and CIOs to undertake a fully pervasive, sound, balanced and cost effective HL7 Service design for Enterprise interoperability.  Within HL7, we anticipate HSRA as having a positive impact in fostering alignment among workgroups, serving to identify existing gaps and to drive cross-product alignment.



3.c. Security Risks

Will this project produce executable(s), for example, schemas, transforms, style sheets, executable program, etc.  If so the project must review and document security risks. Refer to the Cookbook for Security Considerations for additional guidance, including sample spreadsheets that may be used to conduct the security risk assessment .











3.d. External Drivers

Consortia such as the Health Services Platform Consortium (HSPC) are communities that are working in the SOA architecture space and likely contributors and consumers of this work.  The HSPC “Roadmap” has identified a target future state supportive of a shared services platform, and this document will be used as a requirements source for HSRA.  Collaboration with HSPC is expected.

3.e. Project Objectives / Deliverables / Target Dates


Target Date

Project approval

Prior to September 2018

Alpha Draft HSRA Complete

December 2018

Conduct HSRA “Birds of a Feather” – Community Discussion

January 2019 WGM

Beta Draft HSRA Complete

April 2019

Conduct HSRA “Birds of a Feather” – Community Discussion

May 2019 WGM

For comment ballot

September 2019


2020 January Cycle


2020 September





Project End Date (all objectives have been met)

May 2021

3.f.    Common Names / Keywords / Aliases

HL7-HSRA, Services, SOA, Reference Architecture

3.g. Lineage


3.h. Project Dependencies


3.i.    Project Document Repository Location

3.j.    Backwards Compatibility

Are the items being produced by this project backward compatible?





















If you check 'Yes' please indicate the earliest prior release and/or version to which the compatibility applies:


For V3, are you using the current data types? 

(Refer to TSC position statement on new projects using R2B for more information on the current V3 data types)





















If you check 'No' please explain the reason:

3.k. External Vocabularies

Will this project include/reference external vocabularies?

























If yes, please list the vocabularies:


  1. Products (check all that apply)


Arden Syntax



V2 Messages – Administrative


Clinical Context Object Workgroup (CCOW)



V2 Messages - Clinical


Domain Analysis Model (DAM)



V2 Messages - Departmental


Electronic Health Record (EHR) Functional Profile



V2 Messages – Infrastructure


FHIR Extensions



V3 Domain Information Model (DIM / DMIM)


FHIR Implementation Guide



V3 Documents – Administrative (e.g. SPL)


FHIR Profiles



V3 Documents – Clinical (e.g. CDA)


FHIR Resources



V3 Documents - Knowledge


Guidance (e.g. Companion Guide, Cookbook, etc)



V3 Foundation – RIM


Logical Model



V3 Foundation – Vocab Domains & Value Sets


New/Modified/HL7 Policy/Procedure/Process



V3 Messages - Administrative


New Product Definition (please define below)



V3 Messages - Clinical


New Product Family (please define below)



V3 Messages - Departmental


Non Product Project - (Educ. Marketing, Elec. Services, etc.)



V3 Messages - Infrastructure


White Paper



V3 Rules - GELLO





V3 Services – Java Services (ITS Work Group)


Creating/Using a tool not listed in the HL7 Tool Inventory



V3 Services – Web Services (SOA)

If you checked New Product Definition or New Product Family, please define below:


  1. Project Intent (check all that apply)


Create new standard



Supplement to a current standard


Revise current standard (see text box below)



Implementation Guide (IG) will be created/modified


Reaffirmation of a standard



Project is adopting/endorsing an externally developed IG:


New/Modified HL7 Policy/Procedure/Process



Specify external organization in Sec. 6 below;


Withdraw an Informative Document



Externally developed IG is to be (select one):


White Paper (select one):



Adopted  - OR -





Balloted Informative OR


Non-balloted WG White Paper



N/A  (Project not directly related to an HL7 Standard)

5.a. Ballot Type (check all that apply)


Comment (aka Comment-Only)



Joint Ballot (with other SDOs)





N/A  (project won’t go through ballot)


STU to Normative     - OR -


Normative (no STU)




If necessary, add any additional ballot information here.  If artifacts will be jointly balloted with other SDOs, list the other groups.

5.b. Joint Copyright


Joint Copyrighted Material will be produced?









  1. Project Logistics

6.a. External Project Collaboration

  • Healthcare Services Platform Consortium (HSPC)
  • Object Management Group (OMG)

For projects that have some of their content already developed:

How much content for this project is already developed?


Was the content externally developed (Y/N)? 


Is this a hosted (externally funded) project? 
(not asking for amount just if funded)














6.b. Realm


Universal     - OR -



Realm Specific




Check here if this standard balloted or was previously approved as realm specific standard

6.c. Stakeholders / Vendors / Providers

This section must be completed for projects containing items expected to be ANSI approved, as it is an ANSI requirement for all ballots








Clinical and Public Health Laboratories




Clinical and Public Health Laboratories


Immunization Registries




Emergency Services


Quality Reporting Agencies




Local and State Departments of Health


Regulatory Agency


Health Care IT


Medical Imaging Service


Standards Development Organizations (SDOs)


Clinical Decision Support Systems


Healthcare Institutions (hospitals, long term care, home care, mental health)






Other (specify in text box below)


Other (specify in text box below)








Other (specify below)









Other:  Indicate other stakeholders, vendors or providers not listed above.


6.d. Project Approval Dates

Affiliate Approval Date (for Affiliate Specific Projects):


US Realm Steering Committee Approval Date
(for US Realm Specific Projects):



Sponsoring Work Group Approval Date:


moCo-Sponsor Group Approval Date

(Copy this entire row for each co-sponsor; indicate the specific cosponsor that issued approval)


ArB 2018-04-03

FHIR Project: FHIR Management Group Approval Date:


Architectural Review Board Approval Date:

(required for externally developed content)


Steering Division (of Primary Sponsor WG) Approval Date:

InfraSD Approval Date 2018-10-01

Last PBS Metrics Score :







PBS Metrics Reviewed ? (required for SD Approval if not green)





Technical Steering Committee Approval Date:

TSC Approval Date CCYY-MM-DD

TSC has received a Copyright/Distribution Agreement (containing the verbiage outlined within the SOU), signed by both parties.