Networking and Health Information Exchange: Supporting Standards for EHR

Application

Audio Transcript

Slide 1
Welcome Networking and Health Information Exchange, Supporting Standards for
EHR Application. This is Lecture d.

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

required to accomplish networking across and among disparate organizations who have
heterogeneous systems.

Unit 7 covers Supporting Standards for EHR Application and consists of four lectures.
Over these four lectures, we will talk about the additional standards that are available to
support interoperability across different applications that relate to or are interactive with
the Electronic Health Record.

Lecture d wraps up the discussion on application standards. Specifically covered are

standards for management of workflow with multiple systems and some regulatory
standards.

Slide 2
The Objectives for this unit, Supporting Standards for EHR Application, are to:

Understand the clinical decision support standard Arden Syntax,

Understand standards for clinical guidelines,
Understand object-oriented expression language for clinical decision support,
Understand the clinical decision support standard Infobutton,
Understand disease management, and
Understand other clinical decision support applications.

Health IT Workforce Curriculum Networking and Health Information Exchange 1

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 3
Additional objectives for this unit, Supporting Standards for EHR Application, are to:

Understand other standards that help to support networking and reporting

requirements as well as functionality to optimize the connectivity among
heterogeneous systems deployed within a single enterprise,
Understand single sign-on standards and the HL7 Clinical Context Object
Workgroup (CCOW) standard,
Understand regulatory standards, and
Understand issues relating to person identifiers, master patient indexes, and
record locator services.

Slide 4
These regulatory and regulated standards are important mainly for reporting purposes.
They have been developed within HL7 as a work product of the Regulated Clinical
Research Information Management Working Group. Members of this group include
CDC, FDA, EMEA (European Medicines Agency), the International Conference on
Harmonization of Technical Requirements for Registration of Pharmaceuticals for
Human Use (ICH), as well as the usual set of stakeholders in HL7. In the domain of
Public Health, The Individual Case Safety Report (ICSR) is important as this is the
electronic form that is used to report adverse medication events. It is a joint effort
between HL7 and ICH with the above mentioned groups participating. This standard is
significant in that its use is intended for the global community. It is used for reporting to
both the FDA and to EMEA. The Generic Incident Notification is a generic standard for
reporting any adverse event.

In the domain of Regulated Products, Structured Product Labeling (SPL), Regulated

Product Submission (RPS), and Common Product Model (CPM) are each discussed in
following slides.

The 3 regulated studies standards are the annotated ECG (aECG), Clinical Trial
Laboratory, and Stability Study for drug research.

Slide 5
The business driver for the Structured Product Labeling (SPL) standard is the US HHS
Directive. This Directive is to develop a standard for communicating the content of drug
product labelling in both a human and machine-readable format to serve as the basis of
a national repository and to create a national repository of all current approved labelling
on the National Library of Medicine DailyMed website.

Health IT Workforce Curriculum Networking and Health Information Exchange 2

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
DailyMed serves as the official source of approved labelling for prescribing physicians,
patients and healthcare providers and is based on HL7 Clinical Document Architecture
(CDA) and is computer readable.

SPL v3 complies with the new FDA Physician Labelling Rule, and includes an encoded
highlights section, among other features. SPL v3 is mandatory in the US for all new
indications and efficacy supplements (with multi-year phase-in for remaining types of
labelling applications). SPL is important because of the structured approach to drug
labeling noting potential adverse effects.

Slide 6
The Regulated Product Submission (RPS) standard is for conveying product information
to regulatory authorities.

It is used globally and was developed by HL7 and ISO with input from ICH. RPS can
carry an ICH CTD (Common Technical Document) submission and other submission
types for drugs, device, veterinary products, food additives and other regulated
products. RPS storyboards include initial submissions, updates, amendments,
withdrawals, references to other submissions, etc.

Testing team members represent pharmaceutical industry, medical device industry,

other vendors and associated divisions from the FDA.

Slide 7
Rather than creating a standard for any and everything that could be given to a patient
or used on a patient, HL7 has created a generic standard for dealing with a variety of
products called the Common Product Model (CPM). The CPM Domain information
model relates to modeling of any kind or instance of a product. This standard depends
on a rich set of storyboards to make sure the standard has adequate coverage and
functionality. The storyboards relate to the different perspectives on what a product is
and how it is used. For example, a crutch or walking cane might be a common product
that requires certain parts that need to be modeled. What do you think such a model
might include?

Examples of a CPM include

Medication, including vaccines,
Devices used in medical services, and
Anything else to which a person can be exposed.

