Semantic Integration of BPMN Models and FHIR Data to Enable Personalized Decision Support for Malignant Melanoma

Abstract

With digital patient data increasing due to new diagnostic methods and technology, showing the right data in the context of decision support at the point of care becomes an even greater challenge. Standard operating procedures (SOPs) modeled in BPMN (Business Process Model and Notation) contain evidence-based treatment guidance for all phases of a certain diagnosis, while physicians need the parts relevant to a specific patient at a specific point in the clinical process. Therefore, integration of patient data from electronic health records (EHRs) providing context to clinicians is needed, which is stored and communicated in HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources). To address this issue, we propose a method combining an integration of stored data into BPMN and a loss-free transformation from BPMN into FHIR, and vice versa. Based on that method, an identification of the next necessary decision point in a specific patient context is possible. We verified the method for treatment of malignant melanoma by using an extract of a formalized SOP document with predefined decision points and validated FHIR references with real EHR data. The patient data could be stored and integrated into the BPMN element ‘DataStoreReference’. Our loss-free transformation process therefore is the foundation for combining evidence-based knowledge from formalized clinical guidelines or SOPs and patient data from EHRs stored in FHIR. Processing the SOP with the available patient data can then lead to the next upcoming decision point, which will be displayed to the physician integrated with the corresponding data.

1. Introduction

Providing the right data at the right time during the patient treatment process helps improve and accelerate decision-making [1,2]. The significant influx of patient data due to digitization in general, but also new data-intensive methods and therapies, has made the selection of the right data and integration with evidence-based knowledge an even greater challenge. Thus far, the integration of patient data with clinical guidelines and standard operating procedures (SOPs) as a means to provide evidence-based knowledge has been limited in practice [3]. Furthermore, the use of patient data to determine the correct section within large guideline documents is essential to enhance usage supporting the right decision at the point of care. Physicians still in practice must work with text-based guidelines and SOPs alongside a vast amount of patient data to link both manually, a time-consuming and uncertain practice that calls for automation. To link digitized health data with digitally modeled clinical guideline knowledge represents a promising approach to bridging this gap and to unlocking new perspectives to move toward a data-driven and responsive healthcare system.

This proposed integration needs to be developed using existing standards to be reproducible. In the field of healthcare, a range of standards already exists, holding the potential to facilitate this convergence and finally support decision-making processes.

A widely adopted standard for process visualization and modeling is the intuitive graphical notation BPMN (Business Process Model and Notation) [4,5], initially developed by the Business Process Management Initiative (BPMI) and maintained by the Object Management Group (OMG). Due to its intuitive notation, BPMN is widely used for modeling clinical processes using Clinical Practice Guidelines [6,7]. A recent systematic review assessed the impact of BPMN on the healthcare sector, demonstrating its efficacy as a tool for standardizing and redesigning clinical processes [8].

For data exchange and the storage of healthcare information, a variety of standards, e.g., HL7 (Health Level Seven) version 2 (“v2”) and version 3 (“v3”) or openEHR, exist. The newest and widely adopted communication standard is HL7 FHIR (Fast Healthcare Interoperability Resources) [9], also motivated by different governmental initiatives for standardization. Thus, several consecutive projects have concentrated on the representation of clinical guidelines within the FHIR framework. For instance, the CPG-on-FHIR project [10,11] focuses on representation, the development of a FHIR implementation guide for machine-readable clinical practice guideline recommendations (see the Clinical Practice Guidelines (CPGs) on the EBMonFHIR project [10]), and the integration of clinical practice guidelines and data for decision support, as demonstrated by the CELIDA (COVID-19 Clinical Guidelines to Data Mapper) project [12]. Building upon these previous endeavors, the clinical decision support system GREvaluator (Guideline Recommendation Evaluator) [12,13] facilitates the verification of individual guideline adherence. Additionally, both standards have found applications in workflow orchestration or (partial) process automation, exemplified by tools such as [14,15,16], as well as in automated cohort size estimation for research purposes within HiGHmed [17,18,19,20,21,22], and by additional incorporation of Semantic Web technologies to improve decision support (see [23]).

To provide meaningful decision support at the point of care, both standards, BPMN and FHIR, are required. The need for a direct link between BPMN models and real patient data has previously been highlighted [24] as the only way to accurately identify a specific section or decision point within a formalized SOP or clinical guideline based on the data of a particular patient. Once identified, to support the physician, we need to integrate the available patient data for this decision point and present the missing but required data.

