PIRE: Interoperable Platform for Electronic Records

Abstract

The interoperability of electronic health records in Colombia faces a critical gap between the regulatory mandates established by the Colombian regulatory framework and the actual technical capacity of healthcare institutions to implement them. This article presents PIRE (Electronic Records Interoperability Platform), an open-source architecture that demonstrates the viability of end-to-end FHIR systems in the Colombian context. The main objective was to develop a platform capable of integrating health data from biomedical devices into an FHIR server, preserving clinical semantics through LOINC terminologies. The methodology followed an iterative development approach, implementing a HAPI FHIR server on AWS, a normalization application in Flask, and clinical visualization modules aligned with the FHIR Core CO Implementation Guide. The Bioharness-3 device was used to capture metrics on heart rate, respiratory rate, activity, and posture. The platform achieved a data normalization latency of 104–438 ms per record and 100% semantic validation against the FHIR Core CO profiles, validating compliance with Colombian IHCE specifications. It is concluded that PIRE constitutes a reproducible reference model for healthcare institutions that wish to implement interoperability as a cost-effective solution.

1. Introduction

The digital transformation of the healthcare sector is based on the premise that clinical information, when available in a structured, integrated, and accessible form, can significantly improve the quality and safety of healthcare. Electronic Health Records (EHRs) have emerged as a fundamental response to the needs of modern healthcare systems, evolving from rudimentary digital repositories to sophisticated tools that optimize patient safety and enable precision medicine [1,2]. However, the fragmentation of EHR systems built by different providers with heterogeneous data structures has created a critical challenge. Although technical and syntactic levels of interoperability have reached relative maturity, semantic interoperability—the ability to ensure that clinical information is understood identically when exchanged between systems—remains insufficiently resolved [3].

This challenge is particularly acute in developing contexts like Colombia, where the interoperability of Electronic Health Records has transitioned from an aspiration to a legal obligation through a robust regulatory framework [4,5,6]. Despite these mandates, there is a significant gap between regulatory design and technical reality. While large insurers have begun private implementations [7], the Colombian healthcare system is composed of thousands of small and medium-sized Healthcare Provider Institutions (IPS) that still operate with isolated legacy systems. Academic evidence documenting open, reproducible architectures that these smaller institutions can adopt remains very limited. This lack of accessible technical models, compounded by a shortage of specialized health informatics professionals in the region, hinders the nationwide adoption of the FHIR standard.

Specifically, a critical technical gap exists: while powerful open-source FHIR servers like HAPI FHIR provide robust foundational repositories, they are general-purpose solutions. Out of the box, they lack the specialized middleware required to ingest raw biomedical device data, automate semantic normalization, map these signals to the exact profiles demanded by the Colombian Digital Care Summary (RDA), and ensure data privacy compliance. To address this gap, this study presents PIRE (Plataforma de Interoperabilidad de Registros Electrónicos)—a comprehensive suite that combines custom HL7 mapping logic, a normalization module in Flask, and an underlying HAPI FHIR infrastructure. This open-source architecture maps Patient-Generated Health Data (PGHD) from the Bioharness-3 device [8,9] to HL7 FHIR R4 resources, strictly aligned with the Colombian Digital Care Summary (RDA) model. This work contributes to the field by designing and deploying a reference architecture based on HAPI FHIR and AWS that complies with local regulations (FHIR Core CO), developing a normalization module that transforms raw biosignals into semantic FHIR Observations using LOINC, and validating the system in a controlled academic environment to demonstrate the viability of end-to-end interoperability. The remainder of this paper is organized as follows: Section 2 reviews the state of the art in EHR interoperability and FHIR applications; Section 3 details the specific regulatory and technical context of Colombia; and subsequent sections describe the materials, methods, and results of the PIRE implementation.

2. Related Work

The evolution of Electronic Health Records has been intrinsically linked to the challenge of interoperability. Early efforts focused on legacy standards like HL7 CDA, which, while offering high syntactic interoperability in systems such as the Austrian ELGA, often faced limitations regarding dynamic exchange and data reuse [10]. Systematic reviews confirm that preserving clinical meaning during data exchange remains the primary goal of these efforts [11]. To address the limitations of legacy standards, recent solutions such as TermX have emerged to transform CDA documents into FHIR resources, facilitating the migration to modern architectures [12]. This transition is supported by global regulations, including the European Health Data Space and US mandates, which have positioned FHIR as the dominant standard for semantic interoperability [13,14,15].

Literature shows extensive application of FHIR in diverse domains. In general interoperability, FHIR has been established as the technology for harmonizing biomedical data and predictive analytics [16], with feasible implementations even in developing countries [17]. In clinical research, tools like REDCap and XNAT have integrated FHIR to reduce human error and facilitate data exchange [18,19], while automation tools like FML2Mirth simplify the migration of complex laboratory data [20]. The standard’s versatility is further demonstrated in its convergence with artificial intelligence, where systems like FHIR-Former and LINK-FHIR use language models to process multimodal data and standardize unstructured clinical notes [21,22]. Furthermore, innovations such as SQL on FHIR enable massive-scale analysis using traditional tabular tools [23].

Security and usability also feature prominently in recent work, with proposals for attribute-based access control (ABAC) and blockchain-based sovereign identity models to manage granular permissions [24,25]. In specialized domains, FHIR has been successfully applied to genomic medicine [26], hospital operations management [27], pharmaceutical quality data [28], and even the integration of geospatial data for environmental health studies [29]. Regarding the Internet of Medical Things (IoMT), platforms have been developed to combine FHIR with federated learning for wearable privacy [30], personalized musculoskeletal monitoring [31], and diabetes management systems [32,33]. Similarly, the integration of commercial devices like Garmin and low-cost microcontrollers (ESP32) into health spaces highlights the standard’s capability to orchestrate complex ecosystems of continuous monitoring [34,35].

3. Colombian Regulatory and Technical Context

Colombia has established one of the most comprehensive legal frameworks for digital health in Latin America. The cornerstone of this framework is Law 2015 of 2020, which created the Interoperable Electronic Health Record (I-EHR) system and established the obligation for all healthcare providers to share relevant clinical data [4]. This law was further regulated by Resolution 866 of 2021, which explicitly adopted HL7 FHIR as the technical standard for data exchange [5]. More recently, Resolution 1888 of 2025 has updated these technical guidelines, reinforcing the adoption of the Digital Care Summary (RDA) as the centerpiece of information flow [6]. To operationalize this, the Ministry of Health supports the “FHIR Core CO” Implementation Guide, which adapts international resources to local administrative requirements [36].

Despite this mandate, the technical ecosystem remains profoundly fragmented. The structural reality of the country presents a high barrier to entry for standard adoption; most clinical environments lack the native infrastructure and the specialized engineering teams required to implement complex health information exchanges [37]. While initiatives from HL7 Colombia actively promote capacity building and interoperability connectathons, successful deployments are currently concentrated among a few major corporate entities. For instance, the insurer SURA has designed an interoperability architecture on the Google Cloud Healthcare API, developing over fifty FHIR profiles aligned with the Colombian Core [7]. In the corporate sphere, Ecopetrol has promoted integration models using solutions like Medifolios to synchronize administrative and clinical data using FHIR [38,39]. Nevertheless, academic evidence documenting open pilot tests remains limited. Deploying a standalone open-source FHIR server is insufficient to meet these regulatory demands without a custom integration layer. Implementing this layer from scratch represents a massive technical bottleneck for smaller institutions due to the lack of trained personnel, the complexity of clinical mapping, and the strict legal penalties associated with Habeas Data non-compliance. PIRE directly addresses this technical bottleneck by providing the missing middleware that bridges the gap between raw clinical telemetry and the strict compliance rules of the Colombian FHIR Core CO.

4. Materials and Methods

4.1. Materials

The Interoperable Electronic Records Platform (PIRE) is an open, HL7 FHIR R4–based interoperability architecture that includes web services and tools for the comprehensive management of clinical and biomedical data. To achieve this, PIRE was deployed on Amazon Web Services (AWS) cloud infrastructure, using an EC2 compute instance running Ubuntu Linux as the runtime environment for the HAPI FHIR server and Flask web application. This configuration allows the platform to be remotely accessible to authorized users at the Universidad Militar Nueva Granada, while simultaneously facilitating centralized administration of clinical resources and future scalability of the system.

4.1.1. Technology Stack

The platform’s technology stack combines Python 3.12.3 web development components with Java-based FHIR server infrastructure and related persistence via PostgreSQL. Specifically, the web application layer was implemented using Python’s Flask framework, which manages HTTP routes, data capture forms, authentication and authorization logic, and communication with the FHIR server via REST requests. To enhance security, Flask is complemented by Flask-Session for server-side session management, allowing you to securely store authentication status and temporary data from observation log streams. In parallel, the HAPI FHIR server runs on the Java Spring Boot framework, using Open JDK 17 as the runtime environment and Maven as the build and dependency management tool. For persistence purposes, FHIR resource persistence is achieved using PostgreSQL 16, which stores Patient, Observation, and Practitioner resources in JSON format within specialized tables, thereby enabling direct SQL queries on clinical data when advanced analysis or validation of stored information is required. The communication pathway between the Flask application and the HAPI FHIR server is carried out using the standard FHIR RESTful API, using HTTP GET, POST, and DELETE operations on the endpoints corresponding to each type of resource.

Table 1. PIRE technology stack.

Layer	Component	Technology	Version
Web application	Framework	Flask (Python)	2.x
Web application	Sessions	Flask-Session	-
FHIR server	Implementation	HAPI FHIR JPA Server	8.2.0
FHIR server	Runtime	OpenJDK	17.0.15
FHIR server	Build	Maven	3.x
Database	Engine	PostgreSQL	16.9
Operating system	Distribution	Ubuntu Linux	24.04.2 LTS
Infrastructure	Cloud	AWS EC2	-

