hie toolkit for provider decision making - calhipso

i

HIE Toolkit for

Provider Decision Making

June 30, 2013

ii

Prepared by

Katherine K. Kim, MPH, MBA

Lori L. Hack, MBA

Dennis K. Browe, MA

David A. Minch, BS, FHIMSS

Holly C. Logan, MA

Contact: [email protected]

Suggested Citation:

Kim KK, Hack LL, Browe DK, Minch DA, Logan HC. (2013) HIE Toolkit for Provider Decision Making.

Broadband Technology Opportunity Program, University of California Davis and CalHIPSO.

This toolkit is made possible by funding through the University of California Davis under award No. 06-

43-B10584 from the National Institute of Standards and Technology (NIST), U.S. Department of

Commerce. The statements, findings, conclusions, and recommendations are those of the presenter(s)

and do not necessarily reflect the views of NIST or the U.S. Department of Commerce.

i

Table of Contents

List of Figures ................................................................................................................................................................... iii

List of Online Appendices ............................................................................................................................................. iii

Executive Summary ............................................................................................................................................................ 1

Section 1 Introduction to Health Information Exchange ............................................................................................ 4

Section 2 Assessing Your Business Needs for HIE ...................................................................................................... 7

Framework ............................................................................................................................................................ 7

Solution Mapping ................................................................................................................................................. 8

Section 3 Stakeholder Engagement ................................................................................................................................ 16

Section 4 Business Case for HIE ................................................................................................................................... 22

Section 5 Health Information Exchange Technology ................................................................................................ 29

Exchange Services.............................................................................................................................................. 29

Workflow Considerations ................................................................................................................................. 36

Architectures for Exchange .............................................................................................................................. 37

Standards and Requirements ............................................................................................................................ 43

Section 6 Use Cases .......................................................................................................................................................... 45

Examples of HIE Use Cases ............................................................................................................................ 49

What are your use cases?................................................................................................................................... 53

Section 7: Assessing Health Information Organizations ............................................................................................ 55

HIO Business Model ......................................................................................................................................... 55

Structure and Organizational Strategy ............................................................................................................ 57

Finances ............................................................................................................................................................... 59

ii

Operations........................................................................................................................................................... 61

Section 8 Requesting HIO proposals ............................................................................................................................ 67

Conclusion ......................................................................................................................................................................... 69

iii

List of Figures

Figure 1: Business Model Framework ...................................................................................................... 7

Figure 2: Stakeholder Engagement Process............................................................................................ 20

Figure 3: Information Technology Investment Framework ..................................................................... 23

Figure 4: Community Master Patient Index ............................................................................................ 31

Figure 5: Record Locator Service ............................................................................................................ 32

Figure 6: A Sample HIO .......................................................................................................................... 38

Figure 7: Centralized HIE Architecture ................................................................................................... 38

Figure 8: Federated HIE Architecture ..................................................................................................... 40

Figure 9: Hybrid HIE Architecture........................................................................................................... 42

Figure 10: Assessing HIOs Structure ....................................................................................................... 57

Figure 11: Assessing HIOs Finances ....................................................................................................... 59

Figure 12: Assessing HIOs Operations .................................................................................................... 61

List of Online Appendices

Appendix A: Index of HIE Toolkits and Resources

Appendix B: Mission and Purpose Discussion Template

Appendix C: Problem Statement Template

Appendix D: Solution Mapping Template

Appendix E: Influence-Interest Stakeholder Matrix

Appendix F: Stakeholder Communication Plan

Appendix G: HIE Benefit Estimation Tool

Appendix H: Rating of Interoperability Strategy by Use Case

Appendix I: Rural HIE Use Case Sample

Appendix J: HIE Use Case Feature Rating Template

Appendix K: Sample HIO RFP

Provider HIE Toolkit p. 1

HIE Toolkit for Provider Decision Making

Executive Summary

Health information exchange (HIE) has emerged as an important component of our national

infrastructure for sharing of personal health information. Federal legislation such as the Health

Information Technology for Economic and Clinical Health Act (HITECH) of the American Recovery and

Reinvestment Act of 2009 (ARRA) made it a priority by channeling funds for state-level HIE, offering

incentives to hospitals and eligible providers for adoption of meaningful use of connected, certified

electronic health records, and sponsoring grants and contracts for HIE development. ARRA authorized

$2 billion to the Office of the National Coordinator for Health Information technology (ONC) and $27

billion to Centers for Medicare and Medicaid Services (CMS) for provider incentives. In addition, new

models of health care and health services delivery have evolved to address the triple aims of patient

experience (quality and satisfaction), population health, and cost as defined by the Institute for Health

