Data pipelines are chains of functions and activities that lead the input to the output in an attempt for the flow of data to be smooth and automated from source to destination [19]. Dynamic or pipeline-based data models deal with moving, transforming, and analyzing the data using the FHIR standard in their approach. In this category, the FHIR standard has been used as a canonical data model to develop dynamic models. This group encompasses the articles with processes that go beyond static representation and include the movement and transformation of data. Of the 31 articles included, 25 (81%) were related to the development of dynamic data models using the FHIR standard. Table 1 summarizes the extracted information about this category.

Static models do not follow a sequential or linear flow of data processing; instead, they capture and integrate data in broader aspects and mainly consider data mappings rather than the flow of data. These models are more likely to focus on capturing relationships between variables. They focus on the representation and organization of data within the FHIR standard without necessarily addressing the dynamic aspects of data flow or processing. Out of 31 included articles, 6 (19%) studies were related to the development of static data models. Table 2 summarizes the important information of the articles that presented these data models.

In this phase, we tried to maintain the medical domain consistency in summarizing the articles, and there may be some overlaps between the categories of each article’s health care domain. In the following sections, the included papers are summarized and ordered by specific medical use cases and health care applications.

A standard-driven methodology called Clinical Quality Language (CQL) 4NLP was developed to integrate a collection of NLP extensions represented in the HL7 FHIR standard, into the CQL to enhance EHR-driven phenotyping. Using the FHIR standard, specifically the FHIRPath system, enhanced metadata handling and querying by allowing the integration of NLP-derived metadata (such as hypotheticals and negation) into queries. The use case of this research was obesity comorbidities [20]. Another study in the obesity domain used a normalization pipeline to automatically analyze and understand the information in medical records. This FHIR-based approach could detect different sections of medical records and identify important concepts and states of obesity using discharge summaries. The methodology enhanced precise data extraction and portable EHR phenotyping [13]. A similar approach was followed to conduct a case study with obesity data sets. The objective was to predict this condition and the related comorbidities. The sample of adults was categorized into 2 groups called obesity and nonobesity considering their BMI. The design allowed the sharing of deidentified data because only higher-level concepts from knowledge bases and clinical ontologies were included in the FHIR components [35].

In another study, heterogeneous data from a pulmonary hypertension registry were integrated into the Observational Medical Outcomes Partnership–Common Data Model (OMOP CDM) data standard. Common parameters were first identified and mapped to Logical Observation Identifiers Names and Codes (LOINC) and Systemized Nomenclature of Medicine–Clinical Terms (SNOMED CT) as standard terminologies. Extracted data in the form of FHIR bundles were then transformed to OMOP CDM using the Extensible Stylesheet Language Transformations (XSLT). The researchers claimed that FHIR bundles and XSLT can be efficiently and simply used as components of an Extract, Transform, and Load (ETL) process, which can eventually increase data interoperability and applicability [22]. The goal of another research in this area was to map source variables and the value sets to FHIR data elements. The researchers developed a tool called Clinical Asset Mapping Program for FHIR to read Common Data Models (such as informatics for integrating biology and the bedside and Patient-Centered Outcomes Research Network data models) and map the items to FHIR. Using FHIR as a Common Data Model can enhance collaboration, interoperability, and data sharing among health care centers. The clinical use case in the mentioned study was “Asthma” [23].

OMOP-on-FHIR is a technology to convert data elements in OMOP CDM format to the FHIR standard. The researchers used this framework to implement 2 apps to facilitate cohort administration in the context of pediatric musculoskeletal disease research. Accordingly, FHIR can facilitate data access from OMOP CDM databases, support practical integration into health care systems, and enable the development of interoperable clinical applications [30]. For type 1 diabetes mellitus, research presented an ontology-based Clinical Decision Support System based on FHIR and Semantic Sensor Network-Based Type 1 Diabetes Ontology (FASTO). The researchers integrated the FHIR standard, clinical practice guidelines (CPGs), Basic Formal Ontology, and Semantic Sensor Network and implemented a cloud-based interoperable mobile health system for monitoring and managing patients with this condition. Broader adoption and seamless integration within existing EHRs can be achieved through using FHIR and ontology semantics [27]. A multimethod approach involving the development of a Minimum Data Set for cardiovascular computerized physician order entry was presented in another study. The researchers identified and classified critical data elements by reviewing the content of medical records and then mapped them to the FHIR standard. The FHIR standard was used to maintain interoperability between EHR and computerized physician order entry, which can eventually avoid duplicate data entries and redundancies [39].

