Abstract
The digital health landscape in Uganda is plagued by problems with interoperability and sustainability, due to fragmentation and a lack of integrated digital health solutions. This can be partly attributed to the absence of policies on the interoperability of data, as well as the fact that there is no common goal to make digital data and data infrastructure interoperable across the data ecosystem. The promulgation of the FAIR Guidelines in 2016 brought together various data stewards and stakeholders to adopt a common vision on data management and enable greater interoperability. This article explores the potential of enhancing digital health interoperability through FAIR by analysing the digital solutions piloted in Uganda and their sustainability. It looks at the factors that are currently hindering interoperability by examining existing digital health solutions in Uganda, such as the Digital Health Atlas Uganda (DHA-U) and Uganda Digital Health Dashboard (UDHD). The level of FAIRness of the two dashboards was determined using the FAIR Evaluation Services tool. Analysis was also carried out to discover the level of FAIRness of the digital health solutions within the dashboards and the most frequently used software applications and data standards by the different digital health interventions in Uganda.
1. INTRODUCTION
Interoperability is increasingly being recognised as a crucial element of large-scale deployments of data management systems, particularly those that seek to be adopted by national health systems. In this article, we analyse the potential of enhancing digital health interoperability through FAIR by analysing two digital health dashboards piloted in Uganda and their sustainability. The capacity of a digital health product to transmit and receive information from external systems and applications will greatly increase the value of the digital health service and its potential for scalability as an integrated system. For example, interoperability with the national health management information system (HMIS) allows data collected by a digital health product to be accessed and used by the county's ministry of health, which adds value to the product from the ministry's perspective. This type of interoperability is critical for integrating with health system structures [1].
Digital health systems are built from electronic health records (EHRs), which have come a long way since the early 2000s when medical records consisted of a series of Microsoft (MS)-Access spreadsheets local to individual hospitals. The information stored in such a system (such as patient identifiers and visit dates) quickly overwhelmed it and a more robust system based on Java web applications and MySQL databases was soon developed [2]. Around 2005, the Open Medical Record System (OpenMRS) was created by a community of technology developers as a free and open-source generalizable EHR to support healthcare delivery systems in developing countries. OpenMRS, which has proved particularly effective for recording the treatment of millions of HIV/AIDS and tuberculosis patients, has been deployed in more than 25 mostly low-income countries, including Uganda.
The potential of digital health to overcome structural problems with healthcare services in Africa has resulted in a range of initiatives that explore how digital health applications can provide solutions. In this context, the strong proliferation of mHealth applications and digital health solutions has been observed. For example: the Ghana Health Service telemedicine programme, supported by the Novartis Foundation, uses mobile phones to connect remote primary healthcare facilities and community health workers to a teleconsultation centre at a referral facility [3]. In 2013, approximately 54% of the medical calls received at this centre were able to be resolved by telephone consultation [4].
The Broadband Commission Working Group [5] has expressed a growing concern that digital health solutions lack sustainability. Referring to the large number of pilot projects, the Commission points to the lack of policies and infrastructure necessary to embed these pilot solutions in a sustainable environment. This concern was also raised in a systematic literature review [6] of peer-reviewed literature from PubMed, Web of Science, OvidSP and Google Scholar in Africa for the decade 2005 to 2015. This review explored mHealth for community health in Africa in order to assess its ambivalent evidence base. The review revealed weak evidence on the sustainability of mHealth interventions. In addition, it found that the greatest barriers to impact were technology-related issues and circumstantial complications. The process of distinguishing these categories of complications helps to break the deadlock that marks the mHealth debate and adds weight to claims that the evidence base for mHealth is weak.
The East Africa Community has placed digital health high on the regional agenda and, in 2017, adopted an action plan [7]. In countries, such as Rwanda and Kenya, progress has been made with active government support for ICT-led development. In Uganda, such focused ICT-policy orientation has not been sought. As in most countries in Africa, where central focus from the government is lacking, Uganda provides a good case to investigate the reasons for the lack of sustainability resulting from ICT-based infrastructure and possible remedies to overcome such challenges [8]. In this article, we examine two digital health dashboards piloted in Uganda, their sustainability and the extent to which the introduction of FAIR data protocols could help overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda.
2. RESEARCH QUESTION AND OBJECTIVES
In order to assess the level of interoperability and potential of enhancing digital health interoperability through FAIR in Uganda's eHealth sector, the following research questions were posed:
Q1. What factors are currently hindering the interoperability of digital health solutions in Uganda?
Q2. Can the introduction of the systematic use of a FAIR data protocol through a FAIR Data Point help overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda?
The main objectives of the study were:
To analyse the level of FAIRness of the two digital health dashboards piloted in Uganda, before and after FAIRification.
To determine the level of the digital interventions in the two digital health dashboards
To examine the extent to which the introduction of FAIR data protocols would help overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda
3. TWO DIGITAL HEALTH HUBS
This study looked at the interoperability of two digital health dashboards and their vertical digital health tools in Uganda. The Digital Health Atlas Uganda (DHA-U) and Uganda Digital Health Dashboard (UDHD) were investigated with a view to increasing the sustainability of digital health interventions through coordination. Towards this, solutions were designed and tested to support the hubs to enhance data interoperability. Criteria were used to determine if the data science and management was sustainable, namely, whether or not the data was Findable, Accessible, Interoperable and Reusable (FAIR). This set of criteria—the FAIR Guidelines—has the potential to achieve better data management and integration. FAIR has a particular good record in health applications in Europe [9], but its implementation is still relatively new in Africa [10]. Lastly, the article examines the extent to which the introduction of FAIR data protocols could help overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda. Before elaborating on the method used, this section briefly describes these two hubs.
3.1 Digital Health Atlas Uganda
The Digital Health Atlas (DHA) is a global technology registry of digital health intervention (DHIs) developed by the World Health Organization (WHO) and its partners to strengthen the coordination of digital health investments towards harmonised, interoperable digital health systems. It is an open-source web platform designed to allow governments, service providers and donors to better plan, coordinate, monitor and assess the growth and maturity of their digital health projects and gain access to global resources on current best practices in digital health. Such best practices include the mHealth Assessment and Planning for Scale (MAPS) Toolkit [11]. The DHA is a global public good supported by organisations such as the Department of Reproductive Health and Research (WHO), United States Agency for International Development (USAID), United Nations Foundation, United Nations Population Fund (UNFPA), John Hopkins University Global mHealth Initiative, and the Digital Health and Interoperability Working Group, among others [11].
The DHA allows service providers to register their digital health projects globally and, hence, acts as an inventory of digital health products that can help create a global understanding of the digital health landscape. It is designed to reduce duplication, improve cooperation and advance integration between software projects, which is in line with the FAIR Guideline of interoperability. The hub allows investors to obtain useful information on DHIs, such as geographic scope and health focus area, project duration, implementation phase, readiness for scale, financial support from government and other investors, and government approval status. This allows the alignment of DHIs, where possible, and reduces the duplication of efforts [11].
The DHA-U contains a subset of 38 DHIs operating in Uganda, 25 of which have government investment and 13 are funded by other stakeholders. The health focus of these digital health solutions includes HIV/ AIDS, malaria, maternal health, tuberculosis, surveillance, adolescent and sexual reproduction, as well as other cross cutting areas. These interventions operate in different health facilities in Uganda [11].
2.2 Uganda Digital Health Dashboard
The Uganda Digital Health Dashboard (UDHD), which is also referred to as the Health Enabled dashboard, has served as a hub for digital health since 2016. It was developed by the Government of Uganda to solve a range of problems in the provision of healthcare services in the country, including the coordination of digital health solutions. The list of 57 providers of DHIs on the dashboard demonstrates the range of actors involved in digital health in Uganda and the fragmentation of such delivery [12].
The UDHD comprises 4 national digital health systems and 53 organisations that are implementing digital health projects in Uganda. The 4 national digital health systems are: the District Health Information System 2 (DHIS2), which was adopted in 2010 as a national tool for collecting and reporting health data; the Human Resource for Health Information Software 3 (HRHIS3), which is used for data collection, storage, analysis, reporting and the dissemination of human resource information for evidence based decision making; mTRAC, which is an mHealth solution for tracking essential medicines and improving health service delivery (the mTRAC Stop Malaria Program allows health workers to enter data about stock levels of essential malaria drugs into the system); and the Stop Malaria Program, which works with the districts to source supplies [12].
The 57 DHIs on the hub have no data export function. The health focus areas for these digital health solutions includes HIV/AIDS, malaria, maternal health, tuberculosis, surveillance, adolescent and sexual reproduction, clinical decision support, virtual health education, m-health, eHealth, HMIS, and preventable diseases. The duplication of DHIs has been observed in the UDHD (as well as in the DHA-U) [12].
4. METHODS
This case study was conducted as a desk study based on documents on digital health solutions in Uganda. The method employed in this case study consisted of the following steps:
Step 1: Determine the level of FAIRness of the two digital health hubs and the vertical digital health solutions within the hubs using the FAIR Evaluation Services tool [13]. The FAIR Evaluation Services tool is a web-based automated service that checks and validates metadata driven by the FAIRMetrics and FAIRSharing groups. It provides resources and guidelines to assess the FAIRness of digital resources and allows users to evaluate the FAIRness of such resources using collections of maturity indicator tests with the minimum requirement of the globally unique identifier. The FAIR facets used to assess FAIRness comprise the FAIR Guidelines.
Step 2: FAIRify and integrate the hubs using a FAIR Data Point and test the level of FAIRness after FAIRification using the FAIR Evaluation Services Tool [13].
5. RESULTS: LEVEL OF FAIRNESS OF DIGITAL HEALTH HUBS IN UGANDA
The FAIR Evaluation Service was used to determine the level of FAIRness of the UDHD and DHA-U. In order to carry out an evaluation, a globally unique identifier (GUID) is required. The maturity indicator tests applicable to the software application collection were implemented for both dashboards and the results are shown in Table 1.
Principle . | Metric test description . | UGHD . | DHA-U . | FAIR Data Point . |
---|---|---|---|---|
F1 | Metric to test if the metadata resource has a unique identifier. This is done by comparing the GUID to the patterns (by regular expression) of known GUID schemas such as URLs and DOIs. Known schemas are registered in FAIRSharing. | 1 | 1 | 1 |
F1 | Metric to test if the unique identifier of the metadata resource is likely to be persistent. Known schema are registered in FAIRSharing. | 0 | 0 | 0 |
F1 | Metric to test if the unique identifier of the data resource is likely to be persistent. | 0 | 0 | 0 |
F2 | Metric to test if a machine is able to find structured metadata. This could be (for example) RDFa, embedded JSON, JSON-LD, or content-negotiated structured metadata such as RDF Turtle. | 1 | 1 | 1 |
F2 | Metric to test if a machine is able to find ‘grounded’ metadata, i.e., metadata terms that are in a resolvable namespace, where resolution leads to a definition of the meaning of the term. Examples include JSON-LD, embedded schema, or any form of RDF. This test currently excludes XML, even when terms are name spaced. Future versions of this test may be more flexible. | 1 | 1 | 1 |
F3 | Metric to test if the metadata contains the unique identifier for the data. This is done by searching for a variety of properties (including foaf:primaryTopic, schema:mainEntity, schema: distribution, sio:is-about, and iao:is-about); schema code Repository is used for software releases. | 0 | 0 | 1 |
F3 | Metric to test if the metadata contains the unique identifier for the metadata itself. This is done using a variety of ‘scraping’ tools, including DOI metadata resolution, the use of the ‘extruct’ Python tool, and others. | 0 | 0 | 1 |
F4 | Tests whether a machine is able to discover the resource by search, using Microsoft Bing. | 1 | 0 | 0 |
A1.1 | Tests if data may be retrieved by an open and free protocol. Tests data GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community. | 0 | 0 | 1 |
A1.1 | Metadata may be retrieved by an open and free protocol. Tests metadata GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community. | 1 | 1 | 1 |
A1.2 | Tests a discovered data GUID for the ability to implement authentication and authorisation in its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. It also searches the metadata for the Dublin Core ‘access rights’ property, which may point to a document describing the data access process. | 0 | 0 | 1 |
A1.2 | Tests metadata GUID for the ability to implement authentication and authorisation in its resolution protocol. | 0 | 1 | 1 |
A2 | Tests if the metadata contains a persistence policy, explicitly identified by a persistence policy key (in hashed data) or http://www.w3.org/2000/10/swap/pim/doc#persistence policy predicate in linked data. | 0 | 0 | 0 |
I1 | Maturity indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a ‘knowledge representation language’; in this evaluation, anything that can be represented as structured data will be accepted. | 1 | 1 | 1 |
I1 | Maturity indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a ‘knowledge representation language’; in this evaluation, a knowledge representation language is interpreted as one in which terms are semantically-grounded in ontologies. Any form of RDF will pass this test (including RDF that is automatically extracted by third-party parsers such as Apache Tika). | 1 | 1 | 1 |
I2 | Maturity indicator to test if the linked data metadata uses terms that resolve. This only tests if they resolve, not if they resolve to FAIR data and, therefore, is a somewhat weak test. | 0 | 0 | 1 |
I2 | Maturity indicator to test if the linked data metadata uses terms that resolve to linked FAI data. | 0 | 0 | 1 |
I3 | Maturity indicator to test if the metadata links outward to third-party resources. It only tests metadata that can be represented as linked data. | 1 | 0 | 1 |
R1.1 | Maturity indicator to test if the linked data metadata contains an explicit pointer to the licence. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema licence predicates in linked data, and validates the value of those properties. | 0 | 0 | 1 |
R1.1 | Maturity indicator to test if the metadata contains an explicit pointer to the licence. This ‘weak’ test will use a case-insensitive regular expression, and scan both key/value style metadata, as well as linked data metadata. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema licence predicates in linked data, and validates the value of those properties. | 0 | 0 | 1 |
Principle . | Metric test description . | UGHD . | DHA-U . | FAIR Data Point . |
---|---|---|---|---|
F1 | Metric to test if the metadata resource has a unique identifier. This is done by comparing the GUID to the patterns (by regular expression) of known GUID schemas such as URLs and DOIs. Known schemas are registered in FAIRSharing. | 1 | 1 | 1 |
F1 | Metric to test if the unique identifier of the metadata resource is likely to be persistent. Known schema are registered in FAIRSharing. | 0 | 0 | 0 |
F1 | Metric to test if the unique identifier of the data resource is likely to be persistent. | 0 | 0 | 0 |
F2 | Metric to test if a machine is able to find structured metadata. This could be (for example) RDFa, embedded JSON, JSON-LD, or content-negotiated structured metadata such as RDF Turtle. | 1 | 1 | 1 |
F2 | Metric to test if a machine is able to find ‘grounded’ metadata, i.e., metadata terms that are in a resolvable namespace, where resolution leads to a definition of the meaning of the term. Examples include JSON-LD, embedded schema, or any form of RDF. This test currently excludes XML, even when terms are name spaced. Future versions of this test may be more flexible. | 1 | 1 | 1 |
F3 | Metric to test if the metadata contains the unique identifier for the data. This is done by searching for a variety of properties (including foaf:primaryTopic, schema:mainEntity, schema: distribution, sio:is-about, and iao:is-about); schema code Repository is used for software releases. | 0 | 0 | 1 |
F3 | Metric to test if the metadata contains the unique identifier for the metadata itself. This is done using a variety of ‘scraping’ tools, including DOI metadata resolution, the use of the ‘extruct’ Python tool, and others. | 0 | 0 | 1 |
F4 | Tests whether a machine is able to discover the resource by search, using Microsoft Bing. | 1 | 0 | 0 |
A1.1 | Tests if data may be retrieved by an open and free protocol. Tests data GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community. | 0 | 0 | 1 |
A1.1 | Metadata may be retrieved by an open and free protocol. Tests metadata GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community. | 1 | 1 | 1 |
A1.2 | Tests a discovered data GUID for the ability to implement authentication and authorisation in its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. It also searches the metadata for the Dublin Core ‘access rights’ property, which may point to a document describing the data access process. | 0 | 0 | 1 |
A1.2 | Tests metadata GUID for the ability to implement authentication and authorisation in its resolution protocol. | 0 | 1 | 1 |
A2 | Tests if the metadata contains a persistence policy, explicitly identified by a persistence policy key (in hashed data) or http://www.w3.org/2000/10/swap/pim/doc#persistence policy predicate in linked data. | 0 | 0 | 0 |
I1 | Maturity indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a ‘knowledge representation language’; in this evaluation, anything that can be represented as structured data will be accepted. | 1 | 1 | 1 |
I1 | Maturity indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a ‘knowledge representation language’; in this evaluation, a knowledge representation language is interpreted as one in which terms are semantically-grounded in ontologies. Any form of RDF will pass this test (including RDF that is automatically extracted by third-party parsers such as Apache Tika). | 1 | 1 | 1 |
I2 | Maturity indicator to test if the linked data metadata uses terms that resolve. This only tests if they resolve, not if they resolve to FAIR data and, therefore, is a somewhat weak test. | 0 | 0 | 1 |
I2 | Maturity indicator to test if the linked data metadata uses terms that resolve to linked FAI data. | 0 | 0 | 1 |
I3 | Maturity indicator to test if the metadata links outward to third-party resources. It only tests metadata that can be represented as linked data. | 1 | 0 | 1 |
R1.1 | Maturity indicator to test if the linked data metadata contains an explicit pointer to the licence. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema licence predicates in linked data, and validates the value of those properties. | 0 | 0 | 1 |
R1.1 | Maturity indicator to test if the metadata contains an explicit pointer to the licence. This ‘weak’ test will use a case-insensitive regular expression, and scan both key/value style metadata, as well as linked data metadata. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema licence predicates in linked data, and validates the value of those properties. | 0 | 0 | 1 |
5.1 Uganda Digital Health Dashboard
Using the unique identifier for the UDHD (http://healthenabled.org/wordpress/uganda-digital-health-dashboard/), the level of FAIRness was tested using the FAIR Evaluation Services. The results obtained are shown in Figure 1.
UDHD test results using FAIR Evaluation Services [14].
In order to determine the level of FAIRness of the DHA-U, a FAIR metrics evaluation was conducted using the FAIR Evaluation Services. Maturity indicator tests applicable to the software application collection were selected. Out of 20 tests, 9 succeeded and 11 failed (the results are also shown in the link (https://fairsharing.github.io/FAIR-Evaluator-FrontEnd/#!/evaluations/5121).
Maturity indicator tests passed and failed by the DHA-U.
Upon further analysis, the highest and lowest percentage pass of the UDHD was determined. The results obtained show that the UDHD scored the least for ‘Reusable’, with a 0% FAIR metrics test pass. This is because the linked data metadata contains no explicit pointer to the licence. The UDHD scored the most for ‘Interoperable’, with a 60% FAIR metrics test pass, arising from the fact that the metadata uses a formal language broadly applicable for knowledge representation and the metadata links outward to third-party resources.
5.2 Digital Health Atlas-Uganda
Using the unique identifier for the DHA-U (https://www.digitalhealthatlas.org/en/ug/), the level of FAIRness was tested using the FAIR Evaluation Services. The results obtained are shown in Figure 3.
DHA-U test results using FAIR Evaluation Services [15].
The maturity indicator tests applicable to the software application collection on the DHA-U unique identifier showed that out of 20 tests, 7 succeeded and 13 failed (the results are also shown in the link https://fairsharing.github.io/FAIR-Evaluator-FrontEnd/#!/evaluations/5126).
Maturity indicator tests passed and failed by the DHA-U.
Upon further analysis, the highest and lowest percentage pass of the DHA-U was determined. Similarly, the results obtained show that the DHA-U scored the least for ‘Reusable’, with a 0% FAIR metrics test pass.
This is because the linked data metadata and metadata contains no explicit pointer to the licence. The DHA-U scored the most for ‘Findable’, with a 50% FAIR metrics test pass, because the metadata resource has a unique identifier and machines are able to find structured and grounded metadata.
5.3 Digital Health Interventions
In order to determine the level of FAIRness of each DHI in the two digital dashboards, the unique identifier for each digital health solutions was tested. The data was obtained from both the UDHD and the DHA-U. Out of 98 DHIs obtained from both dashboards, 65 have unique identifiers available and accessible. Using the FAIR Evaluation Services, the level of FAIRness of each of the DHIs was tested. A FAIR metrics evaluation with the FAIR Evaluation Services with maturity indicator tests applicable to the software application collection selected was conducted for each of the DHI identifiers. The results obtained are shown in Table 2.
. | Group . | Success score . | Failure score . | Number of DHIs . |
---|---|---|---|---|
1 | 3 | 17 | 19 | |
2 | 7 | 13 | 15 | |
3 | 8 | 12 | 11 | |
4 | 9 | 11 | 7 | |
5 | 10 | 10 | 6 | |
6 | 11 | 9 | 3 | |
7 | 5 | 15 | 1 | |
8 | 12 | 8 | 1 | |
9 | 0 | 20 | 1 | |
10 | 4 | 16 | 1 |
. | Group . | Success score . | Failure score . | Number of DHIs . |
---|---|---|---|---|
1 | 3 | 17 | 19 | |
2 | 7 | 13 | 15 | |
3 | 8 | 12 | 11 | |
4 | 9 | 11 | 7 | |
5 | 10 | 10 | 6 | |
6 | 11 | 9 | 3 | |
7 | 5 | 15 | 1 | |
8 | 12 | 8 | 1 | |
9 | 0 | 20 | 1 | |
10 | 4 | 16 | 1 |
The highest number of DHIs obtained a success score of 3, which is less than half the total score (which is 20), with 12 being the highest success score attained by only 1 DHI. The average success score was 10, and 10 out of the 65 DHIs scored more than the average score, which is less than 50% of the tested identifiers. This further highlights the need to improve the level of FAIRness of the DHIs in Uganda. The ‘Findability’ aspect of each of the DHIs can be improved by assigning the metadata and data resource a persistent unique identifier (PID).
5.4 After FAIRification
In order to integrate and improve the level of FAIRness of the UDHD and DHA-U, a FAIR Data Point, which is a distributed data repository hosting machine-actionable data and metadata that adheres to the FAIR Guidelines (the data be Findable, Accessible, Interoperable and Reusable), was deployed at Kampala International University, Uganda. Metadata was configured for the FAIR Data Point, consisting of a catalog, layer, dataset layer and distribution layer. A catalog for the digital health hubs in Uganda was created and metadata for each of the datasets was assigned, as shown in Figure 5.
FAIR Data Point, digital health hubs in Uganda (Source: Screenshot taken by M. Basajja, 2021).
A FAIR metrics evaluation was conducted on the FAIR Data Point Catalog to determine the new level of FAIRness. The tested identifier was https://fdps.kiu.ac.ug/catalog/87b29cff-8cf5-4342-b8ca-32377ce462e5. The results obtained are shown in Figure 6.
FAIR Data Point (UDHD and DHA-U catalog) test results using FAIR Evaluation Services [16].
Maturity indicator tests applicable to the software application collection on the DHA-U unique identifier showed that out of 20 tests, 16 succeeded and 4 failed (the results are also shown in the link https://fairsharing.github.io/FAIR-Evaluator-FrontEnd/#!/evaluations/5213). The breakdown of the number of tests done per FAIR Guideline is given in Figure 7.
Maturity indicator tests passed and failed by the digital health hubs in Uganda after FAIRification.
The level of FAIRness of the digital health hubs in Uganda improved after implementing the FAIR Data Point with 16 succeeded and 4 failed tests. The maturity indicator tests carried out indicate that the ‘Reusability’ and ‘Interoperability’ aspects of FAIR improved significantly from 0% to 100%. The FAIR Data Point passed all the ‘Interoperability’ and ‘Reusability’ tests done. However, the ‘Findability’ and ‘Accessibility’ aspects of the FAIR Guidelines were failed in 3 and 1 test, respectively, because of lack of a persistent identifier and a persistence policy, which is explicitly identified by a persistence policy key. However, an improvement in the number of ‘Findability’ and ‘Accessibility’ tests passed after FAIRification was still observed. Hence, it can be concluded that there was a significant improvement in the level of FAIRness of the digital health hubs after the FAIRification process with a FAIR Data Point. This shows that the introduction of FAIR data protocols can help overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda by enabling the Findability, Accessibility, Interoperability and Reusability aspects of FAIR.
6. DISCUSSION
The UDHD and the DHA-U both aim to create an inventory of digital health solutions and aggregate all relevant information in one place. However, more coordination is required. In particular, the lack of sustainability of digital health solutions in Uganda is a problem, which has been acknowledged as a motivation for improving the coordination of the hubs. The DHA-U is so far the best at providing information on interoperability and standards for digital health interventions, as well as the most up to date. However, after conducting a FAIR metrics evaluation using the FAIR Evaluation Services, the UDHD ranked higher than the DHA-U on its level of FAIRness in terms of ‘Findability’ and ‘Interoperability’. Both hubs are equally accessible and reusable, with the ‘Reusability’ aspect ranking lowest.
The Digital Health Atlas was designed to be a registry of digital health projects so that information on digital health solutions could be aggregated in one place. Its usefulness lies in helping projects operating in the same health space to easily identify what resources they have in common, so that they can reuse them. Having all this information in one place also helps reduce the duplication of effort and avoids different projects having to ‘reinvent the wheel’. This is in line with the FAIR Guideline of ‘Reusability’. However, the maturity indicator tests carried out show that there is a need to improve the level of FAIRness of the DHA-U. Out of the 20 tests conducted, only 7 succeeded and 13 failed. To improve this, the DHA-U could collect licence information and have it clearly displayed. The DHA also provides information on interoperability and standards for each digital health project registered. For example, it shows whether or not the intervention is interoperable with any other system such as the client registry, national HMIS, health worker registry, logistics management information system, facility registry, etc. In addition, the DHA provides a list of data standards used within the project.
According to the DHA Technical Implementation Guide, registering a digital health project in the DHA requires one to create a user account, either as a technical implementer or government entity (e.g., Ministry of Health Team). There are global fields that must be filled in for each project, including: general overview, implementation overview, completion of project stages, technology overview, interoperability and standards. In addition, there are country custom fields and investor custom fields.
The general overview includes the project name, organisation, project country, geographic scope, overview of the digital health implementation, contact name and email of the person registering the project (project team members). These contact details of the project lead can be used for coordination and liaising purposes. The implementation overview lists the software used in the implementation of the DHI, the functions of the software, the health focus area and the implementing partners, among other things. The technology overview field includes the ‘code documentation or download link’, which should contain a link to the repository where the project source code can be found; a link to Wiki or the project website; project licencing information; and a link to the mobile application. The interoperability and standards field contains information on what other systems the DHI interoperates with. This query is posed as a question: “What other system do you interoperate with?” Unfortunately, for the majority of the 98 digital health solutions operating in Uganda, the answer given to this question is ‘N/A’ (not available) (see Supplementary Material). Only two DHIs, ‘Duty Roster and Attendance Tracking Mobile Application’ and ‘Open Client Registry’, indicate that they interoperate with one other system (the first interoperates with the HMIS and the second a client registry, although it is not clear which client registry this is).
As this information depends on whether the team that registered the project provides it or not, it is hard to tell whether there is no interoperability between the DHIs registered and any other system or if the information was simply not provided. The question of whether or not a DHI is interoperable with another system developed by a third party is not straightforward to answer. However, if the data collected by the DHI is not easy to find using the availed unique identifier, then it cannot be accessible, interoperable or reusable.
Some experts have pointed out that the current wave of mHealth interventions are the equivalent of ‘black boxes’ [17]. This means that information on how the mHealth intervention was implemented (e.g., the technology architecture and software applications used) is mostly unknown and undocumented. This is consistent with the findings of this research, whereby, despite the best efforts of the DHA-U to document the interoperability and data standards for each DHI, most DHIs indicated N/A. When asked about data standards, 35% (n=13) of the DHIs in Uganda indicated N/A. In relation to interoperability with any other system, the technical implementer registering the project may have no knowledge of the technology architecture or software used in the implementation of other systems to infer interoperability. However, the data standards used in the specific DHI should be known and provided at the time project registration. To overcome this, the government could introduce a policy requiring all digital solutions to make this information available. This would incentivise digital health solutions to spend time filling out the information in the DHA-U fully. The government could also provide incentives for selecting standards, formats and ontologies that are already in common use.
FAIR is not equal to RDF, linked data, or the Semantic Web. Mons et al. [18] emphasise the importance of data and metadata being machine-actionable. This implies (in fact, requires) that resources that wish to comprehensively apply the FAIR Guidelines must utilise a widely-accepted machine-readable framework for data and knowledge representation and exchange. While there are only a handful of standards and frameworks that could fulfil this requirement, other potentially more powerful approaches may emerge in the future. As such, the FAIR Guidelines do not explicitly prescribe the use of RDF or any other Semantic Web framework or technology. That said, RDF, together with formal ontologies, are currently a popular solution to the knowledge-sharing problem and fulfils the requirements of FAIR.
Tomlinson et al. [17] recommend that what is needed is a concerted effort by governments, funders, and private enterprises to cooperate in order to set standards towards creating robust interoperable platforms, lest mHealth initiatives fail to be scaled up and improve health outcomes. In 2015, WHO and partners published guidance on best practices for scaling up mHealth innovations to maximise impact on health, in the form of the mHealth Assessment and Planning for Scale (MAPS) Toolkit.
Tomlinson and colleagues also postulated that there is a set of principles that could potentially be established to identify the optimal strategies for delivering mHealth interventions [17]. Such principles include the FAIR Guidelines. Among their recommendations for scaling up mHealth is the establishment of an open mHealth architecture based on a robust platform with standards for application development, which would facilitate the scalable and sustainable health information systems [19]. This is in line with the FAIR Guideline of ‘Interoperability’.
In the 2011 White Paper commissioned by Advanced Development for Africa called Scaling up Mobile Health [20], it was stated that without identifying data and technology standards and interoperability architectures, mHealth programmes will continue to produce competing and duplicate sets of data. It further elaborated that to achieve integration within local healthcare structures and national health information systems (and, thereby, scale up the solution), programme designers and implementers need to know what the local data and technology standards are and how to design their programmes to ensure interoperability. The author advocates for the identification, and promotion of the use of specific data, technology and interoperability standards, as well as for governments to play a stronger role in the regulation and meeting of standards by mHealth technologies.
One of the recommendations of the White Paper is the creation of frameworks for success, including elements such as the development of reference architectures for interoperability and data standards targeted the informing of policymakers, project designers and implementers, and donors. In order to achieve this, it is recommended that the handful of cases in which such architectures have been successfully adopted in countries with different contexts be analysed and this analysis be used to inform a template or toolkit to demonstrate how different types of standards and architectures can be used. A critical factor in the success of such an endeavour is the systematic and detailed documentation of the process and steps taken to establish these successful architectures and standards. In addition, implementers should be required by donors to adhere to interoperability and data standards for mHealth [20].
The promotion of data standards and interoperability is one of the key mechanisms to support the scaling up of mHealth in developing countries. WHO promotes standards-based and integrated approaches on the use of ICTs, including mobile phone technology, with the view to ensuring the interoperability, sustainability, and scalability of mHealth solutions [20].
7. CONCLUSION
From the early days of the conception of the FAIR Guidelines, it was made clear that the guidelines in themselves are just a general guide to making data ‘FAIR’ and not a standard; hence, they do not advocate for a particular technology or implementation solution. It is, therefore, up to those seeking to implement the FAIR Guidelines to make technical implementation choices that render the resulting data FAIR. After conducting a FAIR metrics evaluation using the FAIR Evaluation Services, the UDHD ranked higher than the DHA-U in terms of FAIRness: the UDHD scored higher than DHA-U on ‘Findability’ and ‘Interoperability’; they both scored the same for ‘Accessibility’ and ‘Reusability’, with ‘Reusability’ ranking the lowest because their metadata and data were not well-described, which limited indexation in searchable repository. This means that data on the UDHD and DHA-U is readable only by people and have no licences. Notably, none of the digital health interventions passed more than half of the number of FAIR maturity tests conducted. The digital health solutions in Uganda function independently and are not designed to support FAIR. The data collected by the DHIS is not easy to find, access, or interoperate and, therefore, cannot be easily reused. To address this, the government could apply a level of FAIRness to all digital health tools. Although it may not be feasible for all DHIs to use similar software and technology, given that they may have slightly different health focus areas and implementation challenges, they could use similar data standards and employ the use of APIs in order to support interoperability. In this way, the level of FAIRness of the digital health ecosystem in Uganda could be improved. The introduction of the systematic use of the FAIR data protocol through a FAIR Data Point would help to overcome structural challenges to the development and maintenance of sustainable digital health solutions in Uganda.
ACRONYMS
- API
application programming interface
- DHA
Digital Health Atlas
- DHA-U
Digital Health Atlas-Uganda
- DHI
digital health intervention
- DHIS2
District Health Information Software 2
- EHR
electronic health record
- FAIR
Findable, Accessible, Interoperable, Reusable
- GUID
globally unique identifier
- HMIS
health management information system
- MAPS
mHealth Assessment and Planning for Scale
- OpenMRS
Open Medical Record System
- RDF
Resource Description Framework
- RDFa
Resource Description Framework in Attributes
- UDHD
Uganda Digital Health Dashboard
- WHO
World Health Organization
ACKNOWLEDGEMENTS
We would like to thank Misha Stocker for managing and coordinating this Special Issue (Volume 4) and Susan Sellars for copyediting and proofreading. We would also like to acknowledge VODAN-Africa, the Philips Foundation, the Dutch Development Bank FMO, CORDAID, and the GO FAIR Foundation for supporting this research.
AUTHORS' CONTRIBUTIONS
Mariam Basajja ([email protected], 0000-0001-7710-8843) contributed to the conception and design of the work, data collection, analysis and interpretation, drafting of the article, critical revision of the article and approval of the final version to be published. Mutwalibi Nambobi ([email protected], 0000-0001-6822-616X) contributed to the critical revision of the article and approval of the final version to be published. Katy Wolstencroft ([email protected], 0000-0002-1279-5133) contributed to the conception and design of the work and critical revision of the article.
CONFLICT OF INTEREST
All of the authors declare that they have no competing interests.
ETHICS STATEMENT
Tilburg University, Research Ethics and Data Management Committee of Tilburg School of Humanities and Digital Sciences REDC#2020/013, June 1, 2020-May 31, 2024 on Social Dynamics of Digital Innovation in remote non-western communities
The study was approved by the KIU Research Ethics committee. Permission to conduct interviews in the health facilities was also obtained from the Ministry of Health, district local government authorities and the respective district health officers. All participants provided voluntary informed consent before each interview. The privacy of the participants was ensured by conducting the interviews in private and not including identifiable information. Individual autonomy to participate in the study was guaranteed, as participants were free to decline to participate. All who consented to participate were informed about their freedom to withdraw from the study at any time. No participant withdrew from the study. Permission to tape record the data was similarly obtained. All the audio recorded material and transcripts were safely stored by the lead author, Mariam Basajja.