ANSI/HL7 EHR, R2.

1-2020
6/30/2020

HL7 Electronic Health Record System

Functional Model,
Release 2.1
June 2020
Sponsored by:
Electronic Health Records Work Group

Copyright © 2020 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is
strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health
Level Seven International. Reg. U.S. Pat & TM Off.
IMPORTANT NOTES:
HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this
document, you are not authorized to access or make any use of it. To obtain a free license, please visit
http://www.HL7.org/implement/standards/index.cfm.
If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work
(in each and every instance "Specified Material"), the following describes the permitted uses of the Material.
A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of
HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell
products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without
paying license fees to HL7.
INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special
Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7
ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.
B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without
additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive
and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your
employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having
made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute,
Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other
intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other
rights of any kind are granted under this Agreement.
C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without
additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the
Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not
directly incorporate, the Specified Material in whole or in part.
NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services,
or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become
ORGANIZATIONAL MEMBERS of HL7.
Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Trademark.
Licensee shall take no action contrary to, or inconsistent with, the foregoing.
Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and
that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”).
Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee
alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party
IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting
from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.
Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology Owner/Contact

Current Procedures Terminology

American Medical Association
(CPT) code set
https://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT SNOMED International http://www.snomed.org/snomed-ct/get-snomed-

ct or [email protected]

Logical Observation Identifiers Names Regenstrief Institute

& Codes (LOINC)

International Classification of World Health Organization (WHO)

Diseases (ICD) codes

NUCC Health Care Provider American Medical Association. Please see www.nucc.org. AMA licensing
Taxonomy code set contact: 312-464-5022 (AMA IP services)

Page ii HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
Contents Page

0 Introduction ........................................................................................................................................... iv
0.1 Notes to Readers .................................................................................................................................. iv
0.2 Changes from Previous Release ........................................................................................................ iv
0.3 Background ........................................................................................................................................... vi
0.3.1 What are Electronic Health Record Systems? .................................................................................. vi
0.3.2 How were the Functions Identified and Developed? ........................................................................ vi
1 Scope ...................................................................................................................................................... 1
1.1 EHR-S Functional Model Scope ........................................................................................................... 1
2 Normative References........................................................................................................................... 2
3 Terms and Definitions ........................................................................................................................... 2
4 Overview and Definition of the Functional Model (Normative) ......................................................... 3
4.1 Sections of the Function List ............................................................................................................... 3
4.2 Functional Profiles ................................................................................................................................ 5
4.3 EHR-S Function List Components ....................................................................................................... 5
4.3.1 Function ID (Normative) ........................................................................................................................ 6
4.3.2 Function Type (Reference) ................................................................................................................... 6
4.3.3 Function Name (Normative).................................................................................................................. 6
4.3.4 Function Statement (Normative) .......................................................................................................... 7
4.3.5 Description (Reference) ........................................................................................................................ 7
4.3.6 Conformance Criteria (Normative) ....................................................................................................... 7
5 Anticipated Uses (Reference)............................................................................................................... 7
5.1 Development Approach: Functional Profiles ..................................................................................... 7
5.1.1 Scenario 1 – Group Practice ................................................................................................................ 7
5.1.2 Scenario 2 - Hospital ............................................................................................................................. 8
5.1.3 Scenario 3 - IT Vendor........................................................................................................................... 8
5.2 Examples of Current Use ...................................................................................................................... 8
5.2.1 Functional Profile for Clinical Research based on the EHR-S FM ................................................... 8
5.2.2 AHRQ adopts Health Level Seven International (HL7) Child Health Functional Profile
Specification, Release 1 and incorporates key functionalities in the Children’s Electronic
Health Record Format ........................................................................................................................... 9
5.2.3 Linking clinical content descriptions to the EHR-S FM (Reference) ................................................ 9
6 Conformance Clause........................................................................................................................... 10
6.1 Introduction (Reference) ..................................................................................................................... 10
6.2 Scope and Field of Application (Normative) ..................................................................................... 10
6.3 Concepts (Normative) ......................................................................................................................... 10
6.3.1 Functional Profiles .............................................................................................................................. 10
6.3.2 Conformance Model ............................................................................................................................ 11
6.3.3 Profile Traceability .............................................................................................................................. 11
6.4 Normative Language (Normative) ...................................................................................................... 12
6.5 Conformance Criteria (Normative) ..................................................................................................... 12
6.5.1 Criteria in the Functional Profile ........................................................................................................ 12
6.5.2 ‘Dependent SHALL’ Criteria ............................................................................................................... 12
6.5.3 Referencing Other Criteria or Functions........................................................................................... 12
6.6 Functional Model Structure and Extensibility (Normative) ............................................................. 13
6.6.1 Hierarchical Structure ......................................................................................................................... 13
6.6.2 Naming Convention ............................................................................................................................. 13
6.6.3 Priorities ............................................................................................................................................... 14
6.6.4 Extensibility ......................................................................................................................................... 14
6.7 Functional Profile Conformance (Normative) ................................................................................... 14
6.7.1 Rules for Functional Domain Profiles ............................................................................................... 14
Functional Profiles claiming Functional Model conformance SHALL: ....................................................... 14
Functional domain profiles claiming conformance to the Functional Model MAY: .................................. 15
Functional domain profiles claiming conformance to the Functional Model SHALL NOT: ..................... 15
6.7.2 Rules for Creating New Functions in Functional Profiles .............................................................. 15
6.7.3 Rules for Derived Functional Profiles............................................................................................... 17
Derived functional domain profiles claiming conformance to one or more base functional domain
profiles SHALL: ................................................................................................................................... 17
6.7.4 Conformance Statement .................................................................................................................... 17
6.7.5 Rules for Functional Companion Profiles ........................................................................................ 17
6.8 Use Cases and Samples (Reference) ............................................................................................... 18
6.8.1 Functional Profile Use Cases ............................................................................................................ 18
Care setting ...................................................................................................................................................... 18
Community of interest derived functional domain and companion profiles ............................................. 18
Vendor functional domain profile and overarching conformance ............................................................. 18
6.8.2 Sample Functional Domain Profile Conformance Clauses ............................................................ 19
Conformance Clause for a care-setting functional domain profile ............................................................ 19
Conformance Clause for an application ........................................................................................................ 19
Conformance Clause for a vendor system functional domain profile ....................................................... 19
Conformance Clause for a community of interest functional companion profile .................................... 19
6.8.3 Interpreting and Applying a Conditional ‘SHALL’ (Reference) ...................................................... 20
6.8.4 General Concepts ............................................................................................................................... 20
6.8.5 Rationale for ‘Dependent SHALL’ ..................................................................................................... 20
6.8.6 How to Apply the ‘Dependent SHALL’ .............................................................................................. 21
7 EHR System Conformance Claim via Self-Attestion ....................................................................... 22
8 Glossary ............................................................................................................................................... 23
8.1 Preface (Reference) ............................................................................................................................ 23
8.2 Introduction (Normative) .................................................................................................................... 23
8.3 Overview (Reference) ......................................................................................................................... 23
8.4 The Action-Verb Structure (Normative) ............................................................................................ 23
8.4.1 Secure (System) Hierarchy ................................................................................................................ 23
8.4.2 Data Management Hierarchy ............................................................................................................. 24
8.4.3 How Action-Verbs are defined........................................................................................................... 25
8.4.4 Deprecated Action-Verbs ................................................................................................................... 30
8.5 Guidelines for Use (Reference) ......................................................................................................... 33
8.5.1 General Guidance ............................................................................................................................... 33
8.5.2 Constructing Rigorous Conformance Criteria ................................................................................. 33
9 Glossary Supplement: Record Lifecycle Events and Descriptions (Normative) ........................ 34
9.1 Record Lifecycle Events (See RI.1.1.1) ................................................................................................... 34
Annex A (normative) Function List ............................................................................................................... 37
Annex B (informative) Glossary of Terms for the EHR-S FM ...................................................................... 38
Annex C (informative) Background .............................................................................................................. 65
C.1 What is HL7? ....................................................................................................................................... 65
C.2 The HL7 Electronic Health Records Work Group ............................................................................ 65
Annex D Bibliography ..................................................................................................................................... 66

0 Introduction

0.1 Notes to Readers

EHR System Functional Model Release 2.1 is based on a series of predecessors, starting in 2004 with the
release of the first consensus Draft Standard, followed in 2007 by Release 1, followed in 2009 with Release 1.1
(jointly balloted with ISO TC215 and CEN TC251), followed in 2014 with Release 2.0 (jointly balloted with ISO
TC215, CEN TC251, DICOM, SNOMED (IHTSDO), CDISC and GS1). HL7 also published Release 2.01 as an
unballoted errata version in 2017.
0.2 Changes from Previous Release
The HL7 EHR-System Functional Model Release 2.1 had its first normative ballot in December 2019. Following
are key changes from Release 2.0:
• Includes updates from HL7 errata Release 2.01;

Page iv HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
• Record Infrastructure Section is updated to include three new Record Lifecycle Events: verify, encrypt
and decrypt. There are now a total of 27 Record Lifecycle Events, describing how an Electronic Health
Record System manages health record entries their lifespan, from first point of entry
origination/retention to last point of entry deletion or destruction. The 27 Record Lifecycle Events match
those specified in ISO 21089-2018, Health Informatics – Trusted end-to-end information flow and HL7
Fast Health Interoperable Resources (FHIR) Record Lifecycle Event Implementation Guide, published
a spart of FHIR Core STU-3 (March 2017) and now part of FHIR Core R4 (in ballot, September 2018).
• The 27 Record Lifeycle Event definitions/descriptions are updated according to agreements of the HL7
Vocabulary Alignment project (in joint collaboration of the HL7 EHR and Security Work Groups). The
Glossary Section also includes those definitions/descriptions.
• The Conformance Clause is updated to include a definition/description of a new type of EHR-S FM
Functional Profile (FP): Derived Companion FP.
• Trust Infrastructure is updated to include functions and conformance criteria to support ISO/HL7
Detailed Clinical Models (DCMs).
0.3 Background
0.3.1 What are Electronic Health Record Systems?

The effective use of information technology is a key focal point for improving healthcare in terms of patient safety,
quality outcomes, and economic efficiency. A series of reports from the U.S. Institute of Medicine (IOM)
identifies a crisis of "system" failure and calls for "system" transformation enabled by the use of information
technology. Such a change is possible by "an infrastructure that permits fully interconnected, universal, secure
network of systems that can deliver information for patient care anytime, anywhere.
In developing this EHR-S Functional Model, HL7 relied on three well-accepted definitions: two provided by the
U.S. Institute of Medicine and one developed by the European Committee for Standardization/ Comité Européen
de Normalisation (CEN). This Functional Model leverages these existing EHR-S definitions and does not
attempt to create a redundant definition of an EHR-S.
0.3.2 How were the Functions Identified and Developed?

To achieve healthcare community consensus at the outset, the functions are described at a conceptual level,
providing a robust foundation for a more detailed work. Functions were included if considered essential in at
least one care setting. Written in user-oriented language, the document is intended for a broad readership.
Functional Granularity is a term used to describe the level of abstraction at which a function is represented.
Functions that are commonly grouped together in practice or by major systems have been consolidated where
appropriate; functions requiring extra or separate language or involving different workflows have been kept
separate where appropriate. For example, decision support is maintained as a separate section, but mapped to
other key sections, to indicate the "smart" function behind an action. All of the functions could be expanded into
more granular elements but a balance between a usable document and an unwieldy list of functions has been
agreed upon. The goal of determining an appropriate level of functional granularity at this time is to present
functions that can be easily selected and used by readers of this standard, but that are not so abstract that
readers would need to create a large number of additional functions within each function.
Although the determination of functional granularity is a relatively subjective task, systematic evaluation of each
function by diverse groups of industry professionals has resulted in a level of granularity appropriate for this
EHR-S Functional Model. Every attempt has been made to provide supporting information in the functional
descriptions to illustrate the more granular aspects of functions that may have been consolidated for usability
purposes.
Keeping with the intent of this EHR-S Functional Model to be independent with regard to technology or
implementation strategy, no specific technology has been included in the functions, but may be used in the
examples to illustrate the functions. Inclusion of specific technologies in the examples does not endorse or
support the use of those technologies as implementation strategies.
The EHR-S Functional Model and specific functions have been widely reviewed by healthcare providers,
vendors, public health agencies, regulatory and accreditation bodies, professional societies, trade associations,
researchers and other stakeholders. This Standard reflects input from all these reviewers.

Page vi HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
Health Informatics — HL7 Electronic Health Record-System
Functional Model, Release 2 (EHR FM)

1 Scope

The HL7 EHR System Functional Model provides a reference list of functions that may be present in an Electronic
Health Record System (EHR-S). The function list is described from a user perspective with the intent to enable
consistent expression of system functionality. This EHR-S Functional Model, through the creation of Functional
Profiles for care settings, realms, services and specialties, enables a standardized description and common
understanding of functions sought or available in a given setting (e.g., intensive care, cardiology, office practice
in one country or primary care in another country).
1.1 EHR-S Functional Model Scope

The HL7 EHR-S Functional Model defines a standardized model of the functions that may be present in EHR
Systems. From the outset, a clear distinction between the EHR as a singular entity and systems that operate on
the EHR – i.e., EHR Systems is critical. This Standard makes no distinction regarding implementation - the EHR-
S described in a Functional Profile may be a single system or a system of systems. Within the normative sections
of the Functional Model, the term “system” is used generically to cover the continuum of implementation options.
This includes “core” healthcare functionality, typically provided by healthcare-specific applications that manage
electronic healthcare information. It also includes associated generic application-level capabilities that are
typically provided by middleware or other infrastructure components. The latter includes interoperability and
integration capabilities such as location discovery and such areas as cross application workflow. Interoperability
is considered both from semantic (clear, consistent and persistent communication of meaning) and technical
(format, syntax and physical connectivity) viewpoints. Further, the functions make no statement about which
technology is used, or about the content of the electronic health record. The specifics of 'how' EHR systems are
developed or implemented is not considered to be within the scope of this model now or in the future. This EHR-
S Functional Model does not address or endorse implementations or technology, nor does it include the data
content of the electronic health record.
Finally, the EHR-S Functional Model supports research needs by ensuring that the data available to researchers
follow the required protocols for privacy, confidentiality, and security. The diversity of research needs precludes
the specific listing of functions that are potentially useful for research.
This Functional Model is not:
a messaging specification
an implementation specification
a conformance specification
an EHR specification
a conformance or conformance testing metric
an exercise in creating a definition for an EHR or EHR-S
It is important to note that the EHR-S Function Model does not include a discussion of clinical processes or the
interaction of the healthcare actors. However, ISO 13940 Health Informatics – System of Concepts to Support
Continuity of Care, is an international standard that does outline key principles and processes in the provision of
healthcare. It is recommended that users of the EHR-S FM refer to this standard for clinical processes that EHR
systems support.
This EHR-S Functional Model package includes both Reference and Normative sections.
Status Description
Reference Content of the EHR-S Functional Model Package that contains information which clarifies
concepts or otherwise provides additional information to aid understanding and comprehension.
Reference material is not balloted as part of the standard.
Normative Content that is part of the EHR-S Functional Model which HL7 committee members and
interested industry participants have formally reviewed and balloted following the HL7
procedures for Balloting Normative Documents. This HL7 developed Functional Model
document has been successfully balloted as a normative standard by the HL7 organization.
Table 1: Normative Status Types

Each section within this document is clearly labeled "Normative" if it is normative. For example, in section 5
(Overview) section 5.3 is normative. In section 7, Conformance Clause; sections 7.1 through 7.6 are normative.
In the external Annex A, Function List, the Function ID, Function Name, Function Statement, and Conformance
Criteria components are Normative in this Functional Model.

2 Normative References

The following referenced documents are indispensable for the application of this document.

ASTM E1769:1995, Standard guide for properties of electronic health records and record systems

HL7 Fast Health Interoperable Resources (FHIR), Release 4, January 2019

HL7 FHIR Record Lifecycle Event Implementation Guide, part of FHIR Core Release 4, January 2019

ISO 13606:2018, Health Informatics – Electronic health record communication, Parts 1-5

ISO 13940:2015, Health Informatics – System of concepts to support continuity of care

ISO 16527:2017, Health Informatics – HL7 personal health record system functional model, Release 1

ISO 20514:2005, Health Informatics – Electronic health record – definition, scope and context

ISO 21089:2018, Health Informatics – Trusted End-to-End Information Flows

3 Terms and Definitions

3.1
access control
a means of ensuring that the resources of a data processing system can be accessed only by authorized entities
in authorized ways

3.2
base functional profile
an existing domain or companion functional profile from which new functional profiles are created/derived

3.3
conformance
the fulfillment of a product, process, or service of specified requirements

3.4
conformance criteria
requirements indicating the behavior, action, capability that constitutes implementation of the function

3.5
conformance clause
a section of a specification that defines the requirements, criteria, or conditions to be satisfied in order to claim
conformance

3.6
conformance statement
a description of the function in an EHR system that have been implemented. It reflects the degree to which an
EHR system has met the functionality has met the functional profile’s requirements and may include optional
functions and information

3.7
derived functional profile
a functional domain or companion profile that is created from a base functional profile, (i.e., child functional domain
profile to children’s hospital domain profile)

Page 2 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
3.8
extension
the ability for an EHR-S to incorporate additional functionality beyond what is defined in the Functional Profile

3.9
functional profile
a subset of the Functional Model, in which functions have been designated (sometimes in varying degrees) for
certain EHR systems or healthcare delivery settings or narrow operation requirements

3.10
informative functional profile
a registered functional profile that has successfully completed formal public scrutiny via the HL7 consensus
process

3.11
inherited criterion
all the conformance criteria listed in a parent function will be inherited by all its children functions

3.12
registered functional profile
a functional profile that has successfully completed HL7 EHR Work Group registration process and review

3.13
situational criterion
criterion that is required if the circumstances given are applicable (IF/Then or Dependent SHALL)

4 Overview and Definition of the Functional Model (Normative)

The EHR-S Functional Model is composed of a list of functions, known as the Function List, which is divided into
seven sections: Overarching, Care Provision, Care Provision Support, Population Health Support, Administrative
Support, Record Infrastructure and Trust Infrastructure.

Overarching (OV)

Care Provision (CP)

Care Provision Support (CPS)

Population Health Support (POP)

Administrative Support (AS)

Record Infrastructure (RI)

Trust Infrastructure (TI)

Figure 1: Function List Sections

Within the seven Sections of the Functional List the functions are grouped under header functions which each
have one or more sub-functions in a hierarchical structure.

4.1 Sections of the Function List

Below is a summary description of each of the seven sections:

• Overarching: The Overarching Section contains functions and conformance criteria that apply to
complete EHR Systems and which are typically included in all EHR-S FM compliant profiles.
 • Care Provision: The Care Provision Section contains those functions and conformance criteria
that enable direct care to a specific patient and facilitate hands-on delivery of healthcare. The
functions are general and are not limited to a specific care setting and may be applied as part of an
Electronic Health Record supporting healthcare clinics, hospitals, services, specialties, acute, post-
acute and long-term care settings.
• Care Provision Support: The Care Provision Support Section focuses on functions and
conformance criteria supporting the provision of care. This section is organized generally in
alignment with Care Provision Section. For example, CP.4 (Manage Orders) is supported directly
by CPS.4 (Support Orders).
• Population Health Support: The Population Health Support Section focuses on functions and
conformance criteria supporting the prevention and control of disease among a group of people
(as opposed to the direct care of a single patient). This section includes functions to support input
to systems that perform medical research, promote public health and improve the quality of care to
a population.
• Administrative Support: The Administrative Support Section focuses on functions and conformance
criteria enabling the management of clinical practice and facilitating administrative and financial
operations. This includes management of resources, workflow and communication with patients
and providers as well as the management of non-clinical administrative information on patients and
providers.
• Record Infrastructure: The Record Infrastructure Section consists of functions and conformance
criteria describing how an EHR system manages an EHR record, particularly those functions vital
to managing the lifecycle of EHR record entries (such as origination/retention, attestation,
amendment/update, access/use, translation/transformation, transmittal/disclosure, receipt, de-
identification, archive…) and record entry lifespan (persistence, indelibility, continuity, audit,
encryption). RI functions are core and foundational to all other functions of the EHR-S FM (CP,
CPS, POP, AS).
• Trust Infrastructure: The Trust Infrastructure Section consists of functions and conformance criteria
common to an EHR System infrastructure, particularly those functions foundational to system
operations, security, efficiency and data integrity assurance, safeguards for privacy and
confidentiality, and interoperability with other systems. TI functions are core and foundational to all
other functions of the EHR-S FM (CP, CPS, POP, AS and RI).

Page 4 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
4.2 Functional Profiles

While the Functional Model contains all reasonably anticipated EHR-S functions, it is not itself intended as a list
of all functions to be found in a specific EHR-S or implementation thereof. Functional Profiles offer a method to
constrain EHR-S FM functions and conformance criteria to an intended use.
In the aggregate, the EHR-S FM is intended to include the superset of functions from which a profile subset can
be generated. This subset illustrates what is needed within an EHR-S. Only a subset of all EHR-S FM functions
will apply to any particular EHR-S Functional Profile (FP).

Profiles

Overarching (OV)

Care Provision (CP)

Care Provision Support (CPS)

Population Health Support (POP)

Administrative Support (AS)

Record Infrastructure (RI)

Trust Infrastructure (TI)

Figure 2. Profiling from the EHR-S FM.

Figure 2 shows that a profile would include all 7 sections of the Functional Model, however it may not be
necessary to include all the functions and criteria within each section. A profile may include additional functions
and criteria to meet the requirements of the particular profile domain or subject area.
The Conformance Clause is a high-level description of what is required of profiles and implementations. It, in
turn, refers to other parts of the standard for details. The Conformance Clause describes concepts critical to the
understanding and implementation of the Functional Model, such as: ‘What is a profile? What are Conformance
Criteria? Or how do you know what is mandatory versus optional?. A Conformance Clause can also provide a
communication between the implementers (producers) and users (buyers) as to what is required, and gives
meaning to the phrases, “conforming profile” and “conforming EHR system”. Additionally, it serves as the basis
for inspection, testing and/or certification activities which may be performed by organizations external to HL7.
Refer to the Conformance Clause, section 7, for additional information related to the rules for selecting and adding
Conformance Criteria in the development of a Functional Profile.

4.3 EHR-S Function List Components

The EHR-S Function List is a list (superset) of functions organized into discrete sections. Functions describe the
behavior of a system in user-oriented language so as to be recognizable to the key stakeholders of an EHR-S.
EHR-S functions can be used to:
• Describe end user defined benefits such as patient safety, quality outcomes and cost efficiencies in terms of
standard EHR-S functions.
• Promote a common understanding of EHR system functions upon which developers, vendors, users and
other interested parties can plan and evaluate EHR system designs and implementations.
• Provide the necessary framework to drive the requirements and applications of next level standards, such
as EHR content, coding, information models, constructs and interoperability for information portability
between sub-systems of an EHR system and across EHR systems.
• Establish a standards-based method by which each realm (country) can apply these EHR system functions
to care settings, services, specialties, other uses and priorities.
• Inform those concerned with supporting subsequent use of data initially collected for the purpose of care
(also known as “secondary use”) on what functions can be expected in an EHR system.
• Inform those concerned with supporting realm-specific health information infrastructure on what functions
can be expected in an EHR Systems.