In the context of COVID-19, clinical data across sites were federated by maintaining a single master patient identifier and consistent demographic information. In addition, this proposed methodology was used to distribute data across networks and maintain common data elements, such as mortality status and social determinants of health data. In the aforementioned approach, the data were loaded into an FHIR Clinical Data Repository, which finally produced real-time linked repositories, including FHIR, OMOP, and Patient-Centered Outcomes Research Network. The researchers found that using FHIR as the initial canonical data model and FHIR subscription protocols for transformation and synchronization of multiple data models has potential benefits for health care research, including the automated creation of research data marts for COVID-19 research [9]. An interoperable platform based on the FHIR standard was developed for convenient reporting and sharing of the polymerase chain reaction SARS-CoV-2 tests across countries. The aim was to create a Minimum Data Set for the tests, followed by modeling associated processes and end points. Implementation continued with standards and interoperability design, software development, testing, and implementation [32]. Another COVID-19–related tool called StayHome was developed for collecting patient-reported outcomes. This reusable mobile app was designed to collect COVID-19 symptoms and share them with health care organizations. The FHIR standard was used to ensure interoperability [33]. In another study on COVID-19, the automatic generation of research ontologies through a terminology server and FHIR profiles was analyzed. The researchers also investigated the process of translating user inputs into FHIR queries. On the basis of the results, it is possible to automatically generate mapping files and ontologies for FHIR-based data and profiles [24]. FHIR-based and evidence-based CPG recommendations for patients with COVID-19 were outlined in another approach. Iterative consensus-based mapping of model elements and links to FHIR correspondences along with modeling of recommendations were covered in the mentioned framework. According to the CPG-on-FHIR architecture, the generated guideline recommendations were represented using FHIR profiles. Using this FHIR-based architecture facilitates the creation of computerized guidelines and their seamless integration into EHR systems [42]. In the fields of family planning and sexually transmitted infections, the researchers structured data dictionaries to improve the mapping procedures to FHIR and multiple terminologies, such as the International Classification of Diseases 10th Revision. The corresponding FHIR resources and codes were then identified and mapped to each data dictionary term. The goal was to prepare inputs (mappings and data dictionaries) for an implementation guide (IG) generation tool and enhance the creation of machine-interpretable guidelines [40]. To clarify, FHIR IG is a collection of guidelines and rules designed to facilitate the adaptation of profiles to align with specific care contexts and promote the standardization of information exchange [44].

In the context of research in cancer clinical trials, FHIR-based pipelines can be used to automatically populate the case report forms (CRFs). The Electronic Data Capture framework was developed in a study to model colorectal cancer trials as a case study. With this strategy, real-world trials can be supported using EHR data [21]. Classification of cancer types and prediction of cancers from unknown primaries were the aims of another research in this field. In the mentioned study [25], genetic data elements (from the oncology reports of patients with cancer) and the associated phenotyping data (from an EHR) were extracted. Researchers presented a network-based infrastructure that modeled the EHR and genetic data with FHIR and Resource Description Framework (RDF) to enhance cancer prediction. In this respect, the performance of different machine learning and deep learning techniques was compared and analyzed [25]. In a paper related to colorectal cancer, data elements were extracted from the CRFs of cancer clinical trials using a data population application. The information was then mapped to an equivalent element in the FHIR cancer profile [28]. An interactive statistics and analysis platform called Shiny FHIR was implemented for ovarian cancer. The system included related R packages (R Foundation for Statistical Computing), FHIR resources, and Shiny (a web application framework). In the FHIR data modeling phase, the ovarian cancer data elements were mapped to corresponding FHIR resources. On the basis of the findings, Shiny can be used in parallel with FHIR to perform interactive analysis [29]. Another interoperable data model called Cancer Survivorship Interoperable Data Elements (CASIDE) was developed in the context of cancer survivorship. The researchers defined data elements and then mapped them to the corresponding FHIR resources. Patient information was illustrated by a collection of FHIR resources to enhance secondary use and sharing of medical data. The research declared the benefits of using FHIR-based models in conjunction with machine learning techniques. In addition, data entry tools can be seamlessly integrated with FHIR-based EHRs [10]. A harmonized data model was also developed in the context of cancer research based on FHIR. German cancer care providers are generally required to report patient data to cancer registries using a specific schema called ADT/GEKID. Therefore, in the mentioned research, the XML representation was compared to the extended version in the German Cancer Consortium (DKTK), and a codification of the cancer life cycle was created. The DKTK FHIR-based data model was represented, and the FHIR resources were identified. Other oncology FHIR profiling efforts were analyzed for reuse in DKTK. It was proved that multiple health care domains can be efficiently modeled using the FHIR standard and that using embedded mapping annotations, FHIR can be smoothly integrated with other standards [41]. The integration of genetic data from heterogeneous sources, including EHR data and genetic reports, was provided using another FHIR-based data model. The objective was to enable the validation of the Phenome-Wide Association Studies results across different institutions using the FHIR-based data profile. The researchers used the developed model to identify cancer genotype-phenotype associations, followed by validation of the associations according to a literature review [36].

