Aligning Semantic Interoperability Frameworks with the FOXS Stack for FAIR Health Data

Abstract

Background FAIR Guiding Principles present a synergy with the use cases for digital health records, in that clinical data need to be found, accessible within a range of environments, and data must interoperate between systems and subsequently reused. The use of HL7 FHIR, openEHR, IHE XDS, and SNOMED CT (FOXS) together represents a specification to create an open digital health platform for modern health care applications.

Objectives To describe where logical FOXS components align to the European Open Science Cloud Interoperability Framework (EOSC-IF) reference architecture for semantic interoperability. This should provide a means of defining if FOXS aligns to FAIR principles and to establish the data models and structures that support longitudinal care records as being fit to underpin scientific research.

Methods The EOSC-IF Semantic View is a representation of semantic interoperability where meaning is preserved between systems and users. This was analyzed and cross-referenced with FOXS architectural components, mapping concepts, and objects that describe content such as catalogues and semantic artifacts.

Results Majority of conceptual Semantic View components were featured within the FOXS architecture. Semantic Business Objects are composed of a range of elements such as openEHR archetypes and templates, FHIR resources and profiles, SNOMED CT concepts, and XDS document identifiers. Semantic Functional Content comprises catalogues of metadata that were also supported by openEHR and FHIR tools.

Conclusions Despite some elements of EOSC-IF being vague (e.g., FAIR Digital Object), there was a broad conformance to the framework concepts and the components of a FOXS platform. This work supports a health-domain-specific view of semantic interoperability and how this may be achieved to support FAIR data for health research via a standardized framework.

Keywords

semantic interoperability - HL7 FHIR - IHE XDS - SNOMED CT - openEHR

Introduction

Modern health care applications are increasingly complex, requiring fully structured, semantically coherent clinical data to interoperate seamlessly with a plethora of digital consumers. With increasing scrutiny on how the data could be used for patient benefit, there is the acknowledgment that more can and should be done to aid clinical research. The FAIR Guiding Principles have been developed to ensure data are Findable, Accessible, Interoperable and Reusable[1] and adopted by organizations such as Health Data Research UK as a means to embrace open standards.[2] Nevertheless, there has been little evidence that FAIR principles have been adopted within the UK National Health Service outside of research.

There is a distinct synergy with the challenges presented in modern day health care and those faced by researchers that lead to the creation of the FAIR principles. Clinical care is delivered amongst a heterogenous landscape of care domains, specialisms, and pathways. A typical clinical referral from primary to secondary care or acute hospital may be supplemented by tertiary support services following discharge. The primary purpose of any care system is to represent the longitudinal record accurately and provide timely access at the point of need to enhance clinical processes.

Clinical data need to be found easily, accessible within a range of care environments and digital tools, that data may be interoperated between these systems and subsequently reused. It therefore stands that the goals outlined in the FAIR principles are aligned to those of any modern, digitally enabled health care system. Where value may be derived from effective use of data for patient care, this in turn should represent benefit for scientific research.

FAIR describes principals over specific technological implementations. This enables organizations such as the European Open Science Cloud[3] (EOSC) to develop implementation proposals for FAIR-enabled research to cover a diverse spectrum of interests. The EOSC Interoperability Framework[4] (EOSC-IF) is aligned to other technical approaches[5] to standardize a common architecture pathway. In doing so, it describes technical, semantic, organizational, and legal interoperability layers.

Previous work in this domain has aligned Fast Healthcare Interoperability Resources (FHIR) to the GO FAIR[6] FAIRification Workflow,[7] while openEHR has also been analyzed for goodness of fit to FAIR principles.[8] [9] The issue with these approaches is that components are rarely used in isolation within the health care enterprise. If the emerging “open” approach by care providers continues, it would suggest that research is required to align to a real-world view of multiple health care standards.

