From HITSP to 

HL7 EHR System Function 

and Information Model 

(EHR-S FIM) Release 3.0

Interoperability Specifications

... a Ten Year Journey

Gary.Dickinson@ehr-standards.com , EHR WG Co-Chair

Nancy.Orvis@tma.osd.mil DoD MHS proponent

Shufnagel@tiag.net , EHR WG facilitator

NIST Presentation, June 11, 2013

6/13/2013 1

6/13/2013 DRAFT WORKING DOCUMENT 3
HL7 EHR-S FM

• The HL7 International EHR System Functional Model (EHR-S FM) outlines 

important features and functions that should be contained in an EHR system. 

• Through the creation of functional profiles, this model provides a standard 

description and common understanding of functions for healthcare settings. 

• To date, HL7 has developed or is developing profiles for areas such as child health, 

emergency care, long term care, behavioral health and vital statistic reporting.

• US National Institute of Standards and Technology (NIST) along with its accredited 

certification bodies (ACB) use EHR functional profiles such as the CRFP as a basis 

for certifying EHR systems.

• The EHR-S FM is the original product of the HL7 EHR Work Group that was 

created in 2000 at the request of the National Health Information Infrastructure 

(NHII) (now know as the office of the National Coordinator (ONC)).

6/13/2013 DRAFT WORKING DOCUMENT 4
Executive-Summary

• HITSP Stared Doing Interoperability Specifications in ‘2005

• The release of the EHR System Functional Model (EHR-S FM) Release 3 

is targeted for ‘2015; where, 

– it will become EHR-S Function-and-Information Reference-Architecture 

Release 3.0 (EHR-S FIM RA-3.0), 

– which builds upon and incorporates lessons learned from the EHR-S 

FM ‘2008 Release 1.1 and ‘2013 Release 2.0; and where, 

– the EHR-S FIM RA-3.0 is intended to facilitate pragmatic domainspecific tool-based,

• acquisition, development, implementation, test-and-certification 

requirements-specification 

• for EHR capabilities-and-systems. 

• A ‘2015 US-domain Meaningful Use (MU) Profile will be developed to 

demonstrate the EHR-S FIM RA-3.0’s utility.

6/13/2013 DRAFT WORKING DOCUMENT 5
HL7 EHR WG Tooling Vision

Using Sparx Enterprise Architect

• Proposed methodology and tools to support 

the development of EHR Interoperability 

Specifications. 

• End-to-End lifecycle Scope 

– Use Case, mapped to

– EHR System Functions, mapped to

– Information Exchanges (IEs), mapped to

– Information Model mapped it

– Interoperability Specifications, mapped to

– Standard IE content and transport

6/13/2013 DRAFT WORKING DOCUMENT 6
EHR-S FIM Tool Components

Use Case

• S&I Framework’s Use Case Simplification

– Reusable Actors, Systems, Roles

– Reusable Scenario Event Steps

– Reusable Actions

– Reusable Requirements

– Reusable Data Objects and Data Elements

– Context Constraints

6/13/2013 DRAFT WORKING DOCUMENT 7
EHR-FIM Tool Components

EHR-S Functional Model R 2.0

• The 2006 EHR-S FM had approximately

– 130 functions with

– 1000 conformance criteria. 

• The 2013 EHR-S FM R2 has over 

– 320 functions with 

– 2300 conformance criteria. 

6/13/2013 DRAFT WORKING DOCUMENT 8
EHR-FM Tool Components

HL7 Fast Healthcare Information Resources (FHIR)

• HITSP “C32” Continuity of Care Document (CCD) had 16 Data Modules

• FHIR will have approximately 150 data modules

• FHIR defines a set of granular clinical concepts. 

– The resources can be managed in isolation, or aggregated into 

complex documents. 

– Technically, FHIR is designed for the web; the resources are based 

on simple XML, with an http-based RESTful protocol where each 

resource has predictable URL.

6/13/2013 DRAFT WORKING DOCUMENT 9
NIST’s EHR Tooling Strategy

6/13/2013 DRAFT WORKING DOCUMENT 10

EHR-S 

FIM Tool 

Impact
Statement: Provide the ability to manage clinical orders and results including medication, nonmedication, diagnostic tests, blood products, other biologics and referrals, using order sets as 

appropriate.

Description: The provision of clinical care includes the need to order from a variety of 

treatments using order sets as appropriate as well as reviewing the results of treatment. Orders 

