Stream: netherlands
Topic: Guidance on Resource.text
Alexander Henket (Apr 02 2020 at 15:57):
In qualification testing of FHIR servers we keep running into discussion on the requirements on Resource.text also known as narrative. Even though the FHIR spec has lots of text on the topic, it does not make everything clear. Hence we want to propose an addition to the MedMij FHIR IG that covers that and we've written a proposal.
Input welcome. Text is in English so you don't have to be native Dutch :-) https://bits.nictiz.nl/browse/MM-1050
The short, short version is this:
The expectations for Resource.text or narratives within the context of this implementation guide:
- Sender SHALL provide "clinically safe" Resource.text of status extensions (preferred) or generated, unless explicitly documented in the relevant information standard to do otherwise or unless the resource does not support narrative
- Receiver MAY support Resource.text. If they do, this SHALL be in accordance with the status and explicitly documented use in the relevant information standard
- Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users as an explicitly documented use case for status empty or additional may exist. Also using just the narrative you would not expect to produce graphs, support medication alerts and other functionality
Alexander Henket (Apr 02 2020 at 15:59):
In MedMij/Nictiz/Dutch context "information standard" is equivalent to "implementation guide".
Grahame Grieve (Apr 02 2020 at 19:48):
Challenge here is the definition of 'receiver'. Is that any system that handles the resources?
Alexander Henket (Apr 02 2020 at 22:25):
In our context the IG only discusses the context of 2 parties. Secondary reuse of the same resources is outside of our scope. Is that what you were considering? Maybe Sender/Receiver is not the right paradigm still. Maybe Producer and Processor or something along those lines works better, but they would be new concepts to introduce. Sender/Receiver seems generally understood
Grahame Grieve (Apr 02 2020 at 22:31):
Just with regard to primary use, I think that there's effectively a number of different parties:
- Author
- Registry
- Routing agents
- Renderer
- Decision Maker
Sender/Receiver is too v2-ish; not all arrangements have all these parties but it's pretty common now. I think that Rendering it is fine to use the narrative, but decision making absolutely not (and graphing/alerts etc is definitely decision making)
Grahame Grieve (Apr 02 2020 at 22:32):
Registry and Routing Agents too, in their displays, are fine to just use the narrative.
Alexander Henket (Apr 02 2020 at 22:47):
Isn't that what the third bullet is about?
"Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users as an explicitly documented use case for status empty or additional may exist. Also using just the narrative you would not expect to produce graphs, support medication alerts and other functionality"
Alexander Henket (Apr 02 2020 at 22:49):
I must admit we shy away from distinguishing the different parties that may be involved in producing the narrative. We generally consider how it comes out of the API and reaches the wire.
Grahame Grieve (Apr 02 2020 at 22:55):
I think that's too coarse. you say "must not only rely on rendering as documented use cases for might exist". And I agree, such use cases exist. but they don't exist for all parties, so why make the rule? It's just wasting money. You should write:
Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also using just the narrative you would not expect to produce graphs, support medication alerts and other functionality
though you probably want some words there around due diligence
Grahame Grieve (Apr 02 2020 at 22:56):
but it's your money.
Alexander Henket (Apr 02 2020 at 23:00):
Fair point in the rewrite. I've updated the issue for it. As for due diligence: whose due diligence?
Grahame Grieve (Apr 02 2020 at 23:01):
Right. thats why I didn't try to draft words around that.
Alexander Henket (Apr 02 2020 at 23:04):
Even more basic: I know what due diligence in general means (I think), but I struggle with what you mean in this context
Grahame Grieve (Apr 02 2020 at 23:05):
well, an application might casually assume that they do't have documented use cases, and just use the narrative. I''m sayign that they should be accountable to make sure they've investigated it but how much they should and who is accountable to who will be context and culture specific
Alexander Henket (Apr 03 2020 at 06:19):
Ah that. We are in a pretty controlled context where there is no drive by interoperability so if you are using FHIR, you'll have an IG to guide you why and how. That being said, the same artifacts are also used outside what we define, for example in interfacing a data warehouse in one of our biggest hospitals and supporting a patient portal in a specialist hospital. If and how they deal with narrative based on our profiles which I know they use (they are designed as generic) is up to them. This guidance here is specific to the MedMij set of use cases for the same generic profiles.
I'll chew some on your suggestion for due diligence and see how best to word smith that. Thanks a lot for putting in the effort here!
Michael van der Zel (Apr 03 2020 at 08:28):
I am still not sure why we need a Resource.text and who will use it. The guidance should be to not use the Resource.text in clinical or research processes since we capture all data in discrete fields. Only that can be presented in the right context.
Lloyd McKenzie (Apr 03 2020 at 17:18):
Guidance is that Resource.text should be present for any system that stores data and may eventually propagate that data to other consumers. So a real-time decision support system that doesn't store anything doesn't really need narrative. But for most other situations, narrative should be there. Any time data might be shared and used in ways unanticiapted initially, there's a decent chance that one of the downstream systems won't understand all of the discrete elements (even if all the discrete elements are part of core).
Lloyd McKenzie (Apr 03 2020 at 17:19):
That's not a firm rule, but certainly is a strong recommendation
Last updated: Apr 12 2022 at 19:14 UTC