However, research alters the principal requirement from facilitating patient care to secondary use of data. Within the United Kingdom, Caldicott principles[10] describe the rules for how data may be persisted, retained, and shared. Domain-specific policies such as these pose significant challenges to aligning clinical data to FAIR. Patient consent will be required to permit data reuse, and for specific purposes. Additionally, any data pipeline that facilitates FAIR research will require anonymization of patient data to prevent identification. In certain circumstances, complete patient records may be permanently excluded from general research as they are identifiable through rare genetic disorders.[11] The requirements for enabling precision medicine may ultimately conflict with the need for patient privacy.

The FOXS stack of components ([Fig. 1]) represents a novel assembly of digital standards and specifications used in digital health care applications. Where implemented, these facilitate persistence and interoperable Application Programming Interfaces (APIs) that conform to validated, standardized, clinical models with openEHR[12] and HL7 FHIR,[13] respectively. Clinical data are augmented via SNOMED CT[14] to provide coding and terminology structures while IHE XDS[15] provides a capability to share documents and images at an enterprise level, utilizing common identifiers. While these components are not exhaustive, they represent a pattern of technological implementation in modern health care systems that is increasingly common, such as the use of openEHR and IHE XDS together.[16] [17] [18]

Fig. 1 Open platform architecture with FOXS Stack components comprising HL7 FHIR, openEHR, IHE XDS, and SNOMED CT.

FHIR[13] from HL7 are regarded as the standard for technical and syntactic interoperability[13] in the United Kingdom, championed by initiatives such as UK Core.[19] FHIR is represented via standardized Resources that align to specific data structures such as observations. To ensure message conformance, these resources are modeled into Profiles that underpin system APIs. FHIR represents the baseline for interoperability in a FOXS platform.

While standardization is key to harmonize interoperable transactions, the longitudinal health record necessitates greater granularity at a persistence level. Maintaining clinical data standards is important, and openEHR has been architected for this purpose. OpenEHR is a specification[12] that describes clinical models and the rules which govern them. Models take the form of Archetypes that describe detailed clinical concepts, and Templates that assemble multiple archetypes to address clinical use cases. It is constrained by a reference model and extended by components such as the Archetype Query Language (AQL).[20]

These structures may include clinical terminologies or classifications. SNOMED CT has been adopted in the United Kingdom[21] as a hierarchal clinical vocabulary for use with digital tooling and patient records. Within the FOXS context, SNOMED CT is integral to both persistence and interoperability use cases where data are created, read, or updated.

The traditional clinical document has long been the cornerstone of paper-based records but increasing scrutiny on structure of contained data has not alleviated the need for documents such as clinic letters to exist. The nature of many clinical processes still relies on attributing the rationale for clinical interactions and relaying findings accordingly. Integrating the Healthcare Enterprise (IHE) developed the Cross-Enterprise Document Sharing (XDS.b) as a standards-based specification[15] to support the sharing of documents and images between health organizations, with clear unique attribution to the patient. This represents an envelope of contextual metadata, containing clinical information that is key to maintaining provenance.

Standardized structures for documents may also be created in either openEHR or FHIR, each containing SNOMED CT concepts. However, neither has demonstrated implementation at scale that rivals the more mature standard of IHE XDS.b for interoperability of documents across health domains.[22] This also describes an important facet of FOXS; using best of breed components at the specification level.

While FOXS aligns to the open platform approach,[23] there is no impediment to utilizing other components such as Logical Observation Identifiers Names and Codes (LOINC)[24] where appropriate. Akin to FAIR, FOXS does not mandate the technological implementation and several additional logical components are needed to realize a deployable platform (e.g., master patient index, authentication services).

Objectives

This work proposes a novel architectural approach utilizing the FOXS stack to support next-generation digital care records that align with FAIR principles. In doing so, the requirement for data intrinsic to the fabric of the care record will be described as suitable for research and secondary use, based upon common standards and supporting clear data persistence and interoperability use cases.

