Abstracts from EHRCON25—openEHR International Conference 2025

BMC Proceedings 2026, 20(12):A1

openEHR archetypes provide a rich semantic foundation for structured clinical data [1,2], yet most clinical documentation and modelling tasks begin with narrative text. Bridging the semantic gap between free-text clinical expressions and formal archetype structures remains a major challenge for scalable semantic interoperability and clinical knowledge engineering. Existing tools such as the openEHR Clinical Knowledge Manager (CKM) Resource Finder [3] rely primarily on keyword-based search and struggle with synonymy, abbreviations, and contextual language commonly used in clinical narratives.

We developed a Retrieval-Augmented Generation (RAG) pipeline that maps narrative clinical input to candidate openEHR archetypes and their internal data elements. The approach combines clinical entity extraction with hybrid lexical–semantic retrieval over an attribute-weighted index of archetypes sourced from CKM. Archetypes are decomposed into granular semantic units and indexed using BM25-based keyword search [5] alongside neural vector embeddings. Attribute-level weighting prioritises clinically meaningful metadata, enabling context-aware archetype and data element recommendations while reducing reliance on manual archetype exploration.

The pipeline was evaluated on 800 narrative clinical queries derived from documentation and production systems, each mapped to a gold-standard set of CKM archetypes. Compared with CKM Resource Finder and zero-shot GPT-4.1 prompting, the proposed approach achieved substantially higher archetype recall (0.73 vs. 0.53 and 0.44, respectively) and improved precision. These results demonstrate that hybrid retrieval [4] combined with fine-grained indexing more reliably identifies semantically relevant archetypes within the top-ranked results, supporting practical clinical modelling workflows and reducing the need for manual archetype exploration in tools such as Archetype Designer [6].

Hybrid lexical–semantic retrieval with Retrieval-Augmented Generation provides an effective mechanism for binding narrative clinical language to structured openEHR archetypes. By improving recall and precision over existing tools, the proposed pipeline accelerates clinical modelling, template design, and semantic validation while maintaining consistency across openEHR implementations. This approach supports scalable clinical knowledge engineering and reduces the manual effort required to translate narrative intent into formal clinical models.

BMC Proceedings 2026, 20(12):A2

Finally, a generic export tool based on the Minimum Information About BIobank data Sharing (MIABIS) [13] model was created to retrieve data via Archetype Query Language (AQL) and convert it into the standard formats supported within the BBMIR-ERIC infrastructure, Health Level 7 Fast Healthcare Interoperability Resources (HL7 FHIR) [14] and Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) [15] formats. Where possible, nodes were linked to OMOP standardized vocabulary.

The export functionality to FHIR and OMOP CDM was validated, see Fig. 3. This process maintained semantic integrity while enhancing data quality through systematic cleansing. All software components, models, and documentation were released as open source [11,16,17].

This work was supported by: the H2020 EOSC-Life (grant number 824087) WP1 Demonstrator “Cloudification of BBMRI-ERIC CRC-Cohort and its Digital Pathology Imaging” (APPID 1228); the BBMRI-ERIC Common Service IT; the Sardinian Regional Authority [projects: XDATA; ToPMa, grant ID: RC CRP 077].

BMC Proceedings 2026, 20(12):A3

The World Health Organisation (WHO) developed the Digital Adaptation Kit (DAK) for Antenatal Care (ANC) to assist countries to implement WHO recommendations in digital systems [1, 2]. openEHR enables the standardized representation of data elements in a computable format [2].

The openEHR modelling approach would provide a semantic data model for ANC that can provide clinically rich data. This approach ensures that clinical data can be structured and interpreted consistently across various systems and platforms.

The core data dictionary of the DAK was utilised for the mapping exercise [1]. The mapping exercise was completed using direct mapping of the data elements utilising the input method, data type, input options and collection frequency specified in the Excel® document. The direct mapping approach was chosen to maintain fidelity to the original DAK structure.

The translation of the DAK was used to develop templates that can be adapted to support the implementation of country-specific, vendor neutral ANC records.

A total of eight hundred and seventy-nine (879) individual data elements were extracted from the DAK.

Sixty-two (62) archetype s were used to develop the template for the ANC record. Of the archetypes used, thirty-six (36) were published, twenty-two were drafts, two (2) were initial or pre-draft and two (2) were under review. Two (2) new archetypes were proposed from the mapping exercise; Birth Plan Preference archetype and an Audit Administrative archetype.

