EHR Functional Model Ballot

ANSI/HL7 EHR SYSTEM FUNCTIONAL MODEL AND STANDARD - 2003 AUGUST, 2003

HL7 EHR System Functional Model and Standard
Draft Standard for Trial Use Release 1.0, August 2003
Editors: Gary Dickinson Misys Healthcare Linda Fischetti, RN MS US Department of Veterans Affairs Sam Heard, MD Ocean 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.

Table of Contents
1 Purpose ................................................................................................................................................... 5 1.1 1.2 2 Overview ........................................................................................................................................ 5 Identifying Document Ballot Status ............................................................................................... 5

Introduction ............................................................................................................................................ 6 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.2 2.3 2.4 Definitions ...................................................................................................................................... 6 Existing EHR System Definitions .......................................................................................... 6 Consumer/Person.................................................................................................................... 7 Healthcare professional .......................................................................................................... 7 Profiles.................................................................................................................................... 7 Functions ................................................................................................................................ 8 Infrastructure Functions.......................................................................................................... 8 Functional Knowledge Base ................................................................................................... 8 Draft Standard for Trial Use (DSTU) ..................................................................................... 8 Objective ........................................................................................................................................ 9 History .......................................................................................................................................... 10 Approach ...................................................................................................................................... 10

3

Model: HL7 Electronic Health Record System Model and Standard .................................................. 10 3.1 3.2 Functions ...................................................................................................................................... 11 Profiles.......................................................................................................................................... 12

4

Functions within Model........................................................................................................................ 12 4.1 4.2 4.3 4.4 4.5 Rationale Categories..................................................................................................................... 13 Rationale For Use .......................................................................... Error! Bookmark not defined. Care Delivery Functions............................................................................................................... 18 Infrastructure Content for the Informative Hierarchy................................................................... 19 Assumptions for the Informative Hierarchy ................................................................................. 19

5

Content Management Components...................................................................................................... 19

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.5 5.6 5.7 5.7.1 6 Managing content to support information integrity ...................................................................... 19 Functional Triplets / Expressing Functions .................................................................................. 19 Functional Statement ............................................................................................................ 19 Rationale for use................................................................................................................... 20 Conformance Criteria ........................................................................................................... 20 Navigational/Summation Hierarchy ............................................................................................. 20 Expressing Profiles ....................................................................................................................... 21 Identifying Information ........................................................................................................ 21 Functions Supported ............................................................................................................. 21 Inter-profile relationships ..................................................................................................... 21 Metadata ............................................................................................................................... 21 Terminology and Profile Semantics ............................................................................................. 21 Developing a profile ..................................................................................................................... 22 Care Setting Profiles..................................................................................................................... 22 Profile Management ............................................................................................................. 22

Foundations .......................................................................................................................................... 23 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 HDF .............................................................................................................................................. 23 RIM ...................................................................................................................................... 23 Clinical Document Architecture ........................................................................................... 24 Artifacts and Representations ............................................................................................... 24 Conformance ........................................................................................................................ 24 Tooling ................................................................................................................................. 24

7

Chapter 6: Future................................................................................................................................. 25 7.1 7.1.1 7.1.2 7.2 Next Steps..................................................................................................................................... 25 Ongoing development of the Model and standards .............................................................. 25 Harmonization of formal semantics with HDF..................................................................... 25 Conclusion.................................................................................................................................... 25

HL7 Version 3 Standard: HL7 Style Guide, Release 1.0. 2003. All rights reserved.

Page 3 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 8 Appendices ........................................................................................................................................... 25 8.1 8.2 8.3 8.4 8.5 Profile Submission Form .............................................................................................................. 26 Functional Triplet Submission Form ............................................................................................ 27 Institute of Medicine - Key Capabilities....................................................................................... 28 References .................................................................................................................................... 34 Copyright Information.................................................................................................................. 35

Page 4 Draft #1