Improvement (http://www.ihi.org/offerings/Initiatives/TripleAim/Pages/default.aspx). These models

necessitated new technical infrastructure for data collection, data normalization, making sense of data,

communication and collaboration. Telehealth in all its forms, from telemedicine to mobile health,

combined with health information exchange are all key elements of this new infrastructure. Each of

these aspects of telehealth requires the availability of broadband connectivity, which poses a particular

challenge for some of the rural communities which could most benefit from telemedicine to supplement

the care offered by local providers.

Community organizations such as hospitals, sub-acute facilities, clinics, private practices, and ancillary

service providers are challenged to plan for and implement HIE in order to fulfill these priorities. Among

the important decisions a community needs to make are: What business or strategic needs does HIE

fulfill for you? Should you develop your own health information organization (HIO) to oversee HIE or

should they participate in an existing HIO? If the answer is the latter, which HIO best suits your needs?

If you choose to develop your own HIO, there are plenty of toolkits and resources available to you.

Information, including a variety of tools, templates, work plans and documents, already exists and we’ve

provide a summary of these available toolkits for HIO organizers in the Index of HIE Toolkits and


Resources (Appendix A). However, little guidance exists to support a thoughtful planning process for

community organizations and stakeholders-- especially those in rural and underserved communities--

who might be customers of an HIO. It is particularly important for these stakeholders to understand the

options available and to follow a procurement process that matches their needs with the available

resources before they choose a potentially complicated and expensive HIE solution.

This HIE Toolkit for Provider Decision Making (Toolkit) is designed to support planning for those

stakeholders who are not sure if HIE is a necessary technology or business option, need assistance

navigating the variety of HIE options and alternatives available, or have determined they will move

forward and need assistance in selecting an HIO partner for their needs. The toolkit also provides

guidance for the unique needs of the rural and underserved communities which face additional

technological and financial barriers to HIE. Using this toolkit, these user organizations can obtain

information on HIE/HIO options including best practices, case studies, assessment documents and

guidelines to assist in the evaluation of various HIE options for meeting their particular business needs.

Section One of the Toolkit provides an introduction to health information exchange and health

information organizations.

Section Two of the Toolkit addresses how to understand your business needs and map them to

potential HIE Solutions.

Section Three focuses on identification and engagement of stakeholders for effective planning and

implementation of HIE

Section Four describes how to develop a business case to assist with deciding if HIE is a financially

beneficial strategy.

Section Five gives an overview of HIE technologies. With rapidly changing (and improving) technology

options, it is critical for stakeholders to have a solid and current understanding of technology solutions,

standards and requirements.

Section Six offers HIE use cases including both general interest examples and a few for specialized cases.


Section Seven of the Toolkit helps you navigate the business decisions you will need to make to

determine if an HIO is the right partner to meet the needs identified in section two. It also offers

examples of various HIO business models.

Section Eight provides an overview of how to create a request for proposal for HIO services and make a

selection.

Throughout the toolkit, tools and templates are provided to facilitate thinking and discussion. An online

Appendix provides all tools and templates in the original Microsoft Word or Excel format for you to use.


HIE Toolkit for Provider Decision Making

Section 1 Introduction to Health Information Exchange

Before developing the capacity for health information exchange (HIE), it is useful to think about what

problems your healthcare organization is facing, and whether or not HIE is likely to provide good

solutions to those problems.

HIE is often implemented to improve the quality of health care and reduce costs by:

� Eliminating paperwork,

� Eliminating duplicate tests or treatments,

� Improving patient safety by reducing errors,

� Providing up-to-date information to all entities involved in a patient’s care,

� Improving public health reporting and monitoring,

� Giving patients access to their medical records,

� Enabling clinical analytics.

Whether or not HIE is appropriate for your organization depends on many factors, such as the needs of

your patients and providers, the number and needs of the stakeholders who will need electronic access

to patient information (hospitals, clinics, payers, public health departments, pharmacies, etc.), whether

or not broadband technology is widely available in your community, the costs of implementing HIE, and

the degree to which your organization (or a Health Information Organization you join) can develop

processes and procedures that will justify all stakeholders putting their trust in the HIE system.

This Toolkit will lead you through the important process of determining your goals, the challenges that

face your organization, and whether or not HIE is a good solution to those challenges. If you decide that


HIE is appropriate, the Toolkit helps you evaluate what kind of HIE, what kind of technology, and which

business model might be best for your community. To further inform your decisions, we provide a

compendium of best practices, case studies and guidelines to assist you in the evaluation of HIE options.

In late 2007, the Office of the National Coordinator for Health Information Technology (ONC) initiated a

process through the National Alliance for Health Information Technology to define various terms which

were important for the national move toward electronic patient records and health data exchange.

Among those terms were “health information exchange”, “health information organization”, and

“regional health information organization”1.

Table 1: Definitions

Health Information

Exchange (HIE)

Health Information

Organization (HIO)

Regional Health Information

Organization (RHIO)

The electronic movement of

health-related information

among organizations

according to nationally

recognized standards.

An organization that

oversees and governs the

exchange of health-related

information among

organizations according to

nationally recognized

standards.

A health information organization

that brings together health care

stakeholders within a defined

geographic area and governs health

information exchange among them

for the purpose of improving health

and care in that community.

Maintaining the distinctions among these terms can be useful, and we will try to do so in this Toolkit. In

common usage, however, the term HIE is often used to encompass both the activity of exchange and the

organizations that perform or facilitate that exchange. Further, HIE has come to include some of the

standards for Meaningful Use as defined by the ONC: the participating organizations must not share

common ownership; and to comply with HIPAA, the exchange must take place in an authorized and

secure manner.

The explicit goal of ONC is to make data exchange as open and inclusive as possible. Thus, in HIE, the

movement of data can be either unidirectional or bidirectional and can be between any organizations

with an authorized need to have the data. The data can be any type of health-related data, including

both clinical and non-clinical data (e.g. claims, demographics, financial). The exchange must use

1http://www.nachc.com/client/Key%20HIT%20Terms%20Definitions%20Final_April_2008.pdf


nationally recognized standards such as those promulgated by the American National Standards

Institute (ANSI) and Health Level Seven (HL7), a committee of ANSI.

Similarly, HIOs can take many forms. They can be private, sponsored and paid for by a single large

integrated delivery network; they can be organizations aligned around an EHR vendor; they can be

geographically aligned, state organizations; or they can be aligned by mission or provider type (e.g.

safety-net). While the RHIO moniker has gone by the wayside, there is still a need for communities to

consider HIE on a local and regional basis since the primary patterns of care are often geographically

bound. Most HIOs remain local and regional.


Section 2 Assessing Your Business Needs for HIE

Framework

HIE can be part of a technology-enabled business strategy for accomplishing an organization’s mission.

HIE is not an end in and of itself. A business model framework that relates these strategic elements such

as a mission statement with more operational imperatives such as structure and technology is shown in

the Figure 1 below. We use this framework to organize this toolkit because it is a useful guide to the

important points of discussion that arise in assessing any strategy.

Figure 1: Business Model Framework

As part of the evaluation process, it can be useful to remind ourselves of our mission and purpose and to

share those with potential HIE partners. This way, the mission can frame the subsequent discussion by

providing both a context and a rationale for the ultimate decisions you make. Use the Mission and

Purpose Discussion Guide (Appendix B) to open this dialogue with your partners.


Discussion Guide

Write the organization’s mission statement. What is the ultimate purpose of the organization? Share

these with your partners.

How are your mission statement and your partners’ mission statements similar or different?

Are there any potential conflicts among the organizations’ missions? Might you be in competition? If so,

how would you navigate these conflicts or competitive situations?

Solution Mapping

In this section we consider whether we need HIE and to what end. This process begins with a problem

statement, moves through a needs analysis, and finally, delineates potential solutions.

Do we need health information exchange? In order to answer this question, we start with an exercise in

developing a problem statement.

A problem statement makes clear what issue you are trying to address. A clear problem statement

provides a tool to communicate with those you need to enlist in your solution, or those who might


otherwise have a stake in that solution. A clear statement of the problem you are trying to solve also

provides you with a touchstone for evaluating a proposed solution. By returning to the problem

statement you can ask “Will this solve this particular problem?”

A problem statement includes What, When, Where and for Whom?

• WHAT is the problem? Describe it concisely in one or two sentences. What will happen if the

problem is not addressed? What is the magnitude or extent of problem? Can you quantify it

and make it tangible?

• WHEN does this problem occur? Is it sporadic and continuous, seasonal or not? How often

does it happen and under what circumstances? Is this an immediate problem or is it a longer

term issue?

• WHERE does the problem occur? Is it geographically bound?

• For WHOM is this an issue? Does it affect specific populations, certain organizations? Who are

the stakeholders?

For example, a problem might be high healthcare costs due to avoidable hospital readmissions. This is a

problem for patients, who do not want to be readmitted and whose quality of life suffers from poor

post-discharge communication and follow up. But it may only occur sporadically or more often for those

with readmission-prone conditions. Patients are likely not concerned about this until the readmission is

imminent. It’s not something patients plan for.

It is also a problem for payers who do not want to spend dollars unnecessarily and who worry about the

quality of post-discharge care. Unlike for patients, this is an ongoing concern for payers. Because payers

who don’t address this problem face increasing healthcare costs and lower profit margins, many are

implementing reimbursement models today to make providers responsible for excess costs. .

Thus avoidable hospital readmissions also become an ongoing problem for providers, both because they

may not be reimbursed for certain readmissions, and because they about poor quality follow up for their

patients. To protect themselves financially, providers need to have in place a strategy to address payers’

new reimbursement models.


Geographically, avoidable readmissions are a local issue since most patient care occurs in a local area.

Stakeholders are likely to be most concerned about their own community. In the Use Case outlined

above, it is clear that the problem of avoidable readmissions are a problem for patients, providers and

payers alike. This creates a common area of concern that can be addressed by all stakeholders

participating in the HIO.

Use the Problem Statement Template (Appendix C) below to craft your own problem statement. Try to

be as explicit as possible as you describe the problem. Write down as many problem statements as you

can. The deeper you delve, the more likely you are to get to the root of the problems your community

faces.


Problem Statement Template

Question Answer

WHAT is the problem? Describe it concisely in one or

two sentences.

What will happen if the problem is not addressed?

What is the magnitude or extent of problem?

Can you quantify it and make it tangible?

WHEN does this problem occur?

How often does it happen and under what

circumstances?

Is it sporadic and continuous, seasonal or not?

Is this an immediate problem or is it a longer term issue?

WHERE does the problem occur?

Is it geographically bound?

Does is occur in specific locations?

For WHOM is this an issue?

Does it affect specific populations, certain organizations?

Who are the stakeholders who are concerned?


With the problem statement in hand, you are then prepared to ask, “What does my organization,

stakeholder or customer need to address the problem?” The “need” might be a course of action or a

circumstance; it should be necessary for solving the problem. Try to develop specific statements that

directly link the need with the problem statement.

Many needs may be present and different stakeholder groups may have different needs. In the example

we just used of avoidable readmissions, both the patient and their caregiver might need clear and

understandable discharge instructions and a way to access these instructions at any time. A provider

might also need real-time monitoring of the patient post-discharge, and an easy way to communicate

with the multi-disciplinary, multi-institution care team and patient/caregiver. A payer might need data

regarding discharge location and provider so that they can coordinate and perform case management as

well as analyze the cost-effectiveness of treatments.

To double check that these are needs to address in this particular problem, turn the question into a

statement. For example a patient who has clear discharge instructions available any time she has a

question may be able to avoid complications that lead could to readmission.

Other examples of stakeholder needs are:

• To access patient clinical information across various healthcare organizations

• To coordinate care

• To maintain and access metrics to show outcomes of patient care

• To automate the capture of more data for EHR

• To enable patients to feel more in control of their healthcare through self-service options

For other examples see HIMSS

http://www.himss.org/content/files/HIMSS_HIE_Presentation_HIE_TheBasics.pdf

Try to identify at least 5-7 needs for each problem for each stakeholder. This will help make sure that

you have delved deeply enough into the problem to be able to create an effective solution. You will also

want to determine how these needs are met today, if at all. Try to avoid jumping right to devising

solutions at this point, because that might prevent you from identifying all of your needs.


For our sample problem statement about avoidable hospital readmissions, we’ve assumed

communications are conducted via faxed referrals and ad hoc phone calls. Even if there are integrated

modules within hospital information systems, which can be used by the clinicians and other care team

members who are part of the same organization, this type of system isn’t very useful after discharge

because many community based providers (SNF, rehab, home health, physicians, patient/caregiver) do

not have access directly into the hospital system. In such a system, discharge instructions might only be

offered to patients verbally or be mixed into a set of papers that includes brochures, referral forms or

medication inserts. Thus, we’ve identified one need relating to the problem of avoidable hospital

readmissions: a better system of communication that allows post-discharge community-based providers

to access the hospital system to be able to access information about the care the patient has received

and the approved instructions for post-discharge care.

With your own list of needs in hand, you can begin to identify similarly specific potential solutions. As

you work through our Solution Mapping Template, a high level description of the solution is enough for

now. For each need, ask yourself if your proposed solution is better than (+), worse than (-) or the same

as (=) the current solution? Which specific needs does your proposed solution fill? Is the solution more

focused on the needs of one stakeholder group over another? By answering these questions, you’ll start

to flesh out your solution with the particular details that will allow you to determine whether or not the

solution is workable for all of your stakeholders.

For example for our problem of post-discharge communication, one possible solution could be a

community-wide shared care plan with health information exchange that allows us to populate

information into the plan and track the services provided according to the plan. Such a solution would

enable all of the providers involved in the patient’s care to get access to up-to-date information.

Use the following Solution Mapping Template (Appendix D) to work through your own community’s

health and healthcare problem, needs, and potential solutions.


Instructions for Solution Mapping Template

• Review our example which we’ve put into the Solution Mapping Template below. Then use the rest of the template to map your

problem, need, current approach and proposed solutions.

• For each stakeholder group identify the problem from the stakeholder’s perspective.

• For each stakeholder group identify 5-7 needs related to that problem.

• Describe how each need is currently met (or not met).

• Identify potential solutions.

• Rate your proposed new solution as better than (+), worse than (-) or the same as (=) the current solution.

Stakeholder Group: example-patient

Problem Need Current Approach Proposed Solution

Better +, Worse -, Same =

Avoidable

readmission disrupts

patient’s life and

worsens quality of

life

1. Clear and comprehensive

discharge instructions at time of

discharge from hospital

Disorganized and fragmented information

including verbal instructions, printed

instruction sheets, copies of referral forms,

medication inserts

Shared Care Plan

+ All information stored in one site and

electronically, care team can see

instructions from other team members

2. Accessible discharge instructions

whenever patient or their caregiver

or family member has a question

Relies on patient to keep track of papers, not

sure who to call if they have questions

Shared Care Plan

+ One place for patient/caregiver to find all

discharge instructions

= Patients may not have computer literacy

or access to technology needed


Solution Mapping Template

Stakeholder Group:

Problem Need Current Solution

Proposed Solution

Better +, Worse -, Same =

1.

2.

3.

4.

5.

6.

7.

Repeat for each stakeholder group.


Section 3 Stakeholder Engagement

There are many potential stakeholders and they differ based on the specific application of HIE you might

consider. In the previous section, you thought about categories of stakeholders. In this section, you’ll

conduct planning around stakeholders who may be representative of the categories in the last section,

or may be specific individuals. The choice of when in the planning process to address stakeholder

engagement is up to you. You may want to identify stakeholders before detailing needs since having

their input will be valuable. Or you can determine needs and solutions and engage stakeholders when

you are ready to begin solution planning. The earlier you involve them, the better. The tools in this

section will help you work through how to determine which stakeholders to involve, at what level, and

the best way to engage them.

Stakeholder Identification

First, come up with a list of stakeholders by organization. Name individuals in those organizations if

possible. This list should include everyone who has some stake in your project, could influence it

positively or negatively, or is interested in the outcome. Don’t worry about justifying why they are

stakeholders or how important they are. Just develop a comprehensive list.

Second, write the name of each stakeholder on a post-it and place it in appropriate quadrant of the

influence-interest matrix shown below (Appendix E). Along the vertical axis is influence. An individual

with high influence over your project would be placed in the upper quadrants. For example, a

stakeholder with high influence might have authority over funding, possess political power, or have a

community leadership role that others look to for decision making. Along the horizontal axis is interest.

Someone who is highly interested in your project would be placed in the quadrants on the right side of

the matrix. High interest might be exhibited by willingness to come to meetings regularly, reaching out

to you or your team to inquire about the project or responding in a timely way when you contact them,

being a direct recipient of the outcome of the project. If there are any differences of opinion about

where a particular stakeholder falls in the matrix, discuss them.

During this exercise, be as accurate as you can be about the actual level of interest and influence each

stakeholder has. Don’t place someone into the champion quadrant because you wish they were a

champion. Place them based on how they actually act towards your project today.


Third, decide on the appropriate engagement strategy for each quadrant. Your greatest effort should be

spent on the “Champions” who have high influence and high interest. If they are positively disposed to

your project, they can remove barriers, build relationships, and bring resources to your project. Create

regular opportunities to involve them and assure you are making their involvement worthwhile. The

least effort should be spent on “Bystanders.” In the middle, are the “Potentials” whom you want to

cultivate if you believe you can increase their interest in your HIE effort. Select the individual

stakeholders in this quadrant who you have the best chance of increasing interest and develop a

tailored outreach plan. You will want to maintain periodic communication with “Supporters” to keep

them informed but you may not need their intensive engagement.

Influence-Interest Stakeholder Matrix

Low High Interest

Champions Potentials

Supporters Bystanders

Influence

High

Low


Use the Stakeholder Communication Plan shown below (Appendix F) to brainstorm and document your

engagement strategy. It is important to match the message to the audience. Determine the key

messaged points through the eyes of the stakeholder and create a strategy specific to the stakeholders

concerns and issues related to the project. Frequency and time of communication will be unique to the

stakeholder category. Continuous communication will ensure the project is well understood and assists

the stakeholder in remaining engaged in the process.


Several models exists to create a continuous cycle of engagement that allows for the movement of

stakeholders from a primary level of interest and passive engagement to fully engaged champions of the

Stakeholder Communication Plan

STAKEHOLDER GROUP

1) Patient 2) Provider

(Physician,

NP, PA)

3) Health

System

4) Community

How will change affect this

stakeholder?

What will be the concerns of this

stakeholder?

KEY MESSAGE:

What information will motivate

this stakeholder to support/not

derail the project/change effort?

When should the information be

delivered?

Who is most credible messenger

(e.g., immediate supervisor,

influential peer)?

What are the most effective

channels (e.g., department

meetings, newsletter)?

How will you know you are on

track in communicating with this

stakeholder?

What is the message we want to

convey to this stakeholder?

How often will the message be

conveyed to this group?


HIO vision and mission. This transformation from initial contact to education to full engagement is

necessary to ensure that the various constituents can determine their own value proposition and ROI for

participation in HIE.

The figure 2 below identifies a model of stakeholder engagement that should exist in the HIO.2

Figure 2: Stakeholder Engagement Process

This continuous cycle of stakeholder engagement links to the prior Section 2 in which you have

identified your stakeholders, determined their problems (concerns) and worked through a solutions

mapping exercise to prioritize and link the solutions to the stakeholders. This process will assist you in

keeping the high priority projects on the radar of the stakeholders. Continuous engagement of the

stakeholders will require matching the engagement technique to the stakeholder readiness for

engagement. In addition, addressing the obstacles to engagement early and often will allow the

stakeholder to move along the continuum of passive to active participation.

Engagement techniques can include education sessions, learning circles, webinars and other methods to

ensure that the stakeholder is fully educated about HIE, understands the priorities and is committed to

the vision and mission and priorities identified through the mapping process. The education and

communication process should overcome technical barriers such as accessibility to information, location

and size and make up of stakeholder participants. Convening a large number of stakeholders in open

and transparent process with credible leadership will go a long way to converting passive participants

2 http://www.bursamalaysia.com/market/


into active supporters of the organization. 3 Once education and solutions mapping are completed,

stakeholders will remain engaged as long as their internal priorities are being monitored, reported and

acted upon. The Review and Report process identified in the stakeholder diagram is essential in

maintaining the “momentum” of HIE activities and value to the participants.

3 Merritt D, Best Practice Guide for Stakeholder Engagement, Center for Community Health Leadership, 2005


Section 4 Business Case for HIE

