Machine Learning-Enhanced Architecture Model for Integrated and FHIR-Based Health Data

1. Introduction

In recent years, digital healthcare has witnessed an exponential growth in the volume and variety of clinical data generated from heterogeneous sources such as Health Information Systems (HISs), wearable devices, imaging systems, laboratories, and mobile applications. However, this abundance of information has not translated into effective clinical integration: data often remain fragmented, inaccessible, or non-interoperable across different platforms and institutions. In addition, missing or incomplete modalities are common, as not all patients undergo the same imaging protocols or complete every form, while clinical reports may vary in detail and structure. Furthermore, differences in data formats, annotation standards, and acquisition devices introduce additional complexity. Addressing these issues often requires advanced preprocessing pipelines, including data harmonization techniques, natural language processing tools to extract information from unstructured text, and robust imputation or domain adaptation strategies to manage incomplete or noisy data. These methods are essential to ensure that multimodal models achieve reliable performance across heterogeneous and real-world clinical datasets.

To address these issues, HL7 Fast Healthcare Interoperability Resources (FHIR) has emerged as a modern and modular standard designed to support interoperable health data exchange through well-known web technologies such as RESTful APIs, JSON, and XML. FHIR organizes clinical information into granular and reusable "resources" (e.g., Patient, Observation, Condition), enabling flexible integration among HISs, clinical systems, and computational models [1], including those based on Artificial Intelligence (AI). This scenario hinders the full potential of AI-based tools and Clinical Decision Support Systems (CDSS), which rely on structured, standardized, and semantically rich data to deliver reliable, reproducible, and personalized recommendations [2].

The use of standardized architectures like FHIR not only improves data sharing and quality but also promotes traceability, explainability, and regulatory compliance. Moreover, according to a recent systematic review, over 98% of CDSS tools developed between 2018 and 2021 adopted FHIR as the main interoperability standard [3].

The need for standardized architectures is also evident in companies like Empatica 1, which are developing AI-based wearable devices for continuous monitoring of conditions such as epilepsy and respiratory infections. Although FHIR is not explicitly used, its emphasis on interoperability, regulatory compliance, and real-time processing reflects the same structural need for a unified clinical architecture. For instance, the FHIR standard was tested to collect ECG data from wearable devices, enabling the transformation of a privately defined data format into a common data model [4].

In the medical field, AI-based CDSS and Computer-Aided Diagnosis (CAD) tools can be used to support clinicians in their daily diagnosis process, e.g., radiologists, by automating the detection and classification of lesions in diagnostic images. Indeed, systems like the Automated Breast Ultrasound System (ABUS) have shown advantages over handheld ultrasound images, improving lesion visualization and reducing operator dependency [5]. Furthermore, the adoption of FHIR to standardize diagnostic metadata and clinical information enables the development of interoperable, reusable, and scalable CDSS, thus accelerating knowledge transfer across diverse clinical environments [6].

To concretely demonstrate the impact of such standards, breast cancer serves as a representative case study. It remains one of the leading causes of cancer mortality among women worldwide, and early diagnosis is crucial for improving clinical outcomes. Ultrasound is frequently employed as a screening modality due to its accessibility and safety, but its interpretation is highly operator-dependent, making the diagnosis prone to variability [7].

Our research aims to enhance the integration of AI-based CDSS into clinical practice by adopting the interoperable HL7 FHIR standard. The case study of automated breast cancer diagnosis via ultrasound images highlights the potential of this architecture as a scalable and extensible model for other clinical domains. Finally, we propose a patient-centered mobile application, namely "InferCare", in order to show the potential of the proposed architecture.

2. Related Works

The growing adoption of the HL7 FHIR standard has stimulated a wide range of initiatives addressing different aspects of healthcare data management, from interoperability with legacy systems to AI-driven clinical applications and oncology-specific profiling. However, these contributions are often fragmented, each addressing a specific challenge, such as data exchange, integration of mobile health applications, or definition of oncology data elements, without providing a comprehensive framework that unifies anamnesis, structured data (e.g. diagnostic imaging, medical reports, ...), and intelligent decision support.

