1 of 89

OpenHIE

OpenHIE Academy Course 110

Overview of the OpenHIE Architecture

February 2019

2 of 89

Introduction to the Course

3 of 89

Course Instructors

Samson Yohannes, Ethiopian Institute of Technology - Mekelle

Head, Software Engineering Chair

Jennifer Shivers, Regenstrief Institute

OpenHIE Associate Architect
OpenHIE Co-lead of the Academy Community

Additional Contributions From

Paul Biondich, OpenHIE Founder
Carl Fourie, OpenHIE Associate Architect
Shaun Grannis, OpenHIE Lead Architect

3

4 of 89

4

Learning Objectives

By the end of this session, learners will be able to:

Understand the concept and need for an enterprise architecture
Define and state the value of health architecture
Describe the high-level function of the OpenHIE Architecture Components
Understand how to adapt the architecture to meet a project use case or a specific country’s needs
Discuss the value of health architecture

5 of 89

5

Enterprise Architecture

Blueprint (model) that creates a framework for how the HIS subsystems interact
Is the planning function between strategy formulation and delivery
Depicts the system’s organization or structure and provides an explanation of how it behaves
Analogous to a city master plan
Delineates information systems, data sources, integration & governance and fits to the national enterprise architecture

6 of 89

6

Service Oriented Architecture (SOA)

Designed to overcome the problems resulting from monolithic applications
Emerged as an evolution of distributed computing
Introduce the concept of a ‘service’ that interacts over the wire using a protocol such as REST or SOAP
SOA – a software application is designed as a combination of services
Services are loosely coupled, meaning the service interface is independent of the underlying implementation

7 of 89

7

Monolithic Architecture

Enterprise System Applications are designed

to facilitate business requirements

Offers hundreds of business capabilities
In monolith, capabilities are generally

piled into a single monolithic application

Deployment, troubleshooting, scaling, and

upgrading is a nightmare

8 of 89

8

Microservices Architecture

Applications are developed as a suite of small and independent services that are run in their own process, developed and deployed independently
Is an architectural style that structures
An application as a collection of services that are:

Highly maintainable and testable
Loosely coupled
Able to be independently deployed
Organized around business capabilities
Owned by a small team

9 of 89

9

OpenHIE Architecture Community

Architectural and Exchange Patterns

Developed in a community process

Applied to your context and setting

OpenHIE Architecture

10 of 89

10

Basic Concept: developing an application as a suite of small and independent services that are running in their own process, developed and deployed independently
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are

Highly maintainable and testable
Loosely coupled
Able to be independently deployed
Organized around business capabilities
Owned by a small team

Microservices Architecture

11 of 89

11

eHealth Architecture

The eHealth Architecture is the foundational plan or blueprint that creates a framework for how the HIS subsystems interact.

It may include:

Principles that guide technical investment and decision making
A schema that outlines how the physical components will interact
Policies and/or processes that support the principles and the schema
Physical components needed to support the schema, policies, and procedures
Standards for data exchange and semantic terminology

12 of 89

OpenHIE Architecture Overview

13 of 89

13

OpenHIE Architecture Community

OpenHIE Architecture

14 of 89

What is the value of having an architecture that supports Health Information Exchange?

14

I’d like you to take a minute to write down some thoughts about the value of having an architecture that supports health information exchange. You may want to pause the course so that you have time to gather your thoughts.

In some ways, the value of health information exchange depends directly upon the specific implementation of a particular health challenge. However, from a high-level architecture perspective, there are some key values in having a architecture or health information system plan that supports data exchange. Two key values that are interrelated include:

Enable sharing and using data outside of siloed systems

Without a coordinated plan, the health system will continue to evolve in a way where patient care and the collection of population health data is increasingly distributed amongst many different healthcare workers and local and institutional levels and systems.
Disparate information stored in different locations and formats, making it seemingly impossible for data to be collated, synced and shared.

Reducing duplicate effort. Disjointed investments in ICT health projects lead to duplicate efforts and wasted resources.

To support this, moving to technical model that allows data to be collected at the patient-level and then merged with data from other systems where aggregations and calculations can be done.
This allows us to support the principle of collecting data once and then being able to use it at different levels of the health system.

15 of 89

15

Goal:

Support Healthcare Through Data Sharing Capabilities

16 of 89

OpenHIE Architecture

A community approach to

16

Supporting Global Health Information Needs	Individual Patient Care (Clinical) Reproductive, maternal, newborn, and child health Immunization Health HIV disease management Non-communicable disease management	Population and Public Health Infectious disease surveillance, reporting, and management Cohort identification, management and tracking	Healthcare Administration Facilities Health workers Health medicine and supplies Health coverage and enrollment
Through Support of Data Sharing Capabilities
Designed with Architected Standards-based Solutions

Exchange Specifications
Message standards

OpenHIE Architecture and Specification and Testing

Architecture Components (Diagram)
Component functionality

