Stream: implementers
Topic: Content of narrative and Reference.display
Lloyd McKenzie (Mar 17 2016 at 03:54):
Grahame and I have been having a fun chat. We've been discussing two questions and they're slightly intertwined, so I'll list them both:
1. When you have "generated" or "extension" narrative, is the expectation that the narrative includes only content that can be acquired by performing a transformation on the data that's present within the discrete content of that instance (core elements only or core + extensions, respectively), or is it legitimate to resolve references to other resources and include content from the discrete elements of referenced resources as well?
2. Is it good practice to say that when you have a "reference" type, the "display" element should always be populated to give the system something to display without having to do an _include on the referenced resource or should we expect software to pretty much always do the _include so there's no risk of the text displayed not exactly matching the current version of the resource referenced. (E.g. If the MedicationOrder.prescriber.display said "Dr. Jane Smith" and the practitioner now said "Dr. Jane Jones", implementers would feel a need to back-propagate the name change into all reference.displays and, as a result would rather the displays weren't populated at all.
The overlap is that if there are no reference.display elements, you sort of have to resolve the reference in order to include essential context such as the name of the patient, name of the practitioner, name of the medication, etc. If "display" can be expected to be present, then drawing on external elements might not be necessary, though there's then a question of just how much should be in narrative. Do you need just a light "link-style" reference (e.g. a name) or do you need a full description (e.g. name, gender, data of birth, mrn for a patient; name, gender, discipline, license number for a practitioner; etc.)?
We have rather differing opinions on the answers to these questions, so it seemed wise to let the implementer community weigh in :)
Brian Postlethwaite (Mar 17 2016 at 04:07):
I personally think that this should just be the real short stuff, so for a person would expect it to just be the name. (what I would expect to see on the button/link that I would click). (Postlethwaite, Brian Mr)
Brian Postlethwaite (Mar 17 2016 at 04:08):
Maybe could be talked into including the MRN, but that is quite contextual also, which/whos MRN?
Brian Postlethwaite (Mar 17 2016 at 04:09):
Putting something like DOB/phone number or other information in there could increase the chance of leaking information that could be restricted information to some users.
David Hay (Mar 17 2016 at 04:16):
I agree it's the short stuff - it's a 'teaser' (you wanna see more punk? resolve the reference then...)
David Hay (Mar 17 2016 at 04:18):
if performing a patient selection for example, it would be what you'd put in the result list, that's enough for the user to recognize the one they were after (most of the time)
Grahame Grieve (Mar 17 2016 at 04:37):
I personally have thought that it should be the 3 points of information to identify the patient. if you are de-identifying, then you have to scrub the narrative anywway
Brian Postlethwaite (Mar 17 2016 at 04:41):
I noticed that I only responded regarding the Display on ResourceReference, not the Narrative issue.
My understanding of the Narrative was that if it was Generated then there should be no information in it that can't be created by some transform on the content within.
http://hl7-fhir.github.io/codesystem-narrative-status.html#generated
Defines it pretty clearly. Not really sure why we would have empty here, isn't that where you just don't inlcude a narrative at all?
Grahame Grieve (Mar 17 2016 at 04:42):
I've never read it that way - I've always felt free to follow the references and include some additional describing information - to me thats still 'generated from the structured data in the content'
Brian Postlethwaite (Mar 17 2016 at 04:46):
Hadn't noticed the difference on extensions, and generated. Do we really need that?
Grahame Grieve (Mar 17 2016 at 04:56):
need what?
Brian Postlethwaite (Mar 17 2016 at 04:57):
need to have both generated and generated (from core and extensions)
Brian Postlethwaite (Mar 17 2016 at 04:58):
Does the "extended" generated narrative imply that it's not safe to regenerate if you don't know about the extensions?
Grahame Grieve (Mar 17 2016 at 04:58):
I think so - you know whether the extensions contributed to the narrative, so whether the narrative contains something you don't know if there's extensions you don't know presnet
Brian Postlethwaite (Mar 17 2016 at 05:01):
ok, Just doesn't say which extensions.
Grahame Grieve (Mar 17 2016 at 05:01):
no. that's true. you have to guess at that
Brian Postlethwaite (Mar 17 2016 at 05:02):
And my thoughts were that most content will have extensions in it, so knowing this part is likely to be interesting.
Grahame Grieve (Mar 17 2016 at 05:06):
and how would you suggest to do that?
Brian Postlethwaite (Mar 17 2016 at 05:11):
I don't have any suggestions on how you could do that.
(Have been considering using fhirpath to generate narratives though - not sure if that would be a good idea or not - store it as an extension in the structure definition for the resource)
Grahame Grieve (Mar 17 2016 at 05:12):
man. invent a good hammer....
Grahame Grieve (Mar 17 2016 at 05:12):
man. invent a good hammer....
Brian Postlethwaite (Mar 17 2016 at 05:12):
(No kidding!)
Brian Postlethwaite (Mar 17 2016 at 05:13):
Would get peoples attention as to what you can do with it though.
David Hay (Mar 17 2016 at 06:30):
and if it's a *really* good hammer...
Richard Kavanagh (Mar 17 2016 at 08:38):
We are having similar considerations at the moment.
Consider a Composition resource that has 5 sections each with the it's own Composition.Section.Text content. The resource then has the overarching Composition.Text content which would then duplicate that content (and yes, potentially add more from other elements within the resource) - it looks a bit excessive.
Ewout Kramer (Mar 17 2016 at 09:56):
I'd expect that a resource's narrative just has that resource's data in the narrative, and not referenced resource's data. Especially, since this data (the data in the referred resource) may have been changed without the first resource (that has the narrative) knowing it.
Ewout Kramer (Mar 17 2016 at 09:58):
Also, you cannot say a reference SHOULD have the display text. The reference might have been passed in from another context (say a patient selection part of the app), and you'd need to pass around the reference + the display. I just don't think people will do that.
Grahame Grieve (Mar 17 2016 at 10:53):
we inlined the narrative into Section.text precisely because we expected that the narrative in a document would be extremely context aware, where as the narrative in a restful sense is not context sensitive
Grahame Grieve (Mar 17 2016 at 10:53):
Lloyd proposes a half way house that's nearly ok for both, but the SD community didn't have any faith in that operationally
Lloyd McKenzie (Mar 17 2016 at 11:54):
My understanding of "generated" vs. "extensions" vs. "additional" is that, absent a site-specific agreement and excluding the document scenario, how do you figure out whether you need to make the narrative available to the user. If it says "generated" that means the narrative was automatically generated from discrete core elements in the instance. If you're already displaying all core elements, then the narrative won't have anything new/different and you don't have to show it. You could easily have an instance that contains extensions but where the narrative is still drawn only from "core" elements. If it says "extensions", then at least some of the extensions have also made their way into the narrative. If you don't know how to render *all* of the extensions in the instance, then there's a possibility the narrative contains something new and you should probably expose it. I think having to list exactly what elements (core or extension) are in the narrative is overkill. (And if you really want to, define an extension :>)
Lloyd McKenzie (Mar 17 2016 at 11:55):
Would anyone feel a need to back-propagate changes to name or other information to reference.display?
Jason Walonoski (Mar 17 2016 at 12:36):
I agree with Evout on this one. Narrative should not be expected to (but may) include referenced data. I feel the same way about display text. References may not be resolvable, either due to client permissions, or other issues. Also, if the referenced resource changes, the display text would be out of sync.
Lloyd McKenzie (Mar 17 2016 at 12:48):
Is it an issue if the reference.display isn't the same as the equivalent information in the referenced resource due to an update? E.g. If the practitioner gets married or has a name correction, is it a problem if the "display" elements of numerous resources still have the old name?
Jason Walonoski (Mar 17 2016 at 13:29):
Yes, I would consider that an issue. The name change example may not be Earth shattering if they get out of sync. I'm just saying I don't think display text should be a SHALL.
Jason Walonoski (Mar 17 2016 at 13:31):
For analogy, with an HTML <a> link I give a description of the link, but I don't have to -- the link can just be a URL.
Lloyd McKenzie (Mar 17 2016 at 14:15):
Agree it shouldn't be a SHALL. The question is whether it's a "SHOULD" - and whether we perhaps want to treat it as a quality criteria in the examples we generate.
Eric Haas (Mar 17 2016 at 15:37):
+1 ewout and I always kind of assume you would generate the display elements if they are there, so I'm surprised after rereading the spec there is no mention of this. The display elements are there for human eye in the first place so this makes sense to add guidance. Is there any utility in adding a code "generated-plus" to indicate that there is _include data rendered as well?
Last updated: Apr 12 2022 at 19:14 UTC
