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.
Keywords
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.
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.
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).
FHIR and FAIR
FHIR and FAIR
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.
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.
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].
FHIR leveraging VODAN-A architecture.
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.
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.
Footnotes
Acknowledgements
The authors are very grateful to the members of the VODAN-A community who were in each implementation step of the MVP and helpful in providing their valuable input to this paper.
Funding
The authors have no funding to report.
Conflict of interest
The authors have no conflict of interest to report.