I’m not sure there’s actually a satisfying solution (in the broad sense within openEHR’s general principles) to this @birger.haarbrandt As I said to @ian.mcnicoll in a chat, sometimes we’re going to hit the limits of non-standards based software and real life processes and I think the origin of the fhir annotations is those cases which we may not be able to support.
I think a major source of these annotations is non-standards based clinical systems allowing users to annotate data on the screen just like they could do with a paper based process. They’re forced to allow this because the request from users arrive ad-hoc and for different parts of the system, which, at HIS/Cerner/Epic scale is a massive surface area. I know this because I’ve been there on the non-standard HIS vendor side of the scenario more than once.
So these source systems, having their non-standard internal representation deal with it in any way they want, then it ends up on the wire as an annotation in a fhir message. They cannot stop users from misusing the annotations of course, and that is a choice between data quality, computability and running an actual commercial offering.
Us on the other hand, with model driven platforms, have to consider how to support this in the generalised computing framework we have, and sometimes in cases like this, we may just have to live with the fact that there is no ideal solution, as this thread kinda indicates. In our case things are even more difficult because our ideal approach has a clinical engagement step where models for the specific case must be updated for annotation capability, which means a new archetype/template version and all the work that comes with it, all the way to actual system updates.
Ian favours tackling the problem but I’m not sure it is possible to find a solution that ticks the boxes Tom listed, because we have no control over the source of the annotations or whatever data quality/patient safety principle is potentially violated. Some vendor is making that decision, and semantically speaking I’m not sure we can catch all the balls they can throw. This is pretty much the Z segment of the HL7 V2 messages all over again the way I see it.
The pragmatic in me says there’s no point trying to tame this. I’d suggest revisiting the tagging/metadata related discussions we’ve had for RM. Yes, there’s potential for abuse/misuse but we can work on stopping that on the openEHR side and FHIR based data projected to openEHR would not have to deal with this at archetype/modelling level, which is really very difficult once you have clinical systems running in the field.
So if fhir data with an annotation arrives, we put it in wherever feels more sensible in that particular case of openEHR <-> FHIR bi-directional mapping, and accept the fact that some semantic black hole was put into data by the producers of the data. Maybe we could come up with documented mappings for the openEHR representation and salvage some safety/semantics, but if that requires revisiting the target template itself rather than most RM types supporting metadata/tagging, it’ll be too long of a roundtrip for clinical systems delivery/management.
Others may be more optimistic (and idealistic) compared to me but I’m willing to accept there’ll be some compromise every now and then.
). In any case, we might want to use a link to bi-directionally reference between such conversation as it might contain some relevant information.