ehr functional model ballot
TRANSCRIPT
-
8/7/2019 EHR Functional Model Ballot
1/35
ANSI/HL7 EHR SYSTEM FUNCTIONAL MODEL AND STANDARD - 2003AUGUST, 2003
HL7 EHR System
Functional Model and
StandardDraft Standard for Trial Use
Release 1.0, August 2003
Editors: Gary DickinsonMisys Healthcare
Linda Fischetti, RN MS
US Department of Veterans Affairs
Sam Heard, MDOcean Informatics Australia
Copyright 2003 by Health Level Seven, Inc. ALL RIGHTS RESERVED. The reproduction of this
material in any form is strictly forbidden without the written permission of the publisher.
Health Level Seven and HL7 are trademarks of Health Level Seven, Inc.
-
8/7/2019 EHR Functional Model Ballot
2/35
Table of Contents
1 Purpose ................................................................................................................................................... 5
1.1 Overview ........................................................................................................................................ 5
1.2 Identifying Document Ballot Status ............................................................................................... 5
2 Introduction ............................................................................................................................................ 6
2.1 Definitions...................................................................................................................................... 6
2.1.1 Existing EHR System Definitions .......................................................................................... 6
2.1.2 Consumer/Person.................................................................................................................... 7
2.1.3 Healthcare professional .......................................................................................................... 7
2.1.4 Profiles.................................................................................................................................... 7
2.1.5 Functions ................................................................................................................................ 8
2.1.6 Infrastructure Functions.......................................................................................................... 8
2.1.7 Functional Knowledge Base ................................................................................................... 8
2.1.8 Draft Standard for Trial Use (DSTU) ..................................................................................... 8
2.2 Objective ........................................................................................................................................ 9
2.3 History.......................................................................................................................................... 10
2.4 Approach ...................................................................................................................................... 10
3 Model: HL7 Electronic Health Record System Model and Standard.................................................. 10
3.1 Functions ...................................................................................................................................... 11
3.2 Profiles.......................................................................................................................................... 12
4 Functions within Model........................................................................................................................ 12
4.1 Rationale Categories..................................................................................................................... 13
4.2 Rationale For Use ..........................................................................Error! Bookmark not defined.
4.3 Care Delivery Functions............................................................................................................... 18
4.4 Infrastructure Content for the Informative Hierarchy................................................................... 19
4.5 Assumptions for the Informative Hierarchy................................................................................. 19
5 Content Management Components...................................................................................................... 19
-
8/7/2019 EHR Functional Model Ballot
3/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 Version 3 Standard: HL7 Style Guide, Release 1.0. 2003. All rights reserved. Page 3
Draft #1
5.1 Managing content to support information integrity ...................................................................... 19
5.2 Functional Triplets / Expressing Functions .................................................................................. 19
5.2.1 Functional Statement ............................................................................................................ 19
5.2.2 Rationale for use................................................................................................................... 20
5.2.3 Conformance Criteria ........................................................................................................... 20
5.3 Navigational/Summation Hierarchy............................................................................................. 20
5.4 Expressing Profiles....................................................................................................................... 21
5.4.1 Identifying Information ........................................................................................................ 21
5.4.2 Functions Supported............................................................................................................. 21
5.4.3 Inter-profile relationships ..................................................................................................... 21
5.4.4 Metadata ............................................................................................................................... 21
5.5 Terminology and Profile Semantics ............................................................................................. 21
5.6 Developing a profile ..................................................................................................................... 22
5.7 Care Setting Profiles..................................................................................................................... 22
5.7.1 Profile Management ............................................................................................................. 22
6 Foundations .......................................................................................................................................... 23
6.1 HDF.............................................................................................................................................. 23
6.1.1 RIM ...................................................................................................................................... 23
6.1.2 Clinical Document Architecture........................................................................................... 24
6.1.3 Artifacts and Representations............................................................................................... 24
6.1.4 Conformance ........................................................................................................................ 24
6.1.5 Tooling ................................................................................................................................. 24
7 Chapter 6: Future................................................................................................................................. 25
7.1 Next Steps..................................................................................................................................... 25
7.1.1 Ongoing development of the Model and standards .............................................................. 25
7.1.2 Harmonization of formal semantics with HDF..................................................................... 25
7.2 Conclusion.................................................................................................................................... 25
-
8/7/2019 EHR Functional Model Ballot
4/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 4 HL7 Version 3 Standard: HL7 Style Guide, Release 1.0. 2003. All rights reserved.
Draft #1
8 Appendices ........................................................................................................................................... 25
8.1 Profile Submission Form.............................................................................................................. 26
8.2 Functional Triplet Submission Form............................................................................................ 27
8.3 Institute of Medicine - Key Capabilities....................................................................................... 28
8.4 References .................................................................................................................................... 34
8.5 Copyright Information.................................................................................................................. 35
-
8/7/2019 EHR Functional Model Ballot
5/35
1 PURPOSE
This HL7 EHR System Functional Model and Standard documents key functions of Electronic Health
Record Systems (EHR-S) to enable consistent expression of system functionality. The functions are
organised in two ways: as a hierarchy within the broad headings of care delivery and infrastructure
functions; and as a list of functions that are deemed essential or desirable within four common care settings.The purpose of this is to understand the dependencies of functions upon each and to distinguish the key
functions each system should perform to satisfactorily address the clinical and business needs within caresettings. This document also describes the impact of the standard on related work occurring within and
outside the HL7 community, and an overview of future plans for development of this standard.
1.1 Overview
To achieve healthcare community consensus at the outset, the functions are described at a high level,forming a common foundation for future work. Written in user-oriented language, the document is intended
for a broad readership. Future work on this document will incorporate conformance criteria based on the
functions included within this baseline and extend functionality to lower levels. Periodic updating of this
document will occur as the healthcare community requests additional functions and additional care settingare defined for inclusion.
The primary resource for the attribution of functions to care setting used by the HL7 EHR SIG has beenpublished by the Institute of Medicine:Key Capabilities of an Electronic Health Record System, Letter
Report, July 2003.
1.2 Identifying Document Ballot Status
The HL7 ballot package for the EHR System Functional Model and StandardDraft Standard for Trial
Use (DSTU) document includes content with distinct statuses; Reference, Informative, and Normative. Thestatus of content present is identified with a status icon. The status icon informs readers whether they can
ballot a particular portion of the document and, if so, which ballot rulesinformative or normativeapply.See description column in table below for ballot rules as they apply to a status.
Document Status
Status Description Icon
Reference Content that contains information that clarifies concepts orotherwise provides additional information to aidunderstanding and comprehension. This material is notballoted. Readers may comment, identify typographicalerrors, or provide suggestions for improving the documentbut those comments in no way affect a ballot.
Informative Ballot Document Content that is part of the current ballot package for whichHL7 members shall cast a ballot following the HL7
procedures for Balloting Informative Documents. HL7Informative document are not submitted to ANSI forapproval.
Normative Ballot Document Content that is part of the current ballot package for whichHL7 members shall cast a ballot following the HL7procedures for Balloting Normative Documents. HL7Normative document are subject to both successfulcommittee and membership votes and are submitted toANSI for approval.
-
8/7/2019 EHR Functional Model Ballot
6/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 6 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
2 INTRODUCTION
2.1 Definitions
This document is concerned with the functions of an Electronic Health Record System (EHR-S). The
purpose of this work is not to define the concept but relies on definitions developed elsewhere. By usingthis approach, the risks of restricting future evolution of the standard, alienation of particular communities,
and sparking unproductive debate are mitigated. The ISO/TC 215 EHR definitions will be available by the
next ballot cycle.
This models functional approach to the EHR-S is illustrated by an analogy regarding the functional
description of a vehicle: it will get you from your house to your work, it will accelerate at your command,it will slow at your command. It may keep you dry when it rains and it may allow you to carry a load of up
to 1 ton in weight. Such a description does not define the vehicle as a bicycle, car or truck. The traveler is
free to select an implementation of these functions as desired.
This functional approach shapes this document - the functions are organized into two sets of functions. The
first set includes those functions structured to provide support for direct patient care (at the point of care
and elsewhere). These functions include clinical reviews, assessments, plans, and documentation within thecontext of workflow and decision support. The second includes administrative and infrastructure functions
and, in turn, supports secondary data uses such as healthcare operations, research, public health and quality
measurement. All EHR systems assume a level of interoperability within and between EHR systems and
diverse supported systems. The following definitions have been used as reference points throughout thework.
2.1.1 Existing EHR System Definitions
The 1991 IOMs Computerized Patient Recorddefined the EHR System as:
The set of components that form the mechanism by which patient records are created, used, stored,
and retrieved. A patient record system is usually located within a health care provider setting. It
includes people, data, rules and procedures, processing and storage devices (e.g., paper and pen,hardware and software), and communication and support facilities.
The 2003 IOM Letter Report Key Capabilities of an Electronic Health Record System defined the
EHR System as including:
(1) longitudinal collection of electronic health information for and about persons, where health
information is defined as information pertaining to the health of an individual or health care provided
to an individual; (2) immediate electronic access to person- and population-level information by
authorized, and only authorized, users; (3) provision of knowledge and decision-support that enhancethe quality, safety, and efficiency of patient care; and (4) support of efficient processes for health care
delivery.
The 2003 ISO/TS 18308 references the IOM 1991 definition above as well as CEN 13606, 2000:
A system for recording, retrieving and manipulating information in electronic health records.
ASTM Committee E-31 includes two definitions in the standard, E 1769 95:
an assemblage of technical, administrative, operational, communication and computer-basedautomated functions organized to accept, process, store, transmit and retrieve electronic clinical
-
8/7/2019 EHR Functional Model Ballot
7/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 7
Draft #1
information for various purposes - such as assistance in health-care delivery and evaluation supports
the EHR. It provides practitioner reminders and alerts, and it facilitates access to expert knowledge
bases. The operative EHRS shall permit authorized health-care staff to enter, verify, manage, process,
transmit, retrieve, view or print, or a combination thereof; any or all of the EHR data. The EHRS shall
permit the algorithmic creation of longitudinal electronic healthcare files. The EHRS shall allowauthorized user access to EHR data for purposes such as clinical, educational, administrative, financial,
quality improvement, utilization review, policy formation, and research, as defined in the authorization
agreement with each legitimate user. The EHRS shall protect the data from unauthorized access.
ISO/TC 215 currently has in draft a Technical Report V0.1 entitled EHR definition, Scope and
Context, July 2003 the draft Technical Report includes this definition for EHR System:
the set of components that form the mechanism by which patient records are created, used, stored, andretrieved.
2.1.2 Consumer/Person
A person making decisions about his/her own health and health care; a person requiring, scheduled toreceive, receiving or having received a healthcare service; a caregiver of a person requiring, scheduled
to receive, receiving, or having received a healthcare service. (adapted from ISO/TS 18308 andNCVHS).
2.1.3 Healthcare professional
A person who is authorized by a nationally recognized body to be qualified to perform certain health
duties. (ISO/TC 17090, 2001 from ISO 18308) Model: The HL7 EHR System Functional Model and
Standard is a way to organize and manage the functions that are common to all EHR-Ss, and those
functions that are specific to a profile care setting profile.
2.1.4 Profiles
A set of functions required in a particular setting or available as part of a particular system orcomponent.. The name of the HL7 standard concept that HL7 is using to express the function needs
for various settings of care.
2.1.4.1 Care Setting Profile
A care setting profile is a normative profile for a particular care setting. Four care settings have been
included in this Draft Standard for Trail Use Hospital care, Ambulatory care, Nursing Home care andCare in the Community/Personal Health care.
2.1.4.2 Generated Profile
A generated profile is a set of functions that are generated by a third party utilizing the functions that
are expressed in this standard. This may express the functions required for a particular purpose, thoserequired in a particular settings in which healthcare is delivered or functions delivered by a particular
component or system. Generated profiles may voluntarily registered with HL7 if they so wish. The
registry process is included in this document. The generated profile registration process is intended to
make user generated profiles available for others to use and HL7 will not certify or in any other way
evaluate the profiles during the registry process.
-
8/7/2019 EHR Functional Model Ballot
8/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 8 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
2.1.5 Functions
Actions the Electronic Health Record System can perform.
2.1.5.1 Functional Triplet
An expression of an EHR function consisting of rationale and conformance criteria. Functional tripletscan exist at various levels of granularity and can be associated with other functional triplets as
described in Section 5. The three elements of a functional triplet include:
1) Functional Statement, (Normative for this ballot)
2) Rationale for Use or Reference (Normative for this ballot)
3) Conformance Criteria (Informative for this ballot, should be normative in future)
Not included in the current version the part of feature work. For this version the first 2 elements of the
functional triplets are represented in the appendix EHR Rationale Categories
2.1.5.2 Care Delivery Functions
Actions the Electronic Health Record System can perform to which are specific to health care delivery- for example Order Entry.
2.1.6 Infrastructure Functions
Actions the Electronic Health Record System can perform which are more general including non-clinical information handling needs. For example Security and Communication.
2.1.6.1 Essential
A level of significance applied to functions in relation to a profile. Functions labeled as essential are
widely accepted as such by that health care community.
2.1.6.2 Desirable
A level of significance applied to functions in relation to a profile. Functions labeled as desirable areconsidered to have value and are likely to be essential in the future but may need either additional
advancement in their development or increase expectation of need by the healthcare community before
being considered essential for use in the ERH-S.
2.1.7 Functional Knowledge Base
Permanent storage of Functional Statements and associated information in a software organization and
presentation tool.
2.1.8 Draft Standard for Trial Use (DSTU)
Definition from HL7 Policy and Procedure Manual:
POL 14.00.01 Draft Standard for Trial Use
In order to provide timely compliance with regulatory or other governmental mandate and/or timely
response to industry or market demand, the Board of Directors is empowered to adopt and publish a
-
8/7/2019 EHR Functional Model Ballot
9/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 9
Draft #1
Draft Standard for Trial Use (DSTU). The issuance of a DSTU shall be an extraordinary event and
shall only proceed with the understanding that the draft standard will, following a suitable period for
evaluation and comment, be expeditiously incorporated into a fully balloted and accredited version of
the standard. Where the evaluation and comment period results in a need for substantive changes to
the draft standard, the relevant accredited version of the standard may embody such changes or arevised DSTU may be published for further evaluation. In either case, given the need for substantive
changes, the accredited version of the standard or the subsequent revised DSTU is not bound to
maintain compatibility with the initial DSTU. Under such circumstances it is the obligation of theauthor(s), given that the intent of a draft standard is to improve the viability of the accredited standard,
to select enhancement over compatibility. Conversely, recognizing the commitment and investment
involved in implementing a DSTU for evaluation and comment, a DSTU implementation shall be
accepted as viable for up to two years after its publication or for up to six months after the publicationof a subsequent revised DSTU or the first accredited version of the standard that embodies the draft
standard, whichever is longer.
2.2 Objective
The objective of this draft standard for trial use is to delineate a set of functions that are essential and
desirable to an Electronic Health Record System (EHR-S) within different care settings. The term
Electronic Health Record System, as used in this document, refers not only to the repository of health
related data but to the process of collecting and sharing the data as well as managing the information and
work flows associated with managing health related data about a recipient of care. In creating this standard,the recognition of the multiple sites and circumstances associated with patient care and resulting
similarities and differences among those sites emerged. Many functions and potential functions of the
EHR-S have emerged including:
direct patient care
reporting
reimbursement
credentialing
auditing
legal
insuring quality
preventing medical errors
public health needs
research
education
This standard will accommodate the needs of the variety of stakeholders including; health care providers of
all types, payers, governments, industry, accreditators, and very importantly consumers.
The purpose of this HL7 EHR System Functional Model and Standard is to provide a standard
methodology for communicating all essential or desired functions and provide a framework from which an
EHR function can be conceptualized, communicated or evaluated. The users of this framework could befrom any segment of the healthcare community. At this time, there are many EHR definitions,
implementations, perceptions, and applications; many have been recognized as important to contributing to
the existing body of knowledge related to the automation of health information.
This model defines functions and is to be considered technology and application neutral. The model does
not define how a function must be implemented or if the EHR-S is an assembly of smaller systems frommultiple vendors or a single large system. The standard aims to help providers understand essential
information requirements within an EHR is a deliberate, achievable starting point to set industry-wide
expectations from which future work will evolve and mature.
One key goal of HL7 in the development of an EHR System Functional Model and Standard lies in the
organized consolidation of significant, existing knowledge of EHRs into a standard functional model and
-
8/7/2019 EHR Functional Model Ballot
10/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 10 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
associated standards. That accomplishment facilitates the future adoption of the model within the
healthcare community as a tool and guide for EHR-S development, acquisition and implementation.
Cognizant of the existing body of knowledge and the relevant work being done by other groups throughout
the world at this time, this effort strives to bring together these resources in a manner that is
complimentary, relevant and usable, but avoids unnecessary redundancy.
2.3 History
In 2000 the HL7 mission statement was modified to include the EHR. A follow-up of this expansion of the
mission statement was the formation of the Electronic Health Record Special Interest Group (EHR SIG) in
January 2002. The EHR SIG in January of 2003 had planned the initial scope of work to include thisfunctional model and established a two to three year timeline for the accomplishment of this work. In April
of 2003 the US Veterans Health Administration, Centers for Medicare and Medicaid Services and the
Agency for Health Research and Quality recognized a need for this work and were inquiring into variousgroups when they learned that the HL7 EHR SIG had planned to pursue this important work. These
agencies launched a collaborative effort with the Institute of Medicine (IOM) and HL7 and were approved
by the HL7 board on an accelerated timeline. Subsequently, this effort was joined by key private sectororganizations, in particular the Healthcare Information Management Systems Society (HIMSS) and The
Robert Wood Johnson Foundation, and by the DHHS Assistant Secretary for Planning and Evaluation. It is
recognized that this is an ideal opportunity to broaden input into the process of creating this draft standard.
By increasing the number of participants involved in this effort, the initial product will be improved and
add value to ongoing maintenance initiatives.
2.4 Approach
This work consists of three distinct elements: HL7 EHR System Functional Model and Standard, Functions
within Model, and Content Management Components.
Model (informative). The Model was developed by the EHR SIG as a way to represent the
concept of functions that are applicable across profiles as well as specific to profiles. (See
definitions for Functions and Profiles in section 2.1)
Functions within Model (normative). The content within the Model was accomplished via
collaboration with the Institute of Medicine (IOM). The IOM has contributed significantly
to the body of knowledge of the EHR-S in a uniquely proactive way that has challenged
complacency and invited implementation of EHR-S. The contribution of the IOM is one
example of the broad industry participation that has driven the development of this model.
Content Management Components (informative). The Content Management Components
are the processes put in place by the EHR SIG to collect, organize, manage and present the
content that is in the model as well as organize the content that has been submitted but not
used within the model. The components of this area include the Functional Triplet
Submission Form, Generated profile Submission Form, Functional Hierarchy and
Functional Knowledge Base.
3 MODEL: HL7 ELECTRONIC HEALTH RECORD SYSTEMMODEL AND STANDARD
The HL7 EHR System Functional Model and Standard represents a general model of an EHRs functions
that can be applied to care settings. Functions are represented as eitherCare Delivery Functions orInfrastructureFunctions and are displayed in the illustration as the horizontals bars. Profiles represent
-
8/7/2019 EHR Functional Model Ballot
11/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 11
Draft #1
different settings in which healthcare is delivered and are displayed as the vertical cuts through the
horizontal bars, in the illustration. Example profiles are the hospital or acute care setting and a nursing
home setting. Thus the healthcare delivery function of collecting a patients vital signs can be performed
in a hospital setting or in a nursing home setting.
Figure 1.
3.1 Functions
All functions within either the Care Delivery or Infrastructure horizontal bar are categorized as being eitheressential or desirable. Different Care Setting Profiles will, of course, require a (unique) set of essential and
desirable functions which differentiate systems tailored to work in that setting.
Figure 2
All functions, whether essential or desirable, that reside in either the Care Delivery or the Infrastructure
-
8/7/2019 EHR Functional Model Ballot
12/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 12 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
horizontal bars will be decomposed to a level of specificity for which conformance criteria can be written.
This is a hierarchical relationship, abstract at the highest level and more specific at descending levels. The
hierarchy supports logical groupings as well as recognition of dependencies.
Functions have been submitted using the Functional Triplet Submission Form and are stored in a
knowledge base constructed by the EHR SIG to organize and create associations and dependencies betweenfunctions. The knowledge base is planned to be executed with a Stanford University developed knowledge
management tool and made available for use by others via the internet. This knowledge base is not a part
of the standard but a content management tool for use by the EHR SIG.
The IOM functional designations are assigned and organized using the expected implementation periods of
2004-2005, 2006-2007, 2008-2010. HL7 has placed the IOM designated 2004-2005 functions into the
Essential level of the HL7 model. The IOM designation of anything 2006 or beyond time period is placedin the Desirable level of the HL7 model. Future work will include refreshing the HL7 model when the
IOM (or other external groups) time indications reflect a broader list of functions than are currently in the
Essential group.
3.2 Profiles
The model presents a normative profile for each of the collaborative care settings presented by the IOM
(hospital, ambulatory, nursing home and community care) with general functions used in that setting and
any setting specific functions. The coordination of the definition of the care settings has been done with the
Institute of Medicines Committee on Data Standards for Patient Safety, which published a Letter Reporton the Key Capabilities of an Electronic Health Record System on July 31, 2003. The care delivery and
infrastructure functions as well as the high-level, generic care setting will be mainly derived from
collaboration with the IOM. The functions that are deemed essential and desirable are at the time of ballot.
HL7 makes no statement about when desirable functions become essential as this can only be determined
by a further ballot. Generated profiles developed for a particular purpose may include a timescale forimplementation.
4 FUNCTIONS WITHIN MODEL
The care setting profiles in this chapter are the normative portion of the HL7 EHR System FunctionalModel and Standard. These profiles were determined based upon input from the Institute of Medicine
Letter Report, [IOM citation, 2003] and consultation during the development of this standard. These care
settings were reviewed by the HL7 EHR SIG and determined to be valuable and appropriate to this work.
For each of the identified care settings, the functional triplets identifying essential and desirable
functionality of EHR systems to support that setting were identified. The approach taken to thisidentification was twofold. First, the HL7 membership participating in the development of this ballot
identified and elaborated the functions important to their expectations, as well as designating the care
settings to which those functions were relevant. Second, the IOM work was reviewed and a gap analysis
was performed between the IOM-identified and the HL7-identified functions. Once gaps were identified,
IOM functions were populated into the HL7 model with the functions added to the IOM care settings
resulting in the functional descriptions and profiles appearing here. The overall findings were commonbetween the two groups with IOM choosing more specific language to identify functions and HL7 choosing
an approach that started with more general categories that included the IOM functions.
The normative part of this ballot is a vote at a very high functional level with some lower level functional
items that were recurrently and redundantly identified through the rigorous IOM and HL7 processes. Thefollowing table shows a list of functions/functionality, and their applicability in the four care settings
addressed in this ballot:
-
8/7/2019 EHR Functional Model Ballot
13/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 13
Draft #1
Care Setting 1: Hospital Setting
Care Setting 2: Ambulatory Care Setting
Care Setting 3: Nursing Home Setting
Care Setting 4: Personal Health Setting
For each function, a designation of "E" for "Essential", or "D" for "Desirable" within a given care setting
profile is required. Where applicable, the designation is followed by a superscript citation of the external
source providing the designation, i.e., IOM orHIMSS. The Date column indicates the period (in superscript)
when the Desirable functionality will be considered "Essential." These dates are not set by HL7, insteadreflecting external expert or regulatory sources. In version 1 of the ballot the only the dates provided by the
IOM are used.
Functions are grouped together for the purpose of presenting the ballot in an
organized manner. This grouping (represented via numbering in the left-most
column) is only informative, used to organize the work of the SIG.Understanding that the categorization and structure of these functions can
take many forms, the given presentation is for informational purposes only.
The table represents the complete list of functions/functionality considered
by the SIG. Green background cells represent items considered normative in
the current ballot.
After completing the normative items (in the green cells), you may have asuggestion for a function that is not currently in the ballot or may wish to add
a new one. You can indicate this suggestion in your ballot. Please refer to the
information about creating the functional triplets, found in section 5.2 and
the attached Functional Triplet Submission Form.
4.1 Rationale CategoriesEHR Functional Specification Triplet
WHY - Rationale Categories, v1.2
To serve:
1.1 Patient-centered/oriented care
1.2 Longitudinal, interdisciplinary healthcare delivery (per episode, disease, problem)
1.3 Point of service, point of care: immediate, real-time
1.4 Multiple care settings: acute inpatient, emergent (including trauma and mobile care, ambulance),ambulatory, long term, home, school, occupational, military
1.5 Personal health record: per patient
1.6 Provider business record: per organization, per business unit
Here is what to consider in
this ballot:
Look at each green item, andanswer the following
questions:
1.Does this function belong
to this care setting?
2. Is the "Essential" or
"Desirable" designation
correct?
-
8/7/2019 EHR Functional Model Ballot
14/35
-
8/7/2019 EHR Functional Model Ballot
15/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 15
Draft #1
4.5 Trusted record management
4.6 Trusted record/information flow
4.7 Correlated business, clinical and caregiver record
4.8/.9 Continuous quality improvement and monitoring, measures of quality, performance and outcomes
4.10 Payment and eligibility determination
4.11 Effective communication between patient, family, caregiver and care team
Based on:
5.1 Patient safety and best practice guidance
5.2 Legal and regulatory requirements - national and regional mandates
5.3 Accreditation and professional practice standards
4.2 What and Why
The rationale categories are the version 1 representations of the second element of the functional triplet.Each function within the care delivery infrastructure or assumptions spreadsheet have been evaluated or
assigned the appropriate rational of use.
ID
EHRS Function(ality)
What - Statement of Function(ality)
"The EHRS shall/should support/enable"
WHY - Rationale
(from EHR Rationale
Categories, v1.2)
A EHRS Function(ality) - Assumptions
A.1 Database Management
A.2 Database Transaction Management
A.3 On-Line Transaction Processing (OLTP)
A.4 On-Line Analytical Processing (OLAP)
A.5 Fault Tolerance, Redundancy
A.6 Responsiveness, User Response Time
A.7 Scalability, Change Scale
A.8 Time (Clock) Synchrony
A.9 User/Use Environments
I EHRS Infrastructure Functions
I.1 Information Protection
I.1.1 Privacy
2.5, 2.8, 3.1, 3.6, 4.5, 4.6, 5.2,
5.3
-
8/7/2019 EHR Functional Model Ballot
16/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 16 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
I.1.2 Privacy HIPAA
2.5, 2.8, 3.1, 3.6, 4.5, 4.6, 5.2,
5.3
I.1.3 Security2.5, 2.8, 3.1, 3.4, 3.6, 4.5, 4.6,
5.2, 5.3
I.2 Record Management
I.2.1 Chronology Health Service Acts, Health Record Acts 1.2, 1.5-7, 3.4-5
I.2.2 Record Management
1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 4.11,
5.2
I.2.3 Inbound Record Capture/Receipt 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2
I.2.4 Outbound Record Transmittal 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2
I.2.5 Record Lifecycle Chain of Trust 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2
I.2.6 Record Synchrony 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2
I.2.7 Multiple Person Linkage 3.3-5, 4.2, 4.3, 4.11
I.3 Registry Management
I.3.1 Patient/Person Registry 1.5, 2.1, 3.1, 3.4, 4.5
I.3.2 Practitioner (Person) Registry
1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 4.11,
5.2
I.3.3 Role Registry 1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 5.2
I.3.4 Entity Registry1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 4.11,5.2
I.3.5 Location Registry 1.2-4, 2.1, 3.1, 3.3-5, 4.1-7
I.3.6 Device Registry (out of scope v1.0) [TBD]
I.4 Technical Infrastructure
I.4.1 Availability 1.1-8, 2.1-2, 3.1-6, 4.1-7
I.4.2 Versioning, Version Management 3.4-5
I.5 Vocabulary Service
I.5.1 Controlled Vocabulary 1.5-8, 2.1-2, 3.3-5, 4.1-7, 5.1-3
C EHRS Care Delivery Functions
C.1 Direct Care and Immediate Information
C.1.1 Point of Service, Point of Care 1.1-8, 2.1-2, 2.5, 3.1-6, 4.1-11
C.1.2 Care Planning, Critical Paths, Protocols
1.1-4, 2.1-4, 2.6-7, 3.1, 3.3, 3.5,
4.1-4, 4.8, 5.1, 5.3
C.1.3 Clinical Decision Support, Knowledge Management
1.1-4, 2.1-2, 2.4, 2.6-7, 3.1, 3.3,
3.5, 4.1-4, 4.8, 5.1, 5.3
C.1.4 Orders, Order Management1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4,5.1, 5.3
C.1.5 Results, Result Management
1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4,
5.1, 5.3
C.1.6 Medications, Medication Management
1.1-4, 2.1-2, 2.6, 3.1, 3.3, 3.5,
4.1-4, 5.1, 5.3
-
8/7/2019 EHR Functional Model Ballot
17/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 17
Draft #1
C.1.7 Specimen Collection, Specimen Management
1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4,
5.1, 5.3
C.1.8 Allergies1.1-4, 2.1-2, 2.6, 3.1, 3.3, 3.5,
4.1-4, 5.1, 5.3
C.1.9 Special Notes and Precautions 1.1-4, 2.1-2, 3.1, 3.3, 4.1-4, 5.1,5.3
C.1.10 Preventative Care, Wellness
1.1-4, 2.1-4, 2.6-7, 3.3, 3.5, 4.1,
4.4, 4.11, 5.1
C.1.11 Consents and Authorization
1.1-8, 2.3-4, 2.8, 3.1, 3.4-5, 4.5-
6, 5.2-3
C.1.12 Episode, Problem Management
1.1-4, 2.1-2, 2.4, 2.6, 3.1, 3.3,
3.5, 4.1-4, 5.1
C.1.13 Diet, Diet Management1.1-4, 2.1-4, 2.6, 3.1, 3.3, 3.5,4.1-2, 4.11
C.2 Work Flow and Operations Management
C.2.1 Integral Work Flow 1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-8, 5.1
C.2.2 Scheduling 1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-4, 4.7
C.2.3 Work Lists 1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-8, 5.1
C.3 Communication
C.3.1 Inter-Disciplinary Communication1.1-4, 1.6, 2.1-2, 2.4, 2.6-9, 3.1,3.3-5, 4.1-4, 4.11, 5.3
C.3.2 Inter-Practitioner Communication
1.1-6, 2.1-2, 2.4, 2.6-9, 3.1, 3.3-
5, 4.1-4, 4.11, 5.3
C.3.3 Practitioner/Patient Communication
1.1-4, 2.1-4, 2.6-7, 3.3, 4.1-4,
4.11, 5.1, 5.3
C.3.4 Patient Education 1.1-4, 2.1-4, 2.6, 4.1-4, 4.11
C.4 Records, Documents and Views
C.4.1 Health Record Review (Chart Review) 1.1-4, 2.1-2, 3.1-6, 4.1-7, 5.2
C.4.2 Timeline Perspectives 1.1-7, 2.1-2, 2.6-7, 3.2-5, 4.1-7
C.4.3 Historical Snapshot 1.1.7, 2,.1-2, 3.2-5, 4.1-7
C.4.4 Multi Media Record 1.1-4, 2.1-2, 3.2-5, 4.1-7, 4.10
C.4.5 Clinical Document Management
1.1-4, 2.1-2, 3.2-5, 4.1-7, 4.10,
5.2
C.4.6 Remote Access1.1-4, 2.1-2, 3.1-6, 4.1-7, 4.11,
5.2
C.4.7 Special Records Protections 1.1-8, 2.5, 3.1-6, 4.5-6, 5.2
C.4.8 Practitioner Personal Generated profile 2.2, 4.1-4
C.5 Clinical Support
C.5.1 Epidemiological Surveillance1.2, 1.4, 1.8, 2.1-2, 2.6-9, 3.1,3.3-5, 4.2-4, 5.1-3
-
8/7/2019 EHR Functional Model Ballot
18/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 18 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
C.5.2 Disease Registries
1.2, 1.4, 1.8, 2.1-2, 2.6-9, 3.1,
3.3-5, 4.2-4, 5.1-3
C.5.3 Donor, Blood Bank1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4,
5.1-3
C.5.4 Patient Locator 1.1-4, 1.6-7, 2.1-2, 2.5, 2.8, 3.1,3.4, 3.6, 4.1-6, 4.11, 5.2
C.5.5 Practitioner Locator
1.1-4, 1.6-7, 2.1-2, 3.1, 4.1-7,
4.11
C.5.6 Patient Transport 1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-2
C.5.7 Bed Management 1.4, 3.1, 3.5, 4.1-2
C.6 Measurement, Analysis, Research and Reporting
C.6.1 Quality Indicators1.4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1,
3.3-5, 4.1-8, 5.1-3
C.6.2 Performance and Accountability Measures1.4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1,3.3-5, 4.1-8, 5.1-3
C.6.3 Analysis and Measures
1.4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1,
3.3-5, 4.1-2, 4.4, 4.7-8, 5.1-3
C.6.4 Reports, Reporting
1.1-4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1-
6, 4.1-11, 5.1-3
C.6.5 Clinical Trials, Research (out of scope v1.0) [TBD]
C.7 Administrative, Finance
C.7.1 Encounter Management
1.1-4, 1.6-7, 2.2, 3.1, 3.3-5, 4.1-
2, 4.7, 4.10
C.7.2 Eligibility, Enrollment, Authorizations
1.1-4, 1.6-7, 2.2-3, 3.1, 3.3, 3.5,
4.1-4, 4.7, 4.10-11, 5.2
C.7.3 Practitioner/Patient Relationship1.1-4, 1.6-7, 2.1-6, 3.1, 3.3-6,4.1-4, 4.7, 4.11
C.7.4 Multiple Person Linkage 3.3-5, 4.2, 4.3, 4.11
C.7.5 Diagnosis and Procedure Coding
1.2, 1.4, 1.8, 2.2, 3.1, 3.3-5, 4.1-
4, 4.8-9, 5.1-3
C.7.6 Charges, Charge Management 4.7, 4.10
C.7.7 Costs, Cost Management 4.7, 4.10
C.7.8 Localization, Local Authority 1.6, 3.1, 3.3-5, 4.7
4.3 Care Delivery FunctionsBaseline high-level functions are being balloted in version 1 of this standard. In care delivery there is
increased specificity that is determined by both the EHR SIG activities and the July 2003 IOM LetterReport. Note that CC and PH are used to indicate Care in the Community and Personal Health. See the
EHR Functional Model Reference 1 spreadsheet to review the related ballot content.
-
8/7/2019 EHR Functional Model Ballot
19/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 19
Draft #1
4.4 Infrastructure Functions
See the EHR Functional Model Reference 2 spreadsheet to review the related ballot content.
4.5 Functionality Assumptions
See the EHR Functional Model Reference 3 spreadsheet to review the related ballot content.
5 CONTENT MANAGEMENT COMPONENTS
5.1 Managing content to support information integrity
Content management components developed for this work aim to ensure consistency and integrity acrossthe model. This first iteration of the ballot has not been rigorously expressed and does not drill-down into
deep levels of granularity. Consensus determined that attempts to provide a high level of detail or rigor too
soon would be a disservice to the community. By first developing a framework, those involved would
learn and together develop a group understanding; better positioning the committee to address those areasin subsequent iterations. Providing too much detail would represent a pitfall that could severely curtailconsensual understanding of the problem and be detrimental to the task.
The Functional Model and Standard is positioned to mature through an iterative approach. Each iteration
can add to the established functional triplets arranged in a multi-tiered hierarchy, adding rigor and
granularity. Each of the functions included in this ballot will be better understood with increased
specificity in the future. As more granularity emerges, functional statements will be more precisely
expressed and conformance criteria more critically defined. The means of expression of the functions mayevolve over time given the alignment of the EHR SIG activity and the emerging HL7 Development
Framework described in the Foundations section on page 23.
5.2 Functional Triplets / Expressing FunctionsAlthough all three elements of the Functional triplet have been submitted for this first version of the
Functional Model and Standard, only the first two elements the functional statement and the rationale -
are part of the normative ballot. The third element, the conformance criteria, is helpful to explain and
validate the functional statement but is only informative at this stage. The conformance criteria will be
refined in subsequent versions and may eventually be specific enough to become normative. EHRFunctions are presented as a Functional Triplet that contains three elements of information:
Functional Statement
Rationale for Use or Reference1 See Appendix for Rationale for Use
Conformance Criteria
5.2.1 Functional StatementFunctions will be decomposed until a sufficient level of granularity has been reached so that:
1 The IOM Letter Report Listed five criteria for including a function: improve patient safety, support the
delivery of effective patient care, facilitate the management of chronic conditions, improve efficiency and
feasibility of implementation. The EHR SIG used an expanded grouping.
-
8/7/2019 EHR Functional Model Ballot
20/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 20 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
1. Functional statements support one user action.
2. The conformance criteria are non-ambiguous.
The Functional Triplet Submission Form in the Appendix Section 8.2 on page 27 was used for submission.
A description of each of the fields appears in the form.
5.2.2 Rationale for use
The reason for including a function in this standard must be explicit. Describing a function as essential
must have a strong rationale and, at this early point in the development of EHR systems, must be primarilyconcerned with integrity of the system itself and its ability to support patient care functions. The Rationale
For Use document was the method used by the SIG for specification of functional rationale.
There is compelling need to make health care safer, more effective and more efficient. Evidence validates
the capacity of EHR systems to support these efforts. Decision support systems, as in other industries, are
most likely to be funded and implemented in high-risk settings. EHR Systems can significantly impact thecost effectiveness of health - but as with the 'paper paradox' they can also lead to adverse outcomes. Ideally,
functionality must be described in a manner that reflects specifically the system requirements.
User acceptance of EHR concepts by clinicians and patients and the development of functions that support
clinicians, patients and administrators in the activities and processes they seek to carry out are vital to the
realization of EHR implementation potential. Adapting the highest level functions for this standard to
reflect the users needs and inclusion of system administrators better position the acceptance of EHRconcepts and functions within the healthcare community. Finally, regulators impose requirements that
EHR systems need to meet. These may be legal, via accreditation processes or expected as part of
professional conduct.
In summary, rationale for inclusion from a user perspective has been reflected in the hierarchical
organization of the functions - to support clinicians, patients, administration, and technicians. Furtherrationale for inclusion is organized in terms of patient safety, cost effectiveness and regulation. See
Appendix Section 4.2 Rationale for Use.
5.2.3 Conformance Criteria
Currently the Conformance criteria serve as a plain English re-statement of the functional statement to helpclarify and validate the understanding of the functional statement between submitter and reader. In the
future, the Conformance criteria will become more rigorous with the aim that a user would be able to be
sure if a function was or was not present. This work will progress with input from the HL7 Conformance
group.
5.3 Navigational/Summation Hierarchy
The HL7 EHR System Functional Model and Standard is embodied in the set of functions for a care setting.
These functions have been organized into a hierarchy for the purpose of navigation and summation. Thishierarchy is a reference tool and is nota representation of the Model, implementation or suggestion of best
practice. It is recognized that a different hierarchy can represent all of the functions equally well. The
Hierarchy is not a normative part of this ballot. In this first ballot, there are three levels in the hierarchy
(except in some IOM driven exceptions). At the highest level it is divided into Care Delivery and
Infrastructure functions. The two highest levels are shown in Appendix Section Error! Reference source
not found. Hierarchy on page Error! Bookmark not defined.. Note that this hierarchy is not the sameas that developed by the IOM.
-
8/7/2019 EHR Functional Model Ballot
21/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 21
Draft #1
5.4 Expressing Profiles
There are two kinds of profiles, Care Setting and Generated Profiles. The Care Settings are based on IOM
input and are normative. Generated Profiles are expressions of the standard in use and hence HL7 offers the
tools with which the healthcare community can develop and register a profile. Hence Generated Profiles do
not form part of the standard.
The profile is divided into four basic sections:
Identifying Information
Functions Supported
Inter-profile relationships
Metadata
5.4.1 Identifying Information
The Identifying Information section contains that information describing the profile and its purpose. For
iteration one, we are expecting exactly four profiles, aligned with the emerging IOM work. These are
Acute, Ambulatory, Nursing Home, and Care in the Community or what HL7 has termed the Care in the
Community/ Personal Health Setting. The profile template in Appendix Section 8.1 on page 26 is generic
to accommodate future care settings as needed.
5.4.2 Functions Supported
The Functions Supported section is the basis of the profile. For instance, a profile for the Ambulatorycare setting may include the functions pertaining to dispensing outpatient drugs. Every function identified
is classified as essential or desirable. These distinctions are of key importance given the anticipated
future role of these care setting profiles with respect to conformance.
5.4.3 Inter-profile relationships
The Inter-Profile Relationships section allows annotation of the relationship of the subject generated
profile with other profiles. This may be in terms of specialization or dependency. For example, a generatedprofile may, at its simplest, be defined as the set of functions described in another profile plus another
function.
5.4.4 Metadata
The last section of the profile, the Metadata section, captures information about the submitter, so that
proper attribution and revision information may be recorded as appropriate.
5.5 Terminology and Profile Semantics
Although inter-profile relationships are not part of the standard, they are important in that consumers of thestandard may need to relate their generated profiles which express the special needs in their care setting to
the normative profiles of the standard. In order to establish some consistency and uniformity when relatingprofiles, this section has been included. It will begin to forge the relationship between this EHR ballot and
ongoing work in other parts of HL7, and the emerging HL7 Development Framework (HDF) methodology
in particular.
-
8/7/2019 EHR Functional Model Ballot
22/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 22 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
5.6 Developing a profile
Given that a profile is the elaboration of a set of functional statements to describe a contextwhether that
context describes a care setting or a specific use casethis section elaborates how profiles are developed
and documented. The profiles are containers for functions that are determined to be relevant for that
particular profile.
Developing a profile then depends upon the ability to:
1. Choose high level functions that are required and populate the profile;
2. Choose a profile which closely matches to populate the profile;
3. Locate specific functions that are specifically required;
4. Determine if the function is essential and desirable.
Two HL7 artifacts have been developed to assist with this process. First, one may use the functional
hierarchy allowing the identification of functions of interest by navigating to those areas of relevance to theprofile under construction. Secondly, a profile may be constructed based upon other profiles. For instance,
if an organization is building a generated profile to describe their inpatient care needs, it is reasonable for
them to start with the Inpatient Care Setting profile, then restrict or augment it as necessary to meetorganizational requirements.
During this task, functions which are not available in the knowledge base may become apparent.
Submitting these functions for consideration using the appropriate form will be encouraged.
5.7 Care Setting Profiles
As described in the HL7 EHR-System Functional Model and Standard, the initial version of this standard
consists of four care settings. These care settings identify the functions needed in each venue of care. Thesettings include:
Acute or Hospital care
Ambulatory or Outpatient care
Nursing Home
Care in the Community and Personal Health care
The Care Settings introduced here are based upon the 2003 Institute of Medicine Letter Report entitled
Key Capabilities of an Electronic Health Record System.
5.7.1 Profile Management
Care Setting Profiles are normative, with their content vetted through the balloting process. Generated
profiles are constructed by users of this model. Their content is not vetted through HL7 and they are not
normative or informative in presenting future ballots. This content will be made available for use on the
HL7 web site.
To achieve that goal, a Generated profile Registry will be developed whereby those organizations creating
profiles may choose to publicly contribute their profile. The Generated profile Registry is a crucial step toinstituting this standard within industry for it acts as a vehicle to enable knowledge sharing and reuse
within the domain. For instance, the Veterans Health Administration may choose to contribute a Generated
profile for their Community-based Outpatient Clinics comprised of many functions from the AmbulatoryCare setting as well as several functions commonly used and required by that agency. By contributing this
to a public registry, other clinic operators may use that profile directly (though there is certainly no
-
8/7/2019 EHR Functional Model Ballot
23/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 23
Draft #1
obligation to do so), adapt it for their needs and submit their specialized version, or create their own.
The registry also would provide a mechanism for knowledge management, allowing profile consumers tobrowse and view submissions. As another example, if several provider organizations each have their
profiles public and available, product vendors may analyze those profiles to determine the optimal
functionality for a new release of a product offering.
6 FOUNDATIONS
The work of this model supports and is inter-related to other HL7 standards. This chapter expresses theserelationships.
6.1 HDF
The HL7 Development Framework (HDF) is a project sponsored by the HL7 Modeling and Methodology(MnM) committee, and effectively serves as a refresh to the existing methodology used within and across
HL7. The currently HL7 methodology does not address ongoing work of all committees, for it is primarily
focused on messaging and message development. This fact causes certain issues. In fact, committees such
as EHR are not included in the methodology. To quote from the HDF project charter, one of its objectivesis to:
Expand application of its modeled-based approach for standards development beyond messaging to its
other standards such as structured documents, context management, and standards related to electronic
health records;
Given that the HDF is very much a work in progress, this section is intended to identify relationships
between this EHR work and the emerging HDF framework.
A common consensus that the EHR work must relate to other activities within HL7 pervades the immediate
EHR SIG. Given that this initial version will lack granular detail, some of the relationships between EHR
SIG work products and other HL7 artifacts remain unclear. Future ballot versions are anticipated to followa convergence path with the HDF, thus requiring a means of reconciling HDF and EHR artifacts.
The following subsections identify potential paths of convergence between the EHR and HDF, and present
existing relationships as they are currently understood.
6.1.1 RIM
The HL7 Reference Information Model contains the information classes identified as being of interest
when considering system-to-system communicationsthe context in which HL7 has been traditionally
operating. By contrast, the present document addresses business functions of an Electronic Health Record
system, as identified in Functional Triplets and in profiles.
As these health record functions drill down into more detail, the relationship between the functions andinformation as represented in the RIM will be better understood. As that understanding grows, it is
anticipated that references to the RIM (or products derived from the RIM, such as CMETS or Templates)
will be mapped in relation to EHR functions. At this time, however, the EHR model work lack the level of
maturity and detail to support this type of a mapping.
-
8/7/2019 EHR Functional Model Ballot
24/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 24 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
6.1.2 Clinical Document Architecture
The HL7 Clinical Document Architecture (CDA) specification represents a key potential resource to this
EHR Functional Model and Standard. The CDA is a document markup standard that specifies the structure
and semantics of "clinical documents" for the purpose of exchange.
6.1.3 Artifacts and Representations
From a content point of view, many of the functions identified in the Functional Model and Standard may
well relate to the analysis artifacts identified in the HL7 Development Framework. The Requirements
Gathering chapter of the HDF will need to be reconciled against the analysis approach and products in this
ballot effort so that both may be represented, consistent, and mappable. The breadth of requirements
capture within the HDF must support the identified EHR needs, and the EHR plans to reuse HDF practicesas appropriate to meeting project objectives.
The ability to consistently capture and relate artifacts across HL7 is of paramount importance, especially as
work products are matured to rigorous models and representations. Issues such as semantics, terminology,
constraint language, notation, etc. must all be considered. In this version of the ballot, there was
insufficient time so as to require rigorous expression of requirements and assessment of notations to capture
those requirements. As the products mature, EHR will work with MnM and the HDF to determine the mostadvantageous way of proceeding.
6.1.4 Conformance
Although ultimately some mechanism of conformance is clearly envisioned as being within the scope of
this initiative, it is unrealistic to include conformance until formal, rigorous conformance statements and
measurement metrics have been determined. The functional triplet template has recognized this need, and
the decomposition approach being taken is targeted at arriving precisely at these levels of detail to addressconformance.
6.1.5 Tooling
The short timeframe for this ballot preparation precluded the ability of the committee to perform intensive
research or alignment of tooling activities. Recognizing that this EHR Functional Model and Standarddiffers from the RIM and message development, it is reasonable to expect that a unique tool suite, different
from current HL7 suites, must be considered. HDF has responsibility to ensure the reusability and share-
ability of information content across HL7. A need for tools to support a knowledgebase of the functionaltriplets (some of which appear in this ballot), and to manage and maintain the decomposition of EHR
functions has been identified based on the current work thus far.
A number of potential convergence paths to support interchange between these requirements and the
emerging HDF tooling exist. An assessment of the HL7 Profile for UML and the MIF must be performed
to determine if any new requirements are being surfaced as part of this activity. Hopefully already-established tooling interchange mechanisms can be used to allow for interchange of EHR content with HDF
activities. Special needs must be identified, evaluated and addressed to achieve long-term tooling
alignment.
-
8/7/2019 EHR Functional Model Ballot
25/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 25
Draft #1
7 CHAPTER 6: FUTURE
7.1 Next Steps
7.1.1 Ongoing development of the Model and standardsThis initial version of the standard focuses on coverage and breadth, but does not delve into fine granularity
of the content. EHR-S development will require new and increased specificity of the functions and their
conformance statements. At times more granularity will be required for differentiating systems while on
other occasions collapsing functions into a higher level function will be appropriate. As the functions areexpressed at increasing lower levels of detail, the conformance criteria assertions within the Functional
Triplets can be more rigorous and testable (signs that formal conformance to the Standard can be assessed).
For this standard to further interoperability across EHR systems, the conformance criteria against whichEHR-S implementations are to be measured must be unambiguous.
As the Functional Model and Standard grows and matures, it is expected that organizations will advancetheir functions of interest for inclusion into the knowledgebase. As these functions are collected, they will
be included in the knowledge base and, when appropriate, placed in the Care Setting profiles.
The composition of the profiles within the standard will evolve over time. For instance, functions that are
desired today may well become essential tomorrow. Addressing the temporal aspects of the
standardin terms of generations of EHR systems and not actual calendar yearswill be a challenge forthe committee. The EHR committee has determined that the assertion of functionality by calendar year is
out of its scope, and better handles by other organizations (such as regulatory agencies).
7.1.2 Harmonization of formal semantics with HDF
Though briefly addressed elsewhere within this document, alignment of the EHR Functional Model andStandard with the HL7 Development Framework must be achieved. The emerging HL7 methodology must
acknowledge the work being done here. Similarly, as the EHR model develops and matures into more
formal and rigorous expressions, the language and tooling being used must be capable of interoperatingwith the whole of HL7.
7.2 Conclusion
This draft standard for trial use serves as a deliberate, achievable starting point intended to set industry
wide expectations of EHR-S functionality. The input from the IOM has been invaluable in beginning this
approach to EHR-Ss from the functional perspective of the user. This work represents a vital next step inthe development of the architectural, reference and definitional EHR-S standards work that is taking place
at this time.
8 APPENDICES8.1 Profile Submission Form
8.2 Functional Triplet Submission Form
8.3 Institute of Medicine - Key Capabilities
8.4 References
8.5 Copyright Information
-
8/7/2019 EHR Functional Model Ballot
26/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 26 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
8.1 Profile Submission Form
-
8/7/2019 EHR Functional Model Ballot
27/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 27
Draft #1
8.2 Functional Triplet Submission Form
-
8/7/2019 EHR Functional Model Ballot
28/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 28 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
8.3 Institute of Medicine - Key Capabilities
1. Health Information and Data
1.a Key Data
1.a.1 Problem List
1.a.2 Procedure
1.a.3 Diagnosis
1.a.4 Medication List
1.a.5 Allergies
1.a.6 Demographics
1.a.7 Diagnostic Test Results
1.a.8 Radiology Results
1.a.9 Health Maintenance
1.a.10 Advance Directives
1.a.11 Disposition
1,a.12 Level of Service
1.b Minimum Datasets for Nursing Homes
1.b.1 Defined MDS
1.b.2 Expanded/Refined MDS
-
8/7/2019 EHR Functional Model Ballot
29/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 29
Draft #1
1.c Narrative (clinical and patient narrative)
1.c.1 Free-text
1.c.2 Template-based
1.c.3 Deriving structure from unstructured text
1.c.4 Natural Language Processing
1.c.5 Structured and Coded
1.c.5.1 Signs and Symptoms
1.c.5.2 Diagnoses
1.c.5.3 Procedures
1.c.5.4 Level of Service
1.c.6 Treatment Plan
1.c.6.1 Single discipline
1.c.6.2 Interdisciplinary
1.d Patient acuity/severity of illness/risk adjustment
1.d.1 Nursing workload
1.d.2 Severity adjustment
1.e Capture of Identifiers
1.e.1 People and roles
1.e.2 Products/devices
1.e.3 Places (including directions)
2. Results Management
-
8/7/2019 EHR Functional Model Ballot
30/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 30 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
2.a Results Reporting
2.a.1 Laboratory
2.a.2 Microbiology
2.a.3 Pathology
2.a.4 Radiology Reports
2.a.5 Consults
2.b Results Notification
2.c Multiple views of data and presentation
2.d Multimedia Support
2.d.1 Images
2.d.2 Waveforms
2.d.3 Scanned documents
Patient consents
2.d.4 Pictures
2.d.5 Sounds
3. Order Entry/Management
3.a Computerized provider order entry
3.a.1 Electronic prescribing
3.a.2 Laboratory
3.a.3 Microbiology
3.a.4 Pathology
3.a.5 Xray
3.a.6 Ancillary
3.a.7 Nursing
3.a.8 Supplies
3.a.9 Consults
-
8/7/2019 EHR Functional Model Ballot
31/35
-
8/7/2019 EHR Functional Model Ballot
32/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 32 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
4.k Automated Real-Time Surveillance
4.k.1 Detect adverse events and near misses
4.k.2 Detect disease outbreaks
4.k.3 Detect bioterrorism
5. Electronic Communication and Connectivity
5.a Provider Provider
5.b Team Coordination
5.c Patient Provider
5.d Medical Devices
5.e Trading Partners (external)
5.e.1 Outside pharmacy
5.e.2 Insurer
5.e.3 Laboratory
5.e.4 Radiology
5.f Integrated Medical Record
5.f.1 Within setting
5.f.2 Cross-setting
5.f.2.1 Inpatient - outpatient
5.f.2.2 Other cross-setting
5.f.3 Cross-organizational
6. Patient Support
6.a Patient Education
6.a.1 Access to patient education materials
6.a.2 Custom patient education
6.a.3 Tracking
6.b Family and Informal Caregiver Education
-
8/7/2019 EHR Functional Model Ballot
33/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 33
Draft #1
6.c Data entered by Patient, Family, and/or Informal Caregiver
6.c.1 Home monitoring
6.c.2 Questionnaires
7. Administrative Processes
7.a Scheduling Management
7.a.1 Appointments
7.a.2 Admissions
7.a.3 Surgery/procedure schedule
7.b Eligibility Determination
7.b.1 Insurance eligibility
7.b.2 Clinical trial recruitment
7.b.3 Drug recall
7.b.4 Chronic disease management
8. Reporting and Population Health Management
8.a Patient Safety and Quality Reporting
8.a.1 Clinical dashboards
8.a.2 External accountability reporting
8.a.3 Ad hoc reporting
8.b Public Health Reporting
8.b.1 Reportable diseases
8.b.2 Immunization
8.c Deidentifying Data
8.d Disease Registries
-
8/7/2019 EHR Functional Model Ballot
34/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
Page 34 HL7 EHR System Functional Model and Standard, Release 1.0. 2003. All rights reserved.
Draft #1
8.4 References
ASTM. Standard Guide for Properties of Electronic Health Records and Record Systems. E1769-95, Feb
1996.
Institute of Medicine. 1991. The Computer-Based Patient Record: An Essential Technology for HealthCare. eds. R. S. Dick and E. B. Steen. Washington, D.C: National Academy Press.
Institute of Medicine. 2003. Key Capabilities of an Electronic Health Record System. Letter Report
ISO. Health Informatics Requirements for an Electronic Health Record Architecture. TS 18308.
ISO. TC 215 Draft Technical Report v0.l EHR Definition, Scope and Context. July 2003.
Glondys, Barbara. 1999. Documentation Requirements for the acute Care Patient Record. American
Health Information Management Association.
Health Information Management Systems Society, Electronic Health Record Definitional Model Version
1.0 Electronic Health Record Attributes and Essential Requirements. July 2003.
National Committee on Vital and Health Statistics. 2002.Information for Health: A strategy for Building
the National Health Information Infrastructure. Washington, D.C., U.S. Department of Health and Human
Services.
-
8/7/2019 EHR Functional Model Ballot
35/35
HL7 EHR System Functional Model and Standard (DSTU), Release 1.0
8.5 Copyright Information