Why and how does interoperability matter to our story? How does something as arcane as an eHealth standards framework make any difference to Mosa or to Grace?

Quite simply, we care about eHealth standards because we care about health. The ability to share health information among health system participants and stakeholders contributes to better care delivery and better health outcomes. Mosa’s health relies on continuity of care, over time and across different care delivery sites. Continuity of care relies on interoperability. Interoperability, as we will see, relies on eHealth standards.

Interoperability and the Five C’s

There are different types of eHealth standards. We can think of them in terms of the five Cs:

• Care guidelines. These are guidelines such as the country’s maternal care guidelines, or the Expanded Programme for Immunization (EPI), or the DOTS guideline for tuberculosis treatment.
• Content. Think of this as the list of “fields on a paper form,” such as the paper-based ANC form that a provider fills out.
• Coding. Think of this as the “allowable values” that would apply to a specific field on a form, such as the ISO 5218 specification for Sex: 0=unknown, 1=male, 2=female, 9=not applicable.
• Communication. This is message exchange standards such as HL7 or XDS.
• Confidentiality. This is the set of specifications for managing privacy, security, and patient consent; examples are web protocols and privacy profiles such as secure HTTPS, PKI, the BPPC profile of Integrating the Health Enterprise (IHE), and OAuth.^[1]

Interoperability Profiles: Reusable eHealth Building Blocks

Multiple standards are needed to support the telling of a health story like our story of Mosa and Grace. At this point it is useful to introduce the idea of an interoperability profile. Profiles are not standards, per se. They are better thought of as implementation guides. A profile defines how a set of standards can be used to execute coarse-grained tasks such as “retrieve Mosa’s information based on her ID” or “refer Mosa to the district hospital” or “save the information captured during Mosa’s ANC visit.” Standards-based interoperability profiles provide us with reusable eHealth building blocks that we can employ to operationalize our guideline-based care workflows, as shown in Figure 19.

There are a few important things to note about Figure 19. First, eHealth standards are developed by standards development organizations (SDOs) such as HL7, ISO, WHO, and others. These standards go through long, involved, international balloting processes, and it can be expensive to participate. Developing countries are typically under-represented on SDOs, with the notable exception of the WHO. The good news, however, is that the base standards (the bottom layer in Figure 19) are usually generic and applicable in any context (developed country or developing country).

Second, interoperability is achieved at the profile layer. To achieve interoperability, there must be agreement about which standards will be used and how their options will be “constrained.” This is a very important point (and somewhat of an inconvenient truth): it is possible to be standards-based without being interoperable. System-wide interoperability comes from adopting and implementing profiles that work together.

A collection of interoperable profiles can be thought of as a stack, i.e., a set or group of profiles that work together. In the whole universe of eHealth standards, there are really only three profile stacks that have been internationally balloted: HL7v3,^[2] ISO-13606 (the balloted version of the OpenEHR specifications),^[3] and IHE.^[4] Countries can mitigate risk by selecting one of these stacks as the basis for their NeSF.

Third, integrated care pathways (ICPs) are at the heart of our health care stories. ICPs are the long-running cross-enterprise workflows that describe how guideline-based care is to be delivered within a care delivery network. They play a hugely important role in improving health outcomes. ICPs help close the know/do gap: the chasm between what we know are the most effective care practices and what we actually do in our day-to-day care delivery activities. As we can see from the top half of Figure 19, the reusable eHealth profiles give us a way to operationalize ICPs; profiles are what we leverage to tell our health stories.

Using Standards to Tell the Story

A country’s guideline-based maternal, newborn, and child health (MNCH) ICP underpins the very heart of our example story. The scheduling of Mosa’s ANC visits is based on the country’s MNCH care guidelines, and so are the list of health observations that Grace captures about Mosa and saves on the paper form and in Mosa’s shared health record. Even the rules about when Mosa should be referred to the district hospital are guideline-based.

Figure 20 shows how base standards (content standards in blue, and coding standards in orange), profiles (in yellow), and the MNCH ICP (in dark red) map onto the sequence diagram for Mosa’s ANC visit.