The use of the FHIR standard into HISs has favored the development of solutions aimed at professionals, enhancing data accessibility, quality, and interoperability.

Within the field of interoperability, one of the most influential initiatives is “SMART on FHIR” [8]. This approach proposes a modular framework that not only fosters interoperability, but also facilitates the secure integration of third-party applications into Health Information Systems (HISs), and in particular into Electronic Health Records (EHRs). Through semantically constrained FHIR profiles, OAuth2 2 authorization, and OpenID Connect 3 authentication, the platform SMART on FHIR enables the development of reusable clinical applications, easily integrated into healthcare professionals’ workflows. In this context, Drishti [9] extends the "Open mHealth" framework with a modular sense–plan–act architecture, designed to enable personalised behavioural interventions in mobile health (mHealth). It connects data collection, planning, and alert delivery modules via RESTful APIs and FHIR-compatible backends by integrating FHIR resources such as Observation and CarePlan. This supports seamless integration with clinical systems such as "OpenMRS" 4.

Open mHealth uses FHIR as the canonical format for data exchange and storage, promoting interoperability, reusability, and modular development across different mobile health applications. In this way, it is possible to collect and centralize heterogeneous data, both generated by mobile devices and coming from clinical workflows, similar to what happens for our proposed architecture, where the goal is to integrate and standardize heterogeneous patient information.

Beyond application layer frameworks such as SMART in FHIR and modular platforms such as Drishti, the "MDIRA" initiative [10] offers a vendor-neutral, standards-based reference architecture for clinical device interoperability. Using IEEE 11073 semantics, IHE profiles, and HL7 FHIR messaging, MDIRA enables the seamless and secure integration of medical devices in hospital, home, and hospital-in-home settings. MDIRA supports both peer-to-peer and ICE-style 5 peer-to-aggregator communications and facilitates the development of autonomous, reliable, and reusable systems for critical care delivery.

Complementing these approaches, an ECG stream analysis framework [11] demonstrates how FHIR can support AI-driven healthcare applications in a cloud native environment. Using the Google Cloud Healthcare API, it securely stores FHIR-encoded ECG data and processes it using tools such as Scikit-Learn and PyTorch, thereby bridging the gap between clinical data interoperability and advanced real-time analytics and personalized monitoring. In contrast, in our approach, we manage heterogeneous clinical data, including anamnesis, breast ultrasound images, vital signs sourced by medical devices, which are collected, elaborated with AI for support of phisician decison and structured as FHIR resources. In addition, he secondary use of health data for research purposes, as in our case, has been addressed in [12]. In the cited work, FHIR anonymization and pseudonymization methods allow healthcare institutions to transform identifiable FHIR resources, such as “Patient,” “Visit,” or “Observation”, into de-identified formats suitable for research or data analysis without compromising structural integrity or interoperability.

This enables secure and regulation-compliant reuse of data for purposes such as machine learning, clinical studies, and population health management, while preserving privacy and semantic consistency within FHIR-based infrastructures.

Several studies have explored how FHIR can support advanced clinical workflows. Major et al. [13] demonstrate how a FHIR back-end, integrated with the "Epic" system, which is one of the most widely used EHR systems in the world in hospital setting [14], allows real-time retrieval and analysis of clinical notes, medications, and vital signs to support AI-based models, enhancing timely clinical decision-making. Similarly to our approach, this demonstrates how FHIR-structured data can support decision-making processes across diverse clinical scenarios.

In the mobile environment, Lamprinakos et al. [15] present a FHIR-based health application , similar our, that facilitates interaction between clinicians, patients, and pharmacists. The system uses FHIR RESTful APIs to enable secure data access and personalized care plan management.

A more recent mobile architecture proposed by Pallis et al. [16] enables seamless access to electronic medical records (EMRs) from personal health apps by integrating legacy Cross-Enterprise Document Sharing (XDS) systems with modern FHIR-based EMRs. The mobile solution allows citizens to access and manage clinical information from multiple providers, combining the interoperability of FHIR with the document-centric approach of XDS.