Each function in the HL7 EHR-S Functional Model is identified and described using a set of elements or
components as detailed below.
ID Type Name Statement Description Conformance Criteria
CP.1 H Manage Manage the Patient Clinical History lists
Clinical patient's clinical are used to present
History history lists succinct “snapshots” of
used to present critical health information
summary or including patient history;
detailed allergy intolerance and
information on adverse reactions;
patient health medications; problems;
history. strengths; immunizations;
medical equipment/
devices; and patient and
family preferences.
CP.1.4 F Manage Create and A problem list may include,
Problem maintain but is not limited to chronic
List patient-specific conditions, diagnoses, or
problem lists. symptoms, injury/poisoning
(both intentional and
unintentional), adverse
effects of medical care
(e.g., drugs, surgical),
functional limitations, visit
or stay-specific conditions,
diagnoses, or symptoms…
CP.1.4 C 1. The system SHALL provide the
ability to manage, as discrete
data, all active problems
associated with a patient.
CP.1.4 C 2. The system SHALL capture
and render a history of all
problems associated with a
patient.
CP.1.4 C 3. The system SHALL provide the
ability to manage relevant dates
including the onset date and
resolution date of problem.
Table 2: Function List Example

4.3.1 Function ID (Normative)

This is the unique identifier of a function in the Function List (e.g., CP.1.1) and uniquely identifies the function.
The Function ID also serves to identify the section within which the function exists (CP = Care Provision Section)
and the hierarchy or relationship between functions (CP.1.1 is at the same level as CP.1.2, CP.1.1 is also a parent
of CP.1.1.1 and child of CP.1. In many cases the parent is fully expressed by the children. NOTE: For a detailed
discussion and graphic of the parent and child relationship, see 6.6.1 Hierarchical Structure in Chapter 6,
Conformance Clause.)
4.3.2 Function Type (Reference)

This is an indication of the line item as being a Header (H), Function (F) or Conformance Criteria (C). The Tag
(T) is used to identify a new section in the spreadsheet and its related functions in the spreadsheet. A Tag has
no directly associated Functions or Criteria.
4.3.3 Function Name (Normative)

This is the name of the Function and while expected to be unique within the Function List; it is not recommended
to be used to identify the Function without being accompanied by the Function ID.
Example: Manage Medication List
Page 6 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
4.3.4 Function Statement (Normative)

This is a brief statement of the purpose of this function. While not restricted to the use of structured language
that is used in the Conformance Criteria (see below); the Statement identifies the purpose and scope of the
function.
Example: Create and maintain patient-specific medication lists.
4.3.5 Description (Reference)

This is a more detailed description of the function, including examples if needed.

Sample Description: Medication lists are managed over time, whether over the course of a visit or stay, or the
lifetime of a patient. All pertinent dates, including medication start, modification, and end dates are stored. The
entire medication history for any medication, including alternative supplements and herbal medications, is
viewable. Medication lists are not limited to medication orders recorded by providers, but may include, for example,
pharmacy dispense/supply records, patient-reported medications and additional information such as age specific
dosage.
4.3.6 Conformance Criteria (Normative)

Each function in the Function List includes one or more Conformance Criteria. Conformance Criteria, which exist
as normative language in this standard, define the requirements for conforming to the function. The language
used to express a conformance criterion is highly structured with standardized components with set meanings.
The structured language used to define Conformance Criteria in the Function List are further specified in the
Conformance Section 7 and Glossary Section 8.

5 Anticipated Uses (Reference)

The HL7 International community supports development of Functional Profiles (FPs), which may be realm
(country) specific specifications (i.e., tailored functional requirements) built off the base EHR-S FM Standard.
There are a range of FPs developed and balloted by HL7 International or its national affiliates. These FPs
designate a subset of functions from the base EHR-S FM for use in specific care settings (e.g., Ambulatory Care),
services or specialties (e.g. Behavioral Health) or specify cross-cutting characteristics of EHR systems and/or
records (e.g. the Records Management and Evidentiary Support). Balloted, approved and published FPs, based
on the EHR-S FM, are available in the HL7 International library of Standards.

5.1 Development Approach: Functional Profiles

A “Functional Profile" is a selected set of functions applicable for a particular purpose, realm (country), domain,
care setting, service or specialty.
It is not anticipated that any system or implementation will conform to all functions and conformance criteria set
forth in the base EHR-S FM. Rather EHR systems or implementations may conform to one or more Functional
Profiles.
For more information about creating, registering, and balloting Functional Profiles, see Conformance Section 7.
One might create a Functional Profile to support a business case for EHR-S use by selecting an applicable subset
of functions from the based EHR-S FM list of functions, in effect constraining the model to meet specific
requirements. For example, a Functional Profile may be created by a purchaser, to specify requirements; by a
vendor, to specify capabilities of a system design; or by any person/entity wishing to stipulate a desired subset of
functions for a particular purpose, for example, functions to support a care setting within a particular realm.
Readers may wish to focus on sections of the FM that are most relevant for their purpose of EHR-S use. For
example, a clinician might read the Care Provision and Care Provision Support sections very closely, while
technical specialists might focus especially on Record and Trust Infrastructure sections. Within an organization,
it might be helpful to designate responsibility for reviewing different FM sections among staff with different
responsibilities and expertise for use and support of the EHR system
Three vignettes are included here to help readers in different positions or organizations envision how they would
study, and ultimately utilize the EHR-S Functional Model.
5.1.1 Scenario 1 – Group Practice

Dr. Smith is part of a 50-person group practice. The practice currently has a clinical information system that
provides billing, scheduling, and other administrative support. For several reasons, it will need to be upgraded
or replaced within 2 years. It does not include electronic health records. Dr. Smith and interested colleagues
review an Ambulatory Care registered profile to see how the use, setting and scenario illustrate the EHR functions
related to their practice; they look at the Ambulatory Care prioritization of the individual functions that a group of
experts working with HL7 have identified. With a good understanding of what the EHR functions would mean for
their practice, Dr. Smith and several other providers then focus on the Care Provision and Care Provision Support
sections, while clinic administration staff look at the Administrative Support section, while the technical support
staff look at the Record and Trust Infrastructure sections. They all meet to discuss their conclusions. They plan
to use the list of functions in discussions with vendors about their next EHR system, recognizing that some
functions may not yet be available.
5.1.2 Scenario 2 - Hospital

Mr. Jones is the Chief Informatics Officer in a large hospital organization Their IT system was installed two years
ago and includes patient tracking and ordering components; it was upgraded for compliance with United States
HIPAA (Health Insurance Portability and Accountability Act). It does not include clinical decision support,
performance monitoring, or public health reporting. Mr. Jones asks the Chief Medical Officer to organize a review
of the HL7 EHR-S FM while his team also reviews it. They both begin by looking at an Acute Care Functional
Profile to see how a group of experts working with HL7 have identified how an EHR-S could be used within a
hospital. The scenario and prioritization of the individual functions is helpful. The CMO and several doctors and
senior nurses review the Care Provision and Care Provision Support sections of the EHR-S Functional Model
Acute Care profile; the CIO and his team focus on the Record and Trust Infrastructure sections but also look at
the Care Provision and Care Provision Support sections. A small team of providers and IT staff meet to discuss
their conclusions. They plan to use the list of functions in discussions with vendors about adding decision support,
performance monitoring, and public health reporting to their existing system, recognizing that their budget will
only allow very limited expansion in the near term.
5.1.3 Scenario 3 - IT Vendor

Ms. Green is the head of the clinical systems division of a large health IT company. Their product line includes
both dedicated EHR systems and integrated systems that include an EHR. Their EHR and integrated systems
have some decision support for medication ordering, but no performance monitoring/reporting functions. While
most of their clients are larger provider organizations and hospitals, they are planning to expand into the small
practice and home health markets with a simple, less expensive clinical system. In anticipation of HHS’s
implementation of the Merit-Based Incentive Payment System (MIPS), which provides financial incentives for
providers who use IT to track patients, the company wants to add a range of functionality to its products that
would meet or exceed these requirements. Ms. Green asks her staff to review the entire HL7 EHR-S FM package,
and also review applicable care setting Functional Profiles. Based on these examples, they determine that they
could add a relatively small number of functions to various products to be able to offer superior products for
current and future clients. They see value in the EHR-S FM for their discussions with their clients about upgrades
or new purchases.

5.2 Examples of Current Use

5.2.1 Functional Profile for Clinical Research based on the EHR-S FM

Below is the text of a November 2009 HL7 Press Release demonstrating industry use:

Ann Arbor, Michigan, U.S.A.–November 5, 2009– Health Level Seven International® (HL7®), the global
authority for interoperability and standards in healthcare information technology with members in 57
countries, today announced it has published the healthcare industry’s first ANSI (American National
Standards Institute)-approved standard that specifies the functional requirements for regulated clinical
research in an electronic health record system (EHR-S). The HL7 EHR Clinical Research Functional
Profile for EHR systems is based upon the HL7 EHR Work Group’s EHR System Functional Model
Release 1, which is also an ANSI-approved American National Standard.

The EHR Clinical Research Functional Profile defines high-level requirements critical for using
electronic health record data for regulated clinical research, and provides a roadmap for integrating the
information environment that must support both the patient care and the downstream clinical research
processes. According to Donald Mon, PhD, co-chair of the HL7 EHR Work Group and member of the
HL7 Board of Directors, “This profile is an excellent demonstration of how important functional
requirements for secondary data use, such as clinical research, can be integrated into the patient care
work flow and documented in EHR systems.” Pharmaceutical, biotechnology, clinical research
technology vendor, healthcare technology vendor, and federal regulatory stakeholders from the United
States and the European Union collaborated for two years to identify and address a broad list of data
protection, regulatory and ethical research requirements. The EHR Clinical Research Functional Profile
is also a resource for the Certification Commission for Healthcare Information Technology (CCHIT)
Page 8 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
 Clinical Research Work Group as they define new clinical research certification criteria for EHR
systems. This functional profile will be complemented by the EHR-Clinical Research interoperability
specification, currently being developed by the Health Information Technology Standards Panel
(HITSP). Additionally, Dr. Rebecca Kush, President and CEO of the Clinical Data Interchange
Standards Consortium (CDISC), commented that “CDISC is pleased to be a collaborator and to
contribute clinical research standards and eSource Data Interchange concepts towards these initiatives.
The ultimate goal is to accelerate the pace at which research informs healthcare for the benefit of
patients and this functional profile contributes to the achievement of that goal.”

5.2.2 AHRQ adopts Health Level Seven International (HL7) Child Health Functional Profile
Specification, Release 1 and incorporates key functionalities in the Children’s Electronic Health Record
Format
Below is an excerpt from AHRQ’s Children's Electronic Health Record Format - https://healthit.ahrq.gov/health-
it-tools-and-resources/pediatric-resources/childrens-electronic-health-record-ehr-format

“The Children’s Electronic Health Record (EHR) Format was developed to bridge the gap between the
functionality present in most EHRs currently available and the functionality that would more optimally
support the care of children. Specifically, the Format provides information to EHR system developers and
others about critical functionality, data elements, and other requirements that need to be present in an
EHR system to address health care needs specific to the care of children, especially those enrolled in
Medicaid or the Children’s Health Insurance Program (CHIP). To address these needs, the Format
includes a minimum set of data elements and applicable data standards that can be used as a starting
point or checklist for EHR developers seeking to create a product that can capture the types of health
care components most relevant for children….The Children’s EHR Format contains portions of the Health
Level Seven International (HL7®) Child Health Functional Profile Specification, Release 1, and
modifications thereof, developed by HL7, the copyright of which is owned by HL7. Portions of the Format
that contain excerpts from the HL7 Child Health Functional Profile are identified in the Provenance Field…”

See the link below to access a copy of the “Children’s EHR Format”
- https://ushik.ahrq.gov/mdr/portals/cehrf?system=cehrf

5.2.3 Linking clinical content descriptions to the EHR-S FM (Reference)

HL7 has ongoing initiatives to link clinical content descriptions to functions and criteria in the EHR-S FM. This
clinical content linkage can be helpful input to developers of EHR-systems. Examples of these clinical content
descriptions include the Domain Analysis Models (DAMs) and Detailed Clinical Models (DCMs). Each of these
examples can be linked to applicable sections of the EHR-S FM For example, a Care Plan DAM which can be
linked to a care planning functions in the Care Provision and Care Provision Support sections in the EHR-S FM.
At a more detailed level, the DCMs, can be linked to specific functions in the EHR-S FM or EHR-S Functional
Profiles. For example, a DCM for the Apgar score can be linked to CP.3.1 Conduct Assessments and CPS 3.1
Support for Standard Assessments. Another example is using the DCM for blood pressure with CP.3.2 Manage
Patient Clinical Measurements.
On the level of data elements, which can be specified in a DCM, or in a data table, the linkage to EHR-S FM is
usually through an individual criterion. For example, CP.3.2 Manage Patient Clinical Measurements, for example
criterion ‘The system SHALL provide the ability to capture patient vital signs including blood pressure,
temperature, heart rate, and respiratory rate, as discrete elements of structured or unstructured data.
Finally, similar to EHR-S FM Function TI.4 Standard Terminology and Terminology Services, a Function is
created for Clinical Models and Clinical Models Services. The function name is 'TI.10 Standard or Preferred
Clinical Models and Clinical Model Services'. There are three child functions:
- TI.10.1 Standard or Preferred Clinical Models. The statement is; Employ approved standard or
Preferred Clinical Models to ensure structured data correctness and to enable semantic interoperability
(both within an enterprise and externally). Support a standard or Preferred Clinical Model.
- TI.10.2 Maintenance and Versioning of Standard or Preferred Clinical Models. The statement is;
Enable version control according to scope of practice, organizational policy, and/or jurisdictional law to
ensure maintenance of utilized standard or preferred clinical models. This includes the ability to
accommodate changes to clinical models as the source clinical model undergoes its update process.
Such changes need to be cascaded to clinical content embedded in templates, custom formularies,
etc., as determined by existing policy.
- TI.10.3 Clinical Model Mapping; The statement is; Map or translate one clinical model to another as
needed by local, regional, national, or international interoperability requirements.
6 Conformance Clause

6.1 Introduction (Reference)

Sections 6.2 through 6.7 are the HL7 EHR Work Group approved Conformance Clauses. As important
background on conformance, please note the following:
1. This Conformance Clause defines what it means to conform to the EHR-S Functional Model.
2. Conformance to the Functional Model is defined for functional domain profiles, and for functional
companion profiles. An EHR system does not directly conform to the Functional Model, rather it
conforms to one or more Functional Profiles.
3. Conformance criteria are associated with functions in the EHR-S Functional Model.
4. This Conformance Clause does not specify inspection, testing or validation procedures to determine
whether an EHR system conforms to a EHR-S Functional Profile or whether a Functional Profile
conforms to the EHR-S Functional Model.
6.2 Scope and Field of Application (Normative)
This Conformance Clause defines the minimum requirements for Functional Profiles claiming conformance to the
EHR System Functional Model. It also identifies how EHR systems achieve conformance to the Functional Model,
which is via the system’s conformance to a particular functional domain profile, multiple Functional Profiles, or
combination of domain and companion profiles. This clause specifies:
5. The purpose, structure, and use of conformance criteria that are to be included in the Functional Model
and conforming Functional Profiles,
6. The rules for defining conforming Functional Profiles of the Functional Model,
7. The relationship between Functional Profiles and EHR systems,
8. Sample Conformance Clauses and use case scenarios,
9. Guidance on the conformance requirements that a Functional Profile might levy on EHR systems,
10. Guidance on the purpose and use of an EHR system Conformance Statement.
While the conformance requirements for Functional Profiles can be found in this clause, they necessarily
reference the Functional Model and other sources.
This Conformance Clause does not specify inspection, testing or validation procedures to assess a Functional
Profile’s conformance to the Functional Model. It also does not specify inspection, testing or validation procedures
to determine whether an EHR system conforms to a Functional Profile or matches the EHR System Conformance
Statement.

6.3 Concepts (Normative)

6.3.1 Functional Profiles

Creating a Functional Profile is a method for defining subsets of the Functional Model. A Functional Profile is a
specification which uses the Functional Model to indicate which functions are required, desired, or implemented
for certain EHR systems, healthcare delivery settings, or for other purposes (e.g., the functional profile for Records
Management and Evidentiary Support).
Functional Profiles can be created by healthcare community stakeholders with interest in using and/or providing
a Functional Profile for an EHR system. Functional Profiles can represent the functionality required and desired
for a realm (country/region), domain, care setting or service/specialty, or reflect the functionality incorporated in
a vendor’s EHR system.
(NOTE: During the process of creating a Functional Profile, it may be important to discuss clinical processes,
work flows and/or interaction(s) of the healthcare actors. The international standard ‘ISO 13940 System of
Concepts to Support Continuity of Care’ provides an outline of key principles and processes in the provision of
healthcare. We would highly recommend reviewing this standard as part of your work.)
There are two types of Functional Profiles. The Functional Domain Profile is the common type of profile used to
describe an EHR system for use in one or more care settings, or to describe an EHR system for use in a selected
realm (country/region) to meet the rules, regulations and standards applicable for that realm, to describe an EHR
system for use by a particular service or specialty, etc. The Functional Companion Profile is a type of profile that
must be paired with one or more Domain Profiles. The purpose of a Companion Profile is to add unique features
to an EHR System, such as for research or for evidentiary support. For example, many EHR systems in a clinic
environment do not need to support clinical research. But for a clinic that was supporting advanced research,
they might want an EHR system that was both capable of all of the expected functions for routine clinic patient
care activities, but also had unique features to support the needs for research reporting and clinical trials.
Once a Functional Profile is defined its functions (complying with conformance criteria) can be implemented within
EHR systems or it may trigger the creation of derived Functional Profiles. A derived Functional Profile is a

Page 10 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
Functional Profile that is created from an existing Functional Profile, inheriting FP functions and conformance
criteria. There are two types of derived Functional Profiles: Derived Domain FP and Derived Companion FP.
There are two types of mandatory inheritance in the EHR-S FM. All Functional Domain Profiles will inherit the full
set of functions in the EHR-S FM Overarching section and their related “SHALL” criteria. All criterion listed in a
parent function will be applicable to all the children of that parent function.
A formal HL7 process exists for registering and balloting Functional Profiles. Functional Profiles that are
submitted to the HL7 EHR WG with an attestation of conformance to Section 7: Conformance Clause of the HL7
EHR-S Standard and successfully complete review by the WG are designated as “Registered Functional Profiles”.
Registered Functional Profiles that undergo formal public scrutiny via the HL7 consensus process as an
Informative EHR TC ballot at the committee level will be designated as HL7 functional domain or companion
profiles. HL7 Functional Profiles are eligible to undergo full membership ballot via the HL7 consensus process.
6.3.2 Conformance Model

Conformance to the Functional Model is defined for Functional Profiles. A functional domain profile conforms
either (1) directly to the base EHR-S FM or (2) to another conforming functional domain profile. NOTE: All
functional domain profiles must include all the functions and “SHALL” criteria of the Overarching Chapter. An EHR
system does not conform directly to the Functional Model; rather, it conforms to a functional domain profile, or to
a domain profile in combination with selected companion profile(s). Thus, Functional Profiles claim conformance
to the Functional Model and EHR systems claim conformance to one or more conforming domain Functional
Profiles. An EHR system can also claim conformance to a domain Functional Profile, in combination with one of
more companion profiles. An EHR system cannot claim conformance to only a companion profile. Figure 3
(below) illustrates this relationship.

Figure 3 Conformance Relationships

6.3.3 Profile Traceability

Functional Profiles allow for added specificity and extensibility to the Functional Model with changes allowed to
the base FM functions and criteria. However, Section 6.6 (following) defines rules for these changes. It is also
required that any changes and additions be tracked. Two added columns in profiles accomplish this. One column
will document the unique source FM row number for each item in the new profile (or source profile for a derived
profile). The second column will provide codes for the type of changes from the source FM (or source profile).
Together, these two traceability columns will keep track of the origins of the functions or criteria – and whether it
is modified or unchanged from that within the FM or the source profile. This may be important when questions
arise as to where did it come from, why was it chosen or modified, etc. It can also be helpful to have traceability
back to the FM functions and criteria if and when revisions to a profile or for derived profile are needed to reflect
care setting, regulatory, technology changes – or a future new release of the base EHR-S FM.

6.4 Normative Language (Normative)

The EHR-S Functional Model (i.e., all chapters) contains normative, informative, and reference sections. In this
Conformance Clause section, the normative content defines how a Functional Profile achieves conformance to
the Functional Model.
The following keywords (i.e., normative verbs) SHALL be used to convey conformance requirements.
• SHALL – to indicate a mandatory requirement to be followed (implemented) in order to conform.
Synonymous with ‘is required to’.
• SHALL NOT – to indicate a prohibited action. Synonymous with ‘prohibited’.
• SHOULD – to indicate an optional recommended action, one that is particularly suitable, without
mentioning or excluding others. Synonymous with ‘is permitted and recommended’.
• MAY – to indicate an optional, permissible action. Synonymous with ‘is permitted’.
6.5 Conformance Criteria (Normative)
Every function in the Functional Model is associated with a set of conformance criteria. These conformance
criteria form the basis for determining whether the function has been implemented.
6.5.1 Criteria in the Functional Profile

Functional Profiles also have conformance criteria associated with functions in the Functional Profile. The
Functional Profile’s criteria are either (1) adapted from the Functional Model conformance criteria with
requirements or language specific to the purpose, care-setting, realm (country/region), domain, service or
specialty focus of the Functional Profile; or otherwise (2) inherited directly from Functional Model. Functional
domain and companion profiles MAY change Functional Model criteria to match the needs and priorities of the
Functional Profile’s constituency, e.g., by making it more specific, or changing it from ‘may’ or ‘should’ to ‘shall’.
Functional Profiles MAY change the criteria of a function to allow for alignment to realm specific nomenclature,
including language distinctions and implication of non-english translations. In these cases, the International
Organization for Standardization (ISO) country code (ISO 3166 Country Codes) SHALL be appended to the
function ID in the Functional Profile.
The functional domain profile SHALL NOT be made less restrictive than the Functional Model by changing ‘shall’
criteria to ‘may’ or ‘should’ criteria (The functional companion profile MAY be less restrictive that the FM by
ignoring ‘shall’ criterion). Functional domain and companion profiles MAY also add additional criteria.
6.5.2 ‘Dependent SHALL’ Criteria

Conformance criteria that contain the keyword ‘shall’ and a dependency on situational conditions are called
‘dependent shall’ criteria. The ‘dependent shall’ SHALL contain the phrase “in accordance with scope of practice,
organizational policy, or jurisdictional law” or other appropriate grammatical tie-in words (e.g., ‘based on’ rather
than ‘in accordance’). A ‘dependent shall’ criteria is used to highlight only these (i.e., scope of practice,
organizational policy or jurisdictional law) conditions. A ‘dependent shall’ criterion is a mandatory criterion for
Functional Profiles and situational for EHR systems. Specifically,
• All functional domain profiles SHALL inherit the criterion if the function appears in the Functional Profile.
• An EHR system is required to implement the Dependent SHALL criterion only if the criterion is
applicable per the stated dependency in the Functional Model. (If the Dependent SHALL criterion is not
applicable to the profile, the developer of the profile may still use the criterion if desired.)
6.5.3 Referencing Other Criteria or Functions