You started with a problem, determined the underlying needs, and have arrived at some high level

solutions. Will your solution yield positive value? Is it a strategic investment or a cost of doing business

you are willing to pay?

First let’s talk about the difference between a business case and a business model. A business model is a

tool that expresses an organization’s logic model for earning money. It includes value, the architecture

of the firm for creating, marketing and delivering this value, and the generation of profitable and

sustainable revenue streams.4

Both a business model and a business case model require an understanding of what your organization or

your customer finds valuable. But a business model goes further than a business case in describing how

you operationalize the value at various levels, such as economic, operational and strategic levels.

Elements of a business model include your mission and purpose, organizational structure, product and

service delivery strategy, marketing, operational functions, and financial model including investment,

cost, revenue generation. The business model is a blueprint for how businesses are run. You’ll want to

know that the HIO you may be creating or joining has a business model in place that matches your

business objectives. We’ll address this topic in more depth in Section 6: Assessing Health Information

Organizations. For now, we want to focus on developing a business case for HIE so that you can assess

whether or to what extent investing in HIE or joining an HIO would be a good business decision for you

and your stakeholders.

There are numerous reasons for undertaking an initiative in information technology (IT). To help you

think about your own reasons, we’ve provided in Figure 2 below a framework for IT investment which

identifies two key dimensions in the business case decision making process: your strategic objective,

which highlights the tradeoff between short-term profitability and long-term growth (shown in the

horizontal arrow); and your technology scope, which differentiates shared infrastructure from business

solutions (shown in the vertical arrow).5

4 Osterwalder, A. (2004) The Business Model Ontology: A Proposition in a Design Science Approach. Unpublished

doctoral dissertation. Universite de Lausanne Ecole des Hautes Etudes Commerciale. Lausanne, Switzerland.

Retrieved from http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf. 5 Ross, J.W., & Beath, C.M. (2002). Beyond the Business Case: New Approaches to IT Investment. MIT Sloan

Management Review


Process Improvement

Experiments

Renewal Transformation

Figure 3: Information Technology Investment Framework

The process improvement quadrant represents a business solution such as a particular software system

needed for short-term growth. Experiments are those initiatives that use business solutions which may

be important for long-term growth. Transformational investments are those that are potentially high

risk-high and reward, or ones which the organization can’t afford not to make. And finally, renewal

projects are those that are required to support current operations. You can use this framework to think

about the elements of your own business case for HIE.

Creating a business case is one way to identify why your organization or group might undertake a

venture or initiative. A business case should include information about the investment, the cost, the

benefit and the value. Investment includes the resources put into the project. Cost includes both the up

front, capital and ongoing costs. Benefits may be strategic, operational, financial, community, or other.

Your decision can be based on assessment of non-financial benefits as well as economic. Some of the

possible categories of non-financial benefits are suggested in the HIMSS Guide to Participating in a

Health Information Exchange.6 They include reputation, market position, new opportunities,

competitive advantage, quality, safety, outcomes, service efficiency, disaster recovery, wait times,

access, and community needs. Finally, value is the benefit received for the cost expended.

6 http://www.himss.org/files/HIMSSorg/content/files/HIE_GuideWhitePaper.pdf

Technology Scope

Business

Solutions

Shared

Infrastructure

Short-term Long-term Strategic

Profitability Growth Objective


If the benefit and value received are greater than the investment and ongoing cost then you have a

positive business case.

Benefit + Value > Investment + Ongoing Cost

There are published estimates of national and state level business cases which seek to identify the

collective or societal value of HIE. One study found the value of fully standardized health information

exchange to be $77.8 billion in healthcare value per year.7 Another estimated that savings from

standardized information exchange for the nation was $87 billion annually.8 And a third study projected

that savings to the state of Massachusetts was $23.8 million annually.9 So you can see that it might be

very much worth your while to invest in HIE.

A local business case is different from these national and state level business cases because it focuses on

the value for an individual organization or the local partners in HIE. According to published data about

local business case development, local savings from HIE may result from reduction in emergency

department visits10,11, higher quality in primary care12, reduction in medical errors13,14,15, and improved

surveillance of infectious disease16,17.

7 Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D. W., & Middleton, B. (2005). The Value Of Health Care

Information Exchange And Interoperability. Health Affairs. 8 Center for Information Technology Leadership. (2008). www.citl.org.

9 Massachusetts Technology Collaborative. (2008). Advanced technologies to lower health care costs and improve

quality: Executive summary. http:==www.massinsight.com=docs=AdvancedTechnologies_MTC_NEHI.pdf. 10 Frisse ME, Johnson KB, Nian H, et al. The financial impact of health information exchange on emergency

department care. J Am Med Inform Assoc 2012;19:328e33. 11

Overhage JM, Dextr PR, Perkins SM, et al. A randomized, controlled trial of clinical information shared from

another institution. Ann Emerg Med 2002;39:14e23. reduced emergency room charges (Overhage, 2007). 12 Kern LM, Blumenthal D, Pincus H, Dhopeshwarkar R, Kaushal R. Quality measures for capturing the effects of

health information exchange. AMIA Annu Symp Proc. 2008 Nov 6:1001. 13 Bates DW, Gawande AA. Patient safety: improving safety with information technology. N Engl J Med

2003;348:2526e34. 14 Bates DW, Cohen M, Leape LL, et al. Focus on quality improvement: white paper: reducing the frequency of

errors in medicine using information technology. J Am Med Inform Assoc 2001;8:299e308. 15 Kaelber DC, Bates DW. Health information exchange and patient safety. J Biomed Inform. 2007;40(6

Suppl):S40e5. 16 Kho AN, Lemmon L, Commiskey M, et al. Use of a regional health information exchange to detect crossover of

patients with MRSA between urban hospitals. J Am Med Inform Assoc 2008;15:212e16. 17 Kho AN, Dexter PR, Warvel JS, et al. An effective computerized reminder for contact isolation of patients

colonized or infected with resistant organisms. Int J Med Inform 2008;77:194e8.


HIE Benefit Estimation Tool

The spreadsheet will help you identify and quantify the potential benefits and costs of HIE in your

community or for your organization. The metrics included in the tool are specific to HIE and come from

published sources that are either academic, peer-reviewed articles or reputable industry articles and

reports. You can find a working spreadsheet, including the appropriate embedded calculations in the

online Appendix G.


Enter data into green cells

Duplicate Lab Tests Low Medium High Sources

Number of lab tests 100,000

Estimated reduction in lab tests due to HIE 5.00% 13.00% 20.00% 5% from Frisse 2007 13%: Tierney 1987. 20%: Sridhar 2012.

Average cost per lab/test $ 27.75

Total cost savings from redundant tests due to HIE $ 138,750 $ 360,750 $ 555,000 Our Data

Emergency Department Visits Low Medium High Sources

ED visit rate per 1000 people 293

ED Visits per 1000 people. Average # of ED visits per 1000 people in California was 293 in 2010. The average in the US was

419. http://www.statehealthfacts.org/profileind.jsp?rgn=6&ind=388

Population 851,710 851,710 is the population in Kern County, CA

Estimated number of ED visits 249,551

Percent of visits avoided due to HIE 15.00% Potentially preventable ED Visits: 15%: Sridhar 2012.

Savings per ED visit due to HIE $ 10.00 $ 18.00 $ 26.00 $26: Overhage 2002. $10: Frisse 2007

Total cost savings in ED visits due to HIE $ 374,327 $ 673,788 $ 973,249

Duplicate Radiology Tests Low Medium High Sources

Number of radiology tests 100,000

Percent reduction in number of radiology tests 13.00% Frisse 2007

Average cost per test $ 60.00 Frisse 2007

Estimated cost savings from avoiding redundant tests $ 780,000.00

Hospital Admissions from ED Low Medium High Sources

Number of hospitalizations following ED visits annually 20,000 Frisse 2012 found 97% of costs savings due to reduced admissions from ED

Potentially avoidable hospitalizations due to lack of

information 5.25% 10.00% 14.00%

5.25%: Frisee 2007. 10%: Sridhar 2012. 14%: FCG. Smith 2005 13.6% of primary care visits have missing clinical information.

An alternative could be to focus on particular conditions, e.g. California's overall preventable hospitalization rate of 10533

per 100,000 in 2008 (including 15 conditions)

http://www.oshpd.ca.gov/hid/products/preventable_hospitalizations/pdfs/PH_REPORT_WEB.pdf

Cost of 23-hour observation admission $ 1,000.00

Frisse 2007 used the cost of a 23-hour observation stay. Frisse 2012 used $4999 as average regional cost of a

hospitalization from Tennessee Hospital Association.

Total savings from preventable hospitalization due to HIE $ 1,050,000.00 $ 2,000,000.00 $ 2,800,000.00

TOTAL ESTIMATE OF BENEFIT FROM HIE $ 2,343,076.55 $ 3,034,537.78 $ 4,328,249.02

HIE Benefit Estimation Tool


Note: Numbers are illustrative only. They are not benchmarks

Year 1 Year 2 Year 3 Year 4 Year 5

Personnel

Managerial 25,000 25,000 25,000 25,000 25,000

Clinical 25,000 25,000 25,000 25,000 25,000

Technical 25,000 25,000 25,000 25,000 25,000

Financial 25,000 25,000 25,000 25,000 25,000

Analytical 25,000 25,000 25,000 25,000 25,000

Subtotal 125,000 125,000 125,000 125,000 125,000

Benefits 35% 43,750 43,750 43,750 43,750 43,750

Personel Subtotal 168,750 168,750 168,750 168,750 168,750

Other Costs

Rent 5,000 5,000 5,000 5,000 5,000

Utilities 1,000 1,000 1,000 1,000 1,000

Office Equipment 1,000 1,000 1,000 1,000 1,000

Outreach and Communication 1,000 1,000 1,000 1,000 1,000

Travel 1,000 1,000 1,000 1,000 1,000

Legal and Accounting 5,000 5,000 5,000 5,000 5,000

Consultants 25,000 25,000 25,000 25,000 25,000

Supplies and Miscellaneous 1,000 1,000 1,000 1,000 1,000

Other Cost Subtotal 40,000 40,000 40,000 40,000 40,000

One-time and Capital Technology Costs

Software 100,000

Hardware 100,000

Implementation Services 100,000

Interfaces 40,000

One-time and Capital Subtotal 340,000 - - - -

Ongoing Technology Costs

Hosting 10,000 10,000 10,000 10,000 10,000

Upgrades 0 - 25,000 - 25,000

Maintenance and Support (for licensed software) 0 18,000 18,000 18,000 18,000

Other Fees 0 1,000 1,000 1,000 1,000

Ongoing Technology Cost Subtotal 10,000 29,000 54,000 29,000 54,000

Grand Total 558,750 237,750 262,750 237,750 262,750

Cost Estimation Tool


The National Rural Health Resource Center has devised a useful ROI calculator that will help you develop

your business case18. This tool includes examples of potential cost savings for the deployment of HIE-

related technology. For example, the spreadsheet calculates potential savings and costs for EHR

deployment and maintenance. Although the metrics are based on EHRs, not solely HIE, the information

can be a part of your evaluation of the cost of participation in HIE. Another component of the ROI

calculator is a handy side-by-side chart that compares potential benefits from HIE and the stakeholders

to whom those benefits may accrue. Since benefits under differing use cases accrue to different

stakeholders, one scenario might yield benefit to one group while having a negative impact on another.

For example, the ROI tool suggests that the benefits of increased provider availability accrue to

hospitals, providers, and patients while reduced consults and tests benefits payers and consumers.

These are important considerations for your organization’s business case for HIE.

If you have decided, based on assessment of your problem, needs, solutions, that HIE is a promising

strategy, and you’ve found there is a potentially positive business case, your next step is to investigate

the technological solutions available to support HIE. Section 5 provides an introduction to HIE

technologies and the issues you’ll want to consider.

18

http://www.ruralcenter.org/rhitnd/hie-toolkit


Section 5 Health Information Exchange Technology

Exchange Services

HIOs can provide a range of services to their members. Which services you choose will depend on the

business decisions and needs analysis developed in the previous section. The decision will also take into

consideration the capabilities of your EHR, whether or not you belong to an accountable care

organization (ACO) or integrated delivery network (IDN), and cost. In the next section, the decision

process is outlined. However, it is important to understand the various technology services and

structures that make up HIE in order to evaluate whether developing your own HIO or procuring the

services of an HIE is the better option.

Foundational Services

There are common functions that are typically included in an HIE’s base charge: the capability for the

HIE to link patients together, to locate providers within the HIE for message exchange, to locate a