Over the past three years, significant efforts have been dedicated to harnessing the synergies of these two pivotal standards within the healthcare sector. To facilitate computer-interpretable representations of clinical-guideline-based knowledge, combined BPMN–FHIR modeling approaches have emerged [25,26]. Other works have focused on mapping approaches, encompassing mapping different ontologies to FHIR (see [27]) or mapping BPMN core elements to FHIR elements, as demonstrated in [28,29,30,31,32,33]. One approach addresses our problem statement by offering a mapping solution and bidirectional transformation between BPMN and FHIR [34]. Building upon this fundamental concept, we additionally enable simultaneous patient-specific FHIR data access during the transformation process.

In summary, we find significant ongoing research in the field of computer-interpretable guidelines, as well as in the mapping or transformation between BPMN and FHIR. However, combining this mapping with the integration of electronic health record (EHR) data is still unsolved. This work presents a model to prepare the identification and presentation of a specific decision point within an SOP based on the available patient data. Therefore, the SOP has been modeled in BPMN and the patient data are stored in FHIR. Based on this model, the algorithm can then traverse all decision points using the available patient data until a decision point is reached where no more data are available. Thus, the current position of the patient in the SOP according to the EHR data can be determined. In clinical practice, medical staff will then no longer have to spend time searching for patient data in hospital information systems to figure out the next treatment steps. Also, the quality of patient care might be improved by eliminating human errors and ensuring that tests already performed are not overlooked or repeated.

We needed to address the following challenges—to ensure loss-free TRANSFORMATION between BPMN and FHIR and incorporate the DATA STORAGE aspect into BPMN.

2. Materials and Methods

The BPMN standard is used for modeling processes in an intuitive way. It consists of semantically precise graphical symbols for tasks, gateways, events, and their various types. Each element represents an individual step in a process, contributing to the process flow. In BPMN, subprocesses serve as essential elements for grouping steps or restructuring complex processes.

FHIR basically consists of resources and APIs (Application Programming Interfaces). The resources are a collection of information models that define the data elements, constraints, and relationships for the “business objects” most relevant to healthcare. Therefore, they serve as the foundation for all interchangeable content. Each resource includes a standard definition and human-readable description of use. Additionally, every resource comes equipped with a set of common and resource-specific metadata, which ensures its use is clear and unambiguous. These resources can be further customized into profiles to align with the requirements of specific use cases. The APIs build a collection of well-defined interfaces for interoperating between two applications.

Our overall approach (Figure 1) starts with a data preprocessing step (DATA STORAGE) extending an existing BPMN model using FHIR patient data taken from the EHR. The EHRs are sourced from the Smart Hospital Information Platform (SHIP) [35], which consolidates patient data from diverse information systems, including Hospital Information Systems (HIS), Laboratory Information Systems (LIS), Radiology Information Systems (RIS), and Pathology Information Systems (PIS). This extended model is then further processed by a TRANSFORMATION process, mapping the different elements of the standards, and subsequently transforming between BPMN and FHIR.

To initiate the TRANSFORMATION process, we first validated the BPMN model to ensure the correct BPMN syntax. Based on the results, we conducted an analysis to determine the most suitable modeling approach for integrating patient-specific data during the DATA STORAGE phase by performing manual annotations on the model. The TRANSFORMATION process starts with the mapping of a total of 14 BPMN elements to FHIR fields, followed by the actual transformation. FHIR provides the ‘PlanDefinition’ (see [31]) resource, which is particularly valuable for defining clinical pathways and has already been utilized by researchers [16,33,34]. The resulting BPMN-to-FHIR transformed model underwent syntax validation using Postman. Subsequently, we performed the reverse transformation back into BPMN, comparing the input BPMN model with the BPMN model obtained from FHIR to ensure a loss-free transformation approach. For the transformation process, we employed two Camunda libraries (see [36]) to work with the BPMN elements in XML (Extensible Markup Language) format. For handling the FHIR data, we used the HAPI library [37], which is designed to make it easier to work with FHIR data, both for retrieving and storing healthcare information, and for building applications that use FHIR as their data format. It provides a set of tools and libraries for working with FHIR resources, making it a valuable resource for healthcare software development and interoperability in the medical field. To ensure proper access to patient data, we utilized FHIR Release 4, as Release 5 had not yet been implemented here. For the syntax check of the FHIR resources, we utilized the ‘validate’ method in Postman for the HAPI FHIR.