The modeling capability of a data normalization pipeline (NLP2FHIR) was assessed in a study focusing on core clinical resources and unstructured EHR data. The researchers attempted to integrate the unstructured elements to develop an FHIR-based model that successfully standardized the annotated corpora [14]. Another framework was designed to integrate unstructured and structured data into an interoperable format by implementing an NLP-based pipeline using the FHIR-type system. On the basis of the results, the model facilitates the integration of NLP-driven EHR data into a standard FHIR format, supports diverse NLP tools, and provides strong extension capacities [12]. A framework presented in another research for standardizing heterogeneous annotation corpora included 2 main modules (automatic schema mapping module and expert-based annotation and verification module). The system used annotated clinical notes and proved that using FHIR with this kind of heterogeneous data can enhance data reuse as well as integration in medical NLP research [16]. A data model in the context of secure patient messages was developed based on FHIR concepts (related to base, foundation, clinical, and financial categories). The objective was to define significant information contained in these sources. After annotating the sentences and creating a huge corpus, the researchers extracted hidden topics related to 3 microconcepts (fatigue, patient visit, and prednisone as highly discussed topics) through topic modeling. The presented data model could distinguish critical concepts in messages and can be used to identify other narratives on multiple platforms [34].

In the field of intensive care, researchers aimed to convert the Medical Information Mart for Intensive Care (MIMIC)-IV database elements to FHIR. This database contains patient data from intensive care departments. To support the use of MIMIC-IV on FHIR, a resource demo and a FHIR IG were also created. The benefits of using the FHIR data model are claimed to be its extensive details, which facilitate mappings and conversions of data elements [26]. A FHIR Data Harmonization Pipeline was developed in another study based on an ETL framework. The harmonization of EHR data was performed in 5 phases, including querying the hospital database, mapping the retrieved data to the FHIR format, validating the mapping, transferring the FHIR resources to the patient model database, and exporting the data to the JSON format. Consequently, raw clinical records were transformed into AI-friendly and harmonized representations of data because the hierarchical structure of FHIR may not be sufficiently accessible and standard for AI frameworks. The data could then provide the fast and generic integration of cohort identification methods, facilitating big data processing [15]. In an application for the management of bilirubin in neonates, custom FHIR interfaces were included. After extensive intrainstitutional use, several strategies were explored to modify the app for cross-institutional transfer. Adapting the app for cross-institutional dissemination included clinician-specific implementation using custom FHIR application programming interfaces (APIs), gathering user feedback, differentiating functionality based on FHIR capabilities, implementing gradual replacement with native FHIR interfaces, and using the HL7 Quality Improvement and Clinical Knowledge (QUICK) logical data model for mapping to different FHIR versions and profiles [38]. The QUICK model encapsulates specific details of FHIR (eg, the differences between elements and extensions), enabling a more focused approach to the attributes and classes. This allows for the logical data model specifications to be identified with greater clarity [45]. Another research focused on knowledge graphs (KGs) and semantic modeling. In the mentioned research, the relational databases of the OMOP were used to develop the FHIR-Ontop-OMOP system. The aim was to generate virtual KGs from the databases. The generated KGs were evaluated for the accuracy of data transformation and compatibility with FHIR RDF using an intensive care data set (including medications, vital signs, observations, survival data, and so on). This semantic system could fully represent an OMOP database as an FHIR-compliant representation using KGs, thus enhancing the interoperability of OMOP CDM and FHIR [37].

A study aimed at implementing a maternal health record system with a data access model based on RESTful web services. In the proposed data model, important data elements were mapped to FHIR resources. Maintaining the related data as FHIR resources enhanced interoperability, efficient data exchange, and evidence-based decision-making [31]. Another article dealt with genetic laboratory tests. The researchers aimed to map the test elements to FHIR format based on an IG. FHIR clinical genomic IG is a beneficial and almost comprehensive tool for sharing genetic test results [43].

Concerning developing data models or infrastructures using the FHIR standard, several tools have been used in the reviewed research articles. This section summarizes the important or common tools and approaches. These items include FHIR-based tools and frameworks, machine learning approaches, and data storage and security.