provider’s data, to authorize the participants to perform functions on the HIE, and to keep logs of the

HIE’s use. Some of these are system-level services which any form of HIE needs, and others relate to

interoperability.

The system-level services are:

� Entity Directory (Hospitals, Med Groups, etc.) This is a directory of the HIE’s participants which

typically contains information about the entity, rules for exchanging data with the entity, and

security keys, which allow for encryption and decryption of data as it traverses the internet. The

Master entity directory is set up when a new entity signs their Participation Agreement and is


formally admitted into the HIE. It may also contain information relative to billing for services,

indicators for standards used, and other information useful to the conduct of health data

exchange.

� User Directory This directory is for the registration of all of the HIE’s users. It will usually contain

a user ID and passwords (ideally encrypted), some demographic information, internal email

address, pointers to user security certificates used for communication, and role coding for

determination of access privileges (authorization) within the HIE.

� Authentication / Authorization Methods Users must be authenticated (their credentials tested

and passed / permitted) and authorized (privileges defined for use of certain HIE functions). All

HIEs have secure methods for identification, authentication, and authorization of their users.

This is a very important function, which parallels these same functions in the entity EHRs. Some

HIEs are now requiring 2-factor authentication – that is, the user must not only know a secret

password, but must also possess a token or device for receiving a second method of

authenticating, or pass a biometric test (such as a fingerprint scan). Note that for workflow-

enabled HIEs, a method is used to allow the automatic and secured authorization of an EHR

user, once they are logged into the EHR, to jump over to the HIE without further authentication

steps – this method is commonly known as Single Sign-on (SSO). The end result is a closer

binding of the HIE’s portal functions into the EHR’s workflow and screen context. We will say

more about this capability later.

� ATNA-compliant Transaction and Use Logs The Audit Trail and Node Authentication (ATNA)

specification provides a method for the uniform creation and analysis of log events to discover

misuse and to track utilization and untoward security events. When legitimate but unusual

events occur, such as a “break-the-glass” event in which otherwise protected data is viewed, log

records are written so that they can be reviewed by the entity originating the data and by the

entity viewing the data. Logs are very important for the protection of patient data and for the

HIO’s ability to fulfill its security obligation as a HIPAA-compliant entity.

Interoperability services deal with the mechanics of moving data from one form understood by the

source system to another form understood by the destination system:

� Community Master Patient Index (CMPI) The CMPI (aka EMPI for Enterprise Master Patient

Index) essentially provides a link to all sources of patient data, and to the identifiers used by

each source. In addition, well designed CMPIs will also maintain links to the patient based on the


unique identifier a clinic or practices uses for each patient, so that after the first data request,

you can use your own patient identifier to get up-to-date data for the correct patient. As shown

in the example below, it contains the HIE’s internal identifier, several pieces of demographic

information, some alternate identifier information such as a personal health identifier, a SSN if

the patient wishes, perhaps a plan identifier, and other information useful to the HIE. Finally,

for each instance of another associated identifier for each data contributor or consumer, there

is an identifier associated with that entity.

Figure 4: Community Master Patient Index

The CMPI is used when data is received by the HIE from a data contributor to link that piece of

data to the correct patient. When data is sent from the HIE to a data consumer (results

distribution), the proper identifier can be used to allow the receiver to file the information

appropriately. Finally, when a provider links into the HIE with patient context (for workflow-

enabled portals), the CMPI is used to locate and display the correct patient without the provider

having to search for the patient.

� Record Locator Service (RLS) For the RLS, the content will differ by the HIO architecture,

described later in this section. Federated and Hybrid models will contain pointers used for

retrieving the specific documents from the XDS.b repositories located either in the data

supplier’s EHR, or in the edge server located at the data supplier or the HIE.


Figure 5: Record Locator Service

The CMPI and RLS are used together by the HIE, to locate patient data across all of the

contributing HIO and provider nodes once a patient has been identified.

� Master Provider Index (MPrI) The HIE’s Master Provider Index is used to identify the providers

who work at the entities that belong to the HIE – it is essentially the HIE’s provider directory.

The index is used in conjunction with HIE physician messaging to determine the correct

destination of messages and in translating provider codes in orders to the identifier appropriate

for the receiving EHR. The MPrI also is used to identify the physicians and their organizations

when reviewing the ATNA message audit logs. The MPrI is typically updated by the participating

entities from their individual entity provider masters, or from the entity medical staff offices.

� Other Directories (Clinics, Public Services, Registries, etc.) The HIE must communicate with

many outside (non-member) entities whose endpoint addresses will be listed in a separate

directory with substantially the same structure as the Entity Directory. These entities include

Public Health, the Immunization Registry, any state-sponsored services, outside reference

laboratories, pharmacies, and non-Member endpoints such as SNFs, Nursing Homes, County

EMS services, schools, and more. Essentially, any end-point supplier or receiver of information,

whether or not associated with a patient, needs to be listed in a message destination directory.

Some of the more mature HIEs have multiple clinical registries to which patients are assigned.

All of the information on each registry, including the type and qualifying clinical elements is

typically included in the registry directory. There are also very likely other types of specialty

directories for supporting patient-level functionality and other distinct services of the HIE.

� Provider-to-Provider Messaging Also called “Secure Messaging” or “Clinician-Clinician

Messaging” this is simply an enhanced form of email messaging that is fully encrypted and

HIPAA compliant and allows two or more participants to message each other in a secure

manner. NwHIN Direct, is an example of this type of messaging, and may be deployed in an HIE


along with the HIE’s own portal-based messaging. Often, this is how HIE’s perform referrals –

through the use of template messages. You will want to consider workflow issues when you

look at messaging functionality, since it typically requires extra “clicks” to use functionality

embedded in the HIE.

Transaction Services (Interfaces)

In addition there is a relatively short list of “Core” services which every HIE should be providing. These

start with Transaction Services – inbound and outbound interfaces between the HIE and the

participants. As the term “interface” implies, these services connect two different computer systems, so

that a provider may interact with the HIE from within an EHR. Some interfaces may include:

� ADT: Encounters (hospital admissions, hospital and ambulatory registrations, ED registrations),

discharges, demographic updates and notifications

� ADT: MPI updates, which record information about messages passed from one part of the

system to another

� Lab results

� Discharge summaries and other transcribed documents

� Care reminders, messages from the HIE’s messaging system

� Medication lists

Many of the interfaces are bi-directional – meaning that they can both emanate from EHRs and be

received by EHRs, particularly orders and results, EHR messaging, requests and receipts of CCDs

(Continuity of Care Document) and other documents.

Further Interoperability Services

The HIE needs to standardize how data is represented in the HIE’s Clinical Data Repository (CDR) and in

the clinical portal (EHR). These services include:

� Data parsing and translation, which reads accepted standards for transaction formatting, such as

Health Level 7 (HL7) versions 2 and 3, ANSI (American National Standards Institute) ASC X-12,

and HITSP (Health Information Technology Standards Panel).

� Data normalization, which translates unique code sets at participant locations into the common

code sets for the HIE. For example, while Provider A may call-out their Aetna payer as a separate


financial class, the HIE may use the “commercial” financial class for all non-government payers.

Normalization assures that data represented in the HIE is consistent.

� Semantic normalization is the translation of one terminology set to another so that the HIE can

use consistent terminology to classify “like data” for analytics. Each set of terminology is

separately mapped from the inbound message to its semantic equivalent in the HIE. When

information is sent outbound (to Public Health, as an example), semantic rules and translations

can also be applied so that the receiver gets the data in a specific format. Semantic

terminologies include:

o LOINC for Laboratory

o RXNorm for Pharmacy

o SNOMED for general medical terminology

o ICD-10-CM for Diagnoses / ICD-10-PCS for Procedures

o CPT for ambulatory services

� Continuity of Care Document (CCD) parsing and storing of the discrete data allows computability

and gives the portal and downstream users a rich set of current patient observations to work

from.

Application Services

In addition to the transaction and interoperability services, there are also a set of application services

which most HIEs have. Following list of application services that are generally accepted as a minimum

“must have” for HIEs:

� Results Distribution This critical service enables the HIE to receive results from a data supplier

(Commercial laboratory or a hospital) and route it to an intended recipient (another hospital’s or

a provider’s EHR).

� Consent Management (Opt-In, Opt-Out) While consent is typically obtained at the point of care,

the HIE must know about the patient’s choice to allow or disallow data sharing, and the HIE

must be able to use that notification of consent to manage access to the patient’s records.

Further, in situations of emergency access, the HIE must be able to deploy a “break the glass”

procedure to allow logged access to consent-restricted records.


� Portal Portals are web service screens that let users access the CDR and other messaging

functions and services. The portal is the HIE’s window into their longitudinal or “community”

record – a summary record for any of the patients of providers who contribute data to that HIE.

� Gateways These are sets of communications protocols and standards for transmitting and

exchanging data with other entities such as other local HIEs, State HIEs, Direct HISPs,

Immunization Registry, Public Health, and other eHealth Exchange (formerly NHIN and NwHIN)19

participants. The purpose of the gateway is to bridge the gap between the provider’s EHR, and

other entities to whom they would otherwise require an individual point-to-point connection.

For example, to achieve Meaningful Use, a provider must transmit data to a public health

agency. In many states, such as California, establishing a direct connection is costly and

complicated. A gateway can solve this problem.

� Flow Sheets These are graphical or table representations of tests or clinical observations taken

over a period of time, charted individually or in combinations. Examples include blood pressure,

pulse and insulin levels over time.

� “Mark and Transfer” This is the ability for the portal user to select certain documents or

observations by clicking on them in the portal to transfer them into the EHR. This simple but

important task requires a lot of “behind the scenes” interface work.

� “Break the Glass”(BTG) enables a user to view information marked sensitive or to view data on

who have opted out except for emergency situations. Coupled with ATNA audit capabilities, a

log record is created for each use so that appropriateness can be checked.

Specialty Services:

While these services may involve additional costs, they are often what differentiates one HIE service

from another.

� Data Warehouse / Data Analytics may include clinical management and business management.

Clinical management is a form of provider support in which best practice algorithms, triggered

by new data, review the patient’s chart and generate recommendations for the provider. These

algorithms can report information about outcomes, and can send messages to the provider

about routinely scheduled events such as tests, blood sugar levels, immunizations, and other

19

eHealth Exchange is the new name for the nationwide health information network which has now been placed in

a public-private corporation for administration – see http://healthewayinc.org/index.php/exchange.


aspects of chronic disease management. In addition, data analytics can automate the reporting

of various diagnoses and lab results required by the CDC. Business management analytics

include reporting about insurance claims, population health, clinical trials, public health case

management , ACO metrics and meaningful use standards.

� Integrated Physician “EHR-Lite” is an abridged version of an EHR that allows for limited data

entry and may have limited functionality required for Meaningful Use particularly in stage 2 and

later when health information exchange, patient engagement, and clinical measures become

more important.

� Full EHR with contracted Installation and support

� Other Physician Products such as ePrescribing, practice management and home device

monitoring

� Patient Engagement:

o Personal Health Record (PHR)

o Patient messaging (bi-directional)usually via Direct Messaging or a similar secure

protocol

� Dictation Services

� Disease Registries

� Advance Directives

� Telemedicine Services

Workflow Considerations

After privacy and security, workflow is the most important consideration in HIE. Workflow refers to the

overall interaction of processes which allow a clinic or hospital to provide health care to patients.

Individual processes (which are made up of tasks) come together in workflow. Patient registration is an

example of a process, as is filling a medication refill. Healthcare workflows tend to be quite complicated,

and documenting them can lead to a detailed understanding of how different tasks interact and depend

upon each other. In a health care setting often multiple processes need to be coordinated, with time-

sensitive information being handed off to different departments and being provided to patients.

The value of HIE is directly proportional to the degree that it simplifies difficult, complex and time-

consuming tasks. Thus, before you look at HIE options, you’ll want to analyze your workflow to


determine which tasks or challenges you’ll want the HIE to help with. In addition to simplifying routine

tasks, the HIE should automate complex tasks which have required a great deal of staff time, such as

monitoring a cohort of patients for needed treatments, or reconciling medications. Some HIE questions

to consider in relation to workflow are:

� Are notifications delivered to the provider’s in-box or EHR-based work list?

� Is clinical data reconciled? This will promote physician adoption and use of the HIE.

� Can physicians easily manage their patients within the EHR?

� Is HIE portal functionality (the Browser) available within the context of the provider’s EHR?

� Does Single Sign-on allow switching between the EHR and the HIE’s browser-based

functionality? (Single Sign-on is a process for passing the user’s EHR credentials through to the

HIE’s browser to save time.)