Initial exploration in this area looked at the broad feasibility of aligning FOXS components to the principles of FAIR data access.[25] This article outlines an extension to previous work in applying FOXS to supporting the technical architecture for semantic interoperability as outlined in the EOSC-IF[4]. The objective is to determine if logical FOXS components map to categorized elements of the EOSC-IF Semantic View (SV), representing a reference architecture for semantic interoperability. It provides a link between real-world digital health components that may also support health research communities with timely, reliable datasets.

Methods

EOSC-IF SV is a representation of semantic interoperability where meaning is preserved between systems and users. This is opposed to technical interoperability which facilitates computability through messaging, the traditional interface deployed in health care such as HL7 v2, and syntactic interoperability where data formats and communication protocols are harmonized. Technical and syntactic interoperability are both considered “structural” by HIMSS (Healthcare Information and Management Systems Society)[26] while syntactic is incorporated into the definition semantic by the European Interoperability Framework.[27] FOXS simplifies this view as common syntax is deployed at all levels of platform messaging. Broadly, FOXS considers HL7 FHIR as offering technical and syntactic interoperability, while openEHR represents a more complete semantic understanding of clinical data.

The EOSC-IF semantic layer is composed of concepts and objects that describe content such as catalogues and semantic artifacts. It also features several recommendations which were considered as part of the analysis to aid the mapping process to aid the synthesis. These variables were subjectively cross-referenced with FOXS architectural component specifications (and published use cases where available) within a mapping table.

Where clear definitions of EOSC-IF elements were available, a direct link in FOXS was recorded with attention paid for specific sub-components. Where EOSC-IF definitions were ambiguous or missing, the comparative FOXS representation was inferred, or ignored. For example, a description of the Semantic Interoperability Agreement was missing entirely while the definition of semantic artifact has no common agreement (although implied here). It is acknowledged that the current EOSC-IF Specification is intended to represent a higher level of granularity, and therefore the mappings are an interpretation.

We are do not consider other layers of interoperability in this work such as Legal or Technical, focusing instead on semantic to assess the ability for baseline clinical models to support the framework. Further work in this domain would need to consider these additional layers as well as the wider set of EOSC recommendations.

Results

The mapping of EOSC-IF elements to the FOXS architecture is presented in [Fig. 2]. At a high level, there is broad compatibility with EOSC-IF. It is implied from previous work[25] that the adherence to FAIR principles has been demonstrated through FOXS stack. Despite EOSC-IF being a draft framework, clear synergy with FOXS stack provides a pathway to logical implementation for health domain use cases.

Fig. 2 Adapted EOSC-IF Semantic View[4] aligned to FOXS architecture. Components are mapped as follows: HL7 FHIR (F), openEHR (O), IHE XDS (X), and SNOMED CT (S).

The EOSC SV is conceptual and may be delivered by one or more solution building blocks. The basis of this abstraction lends itself well to the FOXS interpretation as data may be delivered either through the persistence (openEHR) or interoperability (FHIR) layers. OpenEHR archetypes are predicated upon a maximal approach to clinical requirements and can support the lossy transformation to a more focused, limited model to support either interoperability or addressing a specific research question.

Archetypes are a conceptualized model of the clinical requirement, made operationally viable by the technological stack that interoperates them. The core persistence layer allows for variance as per the requirements of the clinical research that may be manifest within the initial data request. But unlike comparable solutions predicated wholly in FHIR,[7] FOXS does not require the source of truth to be restated upon each iteration. Components to allow additional value within data to be delivered via mapping or transform to terminology are not needed. The baseline archetype model enables a more holistic view on potential data quality. This is principally because FOXS facilitates clinical system building through robust and open clinical models that support varied persistence requirements, standardized where needed through a conformant interoperability layer.

An archetype (e.g., blood pressure) may be recomposed within FHIR Profiles that reflect various clinical contexts, but can retain its unique persistence where new research questions are raised. AQL is key to this, as it provides a means for both direct extraction of clinical data from openEHR, transform into a FHIR structure, and load into a normalized repository for research as required (ETL).