The mapping to the non-openEHR source was achieved almost entirely through reuse of the existing archetype library (Fig. 1).

Although OpenEHR archetypes can be used to map the DAK with a high level of accuracy and completion, the output is limited in its utility as a primary patient record and providing persistent information for clinical decision making.

Ninety-eight percent (98%) of the data elements list in the DAK could be mapped to existing archetypes in the CKM. This strongly demonstrates both the maturity and the generalizability of the archetypes.

A second mapping exercise will be completed for semantic optimisation of the ANC templates.

BMC Proceedings 2026, 20(12):A4

The increasing demand for structured high-quality clinical data for AI and decision support systems highlights the shortcomings of current healthcare data infrastructure, particularly its misalignment with FAIR [1] data principles (Findable, Accessible, Interoperable, Reusable). In radiotherapy, clinical information is fragmented across systems, each with its own data model. This heterogeneity limits secondary data use for applications like research, business intelligence, and AI. Although existing standards like DICOM [2] provide extensive technical imaging and treatment delivery persistence capabilities, the clinical context (e.g. diagnosis, toxicity, treatment intention) is not covered. openEHR has emerged as a promising solution, offering semantic consistency through archetype-based modeling and growing interoperability with standards like OMOP and FHIR [3]. This study aimed to evaluate openEHR as a unified data platform for radiotherapy at Isala.

An open-source infrastructure was implemented using EHRbase (openEHR backend), Keycloak (auth), and Snowstorm (terminology server), all deployed with Docker (Fig. 1). A Python-based ETL (extract, transform, load) pipeline was developed to extract and transform data from Mosaiq using SQL queries into openEHR Flat JSON, using mock patient data for validation. Clinical modeling was informed by the international CKM (Clinical Knowledge Manager), available literature [4–7], guided by consultations with domain experts, and collaborative workshops at Isala.

The EHRbase/Keycloak/Snowstorm stack provided a functional prototype for FAIR-compliant data persistence, though setup required considerable (technical) effort due to limited documentation. The ETL process exposed the current institution-specific nature of radiotherapy data, requiring institutespecific mappings and limiting reusability. Mapping codes proved difficult due the absence of 1:1 mappings as one ICD-10 code may correspond to multiple SNOMED CT concepts. Existing openEHR archetypes did not fully cover the project requirements, particularly in representing adaptive treatments, nested targets, and dose-volume relationships. A preliminary template based on existing “Procedure” and “Irradiation” archetypes was developed, and a custom archetype was created to address data model gaps.

openEHR is a viable solution for structuring radiotherapy data for secondary use, but current archetypes fall short in modeling its full complexity. The creation and validation of a common data model with other institutions and international consensus is essential for standardization and broader adoption. Even though few vendors are active in the domain, institution-specific models require the creation of mappings per institute. While the technical foundation is in place, future work must assess usability by clinicians, researchers, and data scientists to fully validate the data platform.

We would like to thank Chris Ootes for the technical support and access to infrastructure provided during this project.

BMC Proceedings 2026, 20(12):A5

Developing and maintaining openEHR archetypes and templates is complex and involves multiple development and publication platforms. The interplay between tools like Better Archetype Designer (AD), Clinical Knowledge Manager (CKM), and Clinical Data Repositories (CDR) creates significant challenges in version management and template validation. To streamline these processes, our team has developed a suite of in-house applications tailored to our workflow.

A bottom-up, needs-driven development strategy was applied. Pain points were identified in versioning, dependency management, and validation of openEHR archetypes and templates within the group’s workflow (Fig. 1), adapted from Moner et al. [1].

After defining requirements, targeted Python applications were developed to address each bottleneck. Validation and testing were performed to ensure solutions met requirements. Software is distributed in-house via a private Confluence domain as executables. Reports are published as HTML files. Adaption and satisfaction in the modelling team was measured with an anonymous survey.

The applied methodology enabled identification of the workflow steps and all platforms involved in openEHR archetype and template development. Seven relevant pain points were identified across archetype management, publication, deployment, and validation stages (Fig. 1). Targeted software solutions were developed to address these pain points, ranging from HTML data visualization to executable programs. Examples of the software have been published online, such as the CKM Visualization [2] and the AQL Manager [3]. Adoption of these solutions has been partial: Of 10 team members, 7 responded to the questionnaire. Five reported using at least one in-house software solution, expressing satisfaction and noting improved work efficacy. The two non-users indicated the tools are not currently needed for their workflow steps.

