Stream: implementers
Topic: PDF2FHIR
Alexander Henket (Nov 14 2016 at 18:51):
I have a sort of funky use case: around 60% of the Spirometer devices in The Netherlands come from 2 sources. Apparently those devices cannot do anything beyond PDF as output and the underlying function results are unobtainable. Sort of fortunately it is textual PDF, and again sort of fortunately you can run PDF to Text and process from there. Like I said: a funky use case.
The thing is this: I want to send the base PDF along with the extracted observation information. The PDF concerns a panel of results. I thought of doing that inside the Observation.text as <object type="application/pdf" width="100%" height="100%" data="data:application/pdf;base64,JVBER..."/> but there is an invariant txt-1 in the way:
The narrative SHALL contain only the basic html formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard
The object tag is in chapter 13 of the HTML 4.0 standard.
Am I principally looking in the right place by looking into Observation.text?
Why is there an invariant referring to HTML 4.0 when Resource.text is actually XHTML?
I understand that <object/> opens up a realm of hacking possibilities but does that outweigh the potential for rich Resource.text?
For reference of what the result could look like using <object/>: http://40.68.112.13/fhir/Bundle/spirometer-panel?_format=html
John Moehrke (Nov 14 2016 at 18:59):
Sounds like you have a need for a DocumentReference.
Alexander Henket (Nov 14 2016 at 19:00):
How so? I can convey the thing in Observation.valueAttachment and I will, but I would like it rendered to the user directly
Alexander Henket (Nov 14 2016 at 19:01):
Note: we are talking loosely coupled systems so I need to send everything in 1 Bundle. There's no following links from contents possible
John Moehrke (Nov 14 2016 at 19:34):
You can put anything you want into a Bundle... so it can include DocumentReference. I was recommending DocumentReference so that the PDF could be more accessible, more completely described (meta)... But if you think that is not needed, then yes put it inside. I am just offering observations on options available.
Alexander Henket (Nov 14 2016 at 19:40):
While a DocumentReference doesn't help me in my initial question which is about rendering it as part of the Observation.text, it could lead me on a different path for Observation.valueAttachment. However currently I have all meta I need in the Observation already. (Patient, Author, Filename, Filetype etc.)
Looking at DocumentReference it looks as if instead of Observation as focal Resource, I could have used DocumentReference and connect the parsed stuff through DocumentReference.context.related.ref. Is that what you where hinting at?
John Moehrke (Nov 14 2016 at 19:43):
possibly, yes. I was simply noticing the source of truth was a Document (PDF), so it occurred to me that it might be then best initially stored/indexed in DocumentReference. Many objects get decomposed out of documents.
Alexander Henket (Nov 14 2016 at 19:44):
A valid point. I must say I was mostly focussing on what came out of the PDF, rather than the PDF being source. So do you know of any example as funky as mine that could serve as prior art/source of inspiration?
Lloyd McKenzie (Nov 14 2016 at 23:22):
Definitely not a fan of allowing Object. You can do an image reference to it as a contained Binary though. I wonder if Observation.related should also support Binary and/or DocumentReference? I suspect there'll be lots of Observations that are based on things that aren't directly expressible as FHIR.
Alexander Henket (Nov 14 2016 at 23:27):
I'm sure both are possible improvements to Observation, but that still does not address:
1. The Human readable part in Observation.text
2. The duplication of data in Observation.text + .valueAttachment of potentially a lot of data
3. The question why HTML 4.0 is called for in an XHTML context
4. The question whether or not FHIR should limit HTML instead of leaving it implementers (even if that comes with a big fat warning for <object/>)
Back in CDA, one could reference between section.text and entries. Actually it feels like that is missing here. If I could link to or from Observation.text and a contained/bundled resource, then I'm golden
Alexander Henket (Nov 14 2016 at 23:33):
Did you by any chance check out http://40.68.112.13/fhir/Bundle/spirometer-panel?_format=html. It sure helps the thing just renders without any particular special software except the browser. It is actually the FHIR part that makes stuff more complicated: none of the links to contained resources render properly.
Lloyd McKenzie (Nov 14 2016 at 23:36):
Duplication of data isn't necessarily unusual. If you go the Binary + img route, you'll avoid duplication - and will still be compliant. I suspect HTML 4.0 was called out because it was a clean way to identify the non-permitted content. If there's an equally easy way to refer to the prohibited content using the XHTML spec, feel free to submit a change request proposing wording.
Lloyd McKenzie (Nov 14 2016 at 23:38):
I don't think your use-case justifies opening the bag of worms that allowing Object would create. The whole point of narrative is that it's easy for all implementations to consistently render the narrative. If you throw Object in, that throws that capability out the window (along with introducing lots of security risks). Narrative is a fall-back mechanism. As such, it needs to be relatively simple.
Alexander Henket (Nov 14 2016 at 23:45):
Not sure why rendering object would be difficult. You either have the required plug-ins or you don't in the browser/webframe etc. If you don't you can use the standard mechanism for getting it if you so please. But anyway, I don't feel like opening up a can of worm today or any time soon over this, so I've rewritten the <object/> to an <img/> with the same construct. It looses a number of functions that way, such as pages, annotations and then some, but works and is within spec.
Alexander Henket (Nov 15 2016 at 00:00):
I checked XHTML just now. The subtitle for XHTML is:
A Reformulation of HTML 4 in XML 1.0
So with that it's probably not weird to go back to HTML 4 for that invariant. XHTML does not have convenient chapters to refer to. No need to file a change request
Grahame Grieve (Nov 15 2016 at 00:37):
yes that's why reference html 4
Grahame Grieve (Nov 15 2016 at 00:38):
i didn't follow how referencing between section text and entries would solve this problem
Grahame Grieve (Nov 15 2016 at 00:39):
I still feel comfortable with not allowing object. If you have a renderer that's customisable enough to support object safely, then you have one that's customisable enough to do it's own rendering and use <object> if it wants to
Last updated: Apr 12 2022 at 19:14 UTC
