FHIR Chat · CarePlans, PlanDefinitions and iCBT · implementers

Stream: implementers

Topic: CarePlans, PlanDefinitions and iCBT

---

Håkan MacLean (Nov 18 2020 at 08:03):

Hi!
I'm trying to create a FHIR compliant iCBT (Internet-based Cognitive Behavioural Therapy) service. I have not been able to find any Profile for this use-case, does anyone know if there exists one? (I tried here: http://www.fhir.org/guides/registry/, but the search does not seem to work on Resource level).

Right now it feels like I'm reinventing the wheel and trying to shoehorn stuff into PlanDefinitions, CarePlans, ResourceGroups etc (where to store the reference to the actual text content?) and I'm not sure if it's actually going to be useful.

Bryn Rhodes (Nov 18 2020 at 12:32):

Can you provide a bit more detail about the requirements? What types of capabilities will this service provide?

Håkan MacLean (Nov 18 2020 at 14:14):

Thanks for replying! I'll try to be brief as I can. We want to store the definition of a iCBT treament programme, e.g.
iCBT Anxiety Treatment Plan v.1

• Internal metadata
  • Link to internal chat session
• Content
  • Module 1
    • Task 1: Read about topic X
      • Task 1.1: Read X.1
      • Task 1.2: Read X.2
    • Task 2: Self-assessment
  • Module 2
    • Task 1: Read about topic Y
    • Task 2: Appointment with Clinician

And then we want to enroll a Patient in one of these programmes.

My current understanding, after reading the chapter here: https://www.hl7.org/fhir/plandefinition.html#12.18.3.3, is that I should try to put the iCBT program in a PlanDefinition, using actions and subactions with ActivityDefinitions to create this Module/Task hierarchy. Then when enrolling a patient I create a RequestGroup with nested Actions/Tasks, referring to the ActivityDefinitions. Finally then create a CarePlan referencing this RequestGroup.

My questions (in descending priority) are:

1. Am I doing this correctly? Or is there a Profile I can look at? I have not find a place where I can search for Profiles implementing a specific Resource.
2. How would I reference the actual content (e.g. text) in the ActivityDefintions? Perhaps using ActivityDefinition.relatedArtifact?
3. When my the patient wants to consume this data, I suppose would send a bundle containing the CarePlan and the RequestGroup?
4. I suppose the reference to the chat session would be a FHIR Extension

Bryn Rhodes (Nov 18 2020 at 16:20):

Yes, that sounds right. Note that if there isn't any optionality in the actions (i.e. they just perform each action), then you don't need to use RequestGroup, you can add the actions directly to the CarePlan. It's a very interesting use case because it's a set of instructions for the patient, as opposed to a set of instructions for a practitioner or care team.

1. CPG-on-FHIR has several profiles that might be helpful here: http://build.fhir.org/ig/HL7/cqf-recommendations
2. You could use the relatedArtifact, yes, you could also consider just using the documentation element of PlanDefinition.action
3. I think the answer to this question depends on what the best way to represent this in FHIR would be, and I'm not 100% sure about that. I think you could use CommunicationRequest/Communication, that might be the best fit, and would let you put the content in the payload element.
4. Yes, I think the chat session would be an extension

Håkan MacLean (Nov 18 2020 at 16:38):

Wow, this is great info, thanks!
0) Re. adding the actions directly to the CarePlan, I found no way of grouping/nesting them in the Module/Task/Subtask hierarchy that we have. Is there a way I have missed? You can't have sub-activities as far as can see?

3) Let's say I want to send the entire plan, with the content and how far the patient has come in each module. Wouldn't I then need to send the entire CarePlan (and perhaps related ResourceGroup)?

Håkan MacLean (Nov 18 2020 at 16:41):

@Ingvar Sørlien thanks for a super interesting talk! We seem to be working on something very similar, as you see in my question above. I have so many questions to you now :)

1. Would you mind sharing your experiences in regards to my questions above?
2. Do you have any example CarePlans, PlanDefinitions I could look at?
3. Do you have any IG/Profile in draft I could look at already?

Bryn Rhodes (Nov 18 2020 at 16:50):