HL7 Version 3 Standard: HL7 Style Guide, Release 1.0. © 2003. All rights reserved.

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 care settings. 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 setting are defined for inclusion. The primary resource for the attribution of functions to care setting used by the HL7 EHR SIG has been published 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 Standard—Draft Standard for Trial Use (DSTU) document includes content with distinct statuses; Reference, Informative, and Normative. The status 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 rules—informative or normative—apply. See description column in table below for ballot rules as they apply to a status. Document Status Status
Reference

Description
Content that contains information that clarifies concepts or otherwise provides additional information to aid understanding and comprehension. This material is not balloted. Readers may comment, identify typographical errors, or provide suggestions for improving the document but those comments in no way affect a ballot. Content that is part of the current ballot package for which HL7 members shall cast a ballot following the HL7 procedures for Balloting Informative Documents. HL7 Informative document are not submitted to ANSI for approval. Content that is part of the current ballot package for which HL7 members shall cast a ballot following the HL7 procedures for Balloting Normative Documents. HL7 Normative document are subject to both successful committee and membership votes and are submitted to ANSI for approval.

Icon

Informative Ballot Document

Normative Ballot Document

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 using this 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 model’s 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 the context 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 the work.

2.1.1 Existing EHR System Definitions
The 1991 IOM’s Computerized Patient Record defined 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 enhance the 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-based automated functions organized to accept, process, store, transmit and retrieve electronic clinical

Page 6 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 allow authorized 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, and retrieved.”

2.1.2 Consumer/Person
A person making decisions about his/her own health and health care; a person requiring, scheduled to receive, 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 and NCVHS).

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-S’s, 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 or component.. 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 and Care 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, those required 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.

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 7 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 triplets can 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 nonclinical 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’ are considered 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