Instead, in the field of precision medicine, the mCODE initiative [17] defines standardized FHIR profiles for oncology data, promoting reuse in both clinical systems and research. This model has been extended to international contexts [18], showcasing its adaptability to different healthcare systems. Similarly, the OSIRIS project [19] proposes a FHIR-compatible framework to enhance the sharing and analysis of clinical and genomic data in oncology.

Another emerging area is the use of FHIR in distributed cancer research, as seen in Oncology on FHIR [20]. This work proposes a modular FHIR-based data model to enable structured data exchange across institutions, using resources such as Condition, Observation, and Procedure.

To support the FHIR standard in defining precise instructions, Implementation Guides (IGs) are used. A noteworthy IG is the International Patient Summary (IPS) [21], which defines an interoperable structure for summarizing a patient’s clinical information, with the goal of supporting the exchange of essential health data. The IPS IG is designed to capture demographic, medical history, and clinical information, including elements such as medical conditions, allergies, ongoing treatments, and immunization history. This guide serves as a key reference for international interoperability and the standardization of patient history collection.

In the oncological field, there are several attempts at FHIR profiling by defining a series of IGs:

(1) mCode [22], an initiative of the American Society of Clinical Oncology (ASCO) in collaboration with the MITRE Corporation, aims to establish a core set of structured data elements for the EHR in oncology.

(2) Breast Cancer Data [23], a joint project of the Clinical Information Council (CIC) and the Clinical Information Modeling Initiative (CIMI), manages a dataset used for breast cancer staging.

(3) Breast Imaging Reporting [24], designed to capture, store, and communicate data derived from breast radiology examinations, supporting breast cancer screening, diagnosis, and treatment activities. It includes FHIR artifacts to represent findings obtained through various imaging modalities, such as ultrasound, Magnetic Resonance Imaging, and nuclear medicine.

(4) ICHOM Patient Centered Outcomes Measure Set for Breast Cancer [25], an IG based on the mCODE data model, proposing a structured set of patient-centered measures for breast cancer management. The IG includes scientifically validated questionnaires that explore specific aspects of the patient’s health experience. The responses to each item are quantified using a scoring system, allowing a standardized and comparable assessment of patient-reported outcomes.

Existing works provide significant but partial contributions: some focus on interoperability and integration with EHRs, others illustrate how FHIR can enable AI-driven clinical workflows, while others define oncology-specific profiles. However, none of them combine structured clinical anamnesis, imaging data, and AI modules within a single end-to-end architecture to support the entire care pathway.

Our work advances the state of the art by integrating these aspects into a complete system solution. It encompasses structured anamnesis and imaging data collection, formalization through FHIR-based Implementation Guides, automated machine learning modules for risk assessment, and a patient-centered mobile application (“InferCare”). Based on insights from the literature on FHIR-enabled AI systems for clinical decision support, our architecture is designed to ensure interoperability while supporting both clinicians and patients throughout the care pathway.

Specifically, the Android application developed within this architecture targets the breast cancer care pathway.

The case study, based on data from multiple patients, focuses on extracting and analyzing key morphological and color-related features in ultrasound images that characterize malignant tumors. By structuring heterogeneous clinical and imaging data in FHIR, our system enables AI modules to provide standardized, explainable, and scalable decision support. In this way, our contribution extends previous experiences by combining interoperability, multi-modal clinical data, and AI-driven analytics within a single, end-to-end framework tailored for oncology care.

3. Integrated Patient Decision Support System - Architecture and Methodology

This section defines the architecture of the Integrated Patient Decision Support System, namely “IPDSS”, a solution designed to centralise, integrate, and standardise heterogeneous patient information in order to provide effective decision support to healthcare professionals and facilitate integration with existing HISs. Figure 1 presents a comprehensive view of the proposed modular architecture.

The main objectives of the defined architecture are:

Data Aggregation and Collection: Aggregating information from different sources, such as: i) information collected (medical and family history) from interviews or through forms filled in by patients; ii) data derived from diagnostic image analysis systems and reports; iii) structured data obtained from HIS.

Data Standardization: Formalizing of all data (source, integrated, and processed) using the international HL7 FHIR standard to realize an interoperable solution.

