Proposed changes to support the Supervisor workflow on FHIR Core

[dubdabasoduba]

Conext

• We are building a supervisor app focusing on managing CHWs (Community Health workers).
• This is introducing a couple of changes to allow the display of Practitioners' data on the app.

Implementation Proposals
1. Wrapping Practitioners with a Group resource to allow CarePlan assignments.

• Currently, when we create users on FHIR Web, a practitioner resource referencing the keycloak user is also created on the HAPI FHIR instance.
• For the Supervisor to perform their duty they need to generate a schedule for the Practitioner visits. However, CarePlans can only accept Patients or Groups as Subjects.
• This means we need to find a way to link a practitioner with a Group resource and then use the Group as a Subject on the generated Visit Schedule CarePlans.
• The implementation would be something like this
  • Create a Group Resource for every Practitioner generated by FHIR Web.
  • Use this Group resource and the subject to the CarePlan generated from the CHW Visit PlanDefinition.

2. Adding a PractitionerRole the Practitioner resource to identify their roles on the assignments.

• Currently, All users are added as Practitioners on FHIR. We however need a way to identify the Supervisors among the practitioners.
• The recommendation is to do the following.
  • Use the PractitionerRole resource to assign the practitioners specific roles.
  • This can be assigned through the code property on the PractitionerRole.
  • Here are the proposed codes to use.
    • {"system":"http://snomed.info/sct","code":"224581009","display":"Community nurse manager (occupation)"}-- Community nurse manager (occupation)
    • {"system":"http://snomed.info/sct","code":"309446002","display":"Nurse manager (occupation)"}-- Nurse manager (occupation)
  • Here is a sample PracttionerRole sample

{
  "resourceType": "PractitionerRole",
  "identifier": [
    {
      "use": "secondary",
      "value": "9b54d1cd-42cc-4dd4-ba7f-1c1245e5b30c"
    }
  ],
  "practitioner": {
    "reference": "Practitioner/practitioner-id"
  },
  "active": true,
  "code": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "309446002",
          "display": "Nurse manager (occupation)"
        }
      ]
    }
  ]
}

3. Downloading all the Practitioners tied to the Supervisor. This should be based on the 3 syncStrategies.

• We need to download the Practitioners in order to create the Practitioner register on the Supervisor application.
• After login, The Practitioner Details endpoints would return all the resources tied to the Practitioner.
• If a PracttionerRole resource is part of the Resources returned by the Practitioner details endpoint then we trigger the download of all the other Practitioners.
• The Practitioners' list to be downloaded guided by the syncStrategy defined for the app.
  • If you have the Location sync strategy then all the Practitioners downloaded are all the Practitioners assigned the same location as the supervisor.
  • If you have the Organization sync strategy then all the Practitioners downloaded are all the Practitioners assigned the same Organization as the supervisor.
  • If you have the CareTeam sync strategy then all the Practitioners downloaded are all the Practitioners assigned the same CareTeam as the Supervisor.

References

• https://hl7.org/fhir/R4/valueset-practitioner-role.html

[ageryck]

The additional condition would be to ensure a 1-1 match between created groups with the assigned Location, Organization, and/or CareTeam. This avoids creation of visit CarePlans for practitioners not in their respective Location, Organization, and/or CareTeam
@dubdabasoduba

[f-odhiambo]

Some questions for part 1

1. Can we use a CareTeam in place of a group? using http://hl7.org/fhir/careplan-definitions.html#CarePlan.careTeam. If we use a group we may need to also distinguish a type of group using a new code scheme to differentiate it from the family.
2. Is this limited to a clinical workflow managing patients only or can be extensible to also structures?

Some questions for part 2

1. We may need to review this later once we have RBAC as I see this as a potential use case to test permissions conflict once data is being created/collected

[pld]

For part 1, question 1, I think the answer is kinda? If we use the subject field, then we can only link Patient or Group resources, but I was thinking something similar to your suggestion, what if we used something other than the subject field to create this link? careteam and wrapping the Practitioner in a CareTeam would be an option, but would still require the wrapping, but with a CareTeam instead of a Group, so then might as well use a Group wrap and the subject field.

author and contributor can link directly to a Practitioner and avoid a wrapper, we could also use supportingInfo which links to any resource type.

The broader point (I guess) this makes is that if we use CarePlan to represent supervisor visits to their practitioners we are outside of the intended semantic usage of CarePlan, that's why Practitioner is not allowed in the subject field in the first place. I can't think of a better way to do it, but want us to note this. But following up on that, if it's not semantic anyhow, why not use the also not semantic author, contributor, or supportingInfo field so we can link to the Practitioner and avoid the wrapping resource? Either way we'll have to figure out how to embed or extensively doc all this to explain this non-semantic usage. I definitely see the counter argument, if that means branching logic to decide what field based on what code (or something else?) the CarePlan has a wrapped link to the subject might be the best option regardless.

Thinking (writing?) out loud, please excuse the ramblyness :D

[dubdabasoduba]

@pld I am okay with using any of the Practitioner referencing keys. I think documentation would help communicate the usage.

[pld]

ok sounds good, let's choose whichever's best and doc it very well and redundantly

[dubdabasoduba]

We ended up going the Group resource way. This is because of the required fields on the CarePlan. Here is the issue to track the implementation.

[dubdabasoduba]

@f-odhiambo @pld Do you have any opinions on points 2 & 3?

[pld]

2. What you've described feels like the correct way to do it. One weird (to me) aspect of Practitioner and PractitionerRole is that Practitioner's don't point to a PractitionerRole, PractitionerRole points to the Practitioner, but I guess this is fine, it just means the primary resource we connect to related to a Practitioner is a PractitionerRole, then we'd fetch the Practitioner data from it when we want to, this also gives us a way to associate Location with a Practitioner, which seem convenient. If we wanted to avoid this additional resource, we could use the qualification field of Practitioner to hold something differentiating roles. We could consider this if we're worried about the overhead of adding a new resource, in terms of performance or LOE, but I don't think we are.

3. I think we should rewrite this in consideration of the above since PractitionerRole is the primary resource. Like instead of a Practitioner register it should be a PractitionerRole register, and instead of fetching from the Practitioner endpoint we need to fetch from the PracitionerRole endpoint, since it's easy to get from there to the Practitioner, but not vice-versa.

[dubdabasoduba]

@pld I think the qualification attribute would work better. That way we don't have to worry about the overhead of fetching 2 more resources tied to a practitioner. It's not a very clean way based on the qualification description.

The field can also hold multiple entries so I think it would be ideal in case we needed to add more Qualifications.

[dubdabasoduba]

I would also propose using the following code {"code":{"coding":[{"system":"http://snomed.info/sct","code":"236321002","display":"Supervisor (occupation)"}]}}