Stream: argonaut
Topic: FHIR-29777
Eric Haas (Mar 02 2021 at 02:00):
RE: FHIR-29777 @Lloyd McKenzie Considering the broad range of usage and audiences, I think it would be difficult to prescribe the contents of any narrative. How would this guidance be different from what is in base FHIR? Can you suggest more specifically what you would like to see re narrative in US Core ?
Lloyd McKenzie (Mar 02 2021 at 03:38):
It'd be nice to at least see that there should be some... Right now, at least some EHRs aren't exposing any. Identifying that certain key elements need to be represented would be nice too.
Lloyd McKenzie (Mar 02 2021 at 03:39):
I understand that US baseline might not make any assertions, but the use-case for US Core is a bit different - it's specifically about patient access, so the expectations around narrative can take that into account
John Moehrke (Mar 02 2021 at 13:07):
Where the Patient or their Guardian is the recipient, having display names for codes should be required. The narrative, I think, is less helpful. In my project we never fall back to just displaying the narrative. We make the most out of the codes as we can, which is why display names for codes is critical. Where a manufactured narrative can be done at the client almost as usefully as at the server (see previous sentence).
Lloyd McKenzie (Mar 02 2021 at 14:07):
As soon as you start to share outside the US Core space, narrative that covers any important extensions matters. E.g. Moving resources into IPS.
Eric Haas (Mar 02 2021 at 18:22):
Lloyd McKenzie said:
As soon as you start to share outside the US Core space, narrative that covers any important extensions matters. E.g. Moving resources into IPS.
Can you clarify what you mean?
Lloyd McKenzie (Mar 02 2021 at 19:00):
When US Core data gets shared in environments that don't adhere to US Core (e.g. shared in an International Patient Summary document, passed to apps not covered by the current CMS/ONC regulations, etc.), you can't count on those systems handling the extensions (and possibly even the core elements) that are mustSupport in US Core. And even when exposing data to US Core systems, it's possible (and appropriate) for EHRs to populate data elements that aren't MS in the US Core spec. Doing that is safer/more useful if the 'important' information is conveyed in narrative.
Eric Haas (Mar 02 2021 at 20:14):
Do any implementers have an opinion on this - should the spec be defining what the narrative content should be?
Lloyd McKenzie (Mar 02 2021 at 20:16):
I don't know about dictating the content. I'd frame it as setting expectations for when it needs to be present and minimum expectations for what it SHALL/SHOULD contain.
Michele Mottini (Mar 02 2021 at 20:37):
Our opinion is that the specs should not be saying anything about narrative
Brett Marquard (Mar 02 2021 at 21:11):
We tried to discuss narrative format expectations in C-CDA/CDA and it's a deep dark hole.
Cooper Thompson (Mar 02 2021 at 23:08):
We'd also prefer not to have requirements for narrative.
Lloyd McKenzie (Mar 02 2021 at 23:40):
Any reasons for the preference? Would it be a problem if narrative was mandated but you had flexibility as to what it contained?
Michele Mottini (Mar 03 2021 at 00:31):
That we do not generate it (as a server) and completely ignore it (as a client)
Lloyd McKenzie (Mar 03 2021 at 01:51):
You ignore it even if it indicates it contains information about extensions and you don't recognize the extensions? Would it be a hard thing for you to generate?
Eric Haas (Mar 03 2021 at 02:13):
Lloyd McKenzie said:
Any reasons for the preference? Would it be a problem if narrative was mandated but you had flexibility as to what it contained?
who do you imagine would be mandating it? the regs, a guide?
Lloyd McKenzie (Mar 03 2021 at 02:27):
US Core, ideally. If we can't get to SHALL, I'd love a SHOULD.
Josh Mandel (Mar 03 2021 at 03:18):
for narrative?
Josh Mandel (Mar 03 2021 at 03:19):
(I also would rather not see requirements for this.)
Paul Church (Mar 03 2021 at 03:34):
What is the client supposed to do if the narrative "contains information about extensions and you don't recognize the extensions"? Apply strong AI to read and understand the narrative? We can't expect everything to be put in front of a human.
Lloyd McKenzie (Mar 03 2021 at 03:50):
Systems that are consuming data for only computation purposes don't need narrative, so if you consume but don't persist data and no human looks at it, narrative is unnecessary overhead. However, if there's a chance of data being disclosed to a human (either immediately or at some indeterminate future point, possibly after having passed through multiple systems, narrative is the fallback to display to a human in those situations where the end recipient system doesn't know how to display some of the discrete data elements (extension or otherwise). There's no requirement to display the narrative at all, but it's good practice to make the narrative available to the end user if there's a chance it contains information the system doesn't know how to render. Having narrative as a fallback makes it safer to include new 'important' discrete elements that may not be modifiers, but that you definitely want the receiving human to know about. Without that, you have to negotiate the addition of the new element(s) to all systems along the transmission path before it's safe to use the element.
Lloyd McKenzie (Mar 03 2021 at 03:52):
In the early stages, we said narrative was mandatory, but we walked that back when people talked about use-cases like real-time decision support that does not persistence or SMS FHIR transmission where the bandwidth costs were too high. But outside of those exceptions, narrative really should always be present.
Lloyd McKenzie (Mar 03 2021 at 03:54):
Narrative fallback is one of the reasons CDA was as popular as it was. You might not always understand the discrete data, but at least you could display it to a human. FHIR is much better at having discrete data that systems are likely to understand, but only around a certain percentage of the core elements. Beyond that, reliable retention and display becomes questionable or non-existent, while the need for the end human to understand the full picture still remains. And that's true whether you're sharing using document mode, messaging, REST or some other mechanism.
Josh Mandel (Mar 03 2021 at 03:59):
Narrative fallback is one of the reasons CDA was as popular as it was.
Not to be over-dramatic, but there's a dark side here too: the focus on narrative is one of the reasons structured data in CDAs is often semantically imprecise.
Lloyd McKenzie (Mar 03 2021 at 04:19):
Certainly the notion that "narrative is good enough, forget the work of exposing/consuming discrete data" is a problem, though given the importance of technologies like SMART, CDS-Hooks, etc., I think that's less of a risk in the FIR space. I think the semantic imprecision of CDA came more from the model. CDA allowed for element meaning to be a lot fuzzier than FHIR does. The presence of narrative is what allowed it to succeed despite the imprecise discrete data.
Jean Duteau (Mar 03 2021 at 05:47):
i have yet to have any of my guides need narrative. I certainly can't see a base guide like US-Core having any requirements around narrative. It certainly can't be SHALL and even SHOULD is too strong for many guides that are basing themselves off US-Core. I just don't see FHIR narrative as bringing any value to interoperability. This isn't a CDA document where I need to be able to fall back on section narratives to create a human readable document. In fact, that's probably the only situation where narrative is important - in FHIR documents.
Lloyd McKenzie (Mar 03 2021 at 06:06):
The use-case for narrative isn't one US-Core conformant system (that only sends US-Core MustSupport elements) that's communicating to another US-Core conformant application. The purpose isn't to satisfy the US Core use-case. It's to satisfy downstream consumers of the data who don't support US-Core. It's also to make it easier/safer and to encourage EHRs to share more than the data elements defined by US-Core. Right now, no one wants to share anything else because if it's important and some recipients don't recognize it, that's problem. If you've got narrative as a fallback, it ceases to be a problem. Human-readable text isn't important only in documents, it's important everywhere there are human consumers. Not as a 'primary' view, but to handle those situations that inevitably occur as data passes from A to B to C to D, possibly over a course of months or years that a recipient doesn't understand all of the discrete data. FHIR made a very conscious decision to not say that that narrative is document-centric. (It would have been far simpler to just stick it in Composition.section.text and be done with it.) We designed FHIR so that narrative would be fully supported in RESTful exchanges, messaging, operation invocation - everything. We did that because we believe it's important for all of those use-cases.
Cooper Thompson (Mar 03 2021 at 14:39):
I get that narrative can be important in some apps, but what content is relevant in that app seems like it would depend on the use case for that app. Rather than having the EHR generate a use-case agnostic narrative, it seems much more useful to have the app generate a narrative that meets their use case. And at least speaking for Epic, we are not really making FHIR API design decisions based on "important but recipients don't recognize it". Adding support for narrative in all our resources just gives us a ton of work that means we wouldn't be able to spend that time actually adding data to our APIs. Narrative generation can get really complicated when you have to account for all the possible profile permutations (US-Core + Netherlands Z-Overdracht, BgZ, Denmark MedCom, etc.). And if basically none of the client apps we work with actually use the narratives, we'd just be wasting a bunch of our developer's time.
Lloyd McKenzie (Mar 03 2021 at 14:48):
The client can only generate narrative based on the elements it recognizes. And it can & should do that. More specifically, clients will generate a detailed UI (much better than narrative) that exposes the data it recognizes. However, a client can't easily expose in a UI information that it doesn't recognize. (It's possible to construct dynamic UIs that can render arbitrary extensions, but that's not something most apps can realistically handle.)
Question: Does Epic spit out different data depending on what profile you're trying to comply with, or do you spit out the same data set, regardless of jurisdiction, trying to ensure it complies with all relevant profiles?
Cooper Thompson (Mar 03 2021 at 15:48):
Lloyd McKenzie said:
Question: Does Epic spit out different data depending on what profile you're trying to comply with, or do you spit out the same data set, regardless of jurisdiction, trying to ensure it complies with all relevant profiles?
The latter. We try to keep all the different profiles we support in the same endpoint. So far, we have been successful, as there haven't been any conflicting profiles. I do expect at some point we'll run into conflicting profiles and we'll have to sort that out, but so far, we've been lucky (and/or involved enough in IGs to nudge them into compatibility)
Lloyd McKenzie (Mar 03 2021 at 16:02):
Good. So then I'm slightly confused about why narrative would need to be different for each profile. Wouldn't the narrative instead be driven by "this is what we expose"? Also, presumably some of those profiles include elements and extensions that other profiles don't. Are you comfortable that human consumers will never need to see the elements that some consumers might not support and will throw away?
Cooper Thompson (Mar 03 2021 at 16:50):
I mean one of the main differences is language. We'd want a Dutch narrative for the extensions that are relevant in the Netherlands, English for US Core, Danish for Denmark Medcom, etc. Should we include English narrative for the Z-Overdracht extensions? The narrative generation would need to be tokenized and the non-tokenized parts translated into all the languages we support. And the narratives would need to flex based on whether there was data in the system to actually populate the properties/extensions, and that can make the actual grammar and sentence structures vary, unless we just do dumb bulleted lists or something. I feel like narrative generation code would really have if/else branching logic for just about every property/extension, but if properties are related you'd need to group those and have branches on the permutations.
Cooper Thompson (Mar 03 2021 at 17:03):
Also, we've worked with hundreds of apps, and I don't think I've ever really heard anyone ask for the narrative. I think we should apply the YAGNI principle here. As soon as we hear of actual real apps that need narrative, we can consider whether the volume of apps that need it outweighs the effort of EHRs to generate it. But we should not add something that we don't have any actual evidence that anyone needs.
Lloyd McKenzie (Mar 03 2021 at 17:08):
Thanks for drilling deeper on this.
Cooper Thompson (Mar 03 2021 at 17:12):
One last point: the narrative generation wouldn't be resource-specific. It would be sub-resource specific. For microbiology results Observations, for example, you'd have a different narrative content for the isolate, method, and sensitivity Observations. So just for micro results, that is three different sets of narrative generation code just for Observation.
Eric Haas (Mar 09 2021 at 23:49):
@Lloyd McKenzie do you still want to pull FHIR#29777 from the block after this feedback?
Lloyd McKenzie (Mar 10 2021 at 00:30):
No, you can leave it.
Last updated: Apr 12 2022 at 19:14 UTC