Patient Identity Management across systems
Health Terminology and Metadata Management
Exchange of lab requests and results
Health Worker and Patient Alerting
Disease Surveillance and Reporting
Health Metrics calculation and Reporting

Facility planning and management, including Unique identification of facilities
Unique identification of Health Workers
Tracking and managing health worker capabilities and geographic coverage
Health access and insurance coverage
Health product logistics/ supply chain support and tracking
Health product identification and management

OHIE Architecture Capabilities

What can the OpenHIE architecture do? What does it support?

The answer really depends upon the prioritized needs of the ministry or the implementer. This is a high-level summary of what OpenHIE can do.

In the top layer, we discuss some of the health impacts that the OpenHIE Architecture can have. These impacts can be at the:

Individual patient care level. An example of this would be an architecture that enables creating a comprehensive patient record by combining data from multiple point-of-care systems.
The same data that is used for patient care can also be leveraged for population or public health by enabling data to be combined and aggregated for metrics or monitored for identified health events that need to be tracked and reported to monitor population health.
In addition, data about facilities, health workers and products can be used to plan and respond to needs across the health system. For example, population data can be combined with facility and health worker data to predict and manage facility and staffing needs. We have seen these capabilities used to clearly track health system resources and play vital roles in preparation and response to events like Ebola and COVID.

In the green layer, we highlight some of the capabilities that support patient care, population health and health administration.

In the white layer, you will see some of the OpenHIE artifacts that outline the architecture and how the HIE components engage each other in standard ways to support the capabilities in the green layer and the health information needs in the top layer.

17 of 89

Vignette

17

Pregnant Woman

Community

Care

Clinic

Care

Hospital

Birth

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

This leaves her health data spread across three different systems and her treatment providers are challenged to see a complete picture of care.

18 of 89

Vignette

18

Pregnant Woman

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

With a Health Data Exchange, her records from all three sites can be linked and that link can be used to show a shared view of her health records.

Community

Care

Clinic

Care

Hospital

Birth

Just as it is important to plan roads, water services and other items needed to run a city, having an eHealth architecture and systems that align with that plan contribute with the ability to share information in a way that shares not only the data, but the meaning of that data.

If we look back at our pregnant woman, the use of standardized data exchange can enable capabilities to support bringing together a patient’s data from different point-of-care systems into a record that is a more comprehensive view of the patient’s health. This can then allow:

health practitioners to see the broader view of the patient while providing treatment / a more comprehensive view of the patient’s symptoms and treatments
And create a foundation for metrics reporting that has the opportunity to reduce duplicate counting of patients that have been seen in multiple locations

This is just one example how having an architecture that supports health data exchange can make a difference in the technical capabilities that support individual, community and population health and provide capabilities to manage and plan for health resources.

19 of 89

19

OpenHIE Architecture Overview

OpenHIE Architecture Community and Sub Communities

Architecture Diagram

Component Requirements

Workflows / Data Exchanges

OpenHIE Architecture Specification

OpenHIE is a community approach to creating the patterns for eHealth Architecture and data exchange. We do that by having sub communities that regularly meet to discuss the business challenges related to specific parts of the architecture. In addition, we have an architecture community which serves to make sure that the individual components work together and that the standards needed for sharing information between components are in place or created.

The architecture specification is expected to evolve over time, but include the following components:

The high level OpenHIE architecture diagram
Some high-level requirements for Architecture components
The patterns and standards for data exchange between components

These three artifacts are created in a collaborative community process that enables them to constantly be updated to support new data exchanges and new learning about previous patterns of data exchange.

20 of 89

20

OpenHIE Architecture - Patterns

This is the OpenHIE architecture pattern. In the next sections, we will work through these components in detail. At a high level, the gray box represents the health information exchange. Inside that box, is an interoperability layer that is like the gateway or doorway to the health exchange. The point of service applications, noted in black are the places in the field where the data are collected. These can include EMRs, community health mobile apps, lab systems and pharmacy systems.

The keys to supporting information exchange include having an eHealth Architecture or a plan that establishes the key components needed to support health information exchange and having the standards both messaging standards and terminology standards that allow data to flow between systems in a way that maintains integrity and meaning of the data.

21 of 89

Additional Reading and References

21

22 of 89

Registry Services

23 of 89

23

OpenHIE Architecture - Patterns

This is the OpenHIE architecture pattern. In this section, we will work through these components in detail. At a high level, the gray box represents the health information exchange.

Note that this diagram is intended to be a logical pattern for the components that are necessary to support health data and health data sharing. That means that individual physical implementations may implement the pattern in different ways. I’ll walk through three examples that help illustrate this point:

For example, a project could implement this pattern by having one physical system that plays the shared health record and the client registry components of the architecture.
In a second example, an implementation could have two or more EMRs that are used to capture patient-level data in clinic settings.
In addition, initial implementations may have just a few components that support the needs of the project and therefore not need all of these components to support the initial planned data exchanges.

