Preparing for future developments in exchanging patient information over the national health information network

5 Questions withGreggMartin,CIOArnotOgdenMedicalCenter

Health Standards IntroductiontoCDA

Insights GeorgetownHospitalSystem

I n T H I S I S S u e

A National Network

I ssue 3 WINTeR 201 1

The health IT journal for the Integration Generation

i

the construction of a national highway system was underway.

The National Networks of Today

Much like the traffic and safety concerns on the road-ways in the mid-20th century, the traditional method for sharing patient information between healthcare organizations is no longer suitable to accommodate the current, and anticipated, patient traffic. Moreover, the technological advancements of the internet and computers in the last 20 years present a realistic solu-tion for transferring patient information now, similar to the automobile’s ability to safely transport people over long distances in a cost-effective way.

With little doubt, Americans could not imagine a country without the network of highways accessible today. Similarly, the national health information network (NHIN) proposed by the Office of the National Coordinator (ONC) is an important future require-ment which will enable hospitals and physicians to be considered “meaningful users” of electronic medical records. This national health information network is one of a number of movements to utilize computer technology as a more flexible solution for communi-cating patient information.

The NHIN

The NHIN is defined by the Office of Interoper- ability and Standards at the ONC as,

“a set of specifications, standards, services and policies that describe how computer systems can securely exchange health information over the internet.”

FeaTure

How do highways relate to a national health information network?

hroughout much of the early 20th century, the automobile increased in its popularity, and this new and exciting technology of-fered a number of opportunities for busi-

ness and leisure. Due to the accelerated growth in production, the existing roads were not in the proper condition to handle the increased traffic. Something needed to be done on a large scale to accommodate the new preference for transportation.

Initially, the creation of the national highway system was not received well by all of those involved in the decision making process. Conflict among deci-sion makers halted legislative action until 1956 when President Eisenhower focused his attention on the highway system for national security pur-poses. Following the President’s acknowledgement of the problem, a public interest in a national highway increased.

Plans began to unfold. At first, construction moved slowly, because of a resistance to the seemingly lofty standards required of the road construction. Ultimately, a number of initial standards were adjusted, and

A National Network: What to Know Before Connecting

“Together, the united forces of our communication and transportation systems are the

dynamic elements in the very name we bear—United States. Without them, we would be a

mere alliance of many separate parts.” President Dwight D. Eisenhower, February 22, 1955

Direct Project is a one-way method for communicat-ing information and does not have the ability to “pull” information from a repository or database.

Therefore, the Direct Project operates differently than traditional HIEs because it does not offer a com-plete bidirectional interoperability solution. Instead, the Direct Project uses one-way communication, sim-ilar to email technology, between pre-identified and trusted sources of information. Furthermore, HIEs operate as smaller-scale and contained networks, covering a state or defined region, and the Direct Project is a national coverage model.

Moving Forward

The nationwide health information network is still in the early stages, yet it is important to continue to read, offer comments and insights into the process, and prepare for the anticipated changes. Undertaking IT projects to meet the first stages of Meaningful Use will take priority, but keeping an eye to future devel-opments will assist in making the right longer term investments.

Like the American highway construction in the middle of the 20th century, the decision to implement an electronic method for communication is a major decision. Therefore, it is important that whichever vendors your organization chooses to partner with, in order to participate in an HIE, RHIO, NHIN, or achieve Meaningful Use, the vendor must share your vision and partner with you throughout the entire implementation process and consistently support any projects in the future.

Read more at corepointhealth.com/START.

Aside from technical objectives, the fundamental objective of a national health information network is to improve patient care and enhance patient safety.

One analogy that works well to describe the func-tion of the NHIN is an online, secure chat room where every healthcare organization in the country is connected to the conversation. If one hospital needs information on a patient, they can access the chat room; request the information from the trusted network of health care facilities; and then use the information to help diagnose or treat that patient more effectively.

The Direct Project

As a first step towards the construction of a national health information network, the ONC established the Direct Project, formerly known as NHIN Direct, to oversee its production. The Direct Project is defined by the ONC as,

“a simple, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet.”

Using the same chat room analogy of the NHIN, the Direct Project would be the application used to send messages in the chat room. The purpose of the Direct Project is an encrypted one-way communica-tion method for disseminating patient information to trusted healthcare organizations and to provide a safe and effective technology to achieve the objectives of the NHIN.