Architectures for Exchange

There are three fundamental architectures for carrying out HIE. Two of them have been developed by

the ONC: eHealth Exchange20 (Exchange) and NwHIN Direct21, both of which can be facilitated through

an EHR which has been built to use them. The third architecture for exchange is through use of an HIO.

The HIO might simply facilitate the exchange of data through Direct and Exchange for member provider

organizations, or it can provide full EHR functionality for its constituents.

The diagram below depicts a typical HIO. Many different providers and ancillary services supply

information to and receive information from the HIO. A copy of all of the data contributed can be

stored within the boundary of the HIO, or data may only be passed through to the end recipient without

a copy being maintained in a community repository.

20

http://www.healthit.gov/sites/default/files/pdf/fact-sheets/get-the-facts-about-nationwide-hit-direct-project-

and-connect.pdf 21

http://directproject.org/


Figure 6: A Sample HIO

HIOs exhibit one of three technology architectures which will impact both the HIO’s services and the

availability of data that can be viewed in the HIO’s portal or retrieved and consumed:

� Centralized

� Federated (aka Distributed)

� Hybrid

There are advantages and disadvantages to each architecture, but more importantly, there are some

limitations which can restrict availability of data.

Centralized HIE Architecture

In the centralized model, all data sent to the HIO by the participants is normalized and stored in a

central repository. This includes the demographic information for construction of the Community

Master Patient Index and all clinical data sent by the data suppliers.

Figure 7: Centralized HIE Architecture


Advantages:

� When all of the HIE’s data is stored centrally in a clinical data repository (CDR), response to a

data request, either through the HIE’s portal or through an Exchange query, is quicker than

other models. This is because the data is centrally maintained and consolidated; there is no

added latency while data is gathered from multiple places and consolidated. Further, the user is

sure that all data that has been made available by the data suppliers is included in the summary

they receive.

� Data is pre-coordinated and reconciled. Duplicates in clinical subject areas such as medications,

allergies, and problems can be located and eliminated as the data flows in.

� A centralized clinical repository facilitates community-wide data analysis since all data is

available centrally and does not have to be “fetched” from the participants.

� Economies of scale, including better resource management, are introduced through the use of

large-scale central resources as long as appropriate investments are made.

� The CDR and HIE portal can be a simple but effective source data backup for an institution’s

EHR. While this wouldn’t typically allow information to be entered, it would allow the patient’s

clinical summary and even a rich set of clinical data to be reviewed, even without the EHR.

Limitations:

� Many providers consider the clinical data they accumulate on a patient to be of significant

strategic value to their organization, and consequently, they are reluctant to place the data in a

location where it will be available to others with the appropriate authorization. Thus, the biggest

advantage of a centralized architecture may also be perceived by many provider organizations

as the biggest disadvantage: all of the provider’s clinical data about a patient is now in a location

where it can be shared with others.

� Strong central coordination is required. There are more stringent requirements for backup and

high-availability strategies, and a professional data center management is imperative. The HIO’s

data center or cloud service should be security and management certified. SAS 70, or more

preferably, the newer SSAE 16 or ISAE 3402 standards are not certifications per se, but they are

audit standards for data centers.

� Although data is typically partitioned by entity (meaning that the data for any given entity can

be easily isolated and excluded, if needed) participants may fear that all data is mixed together.


� The continuous process of data normalization and de-duplication can require significant staff

time, especially when manual reconciliation of data is required, as it may be when maintaining

the HIE’s centralized community-wide master patient index (CMPI).

� The centralized model requires a larger up-front investment, and requires the early significant

participation of each data supplier.

� If a set of clinical data that is sent to the HIE is subsequently updated, the updated data is not

typically guaranteed to be properly matched up with and replace the original. This can lead to

data which have been removed from the data supplier’s EHR still appearing in the CDR.

Federated HIE Architecture

In the Federated technical architecture, most data remains in repositories that exist behind each

provider’s firewalls. With this mode of operation, when a document is generated (such as a lab result,

or a medication order), only the pointer to that document is sent to the HIE, and the clinical data itself

remains outside of the HIE’s CDR. When there is an authorized request for a set of clinical data, the

pointers are used by the HIE to retrieve the data from the data provider’s EHR or edge server.

Figure 8: Federated HIE Architecture

Under the Federated model the individual EHRs send to the HIE a minimal set of information to maintain

the CMPI and record locator service (RLS). All other data such as discharge summaries, visit summaries,

clinical summaries and so forth are maintained on EHR’s repository or edge server22. When an

authorized user wants to view patient records, they must first read the CMPI and the RLS entries to

select a patient, visit, and document type, and then make a request for the patient’s data from the EHR

or edge server.

22

http://wiki.ihe.net/index.php?title=Cross-Enterprise_Document_Sharing


Advantages:

� Data is stored locally within the EHR’s firewalls, or in edge servers that are firewalled away from

the HIE. This architecture appeals to participants who are “protective” of their data.

� Data is always current (corrections are maintained within their appropriate EHR section), which

is important when an EHR’s records must be updated or appended.

� Failure of a single EHR system or connection would only make some HIE patient data

unavailable.

� Risk of data exposure to hackers is less because data is widely dispersed.

Limitations:

� HIE users cannot always get access to data.

� Access latency can be significant, especially when data is stored behind entity firewalls. Even

with agreements to provide specified service levels, specific data may be unavailable at any

given time.

� Because data are dispersed, it’s not possible to perform cross-entity community data analysis. If

the participants sign a separate agreement allowing clinical data to be de-identified and

aggregated, some community data analysis will be possible.

� Data queried is displayed “on the fly” making it impossible to pre-coordinate data subsets and

merge duplicate data instances.

� The HIE does not serve as a simple backup for the EHR.

� Incomplete data may be returned if one or more EHRs are unavailable when the patient record

is queried. (Usually the HIE allows a specified number of seconds for a data response; if one of

the data sources doesn’t respond in that time, that source’s data doesn’t get included in the

response.)

� Participants who host their EHR data locally may experience significant draw on network

resources to support queries for data, since each individual query will result in a data push

and/or pull to/from their local system.

Hybrid HIE Architecture

The hybrid technical architecture is a blend of the two previously discussed architectures, with some

portion of the data being placed into a central repository, and some being maintained in an external


edge server unique to the entity. In the scenario depicted in the diagram, the EHR sends all of its clinical

data to the HIE, and the HIE, according to its rules, files some of the data into the CDR, with the

remainder being placed into the Edge Server for that EHR. For the data sent to the edge server, a

pointer to that data is also placed into the RLS. There are almost as many versions of the hybrid

architectural model as there are vendors who sell software and/or services to HIOs. In some cases,

copies of some of the key clinical data fields are made and stored into the CDR – usually those needed to

generate a patient’s clinical summary in a portal, or a cumulative continuity of care document (CCD) for

transmission.

Figure 9: Hybrid HIE Architecture

Advantages:

Hybrid architecture allows each participant to choose what portions of their data are centralized, and

what data remains private. When more data is stored in the CDR, the advantages and disadvantages of

a hybrid architecture look more like those for a centralized architecture; when less data is stored in the

CDR, the advantages and disadvantages look more like those for a federated architecture.

Limitations:

Cost for the hybrid approach can be significantly more than with either the centralized or federated

approach because both modes of message storage and retrieval need to be supported. Because this

was the original architecture chosen by the ONC and early HIE pilots, it is still dominant architecture.


Standards and Requirements

An EHR with built-in and activated interface capability is critical to interoperation with HIE. If your EHR

does not have the ability to send and receive HL7 transactions, then interoperation with an HIE will not

be possible without significant additional cost to normalize nonstandard data. A comprehensive list of

interfaces required by most HIEs is included in the HIE-Ready Catalogue which was published in 2012 by

California Health eQuality (CHeQ)23.

Supported Outbound Transactions from the EHR

In fulfillment of meaningful use requirements, the following transaction list should be available from the

EHR as automatically triggered event messages when the corresponding activities occur in the EHR. The

list corresponds to specific HL7 messages and should be available at version 2.5 or 3.1.

� ADT Admission and Encounter Registration & Discharge

� ADT Demographic update

� ADT patient merge

� Orders

� Appointment Notification

� Results and Observations

� Transcribed Reports (e.g. visit notes, visit summary, plan of care)

� Immunizations

� Continuity of Care Document (CCD)

Supported Inbound Transactions into the EHR

When messages from the following transaction are received by the EHR, the appropriate data elements

should be loaded into the EHR and associated with the proper patient, triggering an appropriate

workflow.

� ADT Encounter Notifications & Discharge Notifications

23

http://www.ucdmc.ucdavis.edu/iphi/Programs/cheq/HIEready.html


� ADT Demographic update

� Results and Observations (Laboratory & Radiology Results)

� Transcribed Reports (i.e. visit notes, visit summary, plan of care, H&P, operative report,

pathology report, etc.)

� Orders (optional in ambulatory EHRs)

� Receive and consume a Continuity of Care Document (CCD)

Continuity of Care Document (CCD - HITSP C32 Specification)

The CCD is often called a Summary of Care document and is intended to provide the most up-to-date

health status of the patient. Because of the detailed nature of the CCD, it is imperative that the EHR

vendor subscribe to the reference implementation published by the Interoperability Workgroup.

Formatted as an HL7 Version 3.1 message (which has been further specified and constrained by HITSP

with a reference implementation specification by the Interoperability Workgroup24 in conjunction with

HealtheWay), the CCD contains 18 different clinical and demographic subject areas including patient

demographic information, provider information, problem list, allergies, medications, results, and many

others.

Support for Direct

The EHR must send and receive NwHIN Direct messages through a contracted HISP (Health Information

Service Provider) which may also be a service of the HIE. Even if the provider will also be joining an HIE

this capability is important, because it may be several years before the HIE is connected to all healthcare

service providers in the provider’s community. Direct can be a simple and efficient way to push clinical

data to destinations that need it for transition of care, even if the data is also flowing to the local HIE.

24

http://www.interopwg.org/documents/request.html


Section 6 Use Cases

Thinking about use cases will help you carefully consider what services your HIE will need to provide.

The table below shows which use cases can be satisfied with each of the three interoperability

architectures. Remember, an HIE is bi-directional and can provide for both pushing data and pulling or

browsing for data; HIEs with a central clinical repository can support a patient portal and analytics.

Direct can only be used to push messages from one point to another. Connect allows clinical data on a

single patient to be “pulled” from a participating data source.

Table 2: Comparison of Interoperability Strategies by Use Case

Transaction

involving

interoperability

Critical points HIE Direct eHealth

Exchange

Emergency Room

access to patient

data

When a patient is admitted to an emergency facility

where the patient has not been before, no data is

available. HIEs can solve this problem by pulling data

from somewhere which can be through an HIE’s

portal (leading to more complete data), or by using

eHealth Exchange

x x

Patient referrals (in-

bound or out-bound)

The NwHIN Direct protocol can be used effectively to

push a referral message to a receiver, and the

referral message can be enhanced by attachment of

relevant clinical data (Continuity of Care Document).

In the HIE, the HIE’s messaging system can be used to

push a referral, and the pertinent clinical data can

either be included with the message, or a link can be

included pointing to the patient’s record in the HIE

portal.

x x

Distribution of

results (lab,

radiology,

transcription)

Results can be delivered by the HIE into the

providers’ EHRs. Results can also be delivered using

the Direct protocol, but this requires adding them

manually to the provider’s EHR. Future versions of

EHRs that are equipped to use Direct will probably

have some ability to incorporate results pushed to

them.

x x

Reconciliation of

medication

HIEs with centralized clinical repositories can pre-

coordinate medication lists, which makes the actual

clinical process of medication reconciliation very

straightforward. eHealth Exchange can query for the

medication list from specified providers, and Direct

can query where medication lists are pushed to the

provider in advance, but in both cases coordination

and reconciliation of the various lists is completely

manual.

x x x


Transaction

involving

interoperability


Exchange

Transmission of

clinical orders

The HIE’s transaction system is used to deliver an

HL7 message containing the order, and in some of

the more sophisticated implementations, the HIE will

produce follow-up alerts when results from orders

are overdue. Direct could be used to place orders,

but the receiver would necessarily have to be a node

on a HISP, and the provider’s HISP would have to be

capable of sending to that HISP if it isn’t the same

one. The provider may have to match the result to

the correct patient manually.

x x

Meaningful use

solutions for

engaging patients:

Neither Direct nor eHealth Exchange can involve

patients. Thus, for all three functions, HIEs with

central repositories can produce Patient Health

Records (PHRs)

1) Provide clinical

info (discharge/ visit)

