Data interoperability in context: the importance of open source implementations when choosing open standards
In response to the proposal of Tsafnat et al. to converge towards three open health data standards, this viewpoint provides a critical reflection on the proposed alignment of using OpenEHR, FHIR and OMOP as the default standards for clinical care and administration, data exchange and longitudinal analysis, respectively. We argue that open standards are a necessary but not sufficient condition to achieve health data interoperability. The ecosystem of open source implementations needs to be considered when choosing an appropriate standard for a given context. We discuss two specific contexts, namely standardization of i) health data for federated learning, and ii) health data sharing in low- and middle income countries (LMICs). Specific design principles, practical considerations and implementation choices for these two contexts are described, based on ongoing work in both areas. In the case of federated learning, we observe convergence towards OMOP and FHIR, where the two standards can effectively be used side-by-side given the availibility of mediators between the two. In the case of health information exchanges in LMICs, we see a strong convergence towards FHIR as the primary standard, with as yet limited adoption of OMOP and OpenEHR. We propose practical guidelines for context-specific adaptation of open standards.
OMOP, OpenEHR, FHIR, secondary use, data platform, digital platform
Open standards are a necessary but not sufficient condition for interoperability
“A paradox of health care interoperability is the existence of a large number of standards exists with significant overlap among them,” say Tsafnat et al., followed by a call to actions towards the health informatics community to put effort into establishing convergence and preventing collision (Tsafnat et al., 2024). To do so, they propose to converge on three open standards, namely i) OpenEHR for clinical care and administration; ii) Fast Health Interoperability Resources (FHIR) for data exhange and iii) Observational Medical Outcomes Partnership Common Data Model (OMOP) for longitudinal analysis. They argue that open data standards, backed by engaged communities, hold an advantage over proprietary ones and therefore should be chosen as the steppingstones towards achieving true interoperability.
While we support their high-level rationale and intention, we feel their proposed trichotomy does not do justice to details that are crucial in real-world implementations. This viewpoint provides a critical reflection on their proposed framework in three parts. First, we reflect on salient differences between the three open standards from the perspective of the notion of openness of digital platforms (de Reuver et al., 2018) and the paradox of open (Keller and Tarkowski, 2021). Subsequently, we present our findings in designing and implementing health data platforms in two specific contexts, namely i) platforms for federated learning on shared health data in high income countries; and ii) health data platforms for low and middle income countries (LMICs). We conclude with practical guidelines for context-specific adaptation of open standards.
Digital platforms require extensibility, availibility of complementary components and availibility of executable pieces of software
Besides the paradox of interoperability put forward by Tsafnat et al., we argue that open standards are a necessary, but not sufficient condition for convergence of health data standarization. Open source implementations of components, software development kits etc. constitute another necessary condition for establishing a flourishing health data sharing platform and associated ecosystem for any given context, be it regional, international or within a specific sub-domain like pandemic preparedness. Research on digital platforms underline the importance of the platform openness, not only in term of open standards, but also in term of extensibility of the code base, availibility of complements to the core technical platform (in our case the data standard itself) and availibility of executable pieces of software (de Reuver et al., 2018). Only when the majority of these aspects of digital platforms are fullfilled can we resonably expect that the platform will indeed be longlived.
In what they call the paradox of open, Keller and Tarkowsi argue that this conventional approach of open standards and open source flourish under two types of conditions (Keller and Tarkowski, 2021). First, projects where many people contribute to the creation of a common resource have proven succesful. “This is the story of Wikipedia, OpenStreetMap, Blender.org, and the countless free software projects that provide much of the internet’s infrastructure.” (Keller and Tarkowski, 2021) Indeed, Tsafnat et al. have explicitly taken into account that “an engaged and vibrant community is a major advantage for the longevity of the data standards it uses,” which has informed their proposal to converge towards OMOP, FHIR en OpenEHR. However, the emphasis on open source implementations is somewhat overlooked. This point is only mentioned in passing and indirectly, when Tsafnat et al. reference work done by Reynolds and Wyatt who already argued in 2011 “… for the superiority of open source licensing to promote safer, more effective health care information systems. We claim that open source licensing in health care information systems is essential to rational procurement strategy” (Reynolds and Wyatt, 2011). We believe that a realistic assessment of the current position of an open standard within the wider context of availability of complementary components and open source implementations is equally important when choosing which standard to adopt.
This point is related to the second condition put forward by Keller and Tarkoswki, namely that the conventional open approach has proven fruitful when “opening up” is the result of external incentives or requirements, rather than voluntary actions. “This is the story of publicly-funded knowledge production like Open Access academic publications, cultural heritage collections in the Public Domain, Open Educational Resources (OER), and Open Government data.” (Keller and Tarkowski, 2021) A canonical example is the birth of the GSM standard, which was mandated by European legislation.1 Reflecting on this perspective on openness, we observe a salient difference between FHIR vis-a-vis OpenEHR and OMOP, namely that the former is the only one that has been mandated (or at least strongly recommended) in some jurisdictions. In the US, the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare and Medicaid Services (CMS) has introduced a steady stream of new regulations, criteria, and deadlines in Health IT that has resulted in significant adoption of FHIR (Firely, 2023). In India, the open Health Claims Exchange protocol specification - which is based on FHIR - has been mandated by the Indian government as the standard for e-claims handling (“HCX Protocol v0.9,” 2023; National Digital Health Mission, 2020). The African Union recommends all new implementations and digital health system improvements use FHIR as the primary mechanism for data exchange (Tilahun et al., 2023), but doesn’t say anything about the use of, for example, OpenEHR for administrative point-of-service systems.
These external incentives have resulted in a large boost in both commercial and open source development activities in the FHIR ecosystem. Illustrative of this is the speed with which the Bulk FHIR API has been defined and implemented in almost all major implementations (Jones et al., 2021; Mandl et al., 2020), and the the SQL-on-FHIR specification to make large-scale analysis of FHIR data accessible to a larger audience and portable between systems.2 It has also led to more people voluntarily contributing to FHIR-related open source projects, which has resulted in a wide offering of FHIR components across major technology stacks (Java, Python, .NET), thereby strengthening the first condition. By comparison, OMOP and OpenEHR have not yet profited from external incentives to spur the adoption and thereby growing the ecosystem beyond a certain critical mass. To illustrate this, a search on GitHub on “FHIR” yields 8.2 thousand results, “OMOP or OHDSI” one thousand results, and “OpenEHR” returns 400 results. A quick-scan of the available open source components listed on the website of the three governing bodies HL7, OHDSI and OpenEHR, indicates that the ecosystem of FHIR and OMOP have a significantly larger offering of extensible and complementary open source components than OpenEHR.3
Hence, we stress that beyond evaluating the instrinic structure of an open standard and the community that supports the standard, we need to take into account the wider ecosystem of open source implementations and availibility of complementary components. From this wider perspective of the whole ecosystem surrounding the three standards, FHIR stands out as having the most diverse and rich ecosystem because it has been mandated in certain jurisdictions. This is relevant when comparing these standards in real-world implementations. We now turn to two specific use cases c.q. contexts where these considerations are at play.
Standardization of health data for federated learning
The current fragmentation in health data is one of the major barriers towards leveraging the potential medical data for machine learning (ML). Without access to sufficient data, ML will be limited in its application to health improvement efforts and, ultimately, from making the transition from research to clinical practice. High quality health data, obtained from a research setting or a real-world clinical practice setting, is hard to obtain, because health data is highly sensitive and its usage is tightly regulated.
Federated learning (FL) is a learning paradigm that aims to address these issues of data governance and privacy by training algorithms collaboratively without moving (copying) the data itself (Rieke et al., 2020; Teo et al., 2024). Based on ongoing work with the PLUGIN healthcare consortium (https://plugin.healthcare, in Dutch) we have detailed an architecture for FL for secondary use of health data for hospitals in the Netherlands. Starting point for this implementation are the National Health Data Infrastructure agreements for research, policy and innovation for the Dutch healthcare sector, which have been adopted at the beginning of 2024 (Health-RI, 2024). Figure 1 shows a high level overview of the platform, which comprises three areas (multiple use, applications and generic features) and a total of 26 functional components (for details please refer to (Health-RI, 2024)). One of the prerequisites of this architecture is that organizations that participate in a federation of ‘data stations’ use the same common data model to make the data Findable, Accessible, Interoperable and Resusable (FAIR). These FAIR data stations comprise components 7, 8 and 9 in Figure 1, i.e. the data, metadata and APIs, respectively, through which this the data station can be accessed and used.
Following the line of reasoning of Tsafnat et al., OMOP would be the go-to standard for storing the longitudinal data in each of the data stations. Indeed, by now there are quite a few reports of real-world implementations of federated learning networks based on the OHDSI-OMOP stack, including a global infrastructure with 22 centres for COVID19 prediction models (Khalid et al., 2021), FeederNet in South Korea with 57 participating hospitals (Lee et al., 2022), Dutch multi-cohort dementia research with 9 centres (Mateus et al., 2024), the European severe heterogeneous asthma research collaboration (Kroes et al., 2022) and the recently initiated Belgian Federated Health Innovation Network (FHIN) 4.
For the PLUGIN project, however, we choose to adopt FHIR as the common data model because of its practicality and extensibility to be used in a Python-based data science stack, provenance of RESTful APIs out-of-the-box to facilitate easy integration with the container-based vantage6 FL framework, and the support of many healthcare terminologies and flexibility through the profiling mechanims (Choudhury et al., 2020; Smits et al., 2022). Increasingly, other projects have reported the use of FHIR for persistent, longitudinal storage for FL. The CODA platform, which aims to implement a similar FL infrastructure in Canada, compared OMOP and FHIR and chose the latter as it has been found to support more granular mappings required for analytics (Mullie et al., 2023). The fair4health project has implemented also based on FHIR, using their own open source framework for the federated learning infrastructure itself (Sinaci et al., 2024).
Given that conceptually OMOP can be viewed as a strict subset of FHIR, hybrid solutions using OMOP and FHIR combined have also been reported, such as the German KETOS platform (Gruendner et al., 2019), and the preliminary findings from the European GenoMed4All project which aims to connect clinical and -omics data (Cremonesi et al., 2023). A collaboration of 10 university hospitals in Germany have shown that standardized ETL-processing from FHIR into OMOP can achieve 99% conformance (Peng et al., 2023), which confirms the feasiblity of the solution pattern where FHIR acts as an intermediate sharing standard through which data from (legacy) systems are extracted and made available for reuse in a common data model. One could argue that the distiction between FHIR amd OMOP becomes less relevant if data can be effectively stored in either standard. We are hopeful that initiatives like OMOP-on-FHIR indeed will foster convergence rather than collision between these two standards.5
In the case of PLUGIN, another important consideration for choosing FHIR over OMAP is, that from a data architecture perspective, the mechanism of FHIR Profiles can be tied to principle of late binding commonly applied in data lake/warehouse architectures: allow ingest of widely different sources, and gradually add more constraints and validations as you move closer to a specific use case. If machine learning is the primary objective for secondary use, we want to be able to cast a wider net of relevant data, rather than being to restrictive when ingesting the data at the start of processing pipeline. Late binding in data warehousing is a design philosophy where data transformation and schema enforcement are deferred as late as possible in the data processing pipeline, sometimes even until query time. This approach contrasts with early binding, where data is transformed and structured as it is ingested into the data warehouse. This principle is visualized as concentric circles (Figure 2). The advantages of this design is that it allows for greater flexibility. During the initial ingest of the data, we only require the data to conform to the minimal syntactic standard defined by the base FHIR version (R4 in the diagram). As the data is processed, more strict checks and constrains are applied, whereby ultimately different profiles can co-exists next to one another (the two most inner circles), within a larger circle with fewer strictions. This approach does not support the extension mechanism of FHIR, so we need to be cautious if we decide to use that.
We found that this principle of late binding also allows flexible and efficient implementations of the data stations that make use of the current best practices of the a lakehouse architecture of (Hai et al., 2023; Harby and Zulkernine, 2024, 2022) and the composable data stack (Pedreira et al., 2023). Lakehouses typically have a zonal architecture that follow the Extract-Load-Transform pattern (ELT) where data is ingested from the source systems in bulk (E), delivered to storage with aligned schemas (L) and transformed into a format ready for analysis (T) (Hai et al., 2023). The discerning characteristic of the lakehouse architecture is its foundation on low-cost and directly-accessible storage that also provides traditional database management and performance features such as ACID transactions, data versioning, auditing, indexing, caching, and query optimization (Armbrust et al., 2021). Lakehouses thus combine the key benefits of data lakes and data warehouses: low-cost storage in an open format accessible by a variety of systems from the former, and powerful management and optimization features from the latter. By explicitly aligining the mechanism of FHIR Profiles with this design pattern of a data lakehouse enables us to use complementary standards and open source components, most notably Apache Arrow as the standard columnar in-memory format with RPC-based data movement; Apache Parquet as the standard columnar on-disk format; and Apache Iceberg as the open table format.6
The main disadvantage in using FHIR in this way pertains to the need for upgrading the whole ELT pipeline when upgrading to a new primary FHIR version, for example R5. However, we expect that the development time required to upgrade FHIR versions is significantly less than the initial migration to FHIR.
[TO DO: add closing comments for this section]
Health data standards in LMICs
It is a widely held belief that digital technologies have an important role to play in strengthening health systems in LMICs. Yet, also here the current fragmentation of health data stands in the way of scaling up digital health programmes beyond project-centric, vertical solutions into sustainable health information exchanges. Mehl et al. have called for convergence to open standards, similar to Tsafnat et al., but additionally stress the need for open source technologies (our main argument of this paper), open content (representations of public health, health system or clinical knowledge to guide implementations) and open architectures (reusable enterprise architecture patterns for health systems) (Mehl et al., 2023). As for the open architecture, we see a convergence towards the OpenHIE framework (“OpenHIE Framework v5.0,” 2022), which has been adopted by many sub-Saharan African countries as the architectural blueprint for implementing nation-wide health information exchanges (HIE) (Mamuye et al., 2022), including Nigeria (Dalhatu et al., 2023), Kenya (Thaiya et al., 2021) and Tanzania (Nsaghurwe et al., 2021). Figure 3 shows an overview of the OpenHIE architecture.
While the OpenHIE specification is agnostic to which data standard should be used, in practice the digital health community in LMICs have de facto converged towards FHIR as main standard, in line with the proposal by Tsafnat et al. for health information exchange. To illustrate this point, consider the OpenHIM Platform architecture, which is currently the largest open source implementation of the OpenHIE specification Figure 4. Clients (Point-of-Service systems) can initiate various workflows to submit or query patient data. The Shared Health Record (SHR) acts as the core transactional system for the health information exchange, which in this case is realized with the HAPI FHIR server7, being one of the most widely used open source implementations ().
Looking at the Point of Service systems, we see that as of today OpenEHR does not play any role of significance as the standard for clinical administration. Within the context of LMICs, the largest open source EHR implementations are based on proprietary data models, and it is unlikely this will change any time soon (Syzdykova et al., 2017). Instead, we see that the FHIR-native OpenSRP framework (Mehl, 2020) being used more and more, where Android apps are used for clinical administration by health professionals (Figure 5). OpenSRP has been deployed in 14 countries targeting various patient populations, amongst which a reference implementation of the WHO antenatal and neonatal care guidelines for midwives in Lombok, Indonesia (Kurniawan et al., 2019; Summit Institute for Development, 2023). This solution design is particularly useful for mid-size and smaller healthcare facilities, which are often resource constrained, lacking basic IT infrastructure to deploy as full-blown electronic medical record system. Hence, by necessity, the FHIR-based SHR functions as the clinical administration system of record and as the hub for information exchange.
Finally, regarding longitudinal data analysis we also see a convergence towards FHIR as the primary standard. As is the case of federated learning, the choice for FHIR to implement datawarehouse and analytic platforms is the preferred method due to the widespread availibility of complementary open source technologies. FHIR-specific technologies such as Bulk FHIR data access and SQL-on-FHIR mentioned earlier, allow the FHIR ecosystem to be used, complemented and integrated with generic open source datawarehousing technologies such as Clickhouse8 and dbt.9
To summarize, we see that in the context of LMICs, the standardization of the three domains put forward by Tsafnat merge into one. The SHR, as the key component within the OpenHIE specification, serves as the back-end of the system-of-record and provides a transactional, persistent storage engine for information exchange. Downstream longitudinal data stores continu to use FHIR as the common data model for analytical purposes. One could argue that it may even be advantageous to converge to just one standard, thereby reducing complexity and cost of the total system. Thanks to the increasing availibility of open source implementations as digital public goods (“Digital Public Goods Alliance,” 2024) and integration projects such as Instant OpenHIE10 that we have a chance to move the needle in health data standardization for LMICs.
Conclusion
We agree with Tsafnat et al. that there is a dire need to converge to open data standards in healtcare, and support the proposal to focus on OpenEHR, FHIR and OMOP developments in healthcare informatics going forward. However, open standards are a necessary but not sufficient condition for convergence of health data standardization. The availiblity of open source implementations and complementary technologies are as important when choosing which open standard to use. Furthermore, we find that the proposed trichotomy is not always relevant, as we have shown in the case of federated learning en health information exchange in LMICs. As an alternative, we find that the full-STAC approach described by Mehl et al. more comprehensive.
References
Footnotes
See https://en.wikipedia.org/wiki/GSM#Initial_European_development.↩︎
https://build.fhir.org/ig/FHIR/sql-on-fhir-v2/↩︎
FHIR: https://confluence.hl7.org/display/FHIR/Open+Source+Implementations. OMOP: https://www.ohdsi.org/software-tools/. OpenEHR: https://openehr.org/products_tools/platform/↩︎
https://deltaplus.azdelta.be/az-delta30/zorginnovatie↩︎
https://omoponfhir.org↩︎
See https://arrow.apache.org, https://parquet.apache.org and https://iceberg.apache.org↩︎