Intuitive and fast visualization of interest information : Providing integrated information of interest for healthcare professionals through an easy-to-navigate and understand user interface. Only deemed useful information will be displayed for the specific diagnostic case.

Decision Support: Generating a concise summary of the patient’s health status based on the integrated data and the use of AI algorithms, to propose an AI-based risk assessment.

Data Integration: Being able to communicate with HISs (such as EHR or telemedicine systems) through the use of the HL7 FHIR standard.

In the following, we go into the details of the architecture’s description, with reference to functional requirements, data model, data flow, and Diagnostic Image Analysis Module.

3.1. Architecture

The proposed solution adopts a modular architecture, based on logically separated modules or components that communicate with each other.

In detail in Figure 1, the front-end components are contoured in blue, while the overlapped black boxes indicate the back-end modules of the architecture. The front-end modules include:

• Front-end Patient
  It allows the patient to independently collect a range of anamnestic information (possibly specific to the clinical condition). The module allows for the management of data obtained by a form presented to the patient for the collection of medical history and other relevant information (allergies, medication, family history, symptoms, etc.). This module also allows the patient to retrieve any information present in the system through interaction with the HL7 FHIR-HIS interface module.
• Diagnostic Image Analysis Module (DIAM)
  It performs processing and analysis of diagnostic images (e.g., detection, segmentation, classification, feature extraction) using Machine Learning algorithms or specific analysis tools. The aim of this module is to return an AI-based risk assessment.
• HL7 FHIR Formalization Module
  This module allows for formalizing, through international standard HL7 FHIR profiles, the data provided by the patient during the anamnesis phase (coming from the patient’s anamnesis form), and the results of image analysis (from the DIAM). This module uses the FHIR profiles and resources (e.g., Patient, Observation, Diagnostic Report, Allergy Intolerance, Medication Statement), which are appropriately defined to ensure compliance with FHIR standards. It manages the creation of FHIR resources and carries out validation for the aim of proposed architecture.
• Clinical Information of Interest Presentation Module (CIIPM)
  This module allows identifying and collecting all and only the clinical information of interest for a specific diagnosis. It thus enables the presentation of an integrated and intuitive view of the information: Personal data, structured medical history, and image analysis results.
• Health Status Summary Module
  It applies logical rules and algorithms to extract and analyze integrated data (history, image results, other available data), and generates a concise summary of the patient’s health status, highlighting key information, potential risks (AI-based risk assessment), and recommendations.
• HL7 FHIR-HIS Interface
  It enables the CIIPM to communicate with the existing platform (EHR) using the HL7 FHIR standard, and supports FHIR operations such as Create, Read, Update of Patient resources, Observation, Diagnostic Report, and other relevant ones.

3.1.1. Data Model

The data used in the architecture presented in the previous section are anamnestic data, i.e., a collection of information about the patients and their medical history, carried out by the physician to better understand the situation and make an accurate diagnosis. These data help the physician to identify possible diseases, risk factors, and family predispositions, which are essential for appropriate treatment. In addition to the medical history data, some data related to patient images are provided to the clinicians to support the diagnosis (Pathological Features). Moreover, other data features are also extracted from the images (Hand-crafted Features) that allow the computation of the AI-based risk assessment. Section 4 explains the process for the computation of AI-based risk assessment.

3.2. Architecture Modules Details

The following paragraph provides the flow of data within the proposed IPDSS architecture.

3.2.1. Front-End Patient

This module is designed to enable patients to autonomously provide a wide range of anamnestic information, which can be tailored to their specific clinical condition. Through an intuitive user interface, patients are presented with a customizable form where they can input relevant data regarding their personal and family medical history. This includes, but is not limited to, information about existing or past symptoms, current medications, known allergies, past diagnoses, and hereditary conditions.

The collected data are systematically managed and stored by the module, ensuring that healthcare professionals can access accurate and up-to-date patient information. Furthermore, the module is integrated with HIS/EHR, allowing patients to retrieve any relevant data already present in the system. This bidirectional communication ensures that both patient-provided information and existing clinical records are seamlessly synchronized, enhancing the completeness and reliability of the patient’s health profile.