There is often a link between functions and their criteria with other functions and criteria. For example, a given
function may depend on another function or on a specific criterion associated with another function.
A criterion in the Functional Profile that references another function in the Functional Profile SHALL reference
that function by indicating its name and ID, as “X.n.n (Name)”. If the referenced function is required to be
implemented, then all the ‘shall’ criteria of this referenced function apply. If the referenced function is a parent
with children, the reference must be explicit on whether the children are included in the reference, all or selected
ones. See the examples below:
• The system SHALL/SHOULD/MAY conform to TI.1.1 (Entity Authorization).
• The system SHALL/SHOULD/MAY conform to TI.2 (Audit) and all child functions.
• The system SHALL conform to CPS.4 Support Orders, and separate function(s) The systems SHALL
conform to CPS.4.3 Non-medication Orders. The systems SHALL conform to CPS.4.6 Support for
Referrals and all children functions.
Page 12 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
A criterion in the Functional Profile that references a specific criterion in another function SHALL reference that
function by rewriting the referenced criterion as one of its own and indicating the function and criterion number
from where it came (e.g. F#, CC3).

6.6 Functional Model Structure and Extensibility (Normative)

6.6.1 Hierarchical Structure

Functions MAY be contained (i.e., nested) within other functions. A nested function is a ‘child’ to its ‘parent’ (i.e.,
the function that contains it). A child SHALL always have a parent. A function that is not a parent to another
function is considered a ‘leaf’. Figure 2 illustrates this hierarchical structure.
The Functional Model is represented as a hierarchical list of functions, consisting of functional header parents,
functional header children and functional leaf functions. Headers include an ID, Name and “H” in the column
labeled “Type”. Parent and Child Headers MAY contain conformance criteria only if the criteria apply to all its
descendent functions (i.e., children, grandchildren, and leafs). Parent, Child and Leaf functions contain at a
minimum the following: ID, Name, Statement, Description, and Conformance Criteria and have a “F” in the “Type”
column. Conformance criteria listed in a parent function SHALL be inherited by all its children functions.
Conformance Criteria have a “C” in the “Type” column.

Figure 4 Portion of the Functional Model hierarchical structure

(Note: The numbering schema above reflects functions in the Care Provision chapter. For instance, CP.4.2 is
the function ‘Manage Medication Orders.)
Functional Profiles either:
• Select functions from the Functional Model for inclusion in the Functional Profile,
• Deem a function in the Functional Model as not applicable, thus do not select it for inclusion in the
Functional Profile, or,
• Add a new child function when it has been determined that there is no applicable function in the
Functional Model to represent a functional need in the Functional Profile.
6.6.2 Naming Convention

Functional Profiles SHALL NOT change the name or statement of a function except to allow for alignment to
realm specific nomenclature, including language distinctions and implication of non-english translations. In these
cases, the International Organization for Standardization (ISO) country code (ISO 3166 Country Codes) SHALL
be appended to the function ID in the Functional Profile. It is recommended that the HL7 Affiliate for the respective
realm coordinate with the profile development process to maintain a mapping of the Functional Model function
name and/or statement and the realm-adjusted name and/or statement.

6.6.3 Priorities

Functional Profiles indicate the importance and/or immediacy of a Functional Profile by associating a priority with
a function. Three priorities have been defined, Essential Now, Essential Future, and Optional.
• Essential Now indicates that the implementation of the function is mandatory, as of the profile issuance
date.
• Essential Future indicates that the implementation of the function is currently optional but will be
mandatory at some future time, which is specified by the Functional Profile
• Optional indicates that the implementation of the function is optional.
Any or all of these priorities SHALL be used in a Functional Profile. If the Essential Future priority is used, then
Functional Profiles are required to define the timeframe associated with implementing functions. A timeframe
MAY be a date, time allotment (e.g., year 2014 or 4 months after Functional Profile publication), or event (e.g.,
republication of this Functional Profile). A Functional Profile MAY define multiple timeframes for the Essential
Future priority. If multiple timeframes are defined, then the timeframe SHALL be used to qualify each occurrence
of the Essential Future priority (e.g., EF-2015, EF-2016).
6.6.4 Extensibility

To accommodate changes in technology as well as Functional Profiles’ needs, the Functional Model is designed
for extensibility, for functions and their related criteria. Incorporation of additional functions in the Functional
Profile beyond what is defined in the Functional Model is accommodated through a set of rules for adding new
functions as defined in Section 6.7.2.
Incorporation of additional criterion, changing the sequence of criterion and providing greater profile-specific detail,
beyond what is defined in the Functional Model, is accommodated through a set of rules for adding new criterion
or changing existing criterion as defined in Section 6.7.2.
6.7 Functional Profile Conformance (Normative)
A Functional Profile claiming conformance to the Functional Model SHALL meet all requirements specified in the
6.7.1 Rules for Functional Domain Profiles or in the 6.7.5 Rules for Functional Companion Profiles.
6.7.1 Rules for Functional Domain Profiles

Functional Domain Profiles SHALL claim conformance to the version of the EHR-S Functional Model from which
it was derived.

Functional Profiles claiming Functional Model conformance SHALL:

1. Identify the Functional Model with version/date, from which the Functional Profile is derived,
2. Include a description, version and issuance date of the Functional Profile,
3. Contain a Conformance Clause which
a) Defines the requirements that EHR systems must satisfy in order to claim conformance to the
Functional Profile,
b) Defines the requirements that Functional Profiles derived from the Functional Profile (i.e., derived
Functional Profiles) must satisfy in order to claim conformance to the Functional Profile.
c) Specifies that functions designated with the priority ‘Essential Now’ SHALL be implemented by
conformant EHR systems.
d) Specifies that functions designated with the priority ‘Essential Now’ SHALL be included in any
derived Functional Profiles.
e) If Essential Future is used, defines the meaning of ‘Essential Future’, including specifying the
timeframe for when these functions are required to be implemented.
f) Requires that at least one function, regardless of its priority, be implemented in order for an EHR
system to claim conformance to the profile.
4. Include all functions in the Overarching section of Function List as Essential Now and identify functions
from other sections of Function List of the Functional Model that are applicable to the functional
domain profile. For each identified function, indicate its priority (i.e., Essential Now, Essential Future or
Optional).
5. For each function, derive conformance criteria based on the Functional Model’s conformance criteria.
a) In the Functional Profile, there SHALL be at least one criterion for each function that is mandatory
(a ’shall’ criterion).
b) If there are ‘shall’ criteria (for the function in the Functional Model), then those criteria SHALL also
exist for the function (in the Functional Profile). Additionally, if the function is split (in the Functional
Profile), then the parent's ‘shall’ criteria SHALL appear in at least one child of that function.

Page 14 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 c) If, as yet there is no ‘shall’ criterion (for the function in the Functional Model), then at least one of
the ‘should’ or ‘may’ criterion SHALL be made mandatory, i.e., a ‘shall’ criterion.
d) Adhere to the rules for referencing functions or criteria in Section 6.5.3.
6. For any function in the Functional Model where one or more criteria are ‘dependent shall’ criteria, the
Functional Profile for that function SHALL
a) Replicate verbatim each ‘dependent shall’ in the Functional Profile, regardless of whether the
dependent situation applies or not.
b) When the dependent situation applies, create ‘shall’ criteria that apply the dependency to the
‘dependent shall’ criterion, resulting in one or more new, constrained versions of the ‘dependent
shall’ criterion.
c) State the specific scope of practice, organizational policy, and/or jurisdictional law which applies or
state why these dependencies do not apply.
7. Adhere to the rules for creating new functions in Functional Profiles in Section 6.7.2.
8. Adhere to the rules for creating and changing conformance criteria in Section 6.5.
9. Complete the two traceability columns, see Section 6.3.3, for any changes to functions or criteria, and
include the following codes for type of change: (N/C for no change; A for added; M for modified.).
10. Be structured in accordance with the structural requirements defined for the Functional Model in
Section 6.6.1.
11. Use the Glossary Action verbs for modifying or creating new conformance criterion.

Functional domain profiles claiming conformance to the Functional Model MAY:

1. Create additional functions according to the rules specified in Section 6.7.2.
2. Contain conformance criteria more specific and limited in scope than those of the Functional Model.
3. Replace the text ‘standard(s)-based’ found in some criteria with specific standards and/or
specifications named at the most discrete level of designation.
4. Change a ‘should’ criterion to a ‘shall’ or a ‘may’ criterion.
5. Change a ‘may’ criterion to a ‘shall’ or a ‘should’ criterion.
6. Ignore a ‘should’ or ‘may’ criterion in the Functional Model (i.e., not include it in the Functional Profile).
7. Add additional conformance criteria beyond those in the Functional Model.
8. Make the order of the conformance criteria significant (e.g., put all ‘shall’ criteria first).
9. Enforce common resolution of ambiguous semantics of the Functional Model.
10. Make the Functional Profile public (e.g., published on a web site) so interested parties can see/use it.
11. Submit the Functional Profile for registration review by the HL7 EHR Work Group.

Functional domain profiles claiming conformance to the Functional Model SHALL NOT:
1. Specify any requirements that would contradict or cause non-conformance to the Functional Model.
2. Modify the name or statement of any function in the Functional Model, except to allow for alignment
with realm specific nomenclature as specified in Section 6.6.2.
3. Change a mandatory conformance criteria to an optional criteria (i.e., replace the ‘shall’ within the
criteria to ‘should’ or ‘may’) of any function in the Functional Model.
4. Modify any requirements of a function not selected for the Functional Profile (i.e., all unselected
functions default to the Functional Model’s criteria. If a profiling group wants to change something,
they SHALL promote it into their Functional Profile).
6.7.2 Rules for Creating New Functions in Functional Profiles

If a function is not adequately specified for a Functional Profile or does not exist, the Functional Profile SHALL
only create new children, the new children can be parents or leafs . Figure 5 illustrates the addition of a new child
function.
 Figure 5 Creating a new function

The following rules specify the method for creating new functions.
1. Whenever possible, conformance criteria SHOULD be used to avoid creating a new function. This may
be done, for example, in cases where the original function’s conformance criteria are too broad: divide
the Functional Model’s or base Functional Profile’s inherited conformance criteria into two criteria in the
Functional Profile, one being mandatory and the other optional. If this is not possible, the creation of a
new child function and associated criteria is allowed if necessary to clearly define the profile
requirements.
2. When a ‘leaf’ function exists (a child that is not a parent) but is too broadly specified in the Functional
Model or base Functional Profile for conformance criteria to adequately constrain it, then the function
MAY be split as follows:
3. The original ‘leaf’ function is retained as the parent of its newly created children functions, or
4. The original ‘leaf’ function’s conformance criteria SHALL be distributed among its children functions.
5. When no candidate function exists to express the requirements of a Functional Profile, a new child
function MAY be created (e.g., adding a new kind of summary list under the summary list’s parent).
6. ‘Parent functions SHALL NOT be split. This preserves the structure of the underlying Functional Model
in the Functional Profiles.

Figure 6 Splitting a function

If new children functions are created by a Functional Profile that is balloted or registered, these new functions will
be captured by the HL7 EHR WG and tracked for review. The EHR TC WILL use these new functions and
related criterion as input and candidates for changes to the Functional Model (e.g., inclusion, relaxation of
conformance criteria). The EHR WG MAY maintain a file of functions and criterion reviewed and rejected for
inclusion in a future version of the FM.

Page 16 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 Figure 7 Adding a new child function

Function IN 4.4 is added as a new child which is a sibling to IN 4.1, IN 4.2, and IN 4.3..

6.7.3 Rules for Derived Functional Profiles

Derived functional domain profiles claiming conformance to one or more base functional
domain profiles SHALL:
1. Adhere to all the rules for Functional Domain Profiles as specified in Section 6.7.1.
2. Adhere to the rules for creating new functions as specified in Section 6.7.2, if not prohibited by the
base Functional Profile.
3. Identify the base Functional Profiles from which it is derived.
4. For each function inherited from a base Functional Profile, retain and not change mandatory
conformance criteria to optional conformance criteria.
6.7.4 Conformance Statement

Functional Profiles MAY want to require that a conformance statement be produced for systems claiming
conformance to the profile. A Conformance Statement provides information about an EHR system, by presenting
in a uniform manner the functions that have been implemented by the EHR system. A blank (i.e., yet to be
completed) Conformance Statement typically takes the form of a questionnaire or checklist, to be completed for
each EHR system.
A Conformance Statement provides a concise summary of a Functional Profile. It follows a standard layout, thus
providing EHR system vendors and users a quick overview of the Functional Profile’s functions. Moreover, it can
also be used to highlight optional functions and capabilities supported by the EHR systems as well as document
any extensions (i.e., additional functionality beyond what is in the Functional Profile) or specializations that have
been made. An EHR system’s Conformance Statement provides information that can be used in assessing the
EHR system’s conformance to a specific Functional Profile. Additionally, organizations wishing to acquire an
EHR system MAY produce a Conformance Statement to indicate the functions that are required and/or desired
in an EHR system
Functional Profiles MAY want to include a blank, to be completed, sample Conformance Statement in order to
promote consistency among completed Conformance Statements. Conformance Statements can be useful in
determining the chances of interoperability between two EHR systems, by comparing the functions supported by
each EHR system. Additionally, for conformance testing purposes, it can be used to facilitate the selection of
tests that would be applicable to a particular EHR system being tested. For example, if an EHR system did not
implement functions designated as ‘Essential Future’, this would be evident in the Conformance Statement and
the tests for these functions (which are unimplemented) would not be performed.

6.7.5 Rules for Functional Companion Profiles

Functional Domain Profiles SHALL claim conformance to the version of the EHR-S Functional Model from which
it was derived. Functional Companion Profiles will follow the section 6.7.1 Rules for Functional Domain Profiles
and the section 6.7.3. Rules for Derived Functional Profiles, except for the exceptions and addition described
below:
Functional companion profiles claiming Functional Model conformance SHALL:
1. Adhere to section 6.7.2 for adding new functions,
2. Contain a Conformance Clause which
 a) Defines at least one functional domain profiles for which the companion profile can be linked that
EHR systems must satisfy in order to claim conformance, or state any specific domain profiles that
can or cannot be link to the companion profile,
b) Defines the requirement(s) that companion profiles derived from the base functional companion
profile (i.e., derived Functional Profiles) must satisfy in order to claim conformance to the functional
companion profile.
3. Include only functions being modified from the Overarching section of Function List as Essential
Now and identify functions from other section of Function List of the Functional Model that are
applicable to the functional companion profile. For each identified function, indicate its priority (i.e.,
Essential Now, Essential Future or Optional).
4. For each function, derive conformance criteria based on the Functional Model’s conformance criteria.
a) In the Functional Profile, there SHALL be at least one criterion for each function that is mandatory
(a ’shall’ criterion).
b) If there are ‘shall’ criteria (for the function in the Functional Model), then those criteria MAY also exist
for the function (in the functional companion profile) if changes. Additionally, if the function is split (in
the Functional Profile), then the parent's ‘shall’ criteria MAY appear in at least one child of that
function.
5. For any function in the Functional Model where one or more criteria are ‘dependent shall’ criteria, the
functional companion profile may elect to ignore the criterion, but if selected for that function SHALL
follow the rules of section 6.7.1.
Functional companion profiles claiming conformance to the Functional Model MAY:
1. Ignore a ‘shall’, ‘‘should’ or ‘may’ criterion in the Functional Model (i.e., not include it in the Functional
Profile).
There are no exceptions to section 6.7.5. for Derived Functional Companion Profiles

6.8 Use Cases and Samples (Reference)

6.8.1 Functional Profile Use Cases

Care setting
It is determined that a new care setting functional domain profile is needed to reflect the care setting specific
requirements. To help ensure widespread use and uniformity, the Functional Profile authors elect to undergo the
registration review followed by the HL7 consensus process (i.e., submitting the registered Functional Profile for
an “Informative” committee level ballot). If successful, the result will be designated a HL7 Informative Functional
Profile.
After looking at current list of HL7 informative Functional Profiles, the decision to create a new Functional Profile
is made. Each function in the EHR System Functional Model is examined and those that are relevant to the care
setting are chosen. From these functions, a small set of ‘core’ functions are selected as being essential and
mandatory. For each function, conformance criteria is developed either adapting the Functional Model
conformance criteria or in a few cases, using the Functional Model criteria as is. To complete the Functional
Profile, a description of the Functional Profile, including its intended use and audience as well as a Conformance
Clause is written. The Functional Profile is made public by publishing it on various web sites. Additionally, the
Functional Profile is submitted to HL7’s EHR Work Group for registration review, comment and ballot.

Community of interest derived functional domain and companion profiles

A community of interest (e.g., regional health information exchange network) wants a functional domain profile to
reflect their specific needs, and the needs of one of their members to support clinic research.
The Community of Interest doesn’t want to create a new Functional Profile from scratch. After looking at the list
of Registered Functional Profiles, they find an existing Functional Profile that is very close to what they want.
Using this Functional Profile as the base, they accept all the functions designated as ‘Essential Now’, reject
functions designated as ‘Future’ and add several more functions. For each function, they review the conformance
criteria and adapt the criteria to reflect their situational information.
For the one member of the community that needs to support research, a functional companion profile is created.
The Functional Profile is only needed to address the narrow areas of operation that are specific to research. So,
the group finds an existing companion profile for clinical research and modifies it to reflect the functions needed
for the specific disease state implications for the research activities of their member. Now the Community of
Reference can seek a vendor that can meet the needs of both the domain profile for the group and the companion
profile for the unique member.

Vendor functional domain profile and overarching conformance

A vendor with an EHR system wants to claim conformance to the EHR System Functional Model.

Page 18 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
The vendor identifies and lists all the functions that are in his product. The vendor adds a description and a
Conformance Clause (see samples in section 7.2). This is the vendor’s functional domain profile. If the vendor
has actually implemented all the functions listed, then this is equivalent to ‘Essential Now’ and these functions
are mandatory. If functions that are currently implemented and those that will be implemented in the future are
listed, then the Functional Profile is comprised of ‘Essential Now’ and ‘Essential Future’ and/or optional
functionality. Finally, the vendor adds conformance criteria for each function, inheriting some criteria directly
(without change) from in the Functional Model. But can also add new criterion to reflect added system features.
If all children of a function have the same new criterion, that criterion would be moved to the parent function as
overarching, and applicable to all the children. This is appealing in that, the vendor has the opportunity to list all
the current functionality and if desired, indicate future plans. In essence, this is similar to a vendor Conformance
Statement (a concept most vendors are already familiar with). A vendor may create multiple Functional Profiles.

6.8.2 Sample Functional Domain Profile Conformance Clauses

To aid Functional Profile developers in developing a Conformance Clause for their Functional Profile, as required
by Section 6.1 rule #3, the following examples are offered. Note: in these examples, the keywords ‘shall’, ‘should’,
and ‘may’ are capitalized and bold. This is a convention to draw attention to the keywords.

Conformance Clause for a care-setting functional domain profile

This functional domain profile defines the conformance requirements for EHR systems and derived functional
domain profiles. To conform to this Functional Profile, all ‘Essential Now’ functions SHALL be implemented.
‘Essential Now’ functions are considered mandatory functions. An EHR system is conforming if it implements all
the functions designated as ‘Essential Now’ and the mandatory conformance criteria associated with that function.
A derived functional domain profile is conforming if it follows the Rules for Functional Profiles.
Mandatory conformance criteria are indicated by the keyword ‘shall’. Optional conformance criteria are indicated
by the keywords ‘should’ or ‘may’.
EHR systems SHALL provide a Conformance Statement structured according to the rules and policies defined
in this Functional Profile.

Conformance Clause for an application

E-Application is an application that if included in a care-setting specific system SHALL conform to this Functional
Profile. E-Application is an application that has a defined set of attributes of which a minimum set of functions is
required of any system claiming this e-Application functionality. Two levels of conformance are designated:
• Core Conformance is comprised of the functions in the minimal set of functions that are designated
as ‘Essential Now’.
• Advanced Conformance comprises the entire minimal set of functions (i.e., all ‘Essential Now’ as
well as those designated ‘Essential Future’ functions).
A system MAY claim conformance to either the Core or Advanced Conformance levels, if it implements all the
mandatory criteria for the functions at the conformance level for which the claim is being made.
Functions designated with the priority ‘Essential Now’ indicate core functionality. These functions are required to
be implemented in order to claim conformance to E-Application, regardless of the level of conformance (i.e., core
or advanced) to which the claim is made.
Functions designated with the priority ‘Essential Future’ indicate advanced functionality. These functions are
required to be implemented in order to claim advanced level conformance. ‘Essential Future’ functions become
mandatory 18 months after publication of this Functional Profile and thus, required for immediate implementation
in order to claim conformance at either the core or advanced levels.

Conformance Clause for a vendor system functional domain profile

Conformance is defined for My-EHRsystem. All functions in this Functional Profile are mandatory, are deemed
as ‘essential now’, and SHALL be implemented in order to conform to this Functional Profile.

Conformance Clause for a community of interest functional companion

profile
Conformance is defined for BuyMyDiabetesEHR. To conform to this functional companion profile, all functions
labeled as ‘essential now’ SHALL be available and have been implemented, , and all functions labeled ‘essential
now’ in the Long Term Care or Ambulatory domain profile must also be available and implemented. Functions
labeled ‘essential future’ are optional, in that they are present for informational purposes only and MAY be
implemented in future functional companion profiles.
6.8.3 Interpreting and Applying a Conditional ‘SHALL’ (Reference)

Conformance criteria in the FM and those created can be structured in the simple format an Actor followed by
normative verb followed by action or property. For example: The system SHALL capture demographic information
as part of the patient record.
However, there are two conditional forms for which if the condition is true, then the following text must apply. One
is If/Then. If condition, then Actor followed by normative verb followed by action. If the condition is not met (i.e.,
false) then ignore the rest of the sentence. For example, IF data is exchanged with internal or external systems,
THEN the system SHALL conform to function IN 5.1 (Interchange Standards)
The other is a ‘Dependent Shall’ format. Actor followed by normative verb followed by action/interaction followed
by ‘according to scope of practice, organizational policy or jurisdictional law’. For example, "The system SHALL
enable EHR-S security administrators to grant authorizations to principals according to scope of practice,
organizational policy, or jurisdictional law."
The following example of a Functional Model ‘dependent shall’ criterion will be used to illustrate conditional
concepts throughout this section.
Functional Model criterion: The system SHALL enable EHR-S security administrators to
grant authorizations to principals according to scope of practice, organizational policy, or
jurisdictional laws.

6.8.4 General Concepts

The purpose of the ‘dependent shall’ is to allow Functional Profiles to constrain a Functional Model ‘shall’ criteria
based on situational conditions such as policy and legal implications. Specifically, the ‘dependent shall’ criteria
in the Functional Model are ‘shall’ criteria + a dependency, where the dependency is defined by:
• Scope of practice which applies to the EHRs user’s scope of practice and refers to best practices within
the user’s discipline – which may be care setting specific or not.
• Organizational policy which refers to a plan or course of action intended to influence and determine
decisions, actions, and other matters of a group of persons organized for a particular purpose within an
association and structure through which individuals cooperate systematically to conduct business.
• Jurisdictional law which refers to the territorial range of authority or control with the power, right, or
authority to interpret, apply, and declare the body of rules and principles governing the affairs of a
community and enforced by a political authority; a legal system.
The structure of the ‘dependent shall’ criteria in the Functional Model is the same as the ‘shall’ criteria except with
the addition of the phrase “in accordance with scope of practice, organizational policy or jurisdictional law” or
other appropriate grammatical tie-in words (e.g., based on rather than in accordance). Note that all three
dependencies are present in the Functional Model ‘dependent shall’ criteria. It is the Functional Profile that
narrows it to any one dependency or any combination of the three. Moreover, in the Functional Profile, the
specific scope of practice, organizational policy, and/or jurisdictional law which necessitates evoking the
‘dependent shall’ is explicitly identified.
For example: (derived from the Functional Model criterion above)
Functional Model criterion: The system SHALL enable EHR-S security administrators to
grant authorizations in accordance with HIPAA.
The difference between a ‘shall’ criterion and a ‘dependent shall’ criterion is shown in Table 3 below.
‘SHALL’ Criterion ‘Dependent SHALL’ Criterion
Be present in the Yes, either verbatim or Yes, verbatim.
Functional Profile modified (e.g., constrained If dependency exists, add additional criteria
or refined) reflecting the dependency.
Implemented by EHR Yes. Situational - only implement if the dependency
systems exists.
Specifically, EHR system does not implement the
‘dependent shall’ criterion (as copied from the
FM), but does implement additional ‘shall’ criteria
created to reflect the dependency.
Table 3 Differences between 'shall' and 'dependent shall'