Some HIEs can also send secure summaries of EHR

data to patients

x

EHR

2) Communications/

messages

Some HIEs and can allow communication between

patients and providers

x

EHR

3) Patient access to

records

Alternatively, a PHR tied to a provider’s EHR can

make data and communications available to the

patient.

x

EHR

Send immunization/

get history

Sending information to public health agencies and

immunization registries can be accomplished either

through Direct or through an HIE gateway. eHealth

Exchange can accept data from the registry to the

EHR or the HIE if permission is obtained first by

phone. Some HIEs are planning to have their

gateways be able to query and download registry

information on their patients.

x x

Syndromic

surveillance

Some EHRs are equipped to interoperate directly

with public health services, using either Direct or the

HIE’s gateway. In addition, some HIEs are being

programmed to keep current with Public Health

watch lists, and to send data matching those lists.

We expect more EHRs and HIEs to implement

syndromic surveillance in the near future.

x x

Hospitalist getting

information from

specialists

A provider needing this information would use the

HIE or standard eHealth Exchange methods. If the

data were considered sensitive, the “break the glass”

protocol would be used to access patient data

through the HIE.

x x

Clinical integration /

data warehouse

Only HIEs have the ability to create and maintain a

data warehouse, and only HIEs have the ability to link

and aggregate patient data into a longitudinal

x


Transaction

involving

interoperability


Exchange

record. As more providers align with one or more

ACOs, the ability to manage patient outcomes will

become critical to their financial survival. Analytics

that make use of the longitudinal patient record will

become a necessary tool in for both the ACO

managers and for the provider. The NwHIN

protocols are only useful for processing individual

messages and cannot be used for clinical or

management analytics.

Use the rating tool based on this table (Appendix H) to help select which interoperability options you

should consider to meet your needs. You can add additional use cases based on your own needs. The

spreadsheet with automatically calculate the score based on your ratings of the importance of each

item.


Appendix H: Rating Tool for Interoperability Strategy by Use Case

Instructions:

Rate how importance each transaction is on scale of 1 to 7 with 1 = not at all important and 7 = extremely important. Enter rating in the green cell.

The rating will be automatically scored under each applicable interoperability option.

The total score for each interoperability option will give you an idea of which options to consider for your HIE needs.

Transaction involving

interoperability

Critical points Rate Importance

(1 to 7)

HIE Direct Connect

Emergency Room access to

patient data

When a patient is admitted to an emergency facility where the patient has not been

before, no data is available. HIEs can solve this problem by pulling data from

somewhere which can be through an HIE’s portal (leading to more complete data),

or by using NwHIN Connect.

1 1 1

Patient referrals (in-bound or

out-bound)

The NwHIN Direct protocol can be used effectively to push a referral message to a

receiver, and the referral message can be enhanced by attachment of relevant

clinical data (Continuity of Care Document). In the HIE, the HIE’s messaging system

can be used to push a referral, and the pertinent clinical data can either be included

with the message, or a link can be included pointing to the patient’s record in the

HIE portal.

1 1 1

Distribution of results (lab,

radiology, transcription)

Results can be delivered by the HIE into the providers’ EHRs. Results can also be

delivered using the Direct protocol, but this requires adding them manually to the

provider’s EHR. Future versions of EHRs that are equipped to use Direct will

probably have some ability to incorporate results pushed to them.

1 1 1

Reconciliation of medication HIEs with centralized clinical repositories can pre-coordinate medication lists, which

makes the actual clinical process of medication reconciliation very straightforward.

Connect can query for the medication list from specified providers, and Direct can

query where medication lists are pushed to the provider in advance, but in both

cases coordination and reconciliation of the various lists is completely manual.

1 1 1 1

Transmission of clinical

orders

The HIE’s transaction system is used to deliver an HL7 message containing the order,

and in some of the more sophisticated implementations, the HIE will produce

follow-up alerts when results from orders are overdue. Direct could be used to

place orders, but the receiver would necessarily have to be a node on a HISP, and

the provider’s HISP would have to be capable of sending to that HISP if it isn’t the

same one. The provider may have to match the result to the correct patient

manually.

1 1 1

1

EHR

1

EHR

1

EHR

Send immunization/ get

history

Sending information to public health agencies and immunization registries can be

accomplished either through Direct or through an HIE gateway. Connect can accept

data from the registry to the EHR or the HIE if permission is obtained first by phone.

Some HIEs are planning to have their gateways be able to query and download

registry information on their patients.

1 1 1

Syndromic surveillance Some EHRs are equipped to interoperate directly with public health services, using

either Direct or the HIE’s gateway. In addition, some HIEs are being programmed to

keep current with Public Health watch lists, and to send data matching those lists.

We expect more EHRs and HIEs to implement syndromic surveillance in the near

future.

1 1 1

Hospitalist getting

information from specialists

A provider needing this information would use the HIE or standard Connect

methods. If the data were considered sensitive, the “break the glass” protocol

would be used to access patient data through the HIE.

1 1 1

Clinical integration / data

warehouse

Only HIEs have the ability to create and maintain a data warehouse, and only HIEs

have the ability to link and aggregate patient data into a longitudinal record. As

more providers align with one or more ACOs, the ability to manage patient

outcomes will become critical to their financial survival. Analytics that make use of

the longitudinal patient record will become a necessary tool in for both the ACO

managers and for the provider. The NwHIN protocols are only useful for processing

individual messages and cannot be used for clinical or management analytics.

1 1

SCORE 12 6 3

3) Patient access to records Alternatively, a PHR tied to a provider’s EHR can make data and communications

available to the patient.

1

1) Provide clinical info

(discharge/ visit)

Some HIEs can also send secure summaries of EHR data to patients 1

2) Communications/

messages

Some HIEs and can allow communication between patients and providers 1

Meaningful use solutions for

engaging patients:

Neither Direct nor Connect can involve patients. Thus, for all three functions, HIEs

with central repositories can produce Patient Health Records (PHRs)

1


Examples of HIE Use Cases

The four use cases below show how HIE technologies might help you think about specific challenges

involved in implementing HIE. As these cases show, you’ll particularly want to ask questions such as, At

which points will health information need to be transmitted? What will each entity (provider, hospital,

pharmacy, payer, etc.) need to do with that information? For example, information coming from a

hospital to a provider should be integrated into the patient’s Electronic Health Record for careful

tracking of care. Information from a provider to a pharmacy will need to refer to the patient’s Medical

Record Number so that the prescription can be tracked by the provider, by the pharmacy, and by the

payer. Ideally, the provider will be notified when the prescription is filled and re-filled, to ascertain

whether or not the patient is taking the prescribed drug. The issues highlighted in these use cases

should help you think about whether or not HIE can help your organization deliver better care, decrease

administrative workload, or cut costs.

1. HIE can simplify referring a patient to a specialist while meeting Meaningful Use requirements.

Stage 1 and Stage 2 Meaningful Use requirements issued by the federal government require that when

one provider is taking over the care of a patient from another provider, a record summarizing the

patient’s care so far be transmitted to the new provider. The ONC Direct Project which is sometimes

referred to as the Direct standard/messaging25 uses Simple Mail Transport Protocol (SMTP) to send

encrypted health information to a direct mail address used only for HIE.

In a pilot project in Oregon involving several stakeholders26, these steps for referring a patient to a

specialist were isolated:

� A primary care provider refers a patient to a specialist and includes a summary care record after

having made the determination that it is clinically and legally appropriate and necessary to send

these reports to the specialist.

� The referring provider initiates the referral message, with the referral reason described in the

message along with clinical documents attached.

25

www.directproject.org 26

http://wiki.directproject.org/Primary+care+provider+refers+patient+to+specialist+including+summary+care+rec

ord


� The specialist then sees the new referral in their system and either creates a new patient record

or updates the existing one with the new clinical information.

� In this scenario, at minimum a textual description may be transmitted, and ideally a structured

referral message (following the international Health Level 7 standards) and a meaningful use-

compliant summary of care document will be transmitted along with optional PDF or image

attachments.

This use case outlines the critical contact points for HIE in the case of a provider referring a patient to a

specialist. An encrypted, secure message from the primary care provider to the specialist needs to be

recognized in the specialist’s system as a new referral, with both systems accommodating text and

attachments. The specialist’s system needs to make it easy to create a new EHR with the information

provided. Ideally that EHR will have a seamless connection to the systems for making and confirming

appointments, billing, and transmitting secure information to other entities such as payers and

Departments of Public Health.

2. HIE can help rural providers communicate more easily with specialists who have consulted virtually

with their patients through telemedicine.

Transportation times and distances patients need to travel are often much greater in rural communities.

Using telemedicine, patients can link with specialists who aren’t local. Then the specialist can send a

summary of the virtual consultation to the patient’s physician. Using Direct messaging to accomplish this

goal also helps meet the Meaningful Use Stage 1 requirement of having the capability to exchange key

clinical information. In this use case, a patient in a rural town visits a local telemedicine center to

receive a virtual consultation from a specialist. The telemedicine center then transfers any video and

audio files from the visit to the patient’s primary care physician27:

� After the virtual consultation, a representative at the telemedicine center sends a Direct

message to the primary provider, and attaches the relevant audio/video files. (The files need to

be structured according to the appropriate specifications, and the message sent and received

following Direct protocols for security).

3. HIE can send lab results to EHR systems.

27

http://www.siframework.org/scenario_toc3.html


There is currently no official standard for connecting labs and EHRs, and new interfaces can be

expensive for providers to adopt. One solution for this problem has been ELINCS28, which enables the

formatting and coding of electronic messages exchanged between clinical labs and ambulatory EHR

systems. In 2005, the California HealthCare Foundation (CHCF) began developing ELINCS in order to

begin the process of adopting a national lab data standard. ELINCS follows HL7 international standards

for security and inter-operability.

Following is a use case for ELINCS for the reporting of laboratory results to EHR applications29:

� A laboratory order is entered into an ambulatory EHR system by a clinician.

� The EHR system generates a lab requisition that is communicated to the clinical laboratory.

� The information from the order requisition is manually entered or electronically imported

into the laboratory information system (LIS) of the laboratory.

� The specimen(s) required for the order are made available to the laboratory.

� The laboratory performs or attempts to perform the ordered tests.

� Information regarding the status and results of the ordered tests is electronically

transmitted to the EHR system that generated the lab requisition.

This scenario highlights a question you should consider carefully: Where are the points of contact

between the patient’s EHR, the provider’s input (such as ordering a lab test, sending a prescription, or

referring the patient to a specialist), and the entities that will act on that input? At each of these points

of contact, the HIE must ensure that the data is secure, that it arrives in a format that can be used easily

by both systems, and that it provides for necessary feedback. In the case of the lab order above, that

feedback will be either the results of the test or the fact that it was not possible to perform the tests. In

either case, the process you outline must include a step for responding to that feedback: communicating

the results to the patient, providing decision support for the provider’s next steps, and confirming those

next steps were taken.

4. HIE can facilitate information exchange among multiple levels of stakeholders.

28

http://elincs.chcf.org/ 29

http://www.redwoodmednet.org/projects/hie/docs/amc_elincs_20081121.pdf


Tracking data for Departments of Public Health can involve several different stakeholders, such as the

regional health information organization (RHIO), the State Department of Health, local health

departments and their partners, and consumers. For example, the work and data flow for influenza

surveillance and response might look like this30:

� Data from patient-clinician encounters in individual facilities (e.g., hospitals, ambulatory,

Emergency Room (ER), local labs, and pharmacy and physician offices) and hospital resources

(e.g. number of beds) are filtered to identify data relevant to influenza surveillance and

response. Data are aggregated by pre-defined criteria and approved standards. The aggregation

can be either geographical (zip/county) or temporal (longitudinally link encounter data at

individual level).

� Data are then validated for quality and integrity and formatted for transmission using approved

standards.

� Public Health Agencies that request data are identified.

� Data are transmitted to the State Department of Health.

� Data are received and acknowledged by the State DOH.

� Data are assessed for quality and validity by the State DOH.

� Local health departments are identified for data distribution based on jurisdiction and needs.

� Relevant influenza surveillance and hospital resource data and reports are provided to the local

health department to assist with influenza surveillance and response activities.

� Influenza surveillance data and reports are provided to consumers by the State DOH for

increasing awareness of asthma conditions in order to assist with interventions.

30

Taken from the SHIN-NY Health Information Exchange,

http://www.health.ny.gov/technology/projects/docs/health_information_exchange_for_public_health_-

_use_case.pdf


� Influenza surveillance report and information are provided to the public by local health

departments for increasing awareness of local influenza conditions in order to assist with