3.2.2. Diagnostic Image Analysis Module (DIAM)

DIAM aims to provide two types of support to the healthcare professionals:

• Some specific features related to the pathology, namely Pathological Features (PF), are automatically extracted from the images, by using properly designed Computer Vision algorithms. These features are shown to the healthcare professionals and are useful to support the diagnosis.
• A risk assessment, computed by using suitably designed ML algorithms. For the computation of AI-based risk assessment, the ML methods use a set of features automatically extracted from ultrasound images, larger than PF, and called Hand-crafted Features (HF).

3.2.3. HL7 FHIR Formalization Module (HFFM)

HFFM transforms clinical and contextual data collected by the user into resources that comply with the HL7 FHIR standard. Specifically, the module processes two main categories of information:

• Anamnestic data: information provided directly by the patient through the Front-end Patient module. This includes, for example, self-reported symptom medical conditions, self-reported symptoms, etc..
• Clinical information derived from diagnostic images: includes results obtained through the automated analysis of diagnostic images (e.g., ultrasound images) by the DIAM. This information is then translated into formalized clinical observations according to the HL7 FHIR standard.

Based on this information and referring to the work presented in [26], the profiles, value sets, and system codes for a test IG, were defined [27,28]. The Implementation Guide defined in [28] is available to support the structuring of the information used by the proposed solution. Furthermore, the IG enables the automatic validation of the data employed by the solution against the HL7 FHIR standard.

3.2.4. Clinical Information of Interest Presentation Module (CIIPM)

This module is responsible for identifying and aggregating all the clinical information that is specifically relevant to a given diagnosis, based on the patient’s current clinical condition and medical history. Its goal is to filter out non-essential data and focus only on what is diagnostically significant, thereby reducing information overload for healthcare professionals.

The module presents this curated information through an integrated and user-friendly interface. It combines various data sources, including personal and demographic information, structured and categorized medical history, and the results obtained from medical image analysis, into a coherent and accessible overview. This facilitates faster and more informed clinical decision-making by providing a comprehensive yet focused snapshot of the patient’s health status.

3.2.5. Health Status Summary Module

This module performs a synthesis of the patient’s overall health condition by applying predefined logical rules and advanced algorithms to the available integrated data (diagnostic image analysis results, and any other clinically relevant data available in the system).

Based on this analysis, the module generates a clear and concise summary of the patient’s health status. It highlights key clinical findings, flags potential health risks through AI-based risk assessment models, and provides actionable recommendations when appropriate. This summary is designed to support healthcare providers by offering a quick yet comprehensive overview, aiding in both diagnosis and treatment planning.

3.2.6. HL7 FHIR - HIS Interface

This module facilitates seamless communication between the CIIPM and the existing HIS, such as the EHR platform. It leverages the HL7 FHIR standard, which is widely adopted for the secure and efficient exchange of healthcare data.

The interface supports a range of core FHIR operations, including the creation, retrieval, and updating of key healthcare resources such as Patient, Observation, DiagnosticReport, and other relevant resource types. By implementing these operations, the module ensures interoperability with other systems and enables real-time synchronization and sharing of clinical information across the healthcare infrastructure. This interoperability enhances the consistency, accuracy, and accessibility of patient data throughout the clinical workflow.

4. Case Study

This work proposes a case study related to the clinical condition of breast cancer. In the following section, we describe the modules, DIAM and HFFM, that need to be customized in relation to the selected case study.

4.1. DIAM

Dataset description

In this work, the Breast Ultrasound Images Dataset 6 (BUSI) has been used for the evaluation of the classification of ultrasound images. The dataset includes 780 breast ultrasound images of women aged between 25 and 75 years old. 210 images contain malignant lesions, 437 have been annotated as benign breast cancer, and 133 are normal breast cancer images. Only malignant and benign cases are included in this study. In detail, for each ultrasound image, a ground truth with the annotated lesion is associated.

As an example, Figure 2 illustrates two breast ultrasound images: one showing a malignant lesion and the other a benign one. In both cases, the lesions were contoured in red by the expert radiologists, which allowed us to extract the key morphological and color-related features directly in that annotated portion and use them for the classification process.