Currently, the Direct Project is still in the planning stages, and the ONC is actively requesting feedback from all stakeholders on the direction of the project.

Are there parts of the Direct Project that will be incorpo-rated into HIEs?

Health Information Exchanges, or HIEs, have received some compar-ison to the NHIN because of their shared communication objectives. The ONC is clear, however, that the

“More than any single action by the government since

the end of the war, this one would change the face of

America.…Its impact on the American economy— the

jobs it would produce in manufacturing and construc-

tion, the rural areas it would open up—was beyond

calculation.” Mandate for Change 1953-1956

Health Standards: Introduction to CDA

By Mike StockemerSenior Integration Specialist at Corepoint Health

After the Meaningful Use final rule was released in July 2010, the Continuity of Care Document

(CCD) has become a key topic of discussion in the health IT industry. Although CCD is important for

the transitioning of patient care from one provider to another, less known is the overall standard

known as CDA, or Clinical Document Architecture.

History of CDAEven though the CDA standard has been around for over a decade, it has not been widely adopted by clinical applications in the United States as a supported way to transfer data between their systems. Since the final Meaningful Use rules have a requirement for the exchange of CCD (specifically HITSP C32) documents, there has been a flurry of activity by healthcare application vendors to learn and support what is perceived to be a new standard in health IT.

Overview of CDAThe purpose of CDA is to provide an exchange model to allow clinical systems to share clinical documents. In order to do this, a standard had to be built that would allow implementers to encode any type of clinical docu-ment into a defined format. The definition of a clinical document is not limited to clinical care documents such as Discharge Summaries or Progress Notes. It also includes documents associated with billing, as well as documents that may be used for disease surveillance or academic research. Clearly to support all of these use cases, the standard had to be extremely robust and flexible.

The CDA standard was derived from the HL7 version 3 Reference Information Model (RIM). The standard spec-ifies both the structure and semantics of a clinical document. CDA documents as well as all HL7 version 3 messages are encoded in Extensible Markup Language (XML).

There is a perception that because the documents are XML, they are simple to process and simple to cre-ate due to the vast array of development tools available to encode and parse XML. In reality, the encoding or parsing of the data is the easy part; the hard part is understanding how to model the data for a specific use case so that these documents can be exchanged between applications, without losing the original context of the document.

Types of CDA DocumentsThe HL7 version 2.x standards are made up of a list of message types and trigger events. A typical interface into or out of a clinical application will only support a very small subset of the overall standard.

With CDA, you do not have different message types and triggers that define the structure of the document; instead, there are implementation guides that constrain the CDA standard in order to fit a specific use case. For example, one common use case in healthcare is the need to transfer the care of a patient from one provider to another. During that transition, it would be advantageous for the new provider to import all

of the ‘pertinent clinical, demographic, and administrative data’ about the new patient into their Practice Management or EMR system. This use case is the basis for the CCD. The rules for producing a compliant CCD document are contained in the CDA Release 2 CCD Implementation Guide.

Implementation GuidesIf you are going to implement a particular type of CDA document, the first step is to get the implementation guide. The guides contain the rules or constraints that are required to produce a compliant constrained CDA.

A simple constraint will look something like the following:

This means your XML instance must have the following <code> element present and the attributes of this element must be as described below:

Since the CDA standard is so flexible, a large number of constraints need to be applied to create a docu-ment that has data modeled in a uniform manner, so systems can achieve semantic interoperability. The CCD Implementation Guide contains 549 constraints on the CDA. These constraints typically limit things like what coding system, or vocabulary, can be used when modeling the data, as well as defining how clinical data such as allergies or problems should be presented in the instance.

Where to Learn MoreThe final rule has put the pressure on EHR vendors to add functionality to their applications to be able to pro-duce and consume CCD documents, but that is not the only use case for CDA today. The Health Story Project (www.healthstory.com) is a good example of a group of organizations who collaborate to develop implemen-tation guides to assist in the sharing of data between clinical applications using CDA.

CONF-1: The value for “Clinical Document / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.

Read more at corepointhealth.com/START.

Your Resource Center.

Go to HL7standards.com