In-house software solutions were successfully developed to address workflow pain points in openEHR archetype and template development. Easy accessibility and readability of reports were important for adoption by the modellers. Partial adoption and positive feedback demonstrate the usefulness of these solutions in the development, management, and validation of archetypes and templates. Publishing these tools as open source should be considered to maximize their impact and benefit the wider openEHR community.

BMC Proceedings 2026, 20(12):A6

The reuse of routinely collected electronic health record (EHR) data for research depends on reliable transformation into standardized research data models. The Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is widely adopted for observational research, but transforming data from openEHR-based systems into OMOP remains technically complex and resource-intensive. Eos and the OMOP Conversion Language (OMOCL) were previously introduced [1] to support archetype-driven transformation from openEHR to OMOP, but limitations remained regarding terminology coverage, visit construction, and mapping completeness.

We extended OMOCL and the Eos Extract Transform Load (ETL) engine to address these limitations. OMOCL was enhanced with conceptMaps to enable mapping of internal openEHR archetype value sets to OMOP standard vocabulary concepts. Eos was updated to support visit occurrence generation based on Archetype Query Language (AQL), allowing visits to be derived flexibly from different openEHR implementations. In parallel, the international OMOCL mapping library was systematically expanded through a community-driven effort. The resulting mappings were evaluated to assess coverage, terminology alignment, and semantic loss during transformation.

ConceptMap support enabled the transformation of internal archetype codes that are not typically annotated in international terminologies, improving semantic preservation for observations and measurements. ConceptMaps were added to existing mappings when possible. AQL-based visit generation allowed visits to span full healthcare encounters rather than individual compositions, increasing adaptability across openEHR platforms. The mapping library was expanded to cover 196 published archetypes. Evaluation showed that 8.65% of core OMOP concept fields could not be mapped to a valid standard concept and were assigned to zero, reflecting gaps in OMOP-supported vocabularies. Structural differences between openEHR and OMOP led to partial loss of contextual information and qualifiers, particularly where multiple clinical attributes must be collapsed into single OMOP fields.

The presented enhancements substantially improve the coverage, flexibility, and semantic quality of transformations from openEHR to the OMOP CDM, lowering barriers to secondary use of openEHR data in OMOP-based research. Nevertheless, persistent limitations in terminology alignment and model expressiveness result in unavoidable semantic loss. For research requiring fine-grained clinical context, direct use of openEHR data may remain preferable. Continued alignment between openEHR and OMOP communities is essential to support high-quality reuse of clinical data.

BMC Proceedings 2026, 20(12):A7

AI health agents using Large Language Models (LLMs) have demonstrated remarkable capabilities in healthcare applications. However, concerns regarding patient confidentiality, data protection, and network dependency have created demand for privacy-preserving alternatives. While edge-based healthcare AI solutions have been deployed to address these concerns, none have integrated openEHR [1] standardized structures, leaving a critical gap given openEHR’s growing adoption as the framework for interoperable health data across healthcare systems. Recent advances in model compression and mobile hardware now enable Small Language Models (SLMs) with billions of parameters to operate on consumer smartphones, presenting a unique opportunity to combine openEHR’s vendor-neutral approach with on-device privacy preservation.

We evaluated two SLMs: TinyLlama [3] (1.1B parameters) and Phi3-mini-4k [4] (3.5B parameters), both with INT4 quantization. System performance was measured on Google Pixel 6 (CPU). Response quality was assessed using G-Eval [5] methodology with LLM-as-a-judge (Gemini-2.5-pro) [6], evaluating clinical quality and faithfulness against cloud-based LLM responses. We tested both document-level and chunked retrieval strategies across simple and complex query categories.

The larger SLM (Phi3-mini-4k) achieved higher scores on both clinical quality and faithfulness dimensions, demonstrating greater alignment with cloud-based LLM responses. However, SLMs exhibited context prioritization limitations, occasionally omitting critical clinical details such as emergency management information, as illustrated in the side-by-side comparison between SLM and cloud LLM outputs (Fig. 2).

System performance metrics (Table 1) confirm viability on consumer devices, with TinyLlama requiring 0.94 GB memory at 9.04 tokens/second, while Phi3-mini-4k required 2.7 GB at 3.6 tokens/second.