interventions.

In this scenario, you can see that very specific information will need to be relayed from each stakeholder

to the Department of Public Health. You’ll want to assess your HIE technology with an eye to

aggregating and filtering information of this sort from patient records. Your HIE will need to have

protocols in place for linking with the regional health information organization (RHIO) which can help

conduct surveillance, and with your local public health entities.

These four use cases are intended to highlight some issues for you to consider as you follow this

Toolkit’s processes for determining whether HIE is going to be useful to your organization and, if so,

what your requirements will be. If your organization has a particular use case that is not covered here,

you may consult our Index of Toolkits and Resources (Appendix A) for web resources containing many

other use cases which may help you think through your requirements.

What are your use cases?

You’ve already done a lot of thinking about use case in the process of developing your problem

statement and mapping the problem to solutions. By documenting the use case(s) at this point, you are

able to describe for your stakeholders and potential vendors, what you hope to accomplish and how you

anticipate using HIE in a solution. This will help you when you design your HIE if you decide to build it,

and to develop an RFP and evaluate proposals if you decide to procure HIE services from a vendor.

Develop a Use Case that is relevant to the stakeholders and reflects the problem and solution mapping

exercise previously conducted from the Tool Kit. Ensure that the Use Case will depict technology how

the technology may differ in the solutions to the Use Case examples. Make sure that the Use Case will

address unique situations related to the stakeholders such as remote locations, broadband

insufficiencies, and reimbursement shifts such as ACO requirements or Meaningful Use incentive

measures.


A comprehensive Use Case should depict reasonable expectations from the stakeholders that are

considering the HIE solution. The stakeholders should be involved in finalizing and approving the use

case with as much detail as possible. The vendor can prepare a demonstration of the actual system

capability to show the stakeholders how the solution addresses each aspect of the Use Case. This will

ensure that the stakeholders see the product in action against a commonly understood problem and not

a pre-packaged presentation. The Use Case may also be used to develop the requirements of a full RFP.

Sample Use Case for rural providers coordinating transitions of care can be found in the Appendix I. The

summary is listed below:

The use cases for these care transitions include:

1. Out of Area Hospital discharges patient to home providers.

2. A primary care physician refers a patient to a specialist (Part 1 of the closed loop

referral).

3. After seeing the patient, the specialist returns a care summary back to the primary care

physician (Part 2 of the closed loop referral).

4. Patient accesses discharge instructions and a care summary from more than one

provider in an integrated way.

Please use the following use case to describe how your solution could greatly improve these scenarios.

Assume physicians would have the ability to send and receive and access care summaries or discharge

summaries immediately after a visit in a secure and efficient manner.


Section 7: Assessing Health Information Organizations

Earlier in this Toolkit, we gave you an overview of the different technology models for HIE. If you are

considering joining an HIO, in addition to assessing the technology you’ll want to assess the HIO’s

structure, operations and finances.

As you begin to create a vision for HIE it will be important to create a corresponding HIE strategic plan,

in which your mission, values and vision inform your objectives and goals. This strategic plan will inform

the type of HIE that will be the most effective for you. Rural and underserved communities and

providers have unique needs. Their populations, workflow, use cases and technology needs will be

different from those of urban and more highly resourced settings. These communities will want to think

about what kind of technology potential HIE partners can support, how these partners will interact with

specialty care, and gain a realistic view of the operational resources available.

Convening stakeholders to discuss the mission, vision and values for your collaborative will clarify what

your requirements for a successful partnership will be. Your partnership agreement should address your

specific and measurable objectives and goals. The Agency for Healthcare Research and Quality

Evaluation Toolkit for Health Information Exchange Projects offers sample criteria for measurable goals

and objectives31.

HIO Business Model

Once you’ve completed your assessment of the governance and benefits of an HIO, you can see if the

HIO in question is a good fit with your needs. Especially for rural and safety net providers, financial and

staff resources are generally limited, making it all the more important to allocate time and funding to

HIO partners that best meet the business needs.

The number of HIOs across the country rises and falls each year, with new ones cropping up and others

closing their doors. The eHealthInitiative’s (eHI) 2011 Report on Health Information Exchange:

31

AHRQ (2009). Evaluation Toolkit.

http://healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources/919/health_information_exc

hange_(hie)_evaluation_toolkit/27870


Sustainable HIE in a Changing Landscape reported 234 HIOs in 2010 but only 196 in 2011

(eHealthInitiative.org). In 2010, 18 (7.7%) of the HIOs were self-sustaining; in 2011 this number rose to

24 (12.2%) in 2011. This indicates slight progress, but the greatest challenge for HIOs, as identified by

the respondents to the eHI survey, is developing a long-term business model for future growth and

sustainability. To date, most HIOs have been supported by significant levels of federal and private

grants. In fact, more than 80% of HIOs at all stages of development plan to apply for grants (Health IT

Transition Group, 2006). Yet, research (Adler-Milstein, 2010) shows that gaining funding early from HIE

stakeholders and users, e.g., organizations who contribute or use data, was associated with greater

likelihood of financial viability than relying on grant funds.

As we mentioned earlier there are three levels of business models you’ll want to consider for your

organization: economic, operational and strategic. The economic-level business model focuses solely

on financial matters such as revenue (e.g. pricing) and cost. The operational-level model adds

considerations of operational functions and technology. The strategic level encompasses both of these

levels and further includes such elements as organizational mission and structure, industry and

environmental assessment, competition, product vision and value, and marketing. In this toolkit we

address all three of these levels.

Let’s revisit the business model framework we introduced in Section 2. In that section, we talked about

your problems and needs as a potential HIE customer. Now, we want to focus on the HIO as a supplier

of potential solutions for your needs. Understanding the HIO’s business model helps you to assess the

fit between your needs and the way the HIO operates. We’ve already discussed technology; now we

move to structure and organizational strategy to evaluate possible HIO partners for your organization.


Structure and Organizational Strategy

Figure 10: Assessing HIOs Structure

HIE succeeds where the partners trust that their clinical and financial data will be treated with care.

“Engendering a sense of trust among participants in an HIO is also a key in assessing the likelihood of

success of an HIO.” “The culture, policies and procedures of the HIE regarding data usage must ensure

that no stakeholder will gain a competitive advantage at the expense of others.”32 Both of these points

address the mix of technology and relationships that are so critical to the success of HIE: just as the

software used by one organization must be able to speak clearly to the software used by another

organization, so the personnel from those organizations must trust the data they receive, and trust that

the data they send will be secured and used carefully and responsibly. Further, all of the organization

involved in HIE and/or in an HIO must trust that their goals and objectives are aligned, and that

everyone involved understands and support the uses to which each organization plans to put their

shared organization, technology and data.

There are many different variants of HIO, as they’ve been developed for a variety of purposes. The best

HIE/HIO solution will be one in which the HIO’s organizational purpose and strategy closely match the

goals and objectives you’ve developed with your stakeholders.

There are four major organizational structures for HIOs: not-for-profit, public utility, collaborative, and

for-profit.33 First, the non-for-profit structure is usually local and led by a governing body or members

with the right to vote. This type of HIO is often driven by their nonprofit healthcare charter with a focus

32

CHIME and eHI (2011). The HIE Guide for CIOs. http://www.cio-chime.org/HIEGuide/index.asp 33

Adapted from Deloitte Center for Health Solutions. Health Information Exchange (HIE) Business Models: The Path

to Sustainable Financial Success; 2006. Accessed Sept. 9, 2012.


on improved, quality, safety, and efficiency of patient care and lower health care spend per capita. Due

to its tax exempt status, this model of HIO has the ability to use philanthropy as a lever for sustainability.

Second, the utility structure is government regulated or directed. It provides a governance structure

that focuses on public accountability for private businesses. Since it is usually funded by government

sources there are tight fiscal controls. The utility model often uses subscription or transaction pricing.

Third, the collaborative structure involves multiple stakeholders and is led by representatives of

collaborating organizations. The emphasis is on shared goals and mutual benefit and such collaboratives

are often jointly funded. Finally, the for-profit model is led by board of directors (shareholders). For-

profit HIOs strive for ROI-driven investments and focus on optimizing their owner’s strategic goals and

profitability. They are often privately-funded.

The HIMSS HIE Evaluation Checklist provides a handy tool for assessing the organizational structure and

governance of any HIOs you are considering.34 Among the considerations you’ll want to take into

account are the legal status, make-up of the governing body, and opportunity for stakeholder

participation in decision-making and commitment. The HIMSS will help you ask the right questions and

rate the answers provided by the HIO.

You and your stakeholders know the most about the needs of your local community; any HIO you work

with should seek and welcome your input about those specific needs. Looking at the level of

commitment from existing stakeholders is one way to assess the strength of support for the HIO and its

technology.

The HIO should also have a strategic plan that lays out both the vision and the concrete steps the HIO

will take towards achieving the goals and the measurable objectives. Below is an example of a strategic

statement linked to a broad goal, more specific objective, and the outcome expected.

34

HIMSS (2009). HIMSS Guide to Participating in HIE.

http://www.himss.org/files/HIMSSorg/content/files/2009HIEEvaluationChecklist.pdf, Accessed Sept. 29, 2012.


Table 3: Strategy Statement

Strategy Statement Goal Objective Outcome

Lab Results will be shared

in the local community

among providers

Hospital and

independent lab results

will be shared with any

treating provider

Lab results are to be

shared in a manner that

achieves meaningful use

within the next three

months for all providers

with a Certified EHR.

The HIE will prioritize

the interface

development of Lab

results to the top

requesting provider.

As in this example, the strategy should relate the technology solution to the use case needs with defined

outcomes. You’ll find additional samples of measureable outcomes and strategies in the AHRQ HIE

Evaluation Tool Kit35. You can further assess the HIO’s strategies to see if they match up with your

priorities, timelines and budget.

Finances

Figure 11: Assessing HIOs Finances

A review of the HIO’s finances, business plan and success is critical to ensuring a long term, financially

strong partner. A sustainable HIE is one in which “The costs and benefits of the HIE are aligned such

that, once established, the HIE will be funded through mechanisms that reflect the advantages that are

35

AHRQ (2009). Evaluation Toolkit.

http://healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources/919/health_information_exc

hange_(hie)_evaluation_toolkit/27870


accrued from HIE rather than through extraordinary sources.”36 The three major components to a

financial model that are inherent in this definition of sustainability are 1) capital including startup and

ongoing investment, 2) operating cost including direct costs, overhead, and cash flow, and 3) revenue

including earned and unearned income.

Revenues can include earned and unearned income. Typical sources of unearned income are funding

from primary customers, funding from stakeholders, government grants, private foundation grants. For

many HIOs that have not yet achieved sustainability, grants are the source for the bulk of both capital

and operating costs. This should be a red flag to potential customers and warrants a careful review of

the business plan for achieving sustainability. These unproven HIOs should be viewed with caution.

You’ll want to ask questions like, Do the sources of income and expense appear to match with the

priorities of the stakeholder organization? Is there a rationale for the revenue mix between grants and

user fees? Is it clear what is included in the cost of membership and what is to be provided by the

stakeholder for successful planning and implementation of the HIE? Does the financial strategy include a

clear return on investment (ROI) or a well-documented business case for current participants?

Earned income (aka revenue) from the HIO’s perspective translates to pricing from your perspective.

There are some typical pricing structures that include membership fees, transaction fees, service fees,

service contracts, and affiliate revenue (e.g., commission on sales of software or services from other

parties).

When an HIO provides you with prices, the basis of each price should be clearly identified, and should

include detailed examples of what is included in the fee and what is not. A pricing comparison template

is available in Appendix H. You can ask each vendor to fill out this template so that you can compare

costs easily, and can clearly see for which services you’ll need to pay separately.

The financial section of the HIMSS HIE Evaluation Checklist will help you work through a careful

consideration of the HIO’s long-term planning, contingency planning if the organization fails or is

purchased, and other factors related to access to appropriate technology and to the longevity of the

36

Health Information Exchange Economic Sustainability Panel: Final Report. (April 2009): National Opinion

Research Center at University of Chicago.


organization.37 With this information and the tools provided you will be able to determine if an HIO is

financially stable and to see the full costs of participation.

Operations

Figure 12: Assessing HIOs Operations

Operations of HIOs include both the services offered and the infrastructure and processes by which

those services are provided.

Products and Services of the HIO

Another factor influencing your choice of which kind of HIO you want to work with is which services are

provided by the HIO versus the ones your organization will need to provide. Understanding what kinds

of features an HIO might offer will help you evaluate different organizations. A HIMSS survey has