Each of these cases may be true as initial projects begin to emerge. The main point is that we recommend having a strategic vision that identifies component that are expected to support health in the project, region or country.

The keys to supporting information exchange include having an eHealth Architecture or a plan that establishes the key components needed to support health information exchange and having the standards both messaging standards and terminology standards that allow data to flow between systems in a way that maintains integrity and meaning of the data. This section will focus on explaining the architecture a bit more. Another course will introduce standards for data exchange.

One other note that I’d like to make about the OpenHIE Architecture diagram is that it evolves. As the OpenHIE community engages in additional implementations and identifies different needs for health data, the diagram evolves to reflect and support those needs. Our vision is that all implementers would provide feedback and lessons learned that help expand and tune the architecture patterns over time.

24 of 89

24

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

Starting with the bottom blue row in the OpenHIE Architecture Diagram, there are what we call registries. These registries help identify the nouns in the health data; patients are uniquely tracked in a client registry, health care providers (health workers) are tracked in a health worker registry, facilities are tracked in a facility registry, medications and medical supplies can be tracked in a product registry and medical terms can be tracked in a terminology registry. One of the key features of registries is that they provide unique identifiers for each of these nouns that allow for linking and using data across systems. For example, a facility ID can be established and linked to data being generated by an EMR system or point-of-care system at a specific facility.

Each registry provides ways to uniquely identify patients, health workers, facilities, health medications or products and medical terms.

The rest of this section will focus on looking at each of these registry systems and providing some examples.

25 of 89

Registry Services

(Shared Services)

Water image: Michael Tewelde/USAID Lowland WASH ActivityMichael Tewelde/USAID Lowland WASH Activity

25

26 of 89

26

Client Identity Management

Hosp. B Client ID

Hiwott Patient ID 99999

Hiwott

Hiwott Patient ID 123456

Clinic A Client ID

27 of 89

Client Registry

Client Registry (Enterprise Master Patient Index): a master patient index (MPI), or Client Registry manages the unique identities of citizens receiving health services with the country

Hosp. B Client ID

Hiwott Patient ID 99999

Client Registry

Hiwott Patient CR ID 5555555555
Clinic ID 123456 + demographics
Hospital ID 99999 + demographics

Hiwott

Hiwott Patient ID 123456

Clinic A Client ID

Foundational to the ability to combine patient records from multiple systems that are using their own IDs
Links a patient’s ID in one system with their ID in another system
Provides a unique enterprise identity for that patient

The OpenHIE Architecture allows HIwott’s demographic data from both point-of-care systems to be be sent to the health information exchange client registry (CR) which can also be called an enterprise master patient index (EMPI). Inside the CR there is matching logic to help link the patient demographics and patient IDs from one point-of-care system with another. While the CR doesn’t physically , link medical data from the two system, it does create a way to be able to link the patient’s data from one system with the same patient’s data from another system.

The capability to uniquely identify a patient across multiple systems lays the foundation for more accurate metrics calculations and population health. It also provides a foundation for creating a comprehensive health record for a patient.

28 of 89

28

Health Worker Registry

Health Worker(s)

Qualifications / Certifications

Health Worker Registry (eHIRIS) : a health worker registry uniquely identifies each individual who works within the healthcare system and may track information about their qualifications.

The patients or people served by the health system one of the key aspects of a health information system.

Another key aspect in the health system is the health worker or the practitioner providing some type of care. The provider may not be the key subject of point of case systems, but those systems often track the provider that administered the service, performed the lab test or dispensed the medication. It is important to track who has has served the patient. The HWR allows the common ID for a provider to be established and used across the health system.

In health emergencies or crises like Ebola and COVID, it has been important to understand the types of health workers available and the understanding the geographic distribution of those workers can help with planning for capacities in times of crisis and for supporting the population health.

29 of 89

29

Nigeria

30 of 89

30

Nigeria

31 of 89

31

Facility Registry

Facilities

Geographic hierarchy
Data about the facilities

Master Facility Registry (MFR) : a MFR manages the unique id and attributes of the locations where health services are administered or supported.

Usually supports hierarchy data used for analysis and reporting
Allows for analysis of facility or regional data from multiple systems

32 of 89

32

Kenya - http://kmhfl.health.go.ke

33 of 89

33

Kenya - http://kmhfl.health.go.ke

34 of 89

34

Tanzania

35 of 89

35

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

36 of 89

36

Product Registry

A Product Registry serves as the source of truth about what a Product is within an HIE.

Allows organizations to publish and manage one or more product catalogs including product information and master data management
Should support common product identifiers such as GS1 and mappings between different product catalogs/ identifiers
Provides interoperability
Provides data governance workflows

Like the other registries, we need a distinct way to identify products used across the health system. Products can be a little tricky because the health supply chain may be focused on detailed levels of packaging and manufacturer of a health product and a health provider may be focused on prescribing at an active ingredient level.