6.8.5 Rationale for ‘Dependent SHALL’

The reason for using a ‘dependent shall’ in the Functional Model is to highlight these criteria and bring them to
the attention of the reader – both developers of Functional Profiles as well as other users. These criteria are
considered to be special cases, where there are one or more dependencies that affect these criteria, across

Page 20 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
multiple care settings. Using the ‘dependent shall’ ensures that developers of all Functional Profiles address the
criterion and consciously decide whether the criterion in question is applicable, based on the stated dependency.
Regardless of whether a dependency exists or not, the ‘dependent shall’ is copied verbatim into the Functional
Profile. The reasons for this are:
• Adherence to the rule that a ‘shall’ criterion is always inherited by the Functional Profile.
• Consistency with handling the ‘dependent shall’ under all conditions (i.e., when there are dependencies
and when there are not.
• Retention of the ‘dependent shall’ so that it is present for derived profiles.
• Retention of the ‘dependent shall’ so that it remains effective for this profile if future requirements
change (i.e., the dependency may not be applicable at this present time, but may be applicable in the
future due to changes in scope of practice, organizational policy or jurisdictional law.
6.8.6 How to Apply the ‘Dependent SHALL’

The way to interpret and apply a ‘dependent shall’ criterion in a functional domain profile is as follows:
• Copy the criterion into the Functional Profile.
• Review the criterion and determine if any of the dependencies are applicable to the Functional Profile.
• Dependency exists
If one or more dependencies are applicable to the Functional Profile (e.g., there are jurisdictional legal
requirements), add one or more ‘shall’ criteria that refine and further constrain the ‘dependent shall’ with
respect to the dependencies.
For the new criteria, add an explanation and/or citing for the dependency. For example, jurisdictional
legal requirements for this Functional Profile are defined by Federal Regulations (see 45 CFR Parts
160, 162 and 164 – The HIPAA Security Rule. The explanation or citing may be in an appendix. It is
likely that multiple criteria will reference the same explanation or citing.
Examples:
Functional Profile criteria
1. The system SHALL enable EHR-S security administrators to grant authorizations to principles in
accordance with HIPAA*.
2. The system SHALL enable EHR-S security administrators to grant authorizations for roles in
accordance with 42 CFR Part 2*.
Dependency Explanation
*For a U.S. realm Functional Profile, the Health Insurance Portability and Accountability Act of 1996
(HIPAA) as well as other jurisdictional legal requirements or other more stringent requirements would
be applied to ‘dependent shall’ criteria in the Functional Profile.
FM Dependency Applicability Functional Profile
Applicable?
Dependent Yes Mandatory Copy SHALL from FM
SHALL Mandatory Add additional criteria to reflect the
dependencies. Use ‘shall’.
Mandatory Add explanation or citing
Optional Add additional criteria derived from
‘dependent shall’. Use ‘shall’, ‘should’
or ‘may’.
Table 4 Summary of actions when dependency exists

2. No Dependency exists
If no dependency is applicable to the functional domain profile (i.e., there are no scope of practice,
organizational policies or jurisdictional legal requirements that apply), then document the rationale for
deciding that no dependencies apply. This explanation may be in an appendix. It is likely that this
explanation will apply to multiple ‘dependent shall’ criteria.
 FM Dependency Applicability Functional Profile
Applicable?
Dependent No Mandatory Copy SHALL from FM
SHALL Mandatory Add explanation
Optional Add additional criteria derived from
‘dependent shall’. Use ‘shall’, ‘should’
or ‘may’.
Table 5 Summary of actions for when no dependencies
• Add additional criteria – regardless of whether a dependency exists or not.
It is always permissible for a Functional Profile to add new criteria. Add new criteria that are derived
from the ‘dependent shall’. Use any keyword: ‘shall’, ‘should’ or ‘may’ (see Section 3) in these new
criteria.
Examples:
1. The system SHOULD enable EHR-S security administrators to grant authorizations to
principals.
2. The system MAY enable EHR-S security administrators to grant authorizations for
roles.
3. The system SHOULD enable EHR-S security administrators to grant authorizations
within contexts.
4. The system SHALL enable EHR-S security administrators to grant authorizations for
roles for organizations with 10 employees or more.

7 EHR System Conformance Claim via Self-Attestion

Claiming Conformance to a Functional Profile

When a software vendor/developer wishes to claim (for their product) conformance to a version of an EHR
Functional Profile the document claiming conformance should include the following information:
• The Name and Version of the standard that the software product is conformant with

• A full listing of the functions and conformance criteria that the software product is conformant with

In this manner any individual/organization evaluating the software product may easily determine its claimed
functionality.

The documentation detailing the process of determining conformance using a tool (for example, the software
was tested using the widget tool for specific conformance criteria) shall include the name of the tool, the version
of the tool and the date(s) of testing.

The process of claiming conformance to one or more Functional Profiles shall not be construed as creating a
new Functional Profile.

Should an end user (provider) find that a particular EHR-S product is not in compliance with a conformance
criterion claimed in the software statement of conformance, the end user (provider) should first address the
issue with the software developer. The end user (provider) may also communicate their findings with the HL7
EHR Work Group. The EHR WG shall not be responsible for validation of any statement of conformance or for
intervening with a software vendor/developer when a discrepancy is reported by an end user but may at its
discretion reach out to the EHR-S vendor/developer to discuss the identified issues.

Page 22 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
8 Glossary

8.1 Preface (Reference)

Portions of this Glossary Clause are classified as NORMATIVE, including the Action-Verb Structure Section (8.4).
See section by section labels. The Glossary is provided as guidance for preparing and interpreting HL7 Electronic
Health Record and Personal Health Record System Functional Models (EHR-S FM and PHR-S FM respectively)
and Functional Profile (FP) specifications and conformance statements. The goal is to promote clarity and
consistency when interpreting and applying language of the FMs.
This Glossary is intended to be international in application. However, each realm may want to adjust terms to
their own language.

8.2 Introduction (Normative)

The Health Level Seven International (HL7) EHR-S and PHR-S FM Glossary is an HL7 reference document that
provides a set of definitions and guidelines in order to ensure clarity and consistency in the terms used throughout
the FMs and in related FPs. The Glossary includes the definition of important terms used in the expression of
EHR and PHR system functionalities, and comprises a consensus-based list of Action-Verbs and specific
guidelines for constructing conformance criteria (CC).
Action-Verbs play a critical role in phrasing conformance criteria. Extensive efforts were made to categorize and
normalize Action-Verbs and to develop guidelines for creating clear and consistent CCs throughout the FMs and
in related FPs. Continuity with previous FM versions is provided by including Glossary terms that have been
deprecated, accompanied by suggestions for preferred replacement terms. Vigorous efforts were deployed to
reduce the ambiguities inherent in the use of human language; care was used to respect the fundamental meaning
of words and to avoid domain specific usage of terms.

8.3 Overview (Reference)

HL7’s EHR Work Group has unified glossaries for both the EHR-S and PHR-S FMs to ensure consistency. Each
FM has a unique focus and coverage in the health information domain with specific system functional
requirements, yet readers are often the same people. It is expected that FPs created within the context of either
FM will align with this Glossary. However, this Glossary will not provide definitions for all the terms used in FPs.
FPs will typically use context-specific, realm-specific, or specialized terms associated with their area of focus, and
may need to incorporate a complementary glossary for these special terms.
In the case where FPs are merged, care should be exercised to ensure that the same Action-Verbs are used with
the same meaning, and that identical meanings are conveyed with the same Action-Verb. It is recommended that
existing FPs be re-examined and updated to closely align with the current set of Action-Verbs.
Some common terms and Action-Verbs have not been included in this Glossary. For example, terms like
‘computer’, ‘keyboard’, ‘archive’ and ‘compact’ are considered general computer field terms that do not need to
be defined here. Some other terms reflect functionalities inherent in any computer system and are not defined
here, e.g. compute. Readers who desire definitions of terms not covered in the Glossary are invited to consult
trusted dictionaries or encyclopedias. Where definitions of terms are taken from recognized sources, specific
references are included.

8.4 The Action-Verb Structure (Normative)

The Action-Verbs to be used for writing conformance criteria in the EHR-S FM and the PHR-S FM are organized
in two hierarchies, each with its own specific set of Action-Verbs to:
• Secure and operationalize systems;
• Manage data and the health record.
Each hierarchy consists of Action-Verbs that collectively represent a logical set of actions.

8.4.1 Secure (System) Hierarchy

The Secure System hierarchy provides Action-Verbs for controlling access (authenticating and authorizing users), tracking
activities (logging and auditing), and sustaining operations. This hierarchy has one parent, Secure (System), and three (3)
intermediate children: Control Access, Track, and Sustain (Operations).
 Secure (System)
Control Access Track Sustain (Operations)
Authenticate Authorize Log Audit
Table 6. Action-Verbs supporting the Secure System Hierarchy
• Control Access: to limit the use of a system to only those who are permitted
• Track: to govern; control; administrate; oversee; inspect; examine; assess; observe; monitor; police;
enforce; check
• Sustain (Operations): to keep the system running correctly (e.g., sustain operations; quality; integrity;
throughput; mirror; reliability; failover; failsafe; versioned; virus-free; leak-free; up-to-date; safeguard)
8.4.2 Data Management Hierarchy
The Data Management hierarchy provides Action-Verbs for the complete range of data handling actions by a
system. The hierarchy has one parent, Manage (Data), and six (6) children with subsets: Capture, Maintain,
Render, Exchange, Determine, and Manage-Data-Visibility.

Manage (Data)
Manage
Capture Maintain Render Exchange Determine Data
Visibility
Auto- Store Update Remove Extract Present Transmit Export Analyze Decide De-
populate Archive Annotate Delete Import Identify/
Enter Backup Attest Purge Receive Re-
Import Decrypt Edit Transmit Identify
Receive Encrypt Harmonize Hide/
Recover Integrate Unhide
Restore Link/Unlink Mask/
Save Tag/Untag Unmask

Table 7. Action Verbs supporting the Data Management Hierarchy

The first three subsets cover the capture, maintenance and rendering of data as follows:
• Capture:
o Auto-populate fields of data based on partially filled information
o Enter data manually
o Import data from an external source (which may be a device)
o Receive data from another system (which may be a device)
• Maintain:
o Store:
 Archive data to external media
 Backup data on backup storage media
 Encrypt data for security and privacy purposes
 Decrypt data to reverse encryption
 Recover/Restore data from backup
 Save data on local media
o Update:
 Annotate data with notes
 Attest data to verify and approve
 Edit data by modifying it
 Harmonize data across multiple sources
 Integrate data together
 Link data to other data
 Unlink data to remove prior linkage(s)
 Tag data with labels
 Untag data to remove prior label(s)
o Remove:
 Delete/Purge to remove data from storage media or directory(ies)
• Render:
o Extract data based on certain criteria
o Present data on an attached device
o Transmit data to external systems or devices
The next subset pertains to the Exchange of data from one part or system to another or others.
• Exchange:
o Export (transfer) data in a format that can be used by other systems
Page 24 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
 o Import data from an external source (which may be a device)
o Receive data from another system (which may be a device)
o Transmit data to another party/system
The next subset provides verbs for the determination of actions in processing data:
• Determine:
o Analyze data using rules and analytical steps
o Decide appropriate actions as a result of that analysis
The final subset allows the construct of statements restricting the visibility of data and reversing those actions:
• Manage-Data-Visibility:
o De-Identify data as to prevent associating the data to a specific person
o Re-Identify data to reverse a prior de-identification
o Hide data so that only authorized users can see that the data exist
o Unhide data to reverse a prior hide operation
o Mask data so that users can see that the data exist but only authorized users can actually view the
actual data
o Unmask data to reverse a prior mask operation
8.4.3 How Action-Verbs are defined
Action-Verbs are defined in the following manner:
For an Action-Verb that has a parent, the Action-Verb’s definition will start with the immediate parent verb and
then a restatement of the meaning of the Action-Verb, followed by at least one (1) example labeled as such.
Examples will use the Action-Verb being defined with explanatory descriptions where relevant. Such as:
• PRESENT (Action-Verb): To RENDER (the parent Action-Verb) data by delivering the data to local users in
a meaningful and appropriate way. For example, the system may PRESENT an alert automatically when a
newly-arriving laboratory value is received that is out of normal range.
For a top level Action-Verb, the definition will include the next immediate level of children, followed by at least one
(1) example labeled as such. Examples will use the Action-Verb being defined with explanatory descriptions
where relevant. An illustrative example follows:
• MANAGE (DATA) (Action-Verb): To handle data by capturing, maintaining, rendering and exchanging data,
determining actions about data, and managing data visibility. For example, the system shall provide the
ability for a user to MANAGE patient and family preferences as they pertain to current treatment plans.
The following table lists the full set of eligible Action-Verbs and their logical construction:

Action-Verb Construction
To DETERMINE actions in the flow of processing data by comparing, correlating, or
weighting certain data and by applying clinical or business rules, hence leading to a
decision (see DECIDE). For example, the system may ANALYZE patient information
Analyze using a drug-interaction database and a set of clinical rules. Another example is that
the system may ANALYZE various protocols relative to a patient’s condition. Another
example is that a person may ANALYZE a proposed update to a patient’s home
address and DECIDE to reject the proposed update.
To UPDATE data by attaching comments or notes to the data without editing the data.
Annotate For example, an Attending physician may ANNOTATE the information entered by the
Resident physician before signing the report.
To STORE data by moving the data to long-term storage media and deleting or
purging data on the original online storage, according to scope of practice,
organizational policy, and/or jurisdictional law. For example, the system at the Oak
Street Hospital automatically ARCHIVES patient-related data that is older than eight
Archive
years by encrypting and compressing it, moving it to long-term storage, purging it,
identifying the data by month and year, and creating a pointer to the archived data.
Another example is that a system may automatically ARCHIVE outpatient clinic
schedules that are being replaced.
To UPDATE information by ATTESTing that an EHR record (or part of an EHR
record) is genuine.. For example, a resident physician may ATTEST that the
information contained in an EHR record was created by her. Another example is that
Attest
an attending physician may annotate a resident’s version of the record and then
ATTEST to those changes. . Note: Attestations may be applied, affixed or bound to an
EHR record, for example, via a digital signature, certification, or other verifying mark.
 Action-Verb Construction
To TRACK system-initiated or user-initiated activities by analyzing logs based on
policies or rules. For example, the system may automatically AUDIT the daily log for
Audit multiple-failed-logon-attempts. Another example is that an administrator may AUDIT
the excessive use of extraordinary (i.e., “break-the-glass”) access to certain patient
information in the Emergency Department.
To CONTROL ACCESS to a system by validating the identity of a user, another
system or a device before authorizing access. For example, the system may
Authenticate AUTHENTICATE Dr. Jones by validating his identity using a UserID and a biometric
device. Another example is that the system rejects Sara Smith’s attempt to
AUTHENTICATE to the system after three failed password entries.
To CONTROL ACCESS to a system by applying permissions to use certain
functionality or to view certain data. For example, the system may AUTHORIZE Dr.
Jones, an Emergency Department physician, to view Emergency Department patient
Authorize
records (note: We assume that the administrator has entered a set of permissions for
all Emergency Department physicians). Another example is that the system does not
AUTHORIZE deletion by Sara Smith of a patient record that has already been signed.
To CAPTURE data by inputting it automatically using previously-existing data,
providing a default value, or deriving it from other data, or by following various data-
entry business rules. For example, the system may AUTO-POPULATE the city,
Auto-populate
state/province, and country fields when a user enters a zip-code. Another example is
that the system may AUTO-POPULATE a newborn’s home address with the mother’s
home address.
To STORE data by placing a copy of the data onto an electronically-accessible device
for preservation in case the original is lost, corrupted, or destroyed. For example, a
Backup system may BACK UP the incremental changes made to a patient’s record by storing
it locally on a daily basis. Another example is that an administrator may BACK UP a
complete copy of certain data by storing it at an offsite facility.
To MANAGE data by auto-populating, entering, importing, or receiving the data, either
through human intervention or automated means. For example, a system may
CAPTURE patient’s data entered by a physician through the keyboard or sent by the
Capture
physician using a mobile device. Another example is that the system may CAPTURE
laboratory results by automatically receiving laboratory data or by keyboard entry for
locally performed tests.
To AUTHENTICATE users and/or systems and AUTHORIZE access to functionality
and/or data. For example, the system may CONTROL ACCESS to the patient’s data
by authenticating Dr. Jones’ identity and authorizing him to update his patient’s
Control
records. Another example is the system may CONTROL ACCESS to the system by
Access
refusing a hospital visitor the ability to authenticate to the system. NOTE: the set of
CONTROL ACCESS Action-Verbs requires data specifying permissions. This
permission data is managed via the MANAGE data Action-Verbs set.
To DETERMINE actions in the processing of data by choosing a certain alternative
based on an analysis, and acting accordingly. For example, the system may DECIDE
to render a notification to off-duty nurses to report for duty based on clinic rules and
Decide
the receipt of a tornado alert. Another example is that the system may DECIDE to
RENDER an alert to a clinician that a prescribed drug is contraindicated with the
patient’s listed allergies, based on the analysis conducted.
To STORE data by converting encrypted data back into its original form, so it can be
Decrypt understood. For example, the system may DECRYPT clinical data received from an
authenticated external laboratory system.
To MANAGE-DATA-VISIBILITY by removing identifiers from data in such a way that
the risk of identifying an individual is very small under the circumstances, as specified
by scope of practice, organizational policy, and/or jurisdictional law. For example, a
De-identify system may DE-IDENTIFY data for a researcher who wants to perform an analysis of
drug effectiveness on diabetic patients. Another example is where a hospital may DE-
IDENTIFY data for a set of patients to transmit to a university professor looking for
illustrative cases for educational work.
To REMOVE data by making it inaccessible to the application. For example, a user
may DELETE an existing patient-appointment at the request of the patient. . Note: In
the case where the data becomes invalid but needs to remain in the system, the word
“TAG” is preferred over the word “DELETE” or the word “Nullify”. This type of action is
Delete
considered a data “Tagging” process and not a data deletion process. For example, a
health information management professional may desire to TAG a certain clinical term
as obsolete, but the term needs to remain in the system for backward compatibility
purposes.
Page 26 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
Action-Verb Construction
To MANAGE data by analyzing it and making a decision based on the analysis. For
example, the system may DETERMINE the possible severity of a patient’s allergic
reaction to a proposed drug by analyzing the patient’s profile against a drug database
and deciding whether the clinician should be presented with an alert or not. Another
Determine
example is that a system may DETERMINE the next steps in a workflow based on an
analysis of a patient’s laboratory results, the patient’s profile, and the clinical rules of
the clinic, this analysis leading to a decision as to the appropriate next steps in the
clinical process.
To UPDATE data by correcting, amending, appending, or augmenting the data. For
example, the physician may EDIT the patient’s home address by correcting the civic
Edit
number from 368 to 638 Oak Street. Another example is that a physician may EDIT
existing notes about an injury by appending an x-ray picture of a broken bone.
To STORE data by transforming the data into a form that is difficult to understand by
Encrypt unauthorized people or systems. For example, the system may ENCRYPT sensitive
information such as the patient’s financial information.
To CAPTURE data by inputting it manually (for example, via a keyboard) or through
other input devices. For example, the user may manually ENTER the patient’s street
Enter
address via the keyboard. Another example is that the user may ENTER the patient’s
body weight via an electronic weight scale.
To MANAGE data by importing, receiving, exporting, or transmitting the data between
Exchange systems. For example, the PHR Account Holder may exchange family history
information with the PHR systems of other family members.
To RENDER data by locating, retrieving and possibly assembling data based on
certain criteria and for certain purposes. For example, a system may EXTRACT for a
clinician all the x-ray reports regarding the patient’s chest. Another example is that the
system may automatically EXTRACT allergy history when the physician enters a
Extract prescription. Another example is that a system may EXTRACT for a researcher the
number of pneumonia-like cases treated at the Emergency Department within a
specific time period. Another example is that a system may EXTRACT and aggregate
information using a cohort of patients who have pneumococcal disease and
categorize that cohort by specific age-ranges.
To UPDATE data by aligning and reconciling it with other information in the system, or
with the data of another system (or systems). For example, the system may
Harmonize
HARMONIZE a patient’s new home address with the data of systems of other
members of the care-team.
To MANAGE-DATA-VISIBILITY by making specific information invisible so that the
existence of the information is not expressed except to authorized users; viewers of
the patient record receive no indication that the hidden information exists or does not
Hide
exist. For example, the system may HIDE the existence of a patient’s psychiatric
record from all viewers except for the patient’s psychiatrist. Note: the verb “unhide” is
an acceptable verb to reverse the action of hiding.
To CAPTURE data into a local system by proactively accessing data from an external
source and then downloading and integrating the data into the local system. For
Import example, the system may IMPORT the latest drug trial data every Friday evening.
Another example is that the user may IMPORT various sets of best practices related
to juvenile diabetes.
To maintain control of data by removing access to the data in such a way as the data
is no longer active for a certain reason. For example, the PHR Account Holder may
Inactivate
no longer employ a list of local oncologists, while the PHR Account Holder is
stationed in another country for a while.
To UPDATE data by merging other data with the existing data in a controlled manner.
For example, a user may INTEGRATE summaries of health care services that were
provided in another jurisdiction into the patient’s local record. Another example is that
Integrate
an EHR system may INTEGRATE a single-sign-on application with the EHR system’s
existing user-authentication services. Another example is that an EHR system may
INTEGRATE multiple third-party modules to enhance its capabilities.
To UPDATE data by associating one piece of data with another piece of data. For
example, the system may LINK a patient’s encounter note with the patient’s
Link
laboratory results. Another example is that a system may LINK attestable changes to
a patient’s record to the author’s identifying information.
 Action-Verb Construction
To TRACK system-initiated or user-initiated activities (including access to data and/or
functionality, attempts to access data and/or functionality, actions performed on data
and/or functionality, and changes to system characteristics or versions) by storing a
chronological trace of these activities. For example, the system may LOG the fact that
Log
modifications were made to a patient’s record by storing the date, time, and identity of
the user who modified the record as well as what changes were made to that record.
Another example is that the system may LOG the fact that updates were applied to a
drug-interaction database table, by storing the date and time at which it was updated.
To MANAGE data by storing, updating, and/or removing the data within a system. For
example, a system may provide the ability for a clinician to MAINTAIN data by
Maintain
keeping or discarding it. Another example is that a system may provide the ability for
a clinician to MAINTAIN data by correcting or annotating it.
To handle data by capturing, maintaining, and rendering data, determining actions
about data, and managing data visibility. For example, the system may provide the
ability for a user to MANAGE patient and family preferences as they pertain to current
Manage
treatment plans. Another example is that a clinician’s system may provide the ability
(Data)
for the clinician to MANAGE patient data by creating a patient’s record, updating a
clinical note, utilizing clinical decision support tools, and transmitting the patient’s
billing information.
To MANAGE data by de-identifying/re-identifying, masking/unmasking or
Manage-Data- hiding/unhiding that data. For example, the system may provide the ability for an
Visibility administrator to MANAGE-DATA-VISIBILITY in terms of who is allowed to view what
specific patient data.
To MANAGE-DATA-VISIBILITY by obscuring (masking) specific data elements in
order that this information is not available except to authorized users; viewers of the
patient record can see that the data exists but cannot see actual contents. For
Mask (verb)
example, the administrator may MASK the pregnancy status of all patients who are
below the age of eighteen except for the obstetric unit staff.. Note: the verb “unmask”
is an acceptable verb to reverse the action of masking.
To RENDER data by delivering the data to local users in a meaningful and
appropriate way. For example, the system may PRESENT to a physician (upon
manual request) a list of patients who are scheduled for care today, ordered by time-
of-day, with the patient’s known diagnosis using the physician’s preferred terminology
and language of choice. Another example is that the system may PRESENT an alert
Present automatically when a newly-arriving laboratory value is received that is out of normal
range. Another example is that a system may PRESENT to a physician a patient’s
lung respiration sounds. Another example is that a system may PRESENT patient-
instructions using an audio and video system. Note: It is reasonable to assume that
any data that is presented ought to be formatted, filtered, translated, transformed,
mapped, and/or normalized, etc., as appropriate.
To MAINTAIN data by creating a pseudonym for its subject. For example, the name
Pseudonymize "Robert Q. Jamison" might be replaced with a pseudonym such as "John Smith" in a
health care document before sharing it with others.
To REMOVE data by making it unrecoverable at the storage and/or media-level. For
example, the system may PURGE the patient record for John Smith according to a
Purge
rule that targets all records that are older than seven years. (Note: Destroy and Purge
are synonyms; PURGE is the preferred term.)
To CAPTURE data from an external source by taking in that data without manual /
real-time user intervention. For example, the system may RECEIVE various emails for
a clinician who will later review them. Another example is that the system may
Receive
RECEIVE from authenticated and authorized external systems laboratory results for a
given patient. Another example is that the system may RECEIVE a facsimile
transmission from an external device.
To STORE data by rebuilding original data using backups of data. For example, the
Recover system may RECOVER last week’s data following a hard disk failure, using an offsite
backup copy. (See BACKUP.)
To MANAGE-DATA-VISIBILITY by combining data in such a way that the patient’s
identity is re-established according to scope of practice, organizational policy, and/or
Re-identify jurisdictional law. For example, the system may RE-IDENTIFY de-identified data by
providing a key that allows authorized users to re-establish the link between a given
patient and that patient’s de-identified data.
To MAINTAIN data by making the data inaccessible or unrecoverable according to
Remove scope of practice, organizational policy, and/or jurisdictional law. For example, a
system may, at a physician’s request, REMOVE by purging patient information that
Page 28 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
Action-Verb Construction
was received by mistake. Another example is that a system may, upon request by an
administrator, REMOVE by deletion the schedule of outpatient clinic opening hours..
NOTE 1: The data may be deleted either by removing the data’s pointer from the
directory or by overwriting the data in such a way that the original data is
unrecoverable. . NOTE 2: In the case where the data becomes invalid but needs to
remain in the system, the word TAG is preferred over the word REMOVE or “Nullify”.
This type of action is considered a data “Tagging” process and not a data deletion
process. For example, a health information management professional may desire to
TAG a certain clinical term as obsolete, but the term needs to remain in the system
for backward compatibility purposes.
Remove To MAINTAIN data by disallowing access to the data in such a way as the data can
Access no longer be retrieved.
To MANAGE data by extracting, presenting and transmitting data to users or systems.
For example, the system may RENDER a list of patients with a given disease that has
been extracted from the clinic’s active patient records. For example, the system may
Render
RENDER laboratory results by presenting them on a computer screen. Another
example is that the system may RENDER data by transmitting a drug prescription to a
pharmacy.
To STORE data to the production system by using previously archived data. For
example, the system may RESTORE patient-encounter data for a returning patient
Restore whose data had been archived due to inactivity. Another example is that the system
may RESTORE, for evidentiary support, patient data that had been archived after the
patient expired. (See ARCHIVE.)
To STORE data by placing it onto an electronically-accessible device for preservation.
For example, a clinician may SAVE a given patient’s demographic data or a newly-
Save
prescribed medication. Another example is that an administrator may SAVE an
updated list of physicians that have practice privileges at the local hospital.
To ensure system reliability and integrity by controlling access to system functionality
and/or data, tracking activities, and sustaining system operations. For example, the
system may provide the ability for an administrator to SECURE a system by setting
Secure
configuration parameters for controlling access, tracking, and sustaining system
(System)
operations. Another example is that the system may SECURE access to a patient’s
record by controlling access to its content, tracking users who have modified the
patient’s record, and sustaining the record’s availability on a continual basis.
To OUTPUT data from the PHR Account Holder’s system by exporting it in such a
way as to (passively, automatically) route it to another system. For example, a PHR
Send
Account Holder’s system may (passively, automatically) send weekly reports to a
diabetes specialist’s system regarding the PHR Account Holder’s current weight.
To MAINTAIN data by backing up, decrypting, encrypting, restoring and saving that
data onto electronically accessible devices. For example, a clinician may STORE a
given patient’s demographic data or a newly-prescribed medication. Another example
Store
is that an administrator may configure a system to STORE progressive copies of
certain data on a regularly-scheduled basis for backup purposes.. Note: data may be
stored as plain text or in encrypted or compressed form.
To SECURE a system by promoting actions that enable the system to perform
predictably and as intended. For example, a system may SUSTAIN (OPERATIONS)
Sustain
by applying business rules that enforce role-based access to the authorization
(operations)
management portion of the system, thus protecting the PHR Account Holder’s data
according to pre-determined security and privacy rules.
To OUTPUT data from the PHR Account Holder’s system by exporting it in such a
way as to coordinate certain data with another system (or systems). For example, the
Synchronize PHR Account Holder may coordinate the medications prescribed by two physicians
with a list of home remedies so that each relevant, authorized stakeholder has a
current list of the PHR Account Holder’s medications/remedies.
To UPDATE data by marking it for special use. For example, a nurse may TAG the
previous week’s records for patients that presented with a severe cough and fever.
Another example is that a general practitioner may TAG certain data for review by an
Tag oncologist. Another example is that an administrator may TAG an interchange
standard version as being deprecated.. Note: see “flag” if the meaning is to signal a
situation.. Note: the verb “untag” is an acceptable verb to reverse the action of
tagging.
 Action-Verb Construction
To SECURE a system by logging and auditing system-initiated and/or user-initiated
activities. For example, the system may TRACK the amount of time that the system
Track was unavailable last month. Another example is that the system may provide the
ability for an administrator to TRACK the number of active users of a newly-installed
set of system functionality.
To RENDER data by delivering the data to devices or other systems in a meaningful
and appropriate way. For example, the system may (without human intervention)
TRANSMIT an alert to a physician’s beeper. Another example is that the system may
(upon human intervention) TRANSMIT a given patient’s encounter summary to an
Transmit
external facility. Another example is that the system may TRANSMIT data to another
facility after mapping local codes to national codes.. Note: It is reasonable to assume
that any data that is transmitted ought to be formatted, filtered, translated,
transformed, mapped, and/or normalized, etc., as appropriate.
To MANAGE-DATA-VISIBILITY by making visible the existence of previously hidden
information (see HIDE). For example, the system may provide the ability for a patient
Unhide
to UNHIDE his psychiatric record, and hence the existence of that part of his record
becomes visible to all authorized clinicians.
To MANAGE-DATA-VISIBILITY by making masked information visible. For example,
the administrator my desire to UNMASK certain patient financial information for the
Unmask admission Department. For example, a system may provide the ability for an
emergency department physician to UNMASK a patient’s pregnancy status that was
presented by the system as “******”, to reveal a status of “Pregnant”.
To UPDATE data by removing marking for special use. For example, a nurse may
UNTAG the previous week’s records for patients that presented with a severe cough
Untag
and fever that had been previously tagged. Another example is that a general
practitioner may UNTAG certain data after completion of review another provider.
To MAINTAIN data by annotating, editing, harmonizing, integrating, linking and
Update tagging the data. For example, a clinician may UPDATE a patient’s medication
dosage. Another example is that the system may UPDATE a patient’s record.
Table 3. Action Verbs and their Logical Construction

8.4.4 Deprecated Action-Verbs

The use of verbs that are specific in definition and use allows for greater understanding and consistency of
conformance criteria throughout the model.
In this Glossary, the term “deprecated” is used to identify Action-Verbs that were used in conformance criteria (in
previous FM Releases) but are not part of the updated hierarchy of Action-Verbs. It is recommended that
deprecated Action-Verbs not be used in Conformance Criteria.

The following table lists a set of deprecated verbs and possible alternatives:
Deprecated
Possible Alternative(s)
Action-Verb
Instead, use CONTROL-ACCESS if the context is one of controlling access to the
Access system.. Use RENDER or PRESENT or another relevant Action-Verb when the context
is one of accessing data.
Instead, use TAG (with an appropriate qualifier). Affirm, Assert, Declare, Indicate, and
Affirm
State are synonyms.
Instead, use “RENDER or PRESENT or TRANSMIT an alert to a person or another
system (including a device)”. An Alert typically occurs after analyzing some data and
Alert
arriving at a decision that someone must be alerted. See DETERMINE for some
examples.
Amend Instead, use EDIT.
Instead, use the term EDIT. This means editing data by adding new data to existing
Append
data.
Instead, use TAG (with an appropriate qualifier). Affirm, Assert, Declare, Indicate, and
Assert
State are synonyms.
Instead, use EDIT, ANNOTATE, or LINK with the appropriate qualifiers. Augmentation
Augment
is the addition of information to existing healthcare data.

Page 30 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
Deprecated
Possible Alternative(s)
Action-Verb
Instead, use “DETERMINE and STORE” or “DETERMINE and PRESENT”, as
Calculate
appropriate in the context.
Instead, use “DETERMINE and STORE” or “DETERMINE and PRESENT” as
Compute
appropriate in the context.
Instead, use “MANAGE configuration parameters for…”. For example, the user may
desire to STORE configuration parameters regarding the preferred type of human
Configure language. Another example is that an administrator may UPDATE configuration
parameters that control external access to the system by restricting access during the
weekends.
To comply... Note: The verb ‘Conform’ is used with a special meaning in the FM and is
not part of the Action-Verb model. It is a special instruction for including the functional
Conform
requirements of one function in another function. For example: “The system SHALL
conform to function IN.1.1 (Entity Authentication)”.
Correct Instead, use EDIT.
Instead, use “DETERMINE and STORE” or “DETERMINE and RENDER” or
Create
“DETERMINE and PRESENT” as appropriate to the context.
Instead, use TAG (with an appropriate qualifier). Affirm, Assert, Declare, Indicate, and
Declare
State are synonyms.
Instead, use TAG with an appropriate qualifier. Deprecation of certain information may
be required when that data becomes invalid, but needs to remain in the system. For
Deprecate example, a health information management professional may desire to TAG a certain
clinical term as deprecated, but the term is retained in the system for backward
compatibility purposes.
Destroy
Disable- Instead, use “CONTROL ACCESS by removing permissions to use specific
Access functionality and/or manage specific data”.
Instead, use “RENDER and TAG” with a label that identifies the data’s purpose as “for
Disclose
disclosure use only”.
Display Instead, use PRESENT.
Document Instead, use ENTER, or “TAG with” appropriate references, or “LINK to” sources.
Eliminate Instead, use DELETE or PURGE as applicable.
Export Use RENDER instead.
Instead, use “RENDER an alert”, or “PRESENT an alert”, or “TRANSMIT a notice”, if
Flag
the intent is to signal a situation (i.e. flag a situation).
Instead, use “DETERMINE and STORE” or “DETERMINE and PRESENT” or
Generate
“DETERMINE and RENDER“ as appropriate to the context.
Grant-Access Instead, use CONTROL ACCESS.
Instead, use other Action-Verbs adapted to the context. . For example, instead of ‘…to
uniquely identify a patient…’, one should say ‘…to MAINTAIN a unique identifier for a
Identify
patient…’ Another example is: instead of ‘…to help identify the patient...’, use ‘…help
DETERMINE the identity of the patient.’.
Instead, use CAPTURE, ENTER, RECEIVE, IMPORT or AUTO-POPULATE,
Input
depending on the context and scope of actions described.
Label (verb) Use “TAG with a label”.
Merge Instead, use INTEGRATE.
Modify
Instead, use: “MANAGE data regarding permissions”
Access
 Deprecated
Possible Alternative(s)
Action-Verb
Instead, use “RENDER or PRESENT or TRANSMIT a notification to a person or
Notify
another system (including a device)”.
Nullify Instead, use “TAG as nullified”.
Obsolete Instead, use “TAG as obsolete”.
Order Instead, use “ENTER the parameters for an order”.
Permit Instead, use “AUTHENTICATE a user and AUTHORIZE access based on permissions
Access assigned to that user”.
Persist Instead, use “STORE“.
Print Instead, use RENDER, PRESENT, OR TRANSMIT, depending on the context.
Prioritize Instead, use “TAG with a priority level”, or “DETERMINE priorities”.
Provide Instead, use CONTROL ACCESS, or PRESENT, as appropriate to the specific
access to context.
Instead, use ANALYZE or RENDER (or its children Action-Verbs), because queries or
Query
searches are implied when rendering or analyzing data.
Instead, use TAG with an appropriate qualifier. Reactivation of certain information may
be required when that data, previously deprecated or made inactive, becomes valid
Reactivate
again. For example, a health information management professional may desire to
TAG a certain clinical term as reactivated.
Instead, use ANALYZE and DECIDE, or DETERMINE, or HARMONIZE depending on
Reconcile
the context and the meaning intended.
Record Instead, use STORE (or its children Action-Verbs).
Reject Instead, use ‘’PRESENT or RENDER a message of rejection” or “TAG as rejected”.
Instead, use EDIT, or “DELETE the old and SAVE the new”, or “TAG as obsolete and
Replace
SAVE the new”, based on the context.
Report Instead, use “RENDER a report”, or “PRESENT a report”.
Repudiate Instead, use “TAG as repudiated or rejected”.
Instead, use STORE (with the possible addition of language that includes the notion
that retention management may be needed to accommodate scope of practice,
Retain organizational policy, or jurisdictional law). For example, the system may provide the
ability to STORE personal health information, and DELETE that data only as allowed
by the organization’s data-retention policies.
Revoke- Instead, use “CONTROL ACCESS by eliminating permissions to use system
Access functionality or to manage data”.
Instead, use ANALYZE or RENDER (or its children action-verbs), because queries or
searches are implied when rendering or analyzing data. For example, instead of saying
Search “The system SHALL provide the ability to search patient records based on previous
names”, one could say ‘‘The system SHALL provide the ability to PRESENT a list of
records with possible patient name matches using previous patient names”.
Select Instead, use “ENTER a selection”.
Instead, use “TAG-with-authenticated-signature”. For example, a system may TAG a
Sign patient note with an authenticated signature when the physician completes the
patient’s note.
Instead, use TAG with an appropriate qualifier. Affirm, Assert, Declare, Indicate, and
State
State are synonyms.
Instead, use “PRESENT templates to do XYZ”, or DETERMINE, or other Action-Verbs
Support
depending on the context and functionality to specify.
Suspend- Instead, use “CONTROL ACCESS by temporarily withholding permissions to use
Access system functionality or to manage data”.

Page 32 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 Deprecated
Possible Alternative(s)
Action-Verb
Synthesize Instead, use “ANALYZE and STORE” or “ANALYZE and PRESENT”.
Instead, depending on the context, use “DECIDE on a course of action based on an
Trigger analysis of certain data and rules”, or “DECIDE and RENDER some information (for
example, an alert or a notification) based on the analysis of certain data and rules”.
View Instead, use PRESENT.
Term Instead use...

Table 4. Deprecated Action-Verbs and Possible Alternative(s)

8.5 Guidelines for Use (Reference)

Contributors to the contents of the EHR-S and PHR-S FMs must be thoroughly familiar with this ‘Guidelines For
Use’ Section. It is critical to the integrity of the FMs that key terms have a consistent meaning throughout each
FM specification.

8.5.1 General Guidance

Throughout the EHR-S and PHR-S FMs, terms used for stating Conformance Criteria (CC) must respect
meanings as conveyed in the definitions provided in this Glossary. Using the Action-Verbs rigorously will result in
clearly written Conformance Criteria (CC) and help ensure consistent communication of functional requirements.
Furthermore, combining various functional models and functional profiles is facilitated when a controlled set of
terms is used consistently. Therefore, use of synonyms (as replacements) or local jargon should be avoided.
In the FMs, Statements and Descriptions should be written in ‘business-like language’ defining, in business and
user terms, system capabilities that support user needs. CCs should be written from the system’s perspective,
with rigor and consistency across functional areas, using Action-Verbs and the guidelines; CCs should not be
duplicates of the Statements and Descriptions. However, scope-wise, both Statement/Description and
corresponding CCs must address the same functionalities.
CCs represent a fundamental component of the FMs by defining its functionalities in precise terms. Significant
efforts were invested in developing a set of Action-Verbs with precise definitions that must be used in the
construction of CC. The next section provides specific guidance on how CC should be composed.
Since various realms may require the use of certain terms (for example, a term that is embedded in national law),
this FM Glossary maintains a realm-independent perspective. The long-term intent is to construct CCs that are
computable and easy to validate as to their grammar and contents when it is relevant (i.e., use list of approved
Action-Verbs).

8.5.2 Constructing Rigorous Conformance Criteria

Rigor, clarity and consistency in crafting CCs are of paramount importance. The following rules are to be followed
whenever possible:
• It is generally preferable to use separate CCs instead of trying to include multiple actions in a single criteria,
unless such a combination provides for an economy of statements and is unambiguous.
• Where an action can be performed both automatically by the system and manually upon initiation by the
user, CCs should be composed with the “provide the ability to” phrase incorporated.
Selected verbs in conformance criteria should be at the proper level of granularity. If a parent verb in a hierarchy
is used, then it means that the actions of all the children verbs under it are pertinent and applicable.
• For example, instead of saying MAINTAIN clinical data which would imply storage, update and deletion of
data, one would say STORE and UPDATE data if deletion of data was not allowed.
• For example, if a given CC expects EDIT and TAG to be reasonable application of the function, but that
ANNOTATE, HARMONIZE, INTEGRATE, LINK are unreasonable, then the word MAINTAIN should be
avoided in lieu of the more precise “EDIT and TAG”.
• An example of multiple Action-Verbs: “The system SHALL provide the ability to CAPTURE, STORE, EDIT,
and TAG-as-deprecated entries in an xxx registry or directory to keep it current.”
The general grammar to use in developing rigorous CCs has the following structure:
• “The system [SHALL | SHOULD | MAY] [provide the ability to] [Action-Verb] [functionality object(s)]
[participant(s)] [qualifier(s)] [‘according to user preference, scope of practice, organizational policy, and/or
jurisdictional law’]”.
• The system is the subject of all the Conformance Criteria.
• [SHALL | SHOULD | MAY]. It is mandatory that one – and only one – of these three qualifier verbs be used.
Meanings are defined in EHR-S FM Conformance Clause document and are repeated here for
convenience:
o SHALL – to indicate a mandatory functional requirement to be followed (implemented) in order to
conform. Synonymous with ‘is required to’.
o SHOULD – to indicate an optional yet recommended functional requirement, one that is particularly
suitable, without mentioning or excluding others. Synonymous with ‘is permitted and recommended’.
o MAY – to indicate an optional (permissible) functional requirement. Synonymous with ‘is permitted’.
• [provide the ability to]: optional phrase used to convey when the functional requirement may be either
initiated by user action or automatically by system rules. System rules may be configurable.
• [Action-Verb]: mandatory. The Action-Verb must come from the standardized list enumerated in this
Glossary and respect the definitions provided. When another verb would appear preferable, it is suggested
to look for that verb in the Glossary definition section where it may be listed with suggestions for a
replacement verb and composition. This guide provides numerous examples.
• [functionality object(s)]: mandatory. Identifies the object(s) of the functional requirement.
• [participant(s)]: optional. Covers users (or external systems) that participate or are affected by the specified
function.
• [qualifier(s)]: optional. This might relate to time, interval, condition(s). Can include (for example):
“automatically”, “manually”, “in real time”, “according to the business rules”
• [“according to user preference, scope of practice, organizational policy, and/or jurisdictional law”]: optional,
when the action could be governed by relevant practices, policies and/or laws.
Note that “The system SHALL…” means that the system is required to perform the relevant function when all
factors and specified conditions are met.
Some examples of rigorous CCs follow:
• The system SHALL provide the ability to PRESENT the list of scheduled patients according to selected
criteria such as provider name, dates, time of day, nature of visit, etc. using language of choice.
• IF a provider attempts to prescribe a drug using the system, THEN the system SHALL DETERMINE
whether interactions exist between the newly prescribed drugs and the medications on the patient’s current
medication list, and RENDER an appropriate response to the provider, according to scope of practice,
organizational policy, and/or jurisdictional law.
The verb ‘Conform’ is used with a special meaning in the FM and is not part of the Action-Verb model. It is a
special instruction for including the functional requirements of one function in another function.
• For example: The system SHALL conform to function TI.1.1 (Entity Authentication).

9 Glossary Supplement: Record Lifecycle Events and Descriptions (Normative)

Developed (in part) by the HL7 EHR/Security WG Vocabulary Alignment Project

Incorporated in:
HL7 FHIR Core R4 and FHIR Record Lifecycle Event Implementation Guide (RLE IG)
ISO 21089:2018 Trusted End-to-End Information Flows
ISO/HL7 10781:2020 EHR System Functional Model Release 2.1
ISO/HL7 16527:2020 PHR System Functional Model Release 2

9.1 Record Lifecycle Events (See RI.1.1.1)

Access/View Record Lifecycle Event - occurs when an agent causes the system to obtain and open a
record entry for inspection or review.
Add Legal Hold Record Lifecycle Event - occurs when an agent causes the system to tag or otherwise
indicate special access management and suspension of record entry deletion/destruction, if deemed relevant
to a lawsuit or which are reasonably anticipated to be relevant or to fulfill organizational policy under the legal
doctrine of “duty to preserve”.
Amend (Update) Record Lifecycle Event - occurs when an agent makes any change to record entry content
currently residing in storage considered permanent (persistent).

Page 34 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
Archive Record Lifecycle Event - occurs when an agent causes the system to create and move archive
artifacts containing record entry content, typically to long-term offline storage.
Attest Record Lifecycle Event - occurs when an agent causes the system to capture the agent’s digital
signature (or equivalent indication) during formal validation of record entry content.
Decrypt Record Lifecycle Event - occurs when an agent causes the system to decode record entry content
from a cipher.
De-Identify (Anononymize) Record Lifecycle Event - occurs when an agent causes the system to scrub
record entry content to reduce the association between a set of identifying data and the data subject in a way
that may or may not be reversible.
Deprecate Record Lifecycle Event - occurs when an agent causes the system to tag record entry(ies) as
obsolete, erroneous or untrustworthy, to warn against its future use.
Destroy/Delete Record Lifecycle Event - occurs when an agent causes the system to permanently erase
record entry content from the system.
Disclose Record Lifecycle Event - occurs when an agent causes the system to release, transfer, provision
access to, or otherwise divulge record entry content.
Encrypt Record Lifecycle Event - occurs when an agent causes the system to encode record entry content
in a cipher.
Extract Record Lifecycle Event - occurs when an agent causes the system to selectively pull out a subset
of record entry content, based on explicit criteria.
Link Record Lifecycle Event - occurs when an agent causes the system to connect related record entries.
Merge Record Lifecycle Event - occurs when an agent causes the system to combine or join content from
two or more record entries, resulting in a single logical record entry.
Originate/Retain Record Lifecycle Event - occurs when an agent causes the system to: a) initiate capture
of potential record content, and b) incorporate that content into the storage considered a permanent part of
the health record.
Pseudonymize Record Lifecycle Event - occurs when an agent causes the system to remove record entry
content to reduce the association between a set of identifying data and the data subject in a way that may be
reversible.
Re-activate Record Lifecycle Event - occurs when an agent causes the system to recreate or restore full
status to record entries previously deleted or deprecated.
Receive/Retain Record Lifecycle Event - occurs when an agent causes the system to a) initiate capture of
data content from elsewhere, and b) incorporate that content into the storage considered a permanent part
of the health record.
Re-identify Record Lifecycle Event - occurs when an agent causes the system to restore information to
data that allows identification of information source and/or information subject.
Remove Legal Hold Record Lifecycle Event - occurs when an agent causes the system to remove a tag
or other cues for special access management had required to fulfill organizational policy under the legal
doctrine of “duty to preserve”.
Report (Output) Record Lifecycle Event - occurs when an agent causes the system to produce and deliver
record entry content in a particular form and manner.
Restore Record Lifecycle Event - occurs when an agent causes the system to recreate record entries and
their content from a previous created archive artefact.
Transform/Translate Record Lifecycle Event - occurs when an agent causes the system to change the
form, language or code system used to represent record entry content.
Transmit Record Lifecycle Event - occurs when an agent causes the system to send record entry content
from one (EHR/PHR/other) system to another.
Unlink Record Lifecycle Event - occurs when an agent causes the system to disconnect two or more record
entries previously connected, rendering them separate (disconnected) again.
Unmerge Record Lifecycle Event - occurs when an agent causes the system to reverse a previous record
entry merge operation, rendering them separate again.
 Verify Record Lifecycle Event - occurs when an agent causes the system to confirm compliance of data or
