Stream: implementers
Topic: regenerate text
René Spronk (Mar 25 2019 at 05:11):
If systems A and B both have the capability to generate Resource.text, and A sends a resource to B where the resource contains 'generated text', then B could safely regenerate that text to use its own layout. (opinions?)
Use case is the regeneration of text in FHIR documents, then one discovers (in general) the crappy XHTML used in most examples. FHIR documents will have to look at least as good as CDA documents.
Richard Townley-O'Neill (Mar 25 2019 at 05:21):
Is generated text in a document attested content?
René Spronk (Mar 25 2019 at 05:37):
That's a related interesting question.
In my use case, the document-author grabs resources from a server, regenerates the text, and assembles a document. As such this issue doesn't really come into play.
Richard Townley-O'Neill (Mar 25 2019 at 05:51):
I'd say that B can safely generate the resource, to produce an equivalent, but different, resource.
Richard Townley-O'Neill (Mar 25 2019 at 05:59):
The reader of the resource would need to know that both systems have compatible ideas of what counts as core elements.
http://build.fhir.org/valueset-narrative-status.html : "The contents of the narrative are entirely generated from the core elements in the content."
Richard Townley-O'Neill (Mar 25 2019 at 06:00):
It sound like it should work in theory, but would be hard to trust.
Grahame Grieve (Mar 25 2019 at 07:35):
my take on this is:
-
in general, a recipient can always regenerate the text. Whether that's safe is dependent on the context. It's much more likely to be safe if the source is 'generated'. But safety is always dependent on the gap between the system's behaviour and the user's expectations of the system's behaviour
-
in a document, the specific text is attested, and regenerated text is not what was attested
Lloyd McKenzie (Mar 25 2019 at 13:49):
If you do anything to the instance on receipt - regenerate narrative, drop extensions, default elements, whatever - then you've performed a transformation and should ideally capture a provenance record reflecting that. When you receive a document, you should store it as a Binary and perform no transformations at all. I.e. retain all elements, don't add any, don't regenerate anything. Because that's the only way to ensure that you retain the original attested content. If you perform a transformation, then there's a risk that the attestation has been invalidated.
René Spronk (Mar 26 2019 at 04:44):
Back to my original use case: the author of a yet-to-be-instantiated document pulls some resources from a server and assembles a document, regenerating the text (because the layout of the existing XHTML snippets is not usable for document display purposes) for those resource that have "generated" text. Attestation isn't an issue in this context.
One can never be sure how "safe" any generated text will be, one can only assume that those that generate text will faithfully render the key structured data for a human reader.
One of the key drawbacks of text being XHTML instead of cda-style markup is that we've lost almost all flexibility when it comes to how one wishes to render the narrative, so regeneration of text now becomes a necessity. What I mean by that: any author of any resource can just use any style of XHTML they please, which may or may not be suitable for use in a particular use-case (e.g. documents) or display type.
Last updated: Apr 12 2022 at 19:14 UTC