Page 8 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 a revised 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 the author(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 publication of 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 be from 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 from multiple 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
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 9 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 this functional 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 various groups 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 sector organizations, 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 SYSTEM MODEL AND STANDARD
The HL7 EHR System Functional Model and Standard represents a general model of an EHR’s functions that can be applied to care settings. Functions are represented as either Care Delivery Functions or Infrastructure Functions and are displayed in the illustration as the horizontals bars. Profiles represent
Page 10 Draft #1 HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 patient’s 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 either essential 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

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 11 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 between functions. 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 placed in 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 Medicine’s Committee on Data Standards for Patient Safety, which published a Letter Report on 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 for implementation.

4 FUNCTIONS WITHIN MODEL
The care setting profiles in this chapter are the normative portion of the HL7 EHR System Functional Model 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 this identification 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 common between 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. The following table shows a list of functions/functionality, and their applicability in the four care settings addressed in this ballot:

Page 12 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 or HIMSS. The “Date” column indicates the period (in superscript) when the Desirable functionality will be considered "Essential." These dates are not set by HL7, instead reflecting 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 a suggestion 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. Here is what to consider in this ballot: Look at each green item, and answer the following questions: 1. Does this function belong to this care setting? 2. Is the "Essential" or "Desirable" designation correct?

4.1

Rationale Categories

EHR 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
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 13 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 1.7 Practitioner service record: per caregiver 1.8 Primary and secondary record uses

To promote: 2.1 Patient safety 2.2 Best practice - effective, efficient and timely care 2.3 Patient empowerment: participation in care, self care 2.4 Improved outcomes, patient satisfaction 2.5 Confidentiality 2.6 Personal health, wellness and preventative care 2.7 Population health, wellness and prevention 2.8 Personal security (military personnel, special agents, government officials) 2.9 Population security (homeland security, bioterrorism, chemical terrorism, terrorist activity)

To ensure and ascribe: 3.1 Accountability: of organizations, of business units, of persons 3.2 Continuous record availability and access 3.3 Integrity of clinical decision making/Effectiveness of clinical decisions 3.4 Integrity of the health record 3.5 Integrity of the health(care) delivery process 3.6 Health record privacy, PHI protection

To facilitate and enable: 4.1 Health(care) delivery: immediate, real-time point of service, point of care 4.2 Efficient work flow and operations performance - streamline the way people work 4.3 Communication: inter-practitioner 4.4 Clinical decision making

Page 14 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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.
EHRS Function(ality) What - Statement of Function(ality) "The EHRS shall/should support/enable…" EHRS Function(ality) - Assumptions Database Management Database Transaction Management On-Line Transaction Processing (OLTP) On-Line Analytical Processing (OLAP) Fault Tolerance, Redundancy Responsiveness, User Response Time Scalability, Change Scale Time (Clock) Synchrony User/Use Environments WHY - Rationale (from EHR Rationale Categories, v1.2)

ID A A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9

I I.1

EHRS Infrastructure Functions Information Protection 2.5, 2.8, 3.1, 3.6, 4.5, 4.6, 5.2, 5.3

I.1.1

Privacy

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 15 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

I.1.2

Privacy – HIPAA

2.5, 2.8, 3.1, 3.6, 4.5, 4.6, 5.2, 5.3 2.5, 2.8, 3.1, 3.4, 3.6, 4.5, 4.6, 5.2, 5.3

I.1.3 I.2 I.2.1

Security Record Management Chronology Health Service Acts, Health Record Acts

1.2, 1.5-7, 3.4-5 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 4.11, 5.2 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2 1.2, 1.5-8, 2.5, 3.2-6, 4.2-7, 5.2 3.3-5, 4.2, 4.3, 4.11

I.2.2 I.2.3 I.2.4 I.2.5 I.2.6 I.2.7 I.3 I.3.1

Record Management Inbound Record Capture/Receipt Outbound Record Transmittal Record Lifecycle “Chain of Trust” Record Synchrony Multiple Person Linkage Registry Management Patient/Person Registry

1.5, 2.1, 3.1, 3.4, 4.5 1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 4.11, 5.2 1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 5.2 1.6-7, 2.1, 3.1, 3.3-5, 4.1-7, 4.11, 5.2 1.2-4, 2.1, 3.1, 3.3-5, 4.1-7 [TBD]

I.3.2 I.3.3

Practitioner (Person) Registry Role Registry

I.3.4 I.3.5 I.3.6 I.4 I.4.1 I.4.2 I.5 I.5.1

Entity Registry Location Registry Device Registry (out of scope v1.0) Technical Infrastructure Availability Versioning, Version Management Vocabulary Service Controlled Vocabulary

1.1-8, 2.1-2, 3.1-6, 4.1-7 3.4-5

1.5-8, 2.1-2, 3.3-5, 4.1-7, 5.1-3

C C.1 C.1.1

EHRS Care Delivery Functions Direct Care and Immediate Information Point of Service, Point of Care 1.1-8, 2.1-2, 2.5, 3.1-6, 4.1-11 1.1-4, 2.1-4, 2.6-7, 3.1, 3.3, 3.5, 4.1-4, 4.8, 5.1, 5.3 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 1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4, 5.1, 5.3 1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4, 5.1, 5.3 1.1-4, 2.1-2, 2.6, 3.1, 3.3, 3.5, 4.1-4, 5.1, 5.3

C.1.2

Care Planning, Critical Paths, Protocols

C.1.3

Clinical Decision Support, Knowledge Management

C.1.4

Orders, Order Management

C.1.5

Results, Result Management

C.1.6

Medications, Medication Management

Page 16 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 1.1-4, 2.1-2, 2.6, 3.1, 3.3, 3.5, 4.1-4, 5.1, 5.3 1.1-4, 2.1-2, 3.1, 3.3, 4.1-4, 5.1, 5.3 1.1-4, 2.1-4, 2.6-7, 3.3, 3.5, 4.1, 4.4, 4.11, 5.1 1.1-8, 2.3-4, 2.8, 3.1, 3.4-5, 4.56, 5.2-3 1.1-4, 2.1-2, 2.4, 2.6, 3.1, 3.3, 3.5, 4.1-4, 5.1 1.1-4, 2.1-4, 2.6, 3.1, 3.3, 3.5, 4.1-2, 4.11

C.1.8

Allergies

C.1.9

Special Notes and Precautions

C.1.10

Preventative Care, Wellness

C.1.11

Consents and Authorization

C.1.12

Episode, Problem Management

C.1.13 C.2 C.2.1 C.2.2 C.2.3 C.3

Diet, Diet Management Work Flow and Operations Management Integral Work Flow Scheduling Work Lists Communication

1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-8, 5.1 1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-4, 4.7 1.1-4, 2.1-2, 3.1, 3.3-5, 4.1-8, 5.1

C.3.1

Inter-Disciplinary Communication

1.1-4, 1.6, 2.1-2, 2.4, 2.6-9, 3.1, 3.3-5, 4.1-4, 4.11, 5.3 1.1-6, 2.1-2, 2.4, 2.6-9, 3.1, 3.35, 4.1-4, 4.11, 5.3 1.1-4, 2.1-4, 2.6-7, 3.3, 4.1-4, 4.11, 5.1, 5.3 1.1-4, 2.1-4, 2.6, 4.1-4, 4.11

C.3.2

Inter-Practitioner Communication

C.3.3 C.3.4 C.4 C.4.1 C.4.2 C.4.3 C.4.4

Practitioner/Patient Communication Patient Education Records, Documents and Views Health Record Review (Chart Review) Timeline Perspectives Historical Snapshot Multi Media Record

1.1-4, 2.1-2, 3.1-6, 4.1-7, 5.2 1.1-7, 2.1-2, 2.6-7, 3.2-5, 4.1-7 1.1.7, 2,.1-2, 3.2-5, 4.1-7 1.1-4, 2.1-2, 3.2-5, 4.1-7, 4.10 1.1-4, 2.1-2, 3.2-5, 4.1-7, 4.10, 5.2 1.1-4, 2.1-2, 3.1-6, 4.1-7, 4.11, 5.2 1.1-8, 2.5, 3.1-6, 4.5-6, 5.2 2.2, 4.1-4

C.4.5

Clinical Document Management

C.4.6 C.4.7 C.4.8 C.5

Remote Access Special Records Protections Practitioner Personal Generated profile Clinical Support

C.5.1

Epidemiological Surveillance

1.2, 1.4, 1.8, 2.1-2, 2.6-9, 3.1, 3.3-5, 4.2-4, 5.1-3

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 17 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-4, 5.1-3 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 1.1-4, 1.6-7, 2.1-2, 3.1, 4.1-7, 4.11 1.1-4, 2.1-2, 3.1, 3.3, 3.5, 4.1-2 1.4, 3.1, 3.5, 4.1-2

C.5.3

Donor, Blood Bank

C.5.4

Patient Locator

C.5.5 C.5.6 C.5.7 C.6

Practitioner Locator Patient Transport Bed Management Measurement, Analysis, Research and Reporting

C.6.1

Quality Indicators

1.4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1, 3.3-5, 4.1-8, 5.1-3 1.4, 1.8, 2.1-2, 2.4, 2.6-7, 3.1, 3.3-5, 4.1-8, 5.1-3 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 1.1-4, 1.8, 2.1-2, 2.4, 2.6-7, 3.16, 4.1-11, 5.1-3 [TBD]

C.6.2

Performance and Accountability Measures

C.6.3

Analysis and Measures

C.6.4 C.6.5 C.7

Reports, Reporting Clinical Trials, Research (out of scope v1.0) Administrative, Finance

C.7.1

Encounter Management

1.1-4, 1.6-7, 2.2, 3.1, 3.3-5, 4.12, 4.7, 4.10 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 1.1-4, 1.6-7, 2.1-6, 3.1, 3.3-6, 4.1-4, 4.7, 4.11 3.3-5, 4.2, 4.3, 4.11 1.2, 1.4, 1.8, 2.2, 3.1, 3.3-5, 4.14, 4.8-9, 5.1-3 4.7, 4.10 4.7, 4.10 1.6, 3.1, 3.3-5, 4.7

C.7.2

Eligibility, Enrollment, Authorizations

C.7.3 C.7.4

Practitioner/Patient Relationship Multiple Person Linkage

C.7.5 C.7.6 C.7.7 C.7.8

Diagnosis and Procedure Coding Charges, Charge Management Costs, Cost Management Localization, Local Authority

4.3

Care Delivery Functions

Baseline 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 Letter Report. 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.

Page 18 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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
5.1

CONTENT MANAGEMENT COMPONENTS Managing content to support information integrity

Content management components developed for this work aim to ensure consistency and integrity across the 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 areas in subsequent iterations. Providing too much detail would represent a pitfall that could severely curtail consensual 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 may evolve 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 Functions

Although 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. EHR Functions 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 Statement
Functions will be decomposed until a sufficient level of granularity has been reached so that:

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.
HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved. Page 19 Draft #1

1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 1. 2. Functional statements support one user action. 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 primarily concerned 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 the cost 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 user’s needs and inclusion of system administrators better position the acceptance of EHR concepts 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. Further rationale 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 help clarify 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. This hierarchy is a reference tool and is not a 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 same as that developed by the IOM.

Page 20 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 Ambulatory care 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 generated profile 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 the standard 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 relating profiles, 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.

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 21 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

5.6

Developing a profile

Given that a profile is the elaboration of a set of functional statements to describe a context—whether that context describes a care setting or a specific use case—this 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 the profile 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 meet organizational 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. The settings 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 to instituting 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 Ambulatory Care 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
Page 22 Draft #1 HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 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 to browse 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 these relationships.

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 objectives is 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 follow a 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 communications—the 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 and information 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.

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 23 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 practices as 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 most advantageous 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 address conformance.

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 Standard differs 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 shareability of information content across HL7. A need for tools to support a knowledgebase of the functional triplets (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 alreadyestablished 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.

Page 24 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

7 CHAPTER 6: FUTURE
7.1

Next Steps

7.1.1 Ongoing development of the Model and standards
This 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 are expressed 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 which EHR-S implementations are to be measured must be unambiguous. As the Functional Model and Standard grows and matures, it is expected that organizations will advance their 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 standard—in terms of “generations” of EHR systems and not actual calendar years—will be a challenge for the 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 and Standard 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 interoperating with 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-S’s from the functional perspective of the user. This work represents a vital next step in the development of the architectural, reference and definitional EHR-S standards work that is taking place at this time.

8 APPENDICES
8.1 8.2 8.3 8.4 8.5 Profile Submission Form Functional Triplet Submission Form Institute of Medicine - Key Capabilities References Copyright Information

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 25 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

8.1

Profile Submission Form

Page 26 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

8.2

Functional Triplet Submission Form

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 27 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

8.3

Institute of Medicine - Key Capabilities

1. Health Information and Data 1.a Key Data 1.a.1 1.a.2 1.a.3 1.a.4 1.a.5 1.a.6 1.a.7 1.a.8 1.a.9 1.a.10 1.a.11 1,a.12 1.b 1.b.1 1.b.2 Problem List Procedure Diagnosis Medication List Allergies Demographics Diagnostic Test Results Radiology Results Health Maintenance Advance Directives Disposition Level of Service Minimum Datasets for Nursing Homes Defined MDS Expanded/Refined MDS

Page 28 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

1.c 1.c.1 1.c.2 1.c.3 1.c.4 1.c.5 1.c.5.1 1.c.5.2 1.c.5.3 1.c.5.4 1.c.6 1.c.6.1 1.c.6.2 1.d 1.d.1 1.d.2 1.e 1.e.1 1.e.2 1.e.3

Narrative (clinical and patient narrative) Free-text Template-based Deriving structure from unstructured text Natural Language Processing Structured and Coded Signs and Symptoms Diagnoses Procedures Level of Service Treatment Plan Single discipline Interdisciplinary Patient acuity/severity of illness/risk adjustment Nursing workload Severity adjustment Capture of Identifiers People and roles Products/devices Places (including directions)

2. Results Management

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 29 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0 2.a 2.a.1 2.a.2 2.a.3 2.a.4 2.a.5 2.b 2.c 2.d 2.d.1 2.d.2 2.d.3 Results Reporting Laboratory Microbiology Pathology Radiology Reports Consults Results Notification Multiple views of data and presentation Multimedia Support Images Waveforms Scanned documents Patient consents 2.d.4 2.d.5 Pictures Sounds

3. Order Entry/Management 3.a 3.a.1 3.a.2 3.a.3 3.a.4 3.a.5 3.a.6 3.a.7 3.a.8 3.a.9 Computerized provider order entry Electronic prescribing Laboratory Microbiology Pathology Xray Ancillary Nursing Supplies Consults

Page 30 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

4. Decision Support 4.a Access to Knowledge Sources 4.a.1 4.a.2 4.b 4.b.1 4.b.2 4.b.3 4.b.4 4.b.5 4.b.6 4.b.7 4.c 4.d 4.d.1 4.e 4.e.1 4.e.2 4.e.3 Domain knowledge Patient education Drug Alerts Drug dose defaults Drug dose checking Allergy checking Drug interaction checking Drug-lab checking Drug-condition checking Drug-diet checking Other Rule-Base Alerts (e.g., significant lab trends, lab test because of drug) Reminders Preventative services Clinical Guidelines and Pathways Passive Context-sensitive passive Integrated

4.f Chronic Disease Management 4.g 4.h Clinical Work List Incorporation of Patient and/or Family Preferences

4.i Diagnostic Decision Support 4.j Use of Epidemiologic Data

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 31 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

4.k 4.k.1 4.k.2 4.k.3

Automated Real-Time Surveillance Detect adverse events and near misses Detect disease outbreaks Detect bioterrorism

5. Electronic Communication and Connectivity 5.a 5.b 5.c 5.d 5.e 5.e.1 5.e.2 5.e.3 5.e.4 Provider – Provider Team Coordination Patient – Provider Medical Devices Trading Partners (external) Outside pharmacy Insurer Laboratory Radiology

5.f Integrated Medical Record 5.f.1 5.f.2 5.f.2.1 5.f.2.2 5.f.3 6. Patient Support 6.a 6.a.1 6.a.2 6.a.3 6.b Patient Education Access to patient education materials Custom patient education Tracking Family and Informal Caregiver Education Within setting Cross-setting Inpatient - outpatient Other cross-setting Cross-organizational

Page 32 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

6.c 6.c.1 6.c.2

Data entered by Patient, Family, and/or Informal Caregiver Home monitoring Questionnaires

7. Administrative Processes 7.a 7.a.1 7.a.2 7.a.3 7.b 7.b.1 7.b.2 7.b.3 7.b.4 Scheduling Management Appointments Admissions Surgery/procedure schedule Eligibility Determination Insurance eligibility Clinical trial recruitment Drug recall Chronic disease management

8. Reporting and Population Health Management 8.a 8.a.1 8.a.2 8.a.3 8.b 8.b.1 8.b.2 8.c 8.d Patient Safety and Quality Reporting Clinical dashboards External accountability reporting Ad hoc reporting Public Health Reporting Reportable diseases Immunization Deidentifying Data Disease Registries

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 33 Draft #1

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

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 Health Care. 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.

Page 34 Draft #1

HL7 EHR System Functional Model and Standard, Release 1.0. © 2003. All rights reserved.

HL7 EHR System Functional Model and Standard (DSTU), Release 1.0

8.5

Copyright Information

HL7 EHR System Functional Model and Standard Release 1.0. 2003. All rights reserved.

Page 35 Draft #1