openEHR-FHIR Identifer datatype mappings issues

[ian.mcnicoll]

As part of the poenEHR/FHIR collaboration, a group of us are working through data type mappings in detail, based on work already done by @SevKohler and @yampeku for FHIRconnect.

One issue that has arisen is with DV_IDENTIFIER <> FHIR Identifier.

We think we can make most of the attributes line up nicely but there are some concepts in FHIR that simple do not have equivaelents in openEHR.
use and period.

After some discussion, our conclusion was thatthese are not relevant to the openEHR EHR (CDR) model as they really relate to the system ‘managing’/ issuing’ the identifer especially patient/staff identifiers, and although openEHR CDRs will certainly make use of these identifiers, it will not generally be managing them.

Our suggestion is that in the rare cases that use/period are required, that a CLUSTER archetype can be created and added to a slot e.g. the Person archetype

if required.

The alternative is to add the ‘missing’ FHIR attributes to DV_IDENTIFIER, particularly if this might have more value in DEMOGRAPHICS.

[pablo (Pablo Pazos)]

Hi @ian.mcnicoll what a coincidence, I’m working on bidirectional mappings FHIR <=> openEHR right now and found the same issue with the DV_IDENTIFIER, though it might happen with other datatypes that are not aligned, since there is no 1 to 1 mapping between FHIR and openEHR datatypes. I’m working on demographics for creating, updating and searching, even published a video about that hours ago https://youtu.be/aguwCLJ2mj4

With the current models and methodologies, the most accurate approach IMO would be to map openEHR CLUSTERs with FHIR datatypes.

Though there is a more in depth issue besides having more/different fields on FHIR or openEHR datatypes that are semantically similar or serve the same purpose, that is about the modeling methodology: openEHR is a non-extendable while FHIR is an extendable model.

For instance, you can add an extension for Identifier in FHIR that adds a new field, but in openEHR you can’t add fields to a DV, and the closest thing to a DV that can be archetyped in openEHR is the CLUSTER (because for ELEMENT you can’t add stuff, only constraint value or null_flavour).

The main mismatch is that openEHR constraints a fixed/final model, and doesn’t have an extension mechanism, which FHIR does have. Recently I mentioned that idea, I think to Erik and Thomas: to have archetypes for extensions to the RM. An extension archetype would add stuff for any current RM class, even allowing to archetype what’s defined in there. So, for instance, we could add a “purpose” to DV_IDENTIFIER using ADL, as we could add a “purpose” to the FHIR Identifier using FSH:

ADL:

definition
  DV_IDENTIFIER matches {
    extension [ex0001] {
      purpose matches {
        DV_CODED_TEXT matches {
          ...
        }
      }
    }
  }

FSH:

Extension: IdentifierPurpose
Id: identifier-purpose
Title: "Identifier Purpose Extension"
Description: "An extension to capture the specific purpose or intended use of an identifier"
Context: Identifier
* ^version = "1.0.0"
* ^status = #active
* ^date = "2024-01-01"
* ^publisher = "CaboLabs"
* ^contact.telecom.system = #url
* ^contact.telecom.value = "https://cabolabs.com"
* ^jurisdiction = urn:iso:std:iso:3166#US "United States of America"

* value[x] only string
* valueString 1..1 MS
* valueString ^short = "The intended purpose or use case for this identifier"
* valueString ^definition = "A human-readable description explaining the specific purpose, context, or use case for which this identifier is intended to be used."
* valueString ^example.label = "General"
* valueString ^example.valueString = "Primary identification for inpatient admissions"

If we could extend the RM formally, then we could feed extensions to modeling tools, and use those to define archetypes and templates, add constraints on top, etc.

I don’t know if this idea would grasp any interest, though I’m planning to put some time on this when I finish current FHIR-openEHR projects.

In any case, I wouldn’t recommend to change the RM to match exactly the other model, because we have different approaches to modeling/requirements, though I do think DV_IDENTIFIER is overly simplified and has some issues. For instance: “not being able to code the type since it’s a String”, is a pain in the neck.