J.1_Appendix_1.0_-_ETHIOPIA_eHEALTH_ARCHITECTURE.pdf

Federal Democratic Republic of Ethiopia

Ministry of Health

ETHIOPIA eHEALTH ARCHITECTURE

Draft v.92 December 2017

DRAFT

Table of Contents

Acronym List 4

1. PURPOSE 5

2. EXECUTIVE SUMMARY 5

3. BACKGROUND 6

3.1 Ethiopia HIS Current State and Challenges 6

3.2 Challenges 7

3.3 Strategic Investment 8

4. WHY eHEALTH ARCHITECTURE? 8

5. eHEALTH ARCHITECTURE VISION 9

5.1 eHealth Architecture Scenario 9

5.2 Other Scenarios 11

5.2 eHEALTH ARCHITECTURE GOALS 11

6. eHEALTH ARCHITECTURE 12

6.1 Overview 12

6.2 Governance 12

6.3 eHA Principles and Guidelines 13

Business Principles 14 Data Principles 14 Technology and Application Principles 15 Process Principles 15

6.4 Standards 16

6.5 eHealth Architecture Schema Components 16

6.5.1 Shared Services 16

6.5.1.1 Health Worker Registry 17

6.5.1.2 Master Facility Registry 17

65.1.3 National Health Data Dictionary (NHDD) 17

6.5.2 Interoperability Service 18

6.5.3 Institution-based HIS and Data Sources 18

6.5.4 Population-based HIS and Data Sources 20

6.5.5 Point-of-Service HIS 20

6.5.6 Analytics & Business Intelligence 21

6.5.6.1. Data Warehouse 21

6.5.7 External Systems 21

7. eHEALTH ARCHITECTURE PROPOSED PHASES 22

7.1 Foundational Phase 22

7.2 Initial Interoperability Phase 24

7.3 Operationalizing Phase 25

7.4 Supporting and Maturing Phase 25

8. eHA CONSTRAINTS 26

ANNEXES 27

Document References 28 Standards 29

Terminology Standards 29 Messaging Standards 29

Work from other Initiatives and Countries 30 Rwanda: Ministry of Health eHealth Coordination Unit 30 United States: Federal Health Architecture 30 United States: Sequoia 31

Acronym List

CHIS Community Health Information System dB Database DUP Data Use Partnership eCHIS Electronic Community Health Information System EDUP Ethiopian Data Use Partnership eHA eHealth Architecture eHMIS Electronic Health Management Information System EMR Electronic Medical Record FMHACA Food, Medicine and Health Care Administration and Control Authority of

Ethiopia FMOH Federal Ministry of Health FR Facility Registry HCMIS Health Commodity Management Information System HIS Health Information Systems HIT Health Information Technology HMIS Health Management Information System HRIS Health Records Information System HSTP Health Sector Transformation Plan ICT Information and Communication Technology IFMIS Integrated Financial Management Information System IOS Interoperability Service IRR Information Revolution Roadmap JSI John Snow Incorporated M&E Monitoring & Evaluation MFR Master Facility Registry mHealth Mobile Health MCIT Ministry of Communication and Information Technology MOH Ministry of Health NHDD National Health Data Dictionary PHEM Public Health Emergency Management (PHEM) PPD Policy & Planning Directorate RHB Regional Health Bureau RHEA Rwanda Health Enterprise Architecture TWG Technical Working Group

1. PURPOSE

The document is designed to outline the current state and the future directions of Ethiopia’s eHealth Architecture. The eHealth Architecture is not a static concept; it is expected to grow and transform as the health needs, policies and priorities of the country grow and change. The key audience of the eHealth Architecture document are the multiple stakeholders that develop, implement and support projects within the Ethiopian Health Information Systems.

2. EXECUTIVE SUMMARY

eHealth Architecture supports the goals of the Information Revolution. The FMoH is committed to ensuring equitable and affordable access to health care services. The achievement of this vision requires among other things a robust health information technology infrastructure that is both affordable and appropriate. eHealth architecture is designed to support this goal, helping coordinate IT choices and ensuring appropriate resource utilization, resulting in minimizing duplication of effort (in choosing, developing, and implementing eHealth systems) and facilitating access and integration of data. As a result, a robust eHealth architecture facilitates improved data quality and data use, interoperability between and across eHealth applications, performance monitoring, and the sharing of information.

The eHealth architecture delineates the different components of the HIS continuum, and identifies the key systems and functionalities that are needed to support the mission and goals of the FMoH. Specifically, this document details the roles and value of eHA, the principles associated with overall health information management, and architectural schemas that support the mission and vision.

In addition, this document includes an initial roadmap that supports the vision of the connected woreda.

3. BACKGROUND

3.1 Ethiopia HIS Current State and Challenges

