That’s just a simple comment (no provenance) and easy to handle as long a there is a comments element (hopefuly multi-occurrence) in pretty well every Entry archetype.
The problem only comes when the ‘provenance’ part of the Annotation is populated, implying that it was made after the record was created, and is not an ‘official’ update to that record.
If this us used with in a tight business environment, Id want ot understand the exact use
my immediate advice would be that in a gneric ‘national standard’ environment unless the need and purpose of the provencedAnnotation is clear, thta it should be imported into the comment as text.
Comment:
Annotation: 12/01/2023 - Dr Jones - GMC 234567
I do not agree that tihs patient has an allergy to penicillin.
This is safe and simple. There may be use-cases for doing something smarter but I would want to handle these specifically.
Feeder audit does not need not be hidden BTW that’s a design choice. and the original full Annotation could be captured there for medic-legal reasons if important
Not trying to be annoying/smartar**: do you think you could come up with suggestions/modelling practices for every use of annotations within fhir? The ‘used in’ list in the fhir documentation site looked substantial.
What would you think about introducing a subset into openEHR terminology, or use some existing terminology subset to classify annotation while recording as metadata at rm level?
afterthought: using RM may be slightly problematic since it’d force stakeholders to check the RM level for annotations. How will they know there may be a fhir annotation in the data if it is not constrained in the archetype/template? non-constrained rm level metadata/tags may go under the radar so to speak. Maybe forcing annotations to be constrained with a terminology code as a modelling practice may solve both issues? I’m kind of braindumping here
I think the problem is that any such attempt would be pretty speculative right now, which is why having a simple degrade to text option is attractive, especially in Birger’s ‘this a national standard you must comply’ scenario. I might pull in the original json in feeder audit, especially if it carried e.g a reference to an actual Provider resource.
I’d still like to see one of these ‘in the flesh’.
The latest comment on Zulip wasRik Smithies:
I suppose that annotations are just one part of a general disagreement between what clinicians assert. You could annotate, or add another contradictory record. However I guess the main thing is to record what everyone said and let everyone see it. What gets done about that is a different problem maybe, which data representations cannot fix.
And anyway it seems unusual to annotate existing data, more common to add new data. The EHR is normally a cumulative set of statements, with almost no edits to what has gone before (which includes annotations). Not saying that is the best way, just what I have seen.
I’ll ask Rik for some real examples. I suspect we may be chasing ugly unicorns here.
I like his statement regarding the additive nature of an EHR (“cumulative set of statements”). However, with curated lists, it might be a slightly different story. However, while having a well-maintained list of diagnoses, this is not a reality in many places in Germany (and I assume also in other places)
Not sure I understand what sort of classification? Birger’s problem is that any German system can potentially lob any kind of Annotation (unclassified) which he has to handle but this is equally a problem for anyone wishing to ingest that message. As I said before if I knew the the use-case I probably could give more sensible advice but without that, dumbing down to text seems the safest option.
That’s an interesting sub-topic, I agree on the additive concept, including updates and deletes are really adding over the existing clinical statements, I see persistent lists (problems/conditions, medications, immunization, etc.) as derived information from other clinical statements, I mean: when a medication is added to a persistent list, could be because it was previously prescribed to the patient in an INSTRUCTION on a prescription COMPOSITION and the system does some magic to put the new medication in a medication list, though in some cases an app might allow users to manage the lists directly or have a mix of both cases (system magic + manual management). In any case, adding, modifying and deleting items from a list might be considered also as an additive operation.
Most if not all comment elements are by design 0…1, because they are intended for a single narrative clinical comment about the concept of the archetype in question, not as a get-out-of-jail-free card for any kind of data with unknown semantics.
I would suggest the least bad pragmatic way of handling this kind of data would be to create a “FHIR annotation” cluster archetype and stick it wherever needed, whether on the entry or composition level.
I agree Siljes option is fine.
Personally I was thinking of storing the FHIR annotation in a generic entry, because that has the fewest assumptions about the semantics of the data. (and probably put a link to that in the entry containing the rest of the data).
If you are having to handle an individual use case I would agree but Birger’s problem is that the German standard is saying that a system must be able to handle a provenanced annotation, in many potential resources (over 20) including Observations, I think. So the implication is that any templates built must be include such a cluster extension for every entry and potentially for some clusters too.
The other way to look at this is to say that no-one can be adherent to any national set of ‘standard profiles’ regardless of context and that vendors cannot simply be asked to fully ‘automatically’ comply without a clear understanding of use.
I’ll certainly be flagging this up in upcoming discussions about the UK FHIR Core profiles, which include Annotations
My idea to include a ‘link’ would be easier in this regard right, links can be inserted always, and don’t require any editing of the template. This is also the downside right? Because your openEHR to fhir bridge will have to handle mapping the generic entry to the fhir annotation, but now can’t make assumptions on where (what path) the link is stored. On the other hand if you have control over incoming annotations, and don’t allow client apps/users to record these annotations that could be mitigated.
@birger.haarbrandt 's requirement would be a common requirement clinically. I heard some similar requests before in Australia. Healthcare professional would like to attach some additional text based information to the existing EHR data, which may be any types of entry, composition, or clusters. It could be used for communication purpose, or as a reminder, or just temporary throughts, or something else. This feature is a bit like post-it notes (I’ll call it post-it note for now) stick (linked) to an existing EHR data. In most cases, a post-it note need to be linked to existing EHR data so that it is meaningful. The notes could be removed afterwards, or could stay, depending on the purpose of it.
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.
This is a very good point. It is probably wise to do so as they could be notes that the patient shouldn’t see at all (maybe some extreme case such as “patient was lying” or “suspected schizophrenia”)
I completely agree and understand why this could be useful., and I like your approach.
The problem is that the FHIR implementation munges all sorts of use cases (including potentially simple in-line comments) which make it hard to decide what to actually do with them if the context of use is unknown. I also suspect that this will be actually very rare in practice.
Thanks Ian. Yes, agree. That’s why I didn’t mention FHIR in my comments I know it was mentioned in the original question, but would like just focus on the requirements first.
In common use, it’s far more likely to be individuals from the same clinic/department - or even the same individual at multiple times - than users who have equal clinical ‘weight’ commenting on the same resource. Provenance and “cross-organizational editing of shared resources” are very different things. FHIR supports the latter, but few organizations do.
If you received a record where a note included a contradictory assertion, it obviously wasn’t made by someone who had either the confidence or the authority to change the status of the AllergyIntolerance to refuted, so the official record is still “patient is allergic” even though the record shows disagreement. It’s not significantly different than a record with notes that indicate the patient thinks their allergic and the official record asserts a mild intolerance. Written records can also include varying and conflicting assertions from different individuals over time, but there’s still an ‘authoritative’ working assumption reflecting best-known current state. Clinicians who have the time/interest can review the historical notes to come to a more nuanced understanding of how the current assertion came to be - and how much credence they want to give it.
I’m still not sure I’d want to do anything about this at import other than degrade to text, unless I had a really good understanding of the usage. If I was going to implement natively, I would see it as a case for references, painful as they might be!
What amazing software is going to figure that out? Or are armies of humans going to be inspecting the data manually?
Well that’s called the EHR, and whatever is committed to it by authorised users. The ultimate meaning of most of the record (outside managed Rx, Dx lists etc) is up to its human interpreters (and increasingly, some AIs or AI-like automatons) to figure out.
If content is injected (i.e. wasn’t there in the source) into an EHR due to the transmission of its content from A to B, there will be problems. If ‘post-it’ note content (to use Chunlan’s nice term) is in the source system but is made to look like something from the core record in the target… also problems.
Agree. And unless such ‘good understanding’ could be encoded in integration engine algorithms, they are not actually that useful…