AI-based Risk assessment calculation

For the selected case study, the DIAM provides the PF set, reported in the Table 1. These features are among the most used by radiologists to provide a diagnosis of breast cancer [29]. So, we show them to the clinician to support the diagnostic decision process.

For the AI-based risk assessment, a classification of the lesion as benign or malignant is proposed. For the classification purpose, the HF set, composed of morphological and color-related features, reported in the Table 2, is extracted from the annotated lesions.

A feature selection step has been applied in order to assess the HFs that are more important for the classification. Recursive Feature Elimination (RFE) using Logistic Regression (LR) results in being the best method for the feature selection phase [30]. Subsequent to the feature selection phase, a classification pipeline was performed with the objective of assessing the predictive capabilities of various ML algorithms. Specifically, four well-established classifiers were considered: Decision Tree (DT) [31], Multi-Layer Perceptron (MLP) [32], Naive Bayes (NB) [33], Random Forest (RF) [34].

In order to mitigate the issue of class imbalance inherent in the dataset, the Synthetic Minority Oversampling Technique (SMOTE) [35] was applied. Unlike traditional random oversampling methods, which tend to increase the risk of overfitting by merely duplicating existing minority class instances, SMOTE addresses the imbalance by synthetically generating new samples. This is achieved through interpolation between existing minority class samples that are in close proximity within the feature space. Such an approach fosters a more balanced class distribution and enhances the generalization ability of the trained models. For each image, the predicted class is the one associated with the highest probability score assigned by the ML algorithm. The risk assessment proposed to the clinician will consist of the predicted class (benign or malignant) and the associated probability for that class.

Results The obtained results highlight the importance of carefully selecting discriminative handcrafted features for breast lesion classification from ultrasound images. The use of RFE proved particularly effective in identifying the most informative subset of features, suggesting that not all morphological descriptors contribute equally to the discrimination task. The fact that only three features—perimeter regularity, axis ratio, and solidity—were sufficient to achieve high performance indicates that these characteristics capture complementary aspects of lesion morphology that are highly relevant for distinguishing benign from malignant patterns. This is also consistent with radiological practice, where border irregularity, asymmetry, and spiculation are well-established hallmarks of malignancy.

Among the classifiers, MLP outperformed the others, achieving almost perfect discrimination with an accuracy close to 98% and a F1-score of 97%. This reinforces the idea that neural networks, even in relatively simple architectures, are well-suited to model nonlinear feature interactions. While perimeter regularity or solidity alone can already provide meaningful information, their joint contribution, along with axis ratio, can be more effectively exploited by MLP compared to other models. In contrast, NB, constrained by its independence assumption, showed limitations in handling such interactions, which likely explains its relatively lower recall.

Decision Trees (DT) performed adequately but were more affected by dataset size and potential noise. This behavior is expected, as DTs are prone to overfitting when trained on small datasets and may fail to generalize well. RF, on the other hand, mitigated some of these issues by averaging multiple decision trees, which resulted in solid performance (97.2% accuracy and 96.8% F1-score). However, RF still did not surpass MLP, suggesting that ensembles of shallow learners might not capture subtle, higher-order nonlinear relationships as effectively as neural networks.

Overall, these findings suggest that the careful combination of feature selection and the use of flexible learning models such as MLP can yield highly accurate breast cancer classification systems, even when relying solely on handcrafted features rather than deep representations. This is a particularly relevant result for settings where computational resources are limited or where large annotated datasets required for deep learning are not available. At the same time, the high performance obtained with a small feature set also improves interpretability, since the decision-making process can be directly related to clinically meaningful morphological descriptors.

Table 3. Results of the different ML algorithms used with the three key features. In bold, the best results for each measure.

	Accuracy	Precision	Recall	F1-score
DT	$0.9440$	$0.9333$	$0.9439$	$0.9377$
MLP	0.9767	0.9746	0.9729	0.9736
NB	$0.9488$	$0.9596$	$0.9254$	$0.9397$
RF	$0.9720$	$0.9690$	$0.9683$	$0.9684$