Elements of the SV such as Data Syntax and Open Format are represented through platform adherence to W3C standard web-based protocols (e.g., SOAP, REST) and support for common formats (e.g., XML, JSON, RDF).

All FOXS components make use of unique identifiers for metadata and content and dependent on the artifact being sought, a variety of search vectors are available. XDS presents an affinity domain that utilizes metadata structures to locate records consisting of different data standards. This is noted as a candidate for the Identifier Scheme. However, FHIR, openEHR, and SNOMED CT all feature unique and searchable identifiers for metadata.

Semantic Business Objects

EOSC-IF acknowledges that the level of formality in describing data structures will vary. FOXS requires computability as standard and therefore espouses a formal approach within the persistence layer that becomes increasingly flexible to support messaging. The exchange of semantically interoperable data is a principal requirement for digital health tooling and systems.

EOSC-IF Semantic Business Objects resulting from FOXS components can be considered domain-specific metadata frameworks. To enhance interoperability, linkages to generic frameworks can ascribe foundational elements such data types to common definitions. The openEHR Archetype Definition Language[28] and FHIR Foundation Module[29] are examples of Minimal Metadata. Providing a computable route for the Conceptual Metadata object is possible owing to the mapping between ISO11179 and FHIR.[30] This in turn requires any data transformations from persistence to messaging to be closely defined which is supported by the openEHR Reference Information Model and FHIR base resources. This forms EOSC-IF Domain Metadata.

Data Models are not defined by EOSC-IF. Formally modeled archetypes are the computable manifestation for clinical content and therefore represent a definition in this context. It could be argued that FHIR resources themselves fall into this category, however this only applies to specific examples.

FHIR positions resources at a use case level that does not equate to the same level of semantic comprehension as an openEHR archetype. For example, the FHIR AllergyIntolerance Resource[31] and openEHR Adverse Reaction Risk archetype[32] both contain largely similar content models. However, to capture a blood pressure, FHIR offers an Observation resource [33] within which the clinical data reside. Conversely, an openEHR Observation archetype object class (part of the openEHR Reference Model[34]) would be used to create an equivalent model such as Blood Pressure.[35]

This analysis begins to constrain the definition of the Semantic Artifact as something that is an object in its own right, as well as an assembly of smaller components such as terminology or domain models. Within the health domain context and FOXS, a Semantic Artifact is a formulation of objects that results in a clearly defined semantic entity for data persistence or interoperability use cases, i.e., an openEHR template, FHIR Profile, or SNOMED CT concept.

Terminology is key for the development of digital health records, but closely associated with Controlled Vocabulary or other reference data, examples of which may include clinic site locations or lists of staff within a hospital. The requirements to standardize coded data are supported by SNOMED CT which may be embedded or referenced by data models, and subsequently be included within the Semantic Artifact. Equally, the presence of SNOMED CT or other reference data may feature in the remaining platform components either through models or within data itself. SNOMED CT augments the terminology that exists within the openEHR reference model and may be represented via FHIR-based message structures.[36]

Finally, the Ontology object is supported by the baseline data models themselves. Arguably a summation of the entire FOXS architecture, this is enabled by the maximal approach to developing models with openEHR for a wide range of clinical use cases. An ontological view may be derived from a mature electronic health record over time that represents a clinically broad, longitudinal record with uniquely identifiable data to underpin it.

Semantic Functional Content

Components considered within EOSC-IF Semantic Functional Content facilitate semantic interoperability through repositories that catalogue metadata, artifacts, and mappings between. The Metadata Catalogue and Semantic Artifact Catalogue are largely homogenized with two specific components; the openEHR Clinical Knowledge Manager (CKM)[37] and the FHIR Simplifier repository that is home to projects such as UK Core.[38] Although publicly accessible, both offer proprietary-licensed functionality for each respective technology. They present a complete view of all clinical models and how they may be implemented at the API level.