Our work demonstrates feasibility for deploying privacy-preserving health AI agents entirely on mobile devices using standardized openEHR data. While SLMs show promising performance, domain-specific fine-tuning could improve comprehensive clinical documentation. Future work includes openEHR server integration for data synchronization and refined verbalization methods. This research establishes foundations for ubiquitous, privacy-focused AI health agents operating entirely on personal smartphones, ensuring patients retain portable health intelligence across providers and locations.

This research was partly funded by the Slovenian Research Agency grant no. N20393 “approXimation for adaptable diStributed artificial intelligence” and grant no. J2-3047 “Context-Aware On-Device Approximate Computing”.

BMC Proceedings 2026, 20(12):A8

The wealth of information contained in genomic datasets holds great promise for improving medical care; however, their reuse and interoperability remain challenging due to data complexity, incompatible standards, and the continuous evolution of technologies and reference resources. The openEHR Genomics Project [1] was created in 2019 to build machine-readable models of genomic concepts that could preserve semantics, capture data provenance, and ease the integration with heterogeneous data (e.g., clinical, imaging, environmental information).

openEHR was the approach selected to represent genomic data, as it enables a fine-grained data capture, the unambiguous definition of semantics, and the recording of essential provenance information through the inner structure of the archetypes. An international team of experts across bioinformatics, medicine, and health IT conducted the data modeling through periodic virtual meetings and community-based content reviews, drawing the core archetypes out of the Variant Call Format (VCF) specifications [2] and the HGVS Nomenclature [3], two commonly used standards for reporting and describing sequence variations.

The meaning of each node was precisely stated, and, where possible, formalized using domain-specific nomenclatures (e.g., HUGO for gene symbols) and standardized terminologies (e.g., LOINC, SNOMED-CT). Free-to-use tools such as Xmind¹ (for mind mapping) and Archetype Designer² (for modeling) were employed, while review sessions and model versioning were managed directly through the openEHR Clinical Knowledge Manager³ (CKM).

The resulting archetypes capture findings and annotations related to genomic variants identified in a human individual, along with auxiliary models describing the external references used during sequencing. To date, the following 16 archetypes are publicly available in the CKM:

The models are comprehensive yet flexible, supporting both complex research use cases, which require tracking of tools, pipelines, and parameters, and streamlined clinical applications that demand only essential information. Some models and how they could be combined in a report are shown in Fig. 1.

The openEHR Genomics project is an ongoing initiative that welcomes contributions, including new use cases to validate the models, participation from domain experts in development and refinement, and efforts to align with other domain standards. Interested parties are encouraged to adopt the available archetypes and engage with the openEHR Genomics group to participate in the review and development process.

This work has been partially supported by the ToPMa project, funded by the Sardinian Regional Authority (G.A. RC CRP 077).

BMC Proceedings 2026, 20(12):A9

This work addresses a core operational challenge in openEHR Clinical Data Repositories (CDRs): executing operational single-patient and cross-patient queries at scale with low and predictable latency. openEHR separates a stable Reference Model from domain archetypes and templates; the primary unit, the composition, is a hierarchical clinical document whose nodes are addressable via Archetype Query Language (AQL) paths. Many relational implementations of openEHR persist compositions as a mixture of JSON columns and “shredded” rows [1]. This is effective for single-patient retrieval, but often weaker for large-scale cross-patient workloads. Yet modern applications increasingly need near–real-time cross-patient queries during care delivery, such as finding patients by condition, identifying cohorts that meet safety or protocol criteria, and supporting AI-assisted clinical decision support. Data warehouses are well suited for retrospective analytics, but offloading operational cross-patient queries introduces latency and duplication, breaks a unified AQL endpoint across workloads, can lose clinical context when documents are flattened (e.g., temporal order, units, provenance, containment paths), and fragments security and audit trails.

We present a document-first openEHR persistence layer on MongoDB that stores canonical compositions as single JSON documents and materializes a compact node array per composition. Each node retains its clinical subtree and positional metadata and is annotated with a reversed AQL path to enable index-friendly matching for variable-depth paths. This enables deterministic AQL-to-MQL (MongoDB Query Language) compilation, extending prior AQL-to-MongoDB interpreter work [2]. FROM/CONTAINS/WHERE constraints compile into targeted predicates over node paths and values. The design uses dual indexing: (i) for patient-filtered queries, a compound B-Tree index on (ehr_id, reversed_path) enables shard-local lookups; (ii) for cross-patient queries, a Lucene-style search index over selected node paths and values compiles AQL path constraints into wildcard matches on the reversed path and compiles node conditions into range and equals operators.

