Archive for the ‘Health Information Exchanges (HIE)’ Category

Technical Foundations for Accountable Care – Part 1

This posting is part one of an article about the IT infrastructure requirements for ACOs; I explain how data collection works today in traditional HIEs using XML CCD documents (i.e. HITSP C32), and why this is insufficient for care coordination purposes required for accountable care. The full Whitepaper is published here.

In the last few years, Healthcare information technology has evolved quite dramatically.  In 2000, merely 12 years ago, Electronic Medical Record (EMR) adoption across the U.S. physician population was reported to be around 18%, while numbers from 2011 suggest more than 55% adoption (Jamoom et al., 2012).  Now that more data are collected electronically, they can be analyzed, aggregated, and shared, giving rise to many new clinical and financial opportunities, especially in the support of coordinated care.  However, current health information exchange infrastructure using Continuity of Care Documents (CCD) are insufficient for event based, episodic healthcare to evolve towards a more holistic and accountable system that emphasizes prevention and quality improvement.  This white paper explains the limitations of current infrastructure, and proposes a registry platform approach to support next generation of Healthcare.

A performance based Accountable Care Organization (ACO) model requires an extensible, interoperable, and sophisticated IT infrastructure to track patients, providers, and their relationships to promote coordinated care and measure quality improvements.  The proliferation of EMR systems and the widespread adoption of integration technology and standards is helpful, but they alone are not sufficient to aggregate, coordinate, and contextualize the abundant, disparate data exchanged across the ACO community.

The ACO environment is comprised of multiple constituents, some of which are new to the real-time exchange of data.  The landscape represents a range of technical capabilities, distinct data sets, and varying levels of data quality.  Connecting the information systems among such varied participants can be a tedious undertaking, but the task is certainly achievable, especially if common messaging formats and interoperability profiles are utilized.

However, transferring data from one application to another is now merely a first step in the transformation towards accountable care.  The next step is to achieve semantic interoperability to ensure data are exchanged in regards to the same “entity”, such as a patient, provider, or code set.  And to realize full ACO benefits, the technology infrastructure must be able to identify, organize, and correlate data into clinically useful analytics for decision support, care coordination activities, and intelligent referral management.  In the absence of a single system to orchestrate this data aggregation, a platform of healthcare registries can create the framework to deliver a comprehensive and coherent view of information and enable the data management goals of accountable care.

Quality of Care in the United States

The Institute of Medicine (IOM) indicates that quality of care issues in the United States healthcare system cause a high number of avoidable deaths, complications, and associated direct- and indirect costs (Kohn, Corrigan, & Donaldson, 2000).  As a result, the United States performs poorly among a panel of developed nations with regard to clinical outcomes and mortality rates, while at the same time producing the largest increases in cost (Peterson, 2007).

In the same report, the IOM (Institute of Medicine, 2001) recommends “coordination of care across patient conditions, services, and settings over time” which includes:

  • Continuous healing relationships
  • Customization [of care plans] based on patient’s needs
  • Patient as source of control
  • Shared knowledge and free flow of information
  • Evidence based decision making
  • Anticipation of needs
  • Continuous decrease of waste
  • Cooperation among clinicians

These findings about cost and quality motivated unprecedented government programs to invest in the modernization of healthcare IT.  For example, the ARRA/HITECH act offers financial incentives for providers who invest in EMR/EHR infrastructure that complies with certain requirements for interoperability, privacy, and security (Stark, 2010).