CKM can be viewed as the Semantic Clinical Artifact Catalogue with openEHR archetypes and templates listed and available for import into local repositories. Simplifier[39] represents the domain technical interoperability catalogue, with guidance on how machine-readable data may be retrieved, focused on interoperability use cases. It also excludes naming systems and associated metadata that allow for identification of resources and concepts (e.g., terminologies). Both are considered metadata repositories from a FAIR perspective.

The Mapping Repository is key as it provides a means of linking clinical concepts and reference data with operational systems. An example of which in common use, Ontoserver,[36] may contain SNOMED CT concepts and local reference data available via a FHIR-based API. This makes references to Controlled Vocabulary and Terminology available as a catalogue, computable for applications, and be able to be incorporated within a Semantic Artifact. A FHIR-based terminology server is a technological enabler for FOXS implementations, loosely coupling concept content from semantic artifacts which is more manageable in operational environments. A secondary use of the Mapping Repository requires the capability to crosswalk between metadata standards. SNOMED CT provides mapping to Dictionary of Medicines and Devices (dm + d)[40] as unique identifiers used in dm + d are themselves SNOMED CT codes. Manual mapping between other classifications systems is also feasible.

Discussion

It has been shown that the FOXS stack represents a health domain focused example of EOSC-IF, even in this framework's nascent state. While clarity is required in certain areas, FOXS represents an approach to harmonize the requirements of digital health systems and services with those of scientific research. EOSC-IF describes a FAIR Digital Object as a “boundary around a set of data points” which could be inferred as any output from FOXS in terms of XDS.b document, FHIR bundle, or openEHR composition. Importantly, it reflects clinical data that are aligned to a defined use case. This flexibility is welcome in supporting EOSC-IF as it matures, and this comparison may inform progress if FAIR principles for data within health care gather momentum. The fact that both openEHR and FHIR are openly published specifications further adds to support of the EOSC-IF approach and conforms to their general recommendations.[4]

The value of this research is predicated upon the ESOC Framework itself being of benefit. ESOC-IF is not mature and therefore the comparison detailed is oriented on empirically gathered evidence. However, the increasing adoption of FOXS components independently (or as a whole) may in turn support a maturation of EOSC-IF where health systems are being deployed with support from academia or within a university hospital ecosystem. This could be tested with analysis from new deployments of FOXS within health care environments.

Parallel work has looked at the goodness of fit for FOXS components and the broad findings have deemed openEHR “FAIR-enabling by design”[8] and support FAIRification processes[9] which reflect our findings. The production of Semantic Artifacts such as Observational Medical Outcomes Partnership (OMOP) from openEHR and FHIR sources has been studied[41] drawing conclusions that there are direct mappings that are feasible, when containing SNOMED CT and LOINC concepts. This is partially concerned with the reduction in granularity from openEHR to the more basic structures of OMOP. There are issues with attempting to automate this process however.

Direct OMOP to FHIR[42] transforms are being attempted, as well as working groups looking to harmonize FHIR with BRIDG reference model.[43] FAIRification workflows have been applied to FHIR, described to support the processing of raw data to become FAIR.[7] While the aggregation of raw data from multiple data sources is of particular relevance to heterogenous health data economies, applicability of a FOXS architecture is predicated upon a common baseline data model manifested within openEHR.

With several recent deployments of openEHR solutions in the United Kingdom and Europe, it is feasible to assume that the clinical data model has been harmonized to the extent where raw data are by definition highly structured and computationally semantic. This alters the modelling stage of examples such as the Go FAIR process[44] to become one of the dataset assemblies. In this case utilizing either AQL or some other FHIR-based query could enable an export to a predefined FAIR Digital Object.

FOXS inclusion of SNOMED CT makes clear that standards for disease classification and clinical vocabularies are essential. While SNOMED CT is highlighted, equivalent architecture stacks may include other standards such as International Classification of Disease[45] or LOINC,[24] bound to the persisted data structures or mapped where required for interoperability.