Table 3. Results of the different ML algorithms used with the three key features. In bold, the best results for each measure.

	Accuracy	Precision	Recall	F1-score
DT	$0.9440$	$0.9333$	$0.9439$	$0.9377$
MLP	0.9767	0.9746	0.9729	0.9736
NB	$0.9488$	$0.9596$	$0.9254$	$0.9397$
RF	$0.9720$	$0.9690$	$0.9683$	$0.9684$

4.2. HFFM

This section presents FHIR profiles developed to ensure the structured and interoperable representation of clinical and anamnestic information collected through an IG. Derived from the adaptation of international FHIR resources to the project context, these profiles cover several areas ranging from patient history to oncology risk analysis. In Table 4 a summary of single profile of IG are reported.

Figure 3. Overview of the Information Model and Profiled FHIR Resources

Figure 3. Overview of the Information Model and Profiled FHIR Resources

5. “InferCare” Android Application

To facilitate interaction with the IPDSS system by both patients and physicians, the “InferCare” mobile app was developed. The app’s name is derived from the combination of “Inference” (referring to AI inference) and “Care” (patient care). This section explains the interface and main features of the app, which allow guided completion of the medical history form, display of structured information, and support of diagnosis through summary views for physicians.

5.1. IPDSS Functional Requirements

The section specifies the Functional Requirements (FR) of the IPDSS system, organized according to a progressive nomenclature (FR01, FR02, ...). These requirements define the expected behaviors of the system, both in terms of secure data acquisition and management and in terms of accessibility, user interface, and interoperability with external systems (such as EHR, HIS, and telemedicine systems).

Table 5. Functional Requirements of the IPDSS System

Requirement ID	Description
FR01	IPDSS shall enable patients to complete a structured form capturing personal data, teleconsultation history, family medical history, allergies, current medications, lifestyle habits, ongoing symptoms, and other clinically relevant information necessary for initial assessment.
FR02	The form shall support multiple input types, including free text fields, multiple-choice options, checkboxes, and date pickers, to ensure flexibility and completeness of data collection.
FR03	IPDSS shall implement client-side validation mechanisms to ensure data consistency, accuracy, and completeness before submission.
FR04	IPDSS shall allow patients to save their progress during form completion and resume the process at a later time without data loss.
FR05	IPDSS shall ensure the confidentiality and integrity of the submitted information during data transmission through secure communication protocols (e.g., HTTPS, encryption).
FR06	A secure user authentication mechanism shall be provided (where applicable) to control access to the form, particularly when enabling partial form saving or editing features.
FR07	IPDSS shall be responsive and accessible across various devices, including tablets and smartphones, ensuring usability and inclusivity.

Table 5. Functional Requirements of the IPDSS System

Requirement ID	Description
FR01	IPDSS shall enable patients to complete a structured form capturing personal data, teleconsultation history, family medical history, allergies, current medications, lifestyle habits, ongoing symptoms, and other clinically relevant information necessary for initial assessment.
FR02	The form shall support multiple input types, including free text fields, multiple-choice options, checkboxes, and date pickers, to ensure flexibility and completeness of data collection.
FR03	IPDSS shall implement client-side validation mechanisms to ensure data consistency, accuracy, and completeness before submission.
FR04	IPDSS shall allow patients to save their progress during form completion and resume the process at a later time without data loss.
FR05	IPDSS shall ensure the confidentiality and integrity of the submitted information during data transmission through secure communication protocols (e.g., HTTPS, encryption).
FR06	A secure user authentication mechanism shall be provided (where applicable) to control access to the form, particularly when enabling partial form saving or editing features.
FR07	IPDSS shall be responsive and accessible across various devices, including tablets and smartphones, ensuring usability and inclusivity.

5.2. "InferCare"

The mobile app, "InferCare", is designed to provide an intuitive, interactive interface that supports patients and physicians throughout the entire information flow. From the patient’s perspective, an interface has been implemented that allows for the guided completion of a multi-section medical history form covering symptoms, medications, allergies, and habits. The form can be temporarily saved locally and can be resumed later. Once the information is validated through the HFFM module, it is visible to the patient through the interface.