Over the past decade, Ethiopia has been making strides toward maturing its Health Information System (HIS). In the years before the Information Revolution, the Federal Ministry of Health (FMOH) developed various national eHealth applications to meet specific needs, including Electronic Health Management Information System (eHMIS), Public Health Emergency Management (PHEM), Human Resource Information System (HRIS), mHealth, etc. There is also work underway to develop additional HIS capabilities like the eCHIS and Health Commodity Management Information System (HCMIS) that worked on drug dispensing, stock and other projects across all levels of the health system.

Figure 1. eHealth Architecture Current State

The FMOH is also making strides to enhance infrastructure and connectivity. Improvements to electric power are being made. The HealthNet project is dedicated to deploying a fiber optic (broadband) Internet to health facilities (Health Centers and above). Mobile networks are also being expanded throughout the country. Roads and other infrastructure important to delivery service and care are also being improved. Ongoing progress in improving infrastructure is anticipated.

3.2 Challenges

In 2014-2015, an assessment of the state of Ethiopia’s eHealth solutions noted that eHealth services and applications in Ethiopia were delivering promising results in helping achieve the health sector vision. However, the eHealth initiatives in Ethiopia were characterized as fragmented, with identified duplicated efforts, inadequate ICT infrastructure or planning, and insufficient enabling environments to support eHealth standards, skills, and knowledge as well as limited e-health coordination at multiple layers of the health sector. As many of these initiatives are not institutionalized, the knowledge required to expand and sustain the initiatives is held by localized or regional partners and has not been appropriately transferred to the ministry. In the past, this has resulted in a high dependency on localized or regional partners and limited ability to break down siloed HIS projects.

In addition, health professionals trained in various institutes are not routinely exposed to the eHealth applications during their training. Consequently, the healthcare professionals face challenges when asked to integrate new applications or technology in their workflow.

A preliminary analysis using the Technology Domain of the August 2017 Draft Health Information System Interoperability Maturity Model of Low-Resource Settings shows opportunities for enhancing the current status. This tool divides technology into sub-domains and uses descriptors to denote the level of maturity. When looking at the following sub-domains, the following preliminary assessments were made:

Sub Domain Descriptor Level

National Enterprise Architecture An enterprise architecture for HIS does not exist. Level 1 - Nascent

