Comp9 Unit6c Audio Transcript

Networking and Health Information Exchange: EHR Functional Model Standards
Audio Transcript
Slide 1
Welcome to Networking and Health Information Exchange, EHR Functional Model
Standards. This is Lecture c.
This component, Networking and Health Information Exchange, addresses what is

required to accomplish networking across and among disparate organizations who have
heterogeneous systems.
Unit 6 covers EHR Functional Model Standards and consists of three lectures. Over
these three lectures, we will talk about the Electronic Health Record and the functional
requirements an EHR system must satisfy.
This lecture focuses on functional models for the Personal Health Record or PHR. The
importance of the PHR seems to be increasing, and this lecture is important because of
the likelihood that many of the workforce will have some connection to the PHR as
part of an organization that supplies data, as part of a vendor organization that develops
a PHR, or as part of a service organization that provides a PHR service. We will also
discuss the process of certification in this lecture. Certification is important because the
motivation for being a certified EHR, or buying and using a certified EHR is huge it is
required by meaningful use to be eligible for the incentive payments for providers or
organizations.
The PHR is of growing interest, and as the responsibility for health care moves more to
the individual, it will become increasingly important. It may become one of the most
important parts of health and health care therefore, we include it in this lecture.
Slide 2
The Objectives for this unit, EHR Functional Model Standards, are to understand what
an EHR is and what its characteristics are.
Health IT Workforce Curriculum Networking and Health Information Exchange 1

Version 3.0/Spring 2012 EHR Functional Model Standards
Lecture c
This material Comp9_Unit6c 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 IU24OC000024.
Specifically, the objectives are to:
Understand the many definitions of an Electronic Health Record and unfortunately

there are many definitions.
Understand architecture for an EHR; and there are also many different architectures.
In many cases, these architectures are proprietary to a specific commercial system.
Identify and understand key standards for the EHR including ISO/CEN 13606. and
Understand the HL7 EHR Functional Model Standards and its importance to the
certification process.
Slide 3
Additional Objectives for this unit, EHR Functional Model Standards, are to:
Understand the functional profiles that select specific functions from the generic
model for specific applications,
Understand the functional standards for Functional Models for the PHR, and
Understand the functional certification requirements for EHR, PHR and functional
profiles.
Slide 4
Specifically, the HL7 Personal Health Record Functional Model does not define PHR but
does assume certain characteristics. The PHR-FM assumes a pull-push or push-pull
model. It assumes many sources of data, and it assumes control by an individual,
usually to the person whose data is included in the PHR.
The definition or model of PHR is even more confusing than EHR for several reasons.
The PHR seems to be a moving target as we will see in the following slides. Even who
will maintain the PHR depends on the particular model. In some cases, data is pushed
from organizations into the PHR; in other cases, the data is pulled from an
organizational source and aggregated into the PHR. In all cases, the release of data
from the PHR is assumed to be the patient or owner of the PHR.
Slide 5
There are currently five models or approaches to the PHR.
These are:
Provider-based,
Health record bank,
Payer-based,
Free standing, and
Employer-based.

Lecture c
Profiles are being developed for each of these models from the generic functional model
set.
Each of these models has advantages and disadvantages. At least for the next few
years, each of these models will be in existence somewhere. Perhaps over time, the
best model will rise to the top. Who pays for this service will also influence the
outcome.
Slide 6
The Provider-Linked model largely means that the healthcare organization designs a
portal by which a patient can see his clinical, administrative and financial data, which is
clinician-controlled, and is derived from the institutional EHR. Some of these systems
provide scheduling and appointment services. Some provide access to knowledge
modules. Added functionality includes e-mail, refill requests, and a growing set of
others. This PHR model is perhaps the most widely available and is provided without
cost to the patient.
In some cases, the patient can add data into the PHR, and that data may be reviewed
by the patients provider. The concept of medical home will likely advance this model.
Most current versions of this model do not aggregate data from other sources into the
PHR, and most PHR systems do not have the capability to integrate data from multiple
sources. With this model, the database usually resides with the organization.
Slide 7
The Health Record Bank model keeps the data for the patient. The PHR is maintained
by a Trust. It serves as a persistent, secure health information repository for an
individual. Many services may be provided, including the aggregation of data from
multiple sources. A limitation of this model is that rarely are scheduling and
appointment services provided, and rarely is data pushed to a provider taking care of
the patient. The funding model is that the patient or other external source pays for the
PHR service. Release of data is controlled by the patient.
Slide 8
The Payer Model is one in which the data is extracted from claims data, including
reimbursement for medications. Problems with this approach depend on the degree of
correspondence between the billing codes and the actual data. These systems may or
may not be linked to a provider organization. Data items not covered by insurance will
not be included in the records. For the most part, the database resides with the payer.
There is usually no charge to the patient in this model.

