Download File - Subrata BeheraProfessional Portfolio

Running head: FINAL
1
Topic 1
Group 3 Final Paper
Rhona Banayat, Subrata Behera, Brigid Donohue, Ash Goel, Todd Jaschke,
Unuakpovota Okagbare, and Dan Staszcuk
Northwestern University
November 27, 2012
FINAL DRAFT
2
Introduction
The San Francisco Bay Area is home to some of the country’s best hospitals and healthcare professionals. The
region is also home to the world-renowned Good Hope Cancer Research Center, a University Medical Center that
includes the area’s number one ranked level 1 trauma center, a University Hospital, the Memorial Healthcare
System, a County Hospital, and a large number of individual physician practices that each provides a variety of
specialties and services. Despite the high rankings of a number of these organizations, each of these entities
struggles to provide their respective clinicians with comprehensive health information about their patients at the
point of care. Because of this, fragmented care exists between varying levels of care and transitions of care, patients
are routinely subjected to undergoing duplicate testing, health information is not always up-to-date, clinicians must
routinely wait on test results, which often delays treatment, and overall, healthcare costs have been in lockstep with
those around the country where they continue to increase at a rapid pace.
To combat these issues, the federal government passed the Health Information Technology for Economic and
Clinical Health Act (HITECH Act), which was part of the American Recovery and Reinvestment Act (ARRA) of
2009. The central tenet of this law is the idea that when healthcare organizations start capturing patient data in a
structured way and when they start to exchange the data between organizations and between separate vendors of
electronic health record (EHR) systems, care providers will be able to improve patient outcomes as a result of
greater care coordination and more complete information at the point of care. In response to the HITECH Act, the
healthcare organizations and physician practices in the Bay Area have begun working and will continue working
over the next several years in the adoption of EHR systems and a regional health information exchange (HIE), which
will be known as the Bay Area HIE (See Figure 1). Longer-term, the Bay Area HIE will join in the California statewide HIE (previously called Cal e-Connect) as well as the nationwide HIE with the eHealth Exchange, which was
the former Nationwide Health Information Network (NwHIN) before it was transitioned to a not-for-profit
organization where it is today (“NwHIN Exchange,” 2012). Each of the member organizations and practices that
make up the Bay Area HIE would constitute the building blocks of a much larger “network of networks” within the
eHealth Exchange (“Deloitte Center for Health Solutions,” 2006). This process will take an enormous effort from a
large number of stakeholders around the region. It will also require healthcare professionals to start capturing data
for those that do not do so already and do so with terminology, security, and messaging standards in mind, in order
to ensure and retain syntactic as well as semantic interoperability.
Benefits
HIE networks act as the focus point for an organized and standard process for exchange of relevant health care data
across several entities, regions, states and eventually on a nation-wide scale. The benefits of such activity are
sometimes very stark and evident as was demonstrated by the Department of Veterans Affairs in the month after
Hurricane Katrina (AHIMA, 2007) when more than 2,300 users exchanged health data electronically across 48
states including demographics, diagnoses, health summaries, and lab results.
The expected benefits from such systems include (Department of Health and Human Services, 2012):
1.
2.
Improvement of patient care and reduction in medical errors by giving healthcare providers access to
information that allows them to detect interactions between various interventions (such as medications,
prior procedures and test). The knowledge of pre-existing conditions is crucial to making a timely
decision on the next steps in diagnosis and treatment of a condition. It also provides timely data to the
professionals who otherwise would have to either reorder the test or wait for results to be available
during business hours from other providers and thus lose crucial time in the diagnosis and decision
making process.
Cost savings are achieved by efficiencies created through exchange of health information limiting
redundant or unnecessary testing and procedures. These avoidable costs that cost the health system
FINAL DRAFT
millions of dollars a year, monies that could be put to better use on medical and systems technologies,
may not be reimbursed by Medicare or private insurance in the future.
3. This also enhances continuity of care by increasing communication between primary care physicians
and other health care providers, patients and families. This saves on time that each provider has to
spend in trying to recreate data from other sources, which is potentially fraught with chances for more
errors. A prime example of this is medication reconciliation.
4. The ability to provide ePrescriptions saves time, enhances prescription safety, helps monitor drug
abuse and drug interactions.
5. Payor and member satisfaction will increase as the ability to provide information on costs and
insurance coverage will help capture revenue and increase efficiency by decreasing the time to having
such information available for practices, insurers, providers and patients. Operational cost will be
reduced for everyone in the process.
6. It will help create better security with an audit trail that tracks data access and allows for enforcing
regulations governing such access.
7. It will also facilitate the efforts of patient centered medical care delivery models such as “accountable
care organizations” and “pay for performance” initiatives.
8. At a public health level, data exchange enhances monitoring of chronic disease outcomes and helps
focus resources on better disease management by helping establish programs designed to meet the
needs of the community.
9. It allows for early infectious disease identification and provides a proactive approach to early
identification of disease outbreaks and limiting the spread of diseases such as Tuberculosis, HIV,
Pneumonia, Influenza etc.
10. It also improves the ability of health systems in public health reporting, which is a required part of
Stage 2 Meaningful Use rules. This includes reporting immunization information, reportable lab
results, syndromic surveillance, and cancer.
11. It will also enhance the loop from healthcare research to actual practice by collecting large cohorts of
data that can be evaluated in the actual environment of healthcare practice.
It is evident that HIE’s are well positioned to act as the data routing service, which if utilized appropriately and
adequately by various stakeholders connected to the system, can provide tremendous value to all.
3
FINAL DRAFT
4
Figure 1: Greater Bay Area Health Information Exchange
Stakeholders & Governance
The HIE success requires the identification and collaboration of various users and providers of clinical information
(“E-Health Initiative,” 2012). Without involvement from these individuals or organizations in the initiation,
implementation and management of the information network, the success of the HIE as well as the benefits would be
limited. These include the following entities - Healthcare Systems, Primary Care Physicians, Specialty Providers,
Payers, State Agencies, Reference Laboratories/Diagnostic Centers, Consumers, Employers/Large Organizations,
Federal Healthcare Agencies, and the HIE Administrators. Each of these stakeholders play a key role in the success
of an HIE as they are the data providers, the data users, and the data funders. Success will depend on the repository
of data that is made available for exchange and long-term sustainability of the network will depend on the level of
its adoption (“Center for Health System Change,” 2008).
There are several technical models (e-Health Initiatives, 2011) that have been proposed/adopted under the state
Cooperative Agreement Program for the planning, implementation and day-to-day management of an HIE. These
models provide significant flexibility for states to choose a direction and enable each state designated entity to match
it to the local environment with a focus on the five domains – governance, sustainability, technical infrastructure,
business operations and legal/regulatory issues. There are four common approaches that have been adopted:
FINAL DRAFT
1.
5
Centralized Model – This is managed by a state designated entity (SDE) that acts as the Health Information
Organization (HIO) for the entire state. Some states allow this to branch out into multiple Regional HIO’s
and also allow individual health systems/providers to connect to the HIO directly. This can be managed by
a:
a. Public Entity
b. or a Public Private partnership.
The various pros and cons of this are discussed in greater detail in the section.
2.
3.
Decentralized Model – Here the SDE has a role in facilitating the existing HIO’s and healthcare providers
to come together as a group and manages common regulations and policies. No core services are provided
by the SDE outside of this.
A Hybrid model combines the Centralized and Decentralized models in a way that allows the various
HIO’s to connect to a central set of core services including Master Patient Index, Provider Registry,
Identification Services, NwHIN gateway and Query services. The clinical data resides with each individual
entity and not in a central location.
Our HIE will follow the Centralized Model closely in that it will have the ability to provide a much more
comprehensive list of Core Services including the exchange of clinical data, and allow for the future growth to
ePrescribing, Computerized Provider Order entry, Provider Portal, Lab Results delivery and Medication history etc.
It will be based on a Public Private partnership with a board that is representative of each member/stakeholder
including private entities such as the Memorial Hospital System and the Reference Labs and Physician
Representatives (derived from medical society serving the region). This Board will be responsible for setting
policies and staffing the day-to-day operations of the HIE. The sustainability of this organization will be derived
from several sources including Federal and State grants. However, given the limited potential/duration as well as a
relatively delayed ROI, it will be set up to include a partnership from all the participants in the program (Kolkman,
2012) including the health systems, insurers, and laboratories.
It will be very important to consider the roles that each of these entities play towards the sustainability of the
network. Hospital Systems are one of the key data providers and users of the system. These organizations have high
volume needs to exchange data bi-directionally within various facilities (if they are located on multiple campuses)
and also with various providers and payers as well as state health departments and other public health agencies. As
we move into the next stages of implementing the meaningful use strategy for health IT systems, the emphasis will
shift towards data transfer and participation in public health initiatives. Reference Laboratories and Diagnostic
Centers also provide vital data to the patient record including images that are crucial for the providers of care to
make clinical care decisions and buy in from these establishments is important to help drive benefits out of the HIE
network. Primary Care Providers and Specialty physicians are the key users of data and each benefit from seamless
integration with all the other information providers. The direct benefits of such information exchange are passed on
to the patients in terms of better quality of care provided when the clinicians have the details around an episode of
care including medication lists, problem lists, test results and summary of care available at the point of care. In an
ambulatory setting, the ability to connect to payers and other state agencies decreases administrative burden by
automating the business side of data exchange. The ability to verify eligibilities, prior authorizations, and receipt of
amounts due lead to better business planning abilities for some of the smaller practices that make them much more
efficient and sustainable. The payers themselves benefit from such activities because electronic claims processing
allows for faster and efficient business management and reporting. They can also drive subscriber wellness
programs based on real time data. Public Health Agencies receive timely and accurate data from syndromic
surveillance and disease registries, which will help manage population health more effectively. The other vital
stakeholder in this is the patients and consumer organizations that need to have a clear understanding and
involvement in decision making and governance of the networks. Concerns over security and rules of data exchange,
which allow individuals to control the flow of data to other agencies on the network are of crucial importance. State
FINAL DRAFT
6
agencies are an important safety net for certain patient populations that can benefit from this information network. In
several states, Medicaid is being mandated to be the key sponsor for HIE networks. The State Government (through
the Governor’s office) is tasked to identify and initiate the statewide HIE through a designated entity that will act as
the coordinator for the HIE. Various funding/organizational models have been investigated and each state is
choosing its own strategy after discussions with all the stakeholders. These models fall into the four general
categories (Deloitte Center for Health Solutions, 2006):
1.
2.
3.
4.
Not-for-Profit – These are primary focused on community health driven practices and are tax exempt. This
model usually needs special tax credits/incentives to manage funding challenges.
Public Utility – These HIEs are managed by state entities and the funding source is the various state/federal
sources.
Physician and Payer Collaborative – This type of HIE collaborative is driven by the collaboration between
payers and physicians brought together by perceived benefits including increased efficiency in
administrative tasks as well as better management of patient populations.
For-Profit – For-profit HIEs are created to look at this as a sustainable business driven by the financial
benefits for a fee for service model.
Model
Governance
Financial
Value of Services
Architectural
Not for Profit
Led by a governing body
or members with the
right to vote
Financing received
through Fed/State
grants/stakeholder
contributions
Focus has been on
improved, quality, safety,
and efficiency of patient
care and lower health
care spend per capita
Single, interoperable
system at point of care
with a slow expansion
over a larger geographical
area
Public Utility
Led as a public utility
Subscriptions vs.
Transaction Fee financial
model
Provides governance for
public accountability for
private businesses
Simple infrastructure
connecting local health
institutions
Led by physicians and
Payors collaboratively
Common & collaborative
funding from both
entities
Caters to 'creating value'
for all - hospitals,
physicians, payors, public
health entities all bring
respective goals together
Clinical messaging service
that provides a single
source for all
participating hospitals
Private investment
Strives for ROI-driven
investments to achieve
an overall goal of better
quality of care and
efficient workflow
processes
Expected to use best-inclass technology to
achieve quicker and
sustainable results
Physician Payer
Collaborative
For Profit
Led by board of directors
(shareholders)
(“Deloitte Center for Health Solutions,” 2006)
The return on investment for all the stakeholders is somewhat difficult to visualize in the near term. This makes the
challenge of a sustainable information exchange network somewhat difficult. For the most part, the participants need
to focus (and indeed have been doing so) on the qualitative and other intangible benefits including:
1.
2.
Providers – improved ability to provide quality care, better customer service (patient loyalty) and improved
reimbursements.
Payers and Government agencies – increased efficiencies by reducing administrative burden, improvement
of quality of care and improved data intelligence.
FINAL DRAFT
7
It is clear that as states and regions work towards developing their strategic and operational plans for data exchange
networks, they must evaluate each model and choose the best organizing model on the continuum to meet the needs
of providers and organizations in their area in collaboration with all the stakeholders.
Standards
United Hospital, University Medical Center, Good Hope Cancer Research Center, Memorial Healthcare System, the
County Hospital, and the other individual physician practices across the Bay Area will require terminology,
document, and messaging standards in order to effectively capture and disseminate data across the HIE. The
following standards will be used for data exchange. Some of these standards like ICD-10 and HL7 v3 will be used in
the future for implementation of new features and government requirements.
Messaging Standards:
HL7 V2
The HL7 v2 is a messaging standard, which is the most used standard for the electronic data exchange in a clinical
domain and it would be safe to assume that it is the most widely implemented standard for healthcare. The standard
allows for exchange of data within disparate clinical applications. It is commonly used because of its compatibility
with most systems and organizations. V2.x was originally created to support hospital workflows and is still the most
widely used in the U.S. The HL7 v2 supports the notion of central patient care system and a distributed environment
where the clinical data resides in the individual departmental systems (HL7 2012). More than 95 % of US healthcare
organizations use HL7 v2. The standard is also commonly used across 35 countries with varied levels of
implementation and acceptability (HL7 2012).
HL7 v2 also provides benefits that were not seen earlier before it was conceived. The various benefits of using HL7
are (Shaver 2006, HL7 2012):
1.
2.
3.
4.
5.
6.
7.
Reflects the complex “everyone is special” world of healthcare.
Provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interfaceby-interface basis
It was built in an ad hoc way, which allows the critical pieces to be defined first.
It generally provides compatibility between the various 2.X versions that are used across organizations.
It supports the majority of the common interfaces used in the healthcare industry globally
Provides a framework for negotiations of what is not in the standard
Reduces implementation costs
Considering its universal appeal it will be the perfect fit for the HIE systems being developed for the Bay Area of
California. Most of the participating stakeholders use the HL7 v2 extensively to share data within their
organizations. The participating organizations have an infrastructure in place to support the data exchange for the
HIE, so it will be beneficial to make use of this standard.
HL7 V2 also has its own share of issues, which needs to be kept in mind. HL7 v2 was developed as an open
standard and is open to interpretations by each participating vendors/stakeholders. As the standard is open for
interpretation, it increases the cost to maintain interfaces between two systems sharing data and it might
interpret/represent the data differently. HL7 v2 was also designed for inter-organization data exchange. With the
scope of data exchange increasing day by day and with federal mandates of performing data exchange with an HIE,
it becomes more obvious the lack of security/encryption elements that are missing from the standard. So while it
would be beneficial to get started with using HL7 v2, The HIE and the participating stakeholders need to also start
FINAL DRAFT
8
thinking towards migrating to HL7 v3, which provides a more robust framework for data transfer and exchange
("HealthITComment,” 2007).
HL7 V3
The HL7 Version 3 is an information sharing standard, which is modeled on the HL7’s Reference Information
Model (RIM). It contains various standards for communication, which documents and manages the care and
treatment of patient across a broad spectrum of healthcare settings. HL7 V3 includes foundational elements that are
needed for meeting the global challenge of integrating healthcare information in areas of patient care and public
health. V3 represents a better approach for clinical information exchange, which is based on a model driven
methodology. It also produces messages and electronic documents that are expressed in XML syntax. The V3
specification is built around subject domains that provide storyboard descriptions, trigger events, interaction designs,
domain object models derived from the RIM, hierarchical message descriptors (HMDs) and a prose description of
each element ("HL7,” 2012).
There are various benefits of using HL7 version in healthcare. It primarily focuses on the semantic interoperability
as it presents the information in its entirety. It focuses on providing the data in terms of the complete clinical context
so that the sending and receiving systems share the information being exchanged. It has been designed for universal
application so that these can bring in the biggest global impact. It provides consistent representation of the data
laterally across the various HL7 domains of interest and longitudinally over time as new requirements come up and
new issues related to clinical context are addressed. It has application roles well defined. It provides much less
options in terms of the standard, which would result in better interoperable solutions. Interfaces created with the
standard will also be less costly to maintain ("CorepointHealth,” 2010 & "HL7,” 2012).
HIE and health information integration is one of the top priorities for major healthcare systems across institutions
and hospitals. Organizations and healthcare systems are implementing HIE to reap the benefits of the meaningful
information retrieval among the disparate healthcare systems. For HIE’s to work and help in meaningful data
retrieval the need is to have a common standard (Viangteeravat, Anyanwu et al., 2011). HL7 v3 comes up as a
standard designed for such a task. The standard provides less optionality, which is the cause of major issues with
HL7 V2.X. With a more closely tied standard, it will be easier to provide interoperable solutions. HL7 v3 will help
in providing the framework for better semantic interoperability and will help in the integration of various other
standards used in providing the continuity of care (Nagy, Hanzlícek et al., 2010).
Organizations planning to use HL7 v3 should also factor in the issue of backward compatibility with HL7 v2.X.
Backward compatibility is not an option for v3 to v2.X due to the desire to limit change and the interpretation
requirement that was associated with HL7 v2.X. Without backward compatibility, healthcare systems will have to
factor in the implementation of HL7 v3 supported products across the system in order to reap the benefits.
DICOM
For medical imaging, the HIE will leverage the Digital Imaging and Communications in Medicine (DICOM)
standard, which “defines the formats for medical images that can be exchanged with the data and quality necessary
for clinical use” (“Strategic Document,” 2012). This standard can trace its origins to a cooperative effort between the
National Electrical Manufacturers Association (NEMA) and the American College of Radiology (ACR). The goal of
this collaboration was to develop a standard means of communicating and transmitting digital information. Thus, the
DICOM standard was designed to produce, display, retrieve (via archival system) and query medical images. In
1988, this collaboration produced a second version that standardized terminology and information structure. The
second version was later enhanced to produce a third version, which allows for support in a networked environment
using TCP/IP protocol. Version 3 also supports an offline environment using physical media such as CD-R.
FINAL DRAFT
9
DICOM will be an important standard for use in the HIE because it will benefit physicians by providing them with
access to images and reports, which will enable them to diagnose patients in a faster and more effective manner.
This added benefit will apply to specialties like radiology, cardiology, breast imaging, oncology, surgery, and
neurology. In theory, patients will also benefit because they will be able to obtain quicker and more effective care
when their images are able to flow through the various information systems without requiring manual delivery.
Patients would also benefit by not being exposed to radiation on multiple occurrences. Lastly, healthcare payers
would have a stake in this standard and benefit as well because any efficiencies would result in lower claims due to
fewer instances of repeat exams and imaging. Since most of the facilities and physician practices in the HIE utilize
this standard, each will be able to share these medical images for greater overall interoperability.
Terminology Standards:
LOINC
The Logical Observation Identifiers Names and Codes (LOINC) standard is a universal standard for classifying
clinical information that is contained within electronic forms. This is a widely adopted standard within hospitals,
clinics, laboratories, and healthcare information systems that provides a way to classify laboratory results in a
manner that can be communicated across all systems in a universal coding language (Vreeman, 2010). LOINC
allows systems the ability to share information between different departments and even facilities. Prior to LOINC,
each system had their results coded in a different method, which contributed to fragmented care. The LOINC
standard has created a way to universally classify roughly 58,000 observation terms, the majority of which are
designated for laboratory testing (Rouse, 2010). This standard will be implemented and used within the HIE as a
way to provide information across multiple platforms and systems between facilities. This will enable lab results to
be transferred from one hospital to another in a standard language without requiring additional translation. It will
also provide information from one system to another without any delay in interpretation allowing for the care of the
patient to be the top priority.
SNOMED
SNOMED – CT is a comprehensive clinical terminology dataset that has been evolving over the last several years
and is used in healthcare information systems to make them usable and accessible. It was a product of the
combination of the SNOMED –RT (Reference Terminology) and UK National Health Services Clinical Terms –
Read Codes. It is a concept oriented machine readable terminology that meets the U.S. standards for electronic
health information exchange as defined by the Healthcare Information Technology Standards Panel. It contains more
than 364,400 concepts with unique meanings and formal logic-based definitions; more than 984,000 English
language descriptions or synonyms; and approximately 1.47 million semantic relationships.
American Health Information Management Association (AHIMA) has published its position in support of using this
standard in order to facilitate the exchange of health information between various EHRs (AHIMA, 2012). SNOMED
CT is a codified data set that helps capture discrete data in an EHR that provides consistency for storing, sharing and
analyzing data across various facilities or areas and hence is essential for creating a network that allows exchange of
information. Other benefits of using this terminology standard include the ability to provide real time clinical
decision support, prevent duplicative data entry across multiple systems and ability to benchmark and develop
quality improvement processes. It also allows for mapping across other terminology standards (e.g. ICD 9 and ICD
10).
In the HIE network, it will be important to transfer clinical data across various software applications, which are
relevant to disease management and capturing clinical findings and outcomes. This is also one way to index and
order clinical data in a hierarchical concept based relation that can help drive the clinical decision support that can
FINAL DRAFT
10
be consistently distributed across the continuum (IHTSDO, 2012). It is the clinical terminology of choice for most
(if not all) EHR systems and is a vendor neutral source.
ICD-9 & ICD-10
The International Classification of Diseases, known as ‘ICD’, is a code set developed by the World Health
Organization (WHO) that is used for diagnoses, symptoms, procedures/treatments, medications, identifying causes
of death, handling epidemics, developing automated treatment decision-making systems, and for filing insurance
claims. ICD-9-CM is a U.S. healthcare based clinical modification of the ICD-9 coding system, which provides a
diagnosis classification system. This system, which originated in 1979, is in the process of being replaced by ICD10, which is being mandated by the Centers for Medicare and Medicaid Services (CMS).The ICD-10 system will
include a diagnosis code set known as ICD-10-CM and a procedure code set known as ICD-10-PCS. In order to
support a fully integrated and interoperable HIE across the Bay area, both ICD-9 and ICD-10 code sets will need to
be included as part of the standard terminologies used in this system. Members of the HIE will need to code in each
for several months after the October 1, 2014, transition date because hospital discharges and outpatient bills with a
service date on or after the transition must be billed using ICD-10. Documentation and billing for inpatient hospital
stays or outpatient treatments performed with service dates prior to the transition must use ICD-9.
One of the main driving factors for the push to ICD-10 is the healthcare industry currently struggles to measure
quality of care using ICD-9-CM. With ICD-9-CM, it is difficult to evaluate medical outcomes, changes and
advancements in care, and accurately reflect current technology and medical devices as there are not precise codes
to capture such changes and advancements. With ICD-10, the clinical modifications code set has increased from
approximately 13,000 codes to over 68,000 codes while the procedure code set has increased from approximately
3,000 codes to over 87,000 codes. These increases in each code set, which also allow room to grow, provide for
greater coding accuracy and specificity. These enhancements in ICD-10-CM and ICD-10-PCS will guide members
of the HIE to better understanding of patient complications during care, design clinically robust decision support
tools, more accurately track the outcomes of care, better manage disease populations, and reduce coding errors.
The information systems used across the HIE will ultimately benefit from this standard based on the reasons just
listed, however, there will be challenges that each HIE member will have to endure during the transition period. For
example, coder productivity is expected to decrease during this transition. This is because there is typically not a
one-to-one match of ICD-9 to ICD-10 codes. Instead, there might be a one-to-none, one-to-many, or many-to-one
match depending on the code being mapped. In many cases, the number of options for a search will increase
exponentially with ICD-10. It is also expected that the HIE members will experience a need for claims adjustment
work and other workload increases associated to the transition before healthcare professionals become proficient in
ICD-10. Despite these challenges, an independent RAND study concluded,
“the benefits of ICD-10-CM/PCS are likely to exceed initial implementation costs within just
a few years. Furthermore, the cost of doing nothing may be greater than the actual
implementation. Any delay in adoption of ICD-10-CM/PCS will cause an increase in future
implementation costs as the management of health information becomes increasingly
electronic and the costs of implementing new coding systems increase due to required systems
and application upgrade.” – AHIMA (n.d.).
Document Standards:
CCD
The Continuity of Care Document (CCD) is a standard for clinical data exchange. It originated from two previously
competing and incompatible standards, the Health Level 7 (HL7) Group’s Clinical Document Architecture (CDA)
FINAL DRAFT
11
and the ASTM International Group’s Continuity of Care Record (CCR). Although these two standards were very
similar to each other, they were not compatible. Therefore to encourage additional clinical data exchange between
the users of the two standards, the CCD was developed. The result was a combined format that uses the CCR
content data model but constructed within the larger and much more flexible format of the CDA (“Corepoint
Health,” 2009).
The CCD standard uses an extensible markup language (XML) format, which allows the data to be both humanreadable as well as machine-readable. The CCD can also accommodate and include free-form text, images, and
multimedia. This is a large advantage over the older CCR format.
Functionally, the CCD contains templates, which include the following components:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Header
Purpose
Problems
Procedures
Family history
Social history
Payers
Advance directives
Alerts
Medications
Immunizations
Medical equipment
Vital signs
Functional stats
Results
Encounters
Plan of care
The primary goal of generating and exchanging a patient summary record that utilizes the CCD standard is to
“increase the quality and efficacy of patient transfer between points of care” (“Corepoint Health,” 2009). Whether it
is a data exchange between a physician’s office, a hospital facility, or the pharmacy, the CCD will allow the
receiving care provider in the HIE to see current information about the patient (i.e. orders and results) but also their
prior health history (i.e. problem list, procedures) in a summarized format. Having this information set available to
all care providers involved in the care of the patient allows for better provider coordination, elimination of
duplicative diagnostic tests, and overall better care. With the CCD, both the patient and the providers win.
For the Bay Area HIE, each facility and physician practice will provide the central data repository with current
patient data. When requested, a CCD will be generated out of the HIE and sent to the authorized party (provider or
patient). The CCD can include all 17 templates or it can be limited to only those elements that are needed.
One challenge HIE members will face with a consolidated CCD is the dependency on the data by each hospital and
physician practice. A study by D’Amore et al, found that there are three challenges with the CCD in its current state:
1) problematic CCD hierarchy and organization, 2) inconsistency in data representation, and 3) data conflict or
redundancy within the CCD (D’Amore et al, 2011). Issue number three arises because no standard terminology has
been set. As an example, some CCDs contain SNOMED codes and others contain ICD-9 codes. Until one is
mandated for use by all or each CCD segment is defined accordingly, it is possible that current systems will not be
able to accurately represent consolidated data from multiple providers on a single patient record.
FINAL DRAFT
12
It will be important that all HIE members utilize the same terminology, document, and messaging standards. If the
same data (i.e. problem list) is sent to the central repository using different terminology, then the HIE must have
some mechanism to normalize it. This initial mapping effort will take time to complete. It will also require ongoing
maintenance to ensure that data transmission between each hospital and individual practice merges properly.
Communication Standards:
XSD.b
As an extension of the terminology, document, and messaging standards for the clinical data within the
HIE, there is also a standards need for the communication of this data across the network. To facilitate
this, the HIE will utilize the cross enterprise document sharing standard known as ‘XSD.b,’ which is a
health industry standard used to index and store documents across healthcare enterprises. This is made
possible by document repositories and registries (See Figure 2). The document repository stores
documents in a secure, reliable, and consistent manner that also provides for document retrieval requests,
which would be made by the users of the various information systems in the HIE. The document registry
is responsible for storing information about the documents so the documents can be easily retrieved
regardless of where they are actually stored within the HIE. This standard will be beneficial as it allows
for efficient management, retrieval, and distribution of EHR data across each member of the HIE.
Figure 2: XDS (Source: www.IHE.net)
FINAL DRAFT
13
PIX/PDQ
Another network standard that we are implementing for patient lookup by demographics is the patient
Demographics Query (PDQ). With our HIE integration, PDQ allows application to query a patient central server and
retrieve a patient’s demographic and visit information. In combination with other IHE profiles that perform the
reconciliation of patient’s records, the PDQ uses updated information to respond to the query.
One of the core components of our HIE IT infrastructure is PIX (Patient Identifier Cross-referencing). The PIX
integration profile enables the cross referencing of patient identifiers from multiple patient identifier domains by:
Transmitting patient identity information from an identity source to the Patient Identifier Cross-reference Manager,
and by providing the ability to access the list(s) of cross-referenced patient identifiers either via a query/ response or
via an update notification.
Our HIE supports both HL7 v2.x standards and HL7 v3 standards for PIX/PDQ manager. In the first release of this
project, HL7 v2.x transactions are supported, and HL7 v3 support will be added in future release. Our PIX/PDQ will
implement four server side transactions that will, PIX Feed, PIX Query, PIX update notification and PDQ query
Below is a description of the workflow:
1.
2.
3.
4.
A PIX Source submits a PIX Feed to the PIX Manager, and the PIX Manager sends an acknowledgement
back.
A PIX Consumer sends a PIX Query to the PIX Manager who sends a PIX query response back.
The PIX Manager sends a PIX Update Notification message to a subscribed PIX Consumer, and the
consumer sends an acknowledgment back.
A PDQ Consumer sends a PDQ Query to the PDQ Supplier, which returns a query result to the PDQ
Consumer.
Information Flow, Security, & Architecture
The following diagram highlights the information and data flow of the San Francisco Bay Area HIE. United
Hospital is used to illustrate how it and other entities would feed patient information to the centralized HIE. This
diagram also shows how patients and physician offices will be able to access the data made available in the HIE via
the cloud.
FINAL DRAFT
14
Figure 3: Greater Bay Area Health Information Exchange
Data Exchange - Encryption and Technical Security
For the five hospitals participating in the HIE, a secured virtual private network (VPN) will be setup for each to
connect to the HIE central data repository. A VPN is used to connect to private networks using the internet, which is
a public network. All connections are encrypted, which ensures that no data is breached. There are several secure
VPN protocols that can be utilized including IPSec (Internet Protocol Security), Transport Layer Security
(SSL/TLS), Secure Socket Tunneling Protocol (Secure STP), Point-to-Point Encryption (MPPE), or Secure Shell
(SSH) VPN. Depending on each hospital’s technical capability and resources, any of the protocols will work for
securely connecting to the HIE.
For the physicians and patients connecting to the HIE via the internet, web services security (WSS) will be utilized
to ensure that the data being accessed is kept private and secure. WSS is an extension to Simple Object Access
Protocol (SOAP) which is a protocol used for exchanging structured information via the web. There are several key
aspects of web services security and they include the following (Oracle, 2012):
1.
2.
3.
Authentication – verifying the user trying to access the data is who he/she claims to be
Authorization – granting access to the data that the user is only authorized to access and nothing more
Confidentiality and privacy – these are achieved via data encryption and obfuscation of the sending and
receiving parties’ identities
FINAL DRAFT
4.
15
Integrity – ensuring the data remains unaltered during transit.
The web service security setup will include a transport security layer (i.e. Secure Socket Layer-SSL) and a
message/data level security that ensures confidentiality. There are several WSS tools provided by 3 rd party software
vendors (i.e. Oracle) that can be purchased for this piece of the implementation.
Figure 4 outlines the various standards that will be used including the sample security and encryption tools and
methods.
Figure 4: Greater Bay Area Health Information Exchange
HIPAA Security Requirements
In order for the HIE (now considered a “Business Associate” under HIPAA) to be successful and be legally
compliant, it must adequately address all of the HIPAA security and privacy requirements including but not limited
to the proper protection of health information, making the information available and accessible to patients, the data
is managed in a manner that protects patient privacy, security and data integrity, and that the data is released
following all state and federal regulations (Carter, 2006). The nine principles identified under the HIPAA Privacy
and Security Framework (openness and transparency, purpose specification and minimization, collection limitation,
use limitation, individual participation and control, data integrity and quality, security safeguards and controls;
FINAL DRAFT
16
accountability and oversight, and remedies) should be utilized as the guiding principles in establishing the proper
use, operations and maintenance of the HIE.
Several of the key privacy and security issues that the HIE needs to address are the following:
1.
2.
3.
4.
“Minimum necessary” – the HIE must ensure to limit the release and sharing of protected health
information (PHI) to that which is only necessary to accomplish what’s needed. Utilizing standards such as
the CCR or CCD is one way to do this.
Access – the HIE must ensure that only those authorized to access the data have access. The HIE must also
ensure proper auditing processes are in place to detect any misuse.
Identity management – The HIE must have robust patient identification capabilities to ensure that the
patient is accessing only their data.
Opt-in or Opt-out – the HIE must provide an easy way for patients to opt-in or opt-out of having their data
exchanged within the HIE and being shared amongst physicians and the participating hospitals.
By following the security and communication standards identified by the Certification Commission for Healthcare
Information Technology (CCHIT) under ARRA and Meaningful Use, the HIE should be able to cover the technical
aspects. From a procedural standpoint, it is critical that there be a central HIE governing body that includes
representatives from the participating hospitals. This governance structure will be responsible and accountable for
ensuring that the privacy and security items identified above are addressed properly at the implementation stage but
also moving forward.
Challenges
With the adoption of any new technology in the healthcare industry, there are going to be a number of challenges
that emerge throughout the process. These challenges seem to be fairly common in the adoption of HIEs. The
challenges deal with financial implications, competitive challenges, and the ability to truly provide a fluid manner
for information exchange while retaining semantic interoperability.
The financial implications are not as apparent in the initial adoption, since the organization will be relying solely on
grant funding to address the initial implementation. These challenges will present themselves in maintaining a
sustainable system after the external funding has run out (K, 2012). It has been determined that there will be a large
cost associated with developing and maintaining an HIE. Thus far, the government, both federal and state, have
committed $546 million to help get a total of fifty-six qualified entities off the ground to develop their HIE’s (K,
2012). Though this appears to be a significant investment, it will not stretch very far. It has been predicted that the
government funding for HIEs will run out prior to 2015 (K, 2012). This puts a tremendous burden on anyone that is
in the process of trying to implement a system. Not necessarily from the standpoint of getting things off the ground,
but thereafter many organizations are questioning how they will be able to provide a sustainable system that can
keep up with all the information that flows through the process. Another challenge is a mix of financial
sustainability and technology is the matter in which we are going to keep all standards up to date, which will be
addressed from a technical standpoint in greater detail below. This will have a financial impact since it is requiring
that we need to stay on track with the current standards; in addition to being prepared to have our developers ready
to code two or more different standards into the system as they are mandated. Two examples of this can be described
through the transitions from ICD-9 to ICD-10 and from HL7v2.x to HL7 v3.
The competitive challenges will occur when differing vendors cannot come to terms on the level of information that
they agree to share (Guerra, 2011). Some of them feel a bit threatened when collaborating with other vendors that
they would otherwise consider to be competitors. Another challenge pertains to the vendors interpretations of the
standards that are in place; each vendor may have their own idea of how the standard should be applied (Robert
Rowley, 2012). The meaningful use requirements can be considered loose to interpretation regarding certain
FINAL DRAFT
17
instances. Vendors generally address this challenge by having a regulatory committee in place that meets with
members of the ONC in order to obtain test scripts and eliminate any uncertainties that may have otherwise existed.
This will help to ensure that everything is in place and appropriately documented prior to presenting a module to the
CCHIT for certification (CCHIT, 2012).
The third challenge is information exchange between systems. Due to the requirements around meaningful use, there
are multiple standards in place designed to help different systems talk collaboratively amongst each other. At times,
these standards can present challenges when they are not delivered in a universal method. An example of this can be
described through some of the standard transitions that are currently in the process of being updated. This can be
described further by looking at the examples of ICD-9 to ICD-10 and HL7 v2.x to HL7 v3. The challenges here
pertain to the lack of compatibility between the different formats. Neither of these presents a way to be interoperable
with the standard beneath it. The ICD-9 to ICD-10 transition will require the HIE to be able to recognize and process
both formats as they are delivered differently based on the expanded codes used in ICD-10 (as it was defined earlier
in the paper). Other challenges lie in the adoptability of the two different versions of HL7 that are presented between
version 2 and version 3. The dilemma with these two standards is similar to those of ICD that is noted before. The
HL7 v2.x has a number of different subsets that are defined within it (i.e. version 2.3 vs. 2.6). Each of the
enhancements presents a challenge within the deliverable that might not provide a method to be backwards
compatible with the version before it. The Bay Area HIE will address this challenge by developing a data repository
that provides information on each of the versions to ensure that they are appropriately monitoring and adhering to
the appropriate version that is being sent. The true HL7 challenge will occur with the transition between version 2
and 3. These two versions are not backwards compatible, meaning that they cannot share information between each
other due to the different formats used by each. The version 2 standard uses an ASCII encoding syntax whereas
version 3 is based on an XML encoding syntax. Another technical challenge deals with the CCD. CCD is currently
the top pick for transmitting information through an exchange, though many of the EHRs are not able to support this
transmission (Guerra, 2011). These standard transitions in addition to the overall requirement to adopt the required
standards present a challenge when it comes to the overall availability to the market. There are going to be
challenges in every line of work, but the members of the Bay Area HIE believe that prior diligence to the
implementation process should help achieve and attain better results. Every situation will be addressed with eyes
wide open, and each HIE member looks forward to the prospects of complete patient health records at the point of
care, delivered via semantically interoperable systems.
FINAL DRAFT
18
References
AHIMA. (2012, October 31). Implementation of SNOMED-CT needed to facilitate interoperable exchange of
information. Retrieved from AHIMA:
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_028156.hcsp?dDocName=bok1_028
156
Ahmadian, L., Keizer, N. F., & Cornet, R. (2009). The Use of SNOMED CT for Representing Concepts. In K.-P.
Adlassnig, Medical Informatics in a United and Healthy Europe (pp. 658-662). IOS Press.
AHIMA. (2007). HIM Principles in Health Information Exchange. Retrieved from AHIMA:
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_035095.hcsp?dDocName=bok1_035
095
American Academy of Professional Coders (AAPC). (2011). ICD-10 Frequently Asked Questions. Retrieved from
http://www.icd10hub.com/icd10-faq.htm
American Health Information Management Association (AHIMA). (n.d.). What is ICD-10-CM/PCS? Retrieved
from http://www.ahima.org/icd10/whatisicd10.aspx
American Health Information Management Association (AHIMA). (n.d.). Why is ICD-10-CM/PCS necessary?
Retrieved from http://www.ahima.org/icd10/whyicd10.aspx
Briskin, A. and Hinkley, G. (n.d.). HIEs need to focus on their HITECH HIPAA business associate obligations.
HIMSS. Retrieved from http://www.himss.org/ASP//topics_News_item.asp?cid=73289&tid=33
Carter, P., Lemery, C., Mikels, D. et al. (2006). Privacy and security in health information exchange. Journal of
AHIMA. (77) 10. Retrieved from
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032268.hcsp?dDocName=bok1_032
268
CCHIT. (2010, December 21). Loinc Overview. Retrieved from http://loinc.org/faq/getting-started/gettingstarted/#what -is-loinc
Center for Health System Change. (2008, February). Creating Sustainable Local HIE's. Retrieved from
http://www.hschange.org/CONTENT/970/
Centers for Medicare & Medicaid Services (CMS). (n.d.). ICD-10 Overview. Retrieved from
https://www.cms.gov/Medicare/Medicare-Contracting/ContractorLearningResources/downloads/ICD10_Overview_Presentation.pdf
Corepoint Health. (2010). The HL7 Evolution - Comparing HL7 Version 2 to Version 3, Including a History of
Version 2. 14. Retrieved from http://www.corepointhealth.com/sites/default/files/whitepapers/hl7-v2-v3evolution.pdf
Corepoint Health. (2009). The Continuity of Care Document. Retrieved from
http://www.corepointhealth.com/sites/default/files/whitepapers/continuity-of-care-document-ccd.pdf
D’Amore, J., Sittig, D., Wright, A., et al. (2011, October 22). The Promise of CCD: Challenges and Opportunity for
Quality Improvement and Population Health. AMIA. Retrieved from
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3243208/
Deloitte Center for Health Solutions. (2006). Health Information Exchange Business Models - The Path to
Sustainable Financial Success. Deloitte Center for Health Solutions.
FINAL DRAFT
19
Department of Health and Human Services. (2012). Health Information Exchange. Retrieved from Health IT:
http://www.healthit.gov/providers-professionals/health-information-exchange
DICOM. (2012, April 11). Strategic Document. Retrieved from http://medical.nema.org/dicom/geninfo/Strategy.pdf
e-Health Initiatives. (2011). Governance Model for Health Care Exchanges. Thomson Reuters.
E-Health Initiative. (2012, October). HIE Toolkit. Retrieved from http://www.ehealthinitiative.org/setting-up-agovernance-structure/stakeholders-roles-and-needs.html
EHRScope.com. (2012, March 27). Continuity of Care Documents. Retrieved from
http://www.ehrscope.com/continuity-of-care-documents
Guerra, A. (2011, July). KLAS Report Highlights Public HIE Challenges. Retrieved from
http://healthsystemcio.com/2011/07/08/klas-report-highlights-public-hie-challenges/
HealthITComment. (2007). "Healthcare Informatics- A 3000 Feet View." Retrieved Novemeber 17, 2012, from
http://healthcareinformatics3000feet.blogspot.com/2007/11/weakness-of-hl7v2x.html
HL7. (2012). HL7 Version 2 Product Suite. Retrieved from
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
HL7. (2012). HL7 Version 3 Product Suite. Retrieved from
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186
HL7. HL7/ASTM Implementation Guide for CDA Release 2 -Continuity of Care Document (CCD®) Release 1.
Retrieved from http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6
HIMSS. (2011). HIE technical informational overview. HIMSS. Retrieved from
http://www.himss.org/content/files/HIMSSHIETechnicalOverview.pdf
IBM Corporation. (2012). IBM initiate master data service. (9.5). Retrieved from
http://publib.boulder.ibm.com/infocenter/initiate/v9r5/index.jsp?topic=%2Fcom.ibm.ihe.doc%2Ftopics%2F
c_ihe_XDSusecase.html
iHealthBeat. (2012, October 9). NwHIN exchange nearly transitioned to public-private partnership.Retrieved from
http://www.ihealthbeat.org/articles/2012/10/9/nwhin-exchange-nearly-transitioned-to-publicprivatepartnership.aspx
IHTSDO. (2012, October 31). SNOMED-CT Value Proposition. Retrieved from http://www.ihtsdo.org/snomedct/whysnomedct/snomedfeatures/
IHE. (n.d.). Cross-Enterprise Document Sharing. Retrieved from http://wiki.ihe.net/index.php?title=CrossEnterprise_Document_Sharing
K, S. (2012, April). HIE Challenges. Retrieved from APP Design Blog:
http://www.appdesign.com/blog/2012/04/20/hie-challenges-and-the-survey-says/
Kiefer, J. (2011, December). XDS.b support. Mirth Corporation. Retrieved from
http://www.mirthcorp.com/community/wiki/display/MR/XDS.b+Support
Kolkman, L. (2012, November). Expanding the HIE Funding Pool by Redefining ROI. Retrieved from HIMSS:
http://www.himss.org/ASP/ContentRedirector.asp?ContentID=68449
Mead, C.N. (n.d.). Data Interchange Standards in Healthcare IT - Computable semantic interoperability: Now
possible but still difficult, do we really need a better mousetrap? Journal of Healthcare Information
FINAL DRAFT
20
Management. 20:1. Retrieved from http://www.hl7.org/documentcenter/public_temp_529A18EA-1C23BA17-0CCEB854C82E0B5F/pressreleases/CMeadV3Article_HIMSS_Winter_71_78.pdf
Michael F. Chiang, M. M. (2006). Reliability of SNOMED-CT Coding by Three Physicians using Two
Terminology Browsers. AMIA Annual Symposium Proceedings, 131-135.
Nagy, M., P. Hanzlícek, P. Precková, A. Ríha, M. Dioszegi, L. Seidl and J. Zvárová (2010). Semantic
interoperability in Czech healthcare environment supported by HL7 version 3. Methods of information in
medicine 49(2): 186.
Office for Civil Rights. (n.d.). The HIPAA privacy rule and electronic health information exchange in a networked
environment. Department of Health and Human Services. Retrieved from
http://www.hhs.gov/ocr/privacy/hipaa/understanding/special/healthit/introduction.pdf
Oosterwijk, H. (2004). The DICOM standard, overview, and characteristics. Ringholm Whitepaper. Retrieved from
http://www.ringholm.com/docs/02010_en.htm
Oracle. (2012). Understanding web services security concepts. Oracle Corporation. Retrieved from
http://docs.oracle.com/cd/E17904_01/web.1111/b32511/into_security.htm
Rouse, M. (2010, May). Loinc. Retrieved 1 2012, 11, from SecureHealthIT:
http://searchhealthit.techtarget.com/definition/LOINC
Rowley, R.M. (2012, June). The biggest challenge for HIE is not technical. Retrieved from
http://www.govhealthit.com/news/biggest-challenge-hie-not-technical
Ruggeri, R. (n.d.). Cross-enterprise document sharing-b (XDS.b). IHE. Retrieved from
http://www.ihe.net/participation/upload/iti9_ihewkshp07_xds.pdf
Shaver, D. (2006). "What Are the Primary Benefits of HL7 V2 versus HL7 V3?" Retrieved Novemeber 18, 2012,
from http://www.hl7standards.com/blog/2006/10/05/what-are-the-primary-benefits-of-hl7-v2-versus-hl7-v3
US National Library of Medicine. (2012, October 31). SNOMED-CT FAQ's. Retrieved from National Library of
Medicine: http://www.nlm.nih.gov/research/umls/Snomed/snomed_faq.html
Viangteeravat, T., M. N. Anyanwu, V. R. Nagisetty, E. Kuscu, M. E. Sakauye and D. Wu (2011). Clinical data
integration of distributed data sources using Health Level Seven (HL7) v3-RIM mapping. Journal of
clinical bioinformatics 1(1): 1-10.
Vreeman, D. (2010, December 21). Loinc Overview. Retrieved 1 2012, 11, from Loinc from Regenstrief:
http://loinc.org/faq/getting-started/getting-started/#what-is-loinc