The content and coding standards map directly to the information viewpoint of our story. The MOH-mandated ANC content specification applies to the paper form that Grace fills out. It defines what information should be collected—and which fields are mandatory, which optional. The eHealth equivalent of this paper-based form might be expressed as an antenatal care clinical document (HL7 CDA)^[5] or an OpenEHR archetype,^[6] for example. In both cases, the content specification indicates what data should be captured during the care encounter.^[7]

The MOH’s coding specification further refines the content specification. On Mosa’s paper-based ANC visit form there are specific units of measure mandated for her temperature, blood pressure, etc. This is so that anyone reading Mosa’s form can quickly understand the values and know whether they are “normal” or “in a danger range.” If Mosa’s blood pressure, for example, was sometimes recorded in millimeters of mercury (mmHg) and sometimes in kilopascals (kPa), it could lead to confusion and, more seriously, could potentially lead to safety issues for her. The same is true for information about Mosa that is shared electronically. On the eHealth side, coding standards ensure that exchanged information is “understood” by the receiving system. This consistency of content and coding is referred to as semantic interoperability.^[8]

Importantly, content and coding standards come into play for our health insurance workflows, too. For example, if Grace were paid via a provider payment model based on FFS or DRG, then the clinical coding she used to document Mosa’s ANC visit would directly map to how much Grace would be paid for the service. Harmonization between the clinical coding and the insurance fee schedule is a crucial step. This is discussed in detail in Anne Belford’s sidebar on using eHealth transactions to support provider payments.

The sharing of information relies on message exchange specifications. In the paper-based world, the fax machine’s standards ensure that the dots that are scanned at one end are the dots that are printed at the other end. For sharing coded eHealth content, there are communications standards that ensure that the information captured about Mosa is securely and successfully conveyed from the source system to the destination system. Common eHealth communications standards include HL7v3 messaging,^[9] cross-enterprise document exchange (IHE XDS),^[10] or ISO 13606^[11]/openEHR archetype^[12] communication.

Last, but definitely not least, is the family of confidentiality standards. Many of these standards are used by other sectors (such as banking) that also need to manage the exchange of private information. Some, however, are specific to health care—such as standards for the management of patients’ consents regarding the sharing of health information. In aggregate, these standards regarding elements such as authentication, authorization, and encryption are used to ensure that personal health information (PHI) is safely kept and securely shared.

Which Building Blocks Do We Need?

How do the five C’s get operationalized as a NeSF? A “storytelling” technique such as the one used for Mosa’s ANC visit can be employed to develop the requirements for information, communications, and, from these, the requirements for standards-based interoperability profiles. To develop the NeSF, it is important to run through this process for the key health stories representative of the country’s health strategic plan and to use these to come up with the core eHealth “building blocks” needed to bring this set of stories to life. Figure 21 shows the mapping between the RM-ODP viewpoints and the eHealth building blocks.

One of the advantages of the building blocks approach is that interoperability profiles are highly reusable across many health stories. What is the key set of building blocks? It turns out that a wide array of guideline-based ICPs can be constructed from a relatively small number of interoperability profiles:

1. Insert or update demographic information; for example, when Mosa’s baby is born, create a new CR record for him or her.
2. Query for demographic information; for example, when Mosa shows up for her ANC, query for her demographic record based on her insurance identification number.
3. Record health observations about a subject of care; for example, save Mosa’s weight, temperature, and blood pressure readings to her SHR.
4. Query for summary health information about a subject of care; for example, when Mosa’s ANC visit starts, the mHealth application can fetch her health summary from the SHR.
5. Order lab tests; for example, if Grace becomes worried about Mosa’s condition, she may obtain a sample (e.g., blood, sputum) and send it to the lab for testing.
6. Record test results; for example, the lab saves Mosa’s lab test results to her SHR and (potentially: see final bullet) alerts Grace that the results are available to be reviewed.
7. Order medications; for example, based on the lab results, Grace may decide to prescribe a course of medications for Mosa.
8. Dispense medications; for example, Mosa may have her medications order filled at the pharmacy at Grace’s clinic, or at another pharmacy in the community.
9. Provide a referral; for example, Grace may refer Mosa to the local district hospital for specialized follow-up.
10. Communicate information at discharge; for example, after her stay at the district hospital, a discharge summary is saved to Mosa’s SHR outlining the care Mosa received and providing instructions regarding her ongoing plan of care.
11. Send alerts;  for example, an mHealth application can send SMS alerts to Mosa, or to Grace, as reminders, or to provide educational “factoids,” or to provide specific information (such as “lab results ready for viewing”).

