Closed ekigamba closed 3 years ago
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
@pld I will definitely do that
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.
FHIR categorises resources in a clinical workflow as:
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
:
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 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:
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
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="
}
}
]
}
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
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.
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
@pld I agree, moving this to the docs should be the next step.
For the R4 to R5 changes,
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 https://github.com/OpenSRP/fhircore/issues/77#issuecomment-820162306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMETZ4NDB4FW5HV5J6PTTI2DVPANCNFSM42UWVYPA.
definitions
,requests
andevents