for treatments may include medications, non-medication therapies (e.g. physical therapy, 

special diet, immunizations, non-allopathic regimens); diagnostic care (e.g., laboratory, 

radiology); blood products and other biologics (e.g., blood transfusions, human growth 

hormones). Patients are often referred to other health care providers for more specialized 

diagnostic workup and/or treatment. An effective EHR-S must include support and 

management of these processes and associated documentation.

Example: (notional scenario based on conformance criteria) During an encounter, patient problems, 

previous treatments, care plans and results are reviewed; then, orders or order-sets, based-on accepted 

clinical practices and/or order set templates, may be created by the clinician. If an order or order-set is 

created, discrete data elements associated with the order(s) are recorded and any appropriate order 

related or patient-related information is noted. Patient orders and/or order-sets are reported-to or 

coordinated with appropriate sources, appropriate clinicians and organizations (e.g., PHRs, schools, 

registries, public health), according to scope of practice, organizational policy and/or jurisdictional law. 

EXAMPLE: CP.4 Manage Orders

Description / Scenario

6/13/2013 11 RED: Recommended deletion, Blue: Recommended Insertion
RED: Recommend deletion, Blue: Recommended Insertion

EXAMPLE: CP.4 Manage Orders

EHR-S Components Dependent-on Clinician-Activities

6/13/2013 12

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

act CP.4 Manage Orders

CP.4 Manage Orders

Manage 

Events

Manage 

Documents & 

Notes

Manage Records Manage Trusts

Start End

Manage 

Schedules

Manage Business Rules

Manage 

Terminology

Event Document or 

Note Terminology

EHR-S Components Clinician Activities

Encounter

Manage 

Lists

List

Clinical Document 

or Note

Schedule

Clinical 

Information

Order

Order Set Orders 

Schedule

Administrative 

Information

Patient 

Information

is-a
EXAMPLE: CP.4 Manage Orders

Conceptual Information Model (CIM)

6/13/2013 DRAFT WORKING DOCUMENT 13

class CP.4 CIM Manage Orders

Event

Terminology

Trust Infrastructure Record Infrastructure

CP, CPS & AS

Report

Encounter

Document or Note List Registry

Clinical 

Document or 

Note

Schedule

Order

Order for 

Referral

Clinical 

Information

Patient 

Information

Administrative 

Information

Order for 

Diagnostic Test

Order for 

Non-medication

Orders Schedule

Orders for Blood 

Products and 

Other Biologics

Order Set

Order for 

Medication

EHR-S

ISSUE: data associated with CDS
EXAMPLE: CP.4. Manage Orders

Conformance Criteria (CC) Applicable to this CDM

6/13/2013 DRAFT WORKING DOCUMENT 14

SHALL CCs have 

bolded borders. 

class CP.4 Manage Orders (attributes)

Order

- annotation

- comments & instructions (free text)

- demographic information

- indication/justification

- order activation date & time

- order set tag

- oral verification :boolean

- ordering clinician

- Order Execution Time

- Order Lifecycle Stage

- Order Type

- problem/diagnosis

- patient name

- patient identification number

- patient DOB or age

- patient instructions

- problem/diagnosis code link

- problem/diagnosis code or description

- Signature

- status

- supporting documentation

- usgency status

- user-created instructions or system prompts

+ manage()

CP.4#16

CP.4#01

CP.4#02 

CP.4#03

CP.4#04

CP.4#05

CP.4#06

CP.4#07

CP.4#08

CP.4#09

CP.4#10

CP.4#11

CP.4#12

CP.4#13

CP.4#14

CP.4#15

CP.4#18 CP.4#17

CP.4#19

CP.4#20

CP.4#21

CP.4#22

CP.4#23

CP.4#24

CP.4#25

CP.4#26

CP.4#27

CP.4#28

CPS.8.4 Support for 

Communications Between 

Provider and Patient and/or 

the Patient Representative

Order Lifecycle 

Stage 

Enumeration

- new

- cancellation

- modification

- renewal

- discontinuation

- conditional

- other

Order-Execution-Time 

Enumeration

- admission

- discharge

- post-operative

- conditional

- standing

Event

+ date & time (occurence)

- change justification

- circumstances

- Clinical Information

- date (entry)

- date (review)

- description

- duration

- information reviewed

- information source

- information validator

- location

- mechanism

- metadata

- person-role

- status

- trigger

- type

+ deactivate()

+ justify()

+ manage()

Order Type Enumeration

- diagnostic test

- non-medication

- medication

- blood product & biologics

- referral
EXAMPLE: CP.4 Manage Orders