below presents details about the PIRE technology stack.

4.1.2. HAPI FHIR R4 Server

The HAPI FHIR server was installed from the official ha-pi-fhir-jpaserver-starter repository, which provides a production-ready implementation of the FHIR R4 standard with support for JPA persistence and a test web interface. The environment was built and compiled using standard Java and Maven dependencies. Subsequently, the data persistence layer was established by configuring the connection to the PostgreSQL database using the required administrative credentials and connection URLs.

Once initialized, the application exposes the FHIR endpoints via the /fhir path, thereby enabling the Flask middleware to consume the RESTful services to create, query, and delete clinical resources. Notably, the HAPI FHIR server stores resources in the PostgreSQL database using a predefined table schema, which contains the metadata for each resource and stores the complete JSON content of each version of the resource, thus permitting both API access and direct SQL queries for validation and analysis.

Regarding data validation, the FhirInstanceValidator module provided by the HAPI FHIR interceptor framework was enabled to enforce baseline structural and syntactic validation against the core FHIR R4 standard. However, the specific conformance profiles required by the Colombian Digital Care Summary (RDA) and FHIR Core CO were not enforced directly at the database level. Instead, this semantic validation and conformance mapping (e.g., mandatory LOINC code assignments and local identifier extensions) were programmatically orchestrated within the Flask middleware layer. This design choice ensures that the data is strictly validated and formatted to local regulations before the payload is submitted to the HAPI FHIR server for persistence.

4.1.3. AWS EC2 Configuration

The computing infrastructure was deployed on an Amazon Web Services EC2 instance, using a virtual machine image with Ubuntu 24.04.2 LTS. To enable access, the instance was configured with a public IP address that allows remote access via SSH, providing a secure mechanism for server administration without exposing user credentials. In practice, access to the server is achieved using the standard SSH command, specifying the path to the private key and the public IP address of the instance, after which the administrator gains access to manage the services. With respect to network configuration, the instance’s network configuration includes security group rules that allow incoming traffic on the ports necessary for system operation. Internally, the instance maintains a private IP address within the AWS VPC for internal communication between components, while the public IP address simultaneously allows access from authorized external networks. This deployment scheme facilitates future horizontal scalability, as it allows the instance to be replicated or migrated to AWS managed services without modifying the application architecture.

4.1.4. Integration with the Universidad Militar Nueva Granada

The platform was developed within the context of the TIGUM research group at the Universidad Militar Nueva Granada, which determined design decisions aimed at facilitating academic use and clinical validation in controlled environments. Specifically, integration with the university’s infrastructure was achieved through remote access to the EC2 server, allowing authorized researchers and students to interact with the platform. To reflect organizational structure, the platform’s user and role system was designed to mirror the organizational hierarchy of a clinical-academic environment, with distinct roles for administrators, healthcare professionals involved in research, support staff, and auditors. For data isolation purposes, the PostgreSQL database was configured with a schema called pire_db and a specific administrator user for the platform, which allows the platform data to be isolated from other possible uses of the server and simultaneously facilitates the management of backups and eventual migration to permanent institutional infrastructure. To promote knowledge transfer, the technical documentation for the system, including installation guides, architecture, and troubleshooting, was kept in Markdown format within the studio repository, thereby facilitating the transfer of knowledge to future developers or researchers who continue the work. Overall, this configuration allows the platform to function as a working prototype for validating the FHIR interoperability model in the Colombian context, while laying the groundwork for eventual implementation in real clinical production environments.

4.1.5. Biomedical Sensing Device

The Bioharness™ 3.0 (Zephyr Technology Corporation, Annapolis, MD, USA) was selected as the reference wearable biosensor for this study. As of 2026, the BioHarness 3.0 remains the current commercially available model from Zephyr Technology; no successor version has been released. The device captures heart rate, respiratory rate, posture, and activity at validated clinical accuracy [8]. The selection was justified by the standardized, open CSV output format via the OmniSense SDK, enabling reproducible data ingestion without proprietary drivers; availability in the TIGUM academic laboratory at Universidad Militar Nueva Granada, enabling controlled testing without additional procurement; and a well-documented data structure, facilitating the development of deterministic FHIR transformation logic.

4.2. Methods

The development of health informatics software adhering to the HL7 FHIR standard requires a multidisciplinary approach that integrates regulatory alignment, data modeling, semantic validation, and user-centered design. Accordingly, PIRE’s development followed a structured methodology organized into five sequential phases: (1) regulatory and normative analysis, (2) semantic and functional modeling, (3) architectural design and implementation, (4) security, governance, and user-centered design, and (5) validation and deployment.

4.2.1. Phase 1: Regulatory and Normative Foundation

The development of PIRE began with a comprehensive documentary analysis to establish the normative and regulatory framework governing electronic health records interoperability in Colombia. This phase involved examination of Law 2015 of 2020, Resolution 866 of 2021, and Resolution 1888 of 2025, which collectively establish the Interoperable Electronic Health Record (IHCE) as a mandatory national system. Simultaneously, a systematic review of international FHIR implementations and use cases was conducted to identify successful technical patterns applicable to the Colombian context. This included analysis of implementations in the European Health Data Space (EHDS), the United States Interoperability Standards Advisory, and emerging IoMT-FHIR architectures documented in the peer-reviewed literature. The output of this phase was a comprehensive requirements specification document that articulated both functional and non-functional requirements for PIRE, derived from regulatory mandates and international best practices.

4.2.2. Phase 2: Semantic Data Modeling

To ensure that clinical data retained its precise meaning across system boundaries, PIRE’s semantic layer was constructed using standardized clinical terminologies and resource profiles. Specifically, the FHIR R4 Patient, Observation, and Practitioner resources were adapted to comply with the Core Colombia Implementation Guide, incorporating Colombian-specific identifiers, terminology mappings, and organizational hierarchies. For vital signs data, LOINC (Logical Observation Identifiers Names and Codes) terminology was used to standardize the identification of measured phenomena, ensuring that metrics such as heart rate, respiratory rate, activity and posture could be universally understood. Additionally, where applicable, SNOMED CT concepts were mapped to Colombian disease classifications (CIE-10) to preserve clinical semantics during data exchange. This semantic modeling was documented using FHIR StructureDefinitions and implemented as validation schemas within the HAPI FHIR server, ensuring that all resources submitted to the platform conformed to the defined semantic contracts before persistence.

To ensure the reproducibility of the data transformation process, the explicit mapping logic between the raw Bioharness-3 CSV outputs and the FHIR R4 standard is detailed in

Table 2. Data Mapping Schema from Bioharness-3 CSV to FHIR R4 Resources.

Bioharness CSV Fields	Conversion and Normalization Logic	FHIR Element Mapping
Timestamp	Parsed to standard ISO 8601 [40] format (UTC). The minimum and maximum timestamps define the period.	Observation.effectivePeriod.start Observation.effectivePeriod.end
Time Differences	Calculates the average time elapsed between consecutive samples in milliseconds (ms).	Observation.valueSampledData.interval Observation.valueSampledData.intervalUnit = “ms”
HR_BPM	Filters valid physiological ranges (30–200 bpm). Converts the filtered numeric array into a single space-separated string.	Observation.code.coding.code = “8867-4” Observation.code.coding.display = “Heart rate” Observation.valueSampledData.data = [string] Observation.valueSampledData.origin.unit = “beats/min”
BR_BPM	Filters valid ranges (2–40 breaths/min). Converts the floating-point array into a space-separated string.	Observation.code.coding.code = “9279-1” Observation.code.coding.display = “Respiratory rate” Observation.valueSampledData.data = [string] Observation.valueSampledData.origin.unit = “breaths/min”
Activity	Filters valid ranges (0–10 METs).	Observation.code.coding.code = “41950-7” Observation.code.coding.display = “Physical activity level” Observation.valueSampledData.data = [string] Observation.valueSampledData.origin.unit = “MET”
Posture	Filters valid angular ranges (−90° to 90°).	Observation.code.coding.code = “8361-8” Observation.code.coding.display = “Body position” Observation.valueSampledData.data = [string] Observation.valueSampledData.origin.unit = “position_code”
Array Mean Value	Evaluates the mean of the array against clinical thresholds to determine an interpretation code (N = Normal, H = High, L = Low).	Observation.interpretation.coding.code = [Code] Observation.interpretation.coding.system = “…v3-ObservationInterpretation”

. Because continuous wearable monitors generate high-frequency time-series data, mapping each row to a single Observation.valueQuantity would be highly inefficient and could cause server overload. Therefore, the middleware utilizes the FHIR SampledData data type. This approach compresses the time-series array into a single space-separated string, calculates the dynamic sampling interval in milliseconds, and semantically tags the payload using strict LOINC codes. Furthermore, a clinical interpretation algorithm automatically assigns a severity code (Normal, High, Low) based on the calculated mean of the array.

4.2.3. Phase 3: Architectural Design and Implementation

PIRE’s architecture was designed following REST (Representational State Transfer) principles, with clinical data organized as persistent, addressable resources accessible via standard HTTPS protocols and HTTP operations (GET, POST, DELETE). This resource-oriented approach contrasts with message-based architectures, as it treats each clinical entity (Patient, Observation, Practitioner) as a first-class resource with a stable URI and standardized access patterns. The technical implementation employed a microservices topology, with distinct components responsible for specific functions: the HAPI FHIR server manages resource persistence and retrieval; the Flask web application provides the user interface and orchestrates business logic; the Bioharness-3 normalization module transforms raw wearable device data into FHIR Observations; and the audit logging subsystem maintains non-repudiation records of all data transactions. Communication between components uses lightweight, language-agnostic formats: JSON for API payloads and structured data interchange, and standard FHIR transaction bundles for atomic multi- resource operations. This modular design facilitates independent scaling of components and reduces coupling between layers.