That's a fair point, RequestGroup does give you a way to easily follow the same grouping/hierarchy as the PlanDefinition. It would also let you continue to use the documentation element of RequestGroup.action for the actual content. I think with some extensions/codes/profiles to indicate clearly that that's what you were doing, that would make a lot of sense and ease representation/implementation.

Bryn Rhodes (Nov 18 2020 at 16:52):

And yes, that would then mean that you could use the CarePlan/RequestGroup to track current state/progress, though you might need some extensions to keep track of completion of modules.

Håkan MacLean (Nov 20 2020 at 15:56):

So I'm trying to fit a iCBT treatment program into FHIR using PlanDefinitions and CarePlans. Right now I'm thinking about how to encode something like the following task for Patient: "Step 1. Read this text about topic X".

Right now my assumption is that in the PlanDefinition, this task would be encoded using a ActivityDefinition with 'kind' set to Task

Right now my questions are:

1. Is my assumption above reasonable? Or should I use some other Resources?

2. I'm a bit confused about when to store things in PlanDefinition.action[0].aRandomField vs the related ActivityDefinition.aRandomField. Should I interpret the ActivityDefinition to be something like "A generic Task that instructs the patient to read something", which could then be re-used by several different actions in the PlanDefinition and be referenced through definitionCanonical? Or is it more specific and I should create one ActivityDefinition for each topic and reference it through definitionUri?

3. Where in should I put a link to the actual text content? Right now I'm thinking about PlanDefinition.action.document or ActivityDefinition.relatedArtifact (pending the answer on question 2).

4. When it comes to creating the actual Task, what would be an appropriate place to put the link to the text content in the Task?

5. Reading about "Applying an ActivityDefinition" (https://www.hl7.org/fhir/activitydefinition.html#12.17.3.3) it talks about the 'transform' element and StructureMaps. Since I want the text content from the say PlanDefinition.action[0].FieldX to end up in the Task.FieldY, have I understood it correctly that we then have to create a StructureMap that explains this transform?

Lloyd McKenzie (Nov 21 2020 at 17:09):

@Bryn Rhodes

Bryn Rhodes (Nov 23 2020 at 16:35):

@Håkan MacLean:
1) Yes, a Task resource is appropriate here
2) Yes, ActivityDefinitions are used to define a generic task, but _how_ generic it is depends on your use case. One approach is to define an ActivityDefinition _profile_ that establishes the "A generic Task that instructs the patient to read something", and then have ActivityDefinitions that conform to that profile for each specific task. For example CollectInformationActivity is a profile of ActivityDefinition that defines the activity of collecting information using _some_ questionnaire. Then there would be specific ActivityDefinition resources that specify the questionnaire to be used using the "collectWith" extension. The act of applying that ActivityDefinition would result in a Task that conforms to the QuestionnaireTask profile, with the actual Questionnaire to be filled out as an input element.
3) In this approach, you could specify the document as an extension in the ActivityDefinition profile, so that it's clear exactly where the element would be specified
4) That extension in the ActivityDefinition would result in an input element in the generated Task
5) No, you don't have to specify a Transform, that is one of the possible approaches, you can use a StructureMap if you want to use FHIR Mapping Language to describe the transform from the ActivityDefinition to the Request resource, or you can use the ActivityDefinition.kind to specify the type and use dynamicValue elements to specify the individual fields.
Does that help?

Farrukh Najmi (Nov 23 2020 at 21:34):

The CarePlan.activity.status values are specified here: http://hl7.org/fhir/valueset-care-plan-activity-status.html
They do not include a value to indicate that a scheduled activity was not performed in its allocated time and was therefor "missed".
Any suggestions on why this status is not included in the spec and how implementations should handle this?
Is there a general extension mechanism for extending enumeration values like state?

Lin Zhang (Nov 24 2020 at 00:41):

CarePlan.activity.plannedActivityDetail.status? It has a binding of required type.

Lin Zhang (Nov 24 2020 at 00:44):

CarePlan.activity.progress might be relevant element for this case.

Farrukh Najmi (Nov 24 2020 at 12:56):