Lecture c
Slide 9
In the Consumer-Centric model, the consumer assumes full responsibility for the PHR.
The data might be stored on the patients own computer or could be stored with a
service bureau. The PHR is usually web-based. The patient might have an agreement
with a provider to download his or her data, or he or she may have the responsibility for
entering the data either from electronic form or paper form into his or her own record.
This model would usually be purchased and maintained by the patient. Issues of
backup and security are left to the user. The user can enter data into these systems,
including such items as weight, exercise, and travel.
Slide 10
The standard for the PHR-FM was released as a draft standard for trial use in 2008. As
in the case of the EHR-FM, the list of functions is not exhaustive; it is a core standard.
With the use of so many different models, the challenge to create a generic set of
functionalities is much greater than for an EHR.
The same structure as for the EHR-FM was used in creating this standard.
Slide 11
The functionalities cover the clinical data capture and the use of that data, similar to an
EHR. The functions include the ability to capture and maintain demographic, insurance,
and provider information; and include functionality for the capture of problems,
conditions, symptoms, allergies, medications, laboratory and other test results,
immunizations, and encounters. Later units will contrast one model that compares the
PHR with the EHR. A major change in thinking recognizes the ability of a patient to
understand the meaning of data, the significance of problems and diagnoses, the
importance of conformance with the taking of medications, and in assuming more
responsibility for his own health. The required functionalities attempt to provide access
to the data and functions that enable those goals.
Slide 12
The richness of the functionality of a PHR depends on the model and the actual
implementation. A lot of the functionality will be optional. Included are secure
messaging, graphical presentation of results, patient education, guideline-based
reminders, appointment scheduling and reminders, drug-to-drug interactions, formulary
management, healthcare cost comparisons, document storage and clinical trial
eligibility.
In the commercial market, these expanding functionalities will be used to promote a

specific product, and over time may move from an optional function to a required

Lecture c
function. If the PHR is yours, which of these optional functions would you like? There
are several products on the market today that focus on one or more of these products
for a market niche.
Slide 13
The functional outline for the PHR is divided into three sections, similar to the EHR-FM.
These sections are: Personal Health, Supportive, and Information Infrastructure. A core
set of functions is identified in each.
Slide 14
This slide shows the overview of the PHR-FM with the subsections identified.
The primary sections include: Personal Health with subsections

Account holder profile,
Manage historical clinical data and current state data,
Manage health education,
Account holder for decision support, and
Management encounters with problems.
The Supportive section includes:

Provider management,
Finance 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 in detail in the following slides. Note that these
subsections are different from the EHR-FM.
Slide 15
The subsections represent the top level functions for a given section. The numbering
scheme follows a hierarchical structure.
The Personal Health Functions (PH.1) focus on the clinical data and clinical functions.

Lecture c
The first subsection (PH.1.0) includes functions that support building a profile of the
owner of the PHR and defines what the owner wishes his PHR to contain.
PH.1.0 is the parent of child PH.1.1, which is Identify and Maintain a Patient Record and
so forth. In some cases, the children fully define the functions in that category.
This lecture will not go into detail about what functions are listed. You will need to get a
copy of the standard.
Note that only a subset of the inclusive set of functions will apply to any particular PHR-
S. What functions are required will, to a large extent, be defined by the owner of the
PHR. This perspective is different from that of the EHR-S.
Slide 16
Personal health descriptors help an individual keep track of data and events that relate
to managing and assessing their own care. They manage information related to self-
care and provider-based care over time. An example: a function that assures an
individuals demographic data is complete and maintained so that the individual is
unambiguously identified. The Actor is the account holder or principal user.
These functions are intended to support a summary record of an individuals care and
will include data extracted from an EHR.
Slide 17
These are the top level functions in the supportive category. They include:
Provider management: Caregivers associated with individuals care,

Financial management: Insurance and other payer and payment information,
Administrative management: Could include details of health-related programs in
which the patient is engaged, and
Other resource management.
Slide 18
Support descriptions are the subset of functions that assist administrative and financial
requirements; they provide input into patient-care systems, promote public health and
improve quality of care. An example: query local immunization registries to determine
the persons immunization status. The actor is the primary account holder but may also
be a healthcare provider.
Supportive functions could provide input to systems that perform medical research; so,
tracking enrollment and commitments for a clinical trial in which the individual is