data objects with regulations, requirements, specifications, or other imposed conditions based on
organizational policy.

Page 36 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 Annex A
(normative)

Function List

Please refer to the included files EHRS_FM_R2_FunctionList.html and EHRS_FM_R2_FunctionList.pdf for the
EHR-S FM function list. Two formats are included for the reader's convenience.
 Annex B
(informative)
Glossary of Terms for the EHR-S FM

Term Definition Reference

1) obtain, open, inspect, review and/or make use of health data or information CPRI, modified
Access 2) specific type of interaction between a subject and an object that results in the flow of information from ISO 21089:2018
one to the other GCST
1) means to ensure that access to assets is authorized and restricted based on business and security
requirements
ISO/IEC 27000:2009
2) means to ensure that the resources of an electronic system can be accessed only by authorized
Access control ISO/IEC 2382-8:1998, modified
entities in authorized ways
ISO 21089:2018
3) prevention of an unauthorized use of a resource, including the prevention of use of a resource in an
unauthorized manner
1) property that ensures that the actions of an entity may be traced uniquely to that entity ISO/IEC 2382-8:1998
2) obligation of an individual or organization to account for its activities, for completion of a deliverable ISO 7498-2:1998, modified
Accountability
or task, accept responsibility for those activities, deliverables or tasks, and to disclose the results in a ISO 18308:2011
transparent manner ISO 21089:2018
Accuracy (data) extent that recorded data reflect the actual underlying information ISO 21089:2018
Olsen, Jack E., Data Quality: The
Accuracy Dimension, Morgan
Accurate correct; conformity to truth or to a standard or model Kaufmann Publishers, San
Francisco, CA, 2003
Merriam-Webster Dictionary
Active – In a state of action. America Heritage Dictionary,
Active order
Order – Request for a specific action. Second College Edition, 1991
Activity See health care activity
Actor (in the
1) human, organization, or a system entity that can participate in an action ISO/IEC 15414:2015, modified
healthcare
2) with respect to an action, entity that participates in or observes that action ISO 21089:2018
system)
a legal document (such as a living will) signed by a competent person to provide guidance for medical
Advanced
and health-care decisions (such as the termination of life support or organ donation) in the event the Merriam-Webster
Directive
person becomes incompetent to make such decisions
a negative or unexpected reaction to a drug or medical procedure (a reaction can range from mild to
Adverse reaction
life-threatening)
Adverse a condition expected to result in undesirable physiologic reaction to an amount of a substance that
sensitivity would not produce a reaction in most individuals
(review/report) a detailed critical summary or analysis of a past event (such as a clinical intervention)
After Action made for the purposes of re-assessing decisions and considering possible alternatives for future
reference
Page 38 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
 1) (conscious) entity that takes conscious actions, such as an individual, organization, business unit
