# Equivalent to FHIR Annotation **Category:** [HL7 FHIR](https://discourse.openehr.org/c/fhir/101) **Created:** 2023-01-31 14:38 UTC **Views:** 1697 **Replies:** 43 **URL:** https://discourse.openehr.org/t/equivalent-to-fhir-annotation/3505 --- ## Post #1 by @birger.haarbrandt Hi everybody, my colleague at vitragroup raised an issue regarding the way how clinicians might annotate data. Any idea how we should handle FHIR's [Annotation](https://hl7.org/fhir/datatypes.html#Annotation) data type (e.g. as used in [Condition.note](https://hl7.org/fhir/condition-definitions.html#Condition.note))? I think the main issue is to assign a repeating element like "comment" in the problem/diagnosis archetype (at the moment, it has 0..1 though) some additional information that would also include the provider/author on element level. We might also work around this using references, but I favor an approach where an entry is really self-contained and does not rely on any outside entries for interpretation. --- ## Post #2 by @pablo Hi @birger.haarbrandt it feels like the the `extension` pattern used lately in archetypes might be a good place for an annotation extension in openEHR. I'm sure @ian.mcnicoll can comment about that. --- ## Post #3 by @thomas.beale FHIR Annotation is a priori intended to support post hoc comments on data created earlier, hence its inclusion of its own micro-audit information. The real question is what the clinical status of such annotations is. Are they: * unrelated to clinical care, and to do with e.g. research projects done much later? * modifications to clinical data not in its original location (e.g. EMR system) but on a created copy (in different format) somewhere else? Is the original EMR data still reliable and complete or not? * intended to impact on ongoing care of the patient? Could a modification to a Dx or Rx be included in an 'annotation'? * indicators of errors in (much older) patient data (e.g. due to new science)? Ex: until the link between H Pylori and stomach ulcers was discovered in 1982, all previous Dx of causes of stomach ulcers (and Rx) were 'wrong'. It is not clear that in general any of these could be claimed - any of them could be the case in different circumstances. If they are used in FHIR-based systems, my guess is they are used in all kinds of undisciplined ways. Therefore, in a data integration scenario, mechanically pasting in FHIR annotations into current clinical care data for the patient might be a completely erroneous thing to do, and could even be clinically dangerous. The real problem is that the term 'annotation' has no semantics. --- ## Post #4 by @ian.mcnicoll I'm inclined to agree with Thomas here. @Birger - can you give some actual examples of how this might be used? An obvious example is where perhaps a GP comments on a lab test to let the patient know that a result is normal but potentially the requirement there might be lot more complex than just a little bit of text. --- ## Post #5 by @birger.haarbrandt @ian.mcnicoll, @pablo, @thomas.beale thanks a lot! I will ask my colleague to provide an example. This is from a FHIR resource defined by the German government as part of ISIK. EMR vendors will have to comply with the format and we have to be able to digest it. --- ## Post #6 by @ian.mcnicoll I suspect the vast majority of these are simple notes or comments made at the same time as the original entry where we almost certainly have a comments field that would do the job as target. I'd be much more anxious about what to do with these post-recorded annotations. Is this worth an ask in the FHIR community as existing vendors will have exactly the same issues, unless using a FHIR-native CDR. i.e very unlikely to be a good fit for their existing dataset, or at least some per-use case analysis --- ## Post #7 by @thomas.beale [quote="ian.mcnicoll, post:6, topic:3505"] I’d be much more anxious about what to do with these post-recorded annotations. Is this worth an ask in the FHIR community as existing vendors will have exactly the same issues, unless using a FHIR-native CDR. i.e very unlikely to be a good fit for their existing dataset, or at least some per-use case analysis [/quote] Theoretically, you could program rules to look at the timestamp on the annotation, and if it were a 'long time' after the original encounter or whatever, it could infer that it should not be stored with the original data. But this is very unreliable, dangerous stuff. This is what happens when standards are issued without properly considering semantics - it could actually worsen the already poor quality data in many main systems (EMRs etc). --- ## Post #8 by @pablo [quote="thomas.beale, post:7, topic:3505"] if it were a ‘long time’ after the original encounter or whatever, it could infer that it should not be stored with the original data [/quote] That's an interesting area to look for patterns and best practices! One option would be to update the compo and create another version with the comment/annotation, though if the update comes after a certain threshold, it might be better to store it in another compo and create a link. But, that opens a bigger philosophical question: in an update, what is data that should be in the same compo vs. what should be in a different but linked compo? I mean semantically. Because taking an annotation over existing data, might be just that, adding notes over existing data but is not part of the existing data, just references it,, like a forum conversation, the original post is not updated, it just receives responses or comments that reference it, and each has a timestamp so we can follow the conversation chronologically. Maybe this annotation thing is just that, a conversation. Another point to consider, right now with the current AQL spec is difficult to get info from LINKs, so it will be difficult to answer to "give me all the compos where .... and all the annotations of each compo", because the annotations might be LINK sources. --- ## Post #9 by @birger.haarbrandt This is actually what I assume. This field could be a conversation, maybe in the context of a shared care record. However, this should really be something like a "journal entry". As FHIR is mainly intended for data exchange, it can "afford" such aggregation of information on the API level and not care where this is stored. However, the fun begins if you have to properly store the FHIR resource (sorry for preaching to the choir :D ). In any case, we might want to use a link to bi-directionally reference between such conversation as it might contain some relevant information. For our scenario, we might actually create a cluster that we use in the extension slot of the problem/diagnosis archetype. Of all bad ideas, this seems like an acceptable one. This might not provide a general pattern for archetypes, but this might not be needed. --- ## Post #10 by @thomas.beale [quote="birger.haarbrandt, post:9, topic:3505"] This field could be a conversation, maybe in the context of a shared care record [/quote] Or between researchers looking at the data, unrelated to the patient care process in their hospital... in which case it should not be added into the target shared EHR. [quote="birger.haarbrandt, post:9, topic:3505"] As FHIR is mainly intended for data exchange, it can “afford” such aggregation of information on the API level and not care where this is stored. However, the fun begins if you have to properly store the FHIR resource [/quote] yes this is the main issue. Some application (you don't know what) is accreting more data on top of the data sucked out of the EMR, and you don't know the real status of that added data.... [quote="birger.haarbrandt, post:9, topic:3505"] In any case, we might want to use a link to bi-directionally reference between such conversation as it might contain some relevant information [/quote] How would you know? [quote="birger.haarbrandt, post:9, topic:3505"] For our scenario, we might actually create a cluster that we use in the extension slot of the problem/diagnosis archetype [/quote] Still makes too many assumptions I think...! --- ## Post #11 by @ian.mcnicoll Good discussion - nothing in Zuilp on this so I have asked the question in the Zulip UK channel, as it is highly relevant to some upcoming discussions on allergy Intolerance profiling that I've been asked to help with. Could we also consider possibly using feeder_audit? There is a broader issue we are grappling with around dats/times provenance of element-related synchronisation. e.g via GP systems, which feels related. --- ## Post #12 by @ian.mcnicoll I am always happy to resort to a local cluster in an emergency but if you go down that road you are pretty well committing yourself to adding it to every single entry archetype in a template where there is a possibility of encountering an Annotation. --- ## Post #13 by @birger.haarbrandt My colleagues were clearly against using Feeder Audit as we should not "hide" any clinically relevant information (yes, we don't know but anyway...) there. Thanks for asking in Zulip. I actually got one example which I consider not too helpful: ``` { "resourceType": "Procedure", "id": "HCBS", "text": { "status": "generated", "div": "
\n\t\t\t

