2.1 Step 1: Identifying leadership structures and roles
2.1.1 Determining leadership and structure
The Broadband Commission’s Working Group on Digital Health states that, “strong leadership, intersectoral collaboration and clear governance are essential for effective implementation of a national digital health strategy.” To develop a harmonized overall health information system in Tanzania, it was crucial to identify the leadership and governance structure for the HIE, including coordination, partnerships, and financing. MCSP’s primary activity was to support a Ministry-led process that brought stakeholders together to review key concepts and global models, review national applications, develop a common vision, and determine high-level requirements for a comprehensive HIE framework.
Through these discussions, the MOHCDGEC and its development partners defined the high-level data exchange framework that leverages digital health technology to improve key aspects of the health system; achieve the strategic objectives of the Fourth Health Sector Strategic Plan (HSSP-IV); and identify the eHealth system’s architecture objectives, priorities, and gaps. A governance structure was established (Figure 2) under the leadership of the Permanent Secretary of the MOHCDGEC as the chair of the National eHealth Steering Committee. The Ministry’s ICT unit served as the secretariat, and a Project Management Office (PMO) was formed to coordinate development of multiple elements of the HIS. Under the PMO, four technical working groups (TWGs) were created: care delivery, health care resources, decision support, and interoperability. More than 25 government subject-matter experts from national hospitals, partners, and local and regional government offices took part in the development process and participated in a range of steering committees and working groups.
2.1.2 Fostering discussion and education
To facilitate discussion among the partners and stakeholders, the Ministry held a series of meetings and workshops. The process included review of case studies to examine examples used by other projects and countries, and brainstorming sessions to identify issues and understand key concepts (e.g., measuring change). After intense discussions, participants voted on priorities and approaches, and drivers and challenges were addressed at multiple points in the process. Detailed timelines are described in Figure 3. Among the mechanisms used were:
- A National eHealth Steering Committee to review and give feedback on the Tz-HIE Project charter.
- Tz-HIE TWG was created to review and provide feedback on the requirements specifications.
- Various stakeholder workshops were held on use cases, Requirements Specifications solicitation, governance principles, acquisition strategy, and development.
- A high-level stakeholder meeting was held and officiated by the Permanent Secretary of the MOHCDGEC.
2.1.3 Clarifying stakeholders’ roles
Coordinating participating organizations within Tanzania’s eHealth system also required an understanding and alignment of their roles, since each organization operated under its own legal, technical, and political parameters. A situational analysis was conducted to determine the legal and technical environment, governance, data standards, and systems within each participating organization. Decision-makers in some organizations were hesitant about participating, and it was vital to hold meetings with organizational leaders and staff to determine logistics and partner commitments—timelines, legal implications, implications for information technology, and roles and responsibilities.
The Permanent Secretary for Health led the process, which helped to reaffirm the government’s commitment to support the Tz-HIE and improve the country’s overall HIS development. This proactive approach to engagement enabled the MOHCDGEC and partners to increase their ownership of and capacity to manage the Tz-HIE.
Box 1. Business Use Cases to Demonstrate Interoperability
A use case is an explicit, fully documented description of an activity or business/task to be performed, including interactions between multiple people, groups or systems. For example, in the case of maternal health, antenatal care is provided by multiple health workers (doctors, nurses, midwife) at different levels of the health system. The use case will define these interactions and identify the data exchange requirements across these multiple systems. The description includes the stakeholders, the inputs needed for the task, the purpose of the task, and what the task is expected to produce. The primary actors and their responsibilities are also identified. The MOHCDGED employed use cases to demonstrate improved health information transfer between national and sub-national information systems.
2.2 Step 2: Defining public HIS priorities
Once the governance structure is in place, the TWGs focused on the second step to identify the biggest data challenges that could be addressed via interoperability—development of a “middleware” function (see further details in Step 3 below). This brought together senior Ministry officials and partners to identify, prioritize, and develop use cases, including detailed documentation of requirements and specifications (Box 1); gather input from stakeholders; customize and configure the system; and test the system based on use case specifications.
Based on the prevailing challenges and the Ministry’s immediate needs, the project team engaged specific stakeholder groups to develop four major use cases to enable:
- Client-level data exchange for priority hospitals, especially national and specialized hospitals. It has been difficult obtain data from these facilities, since they do not report through DHIS2. There was a need to track the performance in these hospitals on a regular basis, looking at bed occupancy, services delivered, deaths occurring, and revenue collected. Stakeholders for the development of this use case included hospital technical and administrative staff.
- Aggregate data exchange of commodity data (eLMIS) alongside service delivery data (DHIS2), to enable managers to analyze what medical commodities were consumed and what services were delivered. The stakeholders in this use case included the Medical Store Department (MSD) team, program monitoring and evaluation experts, and the DHIS2 team.
- Extraction and cross-system sharing of data from the Health Facility Registry (HFR) with other systems (DHIS2, Vaccine Information Management System, electronic Logistics Management Information System, and others). This was considered important because health facility details are constantly changing from being open, closed or changed to a different grade. It was essential to have a master list of operational facilities that can serve as a source of truth and can update other systems of any changes on the status of the facilities.
- Facilitating the exchange of health commodities stock status from Medical Store Department Epicor 9 to eLMIS, to ensure that supplies are available when needed throughout the system.
Requirements for each of the defined use cases were grouped into functional and system requirements. Functional requirements describe what the system should do—such as its ability to exchange client-level data in a single repository, search for records with data quality issues, and so on. System requirements describe how the system should perform: this includes functions such as queuing, translating, error messaging, etc.
The team observed several challenges with improving electronic data exchange:
- A variety of digital tools to support various domains in the health sector, e.g., DHIS2, eLMIS, HRHIS, HFR, and others.
- Use of different Electronic Medical Records (EMRs) by public and private health facilities use based on their need and process.
- Non-standardization of data across multiple systems. Few systems have adopted any data standards for recording information.
- Most of the systems e.g. EMRs from Hospitals are missing APIs for integration.
- Non-existence of standardized unique identifiers of individual clients/patients in the Tanzanian health sector.
2.3 Step 3: Designing Health Information Exchange architecture
2.3.1 The Enterprise Architecture approach
The Tanzanian Public Service Management and e-Government Agency of the President’s Office developed the national Enterprise Architecture (EA) Approach, national EA policy standards, guidelines, and an operations manual in 2013 to ensure seamless exchange of health information [39-42]. The Tanzania EA focused on putting the user first, particularly health care workers and data users, to highlight the decisions they make to provide effective care. Consequently, Tanzania’s EA approach required all digital health stakeholders to incorporate interoperability, open standards, flexibility, collaboration, and technology into their designs.
The EA approach helps identify information needs across multiple domains and health sector building blocks . The Ministry of Health, Community Development, Gender, Elderly and Children chose the EA approach to help define and frame data exchange and interoperability across levels and health domains. This approach defines the health sector as an enterprise, in contrast to the domain-specific (i.e., service delivery, supply chain, etc.) traditional approaches to HIS development. EA enables a more harmonized development of HIS and facilitates identification of data exchange needs between domains.
The major focus in this activity was on the application architecture—the behavior and interactions of the applications used within a business or enterprise. At the higher level, the Tanzania HIE model provides a structural conception that describes how components fit to one another to share and exchange information. At lower levels, the HIE requires detailed interactions between various components of service delivery and systems for a specific service delivery area. For example, unique identifiers are required to track continuity of care, integrated care, insurance coverage, referrals, etc. The system architecture “maps” these processes and guides development of a harmonized system.
2.3.2 Collaborative decision-making on system elements
Developing this system was time-consuming and required continuous collaboration and feedback. Throughout the five-year process of design and implementation, Tanzania incorporated input from partners and stakeholders, using a collaborative approach to ensure that the system would meet health sector needs, be easy to learn and use, incorporate the principles and products associated with EA and open access, and promote buy-in.
The National eHealth Steering Committee provided overall leadership and governance for the HIE operation; and the Ministry’s ICT Unit served as the secretariat and management office or PMO. The Tz-HIE blueprint (Figure 4) represents a dynamic environment that adapts to changing business, information technology, and data requirements.
The activity in general provided an opportunity to look at the broader health sector-wide need for data and the functions of the proposed data exchange. Once this was done, the next step was to develop use case-specific data exchange architectures and identify components that need to work together. For the purpose of use case 1, the following components of the architecture (Figure 5) were identified as essential:
- Health Information Mediator: Information sharing and exchange across systems is mediated through a middleware, the Health Information Mediator, or HIM (shown in Figure 4). A mediator is an essential component of integrated system architecture that facilitates data exchange across multiple systems. It manages functions such as authentication, queuing of messages data translation and data quality check. As of early 2019, the HIM began integrating data across five health domains—Hospital Information Management, mHealth, HMIS, Immunization, and Logistics—each with corresponding sub-domains and their data. HIM implementation addresses the challenges of the point-to-point data exchange by reducing the number of changes that are required to be made to all system connections when one system is modified.
- Health Data Repository or HDR: A database to act as a central repository for all client data collected from multiple hospitals. The repository provides managers access to a real-time from multiple hospitals in a single database.
- Terminology services: Houses data standards and data quality protocols and ensures that all transactions are meeting the defined standards and quality protocols.
- A dashboard: To provide visualization and analytical features of performance across multiple health facility activities through the HDR.
The Ministry is now using the HIE conceptual model to align investments and harmonize future development in a national health information system that uses integrated digital technology to provide data for improved decision-making at all levels of the health system.
2.3.3 Standardizing data and codes for interoperability
Information sharing through the HIM, and comparison of information across multiple facilities, required harmonization and standardization of service codes. Once the use cases were defined and the architecture designed, the next steps entailed identifying and adopting standards to enable data exchange. For use case 1, a list of data standards were identified, including ICD10 codes for diseases and mortality data and Current Procedure Terminology (CPT) codes for recording procedures. In relation to data standards for use case 1, the PMO team observed that:
- All hospitals were using ICD10 codes for recording disease and mortality information.
- Participating organizations had different custom-made service codes, thus rendering it difficult to compare data across systems.
- Hospitals had different formats for recording dates (e.g., DDMMYY or MMDDYY)
- Hospitals also used different codes for recording sex and other classifications in their system. (e.g., hospitals recording male, female, others versus M, F, O or 1, 2 and 0)
Table 1 shows the standards used for data exchange; Table 2 shows rules for data processing.
Addressing the challenge of non-standard codes for procedures required bringing together health care professionals—including clinicians, radiologists, lab technicians, anesthesiologists, surgeons, cardiologists, physiotherapists, and others—who developed a list of services to be standardized across the country. A standard list of services was defined using the CPT 4 codes from the American Medical Association. These codes were customized for Tanzania and integrated in the terminology services to facilitate data exchange. The list was then mapped against the custom codes used by the hospitals. A digital crosswalk was developed to map the custom hospital codes with the central standard codes, which would enable data from the customized system to the central system. If an exact match was not found, a code nearest to the central code was assigned (Table 3).
The HIM, or mediator, incorporated a degree of flexibility to enable alignment with all the systems. For recording dates, if one system recorded client data using the date/month/year system, and another recorded these data using the month/date/year system, the HIM would always translate those systems into the HIE’s operating system.
Data standards are critical for seamless interoperability. However, during implementation, the PMO decided that as an immediate step all custom codes from hospitals would be mapped to the existing CPT code (as shown in Table 3). This was an advantage for the HIM; mandating the use of standards for legacy systems would have been much more challenging, as the systems were already operational and health workers were used to using the custom codes. Over the long term, any new systems being developed will use the standards adopted by the MOHCDGEC, and if there is an opportunity, legacy systems will migrate to using the standardized codes. Introducing new standards did not force organizations to switch, because the flexible interoperability layer translated data from custom to standard code sets.
2.3.4 Developing guidance on using the interoperable system
To address emerging issues in the future, the MOHCDGEC developed standards, policy guidelines, and a conceptual framework to organize partners and other stakeholders using digital technology in health care. This approach provided the MOHCDGEC with a complete picture of activities to mobilize and commit resources for specific activities. By late 2017, development of integrated guidelines for facilities using electronic management information systems—guidelines explaining how to use the HIE—allowed the Ministry to assess and strengthen 9 hospital management information systems from 33 national, specialized, and regional hospitals. The conceptual framework, standards, and policy guidelines were each critical to enhancing the system’s ability to integrate data.
2.4 Step 4: Designing, testing, and implementing the system
The next step was to customize the system and conduct conformance testing. Once each use case was prioritized and architecture and interoperability needs identified (steps 1 and 2), the PMO team reviewed and identified an interoperability layer that would fit the Ministry’s needs. Multiple options on the market were already being used to support interoperability in various settings—such as OpenHIM, OpenFN, HEALTHeLINK, mulesoft, and many others. The PMO team reviewed the performance of various interoperability layer tools against a variety of use cases. The vendors of the tools were given the use case scenarios and asked to demonstrate their tool’s functionalities and ability to manage the proposed use cases.
This was a crucial stage in the journey toward improving interoperability in the Tanzanian health sector. The PMO, which consisted of representatives from multiple organizations and experts, played the role of an independent advisory group. The group reviewed the available tools and advised the MOHCDGEC team to adopt the HEALTHeLINK tool (version 3), which has been used in the U.S. for the past 13 years. This tool, developed using open-source systems such as Linux, Apache, MySQL, and Java, supports data exchange for client-level and aggregate data exchanges in several states. HEALTHeLINK is flexible and provides multiple options to connect with other systems, including APIs, SFTP, and web uploads. It supports interactions with both open source and proprietary systems. This was a key requirement for the health sector in Tanzania, since the national and specialty hospitals (included in the current use cases) were all using proprietary EMRs from external vendors.
With support from MCSP, the team of software developers from HEALTHeLINK worked with the MOHCDGEC and partner organizations to configure the system based on the rules and requirements outlined. The system was then taken through conformance testing to ensure that all requirements were being met and that the system could manage all transactions.
The team found that some systems were unable to participate fully on the HIE, as they were underdeveloped or used outdated technologies that do not support interoperability. To address this challenge, the system was configured to accept data through file uploads (e.g., export/import of XLS files) to the HIE, providing a flexibility that is particularly important in low-resource countries to accommodate key functions. This was a key functionality offered by the chosen tool, HEALTHeLINK.
2.4.1 Tools for users
Comprehensive support tools and structures were developed to ensure that the system ran smoothly and supported sustainability. The HIE’s sustainability depends on its flexibility and scalability, as seen in its ability to easily accommodate new use cases or extend existing use cases to cover more organizations. Tools developed for Tanzania included a systems installation manual, users’ operationalization guide, and system administration and implementation guides. The implementation guide was based on firsthand experiences from the Tanzanian context, and provides insight on the HIE processes and best practices to follow when “on-boarding” or connecting new or existing organizations or systems to the HIE.
2.5 Step 5: Building capacity and supporting data use
2.5.1 Capacity building
Training and capacity building for both technical staff and users took place throughout the implementation of Tz-HIE. The Ministry used a structured training methodology and standardized training materials for different groups of users. The training methodology was predominantly hands-on, where participants were given access to the system, with facilitator-led demonstrations and presentations, group assignments, pre-tests, quizzes, and post-tests meant to cement users’ understanding and assimilation of the key issues. To further enhance use of the system, the Ministry’s ICT department provides three tiers/levels of escalated support structure. Level 1 is the technical support team for users at the health facility level. Level 2 is the operations team; and Level 3 targets system administrators.
2.5.2 On-the-job support
MCSP also provided technical support to the ICT department by placing a full-time advisor seconded to the ICT unit. The Advisor’s role was to provide technical support the ICT staff and ensure the eHealth Strategy initiatives are implemented as planned. The seconded advisor role included improving coordination across the development of the various eHealth initiatives (including design and implementation of the mediator), identifying the use cases, engaging different departments of the MOHCDGEC, and playing the role of a secretariat for the digital health initiatives in the health sector.
2.5.3 Global conferences and meetings
MOHCDGEC officials were supported to take part in various international conferences and study tours—such as the annual Global Digital Health Forum in Washington, DC, the Public Health Informatics (PHI) Conference in Atlanta, GA, and a 2016 HIS study tour in Boston, Massachusetts. The PHI conference provided an opportunity to learn from experiences with interoperability across multiple programmatic area and geographic states in the U.S. The study tour in Boston enabled the MOHCDGEC team to interact with the Massachusetts Department of Health team and learn why and how they are investing in interoperability, and how they use data to make programmatic decisions.
2.5.4 Data visualization
To foster improvements in use of the available data by the MOHCDGEC leadership team, dashboards were developed to summarize the data and create insights. These were then displayed on wall-mounted TV screens. The system was set to update the dashboards as new data were sent from the hospitals. The dashboards are also available via a web-link, giving managers online access and enabling them to explore the features that interest them, such as performance gaps, time trends, or performance variations by region or organization.
2.5.5 System management
An administrator’s dashboard was added to the HIM to summarize the total number of systems connected to the HIM and the number of transactions successfully performed. An additional feature is the capacity to examine transactions that had errors or were not successfully performed. System administrators can use this feature to provide feedback to stakeholders on errors and improvement strategies, which helps to improve data quality.