We evaluated the approach on a sharded MongoDB Atlas cluster using a de-identified export from a real openEHR CDR, scaled to one billion compositions. End-to-end API latency remained low and stable for both single-EHR and cross-patient queries (Table 1). This provides a viable, cost-effective alternative for next-generation openEHR CDRs and a clear path to inline provenance, semantic enrichment, and AI-driven use cases.

BMC Proceedings 2026, 20(12):A10

Semantic interoperability between research and clinical systems is essential for advancing personalized medicine and ensuring long-term reuse of patient data. However, research studies often rely on heterogeneous sources, such as REDCap, wearable devices, and institutional silos, leading to inconsistent representations of clinical concepts. In the Inflammatory Bowel Disease (IBD) cohort of the Clinnova project, a cross-border European initiative, electronic Case Report Forms (eCRFs) are implemented in REDCap [1], and corresponding openEHR templates are designed to support interoperability [2]. To transfer data from REDCap’s flat data model into the hierarchical structure of openEHR compositions, a scalable Extract-Transform-Load (ETL) pipeline using Apache NiFi has been developed [3].

Each REDCap event is represented by a dedicated openEHR template aligned with the structure of the corresponding eCRF. Instruments are mapped to appropriate archetypes, and repeating instruments are modeled using recurring archetype nodes (Fig. 1). To compensate for REDCap’s lack of built-in form versioning, a versioning attribute is added to the templates to record the evolution of each form. Additionally, the openEHR FEEDER AUDIT class is included to store the original REDCap JSON, instance URL, and software version for full traceability.

The ETL architecture begins with a NiFi pipeline that retrieves data for each event and instrument via the REDCap API and stores it in a data lake. The next components are the transformation and loading pipelines, which are also implemented in NiFi. One pipeline maps REDCap data into structured, hierarchical openEHR compositions, while the other loads compositions into the repository via the openEHR REST API (Fig. 2).

The transformation process operates on two types of JSON files: (1) Instrument Template JSON (ITJ), a static file defining a segment of the openEHR template with mappings to variable names in a REDCap instrument; (2) Event Instance JSON (EIJ), dynamically generated from the data lake, contains contextual metadata and patient-specific values for a REDCap event. The pipeline dynamically selects and combines relevant ITJs based on contextual metadata and substitutes patient-specific values from the EIJs to construct complete composition payloads (Fig. 3).

The loading pipeline interacts with the openEHR REST API. For each patient, it first verifies the existence of an EHR record and creates one if needed. For each composition payload, it checks whether the entry is new, either because it has not been previously created or because it represents a new version of a previously captured REDCap form. If so, a new composition is created. Otherwise, it compares the payload with the stored composition using MD5 hash values. Updates are only performed when differences are detected, to avoid redundant writes (Fig. 4).

The proposed solution enables dynamic generation of openEHR compositions by combining ITJs with contextual metadata and patient-specific values from EIJs. Content-based versioning using MD5 hashing, along with multiple validation steps, prevents redundant writes and ensures that only one composition is created per patient per REDCap event. Designing templates based on community-standard archetypes from Clinical Knowledge Manager (CKM), and aligning them with REDCap events and instruments, enables reuse of both templates and data pipelines across cohorts. Implementing the workflow in Apache NiFi provides a flexible, modular, scalable, and fully traceable orchestration framework.

This architecture bridges REDCap-based data collection with the openEHR model, enabling standardized and reusable representations of clinical concepts. Implementing the workflows in Apache NiFi provides modular and configurable pipelines that can be easily adapted and adopted by external teams and institutions.

BMC Proceedings 2026, 20(12):A11

Accessing and combining clinical data across openEHR (archetype-based electronic health records) [1] and HL7 Fast Healthcare Interoperability Resources (FHIR) systems [2] remains challenging for clinical users, as meaningful queries require detailed knowledge of APIs, data models, and query languages. Model Context Protocol (MCP) [3] provides a standardized mechanism for language models to interact with external tools, but applying MCP to healthcare systems reveals practical limitations, including ambiguous tool selection, platform-imposed limits on the number of tools per agent, and repetitive tool-calling loops caused by insufficient semantic understanding.