@Lin Zhang When cosnidering the same question for CarePlan.status where an application has more status values than what is defined in FHIR I realized that both CarePlan.activity.status are of type code (http://hl7.org/fhir/STU3/datatypes.html#code). This means that apps are free to extend the enumerated values for status in my interpretation.

Michele Mottini (Nov 24 2020 at 15:01):

No, the set of values is fixed (the binding is 'Required')

Yunwei Wang (Nov 24 2020 at 16:32):

Farrukh Najmi said:

The CarePlan.activity.status values are specified here: http://hl7.org/fhir/valueset-care-plan-activity-status.html
They do not include a value to indicate that a scheduled activity was not performed in its allocated time and was therefor "missed".
Any suggestions on why this status is not included in the spec and how implementations should handle this?
Is there a general extension mechanism for extending enumeration values like state?

CarePlan.activity[x].scheduledTiming = (past dateTime)
CarePlan.activity[x].detail.status = not-started
These should be enough to indicate that the activity has a schedule passed and not started yet.
Optionally, You can add CarePlan.activity[x].statusReason to make it clear. Be noticed that FHIR does not provide any binding for that codeableConcept so you have to create your own.

Håkan MacLean (Nov 24 2020 at 22:11):

Wow @Bryn Rhodes , thank you so much for taking the time to help me navigate the world of FHIR! It is really super appreciated.

4. You say that an ActivityDefinition extension would end up as Task.input. How so? Is this behaviour described somwhere?
5. Ah, great suggestion with DynamicValue. Seems like a lightweight way to convey this mapping.

And now I of course have new questions. Let's say the iCBT programme has "Modules" and each module consists of "Steps". We like see these Modules as resources of their own that can be used by many different iCBT programmes. Like we discussed before, the Steps could be modelled as FHIR ActivitiyDefinitions with kind=Task, but what about the Modules? Right now I'm thinking that we could model these as well as ActivityDefinitions with kind=Task. Then two new questions arise:

6. Doing this, the "ModuleActivityDefinition" seems to have no knowledge about its own "StepActivityDefinitons". Instead all this information is stored at the PlanDefinitions level, which doesn't feel right. Is there some way for the ModuleActivityDefinition to reference the Steps in some FHIR like way?

7. I was also thinking about how to nest the PlanDefinition actions. In this example https://www.hl7.org/fhir/plandefinition.html#12.18.3.3 there is only one action at the root level. So would all ModuleActivityDefinitions live inside the a single "root action"? Or could we lift up the ModuleActivityDefinitions and put them at the root level? When applying, I assume that would mean creating multiple RequestGroups instead, but I guess it does not make sense converting an action pointing to an ActivityDefinition to a RequestGroup?

@Ingvar Sørlien , I recall you had some kind of nesting in your PlanDefinition, right? One group of ActivityDefinitions for "green" days and one for "red" days etc. Did you also model the groups as ActivityDefinitions? Do you have any wise things to say about #6 and #7?

Håkan MacLean (Nov 26 2020 at 09:53):

So I’ve been thinking some more about how to model this and came up with a new approach that solves both question 6 and 7. Since we want our Modules to have knowledge about their own Steps (i.e. their ActivityDefinitions/Tasks), I thought maybe we could model Modules as PlanDefinitions. Then to create a programme, we create a “parent” PlanDefinition pointing to multiple ModulePlanDefinitions. E.g. like this:
iCBTProgramme: PlanDefinition1

• Module1: PlanDefintion2
  • Task 1: ActivityDefintion1 kind Task
  • Task 2: ActivityDefintion2 kind Task
• Module2: PlanDefintion3
  • Task 3: ActivityDefintion3 kind Task
  • Task 4: ActivityDefintion4 kind Task

The question is then what happens when you “apply” the above to a Patient? I haven’t found a lot information about the apply operation, except this section here: https://www.hl7.org/fhir/plandefinition.html#12.18.3.3. In this example one PlanDefinition creates both a CarePlan and a ResourceGroup. Would it instead be reasonable that only the parent PlanDefinition generates one CarePlan and the “inner” PlanDefinitions only generate ResourceGroups? How/where is this behaviour defined? See suggestion below.

iCBT Treatment: CarePlan1 (instantiates PlanDefinition1)

• Module1: ResourceGroup 1 (instantiates PlanDefinition2)
  • Task 1: Task1
  • Task 2: Task2
• Module2: ResourceGroup 2 (instantiates PlanDefinition3)
  • Task 3: Task3
  • Task 4: Task4

Lloyd McKenzie (Nov 26 2020 at 15:26):

@Bryn Rhodes

Bryn Rhodes (Nov 27 2020 at 22:11):

The current proposed behavior for nested PlanDefinitions is to have nested CarePlans. However, we are currently prototyping a mergeNestedCarePlans parameter that would indicate that the result of applying nested PlanDefinitions should result in a single merged careplan as the result. http://build.fhir.org/ig/HL7/cqf-recommendations/OperationDefinition-cpg-plandefinition-apply.html

Bryn Rhodes (Nov 27 2020 at 22:12):

We would welcome feedback on whether that would work for your use case as well.

Håkan MacLean (Nov 29 2020 at 22:09):

Super grateful for every reply from you @Bryn Rhodes ! I'll number my questions so nothing gets lost.

1. So we first thought nested PlanDefinitions would result in nested CarePlans, but we couldn't figure out how to do it since CarePlan.activity.reference cannot reference a resource of type CarePlan?

2. Do you have any example resources with PlanDefinitions and CarePlans (preferably nested)? Would help a lot with my understanding. Could only find PlanDefinitions here: http://build.fhir.org/ig/HL7/cqf-recommendations/examples.html

3. Your link says True if the result of any nested PlanDefinitions should be merged into the final care plan, false if they should be preserved as nested CarePlans in the output. If this parameter is not specified, the default behavior is to preserve nested care plans in the output.
   What would true and false actually result in, if we take my example above? If false you seem to suggest nested CarePlans (even though I don't understand how, see Q1) and if true, what happens then? Are all ActivityDefinitions flattened to the root level? Or do we use multiple ResourceGroups as per my example?

4. Would the proposal I have (with the sub-PlanDefintions resulting in multiple ResourceGroups) be invalid from a FHIR perspective? When I read here: https://www.hl7.org/fhir/plandefinition-operation-apply.html it says: The result of this operation is a CarePlan resource with a single activity represented by a RequestGroup. it sounds like maybe it is not valid?

Bryn Rhodes (Dec 08 2020 at 14:47):

1. We're looking at using an extension for the nested CarePlan result, either that or you could maybe use the outcomeReference of the activity to reference the CarePlan. We're currently thinking an extension is the right way to go there, with a request in to the CarePlan resource to allow referencing a CarePlan as the reference of an activity.
2. There is a CarePlan example here: http://build.fhir.org/ig/who-int/anc-cds/examples.html, but it's not nested, that part is in progress.
3. True would result in the activities from the nested care plans being pulled in to the activity element of the main care plan, however they were represented in the nested care plans. So if the activities in the nested care plans are RequestGroups, those would be pulled in as RequestGroups in the main care plan.
4. That does mean that the main care plan will in general have multiple activities, that is an aspect of the operation documentation that needs to be updated to allow for this (and other) scenarios.

Bryn Rhodes (Dec 08 2020 at 14:47):

@Håkan MacLean , apologies for the delayed response :(

Håkan MacLean (Jan 15 2021 at 19:32):

@Bryn Rhodes I just wanted to follow up on this and thank you for all your time. Unfortunately our feeling, after trying to squeeze our iCBT plan with nested modules into FHIR, was that there wasn't a good match between the standard and our use-case atm, so we decided wait with using FHIR in this case since we are not yet integrating with any external systems.
However, I would be very much interested in hearing about updates to your work and if the extensions you suggested will make it into the standard. Is there any mailing list or similar I can get on to get updates re. FHIR CarePlan and PlanDefinitions?

My 2c after all of this would be that the easiest and cleanest solution would be that if you have nested PlanDefintions should result in multiple ResourceGroups, but I guess that would require changing the wording of the standard.

---

Last updated: Apr 12 2022 at 19:14 UTC