For DATA STORAGE, we then verified the FHIR resources associated with the defined decision points in the BPMN model against real EHR data from the University Medicine Essen (UME), ensuring the correct positioning of the data parameters within the JSON (Java Script Object Notation) structure. If necessary, we adjusted the FHIR resources and manually integrated them into the appropriate BPMN modeling elements. The Python package FHIR-PYrate [38] was used to query the FHIR data from the FHIR server and return it as structured data.

To verify our model, we chose malignant melanoma as the medical model and used an SOP transformed into a BPMN model from a previous study [25].

The data used for verification are anonymized patient data from SHIP, retrospectively obtained for research purposes. SHIP includes EHRs in FHIR in JSON data format containing 3429 melanoma patients (as of 23 October 2023), including 51 adjuvant-treated patients for the SLNE (sentinel lymph node excision) treatment section presented here, each based on ICD-10-GM (International Statistical Classification of Diseases and Related Health Problems, 10th revision, German Modification) code C43. We selected the patient cohort receiving adjuvant treatment from the Department of Dermatology, specifically gathering data required for the SLNE treatment step.

Additionally, we conducted syntax checks on the BPMN models before and after the transformation using bpmnlint [39], which validates the diagram against a defined set of rules and reports these as errors or warnings.

3. Results

3.1. Loss-Free Mapping as a Foundation for the TRANSFORMATION Approach between BPMN and FHIR

For the implementation of the BPMN elements, we adhered to the structure outlined in the BPMN 2.0 specifications [4]. To focus on incorporating patient data, our implementation of BPMN elements was limited to the Basic Control Flow Patterns [40,41], alongside data elements. These patterns encompass Sequence, Parallel Split, Synchronization, Exclusive Choice, and Simple Merge.

In the developed mapping (

Table 1. General table of all BPMN elements mapped to FHIR ‘PlanDefinition’ fields.

BPMN Elements	HL7 FHIR ‘PlanDefinition’
Flow Objects
Activities
Task	action
User Task	action.description=’userTask’
Service Task	action.description=’serviceTask’
Subprocess	The preceding BPMN element references the start element of the subprocess and all subsequent elements of the subprocess are subactions of it in FHIR. The end element of the subprocess references the subsequent BPMN element.
Events	action
Start	action which has no actions refers to it
End	action with no related action
Gateways	action
Parallel Gateway	action.selectionBehavior=’all’
Exclusive Gateway	action.selectionBehavior=’exactly-one’
Connecting Objects
Sequence Flow	action.relatedAction
Data Input Association,     Data Output Association	Not needed (Comment: These elements point to ‘DataStoreReference’, and because the ‘DataStoreReference’ in FHIR is directly included in action, no association is needed.)
Artifacts
Annotation	action.relatedArtifact
Data
DataStoreReference	action.input.requirement/ action.output.requirement
Name	DataRequirement.codeFilter.path
Value	DataRequirement.codeFilter.searchParam

), we utilized the FHIR resource ‘PlanDefinition’ as recommended by an OMG presentation [31] and the FHIR Clinical Practice Guidelines Implementation Guide (CPG IG) [42]. The BPMN elements listed in the table are categorized under flow objects, connecting objects, artifacts, and data, aligning with the ‘five basic element categories’ defined by the OMG (see [4], p. 27). Each BPMN element (Table 1, left column) was mapped to the corresponding field in the FHIR resource ‘PlanDefinition’ (Table 1, right column).

Based on this mapping, a transformation was implemented to convert BPMN models into FHIR code and back (see [43]). The transformation of all BPMN elements of the Basic Control Flow Pattern could be performed loss-free to FHIR and back to BPMN (see Section 3.3). During transformation, focus was on content information, such as BPMN elements, order, and name. Technical information such as the IDs of elements or the BPMN Diagram Interchange (BPMN DI), which contains information on the basic visual layout of BPMN diagrams, was not considered.

The mapping between the BPMN element ‘DataStoreReference’ and the FHIR resource ‘PlanDefinition’ is shown in

Table 2. Example BPMN element ‘DataStoreReference’ including patient data and the corresponding HL7 FHIR resource ‘PlanDefinition’.

BPMN

