FHIR4FAIR: Leveraging FHIR in health data FAIRfication process: In the case of VODAN-A

Abstract

This article describes FHIR as a healthcare data exchange standard to attain the FAIR data principles taking the VODAN-A implementation as a showcase. FHIR relies upon the basic unit “resources” and the interaction among them. A new FAIR enabling architecture is proposed.

1. Context

People often confuse FAIR and FHIR given the similarity in the acronym as well as the contexts in which they are used. While the first stands for Findable Accessible Interoperable and Reusable data (FAIR) [9], the latter refers to Fast Healthcare Interoperability Resource (FHIR) [4]. FAIR, as community-agreed guiding principles, aims to prepare machine-actionable and human-readable digital objects [9]. FAIR, in its philosophy, is a technology and standard agnostic. Hence, implementing organizations consider different standards, technologies, and protocols to attain these principles. The uptake for FAIR principles by implementing organizations has increased and proof of concepts demonstrating buy-in to the principles are being published in different research areas [8].

Health data is one of the research areas where the concept of FAIR data is being introduced [1]. Health as a complex system demands a system of standardized data exchange protocols between electronic health applications to support a longitudinal continuum of care supporting patient referral, appointment follow-up, and other data demand use cases, recognizing the sensitivity of patient data. One of the prominent health data interoperability standards is HL7 FHIR. FHIR is a healthcare information exchange standard. FHIR defines “Resources” as the atomic unit of exchange. Hence, everything in FHIR is a resource [6]. FHIR is geared towards the RESTful API standard, which is designed for the HTTP protocol over the web and supports common data exchange standards such as XML, JSON, and RDF [2]. Therefore, a given FHIR resource is based on structured W3C-compliant data types that define reusable metadata and human readability. The data is also structured and standardized to support machine-based processing. A clinical use case can be covered by linking such “resources” as data elements with “references” [5]. In addition, resource profiling with specific extensions is possible for the implementer’s specific use cases of interest. The relevance of FHIR to achieving FAIR principles is an ongoing discussion between FAIR and FHIR communities. FAIR4Health and the Research Data Alliance (RDA) FAIR Maturity Model Working Group have initiated the “FAIRness for FHIR” project aiming to assess FHIR compliance to the FAIR principles [3].

This commentary draws attention to the possibility of leveraging FHIR in the health data FAIRfication process. Taking the VODAN-Africa MVP (Virus Outbreak Data Network – Africa Minimum Viable Product) as a FAIR health data implementation in Africa, the development of horizontal and vertical interoperability between different systems in the Virus Outbreak Data Network (VODAN)-Africa is discussed. But before assessing FAIRness in FHIR and discussing FHIR server capabilities in VODAN-A, the concept of FHIR is discussed and the VODAN-A architecture is presented.

Fig. 1.

Addressing FAIRfication process using FHIR considering FHIR as native compliance, with the help of other standards and protocols and implementer’s consideration to a given use case and context.

2. Description

2.1. FHIR and FAIR

The FHIR compliance for each FAIR principle can be classified into three broad categories (Fig. 1): 1) native compliance provided by FHIR, 2) compliance provided by other supported standards and protocols, and 3) compliance provided by implementers (Table 1): 1).

Table 1

FHIR and FAIR

