The ways that people and processes and information and communication networks all work together to “make it go” are described by enterprise architecture (EA). The US National Institutes of Health uses urban planning^[1] as an analogy for what EA is and why it is important. This is a useful analogy. For a city to “work” (for automobile traffic to flow, for sewer and water systems to be appropriately sized, etc.), there needs to be a city plan. The plan reflects civic goals and aspirations, articulates designs for infrastructure and services (roads, water, sewage, electricity, fire, police, etc.), and guides how construction and growth can occur while remaining consistent with the overall blueprint. Such guidelines may even specify precise details regarding the standards that must be adhered to, right down to the size and rating of water and sewer pipe connections, for example.

As we learned in Chapter 2, Country Experiences, nations have goals and aspirations for their country’s health systems, and these are often quite precisely described and documented by the ministry of health. Some countries have developed eHealth strategic plans that map how ICT can be used to realize and support these health system goals and aspirations. Some have developed, or are developing, blueprints that articulate how shared eHealth infrastructure will be built, and these blueprints may even describe the standards-based “connectors” that will be used to ensure that ICT applications can interoperate with the overall health system. Taken together, these many viewpoints describe the health enterprise architecture.

Enterprise Architecting

Over time, a number of methodologies and frameworks have been developed to help architect large, multifaceted systems. One such framework is TOGAF (an Open Group Standard architecture framework).^[2] Figure 12 shows a high-level diagram of the TOGAF methodology.

The TOGAF process, in a rigorous managed way, covers three key questions that must be addressed by the enterprise architecture:

• Why are we doing what we’re doing? This is addressed by the Preliminary step and by step A (Architecture Vision).
• What are we doing? This is where the overall infrastructure and its requirements are described from the business, information, communication, and engineering/technology viewpoints. It is the scope of steps B, C, and D.
• How are we doing it? This is where crucial issues of implementation science, project management, and governance are brought to bear. It is the scope of steps E, F, G, and H.

Specifically focusing on the “What are we doing?” aspect of the EA, there is another useful framework that can be used to articulate the multiple viewpoints of the health information system. This framework is called RM-ODP.^[3] RM-ODP provides us with a way to define and describe the eHealth infrastructure; it maps to steps B, C, and D of the TOGAF methodology. Figure 13 illustrates the RM-ODP-based viewpoints of a health information system (shown as HIS in Figure 13).

The vision and execution/governance aspects of the TOGAF process are crucial to the successful architecting of a health information system. For the balance of this book, however, we will focus on the enterprise, information, computational, and engineering/technology viewpoints of the health information system. In the following section we will introduce a straightforward, storytelling approach that can be used to develop and describe a standards-based, national-scale, eHealth infrastructure.

Leveraging a Storytelling Approach

Everyone understands storytelling, which is at the heart of many cultures. In a useful way, we will use a familiar storytelling technique to make enterprise architecture more approachable and easier to take on. Although the underlying process is based on formal practices, to get started developing our health EA, we just need to be able to tell a “health story.”

We will illustrate the relationship between eHealth infrastructure, care delivery, and UHC by following the story of a young woman named Mosa. This story’s context describes a national eHealth infrastructure with a relatively high level of maturity, so it might represent a “future state” for some countries. Step by step, we will use this storytelling technique as a way to identify process workflows, develop system requirements, and show what information needs to be shared across the health care system, thus identifying where eHealth standards and interoperability are most needed.

Using characteristic health stories is a very powerful technique that has been used by many countries to design their national eHealth systems (for example, Canada, the United States, Rwanda, and South Africa). It usefully connects health-affecting functionalities and workflows “on the ground” to the ICT assets “in the cloud” that are needed to operationalize them. Countries do not need to implement all of these infrastructure pieces at once and can take a “crawl, walk, run” approach to grow their capabilities over time (this is discussed further in Chapter 7).

Our example story takes place in a country with a national health insurance scheme (NHIS) that includes in its service bundle free (no out-of-pocket fees) maternal care services for its beneficiaries. These services are funded via a combination of capitation and diagnosis-related group (DRG) provider payment methods for antenatal care (ANC) and attended labor and delivery (L&D), respectively. The country has implemented a national eHealth infrastructure for tracking ANC information and for supporting provider payment.

The Story

Mosa is the main actor in our story. She is 19 years old, lives in a rural village, and is pregnant with her first child. Grace is another actor in our story. She is a primary care practitioner who provides services through a community clinic near Mosa’s village.

There is important background information for our story, and these details affect the flow of activities and information. Mosa is enrolled in her country’s national health insurance program and has a health insurance card; this card has an identification number that uniquely identifies her. Mosa has a care relationship with Grace, who is designated as her preferred primary provider (PPP). There is an important nonhuman actor in our story, too—Grace’s mobile phone. The phone is important because Grace uses it to exchange text messages (via SMS or USSD)^[4] with a national mHealth application specifically designed to support primary care services. Figure 14 outlines how Mosa and Grace use ICT and interact for antenatal care services.

Grace has told Mosa that she should come for four ANC visits during her pregnancy.^[5] ANC coverage is included in Mosa’s health insurance plan. As a first step in the story, Grace uses her mobile phone to access a mHealth application; she enters Mosa’s health card number into the application to establish that Mosa is eligible for services under the plan.