4.2.4. Phase 4: Security, Governance, and User-Centered Design

Security and governance were implemented through multiple complementary mechanisms. At the authentication layer, role-based access control (RBAC) was employed, with distinct roles (administrator, clinician-researcher, support staff, auditor) corresponding to organizational positions and clinical responsibilities. At the data layer, all access to FHIR resources was logged with comprehensive audit trails recording the timestamp, user identity, operation type, and resource identifiers, enabling post hoc accountability and compliance with Colombian health data protection regulations (Habeas Data). Additionally, user interface design followed human-centered design principles, prioritizing clarity and cognitive accessibility for clinical users unfamiliar with FHIR’s technical complexity. Interface elements were iteratively refined based on feedback from university researchers and students to ensure that visualization of vital signs data and clinical metadata did not introduce cognitive burden or opportunities for error.

4.2.5. Validation Approach

To validate the technical feasibility and functional correctness of PIRE, a controlled pilot study was conducted using synthetically generated Bioharness-3 wearable data. Continuous vital signs data (heart rate, respiratory rate, activity, posture) were collected during controlled laboratory sessions, normalized into FHIR Observation resources, and transmitted to the cloud FHIR server via the Flask normalization middleware. The validation comprised 36 simulated patient records and 200 biomedical observation records (approximately 5–6 observations per patient). This study constitutes an initial pilot phase; data collection is ongoing to expand the dataset for future statistically powered studies.

5. Development

5.1. Operational Flow

This section describes the technical architecture and functional capabilities of PIRE. The platform is designed to orchestrate four critical functionalities: comprehensive patient management through CRUD operations (PatientCO), processing of biomedical observations from raw CSV files (heart rate, respiratory rate, activity, and posture), clinical analysis with automatic stratification of values, and role-based security with transaction auditing. As illustrated in Figure 1, the platform’s operational architecture is organized into three distinct functional domains: Web Browser, Services, and Audit. The workflow initiates at the Web Browser layer, which serves as the secure entry point for authentication; here, user credentials are verified, and the interface dynamically adjusts to display the appropriate menu options based on the assigned role. The core functionality is executed within the Services domain, where users, subject to their permissions, can perform CRUD operations on patient records and manage medical observations through creation, consultation, and deletion processes. Within this same domain, the Super Admin role retains exclusive privileges to create, delete, and query the credentials of registered users. Complementing these operations, the Audit module ensures accountability by systematically registering all critical security events, including platform logins and processes related to the creation and deletion of user accounts, thereby maintaining a traceable record of system access and administration.

Additionally, the software architecture is described in detail, encompassing component topology, the implementation of role and permission management using security decorators, the generation of FHIR Observation resources with standardized LOINC codes and PatientCO and PractitionerCO profiles aligned with the FHIR Core CO Implementation Guide, and credential management using XOR + Base64 encryption with server-side sessions. Collectively, these elements form an integrated technical foundation that operationalizes the regulatory requirements established by Colombian health informatics standards.

5.2. Technical Architecture of the Platform

PIRE adopts a three-layer architecture that separates responsibilities between the user interface, business logic, and data persistence, thereby facilitating system maintainability, scalability, and security. This architectural model allows the Flask application to act as a central orchestrator, integrating specialized modules for authentication, patient management, processing of biomedical observations generated by the Bioharness-3 device, and generation of standardized FHIR R4 resources. Crucially, communication between layers is carried out through RESTful calls to the HAPI FHIR server, ensuring that all clinical data is structured in accordance with international specifications and Colombian regulations from the point of storage.

5.2.1. General System Topology

The PIRE architecture is organized into three functional layers that operate in an integrated manner. At the presentation level, the layer acts as the single interface where users with different roles interact with HTML forms, view clinical information, and upload CSV files containing measurements from the Bioharness-3 device. HTTP requests from the browser are received by the application layer, where routes protected by security decorators validate permissions before processing business logic. Once the user is authenticated and authorized, the authentication module verifies credentials stored in CSV files, while specialized service modules perform operations on patient, observation, and professional data. At the data layer, the layer comprises two complementary subsystems: a local file system in CSV format that stores user management and audit information, and a HAPI FHIR R4 server that acts as a reference repository for all clinical resources (Patient, Observation, Practitioner) backed by a PostgreSQL database and ensuring compliance with the FHIR R4 standard and alignment with the FHIR Core CO implementation guide. As shown in Figure 2, the data flow architecture presents PIRE’s three layers and their interactions.

The typical data flow in PIRE begins when an authenticated user sends an HTTP request (e.g., create an observation) through the web interface. Subsequently, the Flask application intercepts the request on a specific route, where the security decorator verifies that the user has the necessary role. If validation is successful, the controller calls the corresponding service, which executes the business logic; the CSV file is read and validated, the measurement type is automatically detected, the clinical interpretation is calculated, and the FHIR Observation resource is constructed according to the FHIR R4 standard. Following this, the constructed FHIR resource is transmitted via POST to the HAPI FHIR server endpoint, which persists it in its internal PostgreSQL database. Simultaneously, the authentication module records the action in the local file with user information, IP, timestamp, and transaction result, ensuring complete traceability. Importantly, this three-layer decoupled design allows changes to the user interface do not affect business logic, modifications to services do not require alterations to data access, and FHIR data persistence is independent of local user management and auditing.

5.2.2. Functional Components and Modules

The technical implementation of PIRE structures its code into three specialized modules that operate in coordination under the control of the central Flask application. This modular organization allows each component to be responsible for a specific set of functionalities, thereby facilitating independent testing, incremental maintenance, and code reuse. Importantly, the modules interact through function calls within the application, avoiding direct coupling and allowing internal changes in one module to not affect others while maintaining their public interface.

Table 3. System modules and responsibilities.

Module	Components	Functional Responsibilities
auth/	Authentication, user manager, cryptography, security decorators, auditing	Identity validation; session creation and destruction; permission evaluation; secure encryption; credential generation; path protection; event auditing
services/	Patients, observations, professionals	Patient lifecycle (CRUD); CSV processing; automatic measurement detection; clinical validation; FHIR construction; remote synchronization
utils/	Logging, validators	Patient lifecycle (CRUD); CSV processing; automatic measurement detection; clinical validation; FHIR construction; remote synchronization

below summarizes the three modules and their primary responsibilities.

The Authentication Module (auth/) centralizes all functions related to security, access management, and system auditing. Specifically, this module is responsible for validating user identities against stored credentials, creating and destroying secure sessions, evaluating permissions based on assigned roles, protecting web paths through authorization mechanisms, encrypting and decrypting passwords to ensure they are never stored in plain text, automatically generating secure credentials (username and password) for new users, and comprehensively logging critical system events for complete traceability.

The module consists of five specialized files that work together. First, the authentication service (auth_service.py) provides the core logic allowing the application to verify who the user is and what actions they are authorized to perform. Second, the user manager (user_manager.py) handles the persistence of user data in CSV files, allowing you to create, query, update, and delete records securely and consistently. Third, the cryptographic assistant (crypto_helper.py) provides encryption functions that ensure passwords are never stored in plain text by using secure algorithms to protect credentials. Fourth, security decorators (decorators.py) define reusable mechanisms that protect individual application routes by automatically validating permissions before allowing access to functionality. Finally, the audit manager (audit_manager.py) logs critical authentication and user management events (successful logins, failed login attempts, logouts, user creation and deletion) with user information, IP address, timestamp, and result, creating a comprehensive audit log for regulatory compliance and subsequent forensic analysis.

The Services Module (services/) is responsible for orchestrating all operations involving clinical data, including managing the entire patient lifecycle, processing biomedical observations from CSV files generated by the Bioharness-3 device, generating FHIR R4 resources in accordance with international and Colombian regulatory standards, and ensuring resilient communication with the remote HAPI FHIR server.

A key feature of the module is its ability to automatically detect the type of measurement being analyzed. When a CSV file containing biomedical measurements is uploaded, the service automatically infers whether it corresponds to heart rate, respiratory rate, physical activity, or posture through statistical analysis of the data, without requiring the user to manually specify the type. This capability significantly improves the user experience and reduces classification errors. Additionally, the module encapsulates all clinical validation logic, such as verifying that an identity document is unique in the system before creating a duplicate patient, validating that the patient’s age is consistent with their document type, and calculating whether the measured values are within normal clinical ranges for automatic interpretation. The construction of FHIR resources occurs entirely within this module, ensuring that all data sent to the FHIR server complies with the defined structure, where each Patient resource includes specific Colombian extensions, each Observation includes standardized LOINC codes and accurate timestamps, and each Practitioner links correctly with system users.

The Utilities Module (utils/) provides reusable cross-cutting functionality that supports system integrity and traceability. Specifically, the logging subsystem configures a centralized logging system that captures operational events at different severity levels, simultaneously writing to permanent files for later auditing and also to the console for debugging and real-time monitoring.

The validation subsystem implements a set of reusable validators that protect data integrity at multiple levels by verifying that text fields contain only expected characters, that email addresses have a valid structure with the correct domain, that phone numbers comply with regional patterns, that identity documents correspond to valid types in Colombia, and that dates have the correct format and are within the valid range. These validators are applied on both the client and server sides, ensuring that malformed data never leads to the creation of invalid FHIR resources that could cause errors on the HAPI FHIR server.

5.3. Authentication, Authorization, and Access Control System

The PIRE authentication and authorization system was designed as a layered security mechanism that ensures only identified and authorized users can access critical clinical management functions. Specifically, the solution combines credential-based authentication, role-based access control, application-level route protection, and comprehensive audit logging, aligning platform operation with recommended security practices for electronic health record systems.