Health IT Workforce Curriculum Networking and Health Information Exchange 3

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 8
Visual Integration Messages are an interoperability specification for visual integration of
applications that allow users to experience an integrated computer-user session on the
desktop. Clinical Context Object Workgroup (CCOW) is an interoperability specification
for visual integration of applications that allows users to experience an integrated
computer-user session on the desktop. It enables disparate applications to synchronize
in real-time at the user interface level. CCOW provides two discrete functions:
Facilitates a process called context management that links subjects to
applications, and
Provides single sign on that enables secure access of disparate applications
by a user.

Messages are specified that flow between presentation-level applications that

synchronize the user identifier, patient identifier, and/or observation identifier across
multiple applications for a "single sign-on, single-patient-look-up user experience.

Context management uses subjects of interest, such as user, patient, clinical encounter,
image, lab report, charge item, etc. to virtually link applications so that an end-user sees
them operate in a unified, cohesive way. Context management is valuable for both client
server and web based applications.

Single sign on works closely with content management to enable the user to identify a
subject, i.e. a patient, and have access to all applications containing information about
the selected subject to which the user has access. This method eliminates the user
from having to log on to multiple systems, enter patient ID and request certain
information. The end result is an aggregated view of all patient information across
disparate applications.

CCOW products:
Define standards that enable the visual integration of healthcare applications.
Entail the coordination and synchronization of applications so that they are
mutually aware of the set of common things; e.g., patient ID, patient name,
encounter date, etc., and
Define a protocol for securely linking applications so that they link to a
common concept.

Slide 9
The application tells the CCOW-compliant context manager that it wants to set the
patient context and provides the context manager with an identifier that indicates the
context subject (for example, the medical record number for the patient of interest). The
context manager then notifies the other applications that the context has been changed,
and each application obtains the patients identifier from the context manager. Each

Health IT Workforce Curriculum Networking and Health Information Exchange 4

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
application then adjusts its internal state and data display accordingly. This all happens
in real-time.

The current version of CCOW is v1.6.

Slide 10
The value of CCOW connects and interfaces multiple disparate applications, such as,
labs, meds, cardiology, scheduling, billing, etc.

CCOW provides easy access to data and tools for a family of users, including
physicians, nurses, therapists, administrators, etc.

CCOW enables connectivity from kiosks as well as personal workstations located in

hospitals, clinics, offices, homes, etc.

In too many instances, the user has to log on separately to the individual systems and
interact independently with each system. CCOW makes these disparate systems
appear to be a single system.

It is likely that this standard will be required for many years to come.

Slide 11
Here is an actual example that shows several applications that are linked through the
use of CCOW.

In this case, the x-ray image, demographic data, a flow sheet and other applications are
linked and available to the user.

Slide 12
These are some key standards that are an important part of obtaining global
interoperability. We have previously discussed decision support services and
terminology service.

Health IT Workforce Curriculum Networking and Health Information Exchange 5

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Standards are being developed for:
Entity Identification (to manage and maintain identities within and across
domains, localities, or products),
Record Location & Retrieval (to discover, retrieve, and update records in
distributed environments),
Decision Support Services (to support evaluation processes such as clinical
decision support), and
Terminology Service (to retrieve, maintain, and navigate clinical terminologies
and ontologies).

Entity identification is a necessity if we are to share data and resources.

Both HL7 and IHE are creating standards and supporting material for these areas.

Slide 13
Ambiguity in identifying the patient locally and regionally is particularly important.

These specifications would be necessary parts of enterprise and product applications

such as:

Inter-Enterprise (such as NHIN, RHIOs)

By functionally specifying behavior, roles between applications and products are
clarified, and the technologies supporting them can be profiled and sharpened.
Intra-Enterprise
Standardization on functionality allows for better integration of off-the-shelf and
custom development environments, and promotes more of a plug and play
environment.
Intra-Product
Facilitates vendors ability to integrate third-party value-add components and
speed up the design phase with higher confidence.
Custom-Implementation
Affords organizations wishing to custom-develop the opportunity to later integrate
off-the-shelf.

For example, a typical patient over 65 is apt to have drugs prescribed by 3-5 providers.
In order to create an accurate medication history, we must have the ability and the trust
to combine the records from multiple sites. There are many other examples. The same
arguments could be used for any healthcare object. For example, drugs need identifiers
that should track from manufacture to use. GS1 creates identifiers that would permit us
to do supply chain tracking.

Health IT Workforce Curriculum Networking and Health Information Exchange 6

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 14
Today probabilistic algorithms based on patient demographics are the most frequently
used approach to establishing patient identity.

Functional linkages to certain items are critical to support the concept of a patient-
centric, aggregated patient record.

Providers often have many addresses their practice, a clinic, a hospital, and an
extended care facility. A single identifier would ensure greater odds on tracking and
communicating with providers. The US has implemented a National Provider Identifier
system for provider identification.

