Stream: analytics on FHIR
Topic: using 'contained' resource in plan definition
Tushar Nair (Aug 05 2019 at 21:16):
We are trying to use CDS Hooks for the for solutioning a CDSS use case. One of the requirements is to provide the proof/justification that the elements satisfying the rule that triggered the alert have to be conveyed back in the CDS Hooks response. To do this we intend using a 'contained' resource which shall act as a bucket to showcase the resources that triggered the alert. e.g. If the patient is suffering from Diabetes for the past 10 years and and is above 50 yrs then trigger an alert for something. So while conveying the alert in CDS Hooks I want to show case the resources that triggered this alert which might be 'Condition containing Diabetes code and Condition-onset date along with Patient resource containing the age of the patient. We intend using the 'Contained' resource in the 'Plan Definition' so that CQL when executed brings back a list of resources against a given expression as an output which can be placed in the 'contained' resource. In order to do this, I am assuming we'll have to add it as an extension on the Plan Definition. Is that the correct approach to be taken, or there's a better way to do that. @Lloyd McKenzie , @Bryn Rhodes -thoughts.
Lloyd McKenzie (Aug 05 2019 at 22:38):
Contained resources are not intended to be used as a handy transport mechanism. A resource should only be sent as 'contained' if it has no independent existence from the containing resource. (And if a resource is contained, then it's going to stay that way and will be contained in the same resource for its lifetime - or at least until enough information is gathered that it can live as an independent resource, at which point the contained resource will be dropped and a reference to a stand-alone resource will be added.)
Lloyd McKenzie (Aug 05 2019 at 22:39):
Adding @Kevin Shekleton and @Isaac Vetter for their thoughts on the use-case.
Lloyd McKenzie (Aug 05 2019 at 22:39):
In general, if you want to bring back a bunch of resources with FHIR, you should be looking at Bundle.
Isaac Vetter (Aug 05 2019 at 23:53):
Hi @Tushar Nair, regarding CDS Hooks, do note that there is a simple extension mechanism: https://cds-hooks.org/specification/1.0/#extensions
Isaac Vetter (Aug 05 2019 at 23:58):
I haven't been able to think up a real world cds use-case which would require a clinician to justify the use of the cds service in the request. Can you help me understand? Do note that the cds service is given short term access to the client's FHIR server. Is it reasonable for the cds service to simply query?
Isaac Vetter (Aug 06 2019 at 00:08):
Hey Tushar, also note the the fhir resources in context are meant to communicate at least some this information. Are you familiar with this:https://cds-hooks.org/specification/1.0/#hook-context-and-prefetch ?
Tushar Nair (Aug 06 2019 at 19:46):
@Isaac Vetter The justification is not entirely meant for clinicians alone there are other players like -care managers, coordinators etc. The ask is coming from that direction.
The 'extension' as well as 'prefetch/context' elements belong to the CDS Hooks request construct. My questions is specifically related to the CDS Response construct. The thought is to send a CDS Hooks Request which shall trigger the relevant 'PlanDefinition'. We are trying to extract the output of the CQL expression upon executing the relevant 'PlanDefinition>Actions & capture the expression output, which may contain a list of FHIR resources, used to execute the CQL Expression and thus considered as justification data. This set of resources(Justification information) need to be vended out in a corresponding CDS Hooks Response . Hope this clarifies the use case. We were thinking of using the 'Bundle' resource as an extension in the 'Plan Definition resource as well as CDS Hooks Response -card to present the justification information to the end-users along with the standard alert information. Your thoughts & suggestions.
Bryn Rhodes (Aug 07 2019 at 02:58):
Depending on the CDS use case, the resulting resource may be something like a Request (MedicationRequest, ServiceRequest) or a DetectedIssue or Flag. Each of these resources have specific facilities for communicating this type of information (as supportingInformation). Is there a reason you wouldn't just include references to the resources that were used to infer the response using the supportingInformation element?
Bryn Rhodes (Aug 07 2019 at 03:00):
In addition, if the resources you used to make the inference came from the calling EHR in the first place (i.e. you obtained them through the FHIR endpoint given you to you as part of the CDS request from the EHR), why would you need to communicate the full resource back? Shouldn't it just be a reference to the resource you used?
Tushar Nair (Aug 14 2019 at 22:57):
Thank you @Bryn Rhodes
Last updated: Apr 12 2022 at 19:14 UTC
