Review FHIR models & relationships to support scheduling

[ekigamba]

• Review the workflows https://www.hl7.org/fhir/workflow.html and the standard resources defined for FHIR workflows i.e. the definitions, requests and events
• https://www.hl7.org/fhir/plandefinition.html
• https://www.hl7.org/fhir/activitydefinition.html
• https://www.hl7.org/fhir/careplan.html#CarePlan
• http://hl7.org/fhir/workflow-module.html
• https://www.hl7.org/fhir/workflow-management.html

[pld]

cool, can the output of this be an addition to an existing (or a new) docs file with brief summaries (can be quoted from link) and links for each of the above

[ekigamba]

@pld I will definitely do that

[ekigamba]

Below is a brief summary of the FHIR R4 docs review. This is the foundation on FHIR. It helps understand how to design and use resources in a workflow.

Summary

FHIR categorises resources in a clinical workflow as:

1. Definition - Resources that define something that can potentially happen in a patient and time-independent manner
2. Request
3. Event

The Task is categorised as a Request and Event . A Task keeps track of a request and contains a link to the request. A Task can be generated but not initially assigned to any entity. This task can be picked(self-assigned) and its status can start changing. The implementation details for the Task are contained inside the attached Request.

A PlanDefinition contains actions. These actions can link to an ActivityDefinition which enables definition more properties/details. ActivityDefinition can also be more generic and be re-used by multiple PlanDefinitions. Action and ActivityDefintion share properties and in cases where an ActivityDefinition also exists, the properties in the Action override the property values in the ActivityDefinition. This is useful in cases where an ActivityDefinition is generic and shared but specific details such as title and description for the use-case, time, region, module or purpose are included in the PlanDefinition. ActivityDefinition is used to create a Request. The Request progress, assignment and status is tracked by a Task.

Running an apply operation on a Patient(Context) + PlanDefinition generates a CarePlan that is specific to a person.

A CarePlan :

• Is a group activities to provide context
• Specific to a particular patient or group
• It does not replace a PlanDefinition

It uncomplicates some patient, scheduling and patient-specific details/options in care from the PlanDefinition to the CarePlan . For Goldsmith, we ended up not being able to include certain schedule and logic specific to ANC care while maintaining the generic form of the action. The ActivityDefinition would have helped with this while the CarePlan will be brief enough for computational purposes as compared to a PlanDefinition

→ Still trying to come up with clear examples of this understand why this is required and the clear differences/benefits on this.

It seems, there should always be a task for every clinical Request to request fulfillment of the Request and track progress. The Request is referenced in the Task.focus and also contains the operational details. Inputs and outputs are tracked by the task also. A Task could request fulfilment of a ServiceRequest ordering a radiology that would end with and ImagingStudy. The ImagingStudy would be the output and can be tracked on the task. Once the images are ready, another ServiceRequest would be generated and a Task would be used to track the ImagingStudy to be read/analysed with the output being a DiagnosticReport

CareTeam

CareTeam is a group of practitioners, care takers, patients and organisations who plan to participate in the coordination and delivery of care for a patient. CareTeam can be used in different contexts where there can be a subject such as a a patient or within context such as emergency services, type of service provided. The CareTeam.category which describes the types of care team can be:

• Event-focused care team
• Encounter-focused care team
• Episode of care-focused care team
• Condition-focused care team
• Longitudinal care-coordination focused care team
• Home & Community Based Services (HCBS)-focused care team
• Clinical research-focused care team
• Public health-focused care team
• Longitudinal care-coordination focused care team

IMO, CareTeam can be used to limit access to care details within a domain in cases where we have a global patient directory and global patient history in a country eg. HIV details, PHI(Protected Health Information) and also limit access for different modules of providing care eg. a practitioner might have access to a location and not be part of a CareTeam in that Location. Therefore, this pracititioner should not have access to certain records, health modules. Read HIPAA for US on such laws

FHIR Location

Location enables us to define a jurisdiction or HealthCenter https://www.hl7.org/fhir/location.html . The GeoJSON is described as a location boundary extension to the location here http://build.fhir.org/extension-location-boundary-geojson.html. The extension is a draft with little information but it enables representing the geojson as a base64 string in the Attachment.data

Example 1

"resource": {
                "resourceType": "Location",
                "id": "16260",
                "extension": [
                    {
                        "url": "http://build.fhir.org/extension-location-boundary-geojson.html",
                        "valueAttachment": {
                            "url": "https://sandbox.caredove.com/api/native_v1/Boundary/16907"
                        }
                    }
                ]
            }

Origin of example Brian-Postlethwaite-Healthcare-Directories-DevDays-2019-Redmond.pdf

Example 2

"resource": {
  "resourceType": "Location",
  "name": "Mwango_House",
  "identifier": [
    {
      "system": "biophics",
      "value": "HL0122"
    }
  ],
  "extension": [
    {
      "url": "http://build.fhir.org/extension-location-boundary-geojson.html",
      "valueAttachment": {
        "data": "IHsKICAgICAgICAgICAgImNvb3JkaW5hdGVzIjogWwogICAgICAgICAgICAgICAgOTkuMTgxNzc5NTExNjc3NTgsCiAgICAgICAgICAgICAgICAxNy4wMTA5ODU4OTE5NzU1MDUKICAgICAgICAgICAgXSwKICAgICAgICAgICAgInR5cGUiOiAiUG9pbnQiCiAgICAgICAgfSw="
      }
    }
  ]
}

Origin of example

Workflow Management Patterns

FHIR Workflow management patterns page tries to provide multiple strategies for managing the workflow in cases where the there might be multiple systems/entities. For example, we might have 2 systems interacting in a case where we have a hospital and external laboratory all running their own FHIR servers. Another example is a hospital and external pharmacy each running it's own FHIR server.

The workflow between multiple systems is out-of-scope for now.

For FHIR request placers and fillers working within the same system, below is the proposed strategy

Notes

The workflow module declares that R5 will try to simplify the resources and make them more intuitive for implementers. It is noted that some resources have lost domain-specific context and some elements were introduced instead of being defined as extensions.

[pld]

cool, awesome write up, can you move your above comment to a PR into an existing (or new file) in the docs folder?

want to make sure we don't lose it.

on the final topic of R5 you mentioned, it sounds like the API may change meaningful from R4 to R5 so that is something to be aware of. However, we're not relying on the API for anything right now, but once we do we have to consider delaying until R5 to avoid a bunch of update work

[ekigamba]

@pld I agree, moving this to the docs should be the next step.

For the R4 to R5 changes,

1. I think that that they might not be too significant and might be build upon what the implementers have defined.
2. Resources that are redefined as extensions will require significant and breaking changes.
3. I assumed that we are trying to follow the FHIR standard strictly where applicable, is this the case?

[pld]

Yes following strictly, anything in FHIR resources should validate, and we can use the extension framework to go outside it

…

On Apr 15, 2021, at 2:46 AM, ekigamba ***@***.***> wrote: @pld <https://github.com/pld> I agree, moving this to the docs should be the next step. For the R4 to R5 changes, I think that that they might not be too significant and might be build upon what the implementers have defined. Resources that are redefined as extensions will require significant and breaking changes. I assumed that we are trying to follow the FHIR standard strictly where applicable, is this the case? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMETZ4NDB4FW5HV5J6PTTI2DVPANCNFSM42UWVYPA>.