5.3.1. Model of Roles Implemented

PIRE implements four main roles inspired by the organizational structure of a hospital environment: Super Admin, Doctor, Nurse, and Auditor, each with a clearly defined scope of authority over patient resources, observations, users, and audits. The Super Admin role acts as the overall system administrator, with the ability to perform comprehensive operations on patients and observations, manage users, view all user passwords and access the full audit trail. Consequently, it is reserved for the initial configuration and overall administration of the platform.

The Doctor role represents the clinical professional with permissions to create, consult, and edit patients, record biomedical observations, and delete erroneous measurements, but without the authority to delete patients, administer users, or review audits, with the aim of separating administrative and care functions. In contrast, the Nurse role is geared toward nursing staff with an emphasis on operational records, where they can consult patients, create new observations, and review existing measurements, but cannot modify patient demographic data, delete observations, or manage users, which limits their impact on the structure of the clinical record. Finally, the Auditor role is designed for supervision and monitoring functions, with read-only access to patients and observations, and full access to the audit module, but without the ability to create, edit, or delete resources, ensuring independence between evaluation and operation.

Table 4. Permission matrix by role.

Resource/Action	Super Admin	Doctor	Nurse	Auditor
Create patients	✓	✓	✕	✕
List patients	✓	✓	✓	✓
Consult patients	✓	✓	✓	✓
Edit patients	✓	✓	✕	✕
Delete patients	✓	✕	✕	✕
Create observations	✓	✓	✓	✕
Consult observations	✓	✓	✓	✓
See details of observations	✓	✓	✓	✓
Delete observations	✓	✓	✕	✕
Create user	✓	✕	✕	✕
List user	✓	✕	✕	✕
View user details	✓	✕	✕	✕
View passwords	✓	✕	✕	✕
Delete user	✓	✕	✕	✕
View audit	✓	✕	✕	✓
View my profile	✓	✓	✓	✓

provides detailed information on the permissions assigned to each role.

This role model embodies a principle of least privilege, whereby each actor only has the permissions strictly necessary for their usual tasks, reducing the attack surface and the risk of accidental or malicious modifications to sensitive clinical data. Moreover, the explicit separation between care, administrative, and supervisory roles facilitates the traceability of responsibilities in the event of incidents or internal audits.

5.3.2. Authentication Process and Session Management

Authentication in PIRE is based on individual credentials that are validated on the server before granting access to any protected functionality. As shown in Figure 3, the complete login and sign-in flow is orchestrated through multiple security checks. During system initialization, a startup script generates an initial Super Admin user whose credentials are stored in encrypted CSV files and documented in a restricted credentials file for configuration purposes only. When a user accesses the login page, the Flask application receives the credentials, verifies the user’s existence in the users.csv table, and compares the password provided with the encrypted version in passwords.csv using a controlled decryption process.

Upon successful authentication, the application creates a server session using Flask-Session, storing only internal identifiers such as the user ID, username, and associated role, without saving the password in the session or exposing sensitive information in cookies. To enhance security, sessions are stored in the server’s file system, automatically invalidated when the application is stopped, and accompanied by HTTP headers that disable browser caching, reducing the risk of information exposure on shared computers. In each subsequent request, security decorators verify the presence of an active session and, if not, redirect to the authentication form, ensuring that no critical paths are accessible without login.

Notably, logging out explicitly invalidates the server session and records the event in the audit log, allowing you to identify each user’s logins and logouts. Overall, this approach, based on server sessions and non-cache headers, complements the authentication model with additional measures against session reuse and screen exposure in previously authenticated browsers.

5.3.3. Authorization Mechanisms and Permission Matrix

On top of authentication, there is an authorization layer that evaluates, for each request, whether the user’s role has explicit permission for the action they are attempting to perform. Specifically, this assessment is implemented based on the centralized permission matrix managed and shown in Table 4. The application associates each critical path with a logical resource and an action, so that the authorization layer can decide deterministically whether to grant or deny the operation. To implement this, role and permission security decorators integrate this logic into Flask routes, intercepting requests before business logic is executed. Specifically, the role-based decorator verifies that the session role is included in a set allowed for the path, while the permissions decorator consults the role permissions matrix to assess whether the role has rights over the resource and the requested action, returning a 403 error in case of unauthorized access. This declarative approach allows authorization logic to be kept concentrated in a readable permission structure, facilitating policy review and adjustment, and avoiding inconsistencies between different views that access the same type of resource.

5.3.4. Credential Security and Automatic User Generation

PIRE implements a specific scheme to protect passwords, combining an XOR operation on each character with a fixed secret key and subsequent Base64 encoding, so that passwords are never stored in plain text in the file system. During the encryption process, the plaintext password is transformed into an encoded representation that is stored in passwords.csv, while the users.csv file only retains user metadata such as the identifier, username, assigned role, creation date, and link to the corresponding Practitioner resource, thereby maintaining an explicit separation between identity and secrecy. Notably, password decryption is only performed at controlled moments, such as login validation or explicit viewing by the Super Admin, applying the reverse process of Base64 decoding and XOR operation with the same secret key.

User generation is supported by an automated workflow designed to reduce human error and standardize credentials. When the Super Admin creates a new user through the administration interface, the platform requires the completion of a form with the user’s personal data, including first and last names, type and number of identification document, contact details, specialty, and FHIR role. After validating that the identity document is unique and that the role and specialty are consistent, the system automatically creates a Practitioner resource on the FHIR server, generates a username following a deterministic pattern, and produces a secure random password between 10 and 15 characters that must include uppercase letters, lowercase letters, numbers, and symbols.

Subsequently, new user information is stored in users.csv and their encrypted password in passwords.csv, with the operation being recorded in the audit log along with the identifier of the associated FHIR professional. To enhance security, the generated credentials are displayed only once in the Super Admin interface, who must transmit them to the professional through a secure channel, preventing the password from being automatically displayed again to reduce the risk of inadvertent exposure. Additionally, the platform offers a “My Profile” view accessible to all authenticated users, allowing them to review their basic data, assigned role, and credentials, thereby reinforcing the transparency of the access model.

5.3.5. Auditing Authentication and Access Events

The PIRE audit system is the final layer of the security model, providing complete traceability of authentication events, access, and management of clinical and administrative resources. Specifically, each login attempt, whether successful or unsuccessful, generates a record in the audit_log.csv file with information about the user, the action performed, the IP address, the timestamp, and an indicator of success or failure, allowing patterns of failed attempts or accesses from unusual locations to be identified. Similarly, all sensitive user and professional management operations, such as the creation or removal of Practitioner users and resources, are recorded with the action detail, the type of resource concerned and its identifier.

The audit interface presents the last one hundred records arranged chronologically, thereby allowing for quick identification of recent actions, and highlights different types of events through visual indicators, facilitating anomaly detection, incident investigation, and compliance reporting, making auditing an active component of the platform’s governance model. Taken together, the combination of robust authentication, role-based and permission-based authorization, credential protection, and detailed auditing creates a comprehensive security environment consistent with the needs of an interoperable clinical management system.

5.4. Patient Management and Resource Generation FHIR Patient

Patient management in PIRE was implemented as a complete lifecycle flow on the FHIR R4 Patient resource, aligned with the FHIR Core CO Implementation Guide. Specifically, the web application offers structured forms for patient registration, consultation, updating, and deletion, while the HAPI FHIR server acts as a central clinical repository, storing each patient as a Patient resource enriched with extensions specific to the Colombian context. Critically, the integration between the Flask interface and the FHIR server ensures that all demographic and identification information subsequently used by biomedical observations remains consistent, versioned, and accessible for clinical and secondary analysis purposes.

5.4.1. Processes for Creating, Reading, Updating, and Deleting Patients (CRUD)

Registering a new patient is done through a multi-step web form that guides the user through capturing the minimum data required by the FHIR Patient model, including official identifiers, demographics, contact information, and emergency contact details. During this process, the system validates that the identity document does not already exist on the FHIR server, applies format validators to names, emails and telephones, and verifies the consistency between age and document type, avoiding the creation of duplicate or inconsistent records. Once the validations are passed, the application builds a Patient resource and sends it via a POST operation to the /Patient endpoint of the HAPI FHIR server, which returns the patient’s unique identifier for reference in future clinical operations.

The consultation and listing of patients is supported through searches by identity document and paginated lists that obtain information from the FHIR server using standard search parameters. To facilitate clinical use, the interface displays full name, document type and number, and FHIR identifier, allowing the user, with permissions on patient data, to navigate to the detailed patient record, where complete demographic data is displayed and linked biomedical observations are accessed. With respect to modifications, update operations are restricted to roles with clinical permissions, which can modify specific contact fields or demographic data. These changes are reflected through update operations on the Patient resource in the FHIR server, maintaining a single master record per patient. Notably, deleting patients is reserved for the Super Admin role and is implemented as a cascading process that first removes the observations associated with the patient and subsequently removes the Patient resource from the FHIR server, reducing the risk of leaving orphaned clinical data.

As illustrated in Figure 4, the operational lifecycle of the Patient resource is managed through four distinct workflow stages. The process begins with Creation, where the user completes an HTML form capturing personal, contact, and demographic details; the backend validates this data for consistency before constructing the FHIR Patient resource and executing a POST request to persist it on the HAPI FHIR server. For Reading and Consultation, the system enables users to either list all registered patients or query specific records using unique identification documents, retrieving complete datasets directly from the server. The Update workflow is initiated by locating an existing patient record, allowing authorized personnel to modify specific fields, which are then synchronized with the master record. Finally, the Deletion process requires a two-step verification: the user first locates the patient via the interface, and upon confirmation, the system executes a cascading delete operation that removes both the patient’s demographic information and all associated clinical observations from the HAPI FHIR server, ensuring database integrity.

