Stream: implementers
Topic: DocumentReference contentType search
Gavin Millar (Aug 04 2016 at 01:08):
I have a use case where I want to get all of the documents for a patient but limited to only certain contentTypes (DocumentReference.Attachment.contentType). This looks to not be possible via a standard search. That would mean I need to use a Named Query correct? I've got that working but I'm now struggling to find an example of what the OperationDefinition for the Conformance should look like in this case. Are there any good examples of named query conformances?
Grahame Grieve (Aug 04 2016 at 01:21):
the easiest way would be to add a search parameter for content type
Gavin Millar (Aug 04 2016 at 01:29):
does that imply that something like /fhir/1.0/DocumentReference?subject.identifier=ABC|DEF&content.attachment.contentType=application/pdf is valid? I had assumed that if it wasn't listed as an avaliable search parameter (https://www.hl7.org/fhir/documentreference.html#search) then I needed to do things other ways. Now that I reread I can't see a definite statement to that effect.
If that form is allowed then my life gets much easier!
Lloyd McKenzie (Aug 04 2016 at 01:31):
@Gavin Millar You can define your own SearchParameter resource instances and reference them with your Conformance resource
Lloyd McKenzie (Aug 04 2016 at 01:32):
(In fact, you can't rely on the standard search parameter names - you always need to check the Conformance statement of the server you're talking to as it's theoretically possible for it to bind the standard names to a different search parameter definition)
Grahame Grieve (Aug 04 2016 at 01:32):
the search parameters are defined for convenience. You can add your own search parameters. I'd counsel against naming the search parameter 'content.attachment.contentType') because that looks like a chained search. It's more consistent style-wise to call it 'contentType' or equivalent
Grahame Grieve (Aug 04 2016 at 01:33):
but you need get whatever servers you care about to support your search parameters
Gavin Millar (Aug 04 2016 at 01:43):
OK, I think that all makes sense. I can define my own names for my own search parameters and use them in my server then it's just a matter of adding it as a search-parameter in my Conformance to state the name etc.
Obviously this makes my server distinct in regards to this parameter which is probably fine for my use case (but certainly something to keep in mind)
Grahame Grieve (Aug 04 2016 at 01:45):
yes, you can propose that we add such a search parameter on the grounds that other people might do the same thing
Gavin Millar (Aug 04 2016 at 01:46):
I think that filtering by contentType for documents is fairly reasonable and I'd be keen to see it as part of the spec. Can you point me to where to make the suggestion/case ?
Grahame Grieve (Aug 04 2016 at 01:49):
'propose a change' link tat the bottom of each page
John Moehrke (Aug 04 2016 at 11:16):
@Gavin Millar do you really mean contentType? Or the more specific format? I ask because I expect that contentType might be less useful. Especially since there is only a few types that are likely (pdf, xml,json, etc). Where the format is an indication of the technology and use-case encoding. So format would differentiate between various types of meaning.
John Moehrke (Aug 04 2016 at 11:18):
Further I expect that once you find a DocumentReference that has the content you want; when you then pull the content, the server holding that content could use your requesting (content type negotiation, or _format) to re-format the content to that format. This manipulation would be purely presentation manipulation. Much like http is intended to be used.
John Moehrke (Aug 04 2016 at 11:20):
I put this into the IHE - MHD profile and have gotten many people commenting positively. The reformatting is not mandatory, but enabled by http and _format.
Josh Mandel (Aug 04 2016 at 13:17):
To the extent that "format" and "content type" are both captured in DocumentReference, it's useful to be able to search by both. @John Moehrke, I'm assuming that once you find a particular DocumentReference.content that you want, then GETting the attachment by url should return content according to the format and contentType specified in the DocumentReference. Is this right?
John Moehrke (Aug 04 2016 at 18:36):
@Josh Mandel I am not suggesting that the query parameter should not be added. I am just asking for the use-case where content type is significantly useful. I provide the comments to help illuminate the intent of the parameters and elements that exist. And to point out that in XDS there has never been a need to query by the mime type.
Gavin Millar (Aug 04 2016 at 19:33):
@John Moehrke : Yes, I really mean contentType. Our use case is around displaying a list of PDF documents (initially) as that is what we have the technology to accurately render for the client. Our source in this case has documents of other types (images, CCDA etc.) which are handled elsewhere. So it's not about the meaning of the document but rather it's MIMEtype/contentType etc.
I can understand that a more general case for filtering would be format (or class perhaps) but in our case we would prefer contentType.
John Moehrke (Aug 04 2016 at 19:37):
okay. Include that use-case in the request for the query parameter. Seems reasonable in FHIR. I will note that it won't be supportable by a system that is using FHIR (MHD profile) infront of an XDS/XCA environment. This is NOT an important fact for FHIR specification. I point it out only as an operational perspective.
John Moehrke (Aug 04 2016 at 19:54):
this blog article explains why format ... https://healthcaresecprivacy.blogspot.com/2015/10/ihe-formatcodes-are-mandatory.html
Elliot Silver (Aug 08 2016 at 23:22):
This isn't relevant to Gavin's original question, however...
when you then pull the content, the server holding that content could use your requesting (content type negotiation, or _format) to re-format the content to that format. This manipulation would be purely presentation manipulation.
This is essentially what is proposed for MHD-I: Request an XDS-I image manifest as the specified contentType (application/dicom), and you get back a DICOM KOS (Key Object Selection), request it back as application/fhir+xml, and you get back a FHIR ImagingManifest resource.
Last updated: Apr 12 2022 at 19:14 UTC