<serviceTask id=“Activity_1” name=“Extract tumor thickness”> <incoming>Flow_1</incoming> <outgoing>Flow_2</outgoing> <property id=“Property_1” name=“__targetRef_placeholder”/> <dataInputAssociation id=“DataInputAssociation_1”> <sourceRef>DataStoreRef_1</sourceRef> <targetRef>Property_1</targetRef> </dataInputAssociation> </serviceTask>   <dataStoreReference id=“DataStoreRef_1” name=“Tumor thickness”> <extensionElements> <properties> <property name=“fhir:Observation.where(code.coding. code=‘B1AAYPBTUDI’).valueQuantity.value” value=“2.9”/> </properties> </extensionElements> </dataStoreReference>

HL7 FHIR ‘PlanDefinition’

<action id=“Activity-1”> <title value=“Extract tumor thickness”></title> <description value=“serviceTask”></description> <input> <type value=“DataRequirement”></type> <mustSupport value=“Tumor thickness”></mustSupport> <codeFilter> <path value=“fhir:Observation.where(code.coding.code= ‘B1AAYPBTUDI’).valueQuantity.value”> </path> <searchParam value=“2.9”></searchParam> </codeFilter> </input> <relatedAction> <actionId value=“Gateway-1”></actionId> <relationship value=“before”></relationship> </relatedAction> </action>

.

The top row contains the BPMN element ‘DataStoreReference’ holding the patient data. Here, the task named ‘Extract tumor thickness’ is linked to the parameter ‘Tumor thickness’. The name of the property pertains to the FHIR resource for tumor thickness in the database. In our case, tumor thickness in SHIP is located under “fhir:Observation.where (code.coding.code=‘B1AAYPBTUDI’).valueQuantity.value” (Table 2).

To access patient information, we utilized FHIR Search to execute a query with the patient ID in the required resource of the database. The corresponding value of the patient’s tumor thickness is then inserted into the ‘Value’ field.

3.2. DATA STORAGE Aspect Realized in BPMN

To establish a reference to patient data, BPMN already offers options for accessing external data. These options include Data Objects, Data Inputs, Data Outputs, and Data Stores ([4], p. 28). We chose Data Stores in our case, as the patient data originate from an external database. According to OMG, a Data Store is defined as follows: “A DataStore provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process. The same DataStore can be visualized, through a Data Store Reference, in one or more places in the Process.” ([4], p. 208).

The ‘DataStoreReference’ elements can be used to incorporate generic or technical information using name-value pairs and can be extended with any number of property fields (Figure 2) and can thus be linked to all BPMN tasks relating to patient data. For each data field (e.g., tumor thickness, ulceration, tumor stage, patient age), a property is created in the corresponding ‘DataStoreReference’. These properties, in turn, consist of two fields: ‘Name’, and ‘Value’, where we specify the FHIR path (FHIR resource and field in the SHIP database) linking to the patient data from the ‘Name’ field. This mapping is performed manually by associating the relevant FHIR resources with the patient data to be reviewed at subsequent decision points (Figure 2 center, at the gateway ‘Which tumor thickness (TT) and risk factors are present?‘). The value is retrieved from the selected patient’s FHIR resource using the FHIR-PYrate package and written into the ‘Value’ field. This enables the incorporation of the context-sensitive FHIR patient data at the respective gateways.

3.3. Generic Transformation Algorithm to Enable Personalized Decision Support

This section describes the merging of our mapping approach with the DATA STORAGE aspect in order to provide a general algorithm in pseudocode for a loss-free BPMN-to-FHIR transformation with real EHR data.

In Figure 3, we present a pseudocode representation of our general BPMN-to-FHIR transformation process aiming to generate a FHIR resource ‘PlanDefinition’ out of a BPMN model. During the process, all BPMN elements are mapped to action fields of the ‘PlanDefinition’. Each transformation process starts with the provision of a BPMN input file and the initialization of an output file in XML format. Next, we use Camunda libraries [36] to parse all the BPMN elements into Java objects, creating a list of BPMN elements in Java. The transformation steps are different for three categories of requirements:

• BPMN elements with direct transformation: These elements, including tasks, events, gateways, as well as ‘DataStoreReferences’ existing at the top level (not within subprocesses), can directly be transformed into the corresponding FHIR fields (Figure 3, lines 3–5).
• BPMN elements requiring adjustments: This category contains elements like subprocesses, elements following gateways, as well as text annotations needing adjustments during transformation (Figure 3, lines 6–9).
• Mandatory FHIR requirements: Specific requirements outlined by the FHIR standard, including certain characters required for the FHIR server, unique IDs, and the mandatory field “fhir:PlanDefinition.status” (Figure 3, lines 10–12).