5.4.2. FHIR Patient Resource Structure

The Patient resource generated by the platform follows the FHIR R4 model, incorporating the essential elements for unique identification and clinical use in the Colombian context. Specifically, each resource includes an official identifier in the identifier element, which combines the document type and the patient’s identification number, allowing deterministic searches from the application forms. To preserve regional naming conventions, the patient’s name is represented with explicit separation between first and last names, and with support for registering the second maternal surname through a specific extension, preserving the typical nominal structure of the region. Additionally, the Patient resource includes coding of gender, date of birth, contact information and address structured by lines, city and department, which allows its reuse in both care flows and subsequent geospatial analysis. Furthermore, marital status is also stored and, when available, occupation information via extensions, as well as an emergency contact with name, relationship and contact details, which facilitates continuity of care and communication in critical events. Collectively, this standardized structure ensures that demographic data is interoperable and that Patient resources can be consumed by other FHIR-compliant systems without additional transformations.

5.5. Biomedical Observation Taking and Resource Generation FHIR Observation

PIRE implements a specialized workflow to record biomedical observations from CSV files generated by the Bioharness-3 device, transforming time series of physiological signals into FHIR Observation resources structured according to the R4 standard. The process combines guided web forms, a robust CSV file processing engine, and clinical business logic that ensures data validation, automatic detection of measurement type, and stratification of values according to preconfigured interpretive ranges. In this manner, each set of measurements of heart rate, respiration, physical activity or posture is represented as an interoperable observation, linked to a previously registered patient and available for clinical consultation and further analysis.

5.5.1. CSV File Upload and Data Validation Process

The registration of a new observation is done through a two-step flow that begins with the selection of the patient and the measurement context, followed by the uploading of the CSV file with the biomedical measurements. In the first step, the authenticated user selects the target patient from their identity document, validates their existence on the FHIR server, and specifies contextual information such as the device used (Bioharness-3) and the expected signal type, temporarily storing these parameters in the application session. In the second step, the interface allows you to upload the CSV file exported from Bioharness-3, which is generated from the Software Development Kit (SDK) provided by the company Zephyr called Omnisense 3.9.7, and fill in additional clinical metadata, after which the observations module runs a series of validations on the received file before building the FHIR resource.

The CSV processing system was designed to tolerate frequent variations in encoding, separators, and time formats typical of real-world environments. Specifically, for each file, the service attempts to decode the content using different encoding schemes and test multiple separators until it identifies a valid combination that allows the columns to be interpreted correctly. The expected format requires a first header line, which is discarded, a first column with timestamps, and a second column with numerical values corresponding to the recorded physiological signal. To ensure temporal integrity, timestamps are normalized by applying a set of predefined patterns, ensuring that all points in the series are converted to valid time instants before constructing the observation.

5.5.2. Automatic Detection of Measurement Type

A central feature of the observation module is the ability to automatically detect the type of measurement contained in the CSV file through statistical analysis of the numerical values. The service calculates basic metrics such as range of values, average and presence of decimals and, from these parameters, classifies the signal into one of four categories: heart rate, respiratory rate, physical activity, or posture. This approach enables the system to identify; for example, continuous value series around tens or hundreds, such as heart rate; lower and regular values, such as respiratory rate; numerical levels typical of physical activity scales; and discrete codes that represent changes in posture.

Notably, automatic detection reduces the user’s dependence on correctly declaring the measurement type and decreases the likelihood of classifying a signal under an inappropriate clinical code. In cases where the statistical detection does not match the type declared by the user in the first step, the system can mark the observation as inconsistent or warn the user, avoiding the creation of FHIR resources with ambiguous semantics. Importantly, this logic is integrated before the construction of the Observation resource, so that observations are only generated when there is consistency between the data in the file and the type of measurement identified.

5.5.3. Construction of the FHIR Observation Resource

Once the CSV file has been validated and the type of measurement determined, the platform builds an FHIR Observation resource that encapsulates the time series of measurements using the SampledData structure. Specifically, the code element of the observation is encoded with LOINC terminologies specific to each type of signal, using codes such as 8867-4 for heart rate, 9279-1 for respiratory rate, 41950-7 for physical activity and 8361-8 for posture, which ensures that the semantics of each observation are recognizable by other interoperable systems. The resource links to the corresponding patient through the subject element, referencing the FHIR Patient identifier and maintaining the explicit relationship between the measurements and the patient’s master record.

The series of values is represented by the SampledData type in the value-SampledData element, which includes parameters such as the initial time, the sampling interval, the unit of measurement, and the sequence of space-separated values, derived from the second column of the CSV file. Additionally, the resource also includes temporary metadata where the date of creation of the observation in the system is recorded, which allows observations to be grouped by upload date in the query interface. When additional information about the device or measurement context is available, this data is incorporated into complementary elements or extensions, strengthening the traceability of observations to the physical origin of the signals.

5.5.4. Clinical Interpretation Calculation and Use of Ranges

In addition to storing the raw signal values, the platform calculates a summarized clinical interpretation for each observation, relying on a configuration file of normal ranges. During CSV file processing, the service determines a representative value of the series, typically the average of the measurements, and compares it with reference ranges specific to each type of signal and LOINC code. Based on this comparison, it assigns a categorical classification, providing an immediate summary of the patient’s condition in the context of that measurement. This interpretation is stored as part of the Observation resource, allowing both the user interface and other FHIR-consuming systems to exploit the information without the need to permanently recalculate clinical ranges. In consultation views, the platform uses this classification to highlight out-of-range observations and make it easier for the professional to quickly identify episodes of tachycardia, bradycardia, respiratory disturbances, or unusual activity and posture patterns. Notably, separating raw data from interpretation criteria into a separate, configured file also allows for adjusting ranges without modifying the system logic, thereby facilitating adaptation to different clinical protocols or target populations.

5.5.5. Error Handling

Error handling during CSV file processing was implemented as a cross-cutting component of the observations module, aimed at preserving data integrity and providing clear feedback to the user in the face of loading failures. If none of the configured encoding schemes manage to decode the file, or if the separators do not allow the expected column structure to be correctly reconstructed, the platform catches the exception, records the failed attempt in the application logs, and displays an error message indicating that the file could not be processed, suggesting verification of the encoding and format of the source file. Similarly, when automatic detection of the measurement type does not produce a reliable classification or is inconsistent with the type declared by the user in the first step of the flow, the system marks the observation as invalid, stops the construction of the FHIR Observation resource, and requests a review of the data, preventing measurements with ambiguous semantics from persisting.

In cases where communication errors occur with the HAPI FHIR server during the POST operation of the observation, the service implements automatic retries with increasing wait times and records each attempt in the log to differentiate transient connectivity problems from structural failures in the FHIR server. To mitigate security risks, the uploaded CSV files are temporarily stored in the application’s working directory and are securely deleted once the observation has been successfully created on the FHIR server or when the process is aborted due to unrecoverable errors, reducing the risk of file accumulation and exposure of sensitive data in the file system. As shown in Figure 5, the complete process for ingesting medical observations demonstrates the integrated workflow from upload to FHIR resource creation.

5.6. FHIR Practitioner Health Professional and Resource Management

The management of health professionals in PIRE was modeled using the FHIR R4 Practitioner resource as a representation of the clinical professional, while the internal user system provides the access credentials and associated security roles. This separation allows for a clear distinction between clinical identity and access identity, while ensuring an explicit link between the two by storing the Practitioner identifier in the user record.

5.6.1. Creation of the Practitioner Resource

The creation of a new healthcare professional in the system is done in an integrated way with the user flow managed by the Super Admin role. When a new clinical user is registered through the user management form, the platform requests personal and professional data such as names, surnames, type and number of documents, contact information, city and department, as well as the specialty or position they hold in the institution. After validating this data, the backend invokes the practitioner_service to build and send a Practitioner resource to the HAPI FHIR server, using a POST operation on the /Practitioner endpoint.

The generated Practitioner resource includes an identifier based on the professional’s document, the full name structured in first and last names, and when available, attributes such as gender, date of birth, entered phone numbers and emails, in addition to the contact address. The specialty or position is represented in the Practitioner’s professional qualification elements, allowing other systems to know the clinical profile of the professional who creates or validates observations and manages patients. Once the resource is created, the FHIR server returns the unique identifier that is stored along with the user in the users.csv file and is subsequently used to associate clinical actions with the corresponding professional, for example, as the creator in biomedical observations.

5.6.2. Integration with the User System

The integration between the Practitioner resources and the user system is based on a direct link through the practitioner_id field stored in the users.csv file, which stores, for each user, the identifier of the associated Practitioner resource in the FHIR service. In this manner, each user account with a role (Doctor, Nurse, or Auditor) maintains a stable reference to the healthcare professional it represents, allowing the platform’s functionalities to retrieve and display clinical information about the professional when necessary. In the “My Profile” view, the system queries the associated Practitioner to present the user with their personal data, document, specialty, and FHIR identifier, reinforcing the transparency of the link between access identity and clinical identity.

This coupling is also used to ensure consistency in the clinical actions recorded on the FHIR server, since observations and other operations can reference the responsible professional through the Practitioner identifier stored alongside the authenticated user. When a user is deleted from the administration interface, the platform executes a cascading process that includes the deletion of the corresponding Practitioner resource on the FHIR server, as well as the removal of its records in users.csv and passwords.csv, logging the entire operation in the audit log to preserve traceability. Consequently, this strategy ensures that no orphan Practitioner resources remain associated with non-existent user accounts and keeps the clinical FHIR repository and the internal user management system aligned.

5.7. System Auditing and Logging

PIRE incorporates an auditing and logging subsystem designed to record, in a structured manner, the critical actions performed by users and the relevant events of the application. This subsystem combines a functional log oriented toward compliance and clinical traceability, stored in the audit_log.csv file, with a technical log in the application logs that allows diagnosing errors, monitoring system behavior, and supporting maintenance tasks.

