What practical steps can a country take to begin to develop a NeSF that supports care delivery and UHC initiatives? Based on what has been covered so far, the following are recommended as useful, actionable steps:

1. Storyboard: Develop a set of characteristic user stories that illustrate both the care workflows and the health insurance workflows common to the country. These stories should be aligned with the country’s health strategic goals (e.g., if improving maternal health outcomes is a strategic goal for the MOH, draft stories describing maternal care delivery activities).
2. Stack: Based on the requirements and the constraints in the country, choose a “stack of standards.” The authors recommend that countries mitigate risk by selecting one of the three internationally balloted stacks: HL7v3, OpenEHR, and IHE.
3. Scope: Narrow the initial implementation scope and grow the scope over time. Any country embarking on a national-scale eHealth infrastructure effort will be well served by focusing on a few key areas. A “crawl, walk, run” strategy is usually best.

Develop the Stories

Each country’s stories are unique; they reflect the nation’s burden of disease and the resources that are available to be brought to bear to improve health. As such, the health stories that are to be operationalized by a national, standards-based eHealth infrastructure should be those that speak most directly to the strategic priorities of the country’s MOH. As described in the WHO-ITU Toolkit, the eHealth strategy is driven by the health strategy. As we have seen in Chapters 5 and 6, the standards are driven by the stories (and the information and the communication patterns these stories call out). It is worthwhile to note that the “storytelling approach” described in this book is based on rigorous health enterprise architecture practices and methods that were explored in more detail in a JLN webinar held in September 2013.^[1]

Developing the health stories is the crucial first step. The opportunity should not be missed, in developing these characteristic stories, to accomplish three important objectives:

• Relate the stories to guideline-based ICPs. There is a significant benefit to be realized by closing the know/do gap. We should use our stories to describe the care scenarios we want (especially if what we want is different from the scenarios we presently have).
• If the story is part of an insurance initiative, connect it to the care delivery workflow. If the story is a care initiative, connect it to the insurance workflow. Use every initiative as an opportunity to further harmonize the care delivery and health financing systems.
• Connect the data that arise from routine transaction processing to the data needed for surveillance, population health metrics, and health system management. One of the very powerful benefits of embracing eHealth standards is that the resulting data are in a computable format and may be leveraged to support the generation of important analytics and aggregated indicators.

Choose the Stack

Many countries are presently engaged in eHealth initiatives. These initiatives may be approaching eHealth infrastructure from the care delivery side or from the health insurance side, or both. In any case, it will be important to ensure interoperability of systems so that the all-important network effect can be realized.

Interoperability is achieved by adopting and implementing standards-based profiles. As described in the opening of this chapter, the most effective way to ensure the interoperability of profiles is to select a standards stack and then choose and implement profiles from within that stack, recognizing that some adaptions will be needed to address specific country requirements.

As introduced in Chapter 6, the three internationally balloted stacks of eHealth standards are HL7v3, ISO-13606 (the balloted version of the OpenEHR specifications), and IHE.

How do we choose between these three options? Large IT projects are risky. We recommend that countries favor their lowest-risk option. Ideally, this option is the one that is likely to enjoy the broadest uptake at the lowest cost and in the shortest time.

But which option is the lowest-risk option? For some countries, the answer will be simple: go with the stack that is, today, most commonly found within the health care sector. For other countries, however, there will be few existing eHealth implementations—or worse, numerous isolated pilots, none of which can interoperate with each other—making it harder to choose. The “right” option for a NeSF will be the one that best fits the country’s needs and its constraints and is least likely to fail.

A tool for assessing risk is available from the HingX.org website.^[2] An example spreadsheet is available at the site that illustrates how the tool might be employed to assess the relative risks associated with implementing each of the three candidate stacks. The key message is: do a risk assessment and select a standards stack; this way, eHealth profiles that are implemented will be interoperable with each other.

Expand the Scope over Time

Countries are at different stages of implementation and different stages of readiness to deploy new eHealth infrastructure. These differences are related to many factors, including political will, budget, and resources. Countries often have many non-interoperable pilot projects, and lack a national-scale infrastructure. How do we choose what to do first, and then next, and so on? Applying some basic principles will help, as outlined below.

Harvest the low-hanging fruit. For many countries, even establishing a facility registry will provide immediate benefits from a health system planning and management standpoint. Likewise, where there are databases of regulated professionals (such as physicians and nurses) in place, these can be readily collected together to develop a provider registry. Both of these registries also serve health insurance workflows and can be used to support the basic implementation of provider payment methods.

Identify the people being served. There is no escaping the fact that effective care delivery relies on identifying the subject of care. Also, insurance eligibility relies on being able to correctly identify the beneficiary. As challenging as it is to establish, a client registry^[3] (CR) is the cornerstone of a well-functioning health system. Some ways to make this easier are described in the following points.

Bootstrap rather than big bang. Using the CR as an example, consider as a first step establishing a national registry of pregnant mothers, a registry of babies that need immunization, or a registry of government employees. It may be very difficult to find a database with high-quality records that can be readily used to “seed” the CR. Where a small database exists, use it to get started and then invest in making it easy to “onboard” new clients when they visit a care facility. Always, however, make sure that new records are being added to the national CR and not to siloed databases. This “bootstrapping” idea can be applied to other ICT assets, too. Start with a small database and plan to grow it organically as it is used to support new care scenarios.

Choose mobile phone–friendly identifiers. There are a number of national-scale IDs that must be established as part of the eHealth infrastructure (facility ID, provider ID, client ID, etc.). In many low-resource settings, mobile phones will play an important role as the data entry devices for rudimentary eHealth transactions. Plan for this by ensuring that IDs are numeric and have a check digit.

Favor clinical code systems as billing codes. As Anne Belford mentioned in her sidebar, when it comes time to start saving person-centric health transactions to an SHR, ensure that insurance billing codes readily map to the clinical codes (e.g., LOINC, ICD-10, ICHI, ATC).^[4] Ideally, clinical codes should be used as the insurance billing codes; it will make the adjudication of FFS and DRG claims fundamentally easier.

Look for ways to evolve toward an EHR. Some countries have quite sophisticated health insurance infrastructure but nascent or weak care delivery eHealth systems. A strong health insurance transaction processing capability can be used as a first step toward person-centric EHRs. This is especially true if FFS or DRG payment methods are already implemented. Opportunistically, financial incentives/disincentives can be employed to strengthen the coding of physician claims submissions so that, over time, the usefulness of these data as health records will grow. The incentives may also prove “market making” for growth in the use of EMR systems within hospitals, clinics, and general practitioner offices. Approaching the challenge from the care delivery side, consider capitalizing on the bootstrapping ideas to expand the scope of care-specific databases (e.g., HIV/AIDS or tuberculosis databases) to become national-scale, all-person, shared health records repositories.

Final Thoughts

It is a core premise of this book that interoperability among disparate eHealth and mHealth applications relies on the system-wide adoption of standards. Our goal for this book has been to articulate the value of such interoperability; to relate country experiences on the path to interoperable eHealth; to frame various points of view of the health information system by introducing the four P’s; and to describe a “storytelling approach” that can be employed to develop eHealth standards specifications appropriate to a country’s interoperability requirements.

We conclude by reiterating a single piece of overarching advice:

If the key messages from this book had to be summarized in a single, core piece of advice, it would be that a common, standards-based, national-scale eHealth infrastructure should support both care delivery and financial payment workflows as well as produce the analytics necessary to monitor and manage these.