Conformance Criteria (CC) Applicable to this CDM

6/13/2013 DRAFT WORKING DOCUMENT 15

1. CP.4#01 The system SHALL provide the ability to manage role-based, context-based and/or userbased order entry. (add reference TI role based function or remove here)

2. CP.4#02 The system SHALL provide the ability to manage the order lifecycle creation, renewal, 

modification and discontinuation, etc. of orders.

3. CP.4#03 The system SHALL provide the ability to render relevant, relevant patient-specific laboratory 

test results when entering an order. 

4. CP.4#04 The system SHALL provide the ability to manage the status of an order (e.g. open, completed, 

in process). (harmonize with CP.4.2)

5. CP.4#05 The system MAY provide the ability to capture, maintain and render order entry with an 

appropriate registration process when the identity of the patient is unknown or in an urgent situation.

6. CP.4#06 The system SHOULD provide the ability to manage standing orders or orders that may be 

submitted by providers other than licensed providers according to scope of practice, organizational 

policy and/or jurisdictional law. (standing order = pre-established conditional set of order = CPS 4.1, 

CPS.4.1 CC#4, CC#11) Verbal orders?

7. CP.4#07 The system SHALL provide the ability to capture and render problem/diagnosis as a required 

element of an order.

8. CP.4#08 The system MAY provide the ability to capture, maintain and render, as discrete data, a 

diagnosis/problem code and/or description associated with an order of any type (including prescriptions 

and medications ordered for administration).

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
EXAMPLE: CP.4 Manage Orders

Conformance Criteria (CC) Applicable to this CDM

6/13/2013 DRAFT WORKING DOCUMENT 16

9. CP.4#09 The system MAY provide the ability to link an order of any type (including medication order) 

with a related clinical problem(s) and/or diagnosis code(s) and description.

10. CP.4#10 The system SHALL provide the ability to annotate and render comments and instructions with 

an order. {same as CC11?)

11. CP.4#11 The system SHOULD provide the ability to annotate and render free text comments and 

instructions with an order. (same as CC10? )

12. CP.4#12 The system SHOULD provide the ability to tag frequently used and institutionally-approved 

order sets as “favorites” or “preferences” to facilitate retrieval and ordering.

13. CP.4#13 The system MAY provide the ability to manage orders submitted to or received from external 

organizations and/or facilities such as Health Information Exchanges (HIE) or regional Electronic Health 

Record Systems (EHR-S).

14. CP.4#14 The system SHALL render the patient name, identification number, and age or date of birth 

on all order screens.

15. CP.4#15 The system SHALL provide the ability to capture, maintain and render an indicator of oral 

verification ("read-back") of the complete order by the person receiving the telephone or verbal order.

16. CP.4#16 The system SHALL provide the ability to capture and render the urgency status (e.g., AsSoon-As-Possible or STAT) associated with an order. 

17. CP.4#17 The system SHOULD provide the ability to render order history for any order, including the 

ordering clinician, order details, date, and time. 

18. CP.4#18 The system SHOULD provide the ability to tag and render a field as required for a complete 

order by order type.

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
EXAMPLE: CP.4 Manage Orders

Conformance Criteria (CC) Applicable to this CDM

6/13/2013 DRAFT WORKING DOCUMENT 17

19. CP.4#19 The system SHOULD provide the ability to tag orders to be activated at a future date and time 

including admission orders, discharge orders, and post-operative orders.

20. CP.4#20 The system SHOULD provide the ability to render orders for all order types.

21. CP.4#21 The system MAY provide the ability to manage conditional orders that can be activated when 

certain criteria and conditions are met.

22. CP.4#22 The system SHOULD provide the ability to capture, store and render the identity of all 

providers who signed an order. 

23. CP.4#23 The system SHOULD provide the ability to render a list of active orders for a patient.

24. CP.4#24 The system SHOULD provide the ability to render a list of orders by similar or comparable 

type (e.g., all radiology or all laboratory orders).

25. CP.4#25 The system SHOULD provide the ability to render a list of outstanding orders for multiple 

patients (as opposed to outstanding orders for a single patient).

26. CP.4#26 The system SHOULD provide the ability to capture the provider's order-cancellation request.

27. CP.4#27 The system SHOULD provide the ability to transmit an order-cancellation request.

28. CP.4#28 The system SHALL conform to function CPS.8.4 (Support for Communication between 

Provider and Patient and/or the Patient Representative) to manage information regarding orders.

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
6/13/2013 DRAFT WORKING DOCUMENT 18