Stream: implementers
Topic: US-core DocumentReference modeling
frank cao (Aug 06 2021 at 15:07):
US-core DocumentReference is used for general purpose clinical documents. The content element with attachment is set to mandatory. How would I support text only reports with the profile as a document contributor? Should I generate an xhtml format of the textual content and put that in the content field?
Michele Mottini (Aug 06 2021 at 16:37):
Plain text should be fine, no need to generate XHTML
frank cao (Aug 06 2021 at 18:54):
Thanks. So if I want to send each text line similar to OBX segments, I need to 1) produce a text file and put it in the content field, and 2) put each text line in an observation resource and put it in context.related. Is this a good implementation?
Michele Mottini (Aug 06 2021 at 18:57):
Not sure what would be the purpose of the Observations (?) - and context.related is not a US Core must support, so most (all?) systems will ignore it
Michele Mottini (Aug 06 2021 at 18:59):
If 'text only report' = something like a radiology report then no, no separate Observations needed
frank cao (Aug 06 2021 at 19:17):
It could be something like a discharge summary or consultation note, but we don't expect systems to be able to support the IPS style. We have a existing v2 implementation that uses OBXes for the report text. That's why I want to replicate that with observations. Is that an overkill? If I want to support a text only diagnostic report such as cardiology, should I ignore result[x] and just use presentedForm?
Michele Mottini (Aug 06 2021 at 20:58):
I'd say overkill. And yes, text-only report like cardiology would be a DiagnosticReport with a presentedForm and not result. result is for things like lab panels
frank cao (Aug 12 2021 at 14:10):
Thank you. Is there any downside to just use document bundle for all the document types I want to support?
Michele Mottini (Aug 12 2021 at 14:19):
Yes, clients would not handle that
Lloyd McKenzie (Aug 12 2021 at 14:20):
You generally won't see SMART apps or CDS hooks services that have any ability to dig inside a document wrapper. It's pretty much impossible to search on the content of a document unless you're just looking at header information.
Lloyd McKenzie (Aug 12 2021 at 14:20):
Similar issues for other types of clients.
John Moehrke (Aug 12 2021 at 14:33):
frank cao said:
Thank you. Is there any downside to just use document bundle for all the document types I want to support?
The fact that you have a FHIR-Document made up of Composition and a bunch of other stuff, does not mean that the only access to the Composition and the other stuff is through a Bundle. The document Bundle would only be useful for specific scenarios. Such as pushing to a remote recipient, publishing into a nationwide exchange, or covering the whole content with a digital signature. I expect that others will attack me for promotion of these benefits of a document bundle. I am not saying that RESTful access to these as resource is not a good idea. I am just answering your question of when is a document bundle beneficial.
John Moehrke (Aug 12 2021 at 14:35):
downsides, I fully agree with Michele and Lloyd. I fully agree with them that making the data available in RESTful resource form is proper. I just also see use-cases where a document bundle is ALSO proper.
frank cao (Aug 12 2021 at 16:00):
Thanks. I agree with Lloyd about the inaccessability of discrete data when wrapped in a document bundle. However if we only care about accessing those data as part of the document, it should be fine. For querying documents, I'd like to only use DocumentReference for simplicity and we can include discrete data in it too, if I'm not mistaken.
Lloyd McKenzie (Aug 12 2021 at 16:11):
Keep in mind that even if your system will only want to access the data in the context of a document, that won't necessarily be true of other systems.
frank cao (Aug 12 2021 at 19:06):
Agreed. We'll take it for consideration. Much appreciated for your help!!
Last updated: Apr 12 2022 at 19:14 UTC