Traditional EMR systems, however, are considered “information silos”, that is, the data they maintain are coded in a proprietary format understood only by that particular EMR vendor’s systems.  In an effort to expand the enterprise value from these EMRs, policies like Meaningful Use (MU) were enacted, but ultimately, the policies only require that information is made available, not meaningfully organized.  There is no inherent need or incentive (Porter and Teisberg, (2004) for providers in a Fee-For-Service world to spend time sifting through vast amounts of largely redundant data to discover nuggets of useful information.

The Accountable Care Organization


The concept of an Accountable Care Organization (ACO) is to improve quality through coordination of care across patient conditions, services, settings, and time, and to align financial incentives for participating providers and payers.  Organizations agree that spending more energy on disease prevention and the prudent management of continuous diseases will eventually reduce the need for costly emergency care and hospitalization.  And they also accept that coordinating the various components of care can eliminate waste and redundancy.

Early results from various ACOs formed between private payers and regional ambulatory and acute care providers reported significant cost savings and quality improvements.  But the results also showed that many organizations are not ready to participate in ACOs (Higgins, 2011) because they lack the infrastructure to support the information requirements of risk assessment, care transition management, and care plan development for prevention and early detection.

ACOs need IT infrastructure to do more than just share vast amounts of redundant information. They need IT to uniquely identify content, ensure accurate patient matching, and aggregate data so that participating providers can actually use the information to make evidence based clinical decisions.

Fee-For-Service Information Processing


In a Fee-For-Service (FFS) model, information systems are used to document and reference episodes of care.  The primary information system used in the FFS model is the EMR, and there are hundreds of EMR vendors offering their unique application.   Patients who visit a primary care physician can have their data recorded in a local EMR system, as long as they consent to the electronic storage and sharing of protected health information (PHI).  Typically, that EMR system uses an internal code set to record demographics (D), known problems (P), medications (M), allergies (A), and diagnoses (P). If and when the same patient returns to the same Physician, the EMR is used to access the patient’s historic data as well as any data added in the interval.

However, if the patient visits a different Physician at a different facility, the EMR system with the patient’s medical data may not be available.  But if the Providers participate in a Health Information Exchange (HIE), it may be possible to access the patient’s information in the local EMR.  In an HIE environment, applications and systems and are connected through an information exchange that most likely uses Integrating the Healthcare Enterprise (IHE) standards for cross community document sharing, abbreviated as XDS (Integrating-the-Health-Enterprise, 2007).

To maintain consistency across systems, the well-defined Continuity of Care Document (CCD) [1] has been chosen as the mechanism to share patient data.  For each episode of care, whether it is an ambulatory consultation or an acute care hospitalization, a CCD is created that contains a summary of the event, such as the patient’s current demographics, blood pressure, lipid panels, prescribed medication, etc.  Every CCD is registered in the HIE XDS Registry, an XML repository with web-service access in a so-called ‘affinity domain’ (IHE, 2007).  Reviewed together, multiple CCDs can recount a “history” and illustrate the progression of an illness and its treatment.

Continuity of Care Document Contents


Given an episode of care for a new patient, the published CCD summary record could be described as   C1 = [D1, P1, A1, M1], where:

  • D1 – patient demographics like name, address, local MRN and other identifiers
  • P1 – a description of a diagnosis coded in a clinical Terminology such as ICD10 or SNOMED
  • A1 – a reported allergy in free text
  • M1 – a prescription coded in RxNorm

If the patient visits the same provider and another diagnosis P2 and prescription M2 are added, the CCD for that visit would contain:

C2 = [D2, P1, P2, A1, M1, M2]

If these CCDs are published to an IHE XDS.b compliant registry in the HIE, they are registered under a unique patient identifier, commonly referred to as an EUID.  The EUID is assigned by an Enterprise Master Patient Index (EMPI) service when patient demographics are registered for the first time.  To assign the EUID, the EMPI evaluates the demographic components of the CCD against known patient identities within the registry.  A sophisticated EMPI can incorporate many different demographics data fields into the evaluation.  So when C1 is registered, D1 is evaluated, identified as a new record, and a new EUID is issued and cross-referenced with the local MRN contained in D1.  When C2 is registered, the EMPI can use the cross-referenced MRN contained in D2 to identify the patient’s already existing EUID.

Other systems connected to the HIE, such as EMR, Radiology, and other specialty systems, can also use the information contained in the EMPI.  For example, during a typical patient registration, the registration system could search the EMPI first, instead of automatically creating another local MRN which increases the probability of fragmented patient information.  The EMPI evaluates the search criteria against known patients, and responds to the registrar with a list of likely matches with their associated EUIDs.  This query / response web services transaction, known as “Active Integration”, is described in the IHE XDS.b framework as Patient Demographics Query (PDQ) (Integrating-the-Health-Enterprise, 2007).  An external system could also send the local MRN only to the EMPI, and if the MRN already exists, the EMPI would respond with the cross-referenced EUID.  This query / response web services transaction is known in IHE XDS.b as Patient Identifier Cross Referencing (PIX) service.

CCD Workflow Issues

Let’s assume that when C1 was registered, a new EUID 47111996 was issued by the EMPI.  When C2 is published, it is registered under the same, now existing, EUID.  If D2 of C2 contains additional or different information compared to D1 of C1, such as a new address or additional phone number, the EMPI will update the demographics information for the patient.  A sophisticated EMPI keeps a record of all changes to increase the likelihood of successful PDQ queries, even when they are based on outdated data.

If the physician ordered a lab test during the second consultation, the lab could publish results directly to the HIE, noted here as L1, resulting in:

C3 = [D3, L1]

When the physician imports these lab results into a local EMR, using them to identify a new problem, the EMR would publish:

C4 = [D4, P1, P2, P3, A1, M1, M2, L1]

If the lab results suggest that the initial diagnosis expressed in P2 is wrong, the EMR would publish:

C4’ = [D4, P1, P3, A1, M1, M2, L1]

When the patient goes to see a new provider, a specialist for example, that provider could query the HIE and would see the following content:

C1 = [D1, P1, A1, M1]

C2 = [D2, P1, P2, A1, M1, M2]

C3 = [D3, L1]

C4 = [D4, P1, P2, P3, A1, M1, M2, L1] or C4’ = [D4, P1, P3, A1, M1, M2, L1].


The provider has a few options to review clinical data.  Content can be retrieved and viewed in a portal solution, or data can be imported into a local EMR if the provider is interested in doing so and the HIE offers out-bound data integration.  In the case where the Provider imports C4’ into a local EMR, but chooses not to import the lab result, and then identifies a new problem for the patient and prescribes new medication, then C5 = [D5, P1, P3, P4, A1, M1, M2, M3,] will be published.

The content of the HIE for EUID = 47111996 will now reflect:

C1 = [D1, P1, A1, M1]

C2 = [D2, P1, P2, A1, M1, M2]

C3 = [D3, L1]

C4 = [D4, P1, P2, P3, A1, M1, M2, L1] or C4’ = [D4, P1, P3, A1, M1, M2, L1]

C5 = [D5, P1, P3, P4, A1, M1, M2, M3,]

In the context of Accountable Care, this information model has several problems.  As one can see, CCDs contain a lot of redundant information.  The difference between C1 and C2 is only P2 and M2, but in the lengthy document, it might take a while to identify those differences. By the time C4 is published, M1 might not be current anymore.  If a Physician sees both C2, C4’ and C5, can they safely assume that P2 is obsolete? Should they only import the most recent CCD, in this case C5?  But if they do so, they would lose the L1 information contained in C3, and P2 information contained inC2.

When the goal is to analyze patient information for gaps in care so that preventive care actions can be developed, the redundant, incomplete, and unclear information contained in CCDs presents a significant challenge.

Laboratory Results and Medication Mapping

Some HIEs will store laboratory results as discrete data, preserving the original terminology.  Some EMRs can import such original data to be utilized by built-in decision support tools.  But not all HIEs are capable of discrete data export.  Even if data are stored discreetly, and could be imported into a local EMR, it is still necessary for the local EMR to parse the data.  If L1 is coded in a proprietary format not known to the local EMR, the data are rendered useless for the EMR.  It would be more useful to map proprietary data to LOINC®[2], and store the equivalent LOINC terms, so that all systems retrieving data could utilize the content.

The same problem applies to medication data.  Since different EMRs use different terminologies to describe drugs, CCD entries need to be mapped to RxNorm[3].  In this way, local EMRs importing data from the HIE could identify potential drug-drug effects and issue alerts, as would be the case if prescription M3 conflicts with M1 or M2.

[1] CCD, Continuity of Care Document is a HL7 CDA document format; In ARRA/HITECH legislation it is referred to as HITSP/C32 and HITSP/C83

[2] LOINC: Logical Observation Identifiers Names and Codes,


Meaningful Use criteria and Healthcare IT Infrastructure

This is another excerpt from my class on Healthcare IT Infrastructure. Analyzing the Final Rule for Meaningful Use of Healthcare IT for implications of Infrastructure:

Healthcare IT is currently undergoing an unprecedented rebuilding process. The paper chart used in the past, and the EMR that replaced it, were focused on recording episodes of care for one provider with one patient. Each episode of care contains Problems (usually the reason someone uses medical care), Medications, Allergies, Lab-Tests and other notes, usually organized in a hierarchical data model.

The government provides with ARRA/HITECH incentives to reshape the EMR into an EHR, which includes interoperability – meaning that data needs to be exchanged with other care providers, payers, and public health agencies. This has massive implications on the IT infrastructure of providers, because now clinical data (not only claims data) needs to be submitted securely with other providers, and even electronic access by patients is required.

Healthcare IT managers have to rebuild infrastructure right now in unprecedented scale and complexity, all while having to adhere to extended HIPAA Privacy and Security rules.

Here is a comprehensive overview of Objectives and Measures for Meaningful Use for Eligible Providers (EP) based on the Final Rule published in July 2010[1]:


Objective Measure Infrastructure
1.     CPOE: Use computerized provider order entry (CPOE) for medication orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines. … more than 30 percent of all unique patients with at least one medication in their medication list seen by the EP have at least one medication order entered using CPOE. Data entry at the point of care (mobile access); EMR with CPOE capability;
2.     Implement drug-drug and drug-allergy interaction checks. The EP has enabled this functionality for the entire EHR reporting period. Use of medication information source such as FDB or Medispan with online updates
3.     Maintain an up-to-date problem list of current and active diagnoses. More than 80 percent of all unique patients seen by the EP have at least one entry or an indication that no problems are known for the patient recorded as structured data. Create CCD (structured XML) record with coded problems (ICD9/ICD10), HITSP C32
4.     Generate and transmit permissible prescriptions electronically (eRx). more than 40 percent of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology. Connectivity with RxHub and coded medications
5.     Maintain active medication list. More than 80 percent of all unique patients seen by the EP have at least one entry (or an indication that the patient is not currently prescribed any medication) recorded as structured data. Create CCD with Problems, Meds & Allergies
6.     Maintain active medication allergy list.
7.     Record all of the following demographics:

(A) Preferred language.

(B) Gender.

(C) Race.

(D) Ethnicity.

(E) Date of birth.

More than 50 percent of all unique patients seen by the EP have demographics recorded as structured data. Part of CCD
8.     Record and chart changes in the following vital signs:

(A) Height.

(B) Weight.

(C) Blood pressure.

(D) Calculate and display body mass index (BMI).

(E) Plot and display growth charts for children 2 – 20 years, including BMI.

… more than 50 percent of all unique patients age 2 and over seen by the EP, height, weight and blood pressure are recorded as structured data. EMR/EHR functionality.
9.     Record smoking status for patients 13 years old or older. …. more than 50 percent of all unique patients 13 years old or older seen by the EP have smoking status recorded as structured data. EMR/EHR functionality
10.  Report ambulatory clinical quality measures to CMS or, in the case of Medicaid EPs, the States. …successfully report to CMS (or, in the case of Medicaid EPs, the States) ambulatory clinical quality measures selected by CMS in the manner specified by CMS (or in the case of Medicaid EPs, the States). Requires in many cases that data is off-loaded to RDBMS for processing and reporting
11.  Implement one clinical decision support rules relevant to specialty or high clinical priority along with the ability to track compliance with that rule. Implement one clinical decision support rule. EMR/EHR functionality which requires data entry at the point of care
12.  Provide patients with an electronic copy of their health information (including diagnostics test results, problem list, medication lists, medication allergies) upon request. … more than 50 percent of all patients who request an electronic copy of their health information are provided it within 3 business days. Requires patient portal with secure access to structured data and export, usually as CCR
13.  Provide clinical summaries for patients for each office visit. …clinical summaries provided to patients for more than 50 percent of all office visits within 3 business days. EMR functionality
14.  Capability to exchange key clinical information (for example, problem list, medication list, allergies, and diagnostic test results), among providers of care and patient authorized entities electronically. Performed at least one test of certified EHR technology’s capacity to electronically exchange key clinical information. Requires ability to store structured data in a CCD/CCR (CDA2, XML) and web services for patient identity (PIX/PDQ), Provide and Register, and retrieve document sets.
15.  Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process. Implement technical, physical, and administrative safeguards.


More details are in the text of law (42 CFR, see above) or here:

Let me highlight a few infrastructure consequences of the Meaningful Use (MU) guidelines:

  • Data has to be captured in structured format. Structured means (a) not paper and (b) not in a text document, but essentially in a CCD or CCR. CCD and CCR are based on HL7 CDA2, which itself uses XML for a hierarchical, structured continuity of care record/document in structured format (Dolin et al, 2006). For MU, a specific derivative has been specified and standardized as HITSP/NIST C32,  ( As a consequence, all EMR vendors have to update their software to add these features to their software, so their clients can meet MU. That also meets that hundred thousands of providers have to undergo major software release upgrades, or implement electronic medical records for the first time.
  • Section 10 (Quality Reporting) means that Providers need to be able to generate reports across their patient population for epidemiological purposes and report data. Traditional MUMPS databases struggle with reporting across the branches of their tree, but newer versions like Cache either provide SQL interfaces, or provide ETL tools to download into a Datawarehouse (DWH) for reporting purposes. This is of course troublesome for a single provider.
  • Section 12 (Patient Portal) requires Patient access to electronic health information. This is difficult for providers with traditional stand-alone EMR systems, but many SaaS style EMR offerings have emerged, providing Personal Health Record (PHR) access along with the EHR.
  • Section 14 (Health Information Exchange) requires the capability to exchange clinical data with others Providers. HL7 messages are insufficient for this, because traditional HL7 messages have document types for unstructured data (HL7 MDM). For the exchange of structured documents like CCD or CCR, it is necessary to build a web services infrastructure such as IHE ITI XDS.b ( ).
  • Section 15 (Data Security) re-emphasizes that all this needs to happen under the HIPAA framework.  45 CFR 164.308(a)(1), which is referred to in section 15, is of course the HIPAA Privacy and Security rule ( This constitutes a challenge in combination with all the other requirements, because the cross provider access allows providers from outside the organization to access documents, but still requires maintaining access controls and auditing in accordance with the law. As we discovered since 1996, it was already difficult to achieve compliance within a single organization – now this compliance needs to be extended to Health Information Exchanges.

Dolin, R., Alschuler, I., Boyer, S., Beebe, C., Behlen, F., Biron, P., et al. (2006). HL7 clinical document architecture, release 2. Journal of the American Medical Informatics Association, 13(1), 30.

[1] United States Department of Health and Human Services, Centers for Medicare & Medicaid Services, 42 CFR Parts 412, 413, 422 et al., Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule, online at

Building an interoperable Health Information Exchange

Building an interoperable Health Information Exchange
The federal government declared in the American Recovery and Reinvestment Act (ARRA) of 2009 [1] its intent to fund significant investments necessary to built an interconnected health information exchange (HIE) in the U.S., with the goal of quality improvement and cost containment [7]. In recent years there have been many attempts to built regional HIE, often called RHIOs, but most of these RHIOs failed after they exhausted their initial government funding [2]. Reasons for RHIO failure were both economic, with unsound business plans and monetization models [6], and technical. Learning from the failures of the last decade, a successful approach must provide both a sound financial model for all participating parties, and incorporate proven components into a scalable, secure, extensible and standards oriented architecture. This essay describes at a high level some of the critical components required for building an interoperable HIE.
HIE exchanges allow health data exchanges between various organizations and thus different information systems. Given the sensitive nature of health care information, data privacy has to be maintained throughout such a federated information system in compliance with HIPAA , requires an auditable log of every passive or active data access. In order to fulfill both the regulatory and functional requirements, the following core elements are required:

– Communication adapters that allow data extraction from existing legacy applications such as Electronic Medical Record systems (Providers) or Claims Data Repositories (Payers), usually implemented in a service oriented architecture (SOA). This is achieved by tagging data elements in feeder systems against a common data standard. A template for a common data architecture is HL7 CDA2 [4]. ANSI developed with HITSP specific work flow profiles for common tasks in the provider environment [3]. Complexity of peer-to-peer communication and the requirement of interfaces would grow  , in which n represents the number of information systems connected to a HIE. In the approach to map against a common data template, the interface requirement is reduced to n, a significant reduction in complexity. If the HIE is implemented in multiple loci, interfaces can be re-used, further reducing complexity. Nevertheless, given that most current EMR implementations are proprietary and do not adhere to a standardized architecture, tagging data elements in proprietary architectures does represent a substantial technical and financial challenge in the creation of HIE.

– Master Data Management (MDM) systems that allow identification of unique person profiles across multiple information systems, even in the absence of a single, unique identifier. While some countries do have such identifiers, in the U.S. the use of the social security number is not permitted. However, identifying data belonging to the same person across multiple systems is absolutely crucial for both patient safety and cost containment purposes. Popular systems like Initiate or Quadramed are proprietary in nature and create vendor dependency. With Mural, there is a generic, open source technology available, which is however lacking healthcare specific adapters. However, since communication adapters are essential for the entire system, as discussed earlier, adapters could be used to extract person identifying information and utilize the interpolation capability of the Mural project.

– Record Locator Services track data sources for medical information. The combination of MDM and SOA allows extraction of data related to a specific person from their original record keeping system on demand, when required (ad hoc). In the proposed interoperable HIE the record locator service is implemented in a distributed fashion, thus eliminating single point of failure. Synchronization of the various, distributed record locator services would follow a propagation scheme analogous to Network Routers, which keep routing tables locally without a single point of failure.

– Repositories create data artifacts that are accessible outside of the original record keeping system. This approach is used to create a persistent subset of medical information with emergency information, such as allergies and medications. If the data is constantly updated by trusted sources, it can be used for medical purposes. If it is exclusively or substantially maintained by user input, it is only a consumer directed personal health record (PHR) without clinical application. An interoperable HIE should not contain a repository of all healthcare data, as such an approach would create significant, inherent scalability issues. Every data artifact would have to be constantly checked for accuracy, generating unnecessary information traffic. However, emergency subsets and medical images could and should be kept in a repository in order to achieve high service availability levels with fast response times, while more detailed data is exclusively kept in the original custodial system of record.

– Role management is used to define across the organizations connected in a HIE roles that are associated with data access rights, i.e. which types and to which extend data can be requested by authorized HIE users.  This is an important regulatory requirement, but also a helpful feature to streamline clinical workflow.

– Identity Management (IdM) is used in organizations to create auditable and traceable identities of system users that have certain rights to access or create/update information. It includes access management and single sign on, but also identity provisioning. While each organization within an HIE might have their own IdM solution, those individual solutions have to be federated in order to allow HIE wide access and provisioning. Federated systems create a circle of trust, in which access right and roles migrate with the access request across organizations. Besides the technical implementation of an IdM federation, it also requires audit logging and role definition across the participating organizations.

– Consent management as an extension to access management specific to healthcare privacy concerns. While normally access and role based access to information is sufficient, a specific consent management extension implements patient rights to restrict data access further, while propagating and tracking consented access. The new, extended privacy requirements of HIPAA expressed in ARRA2009 could make consent management mandatory.

– Clinical applications, such as Laboratory Data viewers, consolidated DICOM viewers, Medication records, and Clinical decision support systems. While all the aforementioned modules and systems are enablers of a HIE, the clinical applications are the return on investment. From a cost containment point of view, avoidance of redundant procedures is the direct measurable component. Provided that imaging procedures, for example, are a very rapidly growing cost factor in health care [5], access to recent imaging can both reduce cost and improve decision making. The same is true for laboratory test, albeit the per-procedure savings is smaller by an order of magnitude. Cost savings caused by redundancy avoidance is a major factor in Walker et al.’s value calculation [8]. Indirect cost savings are achieved by access to medication records, which can unveil medication compliance and avoid undesired drug-drug interactions. In recent implementations extending information to citizens also has become a desired feature, be it for prevention or disease management purposes.

It is important to note that working applications for all modules exist, eliminating the need for costly and risky development. However, significant integration effort is required to combine all functional elements to a seamlessly working, secure and scalable information system.

In conclusion, the experience of building RHIOs and HIE over the past decade has demonstrated the risks and challenges of a complex health data exchange, but it has also yielded components and experience that make it today substantially easier to architect working HIE. While the technical problem therefore seems manageable, the core issues of existing RHIOs remain financial viability and access to vast amounts of data that are not currently captured electronically. In recent years, payers have begun to address this gap by mining claims data for longitudinal medication and diagnoses information, which is further evidence that both commercial and public payers (such as Medicaid) should be critical stakeholders in any HIE project.
1.    111th Congress of the United States of America. American Recovery and Reinvestment Act of 2009 (ARRA), 2009.
2.    Adler-Milstein, J. and Jha, A. Fledgling firms offer hope on health costs. Harvard Business Review, 86 (3). 26.
3.    American National Standards Institute (ANSI). HITSP – enabling healthcare interoperability. ANSI ed., 2009.
4.    Dolin, R., Alschuler, I., Boyer, S., Beebe, C., Behlen, F., Biron, P. and Shvo, A.S. HL7 clinical document architecture, release 2. Journal of the American Medical Informatics Association, 13 (1). 30.
5.    Levin, D.C. and Rao, V.M. Turf wars in radiology: the overutilization of imaging resulting from self-referral. Journal of the American College of Radiology, 1 (3). 169-172.
6.    Miller, R.H. and Miller, B.S. The Santa Barbara county care data exchange: Lessons learned iHealth reports, California Health Care Foundation, 2007.
7.    Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D.W. and Middleton, B. The value of health care information exchange and interoperability. Health Affairs.
8.    Walker, J., Pan, E., Johnston, D., Adler-Milstein, J. and et al. The Value Of Health Care Information Exchange And Interoperability. Health Affairs, 24. 10.