5.7.1. Logging of Critical Actions

The auditing module was implemented through the AuditManager class of the /auth component, which exposes operations to record and query audit events from a persistent CSV file. Each critical action, such as successful or failed logins, user creation and deletion, and login and logout, generates an entry in audit_logs.csv with structured information about the context of the operation. The audit file format includes fields such as record identifier, user identifier, username, action type, type of resource involved, resource identifier, additional details, source IP address, timestamp, and a success or failure indicator, which allows accurately reconstructing the history of interactions with the system.

High-level functions and clinical service operations invoke the Audit Manager at key points in the flow, ensuring that each authentication attempt or modification of Practitioner resources is recorded. The audit interface, accessible only to the Super Admin and Auditor roles, queries the records through dedicated methods that allow retrieving the last one hundred events, filtering by user or by action type, and displaying the information in a table ordered chronologically. This view provides the responsible team with an immediate tool to review recent system activity, identify patterns of failed access attempts, and support formal auditing or incident investigation processes.

5.7.2. Transaction Traceability and Application Logging

Complementary to the functional audit file, the platform uses an application logging system configured through the utils.logger module, which records general operation events, errors, and security events in an app.log file located in the logs directory. This logger centralizes messages at different severity levels, including information on normal actions, warnings for anomalous situations, and execution errors with context, thereby facilitating problem diagnosis during development, testing, and operation. Among others, events such as connection failures with the HAPI FHIR server, errors in CSV file processing, unhandled exceptions, and relevant security events, such as repeated access attempts with incorrect credentials, are recorded.

The combination of functional auditing and technical logging provides traceability at both the clinical and infrastructure levels. Notably, while audit_log.csv is oriented toward answering questions about who did what, when, and on which action, the app.log file makes it possible to understand how the application behaved internally when executing those actions, what errors occurred, and in what context they appeared. Collectively, this duality facilitates compliance with governance and oversight requirements in clinical management systems, while also providing the technical team with concrete tools for problem resolution, early incident detection, and continuous improvement of the platform.

6. Results

The PIRE platform was evaluated in two complementary dimensions. The first was functional validation, which demonstrates that the system correctly implements the four operational modules necessary for clinical interoperability. The second was performance evaluation, which provides empirical metrics that objectively demonstrate processing efficiency, multi-user robustness, data integrity, and semantic conformity. Success is not defined as the operability of the interface, but as measurable confirmation of interoperability, demonstrating zero data conversion errors, compliance with FHIR in relation to the profiles established in the FHIR CO Implementation Guide, and validated processing latency within clinically acceptable thresholds.

6.1. Function Validation

The PIRE platform implements four operational modules. Patient management involves four important interfaces for creating patients, listing and viewing patients, searching for a specific patient, and deleting patients, thus completing the CRUD process. Biomedical observation management contains three interfaces for creating an observation, listing, and searching for information about a patient’s observations, and deleting patient observations. User and role administration allows the Super Admin to create users, list, and search for users, manage user credentials, and delete users. Finally, audit logging, which has an interface that allows you to view user login or logout logs and the deletion or creation of users. Together, these modules constitute a complete interoperability channel, from raw data capture to FHIR resource persistence. This section describes the results of the clinical data transformation demonstrated by each module during the validation phase.

6.1.1. Patient Management and FHIR Patient Resource Generation

The patient management module allows you to create, search, update, and delete (CRUD) patient records through a structured form that collects mandatory demographic identifiers aligned with Colombia’s FHIR Core CO PatientCO profile. Once the form has been submitted, the platform automatically creates and transmits an FHIR R4 Patient resource via HTTP POST to the HAPI FHIR server. The generated resource incorporates Colombia-specific extensions, including document type identifiers (CC, TI, CE), structured name components (first name/last name), and administrative data (gender, date of birth, telecommunications, address), as required by Resolution 1888 of 2025. During the validation phase, all operations with patient records (creation, search and update by document number, deletion) returned the expected response codes from the FHIR server: HTTP 201 Created for POST, HTTP 200 for GET, and HTTP 204 for DELETE.

Figure 6 illustrates the CRUD process using four interfaces specific to the Patient resources section. Figure 6a shows the interface that displays the form for entering the patient’s mandatory demographic data according to the FHIR CORE CO Patient CO profile. Figure 6b shows the interface for listing patients currently registered on the HAPI FHIR server. Figure 6c shows the interface that is displayed when searching for a specific patient using their identity document number, which also allows patient data to be updated. Finally, Figure 6d shows the interface for deleting a patient from the server, which is done by entering the identity document number.

6.1.2. Biomedical Observation Management

The observation management module constitutes the core clinical data transformation pipeline of PIRE. The workflow proceeds through four sequential stages: observation context definition, capturing the patient ID, biosensor model (Bioharness-3), and measurement type; patient record validation against the FHIR server to ensure subject linkage before data ingestion; clinical context annotation, including measurement method, body site, and free-text clinical notes; and Bioharness-3 CSV file upload and automated FHIR Observation resource generation.

Figure 7 illustrates this complete end-to-end pipeline through four representative system states. Figure 7a shows the CSV upload interface, where the authenticated user uploads the Bio-harness-3 time series file. Before accessing this interface, the user must enter the ID number of the patient being observed and fill in data related to the measuring device (Bioharness-3) and how the data were collected. Figure 7b presents the listing interface, displaying the observations associated with the patient. Figure 7c shows all the data corresponding to the observation made, displaying the data obtained from the CSV file in an organized manner and with an automatic diagnosis based on the average of the measurements obtained. Finally, Figure 7d shows the interface for deleting an observation, where the patient’s ID number is used to search for their observations and select the observation to be deleted.

Each time an observation is successfully created in PIRE, the system automatically builds an FHIR Observation resource that encapsulates the time series of biomedical measurements using the SampledData structure according to R4 specifications. Additionally, each type of signal is encoded with specific LOINC terminologies, using the specific LOINC codes for each measurement, ensuring that the semantics of each observation are recognizable by other interoperable systems. The resource links to the corresponding patient by referencing the FHIR Patient identifier and maintaining the explicit relationship between the measurements and the patient master record. The data value series includes parameters such as the initial instant of the series, the sampling interval in milliseconds, the specific unit of measure for each type of signal, and the space-separated sequence of values derived from the CSV file. Finally, the resource contains all the additional information filled in the form and the diagnosis performed according to the obtained measurements. As illustrated in Figure 8, the Observation resource generated by the PIRE platform demonstrates complete semantic compliance.

6.1.3. User Management and Practitioner Resource Generation

The user administration module, restricted to the Super Admin role, implements a dual-registration process that simultaneously creates an access credential record in the application layer and a corresponding FHIR R4 Practitioner resource on the HAPI FHIR server. The Practitioner resource encapsulates the professional’s demographic data, contact information, specialty, and Colombian document identifier, ensuring that each clinical user has a traceable representation in the interoperability repository. This linkage enables attribution of all clinical observations to specific practitioners, fulfilling the accountability requirements of the Colombian Habeas Data framework. User lifecycle operations include cascade deletion procedures that remove credentials, the associated Practitioner resource, and all audit references, maintaining referential integrity across both the application layer and the FHIR repository.

6.1.4. Audit and Logging System

The audit system interface constitutes the traceability layer focused on recording critical events related to user authentication and application login and logout. The interface presents event records in a chronologically ordered table that shows the last one hundred system events. The table allows authorized users to quickly view recent activity, identify specific events, and detect anomalies such as multiple failed login attempts from the same IP address or unusual patterns of user creation and deletion. This view consolidates in a single access point all access and user management traceability information, thereby turning the audit module into an active component of the governance and security model of the PIRE platform. As illustrated in Figure 9, the audit and logging system interface demonstrates comprehensive transaction traceability.

6.2. Performance Evaluation

The performance of PIRE was evaluated through three complementary experimental protocols. End-to-end latency measurement for different CSV file sizes, stress testing under concurrent access, and verification of data integrity in the CSV-to-FHIR transformation: All tests were conducted against the same deployment used for the functional validation. Each protocol was implemented as an automated Python script that invoked the Flask endpoints over HTTP, recorded detailed timing information, and validated the responses against predefined success criteria.

6.2.1. End-to-End Latency

The latency experiment was designed to quantify the total time required for the platform to receive, transform, and persist a Bioharness-3 CSV file. For each run, the script opened an HTTPS connection to the Flask application, submitted a POST request to the observation creation endpoint with a multipart/form-data payload, and synchronously waited for the HTTP response. The measured latency corresponds to the interval between client-side timestamping immediately before the request is sent and after the response is received, thereby capturing network transfer, CSV parsing, FHIR Observation construction and the subsequent POST to the HAPI FHIR server.

Three CSV file sizes were evaluated to emulate typical and upper-bound usage scenarios: 1 MB files (mean 1.07 MB), representing short monitoring sessions; 5 MB files (mean 5.02 MB), corresponding to the pilot dataset used for integrity testing; and 10 MB files (mean 10.05 MB), approximating prolonged monitoring sessions. For each size, the script executed 10 independent requests with a single active user (sequential execution, no overlap). The input files were generated from real Bioharness-3 exports and truncated or concatenated to the target size while preserving the original column structure. Each run was considered successful only if the Flask application returned HTTP 201, the internal validation reported “Pass”, and the generated Observation could subsequently be retrieved from the HAPI FHIR server.

In addition to the coarse-grained latency measurement, the script captured three fine-grained timing components by inserting server-side timestamps at well-defined points in the Flask pipeline. T_upload_ms, the time spent receiving the multipart file from the client; T_conversion_ms, the time required to parse the CSV, build the Observation resource, and perform semantic checks; and T_POST_ms, the time consumed by the HTTP POST operation to the HAPI FHIR endpoint. The sum of these components corresponds to Time_Processing_ms, as reported in the log.

