Stream: cds hooks/github
Topic: docs / Issue #123 CDS hook calls as part of a FHIR-based ...
Github Notifications (Dec 03 2017 at 08:20):
vlindhol opened Issue #123
Hi!
I'm working on a CDS service that will provide so-called "CarePlan templates". What this means is:
- A patient has a CarePlan, which describes his or her entire interaction with my country's healthcare system.
- When using different services, this patient may be put on individual "tracks" or "sub-plans". An example would be if the patient is diagnosed with heart disease, at which point some heart disease-related protocol is activated for him, containing some predefined set of steps.
- Some of these steps may be conditional, i.e. the sub-plan may contain forks. My CDS will be used at these forks to read the relevant patient data (most often some fresh measurement data), calculate which path to take next, and return the next steps in the plan. In practice this means that our medical professionals define a complete PlanDefinition for the entire sub-plan, out of which fragments are handed out to the patient in question, one piece at a time, depending on measurement results.
Hopefully my use-case is clear. What I am wondering is: when returning a "plan fragment", say, "perform steps A, B and C and then call decision support", what would actually be a good way to encode this action of calling the CDS? We are naturally using CDS hooks. Is there some obvious resource to do this in? Usually, for other actions, we only return ActivityDefinitions, since the actions will be further "enriched" by the calling service before the actions get turned into more precise FHIR resources.
The simplest way would be to just have an ActivityDefinition with a code containing the hook name. However, we also need to pass in the "fork ID" so the CDS knows which fork we are at. Creating one hook per fork seems a bit counterproductive, I'd rather have one hook, e.g.
evaluate-template-fork
and a parameterforkId
with some unique string. Where would I put this parameter in a CDS hook call?
Github Notifications (Dec 03 2017 at 08:20):
vlindhol edited Issue #123
Hi!
I'm working on a CDS service that will provide so-called "CarePlan templates". What this means is:
- A patient has a CarePlan, which describes his or her entire interaction with my country's healthcare system.
- When using different services, this patient may be put on individual "sub-plans". An example would be if the patient is diagnosed with heart disease, at which point some heart disease-related protocol is activated for him, containing some predefined set of steps.
- Some of these steps may be conditional, i.e. the sub-plan may contain forks. My CDS will be used at these forks to read the relevant patient data (most often some fresh measurement data), calculate which path to take next, and return the next steps in the plan. In practice this means that our medical professionals define a complete PlanDefinition for the entire sub-plan, out of which fragments are handed out to the patient in question, one piece at a time, depending on measurement results.
Hopefully my use-case is clear. What I am wondering is: when returning a "plan fragment", say, "perform steps A, B and C and then call decision support", what would actually be a good way to encode this action of calling the CDS? We are naturally using CDS hooks. Is there some obvious resource to do this in? Usually, for other actions, we only return ActivityDefinitions, since the actions will be further "enriched" by the calling service before the actions get turned into more precise FHIR resources.
The simplest way would be to just have an ActivityDefinition with a code containing the hook name. However, we also need to pass in the "fork ID" so the CDS knows which fork we are at. Creating one hook per fork seems a bit counterproductive, I'd rather have one hook, e.g.
evaluate-template-fork
and a parameterforkId
with some unique string. Where would I put this parameter in a CDS hook call?
Github Notifications (Dec 03 2017 at 08:33):
vlindhol commented on Issue #123
Since it looks like both
context
andprefetch
are described by FHIR search strings, should there be some place to place aParameters
resource?
Github Notifications (Dec 03 2017 at 17:55):
brynrhodes commented on Issue #123
If I'm understanding correctly, the use case requires that you be able to indicate which points in the PlanDefinition should trigger an evaluation. We have typically used the triggerDefinition element to indicate this, and you could define the hook to accept an
actionId
with theid
of the action. Would that work?
Last updated: Apr 12 2022 at 19:14 UTC