Equivalent to FHIR Annotation

[Seref (Seref Arikan)]

@chunlan.ma

I won’t include the post it notes as part of the EHR data (e.g. include it in an Evaluation or observation) and I won’t link the EHR data to the post-it notes. Instead I would have the post-it notes persisted separately, e.g. a special type of composition, and have the link from the individual post-it notes to the EHR data. The benefits for this approach is allow the user to show/hide the post-it notes.

@ian.mcnicoll

I completely agree and understand why this could be useful., and I like your approach.

That makes two of us Ian, but I’d like to repeat/rephrase a concern I voiced above: how do we know about it? Both at the clinical systems implemenation and analytics cases the focus, so to speak, will be on the primary composition that is based on the fhir resource that was annotated. If we don’t put some semantic marker to the primary composition, are we when going to check for annotation-representing-compositions while using the primary ones? This is reminding me of the operational complexity (in code) of making instruction-action-observation sets work. Also consider how heavily recent implementations are invested in AQL which I believe has no capability (at syntax level) to assert B.parent_reference = A.uid .

There’s also the issue of versioning taking place due to updates from the FHIR side, if we’re referring to a resource-composition from an annotation-composition and the resource-composition is updated, you have to update the reference so that it points to the latest version. I’m not even going into what will happen if someone delates the annotation on the fhir side

So I’m seeing a lot of fragile code here and I’d still stand in favour of keeping this simpler as per my previous comments.

[ian.mcnicoll]

I don’t think we are in disagreement. Chunlan and I were saying that we recognise the need to be able to create and manage these kind of annotations in openEHR, and if asked by a client tio implement e.g annotations on an MDT document, we would do this via references, and I suspect in most cases, the requirement and data models would be much richer than just a text comment.

Even if we don’t put some semantic marker to the primary composition, are we when going to check for annotation-representing-compositions while using the primary ones? This is reminding me of the operational complexity (in code) of making instruction-action-observation sets work. Also consider how heavily recent implementations are invested in AQL which I believe has no capability (at syntax level) to assert B.parent_reference = A.uid .

I think that is a fair point, and one that merits further consideration.

For integration from other systems via FHIR, there are, I think 2 quite different scenarios

1. Where FHIR is being used in a very controlled way, where there are opportunities to understand where/ when these annotations are being applied, and make sure that these are properly hooked up to whatever we decide to do internally e.g map to our own approach as above.

2. Birger’s situation, where due to, I think naive national standards requirements, he is faced with suddenly having to ingest a FHIR Annotation, with no understanding of how it was originally intended to work in the source system, which I suspect is actually much closer to the way that Chunlan and I imagined. I agree that we need a simple safe way of ‘handling’ these ‘unscheduled’ annotations safely.

[Seref (Seref Arikan)]

@ian.mcnicoll

Birger’s situation, where due to, I think naive national standards requirements, he is faced with suddenly having to ingest a FHIR Annotation, with no understanding of how it was originally intended to work in the source system, which I suspect is actually much closer to the way that Chunlan and I imagined. I agree that we need a simple safe way of ‘handling’ these ‘unscheduled’ annotations safely.

I think this is the case to focus on. It would offer a default solution for scenario number 1 until modelling can be fine tuned.

Feel free to shoot the following down:
For the annotation-in-the-wild scenario (2) above, can we use a metadata mechanism, something that exists at the RM level? This would be an RM field which would be strongly recommended to be archetyped whenever we know/suspect fhir messages will have annotations. The type of the metadata would be a tree structure that allows hierarchies of coded text only (maybe with some root level date info etc allowed), and the code value/terminology would be used to express semantics. Maybe a default openEHR terminology that very broadly classifies the annotation from our perspective, or something comprehensive, specific to an app or a national standard. You can even bulk update compositions if you decide to change your view of semantics of a set of annotations.

This is what I was implying before. It is queryable without intra-composition references, it can express semantics in a flexible way, using code mappings etc when required, and you’d have enough room to manoeuvre during modelling by constraining this for specific cases, constraining it’s meaning (code) to a small value set etc etc.

In my mind this strikes a balance between the various aspects within the scope of our discussion above: modelling/app-development-complexity/handling uncertainty.

Assuming the above is not entirely rubbish, we could discuss which types we’d extend with the metadata field suggested above, i.e. The Annotatables