Table 5. End-to-end processing latency by CSV file size.

Test Type	File Size	N Requests	Simultaneous Users	Mean (ms)	Std. Dev. (ms)	Min (ms)	Max (ms)	Status Code	Success Rate
LATENCY	1 MB	10	1	104.0	9.9	62.4	375.1	201	100%
LATENCY	5 MB	10	1	228.4	7.7	213.7	240.5	201	100%
LATENCY	10 MB	10	1	438.1	14.7	400.7	453.8	201	100%

summarizes the aggregated statistics across the 30 runs. Mean end-to-end latency increased from 104.0 ms for 1 MB files to 228.4 ms for 5 MB and 438.1 ms for 10 MB, with all 30 requests returning HTTP 201 and passing internal validation.

The detailed logs show that T_upload_ms dominates the total processing time (between 40 ms and 430 ms depending on file size), whereas T_conversion_ms remains nearly constant at 0.02 ms and T_POST_ms ranges between 16 and 33 ms. Thus, approximately 90–95% of latency is attributable to network I/O, with the transformation logic itself completing in less than 0.05 ms even for the largest files. This profile indicates that further optimization of the Python transformation code would have marginal impact compared to improvements in network bandwidth or deployment of edge nodes closer to data sources.

Figure 10 plots mean end-to-end processing latency against CSV file size for the three evaluated conditions, with error bars representing ±1 standard deviation. The graph confirms a linear scaling relationship between file size and total processing time, consistent with the complexity expected from a pipeline dominated by network. It is worth noting that the standard deviation for the 1 MB condition (±95.9 ms) is considerably wider than those observed for 5 MB (±7.7 ms) and 10 MB (±14.7 ms). Inspection of the raw logs reveals that this dispersion is attributable to the first measurement of the series (375.1 ms), which is consistent with a cold-start effect in the HAPI FHIR server connection pool; the remaining nine measurements for this file size ranged between 62.4 and 96.0 ms, well within the narrow band observed for larger files. Across all three conditions, mean latency remains below 500 ms, demonstrating that the platform delivers practical processing speeds for real-time clinical data ingestion workflows regardless of file size.

6.2.2. Concurrency Behavior

To characterize how the platform behaves when multiple users issue requests simultaneously, a second script implemented a simple load generator. The script launched pools of worker threads, each thread establishing an independent HTTP session with the Flask application and submitting an observation–creation request using a 5 MB CSV file. All threads were started within a short time window, producing a burst of near-simultaneous uploads towards the same endpoint. As in the latency tests, each worker measured the user-side response time as the interval between request transmission and receipt of the HTTP 201 response.

For this study, two load levels were studied: the first one with a light load of 10 concurrent workers, each sending one request (10 total requests); the second one with a heavy load of 100 concurrent workers, each sending one request (100 total requests). This design approximates realistic scenarios such as multiple clinicians uploading device exports at the end of a shift or automated processes synchronizing several devices at once. The same 5 MB CSV file structure was used in all runs to isolate the effect of concurrency from that of payload size.

Table 6. Concurrency performance for 5 MB CSV files.

Test Type	File Size	N Requests	Simultaneous Users	Mean (ms)	Std. Dev. (ms)	Min (ms)	Max (ms)	Status Code	Success Rate
CONCURRENCY	5 MB	10	10	113.0	14.6	92.0	133.1	201	100%
CONCURRENCY	5 MB	100	100	653.4	320.2	113.2	1239.5	201	100%

reports the aggregated statistics derived from the 110 measurements. Under light load, the mean response time was 113 ms (standard deviation 14.6 ms), with values ranging from 92 to 133.1 ms. Under heavy load, the mean response time increased to 653.1 ms, with a wider dispersion (standard deviation 320.2 ms), and individual responses ranging from 113.2 ms to 1239.5 ms. In both scenarios, the success rate was 100%, and every request received an HTTP 201 status with “Pass” validation.

From a systems perspective, these results indicate that the current architecture sustains a stable throughput of approximately 153 req/s even when the number of concurrent clients increases by an order of magnitude. The trade-off is a predictable increase in response time under heavy load; however, the 95th percentile remains close to one second, which is acceptable for asynchronous ingestion and batch-processing workflows. For large-scale, real-time scenarios, horizontal scaling of the HAPI FHIR backend or distribution across multiple application instances would be the natural next step.

6.2.3. Data Integrity of the CSV-to-FHIR Transformation

The integrity experiment focused on verifying that the values stored in the FHIR observation resources matched exactly the values present in the original Bioharness-3 CSV files. A specific script iterated over a selected dataset of 200 observations generated during the pilot validation. For each observation, the script performed three steps: First, it read the aggregated metric values from the CSV file (Heart Rate, Respiratory Rate, Activity, Posture); second, it retrieved the corresponding observation from the HAPI FHIR server using its identifier; and third, it extracted the same metrics from the FHIR resource and calculated the difference between the CSV and FHIR values.

The 200 observations correspond to 36 simulated patients (PAT-0000 to PAT-0035) with different physiological profiles. Each row of the integrity log contains the patient identifier, the metrics from the CSV file, the metrics retrieved from the FHIR observation, and their differences, along with the HTTP status code and the validation result.

In each of the 200 cases, the difference between the CSV and FHIR values was zero for each of the variables standardized from the CSV file, and all API responses were HTTP 201 with Approved status. No missing records, unit discrepancies, or rounding artifacts were detected.

Table 7. Data integrity verification for 5 MB CSV input (200 observations, 36 simulated patients).

Test Type	File Size	N Requests	Simultaneous Users	Status Code	Success Rate	Heart Rate Error	Respiratory Rate Error	Activity Error	Posture Error
INTEGRITY	5 MB	200	1	201	100%	0% (200/200)	0% (200/200)	0% (200/200)	0% (200/200)

summarizes these findings.

As an illustrative example, Observation #1 for patient PAT-0000 shows a heart rate of 95 bpm, a respiratory rate of 17 breaths/min, an activity level of 0.07 MET and posture with a deviation of 23.2° in the different types of CSV files; the corresponding FHIR Observation stores the same values, with differences of 0 for all three parameters. This pattern is repeated for all 200 observations. Taken together, these results demonstrate that the transformation pipeline achieves perfect semantic fidelity for the metrics evaluated and that PIRE can be used as a lossless bridge between device-specific CSV exports and FHIR-encoded clinical data.

6.2.4. FHIR Semantic Conformance Validation

Beyond verifying that numerical values are faithfully preserved during transformation, a rigorous interoperability system must also demonstrate that the generated resources conform to the structural, terminological, and regulatory specifications that make them interpretable by any compliant FHIR endpoint. To this end, all 200 Observation resources produced during the pilot validation were subjected to a multi-layered conformance evaluation covering five distinct verification categories.

Structural conformance was enforced at ingestion time by the FhirInstanceValidator interceptor module embedded in the HAPI FHIR server, which validates every incoming resource against the core FHIR R4 specification before persistence. The remaining four categories were verified through the Flask middleware layer, which applies programmatic checks prior to submitting each resource to the server: LOINC code correctness (confirming that each signal type carries the exact LOINC code prescribed by the FHIR Core CO Implementation Guide), temporal metadata integrity (verifying that all effectivePeriod timestamps comply with ISO 8601 UTC format [40]), patient reference linkage (ensuring that every Observation.subject references an existing and retrievable FHIR Patient resource), and HTTP transaction success (confirming that each POST operation received an HTTP 201 Created response from the HAPI FHIR server). Each resource must pass all five categories simultaneously to be counted as conformant.

Table 8. FHIR semantic conformance validation results.

Validation Category	Validation Mechanism	Resources Evaluated	Result	Pass Rate
Structural conformance (FHIR R4 core)	HAPI FhirInstanceValidator interceptor	200	200/200	100% (200/200)
LOINC code correctness	Flask middleware pre-submission check	200	200/200	100% (200/200)
LOINC code correctness	Flask middleware pre-submission check	200	200/200	100% (200/200)
Patient reference linkage	Flask middleware pre-submission check	200	200/200	100% (200/200)
HTTP transaction success (201 Created)	HAPI FHIR server response	200	200/200	100% (200/200)

presents the results of this conformance evaluation across the 200 resources, yielding 1000 discrete validation checks in total.

All 200 resources passed every validation category without exception, yielding a cumulative conformance rate of 100%. These results demonstrate that PIRE consistently produces FHIR Observation resources that satisfy both the international R4 base specification and the terminological requirements of the Colombian FHIR Core CO Implementation Guide. Taken together with the data integrity results reported in Section 6.2.3, this evidence reframes the definition of success in this study: platform performance is not measured by the operability of its user interface, but by the verifiable, end-to-end correctness of the clinical data it produces and persists.

7. Discussion

7.1. Convergence with Historical Evolution and the Colombian Regulatory Framework

The development of the PIRE platform responds to more than six decades of evolution in electronic health records (EHRs), ranging from problem-oriented models in the 1960s to contemporary digital health ecosystems that integrate artificial intelligence and real-time monitoring. By focusing on semantic interoperability, PIRE addresses the most critical challenge identified in the literature: ensuring that clinical information, such as vital signs, preserves its exact meaning when exchanged, thereby going beyond the technical and syntactic maturity already achieved by other systems [1].