This is not an exhaustive list of all possible eHealth transactions. Rather, it is a representative list of important transactions that can be very flexibly employed to operationalize a wide array of ICPs.^[13]

What information workflows are needed on the insurance side? The Provider Payment Reform and Information Technology Systems paper^[14] produced by the JLN describes five core operations for health insurance information systems:

• Beneficiary management
• Provider management
• Premium collection
• Claims management
• Accounting

Premium collection and accounting are purely financial workflows, and there are separate ICT stacks that would support these activities. Beneficiary management, however, can be supported as part of the first workflow in the representative list of 11 eHealth transactions shown previously. Indeed, the HL7 schema for a client record includes the common elements of demographic information (e.g., name, date of birth, gender, address) plus explicit space to save details about the client’s insurance coverage (the “IN1” segment in the HL7 schema) and relationships with specific care providers (the “ROL” segments in the HL7 schema), including providers empaneled by the insurer.

Provider management workflows are not included in the previous list of eHealth transactions but are explicitly supported by profiles in all three standards-based stacks: HL7v3, OpenEHR, and IHE. The IHE Care Services Discovery (CSD) profile, for example, supports explicitly associating empaneled providers with insurers (identified as an insurance “organization” in the CSD data model).

Claims management is supported by the transactional workflows listed in the eHealth transaction list and the eHealth transactions that arise from these. Price lists would be separately maintained by insurers in their accounting systems. To support adjudication of claims, eHealth documents cross-referenced to the facility ID, client ID, and provider ID—and which include coded diagnoses, observations, and procedures—can be matched up against the price lists. In this way, the eHealth documents can support provider invoices submitted under, for example, FFS or DRG payment methods.

Can a health insurance claim be created or derived from an EHR transaction?

I think that success in leveraging an EHR transaction to create a health insurance claim lies in the ability to achieve interoperability across the EHR and claim data standards, while accommodating a variety of providers and access methods on the front end and a broad range of insurer plan design and adjudication rules on the back end.

There will be a variety of EHR messages used across the spectrum, including lab, pharmacy, hospital, and outpatient events, and in all cases the core content of the EHR event fits nicely with the claim requirements. At the highest level, both an EHR message and a claim message contain data to describe a patient and to identify the servicing provider, the services, procedures, and events that occurred, the reason for the event, and the diagnosis and referral information. Taking a closer look though, interoperability is not determined by the messaging format and the presence of like fields; rather it is determined by the actual data content and the successful alignment of clinical nomenclatures, terminologies, and identifiers between the source EHR and target claim requirements. Will providers always submit using coding systems or textual descriptions only? Will the codified EHR service code system match the codified claim service code system, or are they able to be mapped? Data is the key challenge, so we will take a closer look at that aspect.

From a claims perspective, payment systems will use a range of terminologies and code sets.  These will vary by payment method (examples: fee-for-service, case-based), by benefit type (examples: pharmacy, hospital, vision), and by the payment plan designs (examples: in a fee-for-service model, service code “x” pays “y” per unit; in a case-based model, event type “x” pays “y” per diagnosis “z”). The level of granularity in the coding schemes used between the EHR and claim systems must be resolvable in each case, as they may not always be identical.