\n\t\t\t\t Personal care services provided at person's home\n\t\t\t

\n\t\t\t

\n\t\t\t\t Based On : Peter's Long Term Services and Supports (LTSS) care plan

\n\t\t\t

\n\t\t\t\t Status : completed

\n\t\t\t

\n\t\t\t\t Beneficiary : Peter James

\n\t\t\t

\n\t\t\t\t Service Name/Code : Personal care services (Details : {HCPCS code 'T1019' = 'Personal care services, per 15 minutes'})\n\t\t\t

\n\t\t\t

\n\t\t\t\t Service Date : Apr 5, 2018

\n\t\t\t

\n\t\t\t\t Service Provider : Adam Careful

\n\t\t\t

\n\t\t\t\t Service Delivery Address : Peter's home

\n\t\t\t

\n\t\t\t\t Service Comment : Assisted with bathing and dressing, doing laundry, and meal preparation

\n\t\t
" }, "basedOn": [ { "display": "Peter's Long Term Service and Supports (LTSS) Care Plan" } ], "status": "completed", "code": { "coding": [ { "system": "https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha-Numeric-HCPCS.html", "code": "T1019", "display": "Personal care services, per 15 minutes, not for an inpatient or resident of a hospital, nursing facility, icf/mr or imd, part of the individualized plan of treatment." } ], "text": "Personal care services" }, "subject": { "reference": "Patient/example", "display": "Peter James" }, "performedDateTime": "2018-04-05", "performer": [ { "actor": { "reference": "Practitioner/example", "display": "Adam Careful" } } ], "location": { "reference": "Location/ph", "display": "Peter's Home" }, "note": [ { "text": "Assisted with bathing and dressing, doing laundry, and meal preparation" } ] } ``` --- ## Post #14 by @birger.haarbrandt Yes, this is why I was wondering if this could be something we could add to the Reference Model. However, @thomas.beale had some good arguments why this might not be a good idea. Hence, I'm not sure how to resolve this --- ## Post #15 by @thomas.beale I think the #1 priority is to be able to find out whether the annotations are from the original source system, i.e. part of the EMR#s patient record, or were attached in some other system or integration step. If that cannot even be known from the data, then this feature of FHIR (and any other similar feature, where data are pasted in on top of original system data in a way that cannot be detected) is *dangerous*. If it can be determined, either from the data or from some B2B org-level agreements, that information should be used to decide whether to include the data in the target EHR or not. --- ## Post #16 by @Seref 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. --- ## Post #17 by @birger.haarbrandt At minimum, there is a timestamp and an author for an annotation which should make it doable to decide if the annotation was part of the original version. I think there is also some FHIR metadata to have an audit trail of changes including metadata, but I would have to have a second look if this covers all needs. --- ## Post #18 by @ian.mcnicoll Timestamp and author are optional AFAIK, so if unpopulated, we can assume they are part of the original record (or an update of that). I sympathise with Seref's view also. We constantly have to juggle with this kind of situation in integrated environments, so if there was a generic solution to capturing this info, where deemed to be low risk, it does make life a lot easier. Then it is up to people like use to argue about specific issues that need to be handled specifically, because of critical use-cases. And as I said earlier, there are other similar challenges about granular data coming from other systems. --- ## Post #19 by @thomas.beale [quote="Seref, post:16, topic:3505"] I’d suggest revisiting the tagging/metadata related discussions we’ve had for RM. [/quote] I am also more inclined to look at that approach. However I recognise we can't save the world from itself, but we should not promulgate errors / bad data either. The openEHR system will get blamed for the junk in it, not the sender of the letter bomb or the dodgy postal service that brought it... [quote="Seref, post:16, topic:3505"] 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. [/quote] Also yes.... It's worth remembering that the first clinical error that occurs because of poor integration will be when this gets real. In HighMed's case, it's currently not point of care, it's analytics and research. Who knows what analytics will silently go wrong with wrong underlying data? And what happens if anyone decided to start using the openEHR Shared EHR for clinical care, e.g. patient monitoring, clinical trial management etc? --- ## Post #20 by @Seref [quote="thomas.beale, post:19, topic:3505"] The openEHR system will get blamed for the junk in it, not the sender of the letter bomb or the dodgy postal service that brought it… [/quote] [quote="thomas.beale, post:19, topic:3505"] Who knows what analytics will silently go wrong with wrong underlying data? And what happens if anyone decided to start using the openEHR Shared EHR for clinical care, e.g. patient monitoring, clinical trial management etc? [/quote] I don't disagree with these concerns. My point is, we should manage the risk for these scenarios while considering the trade offs of adoption and delivering actual solutions. I think the options I listed and you sound positive about are one way of achieving and managing that balance. I prefer them to our regular approach in modelling especially when openEHR is the upstream data source, not the downstream receiver. There is not much I can say beyond this without repeating myself :slight_smile: --- ## Post #21 by @ian.mcnicoll [quote="birger.haarbrandt, post:13, topic:3505"] ``` "note": [ { "text": "Assisted with bathing and dressing, doing laundry, and meal preparation" } ] ``` [/quote] 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 --- ## Post #22 by @Seref [quote="ian.mcnicoll, post:21, topic:3505"] 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. [/quote] 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 :slight_smile: --- ## Post #23 by @thomas.beale [quote="ian.mcnicoll, post:21, topic:3505"] 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 [/quote] Excellent idea. That is something that is generically implementable and likely to be reasonably safe. --- ## Post #24 by @birger.haarbrandt Only if someone cannot overwrite someones comment but I guess this needs to be addressed on an application level... --- ## Post #25 by @ian.mcnicoll If the comment element is 0..1 then you need to append the Annotation note tp the original comment. If it is 0..* you can add a new comment. @Seref: [quote="Seref, post:22, topic:3505"] 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. [/quote] 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. --- ## Post #26 by @birger.haarbrandt 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) --- ## Post #27 by @ian.mcnicoll [quote="Seref, post:22, topic:3505"] 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? [/quote] 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. --- ## Post #28 by @pablo [quote="birger.haarbrandt, post:26, topic:3505"] 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 [/quote] 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. --- ## Post #29 by @siljelb [quote="ian.mcnicoll, post:21, topic:3505"] a comments element (hopefuly multi-occurrence) [/quote] 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. --- ## Post #30 by @joostholslag 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). --- ## Post #31 by @ian.mcnicoll 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 --- ## Post #32 by @joostholslag [quote="ian.mcnicoll, post:31, topic:3505"] So the implication is that any templates built must be include such a cluster extension for *every* entry and potentially for some clusters too. [/quote] 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. --- ## Post #33 by @joostholslag How about moving this topic to a public place btw? I think it has value to the broader community. Or has private material posted? --- ## Post #34 by @chunlan.ma @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. --- ## Post #35 by @yampeku [quote="chunlan.ma, post:34, topic:3505"] 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. [/quote] 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") --- ## Post #36 by @ian.mcnicoll Thanks Chunlan, 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. --- ## Post #37 by @chunlan.ma [quote="ian.mcnicoll, post:36, topic:3505"] 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 [/quote] Thanks Ian. Yes, agree. That's why I didn't mention FHIR in my comments :slight_smile: I know it was mentioned in the original question, but would like just focus on the requirements first. --- ## Post #38 by @ian.mcnicoll From Lloyd on FHIR Zulip... > 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! --- ## Post #39 by @thomas.beale [quote="ian.mcnicoll, post:38, topic:3505"] If you received a record where a note included a contradictory assertion, it obviously wasn’t made by someone [/quote] What amazing software is going to figure that out? Or are armies of humans going to be inspecting the data manually? [quote="ian.mcnicoll, post:38, topic:3505"] 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 [/quote] 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. [quote="ian.mcnicoll, post:38, topic:3505"] 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. [/quote] Agree. And unless such 'good understanding' could be encoded in integration engine algorithms, they are not actually that useful... [quote="ian.mcnicoll, post:38, topic:3505"] If I was going to implement natively, I would see it as a case for references, painful as they might be! [/quote] Also yes... --- ## Post #41 by @ian.mcnicoll Very happy to make it public. Worth wider debate. --- ## Post #43 by @Seref [quote="chunlan.ma, post:34, topic:3505"] 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. [/quote] [quote="ian.mcnicoll, post:36, topic:3505"] I completely agree and understand why this could be useful., and I like your approach. [/quote] 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 :slight_smile: 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. --- ## Post #44 by @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. --- ## Post #45 by @Seref [quote="ian.mcnicoll, post:44, topic:3505"] 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. [/quote] 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 :slight_smile: --- ## Post #46 by @linforest Label/classify and describe annotation with sufficiently rich metadata (isOriginal, primaryInterpretation, Explanation/Addition/Emphasis/Denial..., ...) to avoid potential ambiguities and risks. So it would need support from the underlying model (RM?) . --- **Canonical:** https://discourse.openehr.org/t/equivalent-to-fhir-annotation/3505 **Original content:** https://discourse.openehr.org/t/equivalent-to-fhir-annotation/3505