1. Networking and Health Information Exchange
Welcome to Networking and Health Information Exchange, EHR Functional Model Standards. This is Lecture a.
This lecture focuses on the characteristics of an EHR and what the characteristics of it’s architecture and content are, particularly from the point of view of the source of the content and the networking required to aggregate the data from all sources. We introduce several standards that relate to definition, architecture and content of the EHR. The EHR is much more than a repository of data. Its value comes largely through a rich set of functionalities that add value to the aggregated database that will be addressed in the following units.
EHR Functional Model Standards
Lecture a
This material (Comp 9 Unit 6) was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. EHR Functional Model Standards Learning Objectives
Understand the definition(s) of an Electronic Health Record
Understand various architectures for an EHR
Identify and understand key standards for the EHR
Understand the HL7 EHR Functional Model Standards
Understand the HL7 PHR Functional Model Standard
The Objectives for this lecture, EHR Functional Model Standards, are to:
Understand the many definitions of an Electronic Health Record,
Understand the various architectures of an EHR,
Identify and understand key standards for the EHR including ISO/CEN 13606,
Understand the HL7 EHR Functional Model Standards and its importance to the certification process, and
Understand the HL7 Personal Health Record functional model.

3. What is an EHR? Many definitions – why? What is its form and format?
What is its purpose?
Who is it for?
Many definitions – why?
There has never, ever been a shared understanding of what an EHR is and what we are trying to achieve with the EHR. Many view it simply as a replacement for the paper record. The power of the EHR results from its use in an active, interactive way with the users. The real value comes, not from a focus on the input of data, but on how that data can be used to enhance information about the patient at the point and time of care and about using the data with knowledge sources to drive decision making. In addition, the power of the EHR can be used to study treatments and outcomes to acquire new data, to understand segments of the population and to understand what influences health, health care, treatments and outcomes. The tremendous change in technology and the increased power of technology has stayed ahead of the visions for the EHR.
The EHR is viewed as a birth-to-death or longitudinal record of any and everything about the patient. There are opinions as to what data should be included in the EHR. When is more too much? What is the difference between a data warehouse and an EHR? Is an EMR and an EHR the same thing?
What is its form and format? Documents, folders, structured, coded data elements with coded values, text, etc.
What is its purpose? Document care, communications, legal, research, audits, reimbursement, etc.
Who is it for? Provider, patient, payer, government, auditor, researcher, public health worker, etc.
The answers to all of these questions and others are important to the architecture and content of the EHR. It is important to understand your definition of what we call the EHR. Your definition may be biased by where you work – a hospital, a clinic, a doctor’s office, a nursing home, or a long-term care setting. The push for a nationwide infrastructure requires you to have some understanding of how these different settings relate.

4. What is an EHR? Also Known As: It’s not a: Automated Medical Record
Computerized Medical Record
Computer-Based Medical Record
Electronic Medical Record
Electronic Health Record
It’s not a:
Data Warehouse
Clinical Data Repository
Disease Registry
The EHR has been known over the years as an automated Medical Record, a computerized Medical Record, a computer-based Medical Record, an electronic Medical Record, an electronic Health Record, and probably by many other names.
What it is not is: a clinical data repository, a data warehouse, or a disease registry.
The development of what we currently call the EHR has evolved over the past 50 years. Its name has changed many times, and its name probably reflected the perception as well as the technology available at the time. The ultimate transition from medical to health reflects the transition in our health care model. The initial focus on the computer has yielded to electronic. What the EHR contains, or does not contain, is important. Functionality is very important and distinguishes the EHR from a Clinical Data Warehouse or Clinical Data Repository, though these may serve some of the functions of the EHR.
We still debate what to call it or what it is. What problems are we solving? Are there multiple uses, what are they, and what impact does each have on the others?