As an example, the insurer plan design rules may pay on a per “visit” basis, but the EHR source message may utilize more granular service codes such as “exam, manipulation, massage” instead of a single visit code. In this case, the three codes can be rolled up into a single visit code to match the more simplistic payment rules that are implemented. Identical codes are not required, though the transformation service that is employed to derive the claim message will need to execute these types of mapping rules. The level of mapping and its complexities will only be discovered though detailed analysis on a case-by-case basis. I would not expect that the EHR coding would be less granular than the claim coding (example: EHR submits “visit” and insurer requires “exam, manipulation, massage,”—but this would of course be problematic). It is notable that the more granular coding schemes can be beneficial to an insurer, as they allow for the creation of more sophisticated plan designs. In addition to terminology, the key patient and provider identifiers must align. Ideally, claim and EHR systems will share identifier enrollment, but otherwise they must be resolved at claim creation time. A centralized patient and provider registry is ideal to perform mapping, should this be required.

In addition to data alignment, the rules for triggering the creation of a claim must be established, as there is not a 1:1 relationship between EHR events and claims. If we consider a hospital setting, a wide range of clinical events are recorded in an EHR repository, only a portion of which are billable. It may be that the discharge event triggers a claim but an admission event will not. These rules are quite straightforward, but the rules relating to updating EHR records are a bit more sophisticated. This is best demonstrated in an example. If a claim has been created for a lab order and the lab order is subsequently updated, the claim data may also need to be updated (claim reversal and resubmission), but this may depend on what data has been updated in the order. If the claim payment rule is tied to the occurrence of an order event (plan pays for every lab order) there may be no impact, but if payment rule is tied to the order detail (plan only pays for order type “x”) then the claim is updated when the order detail is updated. To summarize, the act of deriving a claim event from an EHR event will need to occur based on a series of rules that are applied. These rules may vary in direct relation to the insurer’s plan design, as in the example above.

Lastly, there may be some claims that cannot be purely derived at the interface layer, for the simple reason that required claim information will not exist in the EHR message. For case-based payment models that are event driven (example: discharges from a hospital with diagnosis), it is reasonable to expect that all data is present in the EHR message. If we compare the data requirements in the fee-for-service model against an EHR message, we may find some gaps in the areas of costing and policy information. It is notable also that mature claims standards will distinguish between the concepts of servicing provider (found in the EHR messaging) and the billing provider or billing organization, and this type of data is not found in the EHR message. To convey additional data, a billing segment could accompany the EHR transaction, and the claim is therefore initiated by the provider system. It is worth considering that where provider capabilities exist, having the claim submitted from sophisticated provider systems is beneficial, as it provides the ability to track submitted claims, reconcile payments, and so forth.  Again, this is case driven.

In summary, and as outlined above, there are a few core conditions that must be met in order to successfully derive claims from EHR transactions. Given the many benefits to be gained from doing so, an in-depth analysis to determine when this approach is viable for this environment would be a worthwhile endeavor. The alignment of shared data sets and identifiers between the EHR and payment systems will largely determine the ease with which this can be implemented and the efficiency of the solution. If the ability exists to influence the selection of like EHR and claim vocabularies from the onset, it is very desirable.

Anne Belford is a standards specialist in both the Benefits Management and Electronic Health Record divisions at TELUS Health, with over 20 years of experience

About TELUS Health

TELUS Health (www.telushealth.com) is a leader in telehomecare, electronic medical and health records, consumer health, benefits management, and pharmacy management. Within Canada’s claims and benefits management sector, TELUS provides drug claims processing for more than 12 million Canadians.

Leveraging the NeSF to Support UHC

It is important to recall the discussion regarding how eHealth affects population health (as illustrated by Figure 1). Ravindra Rannan-Eliya has postulated that “health financing is the most important control knob that policymakers have to influence the operation of a health system.”^[15] Indeed, many UHC initiatives have strong motivation for improving quality as well as increasing access, broadening services, and reducing financial risk.

The World Bank’s health system performance model is shown in Figure 22^[16]. This model illustrates how policy interventions, including financing and payments, can be leveraged as process control feedback loops on the system. Such a model may be thought of as complementary to the UHC “cube” shown in Figure 23.^[17] We could say that the UHC cube model illustrates the “what” and the process control model illustrates the “how.”

The experience of government-sponsored health insurance schemes in India