More specifically, after parsing, the algorithm performs as follows: First, the BPMN ‘DataStorageReference’ elements, including the EHR patient data, are mapped into “fhir:PlanDefinition.action.input.requirement” (Figure 3, line 3). During this phase, the patient data are then processed according to the mapping described in Table 1 with an example shown in Table 2. We then proceed to cache all end events from subprocesses to preserve their endpoints (Figure 3, line 4). This is crucial, as subprocesses cannot be translated directly into FHIR. Consequently, all elements within a subprocess are then set as subactions of the start event within the subprocess. Subsequently, all BPMN elements at the top level, excluding those within subprocesses, are converted into “fhir:PlanDefinition.action” and added to the Java objects (Figure 3, line 5).

To ensure consistency in the sequence of BPMN elements after reverse transformation, we set all actions directly following a gateway as subactions of the corresponding gateway (Figure 3, line 6). It is also essential to ensure that sequence flows from divergent gateways reference the correct next element, which is addressed in FHIR using the “fhir:PlanDefinition.action.condition” field (Figure 3, line 7). All converted elements, regardless of their modeling level, are merged (Figure 3, line 8). For BPMN elements with additional documentation in text annotations, we assign “fhir:PlanDefinition.relatedArtifact” (Figure 3, line 9).

The next phase involves adjustments mandated for FHIR servers. This encompasses character replacement for element IDs not permissible for FHIR servers (Figure 3, line 10), the removal of ID duplicates caused by the transformation of diverging gateways for actions, the storage of the ID of an action after a gateway in the URL field (Figure 3, line 11), and compliance with the mandatory FHIR criteria for setting “PlanDefinition.status” (Figure 3, line 12).

Finally, the created ‘PlanDefinition’ resource is validated and serialized into XML format (Figure 3, lines 13–14).

The pseudocode for the other direction—generating a BPMN model from a FHIR resource—is shown in Figure 4. The objective is to transform all information contained in a FHIR resource ‘PlanDefinition’, including FHIR patient data, into a BPMN model without any loss of data.

In general, the reverse FHIR-to-BPMN transformation is performed processing the following steps: provision of a FHIR input file and initialization of an output file in BPMN format, parsing (Figure 4, lines 1–2), readjustments due to mandatory requirements of the FHIR standard (Figure 4, lines 3–4), preprocessing of the BPMN top-level elements (Figure 4, lines 5–7), followed by the transformation into the individual BPMN elements (Figure 4, lines 9–12), handling subprocesses (Figure 4, lines 8,13), validation, and serialization.

In more detail, the reverse transformation from FHIR into BPMN starts with converting XML objects into Java objects. This step includes assigning IDs to actions lacking IDs in FHIR due to multiple actions sharing the same ID (Figure 4, line 3). This regulation has been addressed previously in the forward transformation (Figure 3, line 11). In addition, the characters from FHIR are substituted with acceptable ID characters (Figure 4, line 4), corresponding to the inversion of the forward transformation (Figure 3, line 10).

To identify the start and end events, the algorithm searches for fields in “PlanDefinition.action“ either with no actions referring to them (start events) or no related actions (end events). These events are then transformed into BPMN (Figure 4, lines 5–6). Subsequently, the basic structure of the subprocesses is created at the top level of BPMN modeling, along with their respective start and end events (Figure 4, lines 7). All subprocess information is cached, with the start event acting as the key element (Figure 4, line 8).

Iterating through all FHIR actions, the transformation into the BPMN elements for tasks and gateways is executed first (Figure 4, lines 9–10), followed by the merge gateways and sequence flows (Figure 4, lines 11–12). Subsequently, all created BPMN elements belonging to a subprocess are placed as child elements (Figure 4, line 13) to restore the lower modeling level created by the BPMN subprocesses. For all set BPMN elements allowing a link to a ‘DataStoreReference’ according to the specification, the FHIR fields action.input.requirement and action.output.requirement are checked to see whether values are available. If found, these values are extracted from the FHIR fields DataRequirement.codeFilter.path and DataRequirement.codeFilter.searchParam and inserted into the BPMN property extensions ‘Name’ and ‘Value’. The transformation concludes with validating the created file and serializing it into a BPMN file (Figure 4, lines 14–15).

