FHIR Chat · Use of DetectedIssue for CDS · implementers

Stream: implementers

Topic: Use of DetectedIssue for CDS


view this post on Zulip Julia Davis (Aug 02 2017 at 06:52):

Hi, sorry, me again,
Our Medications Management application runs CDS prior to creating a medication order in the database. When a 3rd party application Posts a MedicationRequest we also perform the same CDS processing. It's quite clear from the documentation that we need to return any CDS errors to the 3rd party application via the DetectedIssue resource but we are not 100% how we should use it.
If we have a drug to drug interaction for example and the medications interacting have been posted as 2 MedicationRequests in a bundle we intend to create a DetectedIssue for each MedicationRequest with a reference pointing to the other medication.
We have a couple of issues, firstly, when we return the response to the post do we return the Bundle and link the DetectedIssue(s) to the relevant MedicationRequests or do we return the Bundle including the DetectedIssue(s) within the MedicationRequest?
We understand that if the 3rd party application retries the Post the have the DetectedIssue and Mitigation included in the MedicationRequest but are not sure if we are allowed to / supposed to include the DetectedIssue.
The other issue is that until we create the Medication Order in our DB we do not have an identifier for the MedicationRequest so we are not sure how we are supposed match the resubmitted request if we do not assign an identifier.
Any help greatly appreciated as always.

view this post on Zulip Grahame Grieve (Aug 02 2017 at 07:52):

what's the bundle? a transaction?

view this post on Zulip Julia Davis (Aug 10 2017 at 00:54):

@Grahame Grieve Hi Grahame, sorry I got dragged off on other things. Yes, this would be a transaction as we would expect all CDS warnings to be mitigated against all the relevant MedicationRequests before we would create / update any of the "orders" in the application.

Cheers

Julia

view this post on Zulip Bryn Rhodes (Aug 22 2017 at 16:54):

@Julia Davis @Grahame Grieve If I understand correctly, this is happening as part of processing a POST of a MedicationRequest resource, and that if there are detected issues, they will prevent the server from actually creating the order. In that case, you'd have to return an error status and an OperationOutcome indicating the result, right?

view this post on Zulip Julia Davis (Aug 22 2017 at 22:50):

@Bryn Rhodes Rhodes Hi Bryn, yes our intention is to return an OperationOutcome notifying that the POST transaction failed and including the actual clinical issues with the MedicationRequest in DetectedIssues.

view this post on Zulip Bryn Rhodes (Aug 22 2017 at 23:03):

So how will the DetectedIssue resources be made available to the calling application? Would they be included as "contained" resources in the OperationOutcome you return? Or would the calling application need to make a separate request to retrieve the DetectedIssues?

view this post on Zulip Julia Davis (Aug 22 2017 at 23:56):

We are planning on including the DetectedIssue(s) as "contained" resources when we return the MedicationRequest and OperationOutcome. Although we are not sure (hence my original post) if this is allowable or if it is only the calling application that can include the DetectedIssue and associated Mitigation as contained resources in the resubmitted MedicationRequest

view this post on Zulip Bryn Rhodes (Aug 23 2017 at 14:28):

I can see them being returned as part of the OperationOutcome, or even on the MedicationRequest, but if they are on the MedicationRequest, you'd then have to include that in the OperationOutcome as well, so it may be cleaner to only return them in the OperationOutcome. As far as how to reference the MedicationRequest from the DetectedIssue, you could use an identifier on the MedicationRequest and have the reference from the DetectedIssue be by identifier.


Last updated: Apr 12 2022 at 19:14 UTC