to read practical insights and

viewpoints.

<Clinical Document>...<code code=”34133-9” codeSystem=”2.16.840.1.113883.6.1” displayName=”Summarization of episode note”/>...

</Clinical Document>

Gregg MartinChief Information OfficerArnot Ogden Medical Center

What was the motivation behind achieving stage 6 of the HIMss eHR adoption?

Late in 2009 we discovered that our adoption of technology over the last 20 plus years

appeared to line up well with the HIMSS adoption model. So, we decided to go through the pro-

cess of obtaining the recognition in order to provide us with an independent benchmark that could

provide some validation of our internal planning process.

What impact has that adoption had?

It did two things basically. One, it gave us the validation of our internal strategic planning process that we hoped

it would, but it also has created a conversation within the Strategic Planning group of what components are

missing that could help take us to Stage 7, or a paperless environment.

What element or elements have proven to be the most critical in planning for stage 1 of Meaningful use requirements?

There is very little standardization among the EMRs in this regard. It was necessary to come up with a process

that was timely but manageable when tackling EMR integration projects. This involved being prepared from a

business process, support model, and technical implementation standpoint.

What significant IT initiatives will Arnot Ogden Medical Center undertake next?

We are in the process of affiliating with another hospital, and beginning the process of migrating their facility

off their existing platforms onto ours. We also are planning how to meet the meaningful use requirements, and

expect to qualify for the first year incentive payments by next fall.

How would you advise a peer on starting to evaluate eMR/eHR adoption at their hospital? The first think is to recognize that EMR/EHR adoption is not an MIS or I.T. project…it really is a clinical transfor-

mation project that needs to be owned by a group within the facility. A second, and equally important issue, is

creating a discussion where the value of I.T. is translated into meeting specific business objectives and how it

can help the organization continue to meet its mission.

With the ARRA HITECH requirements, which include penalties for non-adoption beginning around 2015, those

who have not already started this process may need to realize that they may no longer have the luxury of allow-

ing their use of this technology to evolve like we did. While we, in many ways, blazed our own path, and stumbled

a few times along the way, we are now thankful we didn’t wait.

Read the complete interview at corepointhealth.com/START.

QuesTIOns

Gregg MartinChief Information OfficerArnot Ogden Medical Center

ForinsightsonhealthIT,innovation,debates,andHITECH.corepointhealth.com/GENi

BLOG

“Insights”

“Corepoint Health has delivered

a proven integration solution

that helps us better leverage

our MEDITECH environment,

reducing cost and saving time.

Their solutions have enabled

Georgetown Hospital System to

continue providing high levels

of patient care.”

Georgetown Hospital System required a robust integra-tion platform solution to provide more control over their IT environment in implementing new interfaces and elimi-nating costly maintenance fees associated with the point-to-point interface via their MEDITECH system. After evaluating several interface engines, Georgetown Hospital System selected Corepoint Integration Engine to en-hance their existing IT infrastructure.

“Before Corepoint Integration Engine, Georgetown Hospital System operated without an interface engine and re-lied on expensive point-to-point inter-faces,” explained Theresa Palasota, Sr. Programmer Analyst. “We significantly needed to reduce the cost of imple-mentation of redundant interfaces and eliminate monthly maintenance fees for support.”

“Another key objective was to gain control over develop-ing and implementing our interfaces by eliminating the wait time to receive new interfaces and adding control over the deployed interfaces through active monitoring and support.”

“Corepoint Health has delivered a proven integration solution that helps us better leverage our MEDITECH envi-ronment, reducing cost and saving time. Their solutions have enabled Georgetown Hospital System to continue provid-ing high levels of patient care,” added Palasota. “Corepoint Integration Engine and MEDITECH together are a solid combination that delivers real value and real results in our workflows.”

Georgetown Hospital System is a not-for-profit, multi-facility, rural healthcare system spanning the cities of historic Georgetown to the beach resorts of Myrtle Beach, South Carolina.

Read the complete case study at corepointhealth.com/START.

Georgetown Hospital System

HIMSScorepointhealth.com/ HIMss

Booth 6353

Visit us at

Follow us at:

@corepointhealth

facebook.com/corepointhealth

Listen to Corepoint Health customer stories.

www.empoweringstory.com