Stream: implementers
Topic: ActivityDefinition
René Spronk (Oct 21 2019 at 07:12):
In ActivityDefinition I understand that dynamicValue can be used to set a 'path' (some data element) to a dynamic value as defined by some (CQL or something else) expression. However, from the context it isn't entirely clear as to where those 'paths' would be.
I'm guessing that the specified paths would be to the request resource, the request resource as generated during the $apply operation. Correct? What would a typical example be for using a dynamicValue ?
Lloyd McKenzie (Oct 21 2019 at 15:22):
@Bryn Rhodes
Bryn Rhodes (Oct 21 2019 at 18:36):
@René Spronk , yes, that's correct, the path would be relative to the root of the resource being created (the ActivityDefinition.kind element specifies the resource type). A simple example for using dynamicValue is to set the authoredOn to Now(). More complex examples might be to set the dosage for a medication based on the patient's weight.
René Spronk (Oct 24 2019 at 09:19):
@Bryn Rhodes Thanks - once one has a CarePlan, and one would wish to "add" an instance of an ActivityDefintion to it, it would seem that currently $apply doesn't support this. Does this mean one would have to create a new CarePlan ? And another question: looking at CarePlans and Questionnaires: Q's play a role in determining the outcomes (evaluation), but depending on how the QR is populated they may also trigger new interventions. Some QRs could be mapped into a CarePlan.. how do you see the role of Q in the context of CarePlans ?
Lloyd McKenzie (Oct 24 2019 at 12:34):
$apply gives you a theoretical CarePlan that you adjust to be the 'real' one (or merge into an existing real one). A QR could, in principle, result in any kind of a resource - including CarePlans or even full-blown orders. So long as the mappings are there, extractions should work.
René Spronk (Oct 24 2019 at 14:01):
Hmm - from what I now understand, the CarePlanDefintion is 'constrained for a specific patient' (high level pathway choices) prior to using $apply (which is the time to involve the clinical data of the patient and generate a much more specific set of option/plan/order intent Request resources), and obviously the generated CarePlan may still contain various options, which may or may not lead to actual interventions/requests. The latter choices are during the process of managing the CarePlan resource.
I haven't seen mention of CarePlans being merged, but that should be possible. I was just wodnering if $apply should have a input parameter for "CarePlan to be updated' by $apply-ing a certainly activityDefintion to it.
Lloyd McKenzie (Oct 24 2019 at 14:25):
I can't imagine a practitioner wanting their "real" care plan auto- updated by decision support
Bryn Rhodes (Oct 24 2019 at 18:54):
The $apply operation for an ActivityDefinition returns Any resource, it's the result of constructing the resource described by the ActivityDefinition. So if your ActivityDefinition creates a MedicationRequest, that would be the result of the Apply.
Bryn Rhodes (Oct 24 2019 at 18:55):
And PlanDefinition isn't necessarily constrained for a specific patient, that depends how you create it. CarePlan is, but PlanDefinition could be defined based on the characteristics of "some" patient with a particular condition, or however you want to construct it.
Bryn Rhodes (Oct 24 2019 at 18:57):
I would expect that a process that was applying decision support as part of updating a care plan could use questionnaires to gather information required as input to the decision support, which would then use that information as input to the process of creating the proposals from the PlanDefinition/ActivityDefinition. I would think the user would then be presented with the result of that inferencing and decide whether or not to accept/reject/modify the proposed activities.
Last updated: Apr 12 2022 at 19:14 UTC