5. Institute of Medicine (IOM) Definition (1991, 1997)
The patient record:
Is a principal repository for data concerning a patient’s health care
Affects virtually everyone associated with providing, receiving, auditing, regulating or reimbursing health care services
One of the first formal definitions of the EHR came in a seminal publication from the Institute of Medicine in This publication actually referred to the EHR as a Computer-Based Patient Record. This publication contributed to an increased awareness of the value of the use of computers in health care. The revised edition, published in 1997, noticed that little progress had been made in implementing EHR systems and, with the exception of two additional chapters that discussed the current use of the EHR, was not otherwise changed.
The IOM definition is: “A principal repository for data concerning a patient’s health care that affects virtually everyone associated with providing, receiving, auditing, regulating or reimbursing health care services” (Dick, 1997).
The IOM definition defines a Computer-Based Patient Record as an “electronic patient record that resides in a system specifically designed to support users by providing accessibility to complete and accurate data, alerts, reminders, clinical decision support systems, links to medical knowledge, and other aids.”
This definition still works. Note the words “complete” and “accurate” data and the use of “decision support.” Note the coupling to medical knowledge. When the American Recovery and Reinvestment Act was passed in 2009, one goal was to significantly increase the use of EHRs in both inpatient and outpatient settings, which at the time was less than 20%. By 2015 the EHR adoption rate had increased to over 80% of outpatient settings and over 90% of inpatient settings.
"A computer-based patient record is an electronic patient record that resides in a system specifically designed to support users by providing accessibility to complete and accurate data, alerts, reminders, clinical decision support systems, links to medical knowledge, and other aids.“
(Dick, 1997)

6. Expanding the Definition
Different groups have expanded on these earlier definitions of the EHR
Groups include ISO, CEN, IOM, ASTM, and others
Common understanding is important for sharing and aggregating of clinical data
Since the IOM definition, a number of SDOs have published standards related to definition, architecture and content. These groups include ISO (International Organization for Standardization), CEN (European Committee for Standardization), IOM (Institute of Medicine), ASTM (American Society of the International Association for Testing and Materials) and others. It is still being defined in new ways by others.
We will look at a set of standards created by different groups that expand the definition of the EHR from this IOM definition.
A common understanding is important for the sharing and aggregating of clinical data.

7. ISO EHR Standards ISO TR 20514 ISO TS 18308 ISO IS 13606-1
EHR Definition, Scope and Context
ISO TS 18308
Requirements for an Electronic Health Record Reference Architecture
ISO IS
EHR Communication- Part 1: Reference Model
These three ISO standards provide views of what the architecture structure and content of an EHR should be. 
ISO TR provides some simple concepts about what an EHR might be. 
ISO TS 18308  defines the Requirements for an Electronic Health Record Reference Architecture and provides some suggestions for an EHR architecture that would support interoperability and data sharing. 
In Europe, CEN defined a five-part standard for EHR architecture and communication. This standard is now also an ISO standard by the same number.  This standard is influencing what is happening in Europe.
ISO addresses multiple aspects of the EHR and its contents.  We previously noted part two of this standard when addressing Archetypes.  Part one of the standard  defines a reference model – or a conceptual plan of what the architecture of an EHR should be.

8. ASTM EHR Standards
E Standard Guide for Description of Reservation/Registration-Admission, Discharge, Transfer (R-ADT) Systems for Automated Patient Care Information Systems
E 1384 Standard Guide for Content and Structure of the Electronic Health Record
E Standard Specification for the Coded Values Used in the Electronic Health Record
The ASTM standards are more traditional in name and content. These are largely informational in content but have been maintained and updated.
E 1239 is a Standard Guide for Description of Reservation/Registration-Admission, Discharge, and Transfer (R-ADT) Systems for Automated Patient Care Information Systems. It is focused on a hospital information system application.
E 1384 is a Standard Guide for Content and Structure of the Electronic Health Record, and defines a more traditional approach.
E 1633 is a Standard Specification for the Coded Values Used in the Electronic Health Record and deals with the issues of terminology and data representation.
These standards have education value even though they may not be used to define a specific system.

9. Additional ASTM EHR Standards
E 1715 Standard Practice for an Object-Oriented Model for Registration, Admitting, Discharge, and Transfer (R-ADT) Functions in Computer Based Patient Record Systems
E Standard Guide for a View of Emergency Medical Care in the Computerized Patient Record
E 1869 Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health records
Some of the additional ASTM standards include:
E 1715 is a Standard Practice for an Object-Oriented Model for Registration, Admitting, Discharge, and Transfer (R-ADT) Functions in Computer Based Patient Record Systems. Note that E1715 is essentially the same topic as E 1239.
E is a Standard Guide for a View of Emergency Medical Care in the Computerized Patient Record.
This standard is more recent and perhaps is the most valuable of the set. These standards may be obtained from ASTM, and there is a cost.
E1869 is a Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health records and is one of the newer standards. It defines standards for securing EHRs.

