Care Plans and Clinical Reasoning

The Canonical Resource Management Infrastructure (CRMI) implementation guide has made FHIR a viable format for representing context-independent knowledge, such as decision support rules or drug databases. The authoring, publishing, and distributing of FHIR-based knowledge is a shared concern for many knowledge providers.

Given that CRMI is still relatively new, most of the existing FHIR -tooling is focused on authoring and publishing profiles and implementation guides over knowledge artifacts. Similarly, existing registries, such as Simplifier, are not currently designed to serve as CRMI knowledge repositories. While there has been some past collaboration in this space in the US under the AHRQ CDS Connect project, a European counterpart doesn't yet exist.

• Is there common tooling we could build around the authoring and sharing of knowledge artifacts?
• Do you have clinical knowledge you could author or publish through CRMI?
• Do you have a system that could interface with published CRMI packages?

Terminology is a central part of most clinical knowledge. Definitions often have to be shared across both the local and the global ecosystem, where the same thing might be represented in many ways. This is not only true for individual codes and code systems, but also for more complex expressions, such as "long-acting nitrates".

There have been various approaches to modelling clinical concepts through terminology. To list a couple examples:

• Extensional (enumerated) ValueSets
  - OpenSAFELY OpenCodelists
  - NLM Value Set Authority Center
• Intensional (algorithmically defined) ValueSets
  - SNOMED CT Expression Contraint Language
  - FHIR ValueSet Compose Language

In addition to terminology, different implementation guides have different ways of defining concepts even within FHIR. Consider a concept like *"Patients who are hospitalized for COVID-19 and who are not critically ill"*, for example. A computable guideline (within the CPG IG) would contain a CaseFeatureDefinition as CQL code, whereas the underlying evidence (within the EBM IG) is communicated through a CohortDefinition as a Group resource. A Structured Data Capture (SDC) Questionnaire might define an equvivalent item, too. Not to mention non-FHIR models like openEHR archetypes or OMOP CDM.

• How should we define and share clinical concepts that are robust and precise enough?
• Do you maintain extensional ValueSets that could be simpler as intensional instead?
• What should be done through terminology and what should we reach for when it isn't expressive enough?

The Standards for Sharing Care Plans and Computable Clinical Guidelines project of xShare and EHRxF was kicked off in the HL7 Europe Working Group Meeting on the 3rd of December 2025. The aim is to define common models in the scope of EHDS, building on top of existing profiles and implementation guides. The IHE Computable Care Guidelines (CCG) and HL7 Clinical Practice Guidelines (CPG) are particularly relevant.

Finding common approaches for European care plans and clinical guidelines is a timely concern, as local approaches have already diverged. In Germany, for example, the Evidence Based Medicine (EBM) implementation guide has found success over CPG for representing clinical guidelines through Clinical Practice Guidelines (CPG) on EBMonFHIR (CPG-on-EBM-on-FHIR). Better sharing across the various contexts of the Quality Improvement Ecosystem would benefit all.

The lack of working public examples has been a consistent barrier to the adoption of CPG. For example, a tiny bit of the Duodecim EBMG Rheumatoid Arthritis Guideline that was translated from L1 to L4 in early 2023 is still one of the very few public repositories.

• How should we model and interface with Care Plans and Computable Clinical Guidelines, such as Käypä Hoito?
• Do you have existing Care Plans in other fomats, such as CDA, that would benefit from being translated?
• Could we pave the way for CPG by creating more concrete public examples?

Testing and demonstrating computable knowledge artifacts requires synthetic patient data to work on. Historically, tools like Synthea have been US -centric. EHDS gives us a great set of common profiles to target, as the same synthetic data can be used across the EU. This work has already been started by HL7 Europe in the SYNDERAI project. Extracting the synthetic patient data from the documents into a bulk FHIR import is doable with little effort.

• Could we contribute to the completeness and correctness of EHDS-profiled synthetic data?
• Are there other ways of testing clinical knowledge against realistic data?

Whether the clinical knowledge you have is defined as FHIR resources or not, it can likely use one or more of the integration mechanisms described in the CPG IG:

• Direct, i.e., as CRMI packages. The integration effort depends on the resource type. A drug database with ClinicalUseDefintion resources might work well with just about any FHIR server through the search API, whereas a package containing CQL Library resources applied through PlanDefinitions requires the integrator to have a clinical reasoning implementation in place.
• Reasoning-as-a-Service, i.e, as CDS Hooks services. An integration doesn't necessarily even need a FHIR server, as long as the data defined in the prefetch can be provided. Some systems, such as Apotti (Epic), have the capability to integrate with CDS Hooks services on specific hooks.
• As an Application, i.e., as SMART apps. There is a dedicated topic in the Patient Access Track for the Finnish SMART App Launch implementation guide. Consider joining that, unless this one seems more relevant for your use case. SMART is generally a quite widely supported integration mechanism.
• Via Data Enrichment, i.e. via real-time bidirectional interaction. While this mechanism is still mostly new and unfamiliar territory to Duodecim (and to Joonatan personally), it seems promising for systems that do not implement the clinical reasoning capabilities required for a direct integration, that deal with large populations, or that look to enrich patient records in the background. A clinical decision support system might, for example, deliver insights as DetectedIssue resources. If this is your bread and butter (and/or this description is completely off base) then please come and tell us all about it!

It is possible to provide the same clinical knowledge through all of these mechanisms. Each has different pros and cons.

• Do you have clinical knowledge that you could provide through one of the integration mechanisms?
• Do you have a system that could use clinical knowledge through one of the integration mechanisms?
• Are there other ways of integrating clinical knowledge?

The track leads are:

• Joonatan Vuorinen, Duodecim, joonatan.vuorinen@duodecim.fi.
• Ádám Z. Kövér, Felleskatalogen, adam.kover@felleskatalogen.no.

The Google Sheet embedded below tracks:

• Information of partners who wish to make their participation on the track public
• Information of presentations and educational sessions organized during the hackathon
• Any ideas participants may have for work before, during, and after the hackathon

Please feel free to add your own information to the sheet!

Please be careful not to edit information entered by others.

Note that you also need to register to the hackathon separately.