Apart from the use of the NLP2FHIR pipeline discussed in the previous section, some other articles used simple NLP tools and algorithms to convert unstructured data into structured data elements adhering to a specific schema for better data description [21]. Hong et al [12] used Unstructured Information Management Architecture NLP tools such as MedXN and MedTime in the normalization phase to enhance interoperability. MedXN was used to extract medication extraction concepts, and MedTime was used to extract FHIR-defined temporal elements. Separate NLP extraction modules were developed to extract information directly from free text for those entities that cannot be extracted by current NLP tools. In a classification system developed by Hong et al [13], 4 machine learning algorithms, including support vector machine (SVM), random forest, logistic regression, and decision tree, were implemented to train the classifiers of the disease prediction module; the features that were used by the system were extracted from FHIR resources as well as terminology extensions. Among all methods, the random forest approach had the best performance. Zong et al [25] analyzed some deep learning and machine learning backbone models to compare the performance of cancer prediction. The bag of features (or bag of words) was used in their research based on the values of attributes in the FHIR model. A graph embedding method called Node2vec was used to learn the patient’s features (a vector). Generally, 3 methods of feature generation were compared, including the bag of features, Node2vec, and the bag of features combined with Node2vec. Moreover, 7 classification algorithms were analyzed and compared (random forest, logistic regression, naive Bayes, deep neural network, SVM, graph convolutional network [GCN], and convolutional neural network). Node2vec+bag of features and random forest classifier showed the best performance. To analyze the potential of integrating the unstructured FHIR data representations into deep learning methods, Liu et al [35] used Gated Recurrent Unit, CNN, Text GCN on NLP2FHIR inputs, and raw text. The results highlighted that the best performance was achieved by using the Text GCN classifier in NLP2FHIR input. Therefore, this combination can enhance interoperable EHR phenotyping.

In the data model presented by Zong et al [28], NLP tools were used to provide structured data for the ETL process from unstructured data (such as surgical reports). To cluster each patient in the patient subgrouping process, a model called Dirichlet Multinomial Mixture was used. In the Dirichlet Multinomial Mixture model, one document represents a single topic, which makes it suitable for clustering short texts. The genetic relationship extractor that was developed by Hong et al [16] used SVM as a learning model; the goal was to extract the “FamilyMemberHistory.relationship” FHIR element. Eventually, the NLP performance of the corpora was analyzed. On the basis of the results, an NLP engine can be developed on a pooled corpora that offers enough annotations to train a model. To learn the concealed topics of patient messages, De et al [34] used latent Dirichlet allocation, an unsupervised topic-learning model. It was claimed that latent Dirichlet allocation is effective in finding common topics with well-known terms but, at the same time, tends to overlook less frequent yet important topics in patient messages.

Several studies used PostgreSQL (also known as Postgres) as the database management system [15,26,30,33]. This system is an SQL-based open-source relational database management system that is compatible with JSON document storage. In the study of Williams et al [15], data storage was based on FHIR resource type, and each resource was mapped to a separate JSON structure. Bennett et al [26] used the MIMIC-IV database; the data contained in the data source was loaded into Postgres and the HAPI FHIR server. The data elements were then mapped to JSON within that system. The research indicated a substantial increase in storage requirements when data is converted to FHIR and further when inserted into HAPI FHIR. Specifically, the HAPI FHIR format required significantly more storage space compared to the basic relational structure. To store the “OMOP CDM database” generated by the Synthea synthetic patient generator, Marteau et al [30] used Postgres. The database was then modified to incorporate additional data needed for OMOP-on-FHIR. A PostgreSQL client application (psql) was subsequently used to interact with the database.

Burkhardt et al [33] also used this system along with the Apache web server in their proposed architecture. By contrast, Ismail et al [31] used MongoDB (NoSQL, or nonrelational data storage) for efficient data record manipulation processes. MongoDB can conveniently handle JSON structure, which is the format of the FHIR resources sent and received by servers. Using MongoDB provides a straightforward transformation of JSON objects into JSON documents, making storage and management more efficient. The database can handle FHIR resource searches based on specified criteria. This is facilitated by the MongoDB Data Access Object component that is responsible for validating the JSON strings received from clients.

Some researchers implemented OAuth for security purposes [27] and used Keycloak as an identity provider [33]. JSON Web Token was also used in other studies [32,33] to provide authentication services. This token securely shares information between end points by a JSON object.

Data model development can present many challenges and constraints arising from issues of data integration, interoperability, standardization, performance, scalability, generalizability, etc. In this section, we discuss the significant challenges and limitations identified in the reviewed papers, which researchers should take into account when developing FHIR-based data models and architectures. It is worth noting that there would be overlaps in the categorization of limitations and challenges.

It is the process of combining data from multiple sources and creating a unified data set. The initial stage of working on data analysis, reporting, and forecasting is data integration [69].