Lecture c
enrolled, or a chat room the patient frequents, or a favored source of healthcare-related
knowledge, or favorite diets, etc. These functions support behavioral changes, promote
public health and seek to improve the quality of care. These functions would include
decision support algorithms that support such things as when immunizations are due:
Who knows when you received your last tetanus shot? When you travel, what shots and
other preparations do you need? How often should your blood sugar be measured?
Slide 19
The Information Infrastructure Functions are common functions that support the other
two categories. The second level of detail is broken down into:
IN.1.0 Health record information management: What is required to manage your PHR.
When and where do you back up your PHR?
IN.2.0 Standards-based interoperability: If you need data from other sources, what
functions are required to support transparency and easy aggregation of data from
multiple sources into your PHR?
IN.3.0 Security What levels of security do you need? How do you get them? What
should you worry about? These functions provide the required functions to provide that
security. YOU control the PHR. You require security functions to ensure your intents are
carried out.
IN.4.0 Auditable records - how do you make sure your record is complete, has integrity
and can be trusted to manage your health?
Slide 20
The data domains addressed in the PHR Functional Model include:
Patient Information,
Family History including risks identified from family history,
Physiological Information such as weight, height, blood type,
Encounter including problems, procedures,
Medication or prescription data,
Immunization,
Provider or the set of doctors providing care to person,
Facility or the places person receives care,
Health Risk Factors such as habits including smoking, alcohol, risk behavior,
Advance Directives,
Alerts to allergies and adverse reactions,
Health Plan Information, and
Plan of care.

Lecture c
Slide 21
Certification is to provide confidence that electronic health information technology
products and systems are secure; can maintain data confidentiality; can work with other
systems to share information; and can perform a set of well-defined functions.
Certification is designed to assure health care providers that the EHR technology that
they acquire can perform the functions they need to participate in the Medicare and
Medicaid EHR incentive program. Physicians and hospitals that become meaningful
users of certified EHRs and modules are eligible for incentive payments under the
HITECH Act.
Slide 22
The first certification group was the Certification Commission for Healthcare Information
Technology (CCHIT), formed in 2004 to certify HIT products. Established as an
independent, nonprofit organization,it was formed by three HIT organizations:
American Health Information Management Association,
Healthcare Information and Management Systems Society, and
National Alliance for Health Informatics Technology.
Slide 23
CCHIT has a strong engagement of diverse stakeholders including providers,
developers, HIT experts, payers, and government. It was the first and only certification
body until the final rule was issued in 2010. CCHIT worked under contract with
HHS/ONC from 2005-2009. It was federally recognized and was a requirement of state
eHealth programs and private sector pay-for-performance.
From 2005 to 2010, CCHIT certified over 250 products, representing 85% of the
installed market. It is a voluntary, consensus-based criteria development with a strong
engagement of stakeholders. 100% compliance to the specifications was required.
Vendors were subjected to rigorous, objective and consistent testing. Over 300 persons
participated in the workgroups that did the certification testing.
Other factors included:

Zero tolerance for conflict of interest,
Proved scalability,
Open book model criteria published,
Panel of well-trained expert jurors free of financial conflicts, and
Included an appeal process.

Lecture c
Slide 24
ONC published the Final Rule on Certification in 2010. During that year, 2010, 6 groups
qualified as ATCBs.
These groups were:

Surescripts,
ICSA Labs,
SLI Global Solutions,
InfoGard Laboratories, Inc.,
CCHIT, and
Drummond Group, INC.
All of these groups, with the exception of Surescripts, are qualified to certify complete
EHR and EHR Modules. Surescripts is qualified only to certify E-Prescribing and
Privacy and Security EHR Modules.
In February, 2012, CCHIT certified more than 70% of attested EHRs.
Slide 25
These are the certifications that are currently available.
Ambulatory which includes

Child Health,
Cardiovascular Medicine,
Behavioral Health,
Dermatology, and
Clinical Research.
Inpatient EHR,
ePrescribing,
Emergency Department, and
Long Term or Post-Acute Care.
Note the correspondence with HL7 functional model profiles.

Lecture c
Slide 26
The certification criteria is designed to assure providers that certified EHR technology
can support achievement of meaningful use.
Certification criteria
Assure providers that certified EHR technology can support achievement of
Meaningful Use
Guarantee key capabilities that can be tested objectively and
Support innovation by providing a minimal set
Standards
Provide incremental build capacity and
Establish foundation for greater interoperability.
What standards, that are required to support the required functionality, are identified in
the certification process?
Key to meaningful use is interoperability. Key to interoperability are standards. So

