Realizing health data interoperability in low connectivity settings: The case of VODAN-Africa

2.1.VODAN-Africa

VODAN-Africa (VODAN-A) curates patient data at point of care in clinics according to FAIR Guiding Principles. The community produces federated, machine readable data in residence. Data ownership, Localisation and Regulatory (OLR) [9] compliance elevates federated interoperability for analytical purposes. The VODAN-A Minimum Viable Product (MVP) tried to achieve semantic interoperability. The diversity of formats with which medical information is registered includes: ICD-10, SNOMED, LOINC, RxNorm, and NDC. Those diversities of standards and formats in a medical information registry pose semantic challenges. It is challenging to achieve semantic level interoperability for data exchange from multiple sources. Different terminologies can be used for the same concept, which impedes conducting data analytics in heterogeneous systems. This is a problem because community-defined data exchange formats serve the community itself, but not beyond [3,5].

Fig. 1.

VODAN Africa architecture for clinical data.img.

The architecture of VODAN-Africa (Fig. 1) is a blueprint for the MVP deployed in 88 health facilities in 9 African countries [10]. It enables us to FAIRify data and visualize it through internal and external dashboards, to store machine readable data in residence and to make data accessible through a data visiting tool under well-defined conditions. For data FAIRification, two approaches were followed. First was engineering of a tool that makes bulk upload possible to FAIRify existing data. It converts existing comma-separated data into RDF triples. It reverse-models the vocabularies designed in the template and stores the resulting JSON-LD instance simultaneously in MongoDB and RDF triples in AllegroGraph [2]. Second was collection of data at point of service from registries in clinics, which are stored in JSON-LD format in MongoDB and in the form of RDF triples in AllegroGraph. The FAIR-ready data in a triple store can be exposed to data visiting algorithms. Different use-cases can then be envisaged, such as the export of the data to Health Management Information Systems (HMIS), e.g. District Health Information System (DHIS2). To this end, the MVP has used AllegroGraph as a triple store for querying using SPARQL. VODAN-Africa has implemented two different interoperability methodologies: vertical and horizontal interoperability [7].

2.2.Vertical interoperability

The MVP provides the ability to compute and send aggregated monthly reports to the HMIS systems, which replaces manual computation of indicators. VODAN-A provides a solution to enable interoperability between a point of service application, the MVP and health management information systems. The MVP prepares the statistics based on the data element report skeleton templates prepared in JSON format and posts the aggregated indicators into DHIS2. DHIS2 provides a web API to accept data element values from the MVP, see Fig. 2.

Fig. 2.

Interoperability between VODAN – A MVP and DHIS2.

To create semantic interoperability, terminology services are required to perform the mapping of terms used in the MVP as well as DHIS2 to the terms stored in the ontology server. VODAN-A interoperates with DHIS2, using JSON standard reporting templates generated from DHIS2, which increases syntactic interoperability with point-to-point integration. To add flexibility and ensure security of communication during interoperability, having a separate enterprise service bus is envisaged as a micro-service. It provides authentication, mediation, logging and management of interoperability services. Having such a layer can encourage and promote interoperability as other systems will delegate the task of interoperability to the dedicated service.

2.3.Horizontal interoperability

Health clinics in the VODAN-Africa implementation network sign data sharing agreements to enable generation of knowledge at different levels to facilitate data and service interoperation. The community has created shared vocabularies, metadata templates and other digital objects. As the system is interoperable by design, it creates horizontal interoperability. To realize seamless interoperability, VODAN Africa followed guidance of FAIR principal interoperability facets (I1–I3). Thus, different health facilities are connected to create and use common terminologies which are displayed in a shared VODAN-Africa dashboard Fig. 3.

Principle I1: (meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation:

Fig. 3.

Interoperability across health facilities in VODAN Africa.

To create a common understanding of digital resources, we used a globally understood language, Simple Knowledge Organization System (SKOS), to produce vocabularies. VODAN-A used CEDAR template110, using SKOS vocabularies loaded into BioPortal. The templates are presented in JSON format, which can be reused and are interoperable for other systems. Data produced using the templates is represented in JSON-LD as well as RDF triples.

Principle I2: (meta)data use vocabularies that follow FAIR principles:

Reusability of data by generic agent, rather than a community-specific agent is the key consideration in this principle [6]. This was made possible through the use of controlled vocabularies. To this end, we created templates using CEDAR, which utilize vocabularies we had uploaded into BioPortal. VODAN-A has attempted to deploy OntoPortal locally, named as VodanaPortal, to allow for storing data in the residence where the data is produced. As the terminology service in CEDAR is developed to work with BioPortal, adjustments were needed in the code-base to localize the data storing. Despite attempts to do so, the result was not satisfactory for technical reasons.

Fig. 4.

VODAN Africa architecture for low resource and offline setting.

Data production has been challenging in health facilities with low or no connectivity settings because the ontology portals are remote services that prompt Internet connectivity. This has affected the performance of the system in data production for low connectivity and made it impossible when there is no connectivity. Some of the sites changed the templates removing the controlled vocabularies and replacing them with local controlled lists that users can select. Through these solutions, the spirit of the principle is adapted to what is possible within the context of deployment. The issue was then addressed in a new architecture, see Fig. 4, by making controlled vocabularies accessible from a local repository.

Principle I3: (meta)data include qualified references to other (meta)data:

The semantic modelling was conducted by reviewing terminologies from the registry forms. VODANA-GENERAL terms were identified and stored on BioPortal. Each country has also defined its own templates, vocabularies, and types of (meta)data to be collected. The metadata templates which are in JSON format have as fully qualified reference a resolvable URI to the vocabulary classes and acronyms used. The metadata instances created by filling the templates are represented in JSON-LD. Even metadata information for the terms used is stored using a unique IRI that can help in interpretation, query and visualization. This facilitates both human and machine agents to interpret and understand concepts in the same way.

To address issues of performance for low/no connectivity settings, a lightweight application was developed, using a new architecture Fig. 4, which can produce FAIR data using vocabularies that is accessible offline. Currently, it is being tested in health clinics in Tigray, Ethiopia, where there is a communication blackout [4]. To ensure principle I2, the templates are designed in CEDAR using vocabularies from BioPortal. The template JSON and the vocabularies in CSV format are downloaded from CEDAR and Bioportal, respectively, then loaded to the light MVP. The light MVP renders the templates parsing the JSON and loading the vocabularies offline. During data entry, the system gives an autocomplete feature utilizing the controlled vocabularies and keeps the IRIs of the terms. It produces and displays the resulting JSON-LD and an RDF and offline first manner. The system also stores the RDF triples in AllegroGraph. Statistics are then calculated and loaded into the internal dashboard and the external dashboard. This creates potential for the development of further use-cases through data-visiting that includes low/no connectivity settings [12].