Stream: implementers
Topic: Use of ActivityDefinition within Clinical Decision Support
Katie Wheatley (Feb 08 2019 at 07:18):
We are defining a FHIR Restful API using FHIR STU3 for our Clinical Decision Support service, which uses two systems, the EMS and the CDSS.
The Encounter Management System (EMS) invokes the appropriate Clinical Decision Support System (CDSS), which stores and retains a set of clinical content rules that guide the triage process to an outcome.
The triage process is initiated when the EMS selects a ServiceDefinition from a selected CDSS and the $evaluate operation is invoked by the EMS. The CDSS returns the GuidanceResponse resource detailing the suggested outcome to the triage process or additional data it requires as part of the triage process which is detailed in a referenced Questionnaire resource.
One of the suggested outcomes is redirection to a different ServiceDefinition as the current cycle of Clinical Decision Support has completed. As the element GuidanceResponse.result only has the choice Reference(CarePlan | RequestGroup), in order to achieve this redirection we are considering:
• Selecting RequestGroup and setting the element RequestGroup.action.resouce to reference the resource ‘Activity Definition’
• In Activity Definition, populate the element ActivityDefinition.Library.dataRequirement to match the contents of the element ServiceDefinition.trigger.eventData for the new ServiceDefinition that the EMS is to be re-directed to progress with.
Questions
1. The RequestGroup.action.resource does state “The target resource SHALL be a Request resource with a Request.intent set to "option".” Would referencing an ActivityDefinition at this element be FHIR Conformant? The specification does state ”An activity definition provides a reusable template that can be used to construct specific request resources such as ProcedureRequest and MedicationRequest.”
2. The suggestion above does seem like a complex approach for redirection to a new service definition, given that these additional resources (ActivityDefinition and Library) are solely defined to achieve this outcome by the CDSS. Could anyone suggest a more efficient approach on how this can be achieved?
Lloyd McKenzie (Feb 08 2019 at 17:00):
1. No. RequestGroup is intended to be time-bound and subject-specific. However, you could say "Do this care plan", where the care plan essentially says "instantiate this protocol)
2. @Bryn Rhodes
Bryn Rhodes (Feb 08 2019 at 23:21):
RequestGroup is used if you need to preserve optionality among requests. If the outcome of your decision support is that some other decision support should be run, you could represent that with a CarePlan directly. Return a CarePlan with an activity.detail.definition that specifies the action you want to run. The STU3 CarePlan does not allow for ServiceDefinition to be one of those things, but you could use an extension to do that.
Bryn Rhodes (Feb 08 2019 at 23:23):
Having said that, I'm curious about the implementation. Note that there is a __Note to implementers__ on ServiceDefinition in STU3 stating that the resource is deprecated and will be removed in R4 in favor of a CDS Hooks approach. In R4, it's possible to use a PlanDefinition to model the behavior you want to have run behind a CDS Hooks endpoint, so PlanDefinition would be a potential target for the functionality moving forward (and CarePlan does support pointing to a PlanDefinition in STU3).
Lloyd McKenzie (Feb 08 2019 at 23:43):
No need for an extension. You'd just have the activity.activityDetail.instantiatesCanonical point to the definition.
Katie Wheatley (Feb 13 2019 at 07:18):
Thank you both for your responses. It was incredibly useful that you confirmed that it is not conformant to use the ActivityDefinition resource in the way I outlined.
We are using STU3 at present, so while I am aware that the ServiceDefinition resource is deprecated in R4, it is not possible currently for us to move to R4. However, your comments will be borne in mind, should we be in a future position to move to R4.
Thank you for suggesting ways in which we could reference a chosen ServiceDefinition from CarePlan. However, we are using a Data event triggering event rather than a Named event, so this approach would not be possible for us.
David Waters (Mar 01 2019 at 14:27):
This does not fulfil the requirement - the need is to identify the trigger of a new ServiceDefinition - not an actual ServiceDefinition. The resource must allow the CDS to define the trigger requirements of the next decision support
David Waters (Mar 01 2019 at 14:29):
Having said that, I'm curious about the implementation. Note that there is a __Note to implementers__ on ServiceDefinition in STU3 stating that the resource is deprecated and will be removed in R4 in favor of a CDS Hooks approach.
The note in STU3 says that the two will be aligned (As part of FHIR Release 4, it is the intention to unify the CDS Hooks specification with the Clinical Reasoning module), not that one would be deprecated in favour of the other
Last updated: Apr 12 2022 at 19:14 UTC
