Stream: implementers
Topic: FHIR document search and inclusion of Provenance
Shovan Roy (May 15 2019 at 23:55):
Hi All,
I'm working on a custom FHIR view and wondering if the community can provide me a guidance on the following query:
Summary:
How to instruct (url query param) FHIR server to include Provenance resource or not in a FHIR document?
Background:
Currently I'm working on designing a custom FHIR view which will be used to retrieve summary details from bunch of pre-persisted FHIR documents. as per our design, the custom view has multiple sections and each section contains series of QuestionnaireResponse resources. The QuestionnaireResponse resources are constructed by extracting data from the the source FHIR documents.
*Please note that the source FHIR documents mostly contains resources like Observation, MedicationStatement, Immunization etc. and they are converted to QuestionnaireResponse while constructing the custom view. Separate APIs are provided on each resource type to perform search if the client choose not to use QuestionnaireResponse based view model.
We have a requirement that the Client system may request the reference of the source FHIR document corresponds to each section of the Custom View (Composition). Other than extension in the section, we are thinking of including Provenance resource in the Bundle document for that purpose.
Query:
Is this a good idea to solve this requirement using Provenance? if yes then can this be achieved using the _include param? for an example, can the url be constructed as follows?
GET:[base]/fhir/v1.0.0/Composition/$view?patient=1233445&type=LP96944-1&_include=Provenance
Any suggestion would be greatly helpful
Looping in @Grahame Grieve , @Reuben Daniels , @Nichol Hill , @Richard Townley-O'Neill , @Brett Esler
Lloyd McKenzie (May 16 2019 at 00:38):
Note that $view is not a query, it's an operation. It's also not a standard-defined operation, so it could do a wide variety of things - it all depends on what the operation is defined to do and what parameters it takes. Note that making any modification to the content of a document (including adding Provenance information) would breaking any digital signatures that existed and, for at least some systems, would cause the returned product to be treated as a distinct document instance with its own identifier.
Grahame Grieve (May 16 2019 at 01:30):
Why not use $document per the standard?
Shovan Roy (May 16 2019 at 01:56):
Thanks @Lloyd McKenzie and @Grahame Grieve ,
@Grahame Grieve , the only reason I didn't choose the $document due to the list of defined input parameter. in our requirement we need to instruct the server about the type of view to be generated/retrieved and for whom (patient) along with mentioning if the source Questionnaire to be included etc. However the standard $document only has 'id', 'persist' and 'graph'. Is it allowed to modify the param list of the default $document? then I'll be happy to extend that. Alternatively, can this GET invocation be controlled using the allowed search parameter of Composition in context? any suggestion ?
@Lloyd McKenzie, thanks for the suggestion. I've included another parameter in the $view OperationDefinition. regarding the signature, in our requirement we don't include the signature on the custom generated view. The sources documents may have signature and they are immutable. The custom view will provide the reference to the source documents.
Grahame Grieve (May 16 2019 at 02:02):
You can add parameters, though they need to have possible default values, I think
Shovan Roy (May 16 2019 at 04:04):
thanks @Grahame Grieve , if I want to use the custom params in the standard $document, then shall I use the standard document as "base" in the OperationDefinition? I tried that and publisher didn't complain about anything. I think I'll not be able to provide any default value for the custom param I've added. operationdefinition-ncdhc-composition-document.json
Grahame Grieve (May 16 2019 at 12:30):
I think that the publisher would not complain about anything related to operation derviation right now - it just doesn't check.
Grahame Grieve (May 16 2019 at 12:30):
but it is right to do what you did
Grahame Grieve (May 16 2019 at 12:31):
what custom parameters did you add?
Shovan Roy (May 16 2019 at 21:58):
I've included the following custom parameters:
1. patient (Patient resource): The patient in context
2. type (Coding): document type
3. isIncludeSectionSource (boolean, default false): This parameter instruct the FHIR server to include the reference of the source based on which the section/s of the document is built
4. isSummary (boolean, default true): This parameter instructs the FHIR server to produce a document with minimum details (as defined by server). the default value is true. If client wants full document then the value should be provided as 'false'. In that case the server will provide the referenced resources in the Bundle. For an example if the $document generates a view where each section of the document is based on QuestionnaireResponse then 'false' value of this param will force the server to include the referenced Questionnaire resource in the Bundle document. 'false' will override the value provided in 'isIncludeSectionSource'.
operationdefinition-ncdhc-composition-document.json
Grahame Grieve (May 16 2019 at 22:35):
why add a patient parameter? how can it be different to what is specified in the composition?
Grahame Grieve (May 16 2019 at 22:36):
this looks like a different operation, to synthesize a document from scratch. why? Where's the human attestation? I wonder if this is a document? Maybe this is not really document work, and it overlaps with IPS? (@Rob Hausam )
Shovan Roy (May 16 2019 at 23:41):
Thanks Grahame, If the search parameter of the $document operation can be controlled by the Composition in context, then we don't need the 'patient' and 'type' input search parameter. I was not sure if that can be used. Though that was my first approach and I was checking if _include can be used as well. Please see the first post in this topic for more details.
We have the requirement to generate/present a consolidated view to the consumer.
The consolidated view is generated taking input from existing multiple FHIR documents.
This is a system generated view and attested by Organization and authored by Device
The consolidated view consists of multiple sections and each section represents a source FHIR document. Each section contains series of QuestionnaireReponse resources. These QuestionnaireReponse are derived from the resources from the source FHIR documents.
The Client system may request to include the reference of the source FHIR documents in the consolidated view.
We thought of designing this custom view in the form of FHIR document and proposed a custom operation $view.
Thoughts ?
Grahame Grieve (May 17 2019 at 00:05):
well, you are asking the system to synthesize a new compostion, compose a document around it, and return the resulting thing?
Shovan Roy (May 17 2019 at 00:07):
yes, right.. there is a possibility that we will pre-create the document to optimize read time performance.. but from a Client perspective they are asking the server to generate a new document ( a consolidated view)
Grahame Grieve (May 17 2019 at 00:14):
@Rob Hausam has there been any dsicussion in the IPS context of how to ask for an IPS document to be created?
John Moehrke (May 17 2019 at 13:18):
so, add to $document a FormatCode which indicates the canonical URI of a StructureDefinition of the document you want. would that work?
John Moehrke (May 17 2019 at 13:20):
This is similar to how OnDemand documents are handled in XDS/XCA; the differences is that the custodian publishes which document types they are capable of creating. In this way the XDS OnDemand document entry is similar to a FHIR CapabilityStatement listing the potential support that custodian FHIR server is able to return.
Grahame Grieve (May 17 2019 at 22:20):
$document as it is is defined as packaging a pre-existing Composition. This operation is creating Compositions and then packing them. I think that's a different operation
Grahame Grieve (May 17 2019 at 22:21):
and it would be a graph definition, not a structure definition. Though most systems will simple offer a pre-defined selection of the kinds of documents that could be generated
René Spronk (May 18 2019 at 06:54):
@John Moehrke Well, if in MHD the document is retrieved using an URL contained in DocumentReference.attachment, then that URL could be of a FHIR operation. Strictly taken (although MHD is probably silent on this) one would have to GET that url as-is, but it's entirely feasible to allow a retrieving-client to add some parameters to that URL, e.g. summary=true or language=spanish (if a document is multi lingual or one has auto-translation features).
To specify a document type as part of the URL seems a bit of a stretch (after all, what doc type would the on demand document have in this case?), but it'd be possible. GraphDefinition (as a parameter) allows a retrieving-client to exclude certain parts of the data, whereas it is not the author of the data and as such won't have a clue if its own restrictions are an issue in terms of patient safety. In general it's safer to allow the author/originator of a document to decide what to include in a composition/document. I don't see a problem with things like summary=true, for both the author as well as the retrieving-client both are aware of this very well defined subset. But allowing a client full flexibility to subset a composition seems tricky to me.
John Moehrke (May 18 2019 at 13:43):
Note, I was not suggesting the historic XDS OnDemand is the solution. Just that the use-case is today satisfied by that solution. And that the XDS OnDemand does enable dynamic discovery of the kinds of documents that could be built -on demand-. Yes, today this is just a GET on the url found in the DocumentReference, which is unconstrained, and clients are required to simply GET. They can't mess with the URL. They just GET. They can add http negotiate to see if they can get a different mime-type encoding. In this way a medical summary could be retrieved (GET) in PDF, HTML, TEXT, CDA, FHIR XML, or FHIR JSON. Not as elegant as FHIR will enable, but useful.
Shovan Roy (May 20 2019 at 04:58):
thanks @Grahame Grieve , @René Spronk , @John Moehrke
I'm happy to manage using the summary=true/false.
I've included 'type' in the url param to figure out which view/document needs to be generated. For an example, we have the business requirement to generate a longitudinal view of a baby patient based on the following events:
1. Birth
2. Discharge
3. Immunization
4. Bloodshot Screen
5. Hearing Screen.
I'm grouping all of them to one view type and calling it as birth(BRTH)..
Where as the client system can request for another view of the same child which includes details only on 'Health Check Assessments and Examinations'.
The details that will be provided varies from Consumer accessing the document (view) vs Provider accessing the document (view).
Initially I though managing this using search by 'section' (Composition.section.code) of the composition (full longitudinal view) . But that may over complicate the servers implementation. So trying to manage it using the 'type' (mandatory element in Composition). The documents will be generated based on the type provided.
any alternative suggestion?
John Moehrke (May 20 2019 at 11:52):
I like that you are using the word "View" for this perspective. In the context of XML based content, it could be seen as technically being implemented by various XML stylesheets that hide (or down-play) some information, while elevating and emphasizing others. Where there is a stylesheet for each of these views. All using the same underlying data bundle. This works nice in XML. In this way the "Interoperability" layer is consistent, while the "Presentation" layer is perspective specific. This was also discussed earlier in this zulip thread with having the perspectives as intermediary that apply the view filtering.
Shovan Roy (May 20 2019 at 22:54):
Thanks John, much appreciated..the discussion has been useful and interesting
lastly, I would like to double confirm with the group if I can use the following url to generate the document that I explained in the post
GET:[base]/fhir/v1.0.0/Composition/$document?patient=1233445&type=ncdhc-system|BRTH&summary=true
if yes, then the params like 'patient', 'type' do I have to define them as a part of the OperationDefinition or it can be used directly since these are search params in Composition? in the case the only parm I'll need to define in OperationDefinition is the 'summary'
Shovan Roy (May 26 2019 at 23:16):
Hi All,
First of all I'm sorry for coming back to this again. I'm still undecided how to model this requirement in FHIR. As per our discussion I'm assuming that I can use the url as GET:[base]/fhir/v1.0.0/Composition/$document?patient=1233445&type=ncdhc-system|BRTH&summary=true.. is this correct?
I was reading the spec for List and not sure if our requirement may best be solved using a FHIR Composition document or a List of List. The advantage of List of List as per my understanding is that I can specify it as a working/snapshot of some existing data which may change over the time ( more may get added).
To provide the context, I'm summarising the requirement once again
1. Our System Collects Patient's (baby/child) related details in multiple FHIR documents (Birth, Discharge, Health Check Assessments, Examination, Immunization etc)
2. We store the incoming FHIR documents as immutable resources as well as discrete resources after extracting them from the Bundle.
3. We are exposing APIs for each of the resource types mainly with GET operations
4. We have requirements for our APP to represent few Consolidated Summary from selected FHIR documents. These are pre-defined. Example: We have a 'Birth Summary' which contains data from multiple documents like: Birth (Delivery) FHIR document, Discharge FHIR document, Immunization FHIR document and Screening (Bloodspot and Hearing) FHIR document. We are thinking of exposing an API using QuestionnaireResponse. Where the contents from each of the resources are extracted in the form of QuestionnaireResponse. As mentioned before we are thinking of exposing it as FHIR view using the $document custom operation. Client system may request the source document from which the QuestionnaireResponse is being built.
After looking at the List, I was thinking if it will be a better idea to represent it as List of List since the content may grow over time. For an example there could be more Immunization added in future.
It will extremely helpful if further guidance is provided. @Grahame Grieve @Lloyd McKenzie @John Moehrke @René Spronk may I request you to share your thoughts around it?
Lloyd McKenzie (May 27 2019 at 03:04):
It would be a different operation than the 'standard' $document, but it could work.
QuestionnaireResponse is fine if the primary purpose is to support rendering, but it won't really let recipients understand the data. I'm not totally following the rationale for List of List as opposed to a straight List. Is it to track what gets added when? If so, have you considered just including Provenance records in your collection that shows what got contributed at what point?
Shovan Roy (May 27 2019 at 03:48):
Thanks @Lloyd McKenzie , Here are my comments
[LM] QuestionnaireResponse is fine if the primary purpose is to support rendering, but it won't really let recipients understand the data.
[SR] Yes, the main objective is to provide the support for rendering in a much lighter weight way than providing the actual resource. This gives us an option to control the Questionnaire and changes to it. To make it working with data, along with providing the answer of the question, we are also providing the actual resource reference of the source data as an item in the QuestionnaireResponse. I've attached an sample in-case you are interested to have a look.
[LM] I'm not totally following the rationale for List of List as opposed to a straight List. Is it to track what gets added when? If so, have you considered just including Provenance records in your collection that shows what got contributed at what point?
[SR] my idea was that each of the inner list will represent content from each type of source document (Birth/Discharge/Immunization etc.). But I can see that there is no need of it since the the whole QuestionnaireResponse represents the document itself. If required, I can add an extension on the List.entry to provide the reference of the source document.
Out of the two options: Composition document vs List, which model do you suggest is a better FHIR implementation in this context. From APP perspective, implementation is almost similar for both the approaches, however wanted to make sure that we picking a sensible FHIR complaint approach in our FHIR server design.
René Spronk (May 27 2019 at 06:41):
In general the use of documents only makes sense if there's a reason to persist specific sets/versions of data, and/or if there's narrative that some author wishes to assert. If these factors are not of importance, you should be looking at alternatives.
Lloyd McKenzie (May 27 2019 at 13:12):
If your focus is just delivery, it's probably cleanest to use a 'document' Bundle for each summary and skip List entirely. However, if you want to curate the contents of the different consolidated summaries and maintain only one copy of the source materials, then List is reasonable (and you'd use that to guide generation of the 'document' when the time came)
Last updated: Apr 12 2022 at 19:14 UTC