identified the most common categories of exchange services offered by HIOs: interoperability and

master patient index (73% each), data querying, secure messaging, clinical summaries, and standards

harmonization (65% each) and public health and quality reporting to a lesser extent (27-35%).38

37

HIMSS (2009). HIMSS Guide to Participating in HIE.

http://www.himss.org/files/HIMSSorg/content/files/2009HIEEvaluationChecklist.pdf, Accessed Sept. 29, 2012.

38 HIMSS (2011). Common Practices Survey.

http://www.himss.org/content/files/HIE/HIE_CommonPractices_2011_survey.pdf , Accessed Sept. 10, 2012.


You assessed the needs of your organization by using the tools in Section 2. This inventory of needs will

also help you determine what capabilities to look for from an HIO. Again from HIMSS, common

capabilities include: lab results (81%), discharge summaries (70%), radiology results (65%), clinical notes

(62%), medication summary (54%), viewer/portal (49%), emergency visit documents (49%), public health

(43%), and ePrescribing (41%).39 A small number HIEs are also leading the way in providing patient

engagement services. According to the 2011 eHealth Initiative survey, 31 HIEs support patient

authorization of data sharing, 17 HIEs support audits of access, 15% offer access to educational

information, 12 allow patient review of health data, and 10 support downloading of health data.40

Once you understand what each HIO offers, and how and where the HIO has implemented its

technology, you’ll be able to contact the HIOs reference clients to get more information to help you

evaluate these potential partners. Among the topics you’ll want to discuss with those reference clients

are the product maturity, the workflow, the system requirements, the ability to share data among

providers in the community, and the HIO’s staffing. You’ll learn more about the selection process in

Section 7 of this Toolkit.

In the remainder of the operations section, we will cover the important aspects of operations you

should review as you explore HIOs as potential partners.

General Procedures

A fully functioning HIO should have established policies and procedures for the integrating the data from

new providers into the HIE technology. Formal committees reporting to the Governing Board should

provide oversight of implementation policies, which should include strong privacy and security

guidelines. The HIO should provide you with written policies outlining how users are identified and

authenticated, and the HIO should provide staffing adequate to support the ongoing operations of the

organization.

39

HIMSS (2011). Common Practices Survey.

http://www.himss.org/content/files/HIE/HIE_CommonPractices_2011_survey.pdf , Accessed Sept. 10, 2012. 40

eHealth Initiative 2011 HIE Survey.


Privacy and Security Policies and Procedures

Falling under the rubric of privacy and security is one of the most complex issues you’ll face in

implementing HIE: How is the consent to use and disclose protected health information managed? Make

sure your potential HIO partner provides very explicit documentation of these procedures, and that the

technology the HIO uses is capable of supporting those procedures. Your assessment will be aided by

the provisions of the laws governing the use and disclosure of personal health information in California:

1) The HIPAA Privacy and Security Rule (45 CFR Part 160 and Part 164 Subparts A, C & E), and 2)

California’s Confidentiality of Medical Information Act (CMIA—Cal. Civ. Code §§ 56–56.37). Making sure

that you understand how the HIO treats these laws will be a strong component of the trust you have in

the organization.

The CMIA rules apply when there is no HIPAA regulation on an issue, or when California law is more

stringent than the HIPAA rules. For example, providers must follow HIPAA’s rules about the provider

needing to notify patients of their privacy rights, because the California law does not require this. Rural

and broadband communities will need to pay special attention to the use of “de-identified” data

because when there is a smaller pool of participants traditional methods of de-identification may not be

sufficient to ensure proper privacy. You might want to craft a specific use case to evaluate how an HIO

deals with sensitive health data exchange to gain insight into the management of this important area by

the HIO(you can start with our use case number 3 above and add details specific to your organization.)

There are two excellent resources for in-depth information about privacy and security in HIE: The AHRQ

Privacy and Security Solutions for Interoperable Health Information Exchange41 and the National Rural

Health Resource Center’s Health Information Exchange Policy Matrix.42 Ensuring the HIO you are

reviewing has up to date Privacy and Security Policies is paramount to protecting your interests.

Risk Management

A risk management plan is essential to the long term sustainability of the organization. Evaluation the

risk management capabilities of an HIO will help you understand the organization’s depth of experience

41

Dimitropoulos L (2007). Privacy and Security Solutions for Interoperable Health Information Exchange, Privacy

and Security Assessment of Variation Toolkit. http://healthit.ahrq.gov/portal/server.pt/community/ahrq-

funded_projects/654/outcomes_from_the_privacy_and_security_solutions_for_interoperable_health_informatio

n_exchange_project/24069 42

Health Information Exchange Policy Matrix. National Rural Health Resource Center.

http://www.ruralcenter.org/rhitnd/hie-toolkit


and knowledge and is an indication of reliable organizational processes. These questions from that

HIMSS HIE Evaluation Checklist highlight some of the issues you’ll want to consider:

• Is liability shared by all involved?

• Are there existing data use/sharing agreements in place?

• How is intellectual property protected?

• Is there a compliance officer?

• How are HIPAA, state and institution-specific policies implemented?

• Have the ARRA-related HIPAA changes been implemented?

The HIO’s strategic plan should include a risk analysis component. If they don’t, you can use the

questions above to determine their strategy for managing risk. The HIO will survive longer if they are

prepared for addressing risks. An HIO that has already been in operation for longer than others has

probably already shown some agility in this area; you can ask for specific examples of risks they’ve

encountered and how they’ve dealt with them. In particular, ask about how they would handle any risks

you’ve identified for your organization.

Customers and Market

For an HIO to be successful, it needs to spread the cost of expensive technology across many users, so

an HIO that has a larger pool of local participants is generally a more attractive partner. Similarly, an HIO

with a richer data set from its medical partners will be able to provide more valuable clinical analysis to

any given provider. For rural communities, identifying the customers of the HIO that are also medical

trading partners should heavily influence the decision to participate. You’ll want to get specific

information about which of the HIO’s customers have already implemented the technology, and which

are still in the planning stages. It’s particularly important to assess if the HIO has a sufficient market base

of data to support transitions of care.

Stakeholder Engagement

An additional area of interest is the HIO stakeholder/customer engagement process. Understanding the

approach to engaging and retaining stakeholders is an indicator of how the organization will retain the

proper leadership for long term sustainability. This is often linked to governance and oversight issues

discussed in prior sections. The HIO should have a demonstrated process for stakeholder engagement.


Early engagement of the providers is critical in the long term success and sustainability of an HIO.43

Successful HIOs will have not only strong financial management and experienced leadership, but also

committed stakeholders in an open and transparent process.

Once education and solutions mapping are completed, stakeholders will remain engaged as long as their

internal priorities are being monitored, reported and acted upon by the HIO. The Review and Report

process identified in the stakeholder diagram is essential in maintaining the “momentum” of HIE

activities and value to the participants. As Mr. Merritt identifies successful strategies deployed by HIOs

including44:

Establishment of an oversight committee with representatives from all three groups, as well as

representatives recruited from other community stakeholder groups, that held multiple forums

to promote ongoing discussions and resolve disagreements, which in turn allowed each group to

continue independent activities while staying focused on the overall HIE goals.

A strong stakeholder engagement process should be evident in the HIO when you are reviewing their

business operations. In particular for rural providers, specific goals and objectives and engagement of

experienced rural stakeholders is a requirement for successful HIOs.

Communication and Marketing

A successful HIO will have in place a communication and marketing plan to educate the community,

including patients, about the value of HIE. This communication and marketing plan should focus on

ensuring that both providers and consumers understand the HIO’s plans and trust the implementation

process. Look for a well thought out website, education sessions and materials that are ready for

distribution.

If there is an HIO that seems to fill your needs, proceed to Section 8 for tips on requesting a proposal.

There may not be an adequate HIO partner for some communities, in which case you may need to

consider developing internal HIE capabilities or creating an HIO. The California Health eQuality’s HIO

Development Toolkit is an excellent resource for creating an HIO from the ground up.45 This resource

43

Perna G, (2011). The Value of Early Stakeholder Development, Health Care Informatics, October 2011 44

Merritt D, Best Practice Guide for Stakeholder Engagement, Center for Community Health Leadership, 2005 45

Dennis L, (2012). HIO Development Guide. California Health eQuality, UC Davis Institute for Population Health

Improvement.


guides you through the step by step process of needs analysis, planning, stakeholder involvement, and

development and provides a wealth of tools and templates to assist you along the way.

http://www.ucdmc.ucdavis.edu/iphi/Programs/cheq/resources/CHeQ%20HIO%20Development%20Guide%20121

212.pdf


Section 8 Requesting HIO proposals

The process of selecting a vendor is as important as the final decision itself because inviting stakeholders

into the selection process is the first step in establishing the trusting relationships that will be so critical

to the success of the partnership. Your selection process might look like this:

1. Identify and empower a project manager to organize the RFP process and facilitate the final

decision-making.

2. Enlist a trusted advisory committee of community leaders with different disciplinary

backgrounds to give input throughout the Request for Proposal (RFP) process. This committee

should include practicing clinicians who will use the tools, technical experts who will be involved

in the implementation, practice managers, and patients or patient advocates. An advisory

committee should be large enough to represent the perspectives of important stakeholder

groups, but not so large as to make the coordination and logistics onerous.

3. Develop use cases, a general budget and high level agreement on technology needs. A detailed

list of features related to your use case will help ensure that an HIO can respond appropriately.

This tool is available in Appendix J.

HIE Features Can't do

Can but

Limited

Can

Meet Exceeds

1. Clinical Messaging 0 1 2 3

1.1

Demonstrate the workflow for a primary care physician to pull the demographic and allergy

information from the HIE and how it would be received (for incorporation into the physician’s

EMR prior to the visit). Is it discreet data or in a CCD or both? If

1.1.1

Access method used?

- Provider portal

-EMR

1.1.2

Log-in process used?

-Separate log-in

-Single signon

1.1.3

How is patient found in system?

-Name search

-MPI

-Other approach

1.1.4Is source of information clear?

- Which provider supplied the information?

1.1.5

Is allergy data?

-In text format

-Discrete

-In a database

-From a CCD

4. Modify an existing RFP such as the example provided in Appendix K. Your goal here is to identify

any use cases that are particular to your organization or community. To ensure that responses


to your RFP help streamline the process, make it simple and include a page limit for the

responses.

5. Develop an evaluation tool with numeric outcomes based on the selected RFP. The most

important part of this step is to make sure that your evaluation focuses on the key value drivers

for your community. For example, consider a rural community that relies on broadband

technology, needs to support access to specialty providers and wants to coordinate patient care

management plans with limited local resources. The evaluation tool should focus on features of

the technology and or operations specifically identified to address these issues. You’ll want to

have a very clear and well-documented process in case your choice is later questioned.

6. Establish a timeline for distributing the RFP and getting responses – long enough to allow for

thoughtful responses, but not so long the process bogs down. Identify a single point of contact

for questions. Document this part of the process as well so that you can share it with your

governing board.

7. The advisory committee compiles responses, evaluates and selects the top three to five HIOs for

further due diligence.

8. Ask each vendor to demonstrate the product using your use cases. Use your evaluation tool to

score each presentation. (You’ll find sample tools in Appendix I: Use Case and J: Rating Tool.) It

is critical that the vendor complete the use case demonstrations with their live system instead

of marketing materials or canned demonstrations. You might want to open these

demonstrations to as many community stakeholders as are interested so that you can factor

their input into your scoring.

9. Prepare evaluation scores, conduct reference checks and schedule an onsite visit to one of the

clients of your two top HIOs. The visit team should include a clinician, a business manager, and a

technical expert. Remember to consider a match with your values and goals, the potential for a

trusting relationship, the technology offered, the potential financial and other benefits, and your

experience of working with the vendor’s staff.

10. Begin contract negotiations.


Conclusion

Decision making regarding HIE begins with determination of the business problems and needs facing

providers and healthcare organizations. By identify specific solutions to meet those needs and

addressing the business case, providers can decide if HIE is the right strategy for meeting their needs.

New HIE technology can help providers and communities achieve many healthcare goals that might have

been previously unattainable in an unconnected environment. HIE supports interoperability, multi-party

communication, and collaborative workflows that are cornerstones of the new models of care emerging

to improve quality, efficiency and cost of healthcare. With the increasing bandwidth and access to

broadband in rural and underserved areas, HIE becomes more attainable for all providers and

communities. This toolkit provides tools and guidance to engage stakeholders and make the decision-

making process clearer and more effective for providers and communities as they consider adopting HIE

and selecting HIO partners.

hie toolkit for provider decision making - calhipso

Documents