Just as FHIR profiles or openEHR templates reflect specific clinical use cases, these use cases are de facto Semantic Artefacts that may also be attributed to scientific research. It may be questioned why this process should involve FHIR based resources at all, given that research data syntax is not standardised around the HL7 standard, and that several transforms and normalisation processes may be required in order to make health data actionable in the research context.

However, while FHIR offers an alignment to conceptual metadata frameworks such as ISO11179, further research is necessary to provide mapping from openEHR. Clinical data is frequently viewed within the prism of being lossy by definition. Data silos with differing views on how a “truth” may be constructed have to be mapped and merged. This results in data that conforms to a minimum number of data fields common to both systems leading to a lowest common denominator solution which may be of limited use for clinical and research enquiry. By restricting the richness of data via interoperability routes (i.e. FHIR only), systems will give up a more solid platform comprised of richer, standardised data structures within the persistence layer.

While it is fair to address the separation in concerns of application to data, we must not lose sight that research is itself an application. Attempts to provide technical solutions that cannot “own” the persistent data layer will inevitably be ephemeral as any message or format choices are defined by a use case that is not necessarily compatible with the much broader parameters required for research.

This technical alignment with EOSC deliberately eschews considerations such as ethics, legality, and privacy concerning health data as the FOXS stack is principally constructed to deliver a longitudinal patient care record. Systems that consume these data are themselves subject to these requirements and therefore the data store and flow processes are largely abstracted. This does not preclude a security layer within FOXS in terms of appropriate access and audit data capture.

However, for operational health data to be made FAIRified, there is still a need for deidentification and pseudonymization routines, although this may form part of the data publishing process. Indeed, the proposed FAIRification Workflow[7] based wholly on FHIR would benefit from an openEHR persistence layer to prevent the restating of data when anonymization routines are applied.

Conclusion

The implications of this work indicate that there is alignment between operational platform tools deployed within health domains and those of research. FOXS represents a convergence of current health-focused technologies. Combining the maximal approach for clinical models and persistence in openEHR with an industry-standard syntax for messaging in HL7 FHIR, health care institutions are afforded a seamlessly interoperable baseline for health data. As previously stated,[25] “the assembly attempts to enable FAIR-ness by way of facilitating data access through one or more routes within a FOXS platform.” This should in turn support researchers by not needing to extend current standards such as FHIR to facilitate their specific objectives.

This EOSC Interoperability Taskforce recommends[4] that a detailed specification of architecture building blocks to be further defined. This article provides a perspective of the health community predicated upon an open platform containing structured data that is natively interoperable. Importantly, it is also possible for FOXS components to represent elements of the EOSC-IF SV, and is therefore a FAIR-enabling data provider. A limitation of the FOXS stack lies in the lack of complete, formal implementation to date. However, deployments of FHIR, openEHR, XDS, and SNOMED CT are now common by European health providers. Any implementation of openEHR and/or FHIR should in turn support feasible FAIR use of data.

This article does not describe details regarding the nature of FAIR Digital Objects and the wider complexities of sharing health data to external scientific domains. These elements are positioned as high level and of variable detail in the source framework. However, by implementing FOXS in operational environments, the potential for highly granular, structured clinical data to inform scientific research is feasible. Additionally, we do not seek to address the co-dependency or interference of individual components, for example, optimal mapping between openEHR templates and FHIR profiles, or a comparison between the XDS and the emerging FHIR document standard. Future work will focus on these concerns, as well as formally defining the FOXS stack with a view to supporting the remaining EOSC-IF views and framework components. Specifying the data flow with additional pipeline components to produce consistently structured FAIR Digital Objects is key. Additionally, further analysis on how each FOXS component supports or interferes with the wider stack is also required.

Conflict of Interest

None.

• References

