EHR Functional Model Ballot

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.


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


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


4/35


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


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.


6/35


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


7/35


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/35



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


9/35



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


10/35



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


11/35



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


12/35



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:


13/35



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?


14/35


15/35



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


16/35



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


17/35



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


18/35



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.


19/35



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.


20/35



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.


21/35



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.


22/35



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


23/35



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.


24/35



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.


25/35



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


26/35



Draft #1

8.1 Profile Submission Form


27/35



Draft #1

8.2 Functional Triplet Submission Form


28/35



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


29/35



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


30/35



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


31/35


32/35



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


33/35



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


34/35



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.


35/35


8.5 Copyright Information

EHR Functional Model Ballot

Documents

Transcript of EHR Functional Model Ballot