We designed a hierarchical multi-agent interoperability framework that coordinates openEHR and FHIR systems via MCP. A central orchestrator agent interprets clinical intent and executes declarative YAML-defined workflows with explicit sequencing and error handling, while specialized agents handle openEHR and FHIR operations using curated, domain-specific tool sets. The overall system architecture is shown in Fig. 1. To reduce semantic complexity in openEHR access, openEHR JavaScript Views (predefined clinical data projections) were employed as reusable templates for common clinical data retrieval patterns, minimizing reliance on ad-hoc Archetype Query Language (AQL) generation.

Compared with single-agent approaches, the distributed architecture reduced incorrect tool selection and eliminated repetitive tool-calling loops by enforcing explicit workflow steps. Partitioning tools across specialized agents enabled broader functional coverage while operating within platform constraints. Agent role separation and responsibilities are summarized in Fig. 2. The use of openEHR JavaScript Views improved reliability and consistency for recurring clinical queries by standardizing data access patterns while preserving formal clinical semantics [4].

Hierarchical multi-agent orchestration combined with declarative workflows provides a practical and reliable pattern for coordinating resource-based (FHIR) and archetypebased (openEHR) systems through MCP. Explicit architectural design, rather than emergent tool use, is essential for clinically safe and semantically accurate healthcare interoperability. This framework supports natural language access to heterogeneous healthcare data while maintaining transparency, reproducibility, and clinical oversight.

The authors acknowledge the openEHR and HL7 communities for ongoing collaboration that enables interoperable healthcare systems.

BMC Proceedings 2026, 20(12):A12

PROMs are increasingly used to incorporate patients’ perspectives into healthcare delivery. Electronic PROMs (ePROMs) enable remote collection and allow the incorporation of health data directly into electronic health records through standards such as openEHR. However, challenges remain regarding their implementation, particularly in primary care, where patient diversity varies widely. In Catalonia, ePROMs have been progressively implemented since November 2022 with a particular focus on primary care. ePROM results were encoded into openEHR archetypes for primary use and relational databases for epidemiological investigation. This study aims to describe ePROMs administration and usage within the Catalan Health System and the key determinants influencing their adoption by both professionals and patients.

We conducted a retrospective, population-based cohort study using administrative data from the Catalan public healthcare system. The description of the implementation included all ePROMs administered between November 2022 and October 2024. Analyses of staff and patient-related factors focused on the period from November 2023 to October 2024, when system improvements were implemented.

Descriptive statistics and plots summarised trends in administration and usage. Bivariate tests and multivariate models were used to identify predictors of administration volume and patient response. Analyses were performed using R. Ethical approval was obtained, and data were anonymised in accordance with GDPR.

Between November 2022 and October 2024, 789,294 ePROMs (among 42 different validated questionnaires) were administered. Administration varied widely across PROMs: some instruments showed rapid uptake shortly after implementation, while others remained scarcely used over time. The overall completion rate was 78.5%, with 48.5% of ePROMs completed within one day. Completion rates varied notably across thematic areas, from 85.6% in social support to 6.6% in oncology.

Between November 2023 and October 2024, 685,130 ePROMs were administered by 11,094 professionals. Professional age, gender, territorial socioeconomic index (SI) and rurality were associated with ePROMs administration. Nurses, physiotherapists, dietitians, and mental health professionals also had higher administration volumes than physicians.

Regarding patient response, 417,051 individuals received at least one ePROM. Most received only one (66.8%), with a completion rate of 88.1%. High responders (≥ 80% completion) represented 76.7% of patients. Response rates were particularly associated with administered ePROMs per patient, and weaker associated with gender, age, morbidity, SI and rurality. Only 10.5% of completed ePROMs were answered via the patient portal (LMS), more frequently among middle-aged patients and those with high socioeconomic status.

The implementation of ePROMs in Catalonia demonstrates strong engagement, especially in primary care and among nursing and community health professionals. While overall completion rates are high, usage varies by clinical profile and patient characteristics. Notably, 10.5% of responses were submitted via the patient portal, highlighting limited digital channel adoption and the need to strengthen patient-facing tools. Our findings can inform targeted strategies to improve ePROMs administration and usage. Additionally, the large volume of structured data recorded using openEHR standards offers significant potential for secondary use in research and health system planning.

BMC Proceedings 2026, 20(12):A13

Decommissioning of large-scale Electronic Health Record (EHR) systems presents challenges like preserving data while ensuring continued, clinically useful access to it when the originating system is shut down. We present a practical approach for migrating clinical data:

An important goal is that the end users of the platform should from the start be able to access the records in a familiar manner, but “under the hood” now via standards like openEHR and FHIR in a new platform so that the old system can be shut down without clinical disruption. We believe that the approach is suitable also for other legacy EHR systems.

A Proof of Concept" (PoC) in three months using a handful of full-time equivalents of consultants and hospital staff succeeded (via API) in automating the transfer of medical record text, medication prescriptions, clinical chemistry lab results, measurements, activities, etc., from TakeCare, to an EHR platform based on open standards such as openEHR and FHIR. During the same period, user interfaces were built in the EHR platform that mimicked the structure and functions (including the filtering system) of TakeCare so that healthcare professionals would feel familiar and could use the same types of filtering and workflows as before. Having fine-grained, multifaceted filtering available is much more useful to clinicians than just a word-based search in a set of PDF files that other archiving methods often provide. In Sweden EHR data needs to be made available for at least 10 years, but for both clinical and research use we would like to keep it much longer – keeping TakeCare in “read-only” mode, including maintaining its integrations to national services during 10 years is less attractive than conversion from cost, IT-security and clinical/research utility perspectives, especially when considering that we are anyway moving towards an openEHR + FHIR based EHR landscape in Region Stockholm.

Conversion methods were chosen depending on sources, targets and what was reasonable, technically, informatically, and resource-wise as illustrated in (Fig. 1):

Much of the modelling challenge was in analysing where it was possible to make use of international CKM archetypes vs. when GENERIC_ENTRY ‘integration’ archetype-based templates were required [1]. A particular challenge was a proprietary (TakeCare) template format that was based on an internal terminology but allowed arbitrary nesting of information items.

Much of the modelling challenge was in analyzing where it was possible to make use of international CKM archetypes vs. when GENERIC_ENTRY ‘integration’ archetype-based templates were required. This decision was based on knowledge of the most common and high-value datapoints e.g. diagnosis, vital signs but full roll-out would require more formal governance by clinical stakeholders. Critically, the full context of the original data was captured so further enrichment/re-mapping to CKM archetypes (conversion strategy #3 above) could be done over time. A particular challenge was a proprietary (TakeCare) template format that was based on an internal terminology but allowed arbitrary nesting of information items.

The PoC focused on semantic feasibility of the conversion, and feedback regarding clinical usefulness of the user interface for this a handful of realistic but fake patients’ EHRs were used for data entry in TakeCare followed by ETL via the APIs of TakeCare and an openEHR server. Technical scalability/performance (batch import etc.) and deeper semantic work will be addressed in work starting now.

Presentation files with more details and the open-source code used for conversion and visualisation can be found at https://github.com/regionstockholm/poc_tc2openEHR

BMC Proceedings 2026, 20(12):A14

Text2AQL follows a multi-stage generation pipeline (Fig. 1). First, clinical concepts are extracted from the user’s natural language input. These concepts are then mapped to relevant openEHR archetypes and data element paths using Retrieval-Augmented Generation (RAG) [3]. Archetype data is embedded and indexed in a vector database to enable semantic retrieval of the most relevant archetypes, elements and their paths. Finally, a large language model generates the AQL query by incorporating the retrieved context. A dedicated validation step detects and corrects common syntactic errors, such as invalid CONTAINS clauses or hallucinated paths, ensuring compliance with the AQL rules and specification.

We evaluated Text2AQL on a benchmark dataset of 1,274 natural language descriptions paired with their corresponding AQL queries. Generated queries were assessed for syntactic validity and also semantic similarity to the ground truth using an LLMas-a-judge paradigm [4]. Text2AQL produced syntactically valid AQL queries in 81.9% of cases, outperforming general-purpose language models such as GPT-4o (73.6%) and GPT-5 mini (46.2%) as seen in Fig. 2. Although other two approaches achieved higher semantic similarity scores on their valid outputs, they generated substantially fewer executable queries overall. As a result, Text2AQL provides the most reliable performance for practical query execution.

By combining large language models with the retrieval-based method for openEHR archetypes and element paths, Text2AQL improves the generation of executable AQL queries from natural language. The proposed approach lowers the technical barrier to querying openEHR repositories, supports clinical decision-making and streamlines research workflows. Future work will focus on improving robustness, expanding curated validation datasets and evaluating multilingual clinical queries.