This paper is in the following e-collection/theme issue:

Reviews in Medical Informatics (93) Knowledge Translation and Implementation Science (407) Theoretical Frameworks and Concepts (263) Big Data (245) E-Health / Health Services Research and New Models of Care (542) Clinical Informatics (1050) Health Information Exchange (105) Standards and Interoperability (78) eHealth Infrastructures (357)

Published on in Vol 11 (2023)

Preprints (earlier versions) of this paper are available at https://preprints.jmir.org/preprint/44842, first published .
Designing Interoperable Health Care Services Based on Fast Healthcare Interoperability Resources: Literature Review

Designing Interoperable Health Care Services Based on Fast Healthcare Interoperability Resources: Literature Review

Designing Interoperable Health Care Services Based on Fast Healthcare Interoperability Resources: Literature Review

Authors of this article:

Jingwen Nan1 Author Orcid Image ;   Li-Qun Xu1 Author Orcid Image
Article Authors Cited by (9) Tweetations (2) Metrics

    Review

    Health IT Research, China Mobile (Chengdu) Industrial Research Institute, Chengdu, China

    Corresponding Author:

    Li-Qun Xu, PhD

    Health IT Research

    China Mobile (Chengdu) Industrial Research Institute

    Unit 2, Block C1, AI Innovation Center

    Hele Second Street, Gaoxin District

    Chengdu, 610213

    China

    Phone: 86 (28) 60103585

    Email: xuliqun@chinamobile.com


    Background: With the advent of the digital economy and the aging population, the demand for diversified health care services and innovative care delivery models has been overwhelming. This trend has accelerated the urgency to implement effective and efficient data exchange and service interoperability, which underpins coordinated care services among tiered health care institutions, improves the quality of oversight of regulators, and provides vast and comprehensive data collection to support clinical medicine and health economics research, thus improving the overall service quality and patient satisfaction. To meet this demand and facilitate the interoperability of IT systems of stakeholders, after years of preparation, Health Level 7 formally introduced, in 2014, the Fast Healthcare Interoperability Resources (FHIR) standard. It has since continued to evolve. FHIR depends on the Implementation Guide (IG) to ensure feasibility and consistency while developing an interoperable health care service. The IG defines rules with associated documentation on how FHIR resources are used to tackle a particular problem. However, a gap remains between IGs and the process of building actual services because IGs are rules without specifying concrete methods, procedures, or tools. Thus, stakeholders may feel it nontrivial to participate in the ecosystem, giving rise to the need for a more actionable practice guideline (PG) for promoting FHIR’s fast adoption.

    Objective: This study aimed to propose a general FHIR PG to facilitate stakeholders in the health care ecosystem to understand FHIR and quickly develop interoperable health care services.

    Methods: We selected a collection of FHIR-related papers about the latest studies or use cases on designing and building FHIR-based interoperable health care services and tagged each use case as belonging to 1 of the 3 dominant innovation feature groups that are also associated with practice stages, that is, data standardization, data management, and data integration. Next, we reviewed each group’s detailed process and key techniques to build respective care services and collate a complete FHIR PG. Finally, as an example, we arbitrarily selected a use case outside the scope of the reviewed papers and mapped it back to the FHIR PG to demonstrate the effectiveness and generalizability of the PG.

    Results: The FHIR PG includes 2 core elements: one is a practice design that defines the responsibilities of stakeholders and outlines the complete procedure from data to services, and the other is a development architecture for practice design, which lists the available tools for each practice step and provides direct and actionable recommendations.

    Conclusions: The FHIR PG can bridge the gap between IGs and the process of building actual services by proposing actionable methods, procedures, and tools. It assists stakeholders in identifying participants’ roles, managing the scope of responsibilities, and developing relevant modules, thus helping promote FHIR-based interoperable health care services.

    JMIR Med Inform 2023;11:e44842

    doi:10.2196/44842

    Keywords

    Health level 7 Fast Healthcare Interoperability Resources; HL7 FHIR; interoperability; literature review; practice guideline; mobile phone 


    Background

    The development and innovation of health care service models have accelerated the demand for data exchange and service interoperability. In the United States, the Health Information Technology for Economic and Clinical Health Act took effect in 2009, specifying health IT–based systems as an integrated part of the country’s health care reform. It has spurred the electronic health record (EHR) adoption rate through reward and punishment measures [1]. In addition, the US Department of Health and Human Services established a specific agency, the Office of the National Coordinator for Health Information Technology, to accelerate the implementation of advanced medical IT standards, promote the exchange of electronic health care information, and improve the quality of health care services throughout the country. In Canada, the federal government funded an independent, not-for-profit organization called Canada Health Infoway, tasked with accelerating the adoption of digital health solutions, such as EHR, across the country. The government has set a 10-year implementation strategy for EHR in cooperation with the Canadian Institute for Health Information [2]. Japan has made great efforts to develop remote health care technology and has established a communication system among regional institutions by implementing electronic medical records (EMRs) in the form of an app or software as a service [3]. In China’s state health system, major public hospitals administered by national, provincial, and local health authorities are the pioneers in reforms. Over the years, the government has issued a series of policies promoting coordinated care among health care institutions at different levels of the health system [4,5], together with many qualitative or quantitative assessment criteria that guide the establishment of high-standard EMR system, regional information interoperability, and intelligent service and management in hospitals. In summary, the demand for tiered and coordinated care delivery among health care institutions worldwide is increasing rapidly, and the requirement for health care data exchange continues unabated.

    The enhancement of interoperability is required by transforming health care service models and tackling the challenges of societal problems. According to a United Nations report [6], the share of the population aged ≥65 years is expected to increase from 9.3% in 2020 to approximately 16% in 2050. The rapid aging of the population unavoidably increases the burden of chronic disease care, bringing about the requirements for people-centered and continuous care delivery built on the foundation of a robust primary health care system. Therefore, it is necessary to enhance health IT system interoperability to bridge the gap between uneven health care resource distribution, remove the barrier of isolated data islands, and comprehensively improve the quality of health care services.

    Health Level 7 Fast Healthcare Interoperability Resources

    Health Level 7 (HL7), founded in 1987, is a not-for-profit, standards-developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery, and evaluation of health services. It has successively released many standards, including HL7 version 2, HL7 version 3, and Clinical Document Architecture (CDA). However, with the constant evolution of the internet and the thriving of the application programming interface (API) economy, digital services or assets of health organizations tend to be exposed even more widely in the form of APIs. In this context, HL7 formally introduced Fast Healthcare Interoperability Resources (FHIR) in 2014, highlighting the core concept of resources, and thus, creating a new era for health care service interoperability. A resource is the smallest exchangeable logical unit in FHIR. Resources are independent of each other but can be linked or assembled through specific rules to meet diverse service requirements. FHIR combines web standards to support resource operations through RESTful API in XML or JavaScript Object Notation format. Compared with other alternative standards, FHIR has more advantages and potential, such as comprehensive coverage of data definitions, substantial flexibility of data exchange, explicit semantics, and many available open-source tools, among others. Therefore, it has attracted constant and favorable attention from health care stakeholders since its first release, as shown in Figure 1.

    We investigated the literature from the Web of Science and plotted 2 statistical charts in Figure 1. Figure 1A shows the promotion trends of different health data standards. By using the search term “HL7 v2,” “HL7 v3,” “HL7 CDA,” and “FHIR,” we identified the corresponding papers in the Web of Science database from 2010 to 2022. The results show that the attention paid to FHIR has increased rapidly within a short time, far exceeding the HL7 version 2, HL7 version 3, and CDA standards. Figure 1B compares FHIR-relevant literature among different countries. We used the search term “FHIR” to find the corresponding papers in the Web of Science database from 2014 to 2022. By reading each paper’s abstract and the corresponding author’s information, we identified the country to which the work belongs. Countries that record <5 papers fall into the “others” category. The chart shows that the United States, Germany, and Canada were the top 3 countries that published the most studies on FHIR, accounting for 28.39% (197/694), 11.67% (81/694), and 4.18% (29/694), respectively.

    In addition to the dissemination activities of enthusiastic researchers and pioneering health IT ecosystem players, national health policy makers also play a pivotal role in FHIR adoption, as evidenced by the actions in the United Kingdom, United States, and Canada [7]. Overall, FHIR has gradually gained worldwide recognition and acceptance, and it has the most potential for future large-scale promotion in the health care ecosystem.

    ‎
    Figure 1. Works of literature that focus on health data standards. (A) The attention to Fast Healthcare Interoperability Resources (FHIR) has risen rapidly within a short time of its first release, far exceeding HL7 version 2, HL7 version 3, and Clinical Document Architecture (CDA) standards. (B) The United States, Germany, and Canada are the top 3 countries that published the most literature on FHIR. HL: Health Level.

    Objectives

    Owing to the growing popularity of FHIR, some academic researchers have authored review papers from their perspectives in the last few years. Ayaz et al [8] searched for FHIR-related papers published between 2012 and 2019 in 6 databases (ACM, IEEE, Springer, Google Scholar, PubMed, and ScienceDirect) and selected 80 papers for review. They found that FHIR is identical in supporting intelligent technologies, such as smartphones, tablets, mobile health apps, smartwatches, and fitness trackers, which could solve numerous health care problems that were impossible for the previous standards. Lehne et al [9] searched for FHIR-related papers in 2 databases (Web of Science and PubMed) up to 2019 and selected 131 papers for review. The statistical results revealed that data model–related topics mainly focusing on constructing profiles to implement FHIR in specific scenarios were the most attractive direction. At the same time, analytics-related topics concerning data analysis, modeling, machine learning, and more were less attractive because most FHIR projects were still in the initial development phase, dealing with implementation and data definitions rather than large-scale data analysis. Barker and Johnson[10] surveyed 734 apps released up to December 2020 in 5 digital health care application libraries (hosted by Cerner, Epic, Allscripts, Athenahealth, and Substitutable Medical Applications Reusable Technologies [SMART]) and measured their support for FHIR. They found that the number of apps that support the FHIR standard had increased from 19% in 2019 to 22% in 2020.

    However, to our knowledge, there is a lack of systematic reviews that focus on the FHIR practice. A gap remains between the FHIR Implementation Guide (IG) and building actual services because IGs are rules specifying no methods, procedures, or tools. Thus, stakeholders may feel it nontrivial to participate in the ecosystem, giving rise to the need for a more actionable practice guideline (PG) for promoting FHIR’s fast adoption. Therefore, this study proposed a general FHIR PG to facilitate stakeholders in the health care ecosystem to understand FHIR and quickly develop interoperable health care services.


    Article Selection

    Figure 2 presents the paper selection flowchart used in this review. Initially, we identified a total of 487 papers in the Web of Science and IEEE databases by using the search term “FHIR” or “Fast Healthcare Interoperability Resources.” The time range of publications was set from January 1, 2020, to July 1, 2022, and we finalized 205 articles. After excluding those that merely mentioned the term FHIR but did not elaborate on it, 65 articles were retained. A check of duplications from this batch removed a further 3 articles. Finally, from the references of the remaining 62 articles, we found an additional 23 relevant articles, ending up with a total of 85 articles as the research materials of this study.

    ‎
    Figure 2. Flowchart of paper selection.

    Analysis Process

    By carefully analyzing and collating the recent studies on the design of FHIR-based interoperable health care services, we derived the details of the FHIR PG.

    We selected 85 FHIR-related articles and found that building FHIR-based health care services contains typically 3 stages, that is, data standardization, data management, and data integration. Each stage may use different practice methods, depending on the targeted scenarios and types of services.

    The way to categorize these 85 articles is as follows: if an article’s main innovation feature focused on 1 of the 3 stages, we assigned it to the corresponding group. Specifically, we assigned those articles emphasizing the design process of FHIR profiles or proposing methods for migrating data from specific clinical data models (CDMs) to FHIR to the data standardization group, articles discussing the management of RESTful APIs to the data management group, and articles presenting approaches for integrating data with specific apps or platforms to the data integration group.

    After categorizing the articles, we reviewed the key techniques used by each group to build their respective health care services. We compiled a general FHIR PG through this review. The workflow of the FHIR PG was derived by linking the stages, each consisting of multiple steps. It is important to note that alternative solutions might be identified for certain steps in the workflow based on different conditions. In addition, we leveraged the collective experience of our team working on health care IT projects to further refine and optimize the FHIR PG.

    Finally, as an example, we arbitrarily selected a use case outside the scope of the reviewed articles and mapped it back to the FHIR PG to demonstrate the effectiveness and generalizability of the PG.


    Article Classification

    Data Standardization

    Data standardization typically involves two main steps: (1) defining profiles based on the data exchange requirements of interoperable services and (2) filling these profiles with the corresponding exchange data.

    The base FHIR specification provides foundational resources applicable to various health care contexts. However, health care services often exhibit significant variability across different jurisdictions. Therefore, the base FHIR specification typically requires further adaptation, known as profile definition, to suit specific application contexts. Profile definition mainly encompasses three aspects: (1) rules about which resource elements to use and what additional elements to add to the base specification, (2) rules about which terminologies to use in particular elements, and (3) the restricted value range and cardinality of the elements.

    Table 1 lists the typical profile definitions and the corresponding FHIR foundational resources discussed in the reviewed articles. As shown, these articles cover a wide range of categories, including genomics [10-14], imaging [15-17], cancer [18-20], diabetes [21,22], COVID-19 [23,24], infections [25], electrocardiography [26], screening [27], and allergy [28].

    There are typically 2 approaches to filling the profiles with exchange data. One is redesigning the database to align with the FHIR resource structure, and the other is mapping data from an existing CDM-based legacy system to the FHIR-based system. Table 2 lists relevant articles discussing the latter approach. These articles could roughly fall into 7 groups based on the types of source CDMs. The groups include informatics for integrating biology and the bedside [29,30], Observational Medical Outcomes Partnership (OMOP) [31,32], OpenEHR [33,34], HL7 version 2 [35], variant call format [36], free text or arbitrary proprietary data [37,38], and multisource [39-42]. Multisource refers to cases where multiple CDMs are involved. For example, the study by Lenert et al [40] focused on transforming data from the OMOP and Patient-Centered Outcomes Research Network to FHIR. The study by Pfaff et al [39] aimed to transform data from informatics for integrating biology and the bedside, OMOP, and Patient-Centered Outcomes Research Network to FHIR. The study by Prud’hommeaux et al [41] compared 3 methods for transforming data from various source CDMs into FHIR. The study by Kiourtis et al [42] proposed a resource description framework transformation toolkit to combine FHIR and non-FHIR data.

    The studies in Table 2 indicate that the transformation from a specific CDM type to FHIR typically involves a 2-step mapping process: model mapping and element mapping. Model mapping establishes a relationship between the original data model and the FHIR resource. Element mapping comprises 2 parts, key mapping and value mapping, which define how to map the data fields from the source CDM to the corresponding fields in the FHIR resources. The mapping rules observe the consensus-mapping relationships established by domain experts. These experts analyzed the semantic and structural differences between the source CDMs and FHIR and determined the appropriate mappings to ensure accurate and meaningful data transformation. Although current data transformation approaches intend to support specific source data and target FHIR resource types, it is worth noting that ongoing research and advancements in domain-based applied artificial intelligence, including natural language processing and deep learning, hold great potential for developing more generalized data transformation algorithms.

    As highlighted in previous studies, the granularity of data plays a crucial role in data standardization. When the granularity of the source data is finer than that of the target data, there is potential for information loss during the transformation process: the severity of information loss increases with the extent of the granularity gap.

    Table 1. Profile definitions from the reviewed articles.
    Theme and study, yearInvolved Fast Healthcare Interoperability Resources
    Genomics

    		Murugan et al [10], 2021DiagnosticReport, Specimen, ServiceRequest, Observation, and Task

    		Seong et al [11], 2021MolecularSequence

    		Alterovitz et al [12], 2020DiagnosticReport, ServiceRequest, and Observation

    		Klopfenstein et al [13], 2021Questionnaire and Document

    		Khalifa et al [14], 2021Patient, PractitionerRole, Organization, Specimen, ServiceRequest, Media, RiskAssessment, Task, MedicationRequest, CarePlan, DeviceRequest, NutritionOrder, SupplyRequest, and RequestGroup
    Imaging

    		Kohli et al [15], 2018Patient, DiagnosticReport, ImagingStudy, AllergyIntolerance, Condition, MedicationOrder, Specimen, Organization, Practitioner, and Medication

    		Madrigal and Le [16], 2021Media

    		Boufahja et al [17], 2021Observation
    Cancer

    		Zong et al [18], 2021Observation and DiagnosticReport

    		Gonzalez-Castro et al [19], 2021Observation, Device, FamilyMemberHistory, AllergyIntolerance, Condition, Patient, MedicationStatement, Encounter, Questionnaire, QuestionnaireResponse, and Procedure

    		Zong et al [20], 2020QuestionnaireResponse
    Diabetes

    		Ludmann et al [21], 2020Observation

    		Glachs et al [22], 2020Procedure, ProcedureRequest, Communication, Appointment, Observation, Condition, CommunicationRequest, Device, Encounter, Composition, Goal, Order, OrderResponse, MedicationAdministration, MedicationOrder, Organization, Patient, Practitioner, RiskAssessment, QuestionnaireResponse, Basic, and Parameters
    COVID-19

    		Bauer et al [23], 2021Questionnaire

    		Sass et al [24], 2020Procedure, Observation, Condition, DiagnosticReport, Procedure, Consent, Immunization, MedicationStatement
    Infections

    		Shivers et al [25], 2021Consent, Coverage, DeviceUseStatement, Encounter, HealthcareService, Medication, MedicationAdministration, MedicationStatement, Observation, Patient, Practitioner, Procedure, ServiceRequest, and Specimen
    Electrocardiogram

    		Benhamida et al [26], 2020Observation
    Neonatal screening

    		Bathelt et al [27], 2020Patient, ServiceRequest, DiagnosticReport, Contract, Organization, and Practitioner
    Allergy

    		Lenivtceva and Kopanitsa [28], 2021AllergyIntolerance
    Table 2. Data migration from the existing clinical data model to Fast Healthcare Interoperability Resources.
    Study, yearClinical data model of the source
    Boussadi and Zapletal [29], 2017; Wagholikar et al [30], 2017Informatics for integrating biology and the bedside
    Jiang et al [31], 2017; Fischer et al [32], 2020Observational Medical Outcomes Partnership
    Ladas et al [33], 2022; Fette et al [34], 2020OpenEHR
    Xiao et al [35], 2021HL7a version 2
    Dolin et al [36], 2021Variant call format
    Peterson et al [37], 2020; Wang et al [38], 2020Free text or arbitrary proprietary
    Lenert et al [40], 2021; Pfaff et al [39], 2019; Prud’hommeaux et al [41], 2021; Kiourtis et al [42], 2020Multisource

    aHL7: Health Level 7.

    Data Management

    Data management includes data storage and data exposure. Although FHIR defines 5 approaches for data exposure, including RESTful API, messaging, documents, services, and persistent store, recent articles predominantly chose to expose data in the form of APIs because of the rapid growth of the APIs economy. There are typically 2 methods for data management: developing a customized FHIR warehouse to store and manage FHIR data or selecting a mature third-party warehouse to handle the task.

    Table 3 shows various data management choices and their corresponding targets. It reveals that developing a customized FHIR warehouse to maintain FHIR data often requires meeting some special service requirements. For instance, the customized FHIR warehouse developed by Demurjian et al [43] aimed to enable sensitivity and multilevel security controls. The one developed by Chatterjee et al [44] and Saripalle et al [45] served to integrate with specific terminology. The one developed by Ruminski et al [46], Saripalle [47], and Yu et al [48] intended to support multiple Internet of Things protocols. Finally, the one discussed in the studies by Khvastova et al [49], Dridi et al [50], Lee et al [51], Tanaka and Yamamoto [52], Cheng et al [53], Semenov et al [54], and Gruendner et al [55] was used to support data preprocess plug-ins.

    On the other hand, several mature third-party platforms are available for managing FHIR data. In 2018, a total of 6 technology giants, including Amazon, Microsoft, Google, IBM, Oracle, and Salesforce, jointly announced that they would be committed to removing the barriers to adopting health care interoperability technologies, particularly those enabled through the cloud [56]. All these companies have launched FHIR data management platforms, providing FHIR data APIs for resource operations. Users of these platforms can store their data as FHIR resources and use the data APIs offered by the cloud platform for service development. For instance, the studies by Shi et al [57], Zampognaro et al [58], Ploner and Prokosch [59], and Kamel and Nagy [60] chose cloud warehouses, and the study by Mandl et al [61] chose an on-premises warehouse to rapidly deploy an FHIR development environment.

    The abovementioned analysis highlights that choosing between proprietary and third-party warehouses involves trade-off considerations. Maintaining FHIR data through a proprietary warehouse offers 2 advantages: better privacy and greater flexibility for functional expansion. However, developing a proprietary warehouse requires extensive knowledge of FHIR standards and software development skills, resulting in higher costs. On the other hand, relying on third-party platforms offers the advantages of lower cost and higher implementation efficiency. However, storing sensitive data in a third-party warehouse, with the service provider not being the data owner, raises security and privacy concerns.

    Table 3. Fast Healthcare Interoperability Resources (FHIR) data management methods and their corresponding targets.
    Method and study, yearTarget
    Develop FHIR warehouse

    		Demurjian et al [43], 2020Support lattice-based access control

    		Chatterjee et al [44], 2022; Saripalle et al [45], 2020Integrate with specific terminologies

    		Ruminski et al [46], 2016; Saripalle [47], 2019; Yu et al [48], 2021Support multiple IoTa protocols

    		Khvastova et al [49], 2020; Dridi et al [50], 2020; Lee et al [51], 2020; Tanaka and Yamamoto [52], 2020; Cheng et al [53], 2021; Semenov et al [54], 2019; Gruendner et al [55], 2021Support data preprocess plug-ins
    Use third-party FHIR warehouse

    		Shi et al [57], 2021; Zampognaro et al [58], 2021
    Ploner and Prokosch [59], 2020; Kamel and Nagy [60], 2018    		Rapidly deploy a development environment through a cloud FHIR warehouse

    		Mandl et al [61], 2020Rapidly deploy a development environment through an on-premises FHIR warehouse

    aIoT: Internet of Things.

    Data Integration

    Data integration plays a vital role in health care across various domains, including service delivery, public health management, and clinical medicine or health care economics research, enabling better decision-making and improving overall health care outcomes. In service delivery, data integration is crucial for coordinating multiple IT systems, including the hospital information system (HIS), laboratory information system, picture archiving and communication system, EMR, and EHR. In public health, local governments need to collect health-related data within their jurisdictions to monitor regional health status and effectively address public health issues. In clinical medicine or health care economics research, it is essential to obtain data from diverse domains to conduct comprehensive studies and analyses.

    There are 2 typical modes of FHIR data integration, as listed in Table 4.

    The first mode of data integration is using an integrated service platform (ISPf). The ISPf is an orchestrating platform offering a series of API management functions such as API registration, API calling authorization, and API routing forward. Organizations wishing to exchange data through the ISPf must register their APIs on the platform. Other organizations can search for the appropriate APIs on the ISPf and make API calls. The ISPf performs API calling authorization to verify the calling rights and then routes the API calls to the respective organization to which the API belongs. This process facilitates data exchange among multiple organizations [62-75]. An example of this mode is the efficient transfer of medical records when a patient referral occurs.

    The second mode of data integration is by way of interoperable apps. Different architectures can be selected for different application scenarios. In the case of apps with specific functions, such as statistics and analysis, SMART on FHIR would be a more efficient option [76-85]. In the case of apps with customized functions, such as supporting microservice architecture or blockchain architecture, customized architecture apps would be a more suitable option [86-94].

    Table 4. Fast Healthcare Interoperability Resources data integration modes and their corresponding application scenarios.
    Interoperable modes and study, yearApplied scenarios
    Integrated service platform

    		Nan et al [62], 2021; Taechoyotin et al [63], 2021; Maxi and Morocho [64], 2022; Rosenau et al [65], 2022; Corici et al [66], 2020; Papaioannou et al [67], 2021; Hidayat and Hermanto [68], 2020; Sloane et al [69], 2021; Mukhiya and Lamo [70], 2021; Gruendner et al [71], 2022; Gruendner et al [72], 2020; Park et al [73], 2022; Ziminski et al [74], 2021; De et al [75], 2021Control exchange data through APIsa for service coordination among multiple organizations.
    App

    		Suraj et al [76], 2022; Michaels et al [77], 2021; Curran et al [78], 2020; Thayer et al [79], 2021; Karhade et al [80], 2021; Wesley et al [81], 2021; Burkhardt et al [82], 2021; Hoffman et al [83], 2017; Stoldt and Weber [84], 2020; Stoldt and Weber [85], 2021Substitutable Medical Applications and Reusable Technologies app: apps with specific functions, such as statistics and analysis.

    		Alamri et al [86], 2021; George and Chacko [87], 2022; Gulden et al [88], 2021; Chaves et al [89], 2021; Bae and Yi [90], 2022; Bettoni et al [91], 2021; Weber et al [92], 2020; Sfat et al [93], 2021; Mohammed et al [94], 2021Other architecture app: apps with customized functions, such as supporting microservice and blockchain architecture.

    aAPI: application programming interface.

    FHIR PG Design

    Practice Design

    We present an FHIR practice design in Figure 3, which defines the responsibilities of stakeholders and outlines the complete practice process from data to services.

    ‎
    Figure 3. The general Fast Healthcare Interoperability Resources (FHIR) practice guideline—practice design. API: application programming interface; IG: Implementation Guide; ISPf: integrated service platform.
    IGs Editing Group

    The first stakeholder involved in the process is the IGs editing group, usually coordinated by a government agency or an institution with significant influence in the ecosystem. The primary responsibility of this group is to define the data and service models and release the IGs. The detailed processes are as follows. First, select necessary FHIR resources based on the service requirements. Second, for specific requirements beyond the scope of the original FHIR resources, the group needs to customize resource structure by FHIR profile. Profile generally involves 3 aspects: extending the data field by FHIR extension, linking the local CodeSystem to the CodeableConcept field of FHIR resources, and restricting the cardinality and ValueSet of FHIR foundational resource. The customized resources created by the profile enable better alignment with the data requirements in various scenarios. After completing the data unification task, the IGs editing group moves on to the unification of services workflow, which involves specifying the implementation steps in the workflow and standardizing the corresponding APIs. Ultimately, the abovementioned data and workflow specifications are integrated to form the comprehensive FHIR IGs that health care IT system vendors can adopt.

    Health Care IT System Vendor

    The second type of stakeholder is the health care IT system vendor, responsible for developing and maintaining systems, such as the HIS, laboratory information system, and picture archiving and communication system. First, the vendor must implement the IGs published by the IGs editing group, which involves standardizing data by redesigning the database according to the FHIR resource structure or mapping data from existing CDM-based legacy systems to FHIR-based systems. Second, with RESTful APIs, the vendor has 2 options for data exposure: either maintaining the FHIR data and APIs themselves or selecting a mature third-party platform. FHIR APIs must be exposed to support resource-level operations regardless of the chosen option.

    It is worth pointing out that in terms of data exposure, FHIR defines 5 different approaches, and each data exposure approach has a different data integration method; it would be a lengthy discussion if all approaches are considered. To make FHIR PG more compatible with current technology stacks, we chose to focus on RESTful API rather than on other approaches in this study.

    Health Care Application Developer

    The third stakeholder involved in this process is the health care application developer, responsible for developing interoperable services using open FHIR APIs. As described in the Data Integration section, there are 2 typical modes. The first is to develop an ISPf, that is, an orchestrating platform, for service interoperability. The ISPf manages open APIs registered by each organization and enforces access specifications such as IGs, profiles, and workflows. Any IT systems accessing the ISPf and exchanging data must comply with these specifications. When an IT system needs to access multiple ISPfs, it must support multiple specifications. In such cases, the IT system can deploy an adapter above its native database to comply with various specifications. When the IT system acts as a producer, it reads the corresponding specifications from the adapter to expose the data. When it acts as a consumer, it reads the corresponding specifications from the adapter to parse data. The second mode is to develop specific apps that cater to specific requirements. For example, an app built with SMART on FHIR architecture supports a flexible and switchable application ecosystem.

    Beneficiary

    Beneficiaries such as hospitals, patients, public health institutions, and research institutions can benefit from high-quality FHIR-based health care services. For instance, if there is a need to exchange data through APIs to facilitate service coordination among multiple organizations, they can easily access the ISPf to fulfill this objective. Alternatively, they can choose a suitable app from the application gallery that caters to their needs and functions.

    The Development Architecture for the Practice Design
    Overview

    We presented a 3-stage development architecture for the practice design, as shown in Figure 4. In addition, we compiled a list of commonly used tools in Table 5 to support the development process.

    ‎
    Figure 4. The general Fast Healthcare Interoperability Resources (FHIR) practice guideline—the development architecture for the practice design. IG: Implementation Guide; ISPf: integrated service platform; SMART: Substitutable Medical Applications Reusable Technologies.
    Table 5. A list of commonly used tools.
    Tool and descriptionAvailability
    Data standardization

    		HAPIa FHIRbThis tool provides Java APIc for HL7d FHIR clients and servers[95]

    		IGe Auto-BuilderAn IG publishing tool that makes your IGs to be visible on the internet [96][97]

    		Firely ForgeThe official FHIR tool for managing FHIR profiles[98]

    		Firely TerminalA cross-platform command line tool with a range of commands for working with FHIR resources and installing and publishing FHIR packages[99]
    Data management

    		Firely FacadeA special type of plug-in that registers services to access the existing data repository. It speaks FHIR in the front-end and talks directly to native data in the back-end[100]

    		FHIR Works on AWSfA framework used to deploy an FHIR server on AWS[101]

    		FHIR server for AzureAn open-source implementation of FHIR specification designed for the Microsoft cloud[102]

    		GCPg Healthcare APIA cloud application that accelerates health care solution development with fully managed, enterprise-scale HL7 FHIR, HL7 version 2, and DICOMh APIs[103]

    		IBM FHIR serverAn open-source Java solution that supports the processing, validation, and storage of health care data according to the HL7 FHIR specification[104]

    		Oracle Healthcare Data RepositoryThe foundation of a health care information exchange platform that makes health care data more useful by supporting the integration and operation of a full spectrum of health care applications[105]

    		Health CloudA tool that combines clinical and nonclinical customer data to drive efficiencies in health[106]
    Data integration

    		Spring Cloud GatewayThis tool provides an API Gateway built on top of the Spring Ecosystem[107]

    		RedisThis tool provides access to mutable data structures via a set of commands sent using a server-client model with TCPi sockets and a simple protocol[108]

    		ValidatorThe HAPI FHIR Validator API is a simple RESTj API to validate the structure and content of an FHIR object[109]

    		ElasticsearchA distributed, RESTful search and analytics engine is at the heart of the Elastic Stack[110]

    		OpenIDAn open standard and decentralized authentication protocol promoted by the nonprofit OpenID Foundation[111]

    		OAuthAn open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications[112]

    		SMARTkDefine a workflow that an application can use to securely request access to data and then receive and use that data[113]

    aHAPI: Health Level 7 application programming interface.

    bFHIR: Fast Healthcare Interoperability Resources.

    cAPI: application programming interface.

    dHL7: Health Level 7.

    eIG: Implementation Guide.

    fAWS: Amazon Web Services.

    gGCP: Google Cloud Platform.

    hDICOM: Digital Imaging and Communications in Medicine.

    iTCP: transmission control protocol.

    jREST: representational state transfer.

    kSMART: Substitutable Medical Applications Reusable Technologies.

    Data Standardization

    In the data standardization development stage, several components are defined to ensure the consistent use of codes within a specific context. The terminology system comprises essential resources such as CodeSystem, ValueSet, and ConceptMaps. These resources establish a framework for determining which codes can be used. Furthermore, the conformance system includes resources such as StructureDefinition, OperationDefinition, CapabilityStatement, and ImplementationGuide. These resources are crucial in creating profiles and IGs that adhere to a specific exchange framework. As mentioned in the Data Standardization section, the granularity of the data plays a crucial role in information loss. Pfaff et al [39] pointed out that information loss can be avoided by defining custom values or extensions during the data standardization stage. By incorporating custom values or extensions defined in this stage, it is possible to capture and preserve the finer-grained information that is likely to be lost during the transformation process.

    During this process, developers can use various tools to facilitate efficient data standardization. The HL7 API (HAPI) FHIR offers a Java API for developing HL7 FHIR clients and servers. Forge serves as a management tool for FHIR profiles. The Firely Terminal, a cross-platform command line tool, provides a wide array of commands for working with FHIR resources and installing and publishing FHIR packages. IG Auto-Builder is another helpful tool that simplifies the creation and publication of IGs, available on the internet [96].

    Ultimately, the data standardization stage would generate a set of IGs to ensure consistency and conformity in implementing higher-level services.

    Data Management

    Various situations can arise in the data management development stage, each bringing different challenges. These situations can fall into 3 options.

    The first is to develop an FHIR-native warehouse that the health care IT system vendor manages. In this scenario, the vendor assumes responsibility for designing, implementing, and maintaining the warehouse.

    The second is to select a well-established third-party warehouse, such as FHIR Works on Amazon Web Services, IBM FHIR Server, Google Cloud Platform Healthcare API, FHIR Server for Azure, Health Cloud, and Oracle Healthcare Data Repository, to store and explore the FHIR APIs. This approach allows vendors to leverage the capabilities of mature third-party warehouses for FHIR API functionality.

    The third is to provide FHIR data using plug-ins. In this scenario, vendors retain their existing data infrastructure and use plug-ins to facilitate data transformation from its native format to the FHIR format. A tool called Facade is available to facilitate this mapping process.

    As discussed in the Data Standardization section, the discrepancy in granularity between different systems can lead to potential information loss. To mitigate this issue, developers can incorporate a mapping log within the transformer component. When encountering a granularity gap during the mapping process, the mapping log captures and records the lost information, associating it with the corresponding target resource ID. This mapping log serves as a reference for any subsequent services or systems requiring detailed information about the mapping process. If the overlying services need to retrieve the lost information, they can make a request based on the resource ID recorded in the mapping log. This measure allows them to access the details lost during the initial mapping, ensuring that the required information is preserved and available for further analysis or processing.

    Ultimately, the data management stage generates a series of FHIR APIs. These APIs serve as a foundation for data exploration and form the backbone of the infrastructure required for high-level services.

    Data Integration

    Two types of interoperable services are commonly used in the data integration development stage.

    The first type is the ISPf, which enables interoperability among multiple organizations. The ISPf comprises 4 key components: gateway, validator, flow control, and log system. The gateway, built by the Spring Cloud Gateway, is responsible for API authorization and forwarding API requests between organizations. The validator ensures that the structure and content of the API data comply with the FHIR object defined in IGs. The HAPI FHIR Validator can build this functionality. The flow control component is designed to limit the number of simultaneous API calls to ensure a stable operation. Redis can effectively fulfill the flow control requirements. As ISPf manages multiple organizations and facilitates data exchange, maintaining a comprehensive log system is crucial for history tracking and auditing. Elasticsearch, a powerful search and analytics engine, can be used to develop the log system within the ISPf, enabling efficient storage and retrieval of API call records.

    The second type of interoperable service is represented by apps built by the SMART on FHIR architecture [114]. This architecture consists of 3 key components: the resource server, authorization server, and the SMART on FHIR apps. The resource server is an access layer between the data management layer and the SMART on FHIR apps. The authorization server (an OpenID Connect–compliant web server) authenticates users and issues access tokens. SMART on FHIR apps is designed with specific functionalities and can be substituted based on user preferences.

    Use Case

    We arbitrarily selected a use case that was in addition to the reviewed articles. Portugal et al [115] designed a smart bed infrastructure with an HIS using FHIR. We mapped it back to the FHIR PG to demonstrate PG’s effectiveness and generalizability.

    In this case, the roles and responsibilities can be mapped to the FHIR PG–practice design. The authors and their research partners formed an IGs editing group to define IGs consisting of profiles and workflows. The profiles were derived from foundational FHIR resources such as Observation, Device, and ServiceRequest. The workflows defined the frequency at which the smart bed would collect vital signs from the smart bed. Subsequently, the authors’ team, acting as a health care IT system vendor, developed a gateway that gathers raw data from sensors and converts it into FHIR for transmission. Although they did not discuss the final applications in detail, it can be inferred that health care application developers can build a better smart bed monitor based on their infrastructure.

    The development architecture described in this paper can also be mapped back to the FHIR PG–development architecture. In the data standardization stage, the authors used the HAPI FHIR for HTTP processing, parsing and serialization, and FHIR REST semantics. It provided a bare-bones structure to build the API. In the data management stage, the authors developed a fog server as a gateway between the smart bed and HIS. This fog server is responsible for collecting raw data from the HIS, transforming it into the FHIR format, and facilitating its integration into the FHIR ecosystem. Finally, in the data integration stage, the authors enabled the HIS software to monitor patient procedures and flows, accompanied by the OAuth2 protocol for secure API communication.


    Principal Findings

    FHIR has shown significant advantages in facilitating interoperability among health IT systems compared with established international standards. However, there are challenges in large-scale implementation and promotion, particularly in different countries. First, countries without incentive policies to encourage FHIR research and implementation may exhibit less enthusiasm for adopting FHIR standards. Second, the lack of a suitable infrastructure to support the implementation process can result in high costs associated with FHIR adoption. Third, the foundational resources provided by FHIR may not directly align with the specific service requirements in different regions, necessitating additional customization processes.

    The following steps must be taken to address these challenges. First, it is crucial to have government policies that encourage the evolution and adoption of health care data standards. These policies can stimulate the enthusiasm and investment of stakeholders in the health care ecosystem to promote FHIR implementation on a larger scale. Second, strengthening the infrastructure helps reduce the cost and complexity associated with FHIR adoption, which includes developing services such as FHIR data storage, data standard quality control, and managed services for data operations. Third, FHIR profiles and workflows should be defined to address the specific requirements and characteristics of local health systems. By tailoring FHIR IGs to match the needs of different regions, the gap between FHIR foundational resources and specific service requirements can be bridged.

    FHIR holds significant potential in standardizing health care data and promoting service interoperability among health care institutions. Its adoption can drive the transformation of the health care service model and enhance the overall quality of health care services. With the growing recognition of the benefits of FHIR and its demonstrated impact on health care interoperability, more stakeholders are expected to actively participate in enriching its implementation. This collective effort would lead to the emergence of extensive health care service innovations, further enhancing the delivery of high-quality health care services.

    Limitations

    There are a few current limitations when applying the FHIR PG: (1) PG is derived from the waterfall model that follows a sequential and linear approach. Each step must be completed before proceeding to the next step. Therefore, it is time-consuming and costly to return and modify the previous steps if changes are necessary during the development process. (2) Although PG emphasizes the achievement of interoperability, it leaves out the security discussion. Developers must incorporate additional security mechanisms into PG–development architecture to ensure secure interoperation among multiple organizations.

    Conclusions

    Owing to the unique characteristics of FHIR, including comprehensive coverage of data definitions, substantial flexibility of data exchange, explicit semantics, and many available open-source tools, FHIR-based services have attracted strong interest from stakeholders in the health care ecosystem. Current studies reveal that many institutions, such as hospitals, regulators, and researchers, have already begun collaborations in actively building FHIR foundational frameworks or application use cases. After conducting the latest literature review, we proposed a general FHIR PG to bridge the gap between FHIR IGs and the practice of building usable services. This PG helps stakeholders identify their participant roles, manage the scope of responsibilities, and develop relevant modules, which we believe would effectively facilitate the application and promotion of HL7 FHIR standards across the health care ecosystem.

    Conflicts of Interest

    None declared.

    1. Gold M, McLaughlin C. Assessing HITECH implementation and lessons: 5 years later. Milbank Q. Sep 2016;94(3):654-687. [FREE Full text] [CrossRef] [Medline]
    2. Protti D. Integrated care, information management and information technology in Canada: have we made any progress in the past 12 years? Healthc Q. 2013;16(1):54-59. [Medline]
    3. Murata C, Yamada T, Chen CC, Ojima T, Hirai H, Kondo K. Barriers to health care among the elderly in Japan. Int J Environ Res Public Health. Apr 2010;7(4):1330-1341. [FREE Full text] [CrossRef] [Medline]
    4. Guiding opinions of the general office of the state council on promoting the construction and development of medical consortiums. China Government Network. 2017. URL: http://www.gov.cn/zhengce/content/2017-04/26/content_5189071.htm [accessed 2022-04-01]
    5. Notice on promoting the construction of a compact county-level medical and health community. National Health Commission of the People's Republic of China. May 28, 2019. URL: http://www.nhc.gov.cn/jws/s3580/201905/833cd709c8d346d79dcd7 74fe81f9d83.shtml [accessed 2022-04-01]
    6. World population ageing 2020 highlights. United Nations Department of Economic and Social Affairs. Oct 2020. URL: https:/​/www.​un.org/​development/​desa/​pd/​sites/​www.un.org.development.desa.pd/​files/​files/​documents/​2020/​Sep/​un_pop_2020 _pf_ageing_10_key_messages.​pdf [accessed 2022-04-01]
    7. FHIR®: it is time to shine for the interoperability standard. Enovacom. URL: https://www.enovacom.com/resource/fhir-it-is -time-to-shine-for-the-interoperability-standard [accessed 2022-04-01]
    8. Ayaz M, Pasha MF, Alzahrani MY, Budiarto R, Stiawan D. The Fast Health Interoperability Resources (FHIR) standard: systematic literature review of implementations, applications, challenges and opportunities. JMIR Med Inform. Jul 30, 2021;9(7):e21929. [FREE Full text] [CrossRef] [Medline]
    9. Lehne M, Luijten S, Vom Felde Genannt Imbusch P, Thun S. The use of FHIR in digital health - a review of the scientific literature. Stud Health Technol Inform. Sep 03, 2019;267:52-58. [CrossRef] [Medline]
    10. Murugan M, Babb LJ, Overby Taylor C, Rasmussen LV, Freimuth RR, Venner E, et al. Genomic considerations for FHIR®; eMERGE implementation lessons. J Biomed Inform. Jun 2021;118:103795. [FREE Full text] [CrossRef] [Medline]
    11. Seong D, Jung S, Bae S, Chung J, Son DS, Yi B. Fast Healthcare Interoperability Resources (FHIR)-based quality information exchange for clinical next-generation sequencing genomic testing: implementation study. J Med Internet Res. Apr 28, 2021;23(4):e26261. [FREE Full text] [CrossRef] [Medline]
    12. Alterovitz G, Heale B, Jones J, Kreda D, Lin F, Liu L, et al. FHIR Genomics: enabling standardization for precision medicine use cases. NPJ Genom Med. 2020;5:13. [FREE Full text] [CrossRef] [Medline]
    13. Klopfenstein SA, Vorisek CN, Shutsko A, Lehne M, Sass J, Löbe M, et al. Fast Healthcare Interoperability Resources (FHIR) in a FAIR metadata registry for COVID-19 research. Stud Health Technol Inform. Nov 18, 2021;287:73-77. [CrossRef] [Medline]
    14. Khalifa A, Mason CC, Garvin JH, Williams MS, Del Fiol G, Jackson BR, et al. Interoperable genetic lab test reports: mapping key data elements to HL7 FHIR specifications and professional reporting guidelines. J Am Med Inform Assoc. Nov 25, 2021;28(12):2617-2625. [FREE Full text] [CrossRef] [Medline]
    15. Kohli M, Morrison JJ, Wawira J, Morgan MB, Hostetter J, Genereaux B, et al. Creation and curation of the society of imaging informatics in medicine hackathon dataset. J Digit Imaging. Feb 20, 2018;31(1):9-12. [FREE Full text] [CrossRef] [Medline]
    16. Madrigal E, Le LP. Digital media archive for gross pathology images based on open-source tools and Fast Healthcare Interoperability Resources (FHIR). Mod Pathol. Sep 2021;34(9):1686-1695. [FREE Full text] [CrossRef] [Medline]
    17. Boufahja A, Nichols S, Pangon V. Custom FHIR resources definition of detailed radiation information for dose management systems. In: Proceedings of the 14th International Joint Conference on Biomedical Engineering Systems and Technologies - Volume 5: BIOSTEC. Presented at: BIOSTEC 2021; February 11-13, 2021, 2021; Virtual. [CrossRef]
    18. Zong N, Stone DJ, Sharma DK, Wen A, Wang C, Yu Y, et al. Modeling cancer clinical trials using HL7 FHIR to support downstream applications: a case study with colorectal cancer data. Int J Med Inform. Jan 2021;145:104308. [FREE Full text] [CrossRef] [Medline]
    19. González-Castro L, Cal-González VM, Del Fiol G, López-Nores M. CASIDE: a data model for interoperable cancer survivorship information based on FHIR. J Biomed Inform. Dec 2021;124:103953. [FREE Full text] [CrossRef] [Medline]
    20. Zong N, Wen A, Stone DJ, Sharma DK, Wang C, Yu Y, et al. Developing an FHIR-based computational pipeline for automatic population of case report forms for colorectal cancer clinical trials using electronic health records. JCO Clin Cancer Inform. Mar 05, 2020;4:201-209. [FREE Full text] [CrossRef] [Medline]
    21. Ludmann D, Pantazoglou E, Otten H. Standardized communication using FHIR and SNOMED CT in treatment of diabetic foot syndrome within the project iFoot. Stud Health Technol Inform. Jun 16, 2020;270:1395-1396. [CrossRef] [Medline]
    22. Glachs D, Namli T, Jung O, Strohmeier F, Ploessnig M, Rodriguez G. FHIR driven self-management support system for diabetes. Stud Health Technol Inform. Jun 16, 2020;270:1291-1292. [CrossRef] [Medline]
    23. Bauer DC, Metke-Jimenez A, Maurer-Stroh S, Tiruvayipati S, Wilson LO, Jain Y, et al. Interoperable medical data: the missing link for understanding COVID-19. Transbound Emerg Dis. Jul 29, 2021;68(4):1753-1760. [FREE Full text] [CrossRef] [Medline]
    24. Sass J, Bartschke A, Lehne M, Essenwanger A, Rinaldi E, Rudolph S, et al. The German Corona Consensus Dataset (GECCO): a standardized dataset for COVID-19 research in university medicine and beyond. BMC Med Inform Decis Mak. Dec 21, 2020;20(1):341. [FREE Full text] [CrossRef] [Medline]
    25. Shivers J, Amlung J, Ratanaprayul N, Rhodes B, Biondich P. Enhancing narrative clinical guidance with computer-readable artifacts: authoring FHIR implementation guides based on WHO recommendations. J Biomed Inform. Oct 2021;122:103891. [FREE Full text] [CrossRef] [Medline]
    26. Benhamida A, Kanas A, Vincze M, Papp KT, Abbassi M, Kozlovszky M. SaECG: a new FHIR Data format revision to enable continuous ECG storage and monitoring. In: Proceedings of the IEEE 20th International Symposium on Computational Intelligence and Informatics (CINTI). Presented at: IEEE 20th International Symposium on Computational Intelligence and Informatics (CINTI); November 05-07, 2020, 2020; Budapest, Hungary. [CrossRef]
    27. Bathelt F, Kümmel M, Helfer S, Kamann C, Sedlmayr M. Formal modelling of FHIR based, medical data exchange using algebraic petri nets. Stud Health Technol Inform. Jun 16, 2020;270:597-601. [CrossRef] [Medline]
    28. Lenivtceva ID, Kopanitsa G. The pipeline for standardizing Russian unstructured allergy anamnesis using FHIR allergyintolerance resource. Methods Inf Med. Sep 23, 2021;60(3-04):95-103. [CrossRef] [Medline]
    29. Boussadi A, Zapletal E. A Fast Healthcare Interoperability Resources (FHIR) layer implemented over i2b2. BMC Med Inform Decis Mak. Aug 14, 2017;17(1):120. [FREE Full text] [CrossRef] [Medline]
    30. Wagholikar KB, Mandel JC, Klann JG, Wattanasin N, Mendis M, Chute CG, et al. SMART-on-FHIR implemented over i2b2. J Am Med Inform Assoc. Mar 01, 2017;24(2):398-402. [FREE Full text] [CrossRef] [Medline]
    31. Jiang G, Kiefer RC, Sharma DK, Prud'hommeaux E, Solbrig HR. A consensus-based approach for harmonizing the OHDSI common data model with HL7 FHIR. Stud Health Technol Inform. 2017;245:887-891. [FREE Full text] [Medline]
    32. Fischer P, Stöhr MR, Gall H, Michel-Backofen A, Majeed RW. Data integration into OMOP CDM for heterogeneous clinical data collections via HL7 FHIR bundles and XSLT. Stud Health Technol Inform. Jun 16, 2020;270:138-142. [CrossRef] [Medline]
    33. Ladas N, Franz S, Haarbrandt B, Sommer KK, Kohler S, Ballout S, et al. openEHR-to-FHIR: converting openEHR compositions to Fast Healthcare Interoperability Resources (FHIR) for the German Corona Consensus Dataset (GECCO). Stud Health Technol Inform. Jan 14, 2022;289:485-486. [CrossRef] [Medline]
    34. Fette G, Ertl M, Störk S. Translating openEHR models to FHIR. Stud Health Technol Inform. Jun 16, 2020;270:1415-1416. [CrossRef] [Medline]
    35. Xiao D, Song C, Nakamura N, Nakayama M. Development of an application concerning fast healthcare interoperability resources based on standardized structured medical information exchange version 2 data. Comput Methods Programs Biomed. Sep 2021;208:106232. [FREE Full text] [CrossRef] [Medline]
    36. Dolin RH, Gothi SR, Boxwala A, Heale BS, Husami A, Jones J, et al. vcf2fhir: a utility to convert VCF files into HL7 FHIR format for genomics-EHR integration. BMC Bioinformatics. Mar 02, 2021;22(1):104. [FREE Full text] [CrossRef] [Medline]
    37. Peterson KJ, Jiang G, Liu H. A corpus-driven standardization framework for encoding clinical problems with HL7 FHIR. J Biomed Inform. Oct 2020;110:103541. [FREE Full text] [CrossRef] [Medline]
    38. Wang J, Mathews WC, Pham HA, Xu H, Zhang Y. Opioid2FHIR: a system for extracting FHIR-compatible opioid prescriptions from clinical text. In: Proceedings of the IEEE International Conference on Bioinformatics and Biomedicine (BIBM). Presented at: IEEE International Conference on Bioinformatics and Biomedicine (BIBM); December 16-19, 2020, 2020; Seoul, Korea (South). [CrossRef]
    39. Pfaff ER, Champion J, Bradford RL, Clark M, Xu H, Fecho K, et al. Fast Healthcare Interoperability Resources (FHIR) as a meta model to integrate common data models: development of a tool and quantitative validation study. JMIR Med Inform. Oct 16, 2019;7(4):e15199. [FREE Full text] [CrossRef] [Medline]
    40. Lenert LA, Ilatovskiy AV, Agnew J, Rudisill P, Jacobs J, Weatherston D, et al. Automated production of research data marts from a canonical fast healthcare interoperability resource data repository: applications to COVID-19 research. J Am Med Inform Assoc. Jul 30, 2021;28(8):1605-1611. [FREE Full text] [CrossRef] [Medline]
    41. Prud'hommeaux E, Collins J, Booth D, Peterson KJ, Solbrig HR, Jiang G. Development of a FHIR RDF data transformation and validation framework and its evaluation. J Biomed Inform. May 2021;117:103755. [FREE Full text] [CrossRef] [Medline]
    42. Kiourtis A, Mavrogiorgou A, Kyriazis D. A semantic similarity evaluation for healthcare ontologies matching to HL7 FHIR resources. Stud Health Technol Inform. Jun 16, 2020;270:13-17. [CrossRef] [Medline]
    43. Demurjian S, Agresta T, Sanzi E, DeStefano J. Alternative approaches for supporting Lattice-based Access Control (LBAC) in the Fast Healthcare Interoperability Resources (FHIR) standard. In: Proceedings of the 16th International Conference on Web Information Systems and Technologies (WEBIST 2020). Presented at: WEBIST 2020; November 3-5, 2020, 2020; Budapest, Hungary. URL: http://scitepress.org/Papers/2020/101508/101508.pdf [CrossRef]
    44. Chatterjee A, Pahari N, Prinz A. HL7 FHIR with SNOMED-CT to achieve semantic and structural interoperability in personal health data: a proof-of-concept study. Sensors (Basel). May 15, 2022;22(10):3756. [FREE Full text] [CrossRef] [Medline]
    45. Saripalle R, Sookhak M, Haghparast M. An interoperable UMLS terminology service using FHIR. Future Internet. Nov 16, 2020;12(11):199. [CrossRef]
    46. Ruminski J, Bujnowski A, Kocejko T, Andrushevich A, Biallas M, Kistler R. The data exchange between smart glasses and healthcare information systems using the HL7 FHIR standard. In: Proceedings of the 9th International Conference on Human System Interactions (HSI). Presented at: 9th International Conference on Human System Interactions (HSI); July 06-08, 2016, 2016; Portsmouth, UK. [CrossRef]
    47. Saripalle RK. Leveraging FHIR to integrate activity data with electronic health record. Health Technol. Apr 27, 2019;10:341-352. [CrossRef]
    48. Yu J, Kwon SH, Park S, Jun JA, Pyo CS. Design and implementation of real-time bio signals management system based on HL7 FHIR for healthcare services. In: Proceedings of the International Conference on Platform Technology and Service (PlatCon). Presented at: International Conference on Platform Technology and Service (PlatCon); August 23-25, 2021, 2021; Jeju, South Korea. [CrossRef]
    49. Khvastova M, Witt M, Essenwanger A, Sass J, Thun S, Krefting D. Towards interoperability in clinical research - enabling FHIR on the open-source research platform XNAT. J Med Syst. Jul 09, 2020;44(8):137. [FREE Full text] [CrossRef] [Medline]
    50. Dridi A, Sassi S, Chbeir R, Faiz S. A flexible semantic integration framework for fully-integrated EHR based on FHIR standard. In: Proceedings of the 12th International Conference on Agents and Artificial Intelligence (ICAART 2020). Presented at: ICAART 2020; February 22-24, 2020, 2020; Valletta, Malta. [CrossRef]
    51. Lee YL, Lee HA, Hsu CY, Kung HH, Chiu HW. Implement an international interoperable PHR by FHIR—a Taiwan innovative application. Sustainability. Dec 28, 2020;13(1):198. [CrossRef]
    52. Tanaka K, Yamamoto R. Implementation of a secured cross-institutional data collection infrastructure by applying HL7 FHIR on an existing distributed EMR storages. Stud Health Technol Inform. Jun 26, 2020;272:155-158. [CrossRef] [Medline]
    53. Cheng AC, Duda SN, Taylor R, Delacqua F, Lewis AA, Bosler T, et al. REDCap on FHIR: clinical data interoperability services. J Biomed Inform. Sep 2021;121:103871. [FREE Full text] [CrossRef] [Medline]
    54. Semenov I, Osenev R, Gerasimov S, Kopanitsa G, Denisov D, Andreychuk Y. Experience in developing an FHIR medical data management platform to provide clinical decision support. Int J Environ Res Public Health. Dec 20, 2019;17(1):73. [FREE Full text] [CrossRef] [Medline]
    55. Gruendner J, Gulden C, Kampf M, Mate S, Prokosch HU, Zierk J. A framework for criteria-based selection and processing of Fast Healthcare Interoperability Resources (FHIR) data for statistical analysis: design and implementation study. JMIR Med Inform. Apr 01, 2021;9(4):e25645. [FREE Full text] [CrossRef] [Medline]
    56. Cloud Healthcare Pledge. The Information Technology Industry Council. URL: https://www.itic.org/public-policy/Cloud HealthcarePledge.pdf [accessed 2022-04-01]
    57. Shi W, Giuste FO, Zhu Y, Carpenter AM, Iwinski HJ, Hilton C, et al. A FHIR-compliant application for multi-site and multi-modality pediatric scoliosis patient rehabilitation. In: Proceedings of the IEEE International Conference on Bioinformatics and Biomedicine (BIBM). Presented at: IEEE International Conference on Bioinformatics and Biomedicine (BIBM); December 09-12, 2021, 2021; Houston, TX. [CrossRef]
    58. Zampognaro P, Paragliola G, Falanga V. A FHIR based architecture of a multiprotocol IoT Home Gateway supporting dynamic plug of new devices within instrumented environments. In: Proceedings of the IEEE Symposium on Computers and Communications (ISCC). Presented at: IEEE Symposium on Computers and Communications (ISCC); September 05-08, 2021, 2021; Athens, Greece. [CrossRef]
    59. Ploner N, Prokosch HU. Integrating a secure and generic mobile app for patient reported outcome acquisition into an EHR infrastructure based on FHIR resources. Stud Health Technol Inform. Jun 16, 2020;270:991-995. [CrossRef] [Medline]
    60. Kamel PI, Nagy PG. Patient-centered radiology with FHIR: an introduction to the use of FHIR to offer radiology a clinically integrated platform. J Digit Imaging. Jun 3, 2018;31(3):327-333. [FREE Full text] [CrossRef] [Medline]
    61. Mandl KD, Gottlieb D, Mandel JC, Ignatov V, Sayeed R, Grieve G, et al. Push button population health: the SMART/HL7 FHIR bulk data access application programming interface. NPJ Digit Med. Nov 19, 2020;3(1):151. [FREE Full text] [CrossRef] [Medline]
    62. Nan J, Xu LQ, Wang Q, Bu C, Ma J, Qiao F. Enabling tiered and coordinated services in a health community of primary care facilities and county hospitals based on HL7 FHIR. In: Proceedings of the IEEE International Conference on Digital Health (ICDH). Presented at: IEEE International Conference on Digital Health (ICDH); September 05-10, 2021, 2021; Chicago, IL. [CrossRef]
    63. Taechoyotin P, Prasertsom P, Phanhong M, Wongsutthikoson P, Laohasurayodhin R, Pasuthip N, et al. Health link: scalable health information exchange platform in Thailand. In: Proceedings of the 2nd International Conference on Big Data Analytics and Practices (IBDAP). Presented at: IBDAP; August 26-27, 2021, 2021; Bangkok, Thailand. [CrossRef]
    64. Maxi K, Morocho V. Integrating medical information software using health level seven and FHIR: a case study. In: Narváez FR, Proaño J, Morillo P, Vallejo D, González Montoya D, Díaz GM, editors. Smart Technologies, Systems and Applications. Cham, Switzerland. Springer; 2022.
    65. Rosenau L, Majeed RW, Ingenerf J, Kiel A, Kroll B, Köhler T, et al. Generation of a Fast Healthcare Interoperability Resources (FHIR)-based ontology for federated feasibility queries in the context of COVID-19: feasibility study. JMIR Med Inform. Apr 27, 2022;10(4):e35789. [FREE Full text] [CrossRef] [Medline]
    66. Corici AA, Olaf R, Kraufmann B, Bilig A, Caumanns J, Deglmann M, et al. Interoperable and discrete eHealth data exchange between hospital and patient. In: Proceedings of the 23rd Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN). Presented at: 23rd Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN); February 24-27, 2020, 2020; Paris, France. [CrossRef]
    67. Papaioannou M, Neocleous A, Savva P, Miguel F, Panayides A, Antoniou Z, et al. A prototype of the national EHR system for Cyprus. Annu Int Conf IEEE Eng Med Biol Soc. Nov 2021;2021:2159-2162. [CrossRef] [Medline]
    68. Hidayat IF, Hermanto BR. A preliminary implementation of HL7 FHIR to achieve interoperability in Indonesia's local EHR. In: Proceedings of the 27th International Conference on Telecommunications (ICT). Presented at: 27th International Conference on Telecommunications (ICT); October 05-07, 2020, 2020; Bali, Indonesia. [CrossRef]
    69. Sloane EB, Cooper T, Silva R. MDIRA: IEEE, IHE, and FHIR clinical device and information technology interoperability standards, bridging home to hospital to “hospital-in-home”. In: Proceedings of the SoutheastCon 2021. Presented at: SoutheastCon 2021; March 10-13, 2021, 2021; Atlanta, GA. [CrossRef]
    70. Mukhiya SK, Lamo Y. An HL7 FHIR and GraphQL approach for interoperability between heterogeneous Electronic Health Record systems. Health Informatics J. Sep 15, 2021;27(3):14604582211043920. [FREE Full text] [CrossRef] [Medline]
    71. Gruendner J, Deppenwiese N, Folz M, Köhler T, Kroll B, Prokosch HU, et al. The architecture of a feasibility query portal for distributed COVID-19 Fast Healthcare Interoperability Resources (FHIR) patient data repositories: design and implementation study. JMIR Med Inform. May 25, 2022;10(5):e36709. [FREE Full text] [CrossRef] [Medline]
    72. Gruendner J, Wolf N, Tögel L, Haller F, Prokosch HU, Christoph J. Integrating Genomics and Clinical Data for Statistical Analysis by Using GEnome MINIng (GEMINI) and Fast Healthcare Interoperability Resources (FHIR): system design and implementation. J Med Internet Res. Oct 07, 2020;22(10):e19879. [FREE Full text] [CrossRef] [Medline]
    73. Park CH, You SC, Jeon H, Jeong CW, Choi JW, Park RW. Development and validation of the Radiology Common Data Model (R-CDM) for the international standardization of medical imaging data. Yonsei Med J. 2022;63(Suppl):S74. [CrossRef]
    74. Ziminski T, Demurjian S, Agresta T. Extending the Fast Healthcare Interoperability Resources (FHIR) with meta resources. In: Proceedings of the 16th International Conference on Software Technologies ICSOFT - Volume 1. Presented at: ICSOFT 2021; July 6-8, 2021, 2021; Online. [CrossRef]
    75. De A, Huang M, Feng T, Yue X, Yao L. Analyzing patient secure messages using a Fast Health Care Interoperability Resources (FIHR)-based data model: development and topic modeling study. J Med Internet Res. Jul 30, 2021;23(7):e26770. [FREE Full text] [CrossRef] [Medline]
    76. Suraj V, Del Vecchio Fitz C, Kleiman LB, Bhavnani SK, Jani C, Shah S, et al. SMART COVID navigator, a clinical decision support tool for COVID-19 treatment: design and development study. J Med Internet Res. Feb 18, 2022;24(2):e29279. [FREE Full text] [CrossRef] [Medline]
    77. Michaels M, Syed S, Lober WB. Blueprint for aligned data exchange for research and public health. J Am Med Inform Assoc. Nov 25, 2021;28(12):2702-2706. [FREE Full text] [CrossRef] [Medline]
    78. Curran RL, Kukhareva PV, Taft T, Weir CR, Reese TJ, Nanjo C, et al. Integrated displays to improve chronic disease management in ambulatory care: a SMART on FHIR application informed by mixed-methods user testing. J Am Med Inform Assoc. Aug 01, 2020;27(8):1225-1234. [FREE Full text] [CrossRef] [Medline]
    79. Thayer JG, Ferro DF, Miller JM, Karavite D, Grundmeier RW, Utidjian L, et al. Human-centered development of an electronic health record-embedded, interactive information visualization in the emergency department using fast healthcare interoperability resources. J Am Med Inform Assoc. Jul 14, 2021;28(7):1401-1410. [FREE Full text] [CrossRef] [Medline]
    80. Karhade AV, Schwab JH, Del Fiol G, Kawamoto K. SMART on FHIR in spine: integrating clinical prediction models into electronic health records for precision medicine at the point of care. Spine J. Oct 2021;21(10):1649-1651. [FREE Full text] [CrossRef] [Medline]
    81. Wesley DB, Blumenthal J, Shah S, Littlejohn RA, Pruitt Z, Dixit R, et al. A novel application of SMART on FHIR architecture for interoperable and scalable integration of patient-reported outcome data with electronic health records. J Am Med Inform Assoc. Sep 18, 2021;28(10):2220-2225. [FREE Full text] [CrossRef] [Medline]
    82. Burkhardt HA, Brandt PS, Lee JR, Karras SW, Bugni PF, Cvitkovic I, et al. StayHome: a FHIR-native mobile COVID-19 symptom tracker and public health reporting tool. Online J Public Health Inform. Mar 21, 2021;13(1):e2. [FREE Full text] [CrossRef] [Medline]
    83. Hoffman RA, Wu H, Venugopalan J, Braun P, Wang MD. Intelligent mortality reporting with FHIR. In: Proceedings of the IEEE EMBS International Conference on Biomedical & Health Informatics (BHI). Presented at: IEEE EMBS International Conference on Biomedical & Health Informatics (BHI); February 16-19, 2017, 2016; Orlando, FL. [CrossRef]
    84. Stoldt JP, Weber JH. Safety improvement for SMART on FHIR apps with data quality by contract. In: Proceedings of the IEEE International Conference on Software Architecture Companion (ICSA-C). Presented at: IEEE International Conference on Software Architecture Companion (ICSA-C); March 16-20, 2020, 2020; Salvador, Brazil. [CrossRef]
    85. Stoldt JP, Weber JH. Provenance-based trust model for assessing data quality during clinical decision making. In: Proceedings of the IEEE/ACM 3rd International Workshop on Software Engineering for Healthcare (SEH). Presented at: IEEE/ACM 3rd International Workshop on Software Engineering for Healthcare (SEH); June 3, 2021, 2021; Madrid, Spain. [CrossRef]
    86. Alamri B, Javed IT, Margaria T. A GDPR-compliant framework for IoT-based personal health records using blockchain. In: Proceedings of the 11th IFIP International Conference on New Technologies, Mobility and Security (NTMS). Presented at: 11th IFIP International Conference on New Technologies, Mobility and Security (NTMS); April 19-21, 2021, 2021; Paris, France. [CrossRef]
    87. George M, Chacko AM. A patient-centric interoperable, quorum-based healthcare system for sharing clinical data. In: Proceedings of the 2022 International Conference for Advancement in Technology (ICONAT). Presented at: 2022 International Conference for Advancement in Technology (ICONAT); January 21-22, 2022, 2022; Goa, India. [CrossRef]
    88. Gulden C, Blasini R, Nassirian A, Stein A, Altun FB, Kirchner M, et al. Prototypical clinical trial registry based on Fast Healthcare Interoperability Resources (FHIR): design and implementation study. JMIR Med Inform. Jan 12, 2021;9(1):e20470. [FREE Full text] [CrossRef] [Medline]
    89. Chaves A, Guimarães T, Duarte J, Peixoto H, Abelha A, Machado J. Development of FHIR based web applications for appointment management in healthcare. Proc Comput Sci. 2021;184:917-922. [CrossRef]
    90. Bae S, Yi BK. Development of eClaim system for private indemnity health insurance in South Korea: compatibility and interoperability. Health Informatics J. Jan 17, 2022;28(1):14604582211071019. [FREE Full text] [CrossRef] [Medline]
    91. Bettoni GN, Lobo TC, Flores CD, Gomes Tavares dos Santos B, da Silva FP. Application of HL7 FHIR in a microservice architecture for patient navigation on registration and appointments. In: Proceedings of the IEEE/ACM 3rd International Workshop on Software Engineering for Healthcare (SEH). Presented at: IEEE/ACM 3rd International Workshop on Software Engineering for Healthcare (SEH); June 03, 2021, 2021; Madrid, Spain. [CrossRef]
    92. Weber M, Griessbach A, Grossmann R, Blaser J. A FHIR-based eConsent app for the digital hospital. Stud Health Technol Inform. Jun 16, 2020;270:3-7. [CrossRef] [Medline]
    93. Sfat R, Marin I, Goga N, Popa R, Darla IC, Marian CV. Conceptualization of an intelligent HL7 application based on questionnaire generation and editing. In: Proceedings of the IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom). Presented at: IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom); May 24-28, 2021, 2021; Bucharest, Romania. [CrossRef]
    94. Mohammed S, Fiaidhi J, Sawyer D. Generating physician standing orders for unplanned care scenarios using the HL7 FHIR patient summaries. In: Proceedings of the International Conference on e-Health and Bioengineering (EHB). Presented at: International Conference on e-Health and Bioengineering (EHB); November 18-19, 2021, 2021; Iasi, Romania. [CrossRef]
    95. HAPI FHIR - Java API for HL7 FHIR. GitHub. URL: https://github.com/hapifhir/hapi-fhir [accessed 2023-08-01]
    96. Welcome to FHIR®. Health Level Seven International and Fast Healthcare Interoperability Resources. URL: https://build.fhir.org/ [accessed 2023-08-01]
    97. Implementation Guide builder. GitHub. URL: https://github.com/FHIR/auto-ig-builder [accessed 2023-08-01]
    98. Forge. SIMPLIFIER.NET. URL: https://simplifier.net/forge [accessed 2023-08-01]
    99. Firely terminal. SIMPLIFIER.NET. URL: https://simplifier.net/firely-terminal [accessed 2023-08-01]
    100. FirelyTeam. GitHub. URL: https://github.com/FirelyTeam/Vonk.Facade.Starter [accessed 2023-08-01]
    101. FHIR Works on AWS deployment. GitHub. URL: https://github.com/awslabs/fhir-works-on-aws-deployment [accessed 2023-08-01]
    102. FHIR server for Azure. GitHub. URL: https://github.com/microsoft/fhir-server [accessed 2023-08-01]
    103. Cloud healthcare API. Google Cloud. URL: https://cloud.google.com/healthcare-api [accessed 2023-08-01]
    104. IBM Watson Health is now Merative. IBM. URL: https://ibm.com/products/fhir-server [accessed 2023-08-01]
    105. Oracle Healthcare Data Repository homepage. Oracle. URL: https://www.oracle.com/healthcare/data-repository/ [accessed 2023-08-01]
    106. Health cloud. Salesforce. URL: https://www.salesforce.com/products/health-cloud/overview/ [accessed 2023-08-01]
    107. Spring cloud gateway. GitHub. URL: https://github.com/spring-cloud/spring-cloud-gateway [accessed 2023-08-01]
    108. Redis. GitHub. URL: https://github.com/redis/redis [accessed 2023-08-01]
    109. validator-wrapper. GitHub. URL: https:/github.com/hapifhir/org.hl7.fhir.validator-wrapper [accessed 2023-08-01]
    110. Elasticsearch. GitHub. URL: https://github.com/elastic/elasticsearch [accessed 2023-08-01]
    111. OpenID homepage. OpenID. URL: https://openid.net/ [accessed 2023-08-01]
    112. OAuth 2.0 homepage. OAuth 2.0. URL: https://oauth.net/ [accessed 2023-08-01]
    113. SMART on FHIR. GitHub. URL: https://github.com/smart-on-fhir [accessed 2023-08-01]
    114. Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc. Sep 2016;23(5):899-908. [FREE Full text] [CrossRef] [Medline]
    115. Portugal D, Faria JN, Domingues M, Gaspar L. Integration of a smart bed infrastructure with Hospital Information Systems using Fast Health Interoperability Resources: *a case study of the Wireless biOmonitoring stickers and smart bed architecture: toWards Untethered Patients (WoW) R and D Project. In: Proceedings of the IEEE 20th Consumer Communications & Networking Conference (CCNC). Presented at: IEEE 20th Consumer Communications & Networking Conference (CCNC); January 08-11, 2023, 2023; Las Vegas, NV. [CrossRef]

    ‎
    API: application programming interface
    CDA: Clinical Document Architecture
    CDM: clinical data model
    EHR: electronic health record
    EMR: electronic medical record
    FHIR: Fast Healthcare Interoperability Resources
    HAPI: Health Level 7 application programming interface
    HIS: hospital information system
    HL7: Health Level 7
    IG: Implementation Guide
    ISPf: integrated service platform
    OMOP: Observational Medical Outcomes Partnership
    PG: practice guideline
    SMART: Substitutable Medical Applications Reusable Technologies

    Edited by M Focsa; submitted 05.12.22; peer-reviewed by C Gulden, S Hume, H Kim, S Sarbadhikari, S Ahalt; comments to author 11.01.23; revised version received 07.04.23; accepted 10.07.23; published 21.08.23.

    Copyright

    ©Jingwen Nan, Li-Qun Xu. Originally published in JMIR Medical Informatics (https://medinform.jmir.org), 21.08.2023.

    This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on https://medinform.jmir.org/, as well as this copyright and license information must be included.