Stream: conformance
Topic: Intended and allowed use of narrative
Morten Ernebjerg (Sep 22 2021 at 07:18):
[Strictly speaking, this topic may be more for #implementers but the somewhat excessive message length (and non-urgency) seemed to make it more appropriate for this place :grimacing:]
I've been reading the spec on narrative and am getting the feeling I misunderstood a few things, leading to some questions.
First off, I know that the narrative must contain all essential information encoded in the structured data so that it can be safely displayed instead of the latter. However, I also assumed that the converse would hold, i.e. that it must be safe to ignore the narrative and just use the structured data (thinking that the narrative is primarily a UI fallback). But the spec does not seem to explicitly say that. Indeed, the narrative documentation says that a resource can be essentially nothing but narrative:
A resource MAY only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This can be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
DomainResource.text is not marked as a modifier field so there is no explicit indication that ignoring it can lead to completely misinterpreting the content. However, for "narrative-only resource" that would seems to be a real danger - e.g. for a Condition containing subject as its only structured data element (valid), but with an extensive narrative describing an acute infection.
- Question 1: When (if ever) is it acceptable for a system to ignore the narrative?
The spec statement above could also be read as saying that if we have free text as the source data, we can just put it in toto into the narrative of whatever resource type seems appropriate, filling other elements only as required by cardinalities. Yet many resources have distinct elements explicitly meant for capturing free text information and my understanding was that those are the preferred destination for such information (which also makes it safer to ignore the narrative). For instance, for an Observation resource based on a legacy free text record, I would expect free text to be mapped to Observation.note or the text elements of the various CodeableConcept elements (e.g. Observation.code.text). Conversely, if all we have is really a single free text "black box", my intuitive (though perhaps incorrect) expectation is that should be wrapped in a resource that signals just that (e.g. a DocumentReference).
- Question 2: Under what circumstances is it best-practice (or at least acceptable) to map free text source data directly to the narrative, as opposed to (1) mapping it to resource-specific, "semi-structured" fields designed for free text (e.g.
Observation.note), or (2) putting it in general-purpose "wrapper" resources like DocumentReference?
Finally, I'm wondering about what counts as a worthy narrative. The requirement that the narrative be human-readable suggests that its value lies in being distinctly more user-friendly than raw JSON/XML or a "brute-force" table listing by path - i.e. in being something a doc can just look at and understand without further explanation. Auto-generating that might just about work for Patient (e.g. writing out addresses and names more clearly). But whenever the semantics of the individual element is more subtle and less familiar, it becomes very hard. For instance, having wrestled with visualizing and user-documenting information in the Dosage data type, I find it hard to imagine an automatic narrative generator that takes a generic Dosage instance and produces output that is both clinically safe and, in any useful sense, human-readable.
- Question 3: Are there formal or community rules-of-thumb for the readability-level a narrative has to reach to really improve clinical safety (more than displaying the whole resource as JSON would) and hence be worthy of inclusion?
Grahame Grieve (Sep 22 2021 at 11:07):
- Yes, if you're going to process the data, then you process the data, and the narrative is ignored. This assumes that you rightly understand the data, and there fore you need to make what arrangements you can to do this safely. This is a whole art form in it's own right. And often done badly too.
Grahame Grieve (Sep 22 2021 at 11:08):
but you can be sure that the narrative doesn't contain anything that's not in the data - you didn't mention narrative.status but it's important to your questions
Grahame Grieve (Sep 22 2021 at 11:09):
- if all you have is unstructured data... you don't know what you've got. but legacy systems generally have at least some of the contextual elements as data - e.g. Observation.code, date, and subject. If you don't put it in an observation, it'll be missed - that's (probably) worse
Grahame Grieve (Sep 22 2021 at 11:10):
- no. Some projects have adopted their own. But generally, once you're in a position to enforce rules like that, you don't need narrative; it'll only be needed by recipients who are not party to those agreements. And in today's eco-system, there will be some of those
Morten Ernebjerg (Sep 23 2021 at 08:50):
-
but you can be sure that the narrative doesn't contain anything that's not in the data - you didn't mention narrative.status but it's important to your questions
OK, good to known (and good point about
Narrative.status, I missed that) - might clarifying this in the spec still be worth a ticket? -
Yes, I suppose in practice the "narrative & done"-tactic will be unlikely, My worry was that system/apps with focussed UIs based on the structured data would be stumped by narrative-only resources, but if
Observation.codeetc. is set that already helps a good deal. -
Maybe I'm reading too much into the term "human-readable" here. I take it to imply that someone with medical domain knowledge but no idea about FHIR can read and correctly & completely interpret the narrative. Hence, I would not consider a generic table representation of FHIR human-readable (even with field definitions). If that is the correct meaning, my concern is that when the spec tells us that narratives should be human-readable AND clinically safe AND present if at all possible (meaning, in practice, auto-generated for structured input), it is asking for things that are mutually exclusive in many cases. Specifically, trying to satisfy readability & presence might lead to compromises on safety. As you rightly say, safely dealing with structured data is an art and generating human-readable narratives from structured data is a branch of that art, with the same pitfalls and dangers. On the other hand, if "human-readable" just means "serialized into text and standard layout elements", then that seems fine to me since it allows complete "semi-raw" narratives. Those will , I suspect, often not be understandable to whoever is reading them, but at least they don't incorrectly get the feeling that they understand it when they actually don't :smile:
Lloyd McKenzie (Sep 23 2021 at 23:59):
For Narrative.status, is there clarification that's actually needed?
Agree on the third point. And reality is, there's a significant gap between what we'd like to have happen with narratives and what's typically happening in the real world...
Morten Ernebjerg (Sep 24 2021 at 06:35):
Re. clarification: what I meant was whether we need an explicit statement in the spec to the effect that it must always be safe to ignore the narrative (this is how I understood @Grahame Grieve ). But I'm still not quite sure how such a clarification fits with the explicit license to create narrative-only resources:
A resource MAY only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied).
Grahame Grieve (Sep 24 2021 at 12:44):
I guess they aren't strictly compatible, but i also think that statement isn't meant to apply when the narrative status is additional
Lloyd McKenzie (Sep 24 2021 at 14:33):
'Safe to ignore' is a fuzzy thing. If the narrative has a status of 'generated' and your system displays all of the 'core' elements in the instance, then you can be confident that the 'same' information is displayed, however, it might not be displayed the same way with the same formatting in the same order. Some clinicians might think that's fine, others not so much. That's why with FHIR documents, there's an expectation to display the narrative regardless of status. And obviously if the status is 'additional', the narrative should always be available, but depending on use-case, maybe it's totally safe to not display it because only a couple of pieces of discrete data are relevant.
Morten Ernebjerg (Sep 27 2021 at 07:11):
OK, so I guess any simple statement would be too simplistic. But then how about extending the existing Clinical Safety Concerns-setion with a few sentences on
- Considerations when automatically generating narratives (e.g. simplification for readability vs. clinical safety)
- Considerations for when to make narratives displayable (specifically also the dependence on
Narrative.status)
I realize that we cannot make these points very specific, due to the subtleties discussed. However, I think it is still helpful by pointing out that these are important and complicated themes that require thorough consideration & by giving some factors to consider. Whereas classical EHR system implementers probably have an intuitive feel for clinical safety through experience, that could be different for implementers working on health apps etc.
Grahame Grieve (Sep 27 2021 at 07:12):
that sounds like a good idea
Morten Ernebjerg (Sep 28 2021 at 06:21):
Good, I'll cook up a JIRA issue and try to provide some textual building blocks (based on this discussion) as a starting point.
Morten Ernebjerg (Sep 30 2021 at 07:53):
So, finally found the time to write it up in JIRA :sweat_smile: - issue FHIR-34041.
Yannick Börner (Oct 01 2021 at 09:46):
Great discussion! I'm actually writing up a guideline for a narrative (extensions) right now and it really feels like uncharted territory. Are there any examples of good and human-readable (i.e. suited for practitioners) narratives out there that could be reused?
Last updated: Apr 12 2022 at 19:14 UTC