Grace maintains a paper-based medical record that she updates each time she sees Mosa. At each ANC visit, Grace logs information by filling in an MOH-mandated form that tracks key health indicators based on WHO maternal care guidelines (e.g., weight, temperature, blood pressure). Grace also uses her phone to execute rudimentary eHealth transactions. These transactions about Mosa save key data (e.g., weight, temperature, blood pressure) to a national shared health records (SHR) repository that Grace, or any other clinician, can access from anywhere in the country, based on proper security. This shared information is important in helping to provide continuity of care for Mosa over time and, if necessary, in situations where Mosa may need to be referred to the district hospital.

Importantly, we can think of Grace’s mHealth application and the national eHealth infrastructure (CR, health worker registry [HWR], SHR, etc.) as nonhuman actors in our story. In the context of UHC, we can also think of the insurance scheme (the payor) as an actor, too. This is the actor that pays Grace for the services she provides to Mosa.

In our story, Grace is paid by the health insurance scheme under a capitation provider payments model.^[6] Each month, she receives a set fee for each of the patients she has under her care. Grace also acts as the gatekeeper regarding Mosa’s care referrals, should they be necessary. When it comes time for Mosa to deliver her baby, Grace (or whoever is the skilled attendant at the birth) is paid by the insurer on a DRG payments model.

The Story’s “Information Viewpoint”

What information is needed to support the story of Mosa’s ANC visit with Grace? What information arises from this story (e.g., as reportable indicators or metrics)? As we answer these questions, we are documenting an “information viewpoint” of the underlying systems that support our story of Mosa and Grace. Figure 15 shows the “information” elements inherent in our example story.

From Figure 15, we see:

• Grace is the provider of care.
• Mosa is the subject of care.
• The ANC visit is a care encounter between Mosa and Grace that happens at a certain date and time at a specific location; this information may be derived from the SMS message and sets the care context.
• Mosa’s health insurance identification number relates to her demographic record in the client registry (CR) and to her electronic shared health record (SHR).
• As shown in Figure 9, from the payor’s point of view the CR serves as a beneficiary database. The beneficiary database, along with a database of insured services, is used to determine whether Mosa is covered for ANC services under her health insurance plan.
• Grace is designated as Mosa’s PPP. This relationship is stored in Mosa’s record in the CR (beneficiary database). Grace is paid each month by the insurance plan based on the size of her roster of patients; Mosa is in this roster.
• Health observations (weight, temperature, blood pressure, etc.) about Mosa are collected as per maternal care guidelines. These are stored in Mosa’s SHR.
• If Mosa’s readings are outside guideline-based ranges (the clinical decision support logic), Grace makes a referral for Mosa to go to the district hospital.
• If Mosa’s readings are normal, then her next ANC visit will be scheduled based on the guideline-based interval between visits (plan of care).

The information elements in Mosa’s story can be described using data modeling techniques. Data model artifacts, such as entity-relationship diagrams^[7]  (see Figure 16) or UML class diagrams,^[8] are typically used by IT professionals to translate the user story and document the information viewpoint of a system. Data models are also implied by the content standards that have been developed for certain clinical documents. The fields that are on Grace’s MOH-mandated paper ANC form, for example, represent the content standard (and the associated data model) for documenting an ANC visit. These ideas will be further explored in the following sections.

The Story’s Data Communication Patterns

The information in our story is shared among the story’s actors. Some of this information is shared between the human actors, Mosa and Grace. Sometimes, however, the information is being shared with nonhuman actors. This is the case, for instance, when Grace is using her mobile phone to capture health observations about Mosa and save them to Mosa’s SHR. As illustrated in Figure 17, our story can be broken down into a set of distinct information-sharing patterns.

These information-sharing patterns are further described below:

1. There is an SMS-based communication between Grace and the mHealth application. This launches the workflow.
2. Standards-based messaging occurs between the mHealth application and the MOH’s eHealth infrastructure where Mosa’s CR record and her SHR are maintained.
3. The mHealth application authorizes Mosa’s benefits eligibility and establishes the care context for her ANC visit with Grace, including referencing the applicable care guidelines.
4. A back-and-forth conversation occurs between Grace and the mHealth application that captures key health observations about Mosa. The SMS conversation is based on the maternal care guidelines applicable to Mosa’s ANC visit.
5. If Mosa’s health condition warrants escalation of her care, Grace will send an SMS message to the mHealth application to refer Mosa to the district hospital. The mHealth application will send a standards-based message to update Mosa’s SHR, and the district hospital will be informed of the referral.
6. If no care escalation is needed, Grace will send a standards-based message scheduling Mosa’s next ANC visit as per the maternal care guidelines. The mHealth application will update Mosa’s SHR.

Figure 18 illustrates the information-sharing patterns using a sequence diagram.^[9] A sequence diagram documents the sequence of communications between the story’s actors.

In this sequence diagram, each actor is listed across the top with “life-lines” running vertically down from each one. Communication between actors is indicated by horizontal communication arrows that connect their life-lines. Some communication patterns repeat, or loop; these communications are drawn inside a “loop” box on the diagram. Sometimes there are alternate communication patterns based on one condition or another; these communications are drawn inside an “alt” box on the diagram that shows when and how the communication happens for each alternative.

In this example, our story depicts a guideline-based maternal care workflow. The story, the story’s information content, and the communication among the story’s actors can be thought of as representing three of the “architectural” viewpoints of the underlying health information system (recall Figure 13). A fourth viewpoint—the “engineering” viewpoint—describes the ICT design that operationalizes the other three viewpoints. The engineering viewpoint is where a country’s eHealth standards (the NeSF) are expressed. Chapter 6 describes how we leverage our three “storytelling” viewpoints to develop a NeSF.