Figure 4. Patient’s View

Figure 4. Patient’s View

From the physician’s perspective, an interface has been implemented that provides authenticated and secure access to the patient dashboard, serving as a centralized entry point for all clinical information. Once logged in, the physician can view the list of waiting patients, available appointments, and a summary of each patient’s health status.

Figure 5. Physician’s View

Figure 5. Physician’s View

In the next section, the Sequence Diagrams for patient and physician interaction with the app are described.

5.3. Sequence Diagrams

The sequences of actions performed by the Patient are shown in Figure 6:

• The patient starts the mobile application (StartApp);
• A request is sent to the Front-end Patient to access the data entry form (RequestCompilationForm);
• The patient completes a digital form through the Front-end Patient interface;
• The Front-end Patient form sends the data to the Backend via a REST API (POST(data anamnesis module));
• The "RESTful API" forwards the "POST(data anamnesis module)" to the "HL7 FHIR Formalization Module";
• The HL7 FHIR formalization module transforms the received data into FHIR resources and sends them to the "FHIR Server with IG" for data validation ("validate data") ;
• FHIR Server with IG validates and stores the FHIR Resources , then data sends a "Response FHIR Resources" back to the HL7 FHIR Formalization module.;
• Finally, the "Front-End Patient" receives a "Response Resource FHIR" back to the mobile application as View Form anamnsesis.

Figure 6. Sequence Diagram Patient’s View.

Figure 6. Sequence Diagram Patient’s View.

The sequence in Figure 7 describes the back-end process triggered when a user accesses the mobile application and requests the analysis of diagnostic images. The system handles image retrieval, clinical feature extraction via artificial intelligence, and data transformation into HL7 FHIR format using a structured pipeline supported by RESTful communication and standardized data representation.

• The user accesses the mobile application (AccessApp).
• The application sends an image analysis request to the backend via RESTful API (RequestElaborationImage).
• The RESTful API performs a POST request to the module that queries the ultrasound image database.
• The database receives the request (RequestDiagnosticImage), retrieves the required ultrasound images (Images recovery), and returns them.
• The ultrasound images are sent to the AI-based image analysis module.
• The AI module extracts the clinical features from the ltrasound images (extract features images).
• The extracted data are sent to the HL7 FHIR formalization module (send data features).
• The HL7 FHIR module validates and transforms the data into FHIR format (validate data).
• Finally, the FHIR Server with IG stores the validated features (validation and store features images resource).

Figure 7. Sequence Diagram Images Analysis.

Figure 7. Sequence Diagram Images Analysis.

The sequences of actions performed by the Physician are as follows and shown in Figure 8:

• The physician interacts with the mobile app to request the summary view (RequestViewSummary).
• The app forwards the request to the Clinical Information of Interest presentation module (RequestSummary).
• This module queries the FHIR Server through the RESTful API with a query containing the relevant data (Query FHIR Resources (DataAnamnesis, featuresImage)).
• The FHIR Server with IG retrieves the requested clinical information and returns the FHIR Resources.
• The Clinical Information of Interest presentation module extracts the main data from the received resources, creates a summary with a Health Status Summary and AI-based risk assessment, and highlights the principal information;
• The summary view is presented to the physician through the mobile interface (View Summary).

Figure 8. Sequence Diagram Physician’s View.

Figure 8. Sequence Diagram Physician’s View.

6. Conclusions

In this work, we used the HL7 FHIR standard and all the standard tools made available by the HL7 community to develop an architecture that allows for the integration of data from diagnostic images, data collected by the patient, and data from heterogeneous sources. We have chosen a case study identifying the AI-based risk assessment related to a clinical condition of breast cancer based on the analysis of ultrasound images by using ML models. In this context, the Android application, "InferCare" compliant with HL7 FHIR standard has been created to simplify the diagnostic process with an interactive graphical interface, available for both the patient and the physician.

This application allows the patient to record anamnestic data and the physician to have a summary of the most important information for an effective and fast diagnosis. In the future, it would be interesting to investigate other medical conditions in which this application could be used to quicken and make the diagnostic process efficient.