2) (delegated) entity that has been delegated (e.g. authority, a function) by and acts for another (in
exercising the authority, performing the function)
3) (healthcare) individual, organization, business unit, medical device (e.g. instrument, monitor) and
ISO 21089:2018 (1,2,4,5)
Agent software (e.g. application) which a) performs a role in the provision of healthcare services and/or b) is
CEN 12265:2014, modified (3)
accountable for actions related to, and/or c) ascribed in, the health record
4) (programmed) entity that takes programmed actions, such as software or a device
5) (responsible) entity that bears some form of responsibility for an activity taking place, for the
existence of an entity, or for another agent's activity
Aggregate the consolidation of information from cohorts of individuals, families, or other groupings that is
(Population associated because of similar social, personal, health care, or other needs or interests. Note:
Health context) aggregate-level data is sometimes de-identified in the Population Health context.
Aggregate Data data that has been collected from two or more sources and combined into a single dataset
process to combine standardized data and information ISO 21089:2018
Aggregation
[SOURCE: JCAHO, modified] JCAHO
Alert (used as
an indication from a system or device that a condition exists requiring assessment and possible action.
noun)
MedLine Plus
an exaggerated immune response or reaction to a substance that is generally not harmful. The
US National Institute of
Allergy manifestation of an allergy includes a variety of physiologic responses (e.g. rash, itching, hypotension,
Health/National Library of
anaphylaxis) and can be dependent on the route of exposure (inhalation, skin contact, ingestion).
Medicine
1) process that removes the association between the identifying data set and the data subject
Anonymize 2) remove personally identifying particulars or characteristics from record content so that the original ISO 21089:2018 (2)
source or data subject cannot be known
application program interface: set of routines, protocols, and tools for building software applications. An
API
API specifies how software components should interact.
Appropriate suitable or proper in the circumstances
1) structure of components, their inter-relationships, and the principles and guidelines governing their
design and evolution over time The Open Group Architectural
2) set of principles on which the logical structure and interrelationships to an organization and business Framework (TOGAF):2009 (1)
Architecture context are based. Note: Software architecture is the result of software design activity ISO 21089:2018 (2)
3) set of design artefacts or descriptive representations that are relevant for describing an object such Zachman - Enterprise
that it can be produced to requirements (quality) as well as maintained over the period of its useful life Architecture: 1996 (3)
(change)
1) process of moving one or more EHR extracts to off-line storage in a way that ensures the possibility
of restoring them to on-line storage when needed without loss of meaning. Wherever possible, archived
data should be technology-independent so that future users do not have dependencies on obsolete ISO 18308:2011 (1)
Archive
technology from the past ISO 21089:2018 (2)
2) create, update or move an archive artifact with health record content for long-term, typically offline
storage, external to the source system
 1) (in medicine and nursing) an evaluation or appraisal of a condition
2) the process of making such an evaluation
3) (in a problem-oriented medical record) an examiner's evaluation of the disease or condition based on
Assessment Mosby's Medical Dictionary:2009
the patient's subjective report of the symptoms and course of the illness or condition and the examiner's
objective findings, including data obtained through laboratory tests, physical examination, medical
history, and information reported by family members and other health care team members.
To maintain data by updating it in such a way as to draw connections between disparate data; to
Associate
establish/maintain a relationship between two or more entities
1) (surety) grounds for surety, certainty or confidence about something
2) (security) grounds for confidence that an entity meets its claimed level of protection, including
ISO/IEC 15408-1:2009, modified
security objectives
Assurance (1)
3) (system services) development, documentation, testing, procedural and operational activities carried
OMG, modified (2,3)
out to ensure a system's services do in fact provide the claimed level of function, performance and
usability
Atomic Data
indivisible units of data
Elements
1) affirm, certify and/or authenticate a specific unit of information is true and genuine
2) (authenticity/accuracy) declare that record entry content exists, is authentic, accurate and true and
therefore that it can be trusted
Attest, Attestation ISO 21089:2018 (2,3,4)
3) (completion) declare that record entry content exists and is complete for the purpose intended
4) (evidentiary) provide or serve as clear evidence of and thus certify and record applicable
administrative (or “legal”) responsibility for a particular unit of information
1) mechanism employed to record and examine activities of an agent
2) systematic and independent examination of accesses, additions, or alterations to electronic health
records to determine whether the activities were conducted, and the data were collected, used, retained
Audit ISO 21089:2018 (1)
or disclosed according to organizational standard operating procedures, policies, good clinical practice,
and/or applicable regulatory requirement(s), and to recommend necessary changes in controls, policies
or procedures
1) (evidence of information operations) record that captures details such as additions, deletions, or
alterations of information in an electronic record without obliterating the original record. An audit trail
facilitates the reconstruction of the history of such actions relating to the electronic record.
2) (evidence of resource utilization) record of the resources which were accessed and/or used by whom ISO 7498-2:1998 (2)
Audit Trail
3) (evidence of system use/activities) chronological record of system activities that is sufficient to GCST (3)
enable the reconstruction, reviewing and examination of the sequence of environments and activities
surrounding or leading to an operation, a procedure, or an event in a transaction from its inception to
final results

Page 40 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 ISO 21089:2018 (1)
Downing v. Brown, 3 Colo. 590
1) (object, entity, record) is what it purports to be; genuine and of undisputed origin; bona fide; based on
(2)
facts, accurate and reliable
thelawdictionary.org (2)
2) genuine; true; having the character and authority of an original; duly vested with all necessary
Altiglieri, et al, in “Diagnosing and
formalities and legally attested; competent, credible, and reliable as evidence
Treating Legal Ailments of the
Authentic 3) object state or status, deemed present (authentic) or non-present (not authentic), on the basis of a
Electronic Health Record: Toward
given data object’s responses to conformance testing on three questions:
an Efficient and Trustworthy
a. what does the object provider purport the object to be?
Process for Information Discovery
b. what is the specification for that object?
and Release” in The Sedona
c. what means are offered to verify that 1=2?
Conference Journal, Summer
2017, p. 233 (3)
1) process proving something is real, true, or genuine
2) (data) process of verification of the integrity of data that have been captured, stored or transmitted
3) (data source) process of corroboration that the source of data received is as claimed ISO 21089:2018 (1,2,3)
4) (identity of entity) process to provide assurance regarding the claimed identity of an entity (e.g. ISO/IEC 10181-2:1996, modified
Authenticate, subject, user, author) (4)
Authentication 5) (health record entries) process to verify that an entry exists, is complete, accurate and final JCAHO, modified (5)
6) (object) process to assure the identity of an object ASTM E1762: 2013, modified (6)
7) satisfaction of the requirement of authenticating or identifying an item of evidence, where the US Federal Rules of Evidence (7)
proponent must produce evidence sufficient to support a finding that the item is what the proponent
claims it is
Authority body that has legal powers and rights ISO/IEC 2382-8:1998
Authorize, 1) granting of rights, which includes granting of privileges to access data and functions ISO 7498-2:1998, modified (1)
Authorization 2) prescription that a particular behaviour must not be prevented ISO/IEC 15414:2015 (2)
Authorized User user who may, in accordance with the Security Policy, perform an operation ISO/IEC 15408:1999
qualifier used to indicate that the action will be done by the system, independently of any user
Automatically
intervention
system process that automatically fills in input fields with data that are already known/available within
Auto-Populate
the systems database
1) (accessibility/usability) property of being accessible and useable upon demand by an authorized
ISO 7498 2:1998 (1)
Availability entity
ITSEC (2)
2) (non-concealment) prevention of the unauthorized withholding of information or resources
Background system processes running behind the scene without human initiation, interaction or intervention. Oracle Database Administrator
Process Sometimes employed to perform certain maintenance activities. Guidance, modified
a copy of data for the specific intent of ensuring its preservation and possible restoration in case the
Backup
original is lost, corrupted, or destroyed
Behavioral range of services for individuals at risk of, or suffering from mental, addictive, or other behavioral health
SAMHSA
Healthcare disorders
practices that incorporate the best objective information currently available regarding effectiveness and
Best practice SAMHSA
acceptability
 process of associating two related elements of information. Examples: a) one may bind an author's
(digital) signature to the corresponding health record content created by that author; b) one may bind
Bind, Binding
certain metadata to an electronic document; c) one may bind a certain laboratory results (report) to a
corresponding laboratory order.
Boundaries border or limit
statement that defines or constrains some aspect of the business, intended to assert business
structure, or to control or influence the behavior of the business. Examples include (but are not limited
Business Rule The Business Rules Group:2013
to) coding, billing, claim filing and reimbursement, resource management (personnel, beds, supplies,
equipment), workflow optimization, and clinical decision support.
discrete and accountable function or sub-function within an organization. Example: A business unit
Business Unit ISO 21089:2018
can include a department, service or specialty within a healthcare provider organization.
provision of accommodations, comfort and treatment to an individual subject of care (patient); also
Care JCAHO
implying responsibility for safety
Care Guidelines
1) recommendations offered by a care giver to a patient
(synonymous US Agency for Health Research
2) recommendations recognized by care providers as being appropriate. In general, care guidelines
with Health Care and Quality
are based on expert knowledge of assessing, treating and/or managing a particular medical condition.
Guidelines)
Care Plan, tool used by clinicians to plan and coordinate care for an individual patient that aids in understanding
Treatment Plan and coordinating the actions that need to be performed for the subject of care (patient)
task or set of tasks that is/are clinically-oriented; typically comprised of care planning, care delivery, and
Care Process
follow up tasks
group of individuals who provide health care to an individual for a given health care episode, health
Care Team
care setting or with regard to a health condition
something arranged or occurring in a series or in a succession of stages typically such that each stage
Cascade
derives from or acts upon the product of the preceding
statement of requirements that certain administrative procedures will be implemented to guard the
Chain-of-Trust
integrity, confidentiality and availability of sensitive data, where the sender and receiver agree to protect
Agreement
the data electronically transmitted between them
Change Log, record of revisions/updates that have occurred over time; a log that can serve as an audit record for
Change Histry activity in a file or record system
attributes or dimensions that could be associated with a chronic condition, including: a) time period
(e.g., childhood, pubescence, constant); b) duration of condition (e.g., brief, extended, sustained,
Chronicity
habitual); c) duration of episode (e.g., sleeping hours, self-limiting, consistent); d) level (e.g., mild,
moderate, or severe condition or pain); e) and/or periodicity or frequency (e.g., a seasonal allergy).
1) use of data to discover, guide and/or justify the proper course of care (or interventions) to support
Clinical Decision
health and health care activities
Support
2) type of system or algorithm (logic) that assists health care providers in making clinical decisions

Page 42 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 1) documents (records) created in the course of supporting health and providing health care serices;
may be used in support of clinical decisions
2) documentation of clinical observations and services, with the following characteristics: a) persistence
Clinical
(a clinical document continues to exist in an unaltered state, for a time period defined by local and
Document,
regulatory requirements); b) stewardship (a clinical document is maintained by a person or organization
Clinical
entrusted with its care); c) potential for authentication (a clinical document is an assemblage of
Documentation
information that may be legally authenticated); d) wholeness – (authentication of a clinical document
applies to the whole and does not apply to portions of the document without the full context of the
document); e) human readability (a clinical document is human readable)
Clinical image non-textual, pictorial depiction of clinical information (e.g., a radiograph, picture, video, or waveform)
data related to the health/health care of an individual collected from or about an individual receiving
health care services. It may include a caregiver’s objective measurement or subjective evaluation of a
patient’s physical or mental state of health; descriptions of an individual’s health history and family
Clinical CPRI:1996
health history; diagnostic studies; decision rationale; descriptions of procedures performed; findings;
information ASTM 1769:1997
therapeutic interventions; medications prescribed; description of responses to treatment; prognostic
statements; and descriptions of socio-economic and environmental factors related to the patient’s
health.
Board on Health Care Services,
Clinical Practice statement that includes recommendations intended to optimize patient care. It is informed by a US Institute of Medicine (IOM),
Guideline (CPG) systematic review of evidence and an assessment of the benefits and harms of alternative care options. National Academies of
Science:2011
the set of interrelated or interacting health care activities performed by one or more health care
Clinical process ISO 18308:2011
professionals
Clinician health professional who delivers health services directly to a patient/client ISO 12773-1:2009
Clinical tasks discrete health and health care actions whose results are recorded in clinical documents
group of keys or indices used for encoding data elements, such as tables of terms, medical concepts HIPAA:1996, modified
Code set(s)
(e.g., medical diagnostic codes or medical procedure codes) ISO 21089:2018
organized, managed collection of codes, each of which has associated designations, meanings and in HL7 Vocabulary Work Group,
Coding system
some cases relationships, properties or rules modified
collection of rules that maps the elements of one set on to the elements of a second set. Note: The two
ISO 18308:2011
Coding Scheme sets considered here are: a) a set of ‘code meanings’ (or ‘coded set’), and b) a set of ‘code values’ (or
ISO/IEC 2382-4:1999
‘code set’). Those sets are not, per se, part of the coding scheme.
Coded references a vocabulary, code set or value set (e.g., SNOMED, LOINC)
1) group of individuals who share a common exposure, experience or characteristic
Cohort 2) study group of individuals, some of whom are exposed to a variable of interest, in which subjects are American Medical Association
followed over time. Cohort studies can be prospective or retrospective.
(in the context of Pharmacy) collected body of information detailing the standards of strength, purity,
Compendium
and quality of drugs
 final, assembled and authenticated, health record for an individual. A health record is complete when
a) its contents reflect the diagnosis, results of diagnostic tests, therapy rendered, condition and
Complete Health JCAHO
progress (of the subject of care), and condition (of the subject of care) at discharge, and b) its contents,
Record ISO 21089:2018
including any required clinical résumé or final progress notes, are assembled and authenticated, and all
final diagnoses and any complications are recorded without use of symbols or abbreviations.
(record) extent to which relevant records are present and the fields in each record are populated
Completeness ISO 21089:2018
appropriately
ISO 18308:2011
Concept unit of knowledge created by a unique combination of characteristics
ISO 1087-1:2000
1) (not disclosed) property that information is not made available or disclosed to unauthorized
individuals, entities or processes
ISO 13606-4:2019, modified (1)
2) (controlled release) condition in which information is shared or released in a controlled manner
US National Research Council (2)
3) (labeling) status accorded to data or information indicating that it is sensitive for some reason, and
Confidentiality US Office of Technology
that therefore it needs to be protected against theft or improper use and must be disseminated only to
Assessment (3)
individuals or organizations authorized to have it
JCAHO (4)
4) (need to know) restriction of access to data and information to individuals who have a need, a reason
and permission for access
to comply. Note: The verb ‘Conform’ is used with a special meaning in the FM and is not part of the
Verb Hierarchy. Instead it is a special instruction for including the functional requirements of one
Conform
function in another function. For example: “The system SHALL conform to function TI.1.1 (Entity
Authentication)...”.
HL7 EHR-S/PHR-S Functional
Conformance fulfillment of specified requirements by a product, process, or service. Model Chapter 2: Conformance
Clause
HL7 EHR-S/PHR-S Functional
Conformance statements of requirement indicating the behavior, action, capability that constitutes implementation of
Model Chapter 2: Conformance
Criteria the function
Clause
HL7 EHR-S/PHR-S Functional
Conformance section of a specification that defines the requirements, criteria, or conditions to be satisfied in order to
Model Chapter 2: Conformance
clause claim conformance
Clause
HL7 EHR-S/PHR-S Functional
Conformance statement associated with a specific implementation of a profile of the EHR-S or PHR-S Functional
Model Chapter 2: Conformance
statement Model.
Clause
1) agreement, approval, or permission as to some act or purpose given voluntarily by a competent
person ISO 18308:2011 (1)
Consent, 2) communication process between the caregiver and the (subject of care), and which may refer to CPRI (2)
Informed Consent consent for treatment, special procedures, release of information and advance directives [which give Canadian Institute for Health
instructions regarding the (subject of care's) wishes in special medical situations] Information (CIHI) (3)
3) voluntary agreement with what is being done or proposed (express or implied)
Consumer (in 1) individual who may become a subject of care
relation to 2) person who is the receiver of health-related services and who is an actor in a health information
ISO 12773-1:2009 (1)
healthcare system
services) 3) person requiring, scheduled to receive, receiving or having received a healthcare service
Page 44 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
Continuity of component of patient care quality consisting of the degree to which the care needed by a patient is
ISO 21089:2018
Care coordinated among practitioners and across organizations and time
1) (identity) data that are transferred to establish the claimed identity of an entity
ISO/IEC 2382:2015 (1)
Credentials 2) (healthcare practice) documented evidence of (a healthcare professional's) licensure, education,
JCAHO (2)
training, experience, or other qualifications
Criteria expected level(s) of achievement, or specifications against which performance can be assessed JCAHO
Critical Value, diagnostic result (e.g., from laboratory, radiology, pathology) on a patient that must be reported
Panic Value immediately to the care provider and which may require urgent therapeutic action or intervention
1) medication that a patient is actively using, either on a regular basis or on an ad hoc basis (e.g., “two
Current pills as needed for pain”)
medication 2) medication that has been dispensed to a patient and whose administration has not yet been
completed according to the medication’s intended duration, dose, frequency, and quantity
user interface based on predetermined reports, indicators and data fields, upon which the end user can
Dashboard apply filters and graphical display methods to answer pre-determined business questions, which is
often intuitive and suited to regular use with minimal training
(healthcare) information elements which are input, stored, processed or output by the automated
Data
information system which support the clinical and business functions of a healthcare organization
process by which data is collected, manipulated and expressed in summary form to provide information.
Data aggregation Data aggregation is primarily performed for reporting purposes, policy development, health service ISO TS 18308:2011
management, research, statistical analysis, and population health studies.
Data Attribute,
Data Element, single unit of data that in a certain context is considered indivisible ISO 21089:2018
Data Item
for the uses intended, subject (data) elements that are clear and well defined enough to yield similar
Data Consistency ISO 21089:2018
results in similar analyses
A person who transfers content, written or dictated by someone else, into a clinical document. The
guiding rule of thumb is that an author provides the content found within the header or body of the
Data Enterer document, subject to their own interpretation, and the Data Enterer adds that information to the
electronic system. In other words, a Data Enterer transfers information from one source to another
(e.g. transcription from paper form to electronic system).
1) (non-alteration) property that data has not been altered or destroyed in an unauthorized manner ISO 7498-2:1998 (1)
Data Integrity
2) (wholeness) accuracy, consistency and completeness of data/record content JCAHO, modified (2)
 Olsen, Jack E., Data Quality: The