Technical standards (including standards for data exchange, transmission, messaging, security, privacy and hardware.

No defined or endorsed technical standards exist for use in the country’s HIS data exchange.

Level 1 – Nascent

HIS Sub-systems The country is characterized by standalone sub-systems.

Level 1 – Nascent/ Level 2 – Emerging

HIS interoperability is mainly by single subsystem directly linked to other subsystems to enable basic data exchange.

Recognizing these challenges, the FMOH proposed the development and formulation of a national eHealth strategy to coordinate and streamline the various eHealth initiatives underway in the health sector. This work established the foundation for sustainable eHealth implementation.

Achieving the long-term FMOH strategic goals is dependent upon strong integration of the existing eHealth initiatives with a committed focus to interoperability and standardization (technology/program) without compromising the objectives of each sub-system. Establishing an integrated architectural framework that supports the planning, developing, scaling up, and support of different eHealth efforts is critical to achieving the FMOH strategic goals.

Furthermore, maximizing the potential for the HIS to support Ethiopia’s health care needs requires an intentional effort to create a strategic plan for investment and management of the HIS. This coordinated investment strategy ensures that information and data captured at all levels can be recorded once, and subsequently securely shared and used effectively and efficiently in decision making.

3.3 Strategic Investment

The Information Revolution Roadmap (IRR), published in April 2016, set the strategic objective for investments into digital health systems:

The objective of the Information Revolution is to maximize the availability, accessibility, quality, and use of health information for decision making processes through the appropriate use of ICTs to positively impact the access, quality, and equity of healthcare delivery at all levels.

The IRR presented two pillars - Cultural Transformation for Health Data Use and Digitalization and Scale-Up of Priority Health Information Systems - that would be demonstrated and realized through the implementation of the Connected Woreda. This document outlines and expounds upon the Ethiopian eHealth Architecture that is the foundational framework required to support the objectives of the Information Revolution.

4. WHY eHEALTH ARCHITECTURE?

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

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. This process results in disparate information stored in different locations and formats, making it seemingly impossible for data to be collated, synced and shared. As a result, ministries of health are limited in their ability to develop knowledge, collaborate in care, and understand and trust the reports and population and public health data available for use throughout the health system.

To ensure that information and data can be easily shared across the health system, a blueprint or roadmap of how the systems will interact is required.

4.1 eHealth Architecture (eHA) Benefit The eHealth Architecture is the foundational plan or blueprint that creates a framework for how the HIS subsystems interact. The eHA is created to ensure that information and data can be easily shared and appropriately used across the health system. When implemented, the eHA is a guidance for ICT projects that support the health system. The eHA ensures that systems are developed and maintained to support patient care and the collection and aggregation of population health data. Adherence to the eHealth Architecture, an agreed upon blueprint for HIS systems and data, enables the MOH to share knowledge, collaborate on care, and understand the reports and population health data available for use throughout the health system. eHealth Architecture supports the creation of patient-based longitudinal health records through the establishment of an interoperability layer. This architectural framework creates the HIS system support needed to help achieve health equity.

5. eHEALTH ARCHITECTURE VISION

The vision of eHealth Architecture is to support Ethiopia’s health objectives through establishing, curating, and designing policies and processes that enable HIS subsystems to be interoperable. This is achieved through the development and alignment of eHealth Architecture principles, schema and standards.

5.1 eHealth Architecture Scenario The national eHealth architecture supports the concept of a Connected Woreda. Within the Connected Woreda, health data can be collected, shared and used to support the delivery of patient care, improve health service delivery and equity, and empower the healthcare team and workforce. As a result, the Connected Woreda helps to guide and harmonize all eHealth initiatives through helping envision what is needed to create the enabling environment and the appropriate ICT infrastructure to support this concept. The connected Woreda is a critical goal, though only one of the results of an integrated and supported eHealth architecture.

Scenarios help to illustrate the real world needs of health services, identifying the requirements and components of the eHealth architecture schema and the identified data flow needed for the Connected Woreda. The scenarios help describe the steps, events and actions that occur during the course of an interaction. Scenarios have been developed to guide and inform the eHealth architectural schema, and illustrate the interaction and interface of different data systems.

Scenarios can also be designed to create the vision for how the eHealth Architecture will support the business needs. The following is an example of an aspirational scenario for how the eHealth Architecture can support HMIS reporting and analysis once Connected Woreda and specified components of the eHealth Architecture are in place.

Example 1: eHealth Architecture Monitoring and Evaluation Scenario

The health care providers at Awash Health Center (which has electricity and internet access) see an average of 15 patients per day. They use individual folder, individual diagnosis summary sheet, service card, register books and tally sheets to record patient information. The data on the paper spreadsheets are also aggregated by hand on a monthly basis. Anene works in the Awash Health Center; she is the HMIS focal person at this center. She connects through the Internet to the central DHIS 2 system (at FMOH) to prepare and transmit the required metric data for her Health Center, including the data from the health posts within her cluster. Once any issues have been resolved and quality checks have been performed, she approves the data in the central DHIS 2 system, which is using standardized indicators that are stored and managed in the NHDD system. The data is now ready for Woreda review.

Mulatu works in a connected woreda that has Internet connectivity and electricity. Mulatu is the HMIS focal person for the Woreda that includes the Awash Health Center. Mulatu is also responsible for managing the health center data and entering Woreda level HMIS data into the DHIS 2 system. Before he reviews data for his Woreda, he checks to make sure that any new health facilities are in the central DHIS 2 system. If there are issues, he communicates the changes that need to be made to the MFR and works with the Regional Health Bureau (RHB) to get everything updated. Once the updates are electronically in the MFR and automatically synchronized with the central DHIS 2 system, Mulatu begins to perform the necessary quality checks and identify any quality or other issues with the data reported to his woreda. He records and resolves the issues at the Woreda level or communicates with the health facilities to resolve them.. Once issues are resolved, he approves the data for Zonal review.

Ayelu is the HMIS focal person at Finfine Special Zone. She is responsible for managing (entering) the zone level HMIS data, checking the timeliness, completeness and data quality of the woredas’ data and providing feedback to the woredas in her zone. She follows the FMOH protocols for data review and approval. Once she completes this process and all of the zone data is ready, she elects to approve the data for regional review.

Bizunesh works in the Oromia RHB and her process is very similar to Zonal level except that Bizunesh is reviewing data at the RHB level. Once she has reviewed the data and resolved issues, she approves the data for FMOH review.

Once all of the data is approved by the RHBs, it is ready for review by the regional M&E focal persons at FMOH, PPD. Data analysis and warehouse systems are used to generate reports, and triangulate data from PHEM, nutrition, and other databases that have multiple stakeholders, including some who are outside of the FMOH, who receive the reports. The data is used in a bidirectional fashion and shared with different data contributors at the MOH as well as the RHBs.

5.2 Other Scenarios

The scenario above is just one example of how the architecture can be used to support the HIS.

Based upon health goals and priorities, the following types of data exchange can also be supported by the eHealth Architecture:

● Client-level data exchange for health care facilities

○ Tracking medical services received

○ Tracking death by disease

○ Tracking bed occupancy rate

○ Creation of a longitudinal health record

● Aggregate data exchange to DHIS2

○ From the eLIMS system, count of stock received, consumed or on-hand at a facility level

○ From vaccine or EMR systems, number of children vaccinated

● Standardized data sharing

○ Share facility data between the Master Facility Registry and DHIS 2

○ Share health data dictionary terms with EMR and DHIS 2

5.2 eHEALTH ARCHITECTURE GOALS The eHealth Architecture goals are designed to support the vision of the Information Revolution:

● Presenting a conceptual model for organizing components according to the capabilities that each provides to the enterprise.

● Promoting coordination and reuse by defining and helping evaluate the health information systems, data sources, and capabilities that the FMOH aims to make available to stakeholders throughout the health system.

● Enhancing interoperability by defining minimum terminology and messaging standards that must be used to store and exchange information with components in the architecture.

● Supporting planning and investment by providing a visual roadmap for iterative development of architectural components and capabilities.

The Ethiopian National eHealth Architecture was first presented in the Information Revolution Roadmap and was widely disseminated. The revised eHealth architecture shown here is conceptually similar to the original, with additional information systems and modified categories that more accurately represent how digital health is conceptualized in Ethiopia.

Figure 2 presents the revised 2017 Ethiopia National eHealth Architecture.

6. eHEALTH ARCHITECTURE

6.1 Overview

To realize the vision of the Connected Woreda and additional Ethiopian strategic health priorities, this document articulates the eHealth Architecture goals and components and provides a foundation to ensure that HIS projects and investments are strategically aligned with the Information Revolution and Health Sector Transformation Plan. Additionally, the eHealth architecture will serve as a tool to facilitate consensus on the collective work that is required under the Information Revolution banner.

The Ethiopian eHealth Architecture is a conceptual framework that depicts the information systems, data sources, and integrations that the FMOH proposes to implement and maintain to achieve its strategic goals. The eHealth Architecture illustrates how distinct IT components form a coherent and holistic national HIS that provides an increasingly sophisticated set of business capabilities to the health sector. The Ethiopian eHealth Architecture is designed to help the MOH, regional health bureaus, and their partners achieve the strategic goals of the Information Revolution. Effective leadership and governance, endorsed guiding principles, an enabling policy environment, standards, and procedures are the glue that allow disparate systems under separate management to operate in a coordinated, interoperable, and sustainable fashion.

6.2 Governance

The entire national health HIS infrastructure is supported by governance, policies, standards, guidelines, and procedures to ensure strategic alignment and sustainability. The eHealth Architecture will be a part of the HIS governance structure that is being established at the time of the writing of this document and an eHA Technical Working Group (TWG) will be formed to support it. This TWG would support the development, adoption, management and maintenance of the eHealth Architecture and effectively integrates the eHealth Architecture into the health system.

Figure 2. Ethiopia eHealth Architecture: Future State

6.3 eHA Principles and Guidelines eHA Principles are the underlying guidelines that ensure that eHealth investments and technology projects supporting the Ethiopian health strategy and objectives are executed in a way that maximizes technology and strategic investments. In a complex organization such as the Ethiopian Ministry of Health, a set of widely understood principles is foundational to providing consistent ways of making technology decisions and applying technology investments.

Ethiopia has defined eHA Principles that enable a multi-faceted framework for aligning investments with the eHealth business strategy, governing and protecting data, defining strategy for technology and applications and establishing human-centered processes. These principles form the foundation for the eHA policies, procedures, and guidelines that will need to be developed.

Business Principles These principles define how the eHealth Architecture will support the Health and/or eHealth goals and objectives of the Ministry of Health.

Principle Name Description / Rationale

1. Maximize benefit to the health ministry and the eHealth strategy

The eHealth Architecture guides the development of solutions in alignment with the Architecture Vision and the eHealth Strategy. Adherence to the Architecture Principles enables the evolution of an architecture that is aligned to support eHealth vision for Connected Woredas and use of data at multiple levels of the eHealth system.

2. Inclusiveness The Federal Ministry of Health partners with the broader Ethiopian eGovernance initiatives to ensure that policies are consistent; all levels of the Ethiopian Health system adhere to the Architecture Principle.

3. Build for sustainability HIT investments and projects will plan for sustainability from the start, including planning for long-term financial health e.g., assessing total cost of ownership.

4. Solutions are based upon the eHealth business needs and reference architecture

Solutions will be based upon eHealth business strategy and real business needs;

the eHealth Architecture guides the design and delivery of solutions to support these needs.

5. Leverage existing investments

The country’s eHealth solutions will leverage maximum benefit from existing eHealth investments that can be aligned with the eHealth reference architecture.

6. Ensure Accountability eHealth governance teams, project teams and operations organizations will ensure accountability by making roles and responsibilities clear.

7. Expect Transparency Decision making is visible and accessible, making clear where, when and how decisions are reached

Data Principles Data Principles define how the eHealth data will be governed, curated and protected, and shared.

1. Information is treated as an asset and is governed

Data and information are assets and are managed and governed accordingly. Each data element has a data steward responsible for the definition of the data and ensuring that there are processes to ensure accuracy, and reliability. There are defined rules on who can create, modify, view and delete data.

2. Policies including Privacy, security, confidentiality and management of electronic data and data matter

Appropriate data use policies are developed that support the privacy and security guidance. All information is secured against unauthorized access, modification or loss.

Consider the context and needs for privacy of personally identifiable information when designing solutions and mitigate accordingly. Specific governance exists around data archiving and storage.

3. Endorse Common vocabulary and standards

Common vocabularies are defined, curated and endorsed through the eHealth Architecture governance model. Definitions are understandable and available to all users and systems for consistent use throughout the eHealth System.

Technology and Application Principles Technology and application principles define approaches for technologies and applications that are designed to enable the best service and a good user experience. The principles should be above any specific technology.

1. Ease of use Applications are designed to be easy to use for end users as well as other consumers; the underlying technology is transparent to users, so they can concentrate on tasks at hand.

2. Develop for common and replicable use

Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization. There is an intentional goal to decrease silos of systems and data.

Process Principles Process principles guide the processes for how technology projects are approached.

1. Design with the user in mind

Include representatives of stakeholders in planning, design, development and assessment of solutions. Develop context appropriate solutions informed by user needs. Human Centered Design (HCD) methodologies are employed when and where appropriate.

2. Be data driven Design projects so that impact can be measured at discrete milestones with a focus on outcomes rather than outputs.

3. Use open when possible

To promote interoperability and innovation, use open standards, open source and open innovation whenever possible. Commit to open data as appropriate.

6.4 Standards

Sharing data requires a mutual understanding of what the data is, what it means, and an accepted way to share it. Interoperability is the ability of an application or platform to establish a data exchange with another application or platform. For interoperability to occur, both services must use the same syntactic and semantic standards for communication. Syntactic standards, also referred to as messaging standards, describe the transport or messaging mechanism by which collections of data are transmitted; they can be thought of as the “envelope” or “container” carrying information. Semantic standards, also referred to as terminology standards, describe the actual content to be contained in the message or “envelope”; they standardize common clinical and administrative concepts, as well as other healthcare metadata. Examples of common “semantic” standards include ICD-10, LOINC, RxNorm, and SNOMED, among others. NHDD is one of the tools that is designed to support the sharing of standard terminology. Use of these two types of standards enables interoperable communication between systems.

In addition to the interoperability standards, there may be additional country level standards that are required to support the national health system. These may include information security standards, requiring specific applications to support a defined set of functional capabilities or the ability for a specific architecture component to support a specified minimum data set. For example, a country may require that an Electronic Medical Record (EMR) systems adhere to specific information security requirements, have specific functions or collect and manage specified minimum data about a patient.

6.5 eHealth Architecture Schema Components

6.5.1 Shared Services

HIS typically have data and functions that are used across business processes and applications. This often results in redundant

Figure 3. Future State – Shared Services lists with disparity. Curation efforts can be reduced and opportunities for data sharing and exchange, as well as timeliness and data quality, can be increased by using shared services. A shared service is designed and developed to provides data or information that are used by other HIS. Shared services are designed to support interoperability and standards by providing authoritative sources for data that is used throughout the eHealth system. Examples of shared services include:

6.5.1.1 Health Worker Registry

A Health Worker Registry (HWR) is software that is used to host and curate an authoritative list of health workers (as well as information about those health workers) within a health system.

Other information systems within the architecture can use the HWR to identify the health worker that provided a particular service.

An HWR typically contains data such as

● Health worker name

● Unique health worker identifier

● Health worker credentials

6.5.1.2 Master Facility Registry

A Master Facility List (MFL) is the complete, authoritative listing of the health facilities in a particular country. It is the primary source from which other facility lists in the country are drawn and must be validated, continuously updated, and accessible. It contains data such as

● Facility name

● Unique facility identifier

● Location (coordinates)

An MFL is stored and curated in a Master Facility Registry (MFR), which is software that makes the list accessible to stakeholders such as ministries, donors or implementing organizations that need information about facilities. The MFR enables facility planning and curation.

65.1.3 National Health Data Dictionary (NHDD)

The National Health Data Dictionary (NHDD) is the authoritative source for medical terminology. While one of the initial priorities is to support indicator and data standards within the health system, the dictionary provides a common language for clinicians, lab technicians, pharmacists, and administrators to communicate and exchange health information to ensure that meaning is not lost as data is shared or aggregated into reporting systems. The NHDD is currently populated with indicators and data definitions from the HMIS Data Recording and Reporting Guidelines, the National Classification of Diseases (NCoD), and the Community Health Information System (CHIS) Guidelines. The NHDD defines mappings between the NCoD and the World Health Organization International Classification of Diseases version 10. In the future, NHDD is expected to be expanded to other domains, such as the medicines, services/procedures and supplies.

6.5.2 Interoperability Service

An Interoperability Service layer mediates the exchange of health information between information systems in the eHealth architecture. In the current architecture, applications operate independent from one another or have a point-to point exchange established. The result is disaggregated and non-harmonized data collected by multiple applications and stored in different locations and formats that cannot be integrated. Those who manage and oversee the health system have to spend time manually identifying data needs, collecting, normalizing, and then tabulating data in order to make inferences from these data for monitoring and evaluation purposes. This manual intervention may cause inaccuracies or inability to report at the detail or timeliness needed to provide healthcare personnel with the data to make life-altering decisions for their population. As Ethiopia expands the connectivity with Woredas, there is potential for exponential growth in the number of systems that could be connected and sharing health data. The eHealth Architecture includes an interoperability layer that is key to the exchange of information.

The Interoperability Layer (IOL) will facilitate interoperability between the Ethiopian eHealth Architecture by providing the architecture and specifications (and identifying reference technologies) for connecting the components within the Ethiopian Health Architecture.

The interoperability layer will provide a single point of entry into the services of the eHA stack.

It should centralize the logging/auditing of messages, the handling of authentication and authorization, and the routing of messages to the correct service provider. In addition, it can provide additional mediation functions for transactions in an attempt to simplify the business logic required by service consumer systems, and facilitate data normalization post data acquisition at point of care and tasks such as the transformation of messages and message orchestration into appropriate standards and terminology standards.

6.5.3 Institution-based HIS and Data Sources

These are data sources and systems that are designed to support key FMOH data and processes. These Institution-based HIS and Data Sources are administered centrally and support institutional capabilities of the FMOH. The eHealth architecture supports a way to exchange data with these resources as business processes require. This data will also be

Figure 4. Future State – Institution-based HIS available to the Analytics and Business intelligence components.

Figure 5. Future State – Population-based HIS

Figure 6. Future State – Point-of-Service HIS

6.5.4 Population-based HIS and Data Sources

Population-based HIS and Data Sources collect data directly from the population often through surveys. These include systems that provide services like improving indicator denominators using counts of births and deaths. The eHealth architecture supports a way to exchange data with these resources as business processes require. This data will also be available to the Analytics and Business intelligence components.

6.5.5 Point-of-Service HIS

Point-of-Service HIS are used by health workers throughout the different levels of the Ethiopian Health system to facilitate service delivery.

Examples of these types of systems include systems for reporting infectious disease that trigger case investigations and systems using mobile devices to register a household. These systems will be connected to Institutional and shared systems through the Interoperability Layer. As the development and use of these systems increases, the need for sharing data with other HIS systems and services will increase. The eHealth architecture is designed to facilitate interactions between these systems and the other HIS systems and services through the interoperability layer.

Figure 7. Future State – Analytics and BI

6.5.6 Analytics & Business Intelligence

Traditionally, M&E has been considered to supply the needs of analytics and business intelligence (ABI). As a HIS system matures, additional ABI needs are identified. The eHealth Architecture is designed to support Analytics and Business intelligence components. These components are a technology-driven approach to enhance strategic and operational decision-making by consolidating and analyzing data across organizational units. Data systems support the acquisition of data, and a data warehouse or data storage platform provides a place for data to reside within a structured model. Analytics and visualization software are dependent upon the data sources included in the ABI pillar.

6.5.6.1. Data Warehouse

One component in the Analytics and Business Intelligence section of the Architecture is a Data Warehouse. A health data warehouse facilitates comprehensive analytics and business intelligence designed to enhance and support data use for decision-making within the health system. This result is achieved through the inclusion of multiple data sets that are important adjuncts to health care (for instance, health data could be commingled with educational data, environmental data, etc.). In addition, a data warehouse provides added technical value by facilitating query and reporting across disparate data systems that are not used for production data creation and curation workloads. Data segmentation is supported through comprehensive metadata models, supporting the needs of multiple stakeholders and end users. Using the data to support the analytics and visualization needs to appropriate reports helps provide the needed business intelligence and supports monitoring and evaluation. Analytics allows the MOH to extract the data, analyze trends, discover new relationships between care and the community, and improve effectiveness while continuing to inform strategic and operational decisions in an efficient and effective manner.

6.5.7 External Systems

There are scenarios and cases where external systems, systems outside the FMOH governance process, may be consumed within the eHA

Figure 8. Future State – External Systems framework. However, unlike the other data sources, the eHA framework does not facilitate production data to be shared with these systems. The eHealth Architecture is designed to support these interactions through the Interoperability Layer. Examples of these systems include agricultural data, education data and meteorological data.

7. eHEALTH ARCHITECTURE

PROPOSED PHASES

The following is a proposed phased approach for instantiating the architecture with DRAFT timelines offered

7.1 Foundational Phase

The Foundational Phase is designed to focus on the structural elements of the architecture and designing and establishing the processes to support it. The following include the eHealth Architecture Goals for the Foundation Phase.

2018 and 2019

Activity 2018 Q1

Q2

8 Q3

Q4

Q1

Q2

1. Perform analysis of current HIS application landscape

Identification of applications that are currently in use will be done through the proposed application inventory. Applications will be initially curated in a registry, with appropriate taxonomies developed to help establish a searchable enterprise architecture repository with appropriate attributes. This database will help inform future application need as well as development

2. Complete design and endorsement of an aspirational target eHA

Development of business and informational architecture based on functions, requirements and actors.

3. Identification and Implementation of Shared Services consistent with eHealth architecture

This phase includes identifying and supporting core information, data, and applications infrastructure that will ensure the eHealth Architecture meets actual needs.

This will be done through a requirements process that results in identification and documentation of appropriate shared services. Projects underway at the time of this document include development of shared services, like the master facility registry (MFR) or the national health data dictionary (NHDD). Potential additional shared services include a master person index.

4. Development of eHA processes, capability assessments and training documentation

Partner with stakeholder representatives to develop processes for aligning HIS projects with the eHealth Architecture and architecture principles.

5. Development (if appropriate) of additional key institution-based HIS and Point-of-Service HIS applications or modules

Applications like the health management information system (HMIS) or point of service HIS, like eCHIS, may need to be developed. Each project puts in place requirements that may have a dependency on one or more information systems. A definitive process will be established that supports the decision making process for development or acquisition of new HIS applications or modules.

6. Identify and approve core interoperability standards

Identify core terminology and messaging standards and utilize governance processes to get them approved.

7.2 Initial Interoperability Phase

The initial Interoperability Phase is designed to focus on the interoperability functionality of the eHA. Based upon Health system priorities and needs, the Initial Interoperability Phase should include the following types of activities:

2018 and 2019

Activity 2018 Q1

Q2

Q3

Q4

Q1

Q2

1. Identify and prioritize scenarios for data sharing in support of the Ethiopian MOH data use priorities

Based upon Ethiopia’s health goals, identify, document and prioritize data sharing scenarios.

2. Instantiate a design for the interoperability layer Determine requirements for software supporting the interoperability layer. use these requirements to guide software selection and stand up the interoperability layer service.

3. Identify risk matrix and subsequent risk mitigation plan

4. Pilot interoperability Select transactions and exchange processes to pilot and develop the workflows that need to be supported in the exchange process.

7.3 Operationalizing Phase

The Operationalization Phase is designed to ensure that the processes and structures defined in the foundational phase are documented and that stakeholders are appropriately trained.

1. Running eHealth Architecture and Governance Processes Having regular TWG meeting and performing, curating and refining eHealth Architecture

2. Maintaining and supporting the HIS application landscape

Developing and implementing processes to maintain and support the application inventory.

3. Curating the eHA current and future states

Development of business and informational architecture based on functions, requirements and actors.

4. Identification and Implementation of additional HIS and Shared Services consistent with eHealth architecture As new business cases come forward, new HIS and share services may be necessary.

Processes to identify these and add them to the architecture will be operationalized.

5. Deployment of eHA processes, capability assessments and training documentation

Deploy appropriate training materials for multiple stakeholders, including strategic, tactical and operational stakeholder needs. It is critical to include the regional and zonal level representatives in this process. This will help ensure appropriate linkages are established both within and between different sectors and geographic areas.

7.4 Supporting and Maturing Phase

This phase includes all of the activities in the Operational Phase plus the following additional items:

1. Evaluating and Reviewing Processes to respond to changing needs Having regular schedules for evaluating eHealth Architecture processes to ensure they are meeting new or changing needs.

2. Defining and implementing metrics for evaluating eHealth Architecture processes and value Defining, capturing and using metrics to determine the value that the eHealth architecture processes are providing.

8. eHA CONSTRAINTS

Developing, supporting and ensuring the success of an eHA initiative, including interoperability, is a large undertaking. Necessary human and fiscal resources must be available throughout the lifecycle to increase the chances of success. Part of the planning process will include the development of identified risks that are integrated into a risk matrix with proposed mitigation strategies. See 7.2 above for documentation.

ANNEXES

Document References

Ethiopian Federal Ministry of Health. (2015, October). Health Sector Transformation Plan 2015/16 - 2019/20 (2008-2012 EFY). Retrieved December 05, 2017, from http://www.moh.gov.et/sl/web/guest/-/health-sector-transformation-plan?inheritRedirect=true

Ethiopian Federal Ministry of Health. (2016, April). Information Revolution Roadmap. Retrieved November 07, 2017, from http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F- %252F---163%253FinheritRedirect%253Dtrue%2526

Federal Ministry of Health. (n.d.). Ethiopian National eHealth Strategy 2013-2015, Ver. 1 April, 2012 (Draft). Retrieved from https://drive.google.com/file/d/1nC7mr8AuhiDmhGQXRsaY_FKllWoiXXDF/view?usp=shari ng

Ingun, P., Narkpaichit, C., & Boongerd, P. (2015). Thailand Health Information System Improvement Through Universal Health Coverage Implementation. Retrieved December 07, 2017, from http://tmi.or.th/jtmi/wp-content/uploads/2015/07/4.5-Thailand-Health- Information-System-Improvement-Through-Universal-Health-Coverage-Implementation- Pianghatai-Ingun-Chirod-Narkpaichit-Prasit-Boongerd.pdf

MEASURE Evaluation. (2017, August). Draft MEASURE Evaluation Health Information System Interoperability Maturity Model for Low-Resource Settings . Retrieved November 09, 2017, from https://drive.google.com/file/d/0BwaERMI3v-rpLVJNYzV5TVNRYUE/view

The Federal Democratic Republic of Ethiopia. (2016, September). The National Information and Communication Technology (ICT) Policy and Strategy. Retrieved November 07, 2017, from http://www.mcit.gov.et/web/english/the-national-ict-policy http://www.moh.gov.et/sl/web/guest/-/health-sector-transformation-plan?inheritRedirect=true http://www.moh.gov.et/sl/web/guest/-/health-sector-transformation-plan?inheritRedirect=true http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F-%252F---163%253FinheritRedirect%253Dtrue%2526 http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F-%252F---163%253FinheritRedirect%253Dtrue%2526 http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F-%252F---163%253FinheritRedirect%253Dtrue%2526 http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F-%252F---163%253FinheritRedirect%253Dtrue%2526 http://www.moh.gov.et/bg/web/guest/-/information-revolution-roadmap?inheritRedirect=true&redirect=%2Fbg%2Fweb%2Fguest%2F-%2Fnational-strategy-for-prevention-and-control-of-viral-hepatitis%3FinheritRedirect%3Dtrue%26redirect%3D%252Fbg%252Fweb%252Fguest%252F-%252F---163%253FinheritRedirect%253Dtrue%2526 https://drive.google.com/file/d/1nC7mr8AuhiDmhGQXRsaY_FKllWoiXXDF/view?usp=sharing https://drive.google.com/file/d/1nC7mr8AuhiDmhGQXRsaY_FKllWoiXXDF/view?usp=sharing http://tmi.or.th/jtmi/wp-content/uploads/2015/07/4.5-Thailand-Health-Information-System-Improvement-Through-Universal-Health-Coverage-Implementation-Pianghatai-Ingun-Chirod-Narkpaichit-Prasit-Boongerd.pdf http://tmi.or.th/jtmi/wp-content/uploads/2015/07/4.5-Thailand-Health-Information-System-Improvement-Through-Universal-Health-Coverage-Implementation-Pianghatai-Ingun-Chirod-Narkpaichit-Prasit-Boongerd.pdf http://tmi.or.th/jtmi/wp-content/uploads/2015/07/4.5-Thailand-Health-Information-System-Improvement-Through-Universal-Health-Coverage-Implementation-Pianghatai-Ingun-Chirod-Narkpaichit-Prasit-Boongerd.pdf https://drive.google.com/file/d/0BwaERMI3v-rpLVJNYzV5TVNRYUE/view

Standards

The list of standards will be determined by the business scenarios that Ethiopia needs to support. The list is expected to grow and change over time. At the time of publishing, the following standards are beginning to emerge. As the eHealth architecture progresses, the standards will need to be documented and stored in a way where all ICT and HIS stakeholders can access and reference them.

Terminology Standards The following terminology standards are being used to support semantic interoperability in Ethiopia. This list is a living list and is intended to be curated as additional scenarios are supported by the architecture.

Clinical Use Standards Mapping Diseases The National Classification of Diseases is a subset of the WHO International

Classification of Diseases version 10 (ICD-10) with some extensions to capture additional granularity for locally significant diseases.

Medication/ Pharmaceutical

The Food, Medicine and Health Care Administration and Control Authority (FMHACA) maintains the a code list for pharmaceuticals, essential medicines and supplies in the country.

Messaging Standards The messaging standards will be based upon the

Clinical Use

Standards Mapping Name Definition

Work from other Initiatives and Countries

The following is an overview of work from initiatives or other countries that was used to serve as a benchmark for the foundational work on the Ethiopian eHealth Architecture. This is not intended to be an exhaustive list.

Rwanda: Ministry of Health eHealth Coordination Unit

Summary

The Rwanda Health Enterprise Architecture (RHEA) initiative is focused on defining, developing and implementing a health enterprise architecture for Rwanda. The initiative supports Rwanda’s eHealth programme.

Program goals

The first phase is focused on the maternal healthcare domain, and the main objectives are to:

● Evaluate the impact of a Health Information Exchange (HIE) on the maternal healthcare delivery system in Rwanda.

● Develop a pilot implementation of the HIE ( based on OpenHIE) on the maternal healthcare delivery system.

The project has focused on identifying and defining high level architecture for the health domain in Rwanda, appropriate standards, functional requirements and interoperability profiles across multiple domains.

Key program components

This programme will define and configure the foundational components of the proposed enterprise architecture of the HIE, including client and provider registries, terminologies and a shared health record. It will also develop governance capacity in Rwanda through an advisory committee that develops a phased approach for training coverage for the pilot and then expanding to a train the trainer approach. The main deliverables are the building blocks to support the specific domain identified of maternal health. (Source: www.jembi.org)

United States: Federal Health Architecture

The Federal Health Architecture (FHA) is a…