10. EHR System (EHR-S)
Includes the data storage and supporting applications that provide value
Includes the functionalities that enable HIT for patient care
Promotes and defines criteria for implementation of the EHR
Makes the EHR the beginning, not the end of the journey
The EHR generally refers to just the storage of the data and maybe a few related functions associated with collecting and presenting the data. The EHR system expands to include all functions related to the EHR. These functions will be such things as billing and claims support, decision support, various reporting functions, queries, etc. These functionalities provide the value behind an EHR. It is not the EHR by itself that provides the value, it is really the EHR-S. Many people seem to think of the EHR or EHR-S as the end of the journey – the destination of the roadmap. The new thinking recognizes the EHR-S as the beginning of the journey. Given an EHR-S that supports a rich set of functions, what can be accomplished and the contributions to health and healthcare are huge. The EHR-S model now resides with the Health Level Seven, or HL7 organization and is free to download.

11. EHR-FM
Provides a reference list of functions that shall, should or may be present in an EHR-S.
Enables common understanding of functions sought or available in any given setting.
Includes functions considered essential in at least one care setting.
The EHR functional model provides a reference list of functions that shall, should or may be present in an EHR-S; enables common understanding of functions sought or available in any given setting; and includes functions considered essential in at least one care setting.
It might be an interesting exercise to sit down and list all of the things you can think of about what an EHR should be able to do.  That also might be an interesting contrast to what you think systems currently available can do.   Our list must include all of what might be required in various units or departments such as medical units, service units, different sites – emergency rooms, intensive care units, hospitals, clinics, nursing homes, surgery suites, group practices, and solo practitioners.  Also, differences in the different clinical specialties such as cardiology, primary care, oncology, anesthesiology, etc. are addressed.
Exactly what should be included in a functional module standard is an interesting challenge. It should not depend on a particular technology, since technologies change rapidly. It should not depend on a specific implementation because of all the many variables in the implementation process. It also needs to be vendor neutral – not include functions that favor one vendor over another. It does not define an EHR and it does not imply conformance to any EHR specification. It does not endorse any specific technologies, although examples may mention a specific technology. It is not an EHR specification nor a conformance specification and it is not a definition of an EHR.
The functions can and will be satisfied through a number of different processes. The functions do not require a specific architecture or even content, although there is a relationship. Obviously content is necessary to meet the needs of such functions as a problem list.

12. EHR-S FM (HL7 International, 2014) Overarching (OV)
Care Provision (CP)
Care Provision Support (CPS)
Population Health Support (POP)
Administrative Support (AS)
Record Infrastructure (RI)
Trust Infrastructure (TI)
This slide shows the seven sections that contain the functions of the EHR-S Functional Model. These sections are Overarching, Care Provision, Care Provision Support, Population Health Support, administrative Support, Record Infrastructure and Trust Infrastructure.
(HL7 International, 2014)