• 1 Wilkinson MD, Dumontier M, Aalbersberg IJJ. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 2016; 3 (01) 160018
• 2 UK Health Data Research Alliance. . Recommendations for Data Standards in Health Research.; 2021. Accessed January 11, 2022. https://www.hdruk.ac.uk/news/health-data-research-uk-publishes-recommendations-for-data-standards-in-health-research/
• 3 Open Science Cloud - Shaping Europe's digital future. Accessed March 31, 2022 at: https://digital-strategy.ec.europa.eu/en/policies/open-science-cloud
• 4 European Commission Directorate-General for Research and Innovation;. Corcho O, Eriksson M. et al. EOSC Interoperability Framework?: Report from the EOSC Executive Board Working Groups FAIR and Architecture. Publications Office; 2021.
• 5 The New European Interoperability Framework | ISA ² . Accessed March 31, 2022 at: https://ec.europa.eu/isa2/eif_en
• 6 GO FAIR Initiative. Accessed March 31, 2022 at: https://www.go-fair.org/go-fair-initiative/
• 7 Sinaci AA, Núñez-Benjumea FJ, Gencturk M. et al. From raw data to FAIR data: the FAIRification workflow for health research. Methods Inf Med 2020; 59 (S 01): e21-e32
• 8 Frexia F, Mascia C, Lianas L. et al. openEHR is FAIR-enabling by design. Stud Health Technol Inform 2021; 281: 113-117
• 9 Bönisch C, Sargeant A, Wulff A, Parciak M, Bauer CR, Sax U. FAIRness of openEHR Archetypes and Templates. Published online 2019. Accessed July 29, 2021. https://ceur-ws.org/Vol-2849/paper-12.pdf
• 10 UK Caldicott Guardian Council. The Eight Caldicott principles. Published December 2020. Accessed July 30, 2021 at: https://www.ukcgc.uk/manual/principles
• 11 Hansson MG, Lochmüller H, Riess O. et al. The risk of re-identification versus the need to identify individuals in rare disease research. Eur J Hum Genet 2016; 24 (11) 1553-1558
• 12 openEHR Foundation. What is openEHR? Published 2019. Accessed June 6, 2021. https://www.openehr.org/about/what_is_openehr
• 13 Health Level Seven (HL7). . FHIR Overview. Accessed July 26, 2021. https://www.hl7.org/fhir/overview.html
• 14 SNOMED 5-Step Briefing. Accessed March 31, 2022 at: https://www.snomed.org/snomed-ct/five-step-briefing
• 15 IHE International. Cross-Enterprise Document Sharing (XDS.b). IHE ITI Technical Framework (Rev17 Vol1). Accessed July 27, 2021. https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html
• 16 Wettstein R, Merzweiler A, Klass M, Heinze O. Using openEHR in XDS.b environments - opportunities and challenges. Stud Health Technol Inform 2020; 272: 300-303
• 17 Sara Mageit. The European digital health revolution in the wake of COVID-19. Healthcare IT News. Published April 12, 2021. Accessed March 31, 2022 at: https://www.healthcareitnews.com/news/emea/european-digital-health-revolution-wake-covid-19
• 18 Cora Lydon. Somerset NHS Foundation Trust rolls out digital assessment forms. Digital Health. Published 2021. Accessed March 31, 2022 at: https://www.digitalhealth.net/2021/10/somerset-digital-assessment-forms/
• 19 FHIR UK Core - NHS Digital. . Accessed July 26, 2021 at: https://digital.nhs.uk/services/fhir-uk-core
• 20 openEHR Specification Program. Archetype Query Language (AQL). Accessed April 7, 2020 at: https://specifications.openehr.org/releases/QUERY/latest/AQL.html#_aql_syntax_specification
• 21 SNOMED CT. . NHS Digital. Accessed March 31, 2022 at: https://digital.nhs.uk/services/terminology-and-classifications/snomed-ct
• 22 Joe Marion. The Worldly XDS. Healthcare Innovation. Published March 27, 2015. Accessed April 4, 2022 at: https://www.hcinnovationgroup.com/interoperability-hie/blog/13024847/the-worldly-xds
• 23 Apperta Foundation. Defining an Open Platform. ; 2018. Accessed December 23, 2022. https://apperta.org/openplatforms/
• 24 What LOINC is. loinc.org. Accessed March 18, 2022 at: https://loinc.org/get-started/what-loinc-is/
• 25 Meredith J, Whitehead N, Dacey M. Utilising the FOXS Stack for FAIR architected data access. Stud Health Technol Inform 2021; 287: 134-138
• 26 Healthcare Information and Management Systems Society. What is Interoperability? HIMSS. Accessed April 9, 2018 at: http://www.himss.org/library/interoperability-standards/what-is
• 27 European Commission. . Annex 2. In: European Interoperability Framework – Implementation Strategy. European Commission; 2017. Accessed April 2, 2022. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2017:134:FIN
• 28 openEHR Specification Program. Archetype Definition Language 2 (ADL2). Published 2021. Accessed April 3, 2022 at: https://specifications.openehr.org/releases/AM/latest/ADL2.html
• 29 Foundation-module FHIR. v4.6.0. Published 2022. Accessed April 3, 2022 at: https://build.fhir.org/foundation-module.html
• 30 FHIR v4.0.1 Element Definition. hl7.org. Accessed April 1, 2022 at: http://hl7.org/fhir/elementdefinition.html
• 31 FHIR AllergyIntolerance Resource v4.6.0. Accessed April 3, 2022 at: https://build.fhir.org/allergyintolerance.html
• 32 openEHR Foundation. Adverse reaction risk, Published archetype [Internet]. openEHR Clinical Knowledge Manager. Published 2021. Accessed April 3, 2022 at: https://ckm.openehr.org/ckm/archetypes/1013.1.1713
• 33 Observation Resource FHIR. v4.6.0. Accessed April 3, 2022 at: https://build.fhir.org/observation.html
• 34 openEHR Specification Program. EHR Information Model. openEHR Specifications. Accessed April 3, 2022 at: https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_information_model
• 35 openEHR Foundation. Blood pressure, Published archetype [Internet]. openEHR Clinical Knowledge Manager. Published 2021. Accessed April 3, 2022 at: https://ckm.openehr.org/ckm/archetypes/1013.1.3574
• 36 Metke-Jimenez A, Steel J, Hansen D, Lawley M. Ontoserver: a syndicated terminology server. J Biomed Semantics 2018; 9 (01) 24
• 37 OpenEHR Clinical Knowledge Manager (CKM). . Published online 2019. Accessed December 23, 2022 at: https://ckm.openehr.org/ckm/
• 38 HL7 FHIR® UK Core R4. SIMPLIFIER.NET. Accessed April 3, 2022 at: https://simplifier.net/hl7fhirukcorer4
• 39 The FHIR collaboration platform - SIMPLIFIER.NET. Accessed April 3, 2022 at: https://simplifier.net/
• 40 Dictionary of medicines and devices (dm+d) | NHSBSA. Accessed April 3, 2022 at: https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
• 41 Rinaldi E, Thun S. From OpenEHR to FHIR and OMOP data model for microbiology findings. Stud Health Technol Inform 2021; 281: 402-406
• 42 OMOP on FHIR. . Accessed April 2, 2022 at: https://omoponfhir.org/
• 43 BRIDG. . HL7 & FHIR - Biomedical Research Integrated Domain Group. National Cancer Institute. Published 2021. Accessed July 26, 2021 at: https://bridgmodel.nci.nih.gov/hl7-fhir
• 44 FAIRification Process. . Accessed March 18, 2022 at: https://www.go-fair.org/fair-principles/fairification-process/
• 45 International Classification of Diseases (ICD). . Accessed March 18, 2022 at: https://www.who.int/standards/classifications/classification-of-diseases

Publication History

Received: 04 April 2022

Accepted: 30 November 2022

Accepted Manuscript online:
06 December 2022

Article published online:
13 February 2023