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.