In the national context, PIRE is firmly grounded in the Colombian legal framework, complying with Law 2015 of 2020 by adopting a mandatory model for the exchange of clinical data [4]. Furthermore, the platform integrates the data elements defined by Resolution 866 of 2021 and anticipates the adoption of the Digital Care Summary (Resumen Digital de Atención, RDA) established in Resolution 1888 of 2025, thus enabling local institutions to align with the national interoperability platform and the Vulcano server [4,5,36]. This strategic alignment is consistent with international experiences, such as those observed in the European Health Data Space (EHDS), where the success of an EHR depends on national architectures that mandate HL7 FHIR-based APIs [14]. In addition, local implementations such as SURA’s, which use cloud architectures to harmonize data from more than 10 million patients, empirically validate the feasibility of PIRE by adopting profiles aligned with the FHIR Core CO Implementation Guide [7].

Despite this strategic alignment, strictly complying with the technical specifications of Resolution 1888 presented significant pain points during implementation. One of the greatest technical challenges was adapting the standard FHIR Patient resource to handle Colombia’s highly specific unique identifier system. Accommodating multiple local identification document types required custom mapping logic in the middleware to enforce local extensions that the native HAPI FHIR server does not support out of the box. Furthermore, dealing with missing required fields in raw biosignal datasets posed a significant hurdle. Because the Digital Care Summary (RDA) mandates strict administrative metadata, the middleware had to implement fallback logic and default namespace assignments to prevent the FHIR server from rejecting clinically valid observations simply due to absent administrative tags.

7.2. Technical Architecture and Biosignal Management

The PIRE architecture, based on a HAPI FHIR server deployed on AWS and the use of HL7 FHIR R4, aligns with the view that FHIR is the essential standard for harmonizing biomedical data and enabling clinical decision support tools [16]. In particular, PIRE’s ability to process patient-generated health data (PGHD) using the Bioharness-3 device is supported by studies demonstrating the feasibility of integrating continuous metrics into real clinical workflows through FHIR Observation resources. By encapsulating heart rate, respiratory rate, activity, and posture signals using the SampledData structure combined with LOINC terminologies, PIRE ensures that the semantic meaning of each measurement is universally recognizable across interoperable systems. This approach is analogous to implementations that employ Garmin devices or open-source ESP32 microcontrollers to acquire real-time signals such as ECG and PPG, which are subsequently mapped to FHIR resources [30,31,32,33,34,35]. Moreover, the use of data validators compliant with FHIR Core Colombia, together with a comprehensive logging system, reinforces the integrity of the resources created in PIRE, thereby mitigating the risk of transcription errors or malformed data that could compromise patient safety.

7.3. Security Models and Implementation Lessons

Regarding security governance, PIRE currently relies on standard HTTPS and Basic Authentication paired with a role-based access control (RBAC) model. While this effectively balances security needs with operational simplicity for the platform’s initial academic scope, we explicitly acknowledge that the full OAuth 2.0 and SMART on FHIR authorization flows, which are standard requirements for production-level third-party integrations, have not yet been implemented. Furthermore, relying solely on static roles constitutes an additional recognized technical debt for future deployments. In actual clinical settings, static roles (assigning a generic “physician” or “nurse” permission) are fundamentally insufficient for protecting patient privacy under strict national regulations like the Colombian Habeas Data law. A real-world clinical scenario requires dynamic, context-aware authorization. For instance, a physician should only be authorized to access a patient’s biosignals if they are the actively treating physician, during their specific clinical shift, and provided that the patient has granted explicit consent.

Attribute-Based Access Control (ABAC), as proposed by authors like Mukherjee et al. [24], provides this maximum granularity by evaluating multiple dynamic variables (user attributes, resource tags, environmental context, and consent status) in real time. Resolving this technical debt will require implementing complex Policy Decision Points (PDPs) and dynamic consent management modules within the PIRE middleware. However, unlike implementations that prioritize only technical connectivity, PIRE deliberately adopts a socio-technical perspective. Following findings from similar deployments [18], the platform assumes that useful interoperability must carefully balance this necessary security evolution with the availability and maintainability of records to support real-time clinical decision-making.

7.4. Limitations and Operational Responsibilities

While PIRE presents a robust reference architecture, several limitations and operational realities must be acknowledged. First, the reliance on cloud infrastructure (such as AWS) introduces ongoing financial maintenance costs and requires institutions to have specialized cloud engineering expertise. Furthermore, adopting a self-hosted architecture based on foundational open-source components (like HAPI FHIR) shifts the burden of server maintenance, security patching, and system updates directly to the implementing institution, unlike proprietary enterprise solutions that include guaranteed vendor support. However, this maintenance responsibility is a calculated trade-off. By avoiding proprietary black-box software, architectures like PIRE promote technological sovereignty. This paradigm empowers healthcare institutions and their local engineering teams to design and adapt their interoperability middleware to strictly comply with specific regional regulations without the restrictive barriers of vendor lock-in.

8. Future Work

The current implementation of PIRE lays the groundwork for several avenues of future research and development, particularly in the areas of advanced analytics, security, and usability.

8.1. Advanced Analytics and Data Exploitation

From a public health perspective, the structured biosignals collected by PIRE lay the foundational dataset necessary for future predictive modeling, such as anomaly detection algorithms for remote monitoring [41]. To facilitate this, future work will focus on the adoption of the SQL-on-FHIR standard. This will allow nested FHIR server information to be projected into tabular views, enabling large-scale statistical analyses without the need to process complex JSON structures, thereby opening the door to studies linking clinical records with geospatial environmental data [7,29].

8.2. Enhanced Security and Governance

To further strengthen distributed security, future iterations of PIRE aim to migrate from the current RBAC model toward Attribute-Based Access Control (ABAC) and Self-Sovereign Identity (SSI) frameworks. This evolution is critical as direct data exchange becomes more common, enabling patients to become true owners of their data [24,25]. The implementation of smart contracts within environments such as Hyperledger Fabric is also being considered to ensure transparent and auditable management of records, allowing for selective disclosure of information in compliance with Colombian Habeas Data regulations [25].

8.3. Usability and Data Transformation

Finally, to address the complexity of data ingestion, future work will focus on replacing manual CSV processing pipelines with visual tools like TermX and the FHIR Mapping Language (FML). This shift aims to reduce the error-prone nature of manual coding [12]. On the frontend, the implementation of visual questionnaire editors is planned to further reduce cognitive overload for clinical staff, ensuring that organizational barriers to adoption are minimized through improved user experience [18,42].

9. Conclusions

The development of PIRE represents a significant milestone in operationalizing semantic interoperability within the Colombian regulatory context. By demonstrating that a fully functional end-to-end FHIR architecture is viable in controlled academic environments, utilizing open-source technologies and explicitly aligned with the Core Colombia profiles, PIRE closes a critical gap between the legislative mandates of Law 2015 of 2020, Resolution 866 of 2021, and Resolution 1888 of 2025, and the actual technical capacity of Colombian health institutions to implement them. This alignment is not merely academic, as it validates that medium-sized institutions, which represent the majority of the private health sector in Colombia, can transition toward regulatory compliance by significantly lowering the initial licensing barriers to entry compared to proprietary solutions, providing a more accessible baseline for standards adoption.

The integration of patient-generated health data through commercial wearable devices such as the Bioharness-3 within a native FHIR architecture significantly expands the scope of what constitutes “interoperable data.” Specifically, PIRE’s capability to encapsulate continuous metrics under standardized LOINC terminologies, while simultaneously preserving the semantics of measurement, resolves a challenge that has not been adequately addressed in prior FHIR literature. This is particularly relevant for remote care models and chronic patient monitoring that are emerging as central components of the ongoing Colombian health system reform.

However, the current validation of PIRE operates within clearly circumscribed limitations. The pilot was conducted in a controlled academic environment with stable network infrastructure, standardized devices, and trained operators—conditions that do not represent the heterogeneity of real clinical settings. The robustness of PIRE in the face of electromagnetic interference, network bandwidth variability, and multiple generations of wearable devices requires additional empirical validation. Equally important, although PIRE currently implements a robust role-based access control (RBAC) model, the evolution toward more granular control models (ABAC) and the integration of self-sovereign identity frameworks are anticipated to become necessary as data exchange becomes decentralized in direct patient-to-researcher or institution-to-institution scenarios. Finally, while PIRE reduces initial software licensing barriers, deploying this architecture in production entails a Total Cost of Ownership (TCO) that institutions must consider, including ongoing cloud infrastructure expenses and the specialized engineering labor required for system maintenance and security compliance.

From the perspective of the Colombian health system, PIRE provides three immediate contributions. First, a reproducible reference model that medium-sized institutions can adapt to operationalize IHCE compliance without requiring prohibitive capital investments. Second, technical evidence that clinical semantics can be preserved across data exchange without introducing clinically problematic latency. Third, a demonstration that Colombian regulatory mandates are technically implementable within standard FHIR frameworks, thereby reducing the risk that adoption would require interim solutions that compromise interoperability.

The limitations identified—including validation in controlled environments only, the absence of comparative clinical utility studies, and partial integration of distributed security frameworks—define a clear research agenda for subsequent phases. The transition of PIRE from an academic prototype to an operational platform in pilot institutions would require rigorous clinical validation of the equivalence between wearable measurements and clinical standards, evaluation of socio-organizational effects on clinical workflows, and security hardening in accordance with international cybersecurity standards for health. These investigations must be conducted with rigor equivalent to that applied in the technical validation.

In conclusion, PIRE not only closes a technical gap in the implementation of semantic interoperability in Colombia, but also repositions the Colombian academic digital health community as a generator of evidence regarding how middle-income health systems can operationalize regulatory transformation in a technically rigorous and economically viable manner. As Colombian health institutions advance along their respective IHCE compliance timelines, PIRE provides both a technical model and an institutional model for how academic research can catalyze health system transformations at the national scale. Ultimately, this work demonstrates that semantic interoperability is not a privilege of wealthy systems but a technically achievable and economically justified goal for health systems committed to evidence-based, standards-driven transformation.