This means that how a product like a medication or gloves is understood and discussed depends upon upon the context of use of the product. OpenHIE is working through technical ways to describe products that work in the supply chain, provider and insurance or payer contexts. To provide care, products need to be represented in a way that allows all levels of the health system to interact in ways that enable having medications, vaccines and supplies needed in the right place at the right time to care for patients.

37 of 89

37

Terminology Service

Uniquely defines and identifies both the clinical and M&E concepts throughout the country
Used to align patient-level or indicator-level data across point of service or enterprise-level applications

The last registry I’ll describe is the terminology service registry. This one is a bit more challenging because terminology may not be as obvious to see as some of the other registry components we have discussed so far. However, terminology is one of the keys to interoperability.

For example, the word trolly in US English generally refers to a form of transportation that several people can ride at one time and the British word trolly can refer to a cart or bin with wheels that one uses when shopping or at the airport. As humans, we can use the context to discern the differences in these meanings. However, when computer systems are sharing data, it is important that the meaning of the term is successfully shared. To do this, we use terminology. There is a course that will focus on standards. That course will explain more about the standard health terminologies like ICD-10 that are used in health care settings.

38 of 89

38

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

39 of 89

Additional Reading and References

OpenHIE Architecture - https://wiki.ohie.org/pages/viewpage.action?pageId=8454157
Kenya Facility registry / Master facility list - http://kmhfl.health.go.ke/#/home
Tanzania Facility Registry - http://hfrportal.moh.go.tz/index.php?r=page/index&page_name=about_page

39

40 of 89

Business Domain Services

41 of 89

41

Business Domain Services

Services that support a particular domain and may be used by other HIS systems.

This section is focused on the business domain services located at the top row of the OpenHIE Architecture Diagram. These components service specific domains of the health care system. Many of you are familiar with these types of systems and this section will not be covering each of them in detail.

I will start by briefly describing HMIS (Health Management Information Systems) - Many of you are probably aware of systems like DHIS2 that collect and store health system metrics that are used to understand and manage the broader health system. These systems have three main features:

Store routinely-collected aggregate health care data
Typically uses additional aggregation and visualizations to support data use.
Facilitate analysis with the goal of improving the quality of health services.

LMIS (Logistics Management System) typically bridges the health and supply chain operations

Enabling commodity visibility
Enabling re-supply workflows for clinical locations

Finance and insurance Services

May track information about the different options or payer selections for individuals.

The shared health record may be a bit more challenging to understand. I’ll walk you through a more detailed explanation of that component.

42 of 89

42

Distributed Health Record

Clinic A Client ID

Hosp. B Client ID

Hiwott

Hiwott Patient Records

ANC1 visit data

Hiwott Patient Records

ANC 4 visit data
Delivery data

Health Post

Client ID

Hiwott Patient Records

ANC2 visit data
ANC3 visit data

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

This leaves her health data spread across three different systems and her treatment providers are challenged to see a complete picture of care.

43 of 89

43

Shared Health Record

Shared Health Record : collection of fully normalized person-level data records.

Provides a holistic view of a patient’s medical record
Allows providers working at different facilities to see a patient’s longitudinal record

Hiwot Patient

ANC1 visit data
ANC2 visit data
ANC3 visit data
ANC4 visit data
Delivery data

Clinic A Client ID

Hosp. B Client ID

Hiwott

Hiwott Patient

ANC1 visit data

Hiwott Patient

ANC 4 visit data
Delivery data

Health Post

Client ID

Hiwott Patient

ANC2 visit data
ANC3 visit data

44 of 89

44

The OpenHIE Architecture supports the shared health record through use of several OpenHIE components.

The first is the point-of-care or point-of service systems (shown in the black icons.) These systems collect the data about the patient’s demographic data and the patient’s health care visits.
The point of care data can be shared through the interoperability layer, which will be discussed more in the next section of this training course.
The client registry can link the IDs from the various point-of-care systems.
Finally the shared health record is a collection of the health records for a particular patient.

To fully implement this type of data exchange, other OpenHIE Architecture Components are required. In addition, there are data (semantic) and message standards that are required to share data.

45 of 89

45

Business Domain Services

Services that support a particular domain and may be used by other HIS systems.

46 of 89

Additional Reading and References

46

47 of 89

Putting it All Together

48 of 89

48

49 of 89

49

Interoperability Service

The interoperability layer provides:

a single point of entry for data and requests of the architecture
centralize the logging/auditing of messages
authentication (verifying the machine or process that is sending or receiving data)
authorization (verifying that the machine or process has access to the requested resources)
routing of messages to the correct service provider
mediation functions for transactions in an attempt to simplify the business logic required by service consumer systems

The interoperability layer which is sometimes abbreviated as the IOL is comprised of three main functions; a gateway, a log and a conductor.

