New Incubator for 'FHIR datatype mapping' gaps archetypes

Clinical Ask IEB
1

I’ve started creating a small number of cluster/element archetypes to ‘fill some gaps’ which emerged in the openEHR/FHIR datatypes group when mapping between openEHR and FHIR. We will be writing all of this up in more detail but it would be nice to give the archetypes bit more semi-official visibility.

  1. Extending Identifier to add ‘Use’ and ‘Period’ which are not normally required in EHR contexts since they are more about handling the lifecycle of temporary identifiers
  1. FHIR Narrative as discussed recently, Not surprisingly there was no simple answer but it felt helpful to have a FHIR narrative cluster that could plug in to Extension, for those cases where it was felt necessary to import but where there is no obvious target.
  1. Money - not sure of real use-cases but the idea is to build an Element archetype explicitly labelled as Money, with a Quantity datatype and guidance on the use of the specific units codesystem for currencies as used in FHIR. Arguably, if required, this should really become an RM attribute but archetyping it will allow us to assess the correct approach and assess whether it is really needed

These are as much for discussion as anything else, and I have them in a local AD repo but it might be better to have them visible on CKM in a public incubator?

4 Likes
2

I’m not sure I understand the implications of this. Could you explain a bit further? :smile:

3

Sure!

The FHIR Identifier equivalent of DV_IDENTIFIER includes 2 elements that are missing from DV_IDENTIFIER.

Use : usual | official | temp | secondary | old (If known) 0..1

Period: Date interval 0..1

In discussion with the FHIR guys, typically these would be used to manage e.g. temporary patient identifiers ( foreign patient, patient unconscious) with some kind of validity period. Temporary patient ID Issued 1/1/0206 - Expires 1/4/2026.

This makes sense if you are responsible for the assignment of identifiers and taking corrective action when the period has expired but the FHIR-openEHR datatypes team did not think it was likely that these extra elements would be required within an openEHR patient record setting, and it was not compelling to suggest an RM change. It might be of more interest for the openEHR Demographics community The cluster archetype was proposed as a possible workaround if someone did need to map these extra attributes into a patient record for some obscure reason.

2 Likes