The recent wave of government-sponsored health insurance schemes in India (GSHISs) represents a new form of mobilizing and allocating government resources for health care for the poor, at least in the Indian context. An explicit (and delivered) package of services, greater accountability for results, and a “built-in” bottom-up design to reach UHC by first achieving coverage of the poor are building a promising foundation for the country’s future health system. The new generation of GSHISs has successfully leveraged and built upon the earlier development of the health insurance sector in the country, which has enabled them to scale up rapidly and achieve a significant increase in the breadth of coverage of health insurance in the country. By 2013, over 360 million Indians were covered by GSHISs. This represents about 30 percent of the country’s population and constitutes the vast majority (over four-fifths) of the insured population base in the country. Such broad coverage by GSHISs indicates their huge leverage in bringing about incremental changes in India’s health financing and overall health system space.GSHISs have introduced a number of IT solutions on a mass scale, including biometric enrollments, electronic preauthorization, online claims and payment processes, and monitoring of field functionaries through video surveillance. ICT has the potential to play an increasingly important role for reducing fraud, containing administrative costs, and generating data for monitoring and analysis. The future success and sustainability of GSHISs hinge on the development of key governance and information systems that will help them carry out their core functions of program design, implementation, purchasing, cost containment, quality improvement, supervision, and enhancing consumer satisfaction, among others.

In this context, the World Bank’s India health team, in collaboration with the World Bank Institute (WBI), has been organizing a series of practitioner-to-practitioner knowledge exchanges christened as the “Forum of Government Sponsored Health Insurance Schemes in India.”^[18] This knowledge-sharing venue, which has evolved into a unique semi-annual event, brings together senior government decision-makers for thematic discussions on specific areas deemed to be important by them. The seventh forum in this series was organized in Mumbai from November 20 through 22, 2013, and focused on the central theme of “Information Systems and Standards.” The event closely followed the announcement, by the Government of India, of the first-ever National EHR standards and benefited from participation by the group closely involved in the standards effort. As such, this event provided a platform for discussion on India’s national eHealth standards and their application and relevance to the GSHISs.A series of presentations and discussions were held, involving the CEOs of the GSHISs and senior officials from the Government of India and state governments, by the EHR group that drafted the national standards and by international resource persons. The group discussed the value proposition for a standards-based eHealth infrastructure and explored how such infrastructure can be employed to both monitor the health care system and exert process control upon it. Discussion regarding health system process control generally referenced the World Bank’s “control knobs” techniques as well as, specifically, a recent in-depth analysis of GSHISs in India.^[19] Leveraging such techniques importantly provides an opportunity to operationalize continuous quality improvement of the health care delivery network. The Forum also explored ways to leverage big data analytics (BDA) against the resulting eHealth data. GSHIS members undertook facilitated group work to develop, articulate, and explore three key BDA application areas: institutional quality, disease prevalence/trends, and detection of provider fraud.

There are several key areas where the application of standards-based eHealth information systems by the GSHISs will enable their functionality even more. By enabling the assessment and comparison of performance parameters within and across schemes, the adoption of standards will make possible closer and more effective management and monitoring of data on utilization, claims, payments, quality, grievances, patient satisfaction, and outcomes. This has important implications. Cost containment requires timely information on utilization patterns and spending, benchmarked with peers. Strengthening the precision of package rates is also dependent on sound data on diagnoses and costs. Enabling facility-level quality metrics and implementation of evidence-based treatment guidelines would also depend on such standards-based data sets being introduced, implemented, and reported upon. Clearly, the GSHISs are uniquely placed to be key players in India’s ambitions for UHC, and the support of eHealth standards will be a powerful tool in their armory.

Dr. Somil Nagpal is a health specialist with the World Bank (South Asia Region). He was deputed by the Government of India to the Insurance Regulatory and Development Authority (IRDA), where he was responsible for setting up and leading the specialized health insurance unit. He has previously served the Indian Ministry of Health, the National Commission on Macroeconomics and Health, and WHO. Dr. Nagpal is a medical doctor and a postgraduate in health management. He holds an MBA in finance and a fellowship in insurance.