First, we can think of the IOL as the door or gateway to the health information exchange. The IOL ensures that only known senders and receivers can participate in sending data to information exchange or retrieving data from the information exchange. This is called authentication. The IOL can also determine which senders and receivers are authorized to send or share information. So the IOL is like a gateway with a gatekeeper that decides what systems can send or receive information and the types of transactions they can perform.
The interoperability layer also logs transactions that go in and out of the HIE
The interoperability layer can also function like a conductor ensuring that messages are routed to registries to translate IDs and terminology.

50 of 89

50

OpenHIE Architecture Overview

OpenHIE Architecture Community and Sub Communities

Architecture Diagram

Component Requirements

Workflows / Data Exchanges

OpenHIE Architecture Specification

Note: OpenHIE also has Exemplar Software demonstrating the workflows, but OHIE is not software

51 of 89

Additional Reading and References

51

52 of 89

52

53 of 89

Workflows - Patterns

(Information Exchanges)

https://ohie.org/architecture-specification/

53

The word “workflow” is used a lot in OpenHIE. In OpenHIE a “workflow” really refers to a data exchange pattern. We have several of them outlined in the OpenHIE specification that is available on the OpenHIE website. I have noted the location of the specification on this slide. The specification is continually evolving, but examples of the workflows are listed on the right side of this slide.

Each workflow outlines how the data moves between the OpenHIE components. On the left side, there is a diagram depicting how the “Create Patient Demographic Record Workflow” sends data from a point of care system, like an EMR or a mobile device, through the interoperability layer. The interoperability layer checks the identity of the sending system and determines if the sending system has the authority to perform this transaction and then routes the patient’s demographics to the client registry. Once inside the client registry, the patient’s identity can be linked with this patient’s records in laboratory systems or other EMR or point of care systems.

There can also be an acknowledgement of the transaction that returns to the interoperability layer and/or the sending point of care system.

Each of the workflows in the OpenHIE specification specifies how the transaction works and outlines the data exchange message protocols that support this exchange of data.

54 of 89

Shared Services Example

Abraham is a child that has been seen by both a community health worker and a clinic worker during the first 4 months of life. While he received immunizations in both service locations, bringing those data together imply being able to uniquely identify similar immunizations from each location (ie, Polio vaccine) as well as distinguishing the service location.

Shared services allow data emitted from both an EMR and a mobile app to be normalized consistently. The Shared Health record allows this normalized data to be made available to the larger enterprise.

54

Shared Services

Master Facility Registry

Health Data Dictionary

iHRIS

Client Registry (EMPI)

Shared Health Record

EMR

Mobile App

Interoperability Service

Data travels from the point of care system, through the interoperability layer.

The interoperability layer authenticates the sender and mediates the rest of the process steps.

Any terminology that is not compliant with the standards is translated.

Patient IDs are translated from the local id to the health system ID

Data is recorded in the shared health record

1.

2.

3.

4.

Here is an example of how the “Save Patient-level Clinical Data Workflow” outlined in the specification might work in practice. Note that these workflows are patterns that can be applied in different contexts with different contraints. The pattern outlines the data exchange standards used for the syntactic standard for sharing data.

In this situation, we note that a Abraham has received a vaccine that was recorded on a mobile app by a community worker and he also received a vaccine at a clinic perhaps during a routine check up. The data exchange process for taking the data that was recorded at both point-of-care systems is similar:

Data travels from the point of care system, through the interoperability layer.

The interoperability layer authenticates the sender and mediates the rest of the process steps.

Any terminology that is not compliant with the standards is translated.

Patient IDs are translated from the local id to the health system ID

Data is recorded in the shared health record

In the diagram, these steps are shown for data coming from the mobile application and for data coming from the EMR.

55 of 89

55

Scenario Exercise

Use the architecture diagram the the future state scenario described on the next slide to:

Identify the OpenHIE components needed to support the scenario on the next slide

56 of 89

56