Accuracy Dimension, Morgan
Kaufmann Publishers, San
1) degree to which a given data set satisfies the requirements of its intended use Francisco, CA, 2003 (1,2)
2) aggregate construct composed of conformance with end-use requirements including specifications Kahn, MG, Raebel, MA, Glanz,
Data Quality for accurate, timely, relevant, complete, understood, and trusted JM, Riedlinger, K and Steiner, JF.
3) fitness for use for a particular task A Pragmatic Framework for
4) conformance with a specification for a defined end-use Single-site and Multisite Data
Quality Assessment in Electronic
Health Record-based Clinical
Research. Med Care. 2012 (3)
for the uses intended, subject (data) elements that demonstrate accuracy, completeness, integrity,
Data Reliability JCAHO, modified
stability, repeatability and precision
Data sending of data or information from one location to another location; exchange of data between person CPRI
Transmission and program, or program and program, when the sender and receiver are remote from each other JCAHO
1) process used to determine if data are accurate, complete, or meet specified criteria. Note: Data
Data Validity, validation may include format checks, completeness checks, check key tests, reasonableness checks, ISO/IEC 2382-8:1998 (1)
Data Validation and limit checks JCAHO (2)
2) verification of correctness (reflecting the true situation)
Decision support
See "Clinical Decision Support"
system
1) process of making encrypted data reappear in its original unencrypted form; reversal of a ISO 7498-2:1989 (1)
Decrypt,
corresponding reversible encipherment HL7 v3 ObligationPolicy value set,
Decryption
2) decode or render information readable by algorithmically transforming ciphertext into plaintext modified (2)
De-identification process of removing the association between a set of identifying data and the data subject ISO 25237:2008
Delegate give authority, function, or responsibility to another ISO/IEC 15414:2015, modified
data related to identifying an individual (such as name, date of birth, age, gender, etc.). May also
Demographic
include emergency and other types of contact information for the individual and administrative data
Data
(such as health insurance eligibility)
(data/record content) designate data/record content as obsolete, erroneous or untrustworthy, as
Deprecate ISO 21089:2018
indication against its future use
HL7 EHR-S Functional Model
Derived profile profile created from an existing profile
Chapter 2: Conformance Clause
(data/record content) purge or expunge data/record content stored in electronic or magnetic media,
Destroy ISO 21089:2018
typically based on explicit criteria, so that it is completely unreadable and cannot be accessed or used
1) electronic signature based upon cryptographic methods of originator authentication, computed by
using a set of rules and a set of parameters such that the identity of the signer and the integrity of the
data can be verified
HIPAA (1)
Digital Signature 2) data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data
ISO 7498-2:1998, modified (2)
unit to prove the source, signer and integrity of the data unit and protect against forgery; this term is
usually reserved for digital values or checksums calculated using asymmetric techniques, where only
the originator of the message can generate the digital signature but many people can verify it
Directive instruction how to proceed or act
Page 46 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
Directory index or catalog of entities (e.g., individuals or organizations)
Disable-Access
release, transfer, provision of access to, or divulging in any other manner of information outside the
Disclose HIPAA
entity holding the information
(health information) release of information to third parties within or outside the healthcare provider
Disclosure organization from an individual's (health) record with or without the consent of the individual to whom CPRI
the record pertains
Disease system of coordinated healthcare interventions and communications for persons and populations with
management particular sickness, illness or ailment
Discrete capture (data) input of an individual item of data
Discrete data data that contains distinct or separate values
Dispense (a
[See "Fill (a prescription or a medication order)"]
medication)
Document See "Clinical Document"
Documentation process of recording information in the (health) record JCAHO
to copy or move programs or information into a computer's memory, especially from a large datastore
Download
or the internet
(of care) degree to which the care is provided in the correct manner, given the current state of
Effectiveness JCAHO
knowledge, to achieve the desired or projected outcome for the subject of care (patient)
e.g. for example ("exempli fratia" in Latin)
electronic health record
EHR
See "Electronic Health Record"
EHR-S FM HL7 Electronic Health Record System Functional Model
1) comprehensive, structured set of clinical, demographic, environmental, social, and financial data and
information in electronic form, documenting the health care given to a single individual
2) Information relevant to the wellness, health and health care of an individual, in computer-processable
form and represented according to a standardized information model
3) repository of (organized sets of) information regarding the health of a subject of care, in computer ASTM E1769:1995 (1)
Electronic Health processable form ISO 18308:2011 (2)
Record 4) a virtual compilation of non-redundant health data about a person across a lifetime, including facts, ISO 20514:2015, modified (3)
observations, interpretations, plans, actions, and outcomes. Health data include information on CPRI:1995 (4)
allergies, history of illness and injury, functional status, diagnostic studies, assessments, orders,
consultation reports, treatment records, etc. Health data also include wellness data such as
immunization history, behavioural data, environmental information, demographics, health insurance,
administrative data for care delivery processes, and legal data such as consents
Electronic Health
Record generic structural components from which all EHRs are built, defined in terms of an information model ISO 18308:2011
Architecture
Electronic Health ISO 18308:2011
system for recording, retrieving and handling information in electronic health records
Record System ISO 13606-1:2019
 Electronic
Consult (e- healthcare consultation carried out remotely using audiovisual telecommunications between doctor and
Consult), subject of care (patient)
Teleconsultation
Electronic
Referral (e- an act of referring someone (typically to a specialist) for consultation, review, or further action via an
Referral), Tele- electronic service
referral
Electronic
electronic sound, symbol, or process, attached to or logically associated with a contract or other record
Signature (e-
and executed or adopted by a person with the intent to sign the contract or record
Signature)
in occupational health, the company, organization, or individual that provides compensation (either HL7 Occupational Data for Health
Employer
direct or indirect) for a job, as reported by the person. Project
in occupational health, a person's self-reported, coded economic relationship to work (e.g. having one
Employment or more jobs) for a specified time period. Generally, employment status refers to whether or not a HL7 Occupational Data for Health
Status person has at least one job (i.e., is working for compensation), unemployed (i.e., searching for work for Project
compensation), or not in the labor force (e.g., disabled, chooses not to work, etc.).
interaction between a subject of care (patient) and care provider(s) for the purpose of obtaining and/or
Encounter
providing healthcare-related service(s)
encode or render information unreadable by algorithmically transforming plaintext into ciphertext where HL7 Version 3 Standard: Security
Encrypt data are temporarily re-arranged into an unreadable or unintelligible form for confidentiality, and Privacy Ontology, Release 1,
transmission, or other security purposes modified
US Office of Technology
Encryption process of encoding a message so that its meaning is not obvious
Assessment
commercial or industrial activity or organization or business that has specific social objectives that serve
Enterprise
its primary purpose
1) physical, digital, conceptual, or other kind of thing with some fixed aspects, such as a person, body,
or object
Entity W3C, modified (1)
2) something or someone that has a separate, distinct and identifiable existence; something or
someone that has a unique identity (e.g., a person, an organization)
Entry [See "Record Entry"]
1) noteworthy occurrence that has a location in time and space
2) (patient) anything that takes place or happens to the patient or is related to the patient, especially
HL7 Reference Information Model
Event something important such as an incident (e.g. adverse event), procedure or diagnosis
(3)
3) (trigger) stimulus that causes a noteworthy change in the state of an object, or a signal that invokes
the behaviour of an object
1) (demonstrate truth) everything that is used to determine or demonstrate the truth of an assertion
Evidence ISO 21089:2018
2) (fulfill burden of proof) currency by which one fulfills the burden of proof
(information) act of people and organizations passing information from one to another, especially
Exchange
electronically
Explicit Consent permission that is freely and directly given, expressed either viva voice or in writing. ISO 18308:2011

Page 48 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 (information) Refers to an information object captured from outside the immediate system (e.g., EHR
Externally-
system), e.g., faxes, referral authorizations, consultant reports, laboratory results, encounter notes from
Sourced
another healthcare organization
1) select, copy out or cite a set of health data/record content, typically based on explicit criteria
Extract ISO 21089:2018
2) remove for separate consideration or publication.
record of health information about a subject of care's (patient's) close relatives; including e.g.,
Family History
disorders, environment, lifestyle, age at and cause of death
Fast Track route, course, or method that provides for more rapid results than usual
Death prior to the complete expulsion or extraction from its mother of a product of human conception,
irrespective of the duration of pregnancy and which is not an induced termination of pregnancy. The
Fetal Death death is indicated by the fact that after such expulsion or extraction, the fetus does not breathe or show
any other evidence of life, such as beating of the heart, pulsation of the umbilical cord, or definite
movement of voluntary muscles.
Fill (a prescription assign, count, label, and disburse/transport dose(s) of a medication in preparation for administration to
or a medication a subject of care (patient). Note: In the FM the term "fill" represents the combined notions of
order) medication filling and prescription.
Filter ability to programmatically separate and constrain data into specific value sets
tabular summary of information that is arranged to display the values of variables as they change over
Flow Sheet CEN TC251
time
functional model, (i.e., HL7 Electronic Health Record System Functional Model, HL7 Personal Health
FM
Record Functional Model)
preferred list of drug products that typically limits the number of medications available within a
therapeutic class for purposes of purchasing, ordering, dispensing, administration and reimbursement.
Formulary
A government body, third-party insurer or health plan, or a provider organization may compile a
formulary and its constraints may be mandatory.
1) computation which takes some arguments or inputs and yields an output; any particular input yields
Function the same output every time.
2) subroutine (software process) which returns a value
Generic Orders general diagnostic or treatment orders
1) genetic makeup, as distinguished from the physical appearance, of an organism or a group of
organisms American Heritage Science
Genotype
2) combination of alleles located on homologous chromosomes that determines a specific characteristic Dictionary:2005
or trait
Genetic Disorder
(also Genetic disease or condition caused by an absent or defective gene or by a chromosomal aberration (e.g., American Heritage Science
Illness, Inherited Down Syndrome) Dictionary:2005
Disorder)
1) indication or outline of recommendations (e.g., for use/guidance in clinical practice)
Guidelines 2) systematically developed statements to assist practitioner and patient decisions about appropriate
health care for specific clinical circumstances
 activities, services, or supplies related to the health of an individual, including: a) preventative,
diagnostic, therapeutic, rehabilitative, maintenance, or palliative care, counselling, service, or procedure
HIPAA
Health Care, with respect to the physical or mental condition, or functional status, of a patient or affecting the
ISO 18308:2011
Healthcare structure or function of the body; b) sale or dispensing of a drug, device, equipment, or other item
ISO 21089:2018
pursuant to a prescription; or c) procurement or banking of blood, sperm, organs, or any other tissue for
administration to patients
Health Care
Activity,
undertakings (such as assessments, interventions) that comprise a healthcare service ISO 12773-1:2009
Healthcare
Activity
Health Care
Agent, See "Agent"
Healthcare Agent
Health Care Directory of the European
scientific discipline that is concerned with the cognitive, information processing and communication
Informatics, Standardization Requirements for
tasks of healthcare practice, education and research, including the information science and technology
Healthcare Healthcare Informatics and
to support these tasks
Informatics Telematics v2.1
Health Care
Organization,
See "Health Care Provider"
Healthcare
Organization
Health Care
Party, Healthcare Individual or organization involved in the process of health care ISO 18308:2011
Party
1) (care provision) individual who is entrusted with the direct or indirect provision of defined healthcare
services to an individual subject of care or to populations
Health Care 2) (qualification) person that is authorized by a nationally recognized body to be qualified to perform
Professional, certain health services. Note: The types of registering or accrediting bodies differ in different countries ISO 21089:2018, modified (1,2)
Healthcare and for different professions. Nationally recognized bodies include local or regional governmental CEN 1613:1994, modified (1,2)
Professional agencies, independent professional associations and other formally and nationally recognized
organizations. They may be exclusive or non-exclusive in their territory. Examples of health
professionals are physicians, registered nurses and pharmacists.
Health Care 1) individual or organization licensed, certified or otherwise authorized or permitted to, directly or
ISO 13606-4:2019, modified (1)
Provider, indirectly, administer or provide health care services, to individuals (patients) or populations, in the
ISO 18307:2001, modified (2)
Healthcare ordinary course of business or practice of a profession, including a health care facility
JCAHO, modified (2)
Provider 2) generic term used to describe many types of organizations that provide healthcare services
Health Care
Service, service provided (by a health care provider) with the intention of directly or indirectly improving the
ISO 12773-1:2009
Healthcare health of the person or populations to whom it is provided
Service

Page 50 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 aspect of a person or group’s health that may require some form of intervention. Note: These
interventions could be anticipatory or prospective, such as enhancing wellness, wellness promotion or
illness prevention (e.g., immunization), also symptoms, health problems (not yet diagnosed), diagnoses
Health Condition ISO 12773-1:2009
(known or provisional), e.g., a) diabetes, or physiological changes that affect the body as a whole or
one or more of its parts, b) benign positional vertigo, and/or affect the person’s well-being, c) psychosis,
and/or affect the person’s usual physiological state, d) pregnancy, lactation.
1) information about a person relevant to his or her health
2) any information, whether oral or recorded in any form or medium, that a) is created or received by a
Health healthcare provider, health plan, public health authority, employer, life insurer, school or university, or ISO 18308:2011 (1)
Information healthcare clearing-house; and b) relates to the past, present, or future physical or mental health or HIPAA (2)
condition of an individual; the provision of healthcare to an individual; or the past, present, or future
payment for the provision of healthcare to an individual
Health Insurance
Carrier, Health individual or group plan that provides, or pays the cost of, medical care; may be public or private entity HIPAA, modified
Plan, Payer
concern or situation related to the health of a subject of care, as identified or stated by a specific health
Health Issue ISO 18308:2011, modified
care party
account compiled by healthcare providers of a variety of subject of care (patient) health information,
Health Record JCAHO, modified
such as assessment findings, treatment details and progress notes
Health Record
See "Record Entry"
Entry
1) circumstances, influences, causes or issues that affect or describe a patient’s ability to receive or
respond to treatment, or maintain wellness (including physical, mental, social, spiritual, community,
and/or economic dimensions). A patient's strengths (positive factors) or weaknesses (negative factors)
may impact a patient's care or recovery and may be recorded as part of the EHR to support the
Health-related
development of care plans and treatment options (e.g. coverage by insurance (typically a positive
Factors, Social
factor) versus unemployment (typically a negative factor). Examples of factors include: family support, CDC:2018 (2)
Determinants of
financial support, health insurance levels, good overall health, employment status/type, access to care,
Health
and education level. Heath-related factors may be included in a patient’s problem list (e.g. ambulatory
status, or addictions).
2) conditions in the places where people live, learn, work, and play affect a wide range of health risks
and outcomes
1) (claimed) piece of information used to claim an identity, before a potential corroboration by a
corresponding authenticator ISO 13606-1:2019, modified (1)
Identifier
2) (unique) identity information that unambiguously distinguishes one entity from another one in a given ISO 21089:2018
identity domain
i.e. that is to say or in other words ("id est" in Latin)
Immunization
history of immunization (vaccination) events for a subject of care (patient)
History
Implied Consent consent inferred from signs, actions, or facts, or by inaction or silence ISO 18308:2011
Including indicates a minimum set of values or options which must be instantiated
Indelible impossible to remove or erase ISO 21089:2018
 information, including demographic information collected from an individual, that a) is created or
Individually received by a healthcare provider, health plan employer, or healthcare clearing-house; and b) relates to
Identifiable the past, present or future physical or mental health or condition of an individual, the provision of
HIPAA
Health healthcare to an individual, or the past, present, or future payment for the provision of healthcare to an
Information individual, and i) identifies the individual, or ii) with respect to which there is a reasonable basis to
believe that the information can be used to identify the individual
in occupational health, self-reported title (with associated code) that identifies the kind of business (i.e., HL7 Occupational Data for Health
Industry
primary business activity), conducted by a person's employer. Project
JCAHO, modified
interpreted set(s) of data that can assist in decision making; data to which meaning is assigned,
Information US National Security Council,
according to context and assumed conventions
modified
(message) proof that message content has not altered, deliberately or accidentally in any way, during
transmission
Integrity ISO/IEC 7498-2:1998
See also "Data Integrity"
Interchange standards specifying the form(s), method(s) and mechanisms by which information, typically electronic
standards data, are exchanged
Internet
large open international community of network designers, operators, vendors, and researchers
Engineering Task
concerned with the evolution of the Internet architecture and the smooth operation of the Internet
Force (IETF)
1) (semantic) ability of different information technology systems and software applications to
communicate, exchange data, and use the information that has been exchanged
2) (standards-based) ability for data to be shared across clinicians, laboratory, hospital, pharmacy and
IEEE:1990, modified (1)
Interoperability patient, facilitated by data exchange schema and standards, regardless of the application or application
ISO 21089:2018 (1,2)
vendor; also, ability of health information systems to work together within and across organizational
boundaries in order to advance the health status of, and the effective delivery of healthcare for,
individuals and communities.
Interoperate,
coordinate information, services, and/or functionality among systems
Interoperation
conclusion that a health care provider (or possibly machine - in the form of clinical decision support)
Interpretation comes to based upon knowledge and scrutiny/analysis of information available (e.g., in the course of
diagnosis/treatment of a subject's (patient's) condition
1) action(s) whose purpose is to improve health or to alter the course of a disease
Intervention 3) action(s) taken to maximize the prospects of achieving goals of care, including the removal of
barriers to success
Input mechanism approach, typically utilizing a user interaction device, for data input, (e.g., keyboard and mouse)
non-immunological adverse physiological sensitivity to a substance; may be manifest by an inability to
Intolerance
endure, withstand, absorb, or metabolize a substance (e.g. lactose)
Jurisdictional Law statute and/or legal requirement of a domain or realm
operation that tags or otherwise cues special access management and destruction suspension for
Legal Hold, Record Entries deemed relevant, consistent with organization policy under the legal doctrine of “duty to
ISO 21089:2018
Litigation Hold preserve”, also notifying records owners and other designated parties of the special data controls on
access, retention, and destruction processes
Page 52 HL7 EHR-S FM Release 2.1
© 2020 Health Level Seven International. All rights reserved. June 2020
 operation that untags or otherwise removes cues for special access management and destruction
Legal Hold suspension for record entries as organization policy had required under the legal doctrine of “duty to
Release, preserve”, also notifying records owners and other designated parties of the release of special data
ISO 21089:2018
Litigation Hold controls and that the organization will resume normal data retention and destruction processes; provide
Release notification to the records owners of the release of data and that the organization will resume normal
data retention and destruction processes
Lifecycle (record entry) stages during the lifespan of a health record entry instance ISO 21089:2018
(record entry) operation occurring during the course of record entry instance lifespan such as: originate,
Lifecycle Event ISO 21089:2018
retain, amend (update), attest, exchange (transmit, receipt), access/view
(record entry) period of time from the point of record entry instance origination to the point of record
Lifespan ISO 21089:2018
entry instance loss, destruction or deletion
(record entries) perform an operation that connects (establish a relationship between) two or more
Link separate but related health records so that access or use of one necessarily means equal access to ISO 21089:2018
ability to use of all the connected records
reference to a data record that is independent of its physical location; may be physically stored in two or
Logical Record
more locations
Longitudinal
Personal Health permanent, coordinated record of significant information, in chronological sequence; may include all
Record, Lifetime historical data collected or be retrieved as a user designated synopsis of significant demographic, ASTM E1384:2013
Personal Health genetic, clinical and environmental facts and events maintained within an automated system
Record
Maintain keep, preserve and support
Manage take charge of; master
Management conducting, administering, supervising
1) conceal from view, disguise or hide
2) process of obscuring (masking) specific data elements within data stores. It ensures that sensitive
data is replaced with realistic but not real data. The goal is that sensitive customer information is not
Mask. Masking
available outside of the authorized environment. Effective data masking requires data to be altered in a
way that the actual values cannot be determined or reengineered, functional appearance is maintained,
so effective testing is possible.
dataset containing definitional entries in common across system, business units and, in some cases,
organizational boundaries (e.g., master files may include data group and attribute definitions, security
Master File ISO 21089:2018
policy and domain definitions, security classification and clearance definitions, healthcare service
definitions, care protocol definitions)
Master Patient
catalog within a given healthcare organization which serves as a directory to patients (subjects of care) CPRI, modified
Index
MAY indicates an optional, permissible action
Measure collect quantifiable data about a function or process JCAHO
Medical relating to the study or practice of medicine
 comprehensive evaluation of a patient’s medication regimen any time there is a change in therapy in an
effort to avoid medication errors (e.g., omissions, duplications, dosing errors, or drug interactions), and
to observe the patient’s medication compliance and adherence patterns. The medication reconciliation
Medication American Pharmacists
process should include a comparison of the existing and previous medication regimens and should
reconciliation Association
occur at every transition of care in which new medications are ordered, existing orders are rewritten,
existing orders are adjusted, or if the patient has added nonprescription medications to [his or her] self-
care.
(record entries) perform an operation that combines or joins the content of two or more health records,
Merge resulting in a single logical record entry (e.g., includes health records found to be registered as ISO 21089:2018
separate patients but are really one)
Message logically ordered dataset designed to communicate essential information between systems ISO 21089:2018
Messaging in the context of Health IT, specifies the structure and format of electronic data exchange, enabling
HL7
Standard disparate healthcare applications to exchange key sets of clinical and administrative data
ISO/IEC 11179-3:2003
Metadata data that define and describes other data
ISO 1087-1:2000
requirement for access to, knowledge, or possession of the classified information in order to perform
Need-to-Know ISO/IEC 2382:2015, modified
tasks, functions or services
electronic data transmission facility which can comprise just a point-to-point wire link between two
Network ISO 21089:2018
devices, or a complex arrangement of transmission lines
(of origination, of submission, of receipt) service that provides proof of the integrity and source of data
Non-repudiation (both in an unforgeable relationship) and that only the signer could have created the associated ASTM E1762:2013, modified
signature, which can be verified by any party
brief record of facts, topics, or thoughts, often captured as an aid to memory; clinical documents are
Notes
forms of clinical notes
Notice, information presented or transmitted to an interested party; may not require recipient's action or
Notification response
Obfuscation action of making something obscure, unclear, or unintelligible
in occupational health, self-reported title (with an associated code) that identifies a person's type of
HL7 Occupational Data for Health
Occupation work, i.e., the set of activities or tasks that a person is paid to perform or, if unpaid, the person’s
Project
contribution to a household/family business/community
On-Demand as soon as or whenever required
prescription of a qualified health care professional regarding diagnostic testing and/or treatment of a
Order
subject of care (patient)
1) pre-defined template that provides support in making clinical decisions for a specific condition or
medical procedure
Order sets
2) a grouping of orders that standardizes and expedites the ordering process for a common clinical
scenario
(record entry) create or initiate an entry in a persistent datastore, such as an electronic or personal
Originate ISO 21089:2018
health record (EHR/PHR)
unique framework of authority within which a person or persons act, or are designated to act towards
Organization ISO 6523:1998
the same purpose