standards are closely related to certification. Most of these standards have been
identified, or will be identified in this component. Certification is an attempt to solve
many of the existing and past problems of failure in the use of HIT.
Slide 27
The current market, as well as implementation strategies of most users, support
implementation of components of an EHR-S, rather than the purchase of a complete
EHR-S from a single vendor. Acknowledging this reality, the certification process
supports both certification for complete EHR-S or for components of broader and more
expanded systems.
The regulatory process will certify a complete EHR or combination of EHR Modules,
each of which meets the requirements included in the definition of a qualified EHR; and
has been tested and certified in accordance with the certification program established
by the National Coordinator as having met all applicable certification criteria adopted by
the Secretary, HHS.
ONC has established a certified health IT product list at website http://onc-

chpl.force.com/ehrcert.

Lecture c
Slide 28
Definitions:
Certification for a complete EHR means that the EHR technology that has been
developed to meet all applicable certification criteria adopted by Secretary of Health and
Human Services (HHS).
EHR Module is defined as any service, component, or combination thereof that can
meet the requirements of at least one certification criterion adopted by the Secretary of
HHS.
For example, if a hospital wanted to purchase a system that would be used only in its
emergency department, it could buy a certified product that just addressed this domain.
The same might be true if a hospital wished to buy a system only for its obstetrics clinic.
However, as these modules are linked, we need to be sure that safety and integrity are
preserved across the boundaries.
Slide 29
The standards and criteria are organized into 4 categories:
Content Exchange Standards: These are the standards that are required to share
clinical information such as clinical summaries, prescriptions, clinical documents,
etc.
Vocabulary Standards: Standard nomenclatures used to describe clinical problems,
procedures, prescriptions, allergies, etc.
Transport Standards: Standards used to exchange data among heterogeneous
systems
Privacy and Security Standards: Authentication, access control, role based access,
digital signatures, encryption.
Again, most of these standards and topics have been covered within this component.
Slide 30
In this lecture we have explored a super set of functional requirements for the Personal
Health Record. The PHR is still evolving, and the functional requirements will continue
to change. We also discussed the ONC certification process. This topic is important to
us because it is connected to meaningful use and the incentive payments.
While you are not an expert in all of the topics covered in this lecture, you should feel
comfortable with an overview of the functional models of an EHR, and have a good idea
of where you might look when you need to know more.

Lecture c
Slide 31
This concludes EHR Functional Model Standards.
This unit has introduced the concept of an EHR and the PHR, from the perspective of
standards that relate to definition, architecture, and required functions.
We looked at specific profiles and at certification in the U.S.
Slide 32
No audio.
End.

Lecture c

Comp9 Unit6c Audio Transcript

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Comp9 Unit6c Audio Transcript

Transféré par

Droits d'auteur :

Formats disponibles

Networking and Health Information Exchange: EHR Functional Model Standards

This component, Networking and Health Information Exchange, addresses what is

Health IT Workforce Curriculum Networking and Health Information Exchange 1

Understand the many definitions of an Electronic Health Record and unfortunately

Health IT Workforce Curriculum Networking and Health Information Exchange 2

Health IT Workforce Curriculum Networking and Health Information Exchange 3

In the commercial market, these expanding functionalities will be used to promote a

Health IT Workforce Curriculum Networking and Health Information Exchange 4

The primary sections include: Personal Health with subsections

The Supportive section includes:

The Information Infrastructure includes:

Health IT Workforce Curriculum Networking and Health Information Exchange 5

Provider management: Caregivers associated with individuals care,

Health IT Workforce Curriculum Networking and Health Information Exchange 6

Health IT Workforce Curriculum Networking and Health Information Exchange 7

Other factors included:

Health IT Workforce Curriculum Networking and Health Information Exchange 8

These groups were:

In February, 2012, CCHIT certified more than 70% of attested EHRs.

Ambulatory which includes

Note the correspondence with HL7 functional model profiles.

Health IT Workforce Curriculum Networking and Health Information Exchange 9

Key to meaningful use is interoperability. Key to interoperability are standards. So

ONC has established a certified health IT product list at website http://onc-

Health IT Workforce Curriculum Networking and Health Information Exchange 10

Health IT Workforce Curriculum Networking and Health Information Exchange 11

We looked at specific profiles and at certification in the U.S.

Health IT Workforce Curriculum Networking and Health Information Exchange 12

Vous aimerez peut-être aussi