Background	Fireiwot is a health extension worker who works within the Babo health post which supports the Ancho Health Center. The health post has reliable 3G wireless internet. They have recently implemented a community health mobile app (CHMA) which allows Fireiwot to collect patient-level information electronically. Fireiwot regularly phones community leaders in her catchment area who meet with the mothers-to-be.
Health Post - Mobile App (CHMA)	Fireiwot learns from a community leader that Hiwot, a mother within her catchment has become pregnant. The mother therefore is sent to the health post. At the health post, Fireiwot completes the mobile CHMA registration and the mother’s demographic record (identity) is electronically captured in the mobile system. At the health post, Fireiwot continues to complete the CHMA pregnancy form. At the end of the day, Fireiwot will need to upload the data from her mobile CHMA to the central health information exchange. If it is a new patient, the patient’s identity will be added to the Client registry. In addition, the record of the visit will be added to the mother’s shared health record (SHR).
Clinic - EMR	Kebede, who leads the ANC unit at the Ancho Health Center is able to use the EMR to get the list of pregnant patients in his catchment area. He sees that Hiwot should be coming to the health center for her ANC1. Kebede begins the process to receive Hiwot for her first ANC visit. The Ancho Health Center has recently been fitted with fiber optic intranet services and also maintains an EMR registration and basic MNCH EMR function within the setting. When Hiwot arrives at the ANC Unit at the Health Center, she is given a thorough evaluation and screening, and overall, she appears to be in excellent health. Kebede documents all of these findings in the EMR and that data is then synced with the Shared Health Record. Hiwot then returns home, with an expectation that until the end of her pregnancy, she’ll be supported within her local community and by Firewot.
Health Post - Mobile App (CHMA)	Firewot can access the Shared Health Record information and see the expected due date and other key health data recorded at the Ancho Health Center during the ANC1 visit. Over the course of the next few months, Hiwot participated in a number of peer support events in her community and also completed her second and third antenatal visits with Firewot. As a part of the job, the Health Extension worker (HEW), Firewot, talks about the nutrition status of the family. The HEW measures Hiwot’s arm, after noting that Hiwot has always been a light eater. Over the course of the past few months, she has not gained as much weight as she should. She gave the mother some advice, and they decided to manage this conservatively. All of this information is dutifully gathered and this data are recorded in the mobile CHMA and subsequently synced with the Shared Health Record.
Clinic - EMR	Now eight months into the pregnancy, Firewot reminds Hiwot to go back to the Ancho ANC Unit for her 4th antenatal visit. During that visit, Kebede notes that the nutrition interventions have been working. Hiwot ends up delivering a healthy baby at the PHCU a few weeks later. She names her boy Dawit. Kebede registers Dawit as a new delivery and ensures that the PHCU is prepared to receive him as soon as possible for immunizations and his first well child visit.

Scenario Exercise

57 of 89

57

Scenario Exercise - Answers

Components used to support the scenario:

Depending upon how you interpreted the scenario, the orange components are needed and perhaps you included others like the components highlighted in blue. There is no exact answer to this exercise, the details depend upon the actual project scope and data that is required to be shared. However, depending upon how you interpreted the scenario, the orange components are needed and perhaps you included others like the components highlighted in blue.

To collect the data, a mobile application were the point-of-service applications needed.
The scenario mentions that data from the mobile app and the EMR are synced with the shared health record. To do that, we need an interoperability layer to provide security and routing features for the health information exchange.
Client Registry to link the identities from the mobile application and the EMR.
We also need a shared health record where the patient’s health visit information from the mobile system and the EMR can provide a collective view of the patient’s record.

Identifying the components needed to support a particular health data sharing problem is a first step in moving toward data exchange.

58 of 89

58

Scenario Exercise

Use the architecture diagram the the future state scenario described on the next slide to:

Draw lines to identify the high level data exchanges between the components.

59 of 89

59

Background	Fireiwot is a health extension worker who works within the Babo health post which supports the Ancho Health Center. The health post has reliable 3G wireless internet. They have recently implemented a community health mobile app (CHMA) which allows Fireiwot to collect patient-level information electronically. Fireiwot regularly phones community leaders in her catchment area who meet with the mothers-to-be.
Health Post - Mobile App (CHMA)	Fireiwot learns from a community leader that Hiwot, a mother within her catchment has become pregnant. The mother therefore is sent to the health post. At the health post, Fireiwot completes the mobile CHMA registration and the mother’s demographic record (identity) is electronically captured in the mobile system. At the health post, Fireiwot continues to complete the CHMA pregnancy form. At the end of the day, Fireiwot will need to upload the data from her mobile CHMA to the central health information exchange. If it is a new patient, the patient’s identity will be added to the Client registry. In addition, the record of the visit will be added to the mother’s shared health record (SHR).
Clinic - EMR	Kebede, who leads the ANC unit at the Ancho Health Center is able to use the EMR to get the list of pregnant patients in his catchment area. He sees that Hiwot should be coming to the health center for her ANC1. Kebede begins the process to receive Hiwot for her first ANC visit. The Ancho Health Center has recently been fitted with fiber optic intranet services and also maintains an EMR registration and basic MNCH EMR function within the setting. When Hiwot arrives at the ANC Unit at the Health Center, she is given a thorough evaluation and screening, and overall, she appears to be in excellent health. Kebede documents all of these findings in the EMR and that data is then synced with the Shared Health Record. Hiwot then returns home, with an expectation that until the end of her pregnancy, she’ll be supported within her local community and by Firewot.
Health Post - Mobile App (CHMA)	Firewot can access the Shared Health Record information and see the expected due date and other key health data recorded at the Ancho Health Center during the ANC1 visit. Over the course of the next few months, Hiwot participated in a number of peer support events in her community and also completed her second and third antenatal visits with Firewot. As a part of the job, the Health Extension worker (HEW), Firewot, talks about the nutrition status of the family. The HEW measures Hiwot’s arm, after noting that Hiwot has always been a light eater. Over the course of the past few months, she has not gained as much weight as she should. She gave the mother some advice, and they decided to manage this conservatively. All of this information is dutifully gathered and this data are recorded in the mobile CHMA and subsequently synced with the Shared Health Record.
Clinic - EMR	Now eight months into the pregnancy, Firewot reminds Hiwot to go back to the Ancho ANC Unit for her 4th antenatal visit. During that visit, Kebede notes that the nutrition interventions have been working. Hiwot ends up delivering a healthy baby at the PHCU a few weeks later. She names her boy Dawit. Kebede registers Dawit as a new delivery and ensures that the PHCU is prepared to receive him as soon as possible for immunizations and his first well child visit.