Principle/Facet of FAIR	FHIR compliance
F1: (Meta)data are assigned a globally unique and persistent identifier	A resource ID combined with the URL prefix of the FHIR server constructs a globally unique, persistent, and machine-resolvable identifier.
F2: Data are described with rich metadata	FHIR provides ‘intrinsic’ metadata such as “version ID and the Last update date” attached with data. FHIR also provides ‘contextual’ metadata resources such as provenance, library, and citation that could be cross-referenced with the fhir resource data. that explicitly describes a given data
F3: Metadata clearly and explicitly include the identifier of the data it describes	FHIR has “reference resource” datatypes or canonical URLs so that metadata include an identifier of the data.
F4: (Meta)data are registered or indexed in a searchable resource.	FHIR has a search framework. By indexing resources into the FHIR server, a given resource could be indexed or searched.
A1: (Meta)data are retrievable by their identifier using a standardized communicationprotocol	FHIR adheres to the ‘RESTful’ specification. HTTP request/response communication protocols are performed directly on the server resource to retrieve the data or metadata using the identifier as a filtering mechanism.
A1.1: The protocol is open, free and universally implementable	The HTTP protocol and FHIR RESTful API are the backbones of FHIR. These protocols are open-free and universally implementable. Though ‘open standard’ could mean different things in different scenarios, considering the openness of access to the process and the rights of use, FHIR fulfills all of them.
A1.2: The protocol allows for an authentication and authorization procedure, where necessary	FHIR defines exchange protocols and content models with various open security protocols such as HMAC authentication, HTTPS, or OAuth2.
A2: Metadata are accessible, even when the data are no longer available	Metadata and data can be represented with distinct FHIR resources. Hence, the longevity of data is defined using separate fhir “contextual metadata” resources that an implementer is expected to define.
I1: (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation	If implementers set vocabularies, profiles, and other conformance resources, FHIR supports XML, JSON, and RDF for knowledge representation which are common schemes in FAIR as well.
I2: (Meta)data use vocabularies that follow FAIR principles	FHIR provides a formal way to bind vocabulary(terminology) resources and API specification to facilitate it.
I3: (Meta)data include qualified references to other (meta)data	FHIR technically supports different kinds of references among FHIR resources that are represented as data or metadata.
R1: (Meta)data are richly described with a plurality of accurate and relevant attributes	General considerations made for F2 also apply to R1. The fact data and metadata are richly described and have accurate and relevant attributes depending on the context of use.
R1.1: (Meta)data are released with a clear and accessible data usage license	FHIR provides different means to specify the license and the conditions under which data can be used. E.g., GNU, CC
R1.2: (Meta)data are associated with detailed provenance	FHIR associates meta(data) with provenance information using the “Provenance” resource. Similarly, publication information using “citation” resources.
R1.3: (Meta)data meets domain-relevant community standards	FHIR supports resource profiling to fulfill community-specific domain-relevant standards. Communities are encouraged to prepare implementation guides specific to their model, vocabulary, and context.

Implementers are encouraged to qualify the given principle according to the needed level by preparing a normalized implementation guide. For example, when describing data with rich metadata (F2:), FHIR provides a metadata declaration. However, the “Richness” of the metadata depends on the conformance to the implementation guide. Similarly, (I3:) A metadata qualified to reference other meta(data) can be fulfilled technically with the FHIR resource capability to reference other FHIR resources, although (I3:). Hence, implementers are encouraged to determine qualified references that are needed to provide contextual knowledge for the scope of their community.

2.2. VODAN-Africa

In Africa, the culture of data use rests on sharing data between different systems, whereby data leaves the residence. VODAN Africa, as one implementer of the GO-FAIR implementation network, has been developing and testing an MVP to provide a proof- of-concept solution to the infrastructural and contextual issues regarding privacy, diversity, and ownership of digital data. The MVP is the first to revitalize health data acquisition, management, and use by generating FAIR data points in nine African countries and 88 Health facilities. To achieve the FAIR principles, the MVP used different technologies and standards.

Fig. 2.

VODAN MVP architecture.

The MVP provides a service architecture to transform the data into machine-readable clinical FAIR data from the outpatient department (OPD), antenatal care (ANC), and COVID registers to produce interoperable and reusable data. The architecture (Fig. 2) has input/bulk input capability to import data from other sources. In addition, CEDAR serves for the creation of meta(data) templates. Hence the processing, machine data conversion, and a metadata repository at the center of the architecture serve in the creation of FAIR data that could later be accessed by analytic dashboards and a FAIR Data Point. The architecture has the capability of FAIR data production and uses a federated modality without data losing its residence, as SPARQL queries can be executed over the internet on machine-actionable linked data without the data leaving the residence. The MVP is collecting data from registers using the CEDAR template. Still, the capability to accept data from an electronic medical record and send data to District Health Information System (DHIS2) is also part of the architecture [7].

Fig. 3.

FHIR leveraging VODAN-A architecture.

2.3. A proposal for leveraging FHIR in VODAN-A

Through its FHIR-server adapter such as HL7 Application Programming Interface (HAPI), FHIR could have a role in easing the data exchange (Fig. 3) in VODAN-A. A given health facility MVP interoperates with other, similar facility MVPs horizontally, and simultaneously exchanges data with DHIS2, and the triple store Allegro Graph is used as FDP to enable data visiting by performing SPARQL queries, vertically. Complementing the architecture, FHIR could be a convenient option for vertical interoperability without complicating horizontal data interoperability. Hence, the FHIR resource will be exposed by the plugged-in HAPI FHIR server between the vertically interoperating systems and the data production repository databases.

3. Conclusion

FHIR as a native solution through the protocols and specifications it supports, or with the community implementation guides, could be a viable option for the FAIRfication process of health data. Architectures not FHIR-based by design could also support health data interoperation and the FAIRfication process. Hence, further exploration is needed to see the possibility of non-native FHIR implementation, such as HAPI FHIR serving as a FAIR data point exposing data and metadata in RDF format.