As a final adjustment, we have supplemented our implemented FHIR-to-BPMN transformation algorithm with the functionality of data associations. Thus, the linking of ‘DataStorageReferences’ to the related BPMN elements are ensured in the terms of modeling.

To validate our presented approach, data from the 51 melanoma patients being treated in the adjuvant setting have been added into the BPMN model of the SLNE section of the SOP document. In the next step, data from the generated BPMN model have been transformed into FHIR and back into BPMN. All information of the BPMN elements—the order, names, as well as the retrieved patient data relevant to this SOP—could be preserved during the whole transformation process.

4. Discussion

With this work, we have demonstrated an approach to identifying a decision point by transforming a BPMN-formalized SOP into FHIR, including FHIR-based patient data. We verified the model using the formalized document ‘SOP Malignes Melanom’. For transformation, we considered all the BPMN-specific data inclusion options provided by OMG, as well as all the BPMN elements defined by OMG as Basic Control Flow Patterns. The FHIR resource ‘PlanDefinition’ has been chosen to rely on an already established standard for modeling clinical pathways. We showed that a loss-free transformation is possible and so created the prerequisites for the identification of decision points using the algorithm.

Despite this success, we also encountered a few limitations. As gateways are typically not represented as direct resources in FHIR, we were not able to directly map ‘merge gateways’ (two tasks pointing to one task after the gateway) in FHIR. Instead, the task preceding the gateway needs to reference all tasks following the gateway, along with additional information indicating whether it is a parallel or an exclusive gateway. If there is a case of two gateways being merged sequentially, the results are a loss of information regarding which gateway was merged first. To address this challenge, we created a subprocess that encompasses all elements from the diverging gateway to the ‘merge gateway’. The preceding element points to the start element of the subprocess, and the subsequent ‘merge gateway’ follows the end event of the subprocess. While this approach increases the size of the model due to the additional subprocesses, it only affects visual representation of the BPMN model. The FHIR code remains unchanged. We developed a different method from Helm et al. [34] to ensure that our models remained as compact as possible, enhancing the readability.

Another limitation is the loss of IDs of the BPMN elements. These exact IDs for sequence flows, Data Associations, and ‘DataStoreReferences’ are lost during transformation into FHIR, while new ones are generated during the transformation back into BPMN. These not identical IDs do not impact semantics or the transformation process in any way. To address the limitations of the technical information, additional fields of the FHIR resource ‘PlanDefinition’ could be selected in the future to map this information.

As we used ‘DataStoreReferences’, including Data Associations, to embed patient-specific data, some manual adjustments to visualizations in Camunda had to be made, because here the linkage between BPMN elements and ‘DataStoreReferences’ is achieved using Data Input Associations or Data Output Associations.

The generated BPMN models are intended for visual representation in medical contexts, specifically at the point of care. Our transformation approach establishes a framework for navigating to the appropriate section of the BPMN model based on the current patient-specific data, thus presenting only the currently relevant section to the physician. In real clinical settings, our mapping and transformation approach can be integrated into a medical dashboard. In Essen, dermatooncologists will, e.g., prepare tumor conferences with this tool, potentially saving time and enhancing quality.

5. Conclusions

Our transformation approach provides a mapping of BPMN models and FHIR with special emphasis on the semantic integration of patient-specific data, with the purpose of enabling patient-data-specific decision support at the point of care.

To embed patient-specific FHIR data into clinical pathways modeled using BPMN, we developed a method to transform BPMN elements into FHIR fields and vice versa. With an additional framework for navigating to the appropriate section of the BPMN model based on the current patient-specific data, only the currently relevant section can be presented to the physician. Furthermore, this approach offers the possibility to access patient FHIR data at certain decision points and to integrate it into BPMN data elements.

Moving forward, the next step could be to determine the position of a patient in the clinical pathway by a means of integrating patient-specific EHR data stored in FHIR into formalized clinical guidelines. This information can then be visualized for physicians using BPMN, providing a standardized method for clinical decision-making at the point of care.

Overall, our approach offers a promising method for integrating patient FHIR data into BPMN-modeled clinical pathways. Future studies should aim at validating the effectiveness of our approach in clinical practice and evaluating its impact on patient care at the point of care.