For employers and facilities, the IRS identifier number works as a unique identifier.

For health care plans, a health plan identifier would be useful to uniquely build the plan
into CPOE systems to determine authorization issues.

The problem with personal identifiers remains a problem. Currently, a set of parameters
is used to generate an identifier. The next slide identifies these parameters.

The master patient index, along with a record locator service is critical in a regional or
HIE organization. This index must serve local, regional and rational needs. If patient
data is to be aggregated, we must know who the patient is and where the patient-centric
record is located. IHE provides an implementation guide that addresses these topics.

Slide 15
The below 10 parameters are most generally used to identify the patient in the absence
of a unique identifier. Many people add the SSN to this set, and, in fact, the SSN is one
of the best identifiers.

Medical Record Number,

Patient Surname,
Patient Given Name,
Gender,
Telephone Number,
Zip Code,
City,
Date of Birth year, month, day,
Next of Kin Surname, Given Name, and
Physician Surname, Given Name.

These parameters are weighted as to the uniqueness they provide to the persons
identity. Other algorithms exist that use a probabilistic model. All have a finite error rate.

Health IT Workforce Curriculum Networking and Health Information Exchange 7

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 16
Master Patient Index systems are necessary to locate a patient, particularly if the patient
has multiple numbers across many systems. A clinic may assign one number, the
hospital another number, an employer another number, and the insurance plan another
number. The MPI links all of these numbers together.

The MPI contains required data to identify and distinguish the patient across healthcare
facilities and levels; includes some patient demographic data; may include multiple
identifiers the patient is assigned across various facilities; and has a primary identifier.

The MPI may also provide a linkage to other family members.

Issues of privacy and security are factors in designing and accessing MPIs.

Slide 17
A number of other standards contribute to networking services. Examples include:

Genomic and proteomic data as part of an EHR;

Rule-based data exchange to identify what data should be included in a business
transaction whether reimbursement, clinical or research;
Filters for data presentation for presentations of data related to events and
circumstances. For example, what is reported to the attending physician on
admission is different from what is presented on discharge;
Consent management standards for getting and recording patient consent for both
patient care as well as research;
Identifying candidates for clinical trials standards to scan a patient record to identify
patients based on requirements defined in the standard, plus follow-up for patient
consent;
Record linkages links various records and repositories;
Notification services - standardized approach to notification on various media
including mobile devices;
Natural language processes approaches to natural language processing for free
text entries; and
Mapping services in transition (real word inclusion).

Health IT Workforce Curriculum Networking and Health Information Exchange 8

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 18
The Clinical Genomics WG produces standards to enable the standard use of patient-
related genetic data such as DNA sequence variations and gene expression levels for
healthcare purposes (personalized medicine) as well as for clinical trials and research.
This WG also defines what data needs to be exchanged and creates standards for
doing so. The Clinical Genomics Standard Family Tree specifically addresses:

Family history (pedigree) topic,

Genetic variations topic,
Gene expressions topic,
CMETS defined by the domain, and
Messages for the exchange of family history and genetic information.

Slide 19
This slide illustrates products of the Clinical Genomic Work Group. Note the R-MIMs
and D-MIMs behind this model (previously discussed). Data content is referenced to
the HL7 RIM and supports different data interchange mechanisms (v2 messaging, v3
messaging) and uses CDISC SDTM data model. Its applications include support for
genetic testing, family history and pharmacogenomics implementation.

Slide 20
This lecture identified a few of the additional standards required to support networking
and the exchange of data. CCOW is an important and powerful standard that has great
value in todays world of disparate systems. The other standards represent more
domain specific activities. We discussed regulatory standards, standards for identifying
and managing patient identity and record locators. Many standards have yet to be
developed to support the full requirements for networking and data sharing.

Slide 21
This concludes Supporting Standards for EHR Application.

This unit provided a continuation of the discussion of standards, specifically addressing

a number of supporting standards to application in contrast to standards for data
interchange. Areas discussed included clinical decision support, including clinical
guidelines, expression languages, the InfoButton, disease management, and risk
assessment for various diseases. Other topics included CCOW for linking
heterogeneous systems within a single enterprise, regulatory standards, record locator
and person identifying standards.

Standards will continue to be developed as the use of HIT continues to expand into new
areas and new functionalities.

Health IT Workforce Curriculum Networking and Health Information Exchange 9

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.
Slide 22
No audio.

End.

Health IT Workforce Curriculum Networking and Health Information Exchange 10

Version 3.0/Spring 2012 Supporting Standards for EHR Application
Lecture d
This material Comp9_Unit7d 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.