Regarding data integration, the problems mentioned in the analyzed papers include requiring some manual ETL processes [9], manual download of FHIR resources [12], reproducibility issues [20], maintaining robustness [9,20], using only 2 data sets and information loss [13], challenging content normalization [14], single CRF with limited data elements and inadequate questions [21], quality and completeness of the database documentation and nonautomatic concept recognition and considerable data preparation process [15], using incomplete synthetic database [30], no data curation during transformation, bias in database [26], storage space costs [26,33], maintaining inadequate aspects of data [27], synchronization issues and hard-coded mapping [22], privacy and confidentiality issues and limited corpora reuse [16], ignoring continuous changing of values over time [25], lack of comprehensive use of health care records due to lack of education and awareness [31], mapping rules based on only 2 use cases and not including information about generic data [10], manual FHIR mapping and reviewing data of only 1 setting [39], the requirement to implement a structured information model to an existing data dictionary [40], issues with ADT data set as a national reference (completeness and accuracy) [41], and no robust mapping [37].

Interoperability issues are related to the limitations in the seamless transfer and exchange of information between medical systems or applications [70].

Interoperability issues mentioned in the papers include reproducibility concerns [20], organizational interoperability issues [24], privacy and confidentiality issues [16], synchronization issues and hard-coded mapping [22], no evidence to attain a balance of functionality and portability and dissemination barriers due to development and integration costs [38], and extra mapping effort, which affects flexibility and adaptability of the framework [36].

It is a crucial step in transforming data into a uniform format to enable the shared use of advanced tools and techniques, large-scale analytics, and collaborative research [9,71]. Therefore, standardization issues are related to challenges in attaining standard and consistent data representation across different medical systems.

The issues that could be categorized into the data standardization challenges include difficult rule-changing in compiled java code for data transformation [9]; semantic gaps between NLP system’s data model and FHIR specification [14]; no adequate standardization [12]; mapping accuracy issues [15]; handling valid source system data with no match in FHIR [23]; SNOMED CT postcoordination limitations [24]; not mapping to the US Core as standard ontology, not mapping other databases linked to MIMIC-IV, and not covering some clinical modifiers and qualifiers by FHIR redefinitions [16]; SNOMED coverage restrictions [10]; manual FHIR mapping [39]; duplication of the mapping terms and the necessity to assess the need for a new FHIR profile versus continuing with the existing one [40]; LOINC codes for some observations (SNOMED could be used instead), no available code systems for many value sets, and lack of ubiquitous adoption of FHIR profiles due to the issues with SNOMED license [41]; requiring constant synchronization to the updates because the model was based on EBMonFHIR resources (have low maturity level and subject to changes) and impossibility of showing all guideline information in the FHIR resource format [42]; no textual structure due to lack of gold standard labels, not using syntax-based features for semantic representation, and elimination of some contextual information [35]; translation issues (from OMOP to preferred code systems of FHIR) [37].

Performance issues are related to obstacles in the efficient processing and retrieval of data that can compromise system performance, for example, the data are not processed within an acceptable response time [72].

According to the analyzed papers, performance issues include integration speed limitations due to transactional EHR [9], performance limitations [13], lack of sophisticated evaluation method [21], limited implementation assessment [30], performance validation issues and no validation for real questions [28], technical challenges [29], model’s limited functionality and lack of comprehensive specification [10], no evidence to attain a balance of functionality and portability [38], reduced response rate due to using a web-based questionnaire [39], no execution engine available for representation format [42], evaluation and validation [34], performance rate lower than others and low F₁-score [35], evaluation issues (one instance of MIMIC-III OMOP CDM, no rigorous evaluation) and no comprehensive assessment [43].

Scalability limitations can be considered as the data model’s weakness in handling increasing data volume or workload.

Generalizability problems are challenges in the applicability of the data model to other aspects or settings.

Considering the selected papers, scalability and generalizability limitations include few resources being used [15]; limited corpora reuse [16]; not enough compatibility and generalizability experiments [15]; not using a real environment [27]; possible bias when conducting a similar study and challenging generalizability for other types of a disease (in this case other cancers) [28]; restriction in the adaptability of the best-performing prediction model and requiring more complex methods to empower prediction and cover diversity [25]; the generalizability issues of the platform [32]; no broad adoption of the app due to issues related to resources and expertise, the best performance for specific programs [33]; few data models are used with no exhaustive evaluation [35]; low contribution to the medical field, failure to distinguish differences in genetic data, low resources for evaluation, and lack of comprehensive data modeling comparisons [36]; and not studying other test types and small sample size [43].