13. EHR-S FM Sections
Overarching: contains Conformance Criteria that apply to all EHR Systems and consequently must be included in all EHR-S FM compliant profiles.
Care Provision: contains those functions and supporting Conformance Criteria that are required to provide direct care to a specific patient and enable hands-on delivery of healthcare. The functions are general and are not limited to a specific care setting and may be applied as part of an Electronic Health Record supporting healthcare offices, clinics, hospitals and specialty care centers.–
Care Provision Support: focuses on functions needed to enable the provision of care This section is organized generally in alignment with Care Provision Section. For example, CP.4 (Manage Orders) is supported directly by CPS.4 (Support Orders).
Population Health Support: focuses on those functions required of the EHR to support the prevention and control of disease among a group of people (as opposed to the direct care of a single patient. This section includes functions to support input to systems that perform medical research, promote public health, & improve the quality of care at a multi-patient level.
Let’s take a closer look at each of these sections:
The Overarching section contains Conformance Criteria that apply to all EHR Systems and consequently must be included in all EHR-S FM compliant profiles.
The Care Provision section contains those functions and supporting Conformance Criteria that are required to provide direct care to a specific patient and enable hands-on delivery of healthcare. The functions are general and are not limited to a specific care setting and may be applied as part of an Electronic Health Record supporting healthcare offices, clinics, hospitals and specialty care centers.–
The Care Provision Support section focuses on functions needed to enable the provision of care This section is organized generally in alignment with Care Provision Section. For example, CP.4 (Manage Orders) is supported directly by CPS.4 (Support Orders).
The Population Health Support section focuses on those functions required of the EHR to support the prevention and control of disease among a group of people (as opposed to the direct care of a single patient. This section includes functions to support input to systems that perform medical research, promote public health, & improve the quality of care at a multi- patient level.

14. EHR-S FM Sections
Administrative Support: focuses on functions required in the EHR-S to enable the management of the clinical practice and to assist with the administrative and financial operations. This includes management of resources, workflow and communication with patients and providers as well as the management of non-clinical administrative information on patients and providers.
Record Infrastructure: consists of functions common to EHR System record management, particularly those functions foundational to managing record lifecycle (origination, attestation, amendment, access/use, translation, transmittal/disclosure, receipt, de-identification, archive…) and record lifespan (persistence, indelibility, continuity, audit, encryption). RI functions are core and foundational to all other functions of the Model (CP, CPS, POP, AS).
Trust Infrastructure: consists of functions common to an EHR System infrastructure, particularly those functions foundational to system operations, security, efficiency and data integrity assurance, safeguards for privacy and confidentiality, and interoperability with other systems. TI functions are core and foundational to all other functions of the Model (CP, CPS, POP, AS and RI).
Continuing the list;
The Administrative Support section focuses on functions required in the EHR-S to enable the management of the clinical practice and to assist with the administrative and financial operations. This includes management of resources, workflow and communication with patients and providers as well as the management of non-clinical administrative information on patients and providers.
The Record Infrastructure section consists of functions common to EHR System record management, particularly those functions foundational to managing record lifecycle (origination, attestation, amendment, access/use, translation, transmittal/disclosure, receipt, de-identification, archive…) and record lifespan (persistence, indelibility, continuity, audit, encryption). RI functions are core and foundational to all other functions of the Model (CP, CPS, POP, AS).
Finally, the Trust Infrastructure section consists of functions common to an EHR System infrastructure, particularly those functions foundational to system operations, security, efficiency and data integrity assurance, safeguards for privacy and confidentiality, and interoperability with other systems. TI functions are core and foundational to all other functions of the Model (CP, CPS, POP, AS and RI).

15. Information Infrastructure
PHR-FM
Personal Health
PH.0
PH.1
PHR Account Holder Profile
PH.2
Manage Historical Clinical Data and Current State Data
PH.3
Wellness, Preventative medicine, and Self Care
PH.4
Manage Health Education
PH.5
PHR Account Holder Decision Support
PH.6
Manage Encounters with Providers
Supportive
S.1
Provider Information
S.2
Financial Management
S.3
Administrative Management
S.4
Manage Other Resources
Information Infrastructure
IN.1
Health Record Information Management
IN.2
Standards Based Interoperability
IN.3
Security
IN.4
Auditable Records
This slide shows the overview of the PHR-FM with the subsections identified.
The primary sections include: Personal Health with subsections
Personal Health details,
PHR account holder profile
Manage historical clinical data and current state data,
Wellness, preventative medicine, and self care,
PHR Account holder decision support, and
Management encounters with providers.
The Supportive section includes:
Provider information,
Financial management,
Administrative management, and
Other resource management.
The Information Infrastructure includes:
Health record information management,
Standards-based interoperability,
Security, and
Auditable records.
These subsections will be discussed briefly in the following slides. Note that these subsections are different from the EHR-FM.

16. PHR-S FM Sections
Personal Health section: are the subset of PHR-S functions that manage information and features related to self-care and provider based care over time. PH section functions can yield a summary record of an individual’s care, including ad hoc views of the overall PHR.
Supportive section: are the subset of PHR-S functions that assist the PHR Account Holder with administrative and financial requirements. Also included are PHR-S functions that provide input to systems that perform clinical research, promote public health and seek to improve the quality and outcome of health care delivered.
Information Infrastructure section: consists of PHR-S functions that support Personal Health and Supportive section functions. These functions ensure that the PHR-S provides information privacy and security, interoperates with other information systems (including PHR and EHR systems), and helps make PHR-S features accessible and easy to use.
The three sections of the PHR-S Functional Model each have a number of functions included.
Personal health section functions are the subset of PHR-S functions that manage information and features related to self-care and provider based care over time. PH section functions can yield a summary record of an individual’s care, including ad hoc views of the overall PHR. This section defines the clinical portion of the personal health record as well as individual provider encounter information.
Supportive section functions are the subset of PHR-S functions that assist the PHR Account Holder with administrative and financial requirements. Also included are PHR-S functions that provide input to systems that perform clinical research, promote public health and seek to improve the quality and outcome of health care delivered. Activities like clinic scheduling, billing information, and other administrative functions would be included in this section.
Information infrastructure section contains functions that support Personal Health and Supportive section functions. These functions ensure that the PHR-S provides information privacy and security, interoperates with other information systems (including PHR and EHR systems), and helps make PHR-S features accessible and easy to use. These are functions that ensure the reliability, confidentiality, and security of the PHR and are an important foundation for any system.

17. Intent of Standard Is technology neutral Is implementation neutral
Does not endorse any specific technologies, although examples may mention a specific technology
Is not an EHR specification nor a conformance specification
Is not a definition of an EHR
Exactly what should be included in a functional module standard is an interesting challenge. It should not depend on a particular technology, since technologies change rapidly. It should not depend on a specific implementation because of all the many variables in the implementation process. It also needs to be vendor neutral – not include functions that favor one vendor over another. It does not define an EHR and it does not imply conformance to any EHR specification. It does not endorse any specific technologies, although examples may mention a specific technology. It is not an EHR specification nor a conformance specification and it is not a definition of an EHR.
The functions can and will be satisfied through a number of different processes. The functions do not require a specific architecture or even content, although there is a relationship. Obviously content is necessary to meet the needs of such functions as a problem list.
Hopefully this discussion on standards for EHRs and PHRs helps you understand how we can come together on common understanding and implementation of technology without having to use one single vendor.

18. EHR Functional Model Standards Summary – Lecture a
Several standards from various SDOs that deal with EHR definition, architecture and content
None of these standards are complete and definitive
Unfortunately, the current state of the art for EHRs is similar to the story of five blind men and the elephant
Until a stronger agreement is reached, content interoperability, efficiency, and query will be compromised
We are unlikely to ever have a single standard for an EHR architecture
The reasons include:
Lack of agreement among developers
The proprietary nature of the architectural design
Legacy systems
This concludes the Lecture of EHR Functional Model Standards.
In this lecture, we have drawn attention to several standards from various SDOs that deal with EHR definition, architecture and content. None of these standards is complete and definitive. Unfortunately, the current state of the art for EHRs is similar to the story of 5 blind men and the elephant. Until a stronger agreement is reached, content interoperability, efficiency, and query will be compromised. We are unlikely to ever have a single standard for an EHR architecture. The main reasons include lack of agreement among developers, the proprietary nature of the architectural design, and legacy systems.

19. EHR Functional Model Standards References – Lecture a
Dick, R. S., Steen, E. B., & Detmer, D. E. (Eds.). Committee on Improving the Patient Record, Institute of Medicine. (1997). Computer-Based Patient Record : An Essential Technology for Health Care (Rev ed.). Washington, D.C.: The National Academy Press.
ASTM. (1996, Feb). Standard Guide for Properties of Electronic Health Records and Record Systems. E
Health IT Dashboard. (2016) The Office of the National Coordinator for Health IT.
HL7 International, (2014, April). HL7 EHR-System Functional Model, Release 2.
HL7 International, (2014, May). HL7 Personal Health Record System Functional Model, Release 1.
Acknowledgement:
The material presented in this lecture was taken from the web sites of the various standards. Details of the standards listed here can be obtained from the various SDOs. There may be a membership cost or other cost associated with the standards.
Images
Slide 6: Photo of book by W. Ed Hammond, PhD.
No audio.

20. EHR Functional Model Standards Lecture a
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
No audio.
Health IT Workforce Curriculum Version 4.0