Page 54 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 generally adopted by a governance body within an organization:
Organizational
1) deliberate system of principles to guide decisions and achieve rational outcomes
Policy
2) statement of intent, typically implemented as a procedure or protocol
1) result of the performance (or non-performance) of a function or process(es)
Outcome JCAHO, modified
2) condition or occurrence traceable to a cause
produce and deliver health record content in the form and manner expected by a viewer or recipient
Output ISO 21089:2018
(e.g., printout, visual rendering, tagged or delimited data stream)
natural person or any other entity considered to have the same rights, powers and duties of a natural
Party ISO/IEC 15414:2015
person
1) subject of care
Patient 2) individual who is receiving or registered as eligible to receive healthcare services or having received ISO 21089:2018, modified (2)
healthcare services
Patient and
health care treatment choices influenced by but not limited to language, religious, or cultural
Family
preferences selected by the subject of care (patient) and his/her family
Preferences
Patient Identifier set of data that is used for uniquely distinguishing one patient from another patient
Patient Record See "Health Record"
Patient designated to bearing the character or power of the patient; acting for the patient’s benefit, e.g.
UK CancerWeb
Representative guardian, legal representative, surrogate, or advocate
Patient Safety See "Safety"
within the context of the Population Health arena, refers to data that is collected (and analyzed)
Patient-Level
regarding a single patient (e.g., “Person123 is left-handed”). Note: patient-level data may be de-
Data
identified.
Data provided and/or entered by the subject of care (patient), e.g., an individual (or their representative)
Patient- American Academy of
may provide or enter health information from personal memory and/or by using information that was
Originated Data Pediatrics:2011
recorded on a piece of paper
way in which an individual, group or organization carries out, accomplishes and fulfils its important
Performance JCAHO, modified
functions and processes, usually with regard to effectiveness
Performance
standard or criteria used to assess the capabilities of functions, processes and outcomes within an
Indicator,
organization; quantification of processes and outcomes using one or more dimensions of performance, JCAHO, modified
Performance
such as timeliness or availability.
Measure
affirmation or agreement, provided by the parent or guardian of a patient, to undertake a clinical action;
in most cases, clinicians have an ethical (and legal) obligation to obtain parental permission to
Permission American Academy of
undertake recommended medical interventions
(Parental) Pediatrics:2011
See also "Consent, Informed Consent"
1) data in a final form intended as a permanent record, such that any subsequent modification is
Persistent recorded together with the original data ISO 21089:2018 (2)
2) existing or remaining in the same state for an indefinitely long time
 1) information about an identifiable person which relates to the physical or mental health of the
individual, or to provision of health services to the individual, and which may include: a) information
about the registration of the individual for the provision of health services; b) information about
payments or eligibility for healthcare with respect to the individual; c) a number, symbol or particular
Pesonal Health assigned to an individual to uniquely identify the individual for health purposes; d) any information about ISO 27799:2008 (1)
Information (PHI) the individual collected in the course of the provision of health services to the individual; e) information MEDSEC (2)
derived from the testing or examination of a body part or bodily substance; f) identification of a person
(e.g. a health professional) as provider of healthcare to the individual
2) information that concerns a person's health, medical history, medical treatment or genetic
characteristics in a form that enables the person to be identified
Personal Health health record, or part of a health record, for which the subject of care or a legal representative of the
ISO 18308:2011
Record (PHR) subject of care is the data controller
physical appearance of an organism as distinguished from its genetic makeup; the phenotype of an
American Heritage Science
Phenotype organism depends on which genes are dominant and on the interaction between genes and
Dictionary:2005
environment
personal health record
PHR
See "Personal Health Record"
PHR-S FM HL7 Personal Health Record System Functional Model
1) provides the PHR Account Holder with: a) access to his or her personal health data and b) access to
the functions of a PHR system
2) conceptually similar to a bank account (e.g., health record bank), which provides controlled access
PHR Account
to data and to the functions of the system in which the data are stored; may be hosted on a stand-alone
personal computer, within an EHR system (i.e., as a portal), a web-based system, or other portable
electronic device
1) subject of the PHR Account, controls access to and permissions of the PHR Account, and controls
the movement of data in and out of the PHR Account
PHR Account 2) synonymous with the terms “patient” or “consumer.”
Holder Note: In certain PHR Account matters related to decision making, the term PHR Account Holder is also
meant to include the PHR Account Holder Proxy, as he or she may be the PHR Account Holder’s
substitute decision maker.
PHR Account person who is appropriately authorized to act on behalf of the PHR Account Holder within the PHR
Holder Proxy Account; could be a family member, friend or substitute decision maker
set of software that offers PHR functionality and related services to PHR Account Holders through
PHR Application
individual PHR Accounts
permission granted by a PHR Account Holder to an Authorized PHR User to use function(s) of the PHR
System for intended and permitted purposes. PHR Authorizations may be to specific individuals or to
PHR specific remote computer systems. PHR Authorizations also may be role-based, i.e., granted to a class
Authorization of individuals or a class of remote computer systems. PHR Authorizations may include varying levels of
access, e.g., “read-only,” “write-only,” “read/write,” etc. The exact permissions and levels of PHR
Authorizations may vary based on different PHR Sponsors and PHR Service Providers.

Page 56 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 organization that delivers PHR Application(s) to PHR Account Holders. A PHR Service Provider may
offer PHR Applications directly to PHR Account Holders or indirectly via contracted PHR Sponsors.
PHR Service PHR Service Providers are often PHR system vendors, enabling the distinction between direct PHR
Provider Application providers and third-party sponsors (such as physician offices or hospitals).

See "PHR Sponsor".

entity that provides PHR Account Holders access to a given PHR Application (e.g., a physician office, a
PHR Sponsor health system, an employer, a pharmacy, a health plan). A PHR Sponsor may not necessarily be the
same entity as the PHR Service Provider.
1) set of rules related to a particular purpose. A rule can be expressed as an obligation, an
authorization, a permission or a prohibition. ISO/IEC 15414:2015 (1)
Policy
2) formal, approved description of how a governance, management of clinical care process is defined, JCAHO (2)
organized and carried out
1) art, process, science and a product of enhancing the health condition of a specific number of people
within a given geographical area
Population Health
2) health outcomes of a group of individuals, including the distribution of such outcomes within the
group
Practice
See "Guideline"
Guideline
actions taken to:
1) reduce susceptibility or exposure to health problems (primary prevention)
Prevention
2) detect and treat disease in early stages (secondary prevention)
3) alleviate the effects of disease and injury (tertiary prevention)
records captured and maintained for the chief purpose of: a) supporting individual health and providing
Primary Record ISO 21089:2018
healthcare; b) clinical use including care, interventions and decision making
highest in rank, authority, character, importance, or degree; most considerable or important; chief; main
Principal
(e.g., principal diagnosis)
healthcare provider who is the most responsible and accountable for managing or coordinating the
Principal provider
members of a care team(s) that deliver health care to an individual
Principle an accepted or professed rule of action or conduct, an adopted rule or method for application in action
1) quality or state of being hidden from, or undisturbed by, the observation or activities of other persons
2) freedom from intrusion into the private life or affairs of an individual when that intrusion results from
undue or illegal gathering and use of data about that individual and the ability of an individual or group AHIMA, modified (1,2,3)
to seclude themselves, or information about themselves, and thereby express themselves selectively ISO/IEC 2382-8:2015, modified
Privacy
3) right of individuals to keep information about themselves from being disclosed to anyone (2,3)
4) (information practices) security principle that protects individuals from the collection, storage and HL7 Security Work Group (4)
dissemination of information about themselves and the possible compromises resulting from
unauthorized release of that information
Problem (clinicial) issue for which an assessment is made and a plan or intervention is initiated ISO 12773-1:2009, modified
 1) list that includes the most important health problems facing a subject of care (patient) such as
nontransitive illnesses or diseases and injuries suffered; may include signs and symptoms
US Centers for Medicare and
Problem List 2) list of a patient's problems that serves as an index to his or her record
Medicaid Services (CMS) (3)
3) list of current and active diagnoses as well as past diagnoses relevant to the current care of the
patient
sequence of goal-directed, interrelated series of actions, events, mechanisms, or steps taking place in a
Process ISO/IEC 15414:2015, modified
prescribed manner and leading to the accomplishment of some result
(EHR or PHR System) Functional Model subset, in which functions have been designated for particular
HL7 EHR/PHR System Functional
purposes, domains, services, specialties or care settings. A Functional Profile (FP) allows selection of
Profile Model Chapter 2: Conformance
functions and conformance criteria from the base FM, as well and revisions and extensions to those
Clause
functions and criteria.
1) (care) written plan specifying the procedures to be followed in giving a particular examination,
conducting research, or providing care for a particular condition
Protocol (2) set of instructions that describe the procedure to be followed when investigating a particular set of ISO 21089:2018 (1)
findings for a subject of care (patient), or the method to be followed in the management of a given
disease
phrase that conveys the notion that the corresponding FM-specified system functionality will enable a
Provide the ability
user to perform a given task, rather than having the system perform the task itself (i.e., without user
to ...
intervention)
Provider See "Health Care Provider"
1) removal of individually identifiable data/record content by replacing with identity-bearing content for
Pseudonymize,
another entity ISO 25237:2017, modified
Pseudonymizatio
2) sub-class of de-identification which can be performed with or without the possibility of re-identifying ISO 21089:2018, modified
n
the subject of the data/record content
1) area of health care that deals with the health of populations in geo-political areas, such as States and
Public Health counties Dorland's Medical Dictionary
2) field of medicine concerned with safeguarding and improving the health of the community as a whole
1) (of use) context and conditions of data/record use at a specific point in time, and within a specific
ASTM 1986:2013, modified (1)
Purpose setting
ISO/IEC 15414:2015 (2)
2) (of a system) practical advantage or intended effect of the system
1) character, characteristic or property of anything that makes it good or bad, commendable or
reprehensible, thus the degree of excellence that a thing possesses JCAHO, modified
Quality
2) totality of features and characteristics of a product or service that bear on its ability to satisfy stated CEN TC251, modified
or implied needs or fitness for use.
Quality approach to the continuous study and improvement of the processes of providing healthcare services to
JCAHO
Improvement meet the needs of patients and others
(record entry) recreate or restore full status to health records and their content from a previous state of
Reactivate ISO 21089:2018
deletion or deprecation
actual time during which something takes place; the system may partly analyze the data in real time (as
Real-time
it comes in)
capture an exchange artifact (e.g., message, document, API resource) from an external system or
Receive ISO 21089:2018
entity (e.g., acquire data objects that exist elsewhere for potential inclusion in an EHR or PHR record)

Page 58 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 a suggestion or proposal as to the best course of action, especially one put forward by an authoritative
body
Recommendation
See "Guidance"
Record See "Health Record"
1) (evidentiary) persistent documentation, recording or evidence of facts, context, findings and
observations, with associated supporting system data or metadata, regarding an action taken to support
individual health or provide healthcare
ISO 21089:2018 (1,2)
2) (indivisible notation) semantically indivisible clinical statement which may be structurally large or
Record Entry ISO 18308:2011, modified (3)
small, but which loses meaning if broken up
ISO 13606-2:2019, modified (3)
3) (instance) discrete notation, recording instance or dataset in (EHR/PHR/other) system datastore,
suitably attributed, which forms part of, or a whole, contribution to a health(care) record at one place
and time
1) directory-like system that focuses solely on managing data pertaining to one conceptual entity
Canada Health Infoway (1)
Registry 2) server capable of holding data for the systematic and continuous follow up of information objects
ISO 21089:2018
maintained in accordance with specific rules
restore information to data that would allow the identification of the source of the information or the HL7 Version 3 Standard: Security
Re-identify
information subject and Privacy Ontology, Release 1
Release of
disclosure of documents containing (subject of care-) identifiable information to a third party requestor CPRI
Information
type of notification that is specifically to prompt the recipient with information they may have previously
Reminder
received (e.g. an appointment reminder); distinct from an alert, where immediate action is required
1) make or present an official or formal account or summary of
Report ISO 21089:2018
2) formal rendering (e.g., document) that gives information about a particular subject
Repudiate, denial by a user or a system that it was the source of certain information or the sender or receiver of a
ASTM E1762:2013, modified
Repudiation message or the agent of an action requested from the system
entity which is essential to some behaviour and which requires allocation or may become unavailable
Resource ISO/IEC 15414:2015
because it is in use or used up
1) process of making the best use of available resources in order to achieve a particular objective
Resource
2) total amount of resources consumed, compared against the amount of resources planned for a
Utilization
specific process
1) (record entry) recreate record entries and their content from a previously created archive artifact
ISO 21089:2018
2) produce another object with the same content as one previously backed up (i.e., recreate a readily
Restore HL7 Version 3 Standard: Security
usable copy) or reinstate an information system back to an error-free and secure state from which
and Privacy Ontology, Release 1
normal operation can resume
1) conclusion or end to which any course or condition of things leads, or which is obtained by any
process or operation
Result
2) set of information including all essential or useful data relevant to the outcome of an analytical
investigation and corresponding procedure (e.g., diagnostic findings)
(record entry) store and maintain (in a persistent datastore) health records after their point of
Retain ISO 21089:2018
origination, update, receipt, re-identification, restoration, decryption, etc.
 maintenance and preservation of information in some form (e.g. paper, microfilm, or electronic storage)
Retention CPRI
for a given period of time
Role function or responsibility assumed by a person in the context of a health care event
1) (normative) quality of a product to meet applicable standards and practices for design, construction
or manufacture
2) (patient) prevention of accidental or preventable injuries and mitigation of harm caused by errors of
ISO 21089:2018 (1,2,3)
Safety omission or commission that are associated with healthcare, and involving the establishment of
US National Quality Forum (2)
operational systems and processes that minimize the likelihood of errors and maximize the likelihood of
intercepting them when they occur
3) (perceived) users' level of comfort and perception of risk
Save keep (data) by moving a copy to a storage location
services that a qualified health professional is deemed competent to perform, and permitted to
Scope of Practice
undertake in keeping with the terms of their professional license
smooth and continuous, with no apparent gaps or spaces between one part and the next; perfectly
Seamless
cosistent and coherent
1) record that is derived from the primary record and contains selected data elements
Secondary Data ASTM E1384:2013
2) record that is derived/extracted from the primary record for specific purposes of use
1) (data) combination of availability, confidentiality, integrity and accountability including protection of
data from intentional, accidental or unintentional alteration or destruction, or copying or disclosure to CEN 13608-1:2005 (1)
unauthorized persons, whether in storage, processing, or transit JCAHO (1)
Security 2) (system safeguards) result of effective protection measures including safeguards for protection of MEDSEC, modified (1)
information systems against software deficiencies, operating mistakes, or sabotage, against the denial US National Security Council (2)
of service to authorized users or the provision of service to unauthorized users, including those US Institute of Medicine (2)
measures necessary to detect, document and counter such threats
1) (information) set of laws, rules, and practices that regulate how an organization manages, protects US Department of Defense (1)
and distributes sensitive information ISO/IEC 2382:2015 (2)
Security Policy
2) (system) plan or course of action adopted for providing computer security including a statement of US Office of Technology
information values, protection responsibilities and organization commitment for a system Assessment (2)
Send See "Transmit"
signal of urgency or escalation; relative impact of a situation; may be used by people responding to an
Severity Level
incident as a way to describe their current assessment of a situation to relay to others
Semantic
See "Interoperability"
interoperability
Indicates a mandatory requirement to be followed (implemented) in order to conform. Synonymous with HL7 EHR-S Functional Model
SHALL
“is required to”. Chapter 2: Conformance Clause
Indicates an optional yet recommended action, one that is particularly suitable. Synonymous with “is HL7 EHR-S Functional Model
SHOULD
permitted and recommended”. Chapter 2: Conformance Clause
instructions that direct a patient regarding the recommended use of a medication (abbreviation for
SIG
Signetur – “Let it be labeled” - in Latin)
Single Logical
See "Logical Record"
Patient Record

Page 60 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 HL7 EHR/PHR Syste Functional
Situational
criterion that is required if the circumstances given are applicable Model Chapter 2: Conformance
Criterion
Clause
Social
Determinants of See "Health-related Factors"
Health
Specialized customized view which may be based on encounter specific values, clinical protocols and business
Views rules
1) document, established by consensus and approved by a recognized body, that provides, for common
and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the
achievement of the optimum degree of order in a given context. Note: Standards should be based on
the consolidated results of science, technology and experience, and aimed at the promotion of optimum
Standard ISO/IEC Guide 2 (1)
community benefits.
2) technical specification which addresses a business requirement, has been implemented in viable
commercial products, and, to the extent practical, complies with recognized standards organizations
such as ISO
specification (guiding principles) that describe responsibilities and define safe practice, including:
professional standards, ethical guidelines, entry-level competencies, provincial/regional regulations,
Standards of
standards of care, and practice guidelines
Practice
See "Guidelines" and "Safety"
Store See "Save"
Structured Data data that can be slotted into discrete fields and enumerated or codified
one or more individuals scheduled to receive or who are receiving or have received health care
ISO 12773-1:2009, modified
Subject of Care services. Note: The terms “patient” and “client” are synonymous with subject of care in a health record
ISO 13606-1:2018. modified
context and are commonly used instead of the more formal term “subject of care”.
Suitable possessing the qualities that are right, needed, or appropriate for the task or use ISO 21089:2018
Summary abbreviated version of something that has been said or written, containing only the main points
Syntactic
See "Interoperability"
Interoperability
Systematic pursuing defined objective(s) in a planned, step-by-step manner JCAHO
Unit of work. A task (in health care) may be a clinical task (i.e., a task that occurs as part of the process
of providing care for a patient) or a non-clinical task (e.g., an administrative task such as updating the
list of providers who have admitting privileges at the local hospital). A task may arise in an ad hoc
Task
fashion or may appear according to a schedule. A task may be placed on a list and assigned to a
person, a group of people, or to an automated mechanism; a task may also be shared, reassigned,
prioritized (or re-prioritized), routed, corrected, updated, cancelled, or suspended.
Term word or words corresponding to one or more concepts
Terminological
structured human and machine-readable representation of healthcare concepts and relationships
System
 set of services that present and apply vocabularies, both controlled and uncontrolled, including their
Terminology member terms, concepts and relationships. This is done for purposes of searching, browsing,
Services discovery, translation, mapping, semantic reasoning, subject indexing and classification, harvesting,
alerting, etc.
1) data in the form of words or alphabetic characters
Text
2) human-readable sequence of characters
Timestamp digital record of the time of occurrence of a particular event
act of processing a logical unit of information (e.g., data received from an external system may be
Transact Data
committed (or “transacted”) to a local database
1) convert and/or encode source health record content into exchange artifacts such as HL7 v2/v3
Transform, messages, CDA/CCDA documents or FHIR resources
ISO 21089:2018, modified
Transformation 2) convert or change data/record content from one format to another, from one arrangement to another,
from one structure to another
(record entry) convert data content from one coding/classification system to another or from one human
HL7 Version 3 Standard: Security
Translate language to another or express the sense of (words or text) in another language (e.g. English translated
and Privacy Ontology, Release 1
to Spanish)
(record entry) initiate communication of health record content from one system to another; send or
Transmit ISO 21089:2018
convey from one person or place to another; send or forward, as to a recipient or destination
Treatment Option consideration of one of several remedies with the object of effecting a resolution or cure
Treatment Plan See "Care Plan"
Treatment
See "Protocol"
Protocol
Trigger event that causes an action to be taken (e.g., message transmittal)
1) (confidence) have reliance, faith, or hope
Trust ISO 21089:2018
2) assured reliance on the character, strength, or truth of someone or something
Trusted
Information environment which ensures integrity, confidentiality, and availability of data in the process of information
Exchange exchange between participating parties; may be based on a "chain of trust" agreement
Environment
1) quality or state of being true in accordance with the body of real things, events and facts
Truth ISO 21089:2018
2) maintain fidelity to an original or to a standard, proposition or principle.
Unique Identifier See "Identifier"
(record entries) undo an operation that previously connected two or more health records, rendering
Unlink ISO 21089:2018
them separate again
Unmerge (record entries) perform an operation that reverses a previously executed merge operation ISO 21089:2018
Unstructured
data that is not slotted into discrete fields and enumerated or codified; opposite of structured data
Data
Unstructured Text lacking a definite structure or organization; not formally organized or systematized
HL7 Vocabulary Alignment
Update perform an operation that results only in the revision or alteration of an object
Project
transfer (data) from one computer to another, typically to one that is larger or remote from the user or is
Upload
functioning as a server

Page 62 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020
 (of health information) sharing, employment, application, utilization, examination, or analysis of such
Use HIPAA
information
person or other entity authorized by a provider to use some or all of the services provided by the COACH
User
provider OMG
collection of defining attributes that characterize a population of users and their intended interactions
User Role
with the system
confirm that the contents of data objects meet the needs of identified stakeholders (e.g., healthcare Project Management Body of
Validate providers, patients), often involving acceptance and suitability; verify correctness (to reflect the true Knowledge, modified
situation) JCAHO, modified
confirm and notate that record/data content is true, accurate and/or justified based on reviewing,
Project Management Body of
Verify inspecting or testing or evaluate the compliance of data objects with specified requirements based on
Knowledge, modified
organizational policy
Versioning management of multiple revisions of the same unit of information, or of a software application
1) look at attentively or inspect
View 2) representation of an object or collection of objects for use by visual capture, rendered electronically ISO 21089:2018
or in print
Error! Reference source not found. Error! Reference source not found.

Annex C
(informative)

Background

C.1 What is HL7?

Established in 1987, Health Level Seven (HL7) is an American National Standards Institute (ANSI) accredited,
not-for-profit standards-development organization, whose mission is to provide standards for the exchange,
integration, sharing, and retrieval of electronic health information; support clinical practice; and support the
management, delivery and evaluation of health services. ANSI accreditation, coupled with HL7's own
procedures, dictates that any standard published by HL7 and submitted to ANSI for approval, be developed and
ratified by a process that adheres to ANSI's procedures for open consensus and meets a balance of interest
requirement by attaining near equal participation in the voting process by the various constituencies that are
materially affected by the standard (e.g., vendors, providers, government agencies, consultants, non-profit
organizations). This balance of interest goal ensures that a particular constituency is neither refused
participation nor is it allowed to dominate the development and ratification of a proposed standard. More
information and background on ANSI is available on their website at: http://www.ANSI.org

C.2 The HL7 Electronic Health Records Work Group

The HL7 Electronic Health Records Special Interest Group (EHR SIG) was established in the spring of 2002. In
the spring of 2003 the HL7 group began efforts to develop a standardized functional specification for Electronic
Health Records Systems (EHR-S). In May 2004 the SIG was promoted to a full HL7 Technical Committee,
becoming the EHR TC. The EHR TC is intended primarily to serve as a body which promotes the uptake of
Electronic Health Record (EHR) implementation by standardizing the functions that may be present, based on
user selection, in an EHR-S.
The Department of Health and Human Services, the Veterans Health Administration, the Health Information
Management Systems Society and the Robert Wood Johnson Foundation, in a public-private partnership,
approached HL7 to accelerate their existing work to develop a consensus standard to define the functions of an
EHR-S. HL7, through its EHR SIG, responded by developing an EHR-S Functional Model that passed ballot
as a Draft Standard for Trial Use (DSTU) in April 2004. The Functional Model DSTU was published and formally
registered with the American National Standards Institute (ANSI) in July 2004. The Functional Model was then
balloted and passed as a normative standard as part of the January 2007 HL7 Work Group Meeting and is now
registered as a normative standard with ANSI
Learning important lessons from the ballot process, a Functional Model with a clearer, more simplified list of
functions, has been created. The HL7 EHR System Functional Model provides a reference list of functions that
may be present in an Electronic Health Record System (EHR-S). The Function List is described from a user
perspective with the intent to enable consistent expression of system functionality. This EHR-S Model, through
the creation of Functional Profiles, enables a standardized description and common understanding of functions
sought or available in a given setting (e.g. intensive care, cardiology, office practice in one country or primary
care in another country).

Page 65 HL7 EHR-S FM Release 2.1

© 2020 ISO and Health Level Seven International. All rights reserved. June 2020
 Annex D
Bibliography

a) Dick, Richard S. et al. The Computer-Based Patient Record: An Essential Technology. National
Academy Press, Washington, D.C., 1997. ISBN: 0-309-08684-1

b) Johns, Merida L., PhD, RHIA Health Information Management Technology: An Applied Approach, 3rd
Edition. AHIMA, Chicago, IL, 2010. ISBN: 9781584262596

Page 66 HL7 EHR-S FM Release 2.1

© 2020 Health Level Seven International. All rights reserved. June 2020