Scenario Exercise

60 of 89

60

Scenario Exercise - Answers

Note: There can be many different answers depending upon how the scenario was interpreted, but these are some key points that should be present.

1a. Patient is registered in the point of care system (in this case the EMR or the mobile system.) The patient’s demographic data is sent through the interoperability layer.

1b. The point of care system ID is stored in the client registry and linked to a unique ID for that patient in the health exchange. The Client Registry will link the IDs from the Mobile system.

1a

1b

1a

61 of 89

61

Note: There can be many different answers depending upon how the scenario was interpreted, but these are some key points that should be present.

2a. The patient visit data is sent to the interoperability layer.

2b. The interoperability layer translates the patient ID from the sender’s ID to the Health Exchange ID in the client registry.

2c. Visit data from the point of care system is stored in the shared health record.

2a

2b

2a

2c

Scenario Exercise - Answers

62 of 89

62

Note: There can be many different answers depending upon how the scenario was interpreted, but these are some key points that should be present.

3a. There is a request to see the patient’s full record.

3b. The interoperability layer translates the patient ID from the requestor’s ID to the Health Exchange ID in the client registry.

3c. The Shared health record receives the request for the patient record.

3d. The record is sent to the interoperability layer.

3e. The record is sent back to the point of care system.

3a

2b

3a

3c

3d

3e

Scenario Exercise - Answers

63 of 89

63

Join us in the Journey

64 of 89

Course Evaluation

64

65 of 89

Course Evaluation

Please proceed to the evaluation questions.

65

66 of 89

Evaluation Question 1

Which architecture component would you use to help create standard facility names and assign unique facility IDs?

CR
FR
SHR
TS

66

67 of 89

Evaluation Question 1

Which architecture component would you use to help create standard facility names and assign unique facility IDs

CR
FR
SHR
TS

A FR (facility registry) manages the unique id and attributes of the locations where health services are administered or supported.

67

68 of 89

Evaluation Question 2

2. In one health district, there is a hospital and a clinic. Mothers may do antenatal care at either facility and may give birth at another. What part of the architecture can help manage a patient's identity across systems?

CR
FR
SHR
TS

68

69 of 89

Evaluation Question 2

2. In one health district, there is a hospital and a clinic. Mothers may do antenatal care at either facility and may give birth at another. What part of the architecture can help manage a patient's identity across systems?

CR
FR
SHR
TS

The CR helps link a single patient’s identity across multiple systems.

A SHR (shared health record) supports data from multiple point of care systems and creates a comprehensive health record for a patient.

69

70 of 89

Evaluation Question 3

3. What component will help ensure that medical symptoms that are used in an EMR can be analyzed with symptoms from a mobile community patient application?

CR
FR
SHR
TS

70

71 of 89

Evaluation Question 3

3. What component will help ensure that medical symptoms that are used in an EMR can be analyzed patient with symptoms from a mobile community patient application.

CR
FR
SHR
TS

A TS (terminology service) manages the medical terminology used in the health system. It can be used to support data standards that are used in other applications or to support mapping terminology from one system to another.

71

72 of 89

Evaluation Question 4

4. What is an example of a point of care system.

A mobile application used to support community health
An EMR used to manage patient records
A pharmacy system used when dispensing medicine and supplies to patients.
All of the above

72

73 of 89

Evaluation Question 4

What is an example of a point of care system.

A mobile application used to support community health
An EMR used to manage patient records
A pharmacy system used when dispensing medicine and supplies to patients.
All of the above

Some examples of point-of-care systems are an EMR or a mobile system which is implemented at a point of care such as a clinic or as an application for a community health worker to use. Laboratory systems and pharmacy systems may also be examples of point-of-care systems.

73

74 of 89

Evaluation Question 5

What is the value of having an enterprise architecture?

It helps create a plan for the different types of data needed to support a health information exchange
Project teams can see the plan and contribute to the health information infrastructure as they build specific solutions.
Having the architecture creates the foundation that allows for reuse of systems and data across projects.
All of the above

74

75 of 89

Evaluation Question 5 - Answer

What is the value of having an enterprise architecture?

It helps create a plan for the different types of data and systems needed to support a health information exchange
Project teams can see the plan and contribute to the health information infrastructure as they build specific solutions.
Having the architecture creates the foundation that allows for reuse of systems and data across projects.
All of the above

Among other things, an enterprise architecture creates value by creating a plan that:

Enables sharing and using data outside of siloed systems
Reduces duplicate effort. Disjointed investments in ICT health projects lead to duplicate efforts and wasted resources.

75

76 of 89

Evaluation Question 6

6. The OpenHIE Architecture Specification provides which of the following information:

A model or diagram for a pattern of service oriented architecture used for health systems
A downloadable version of a health information exchange
Specifications or requirements for the OpenHIE components
Specifications of the data exchanges or OpenHIE workflows
Both a and b
a, c, and d

76

77 of 89

Evaluation Question 6

The OpenHIE Architecture Specification provides which of the following information:

A model or diagram for a pattern of service oriented architecture used for health systems
A downloadable version of a health information exchange
Specifications or requirements for the OpenHIE components
Specifications of the data exchanges or OpenHIE workflows
Both a and b
a, c and d

The OpenHIE Architecture Specification provides:

an architecture diagram pattern
specifications for OpenHIE components such as the client registry and the facility registry
detailed workflows or data exchange patterns that include the IHE standards or other standards that support that data exchange

77

78 of 89

Evaluation Question 7

If I need to create a way to link patient identities from an EMR and a mobile application, which OpenHIE components support that functionality?

Client registry (CR), an HMIS and an Interoperability Layer (IOL)
A facility registry and a terminology service
Both point-of-care systems, a Client registry (CR), and an Interoperability Layer (IOL)
The facility registry and the Client registry (CR)

78

79 of 89

Evaluation Question 7- Answer

If I need to create a way to link patient identities from an EMR and a mobile application, which OpenHIE components support that functionality?

Client registry (CR), an HMIS and an Interoperability Layer (IOL)
A facility registry and a terminology service
Both point-of-care systems, a Client registry (CR), and an Interoperability Layer (IOL)
The facility registry and the Client registry (CR)

The EMR and the mobile app are point-of-service systems that can send their identities through the interoperability layer to the client registry.

79

80 of 89

END

80

81 of 89

81

82 of 89

82

83 of 89

83

Quality Attributes

Quality is a measure of excellence or the state of being free from deficiencies or defects.

Quality may also be defined as adherence to requirements.
Quality attributes are system properties that are separate from the functionality of the system.
Attributes are overall factors that affect run-time behavior, system design, and user experience.

84 of 89

84

Begin to discuss

What is quality in general and in architecture particular

List the quality attributes of an architecture and relate it with OHIE and why do they matter

Categorize the quality attributes

85 of 89

85

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

Starting with the bottom blue row in the OpenHIE Architecture Diagram, there are what we call registries. These registries help identify the nouns in the health data; patients are uniquely tracked in a client registry, health care providers (health workers) are tracked in a health worker registry, facilities are tracked in a facility registry, medications and medical supplies can be tracked in a product registry and medical terms can be tracked in a terminology registry. One of the key features of registries is that they provide unique identifiers for each of these nouns that allow for linking and using data across systems. For example, a facility ID can be established and linked to data being generated by an EMR system or point-of-care system at a specific facility.

Each registry provides ways to uniquely identify patients, health workers, facilities, health medications or products and medical terms.

The rest of this section will focus on looking at each of these registry systems and providing some examples.

86 of 89

86

Quality Cont..

Category	Quality Attribute	Description
Design Qualities	Conceptual Integrity	Defines the consistency and coherence of the overall design. This includes the way components or modules are designed
	Maintainability	Ability of the system to undergo changes with a degree of ease.
	Reusability	Defines the capability for components and subsystems to be suitable for use in other applications

87 of 89

87

Quality Cont..

Category	Quality Attribute	Description
Run-time Qualities	Interoperability	Ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties.
	Manageability	Defines how easy it is for system administrators to manage the application
	Reliability	Ability of a system to remain operational over time
	Scalability	Ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged.
	Security	Capability of a system to prevent malicious or accidental actions outside of the designed usages
	Performance	Indication of the responsiveness of a system to execute any action within a given time interval.
	Availability	Defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period.

88 of 89

88

Quality Cont..

Category	Quality Attribute	Description
System Qualities	Supportability	Ability of the system to provide information helpful for identifying and resolving issues when it fails to work correctly.
System Qualities	Testability	Measure of how easy it is to create test criteria for the system and its components
User Qualities	Usability	Defines how well the application meets the requirements of the user and consumer by being intuitive

89 of 89

89

Quality Cont..

Category	Quality Attribute	Description
Architecture Quality	Correctness	Accountability for satisfying all the requirements of the system.
Non-runtime Quality	Portability	Ability of the system to run under different computing environment.
	Integrality	Ability to make separately developed components of the system work correctly together.
	Modifiability	Ease with which each software system can accommodate changes to its software.
Business quality attributes	Cost and schedule	Cost of the system with respect to time to market, expected project lifetime & utilization of legacy
Business quality attributes	Marketability	Use of system with respect to market competition.