Generic_entry would greatly benefit from a "meaning" attribute
Description
Activity
Diego Bosca May 31, 2022 at 7:25 PM
Meaning means original_model_type, if there is some extra binding in source model then we can put that as a binding if needed
Thomas Beale May 31, 2022 at 6:59 PM
Maybe needs two attributes? One for meaning, one for ‘original_model_type’ or similar?
Diego Bosca May 31, 2022 at 6:54 PM
Yes, ‘meaning’ would be an optional attribute containing a DV_CODED_TEXT. It could draw codes either from ISO13606 part 3 ((for CDA or ISO13606 codes already defined) or some specific way of identifying the source class in other standards, maybe something putting codes such as FHIR(R4)::Observation
Thomas Beale May 31, 2022 at 6:49 PM
do we have a concrete change to propose for this PR? If so we can create a CR.
Thomas Beale January 10, 2019 at 10:51 AM
I agree - I thought they would get used. I think in the US they would have been used to deal with CDA, maybe in Germany as well. But in other countries, it is either HL7v2 or proprietary structured that is the main need (e.g. British GP systems).
Anyway, it's an easy change to schedule for the next release.
When dealing with integration of other artifacts, having kind of an optional "meaning" archetype in the GENERIC_ENTRY class, in a similar way 13606 entry has (see 13606 part 3) would ease the transformation of clinical models between any other standard and openEHR, while keeping all the semantics (e.g. something was originally a CDA Observation, or even a MedicationAdministration FHIR resource). With this we could separate the original "class" of the model and still being able to copy the source model terminology bindings if available (no need to add some term bindings in addition to the ones the source class may have)