CHW/ANC SubTask - Enroll a family #276
Comments
|
The user can register a new family by clicking the option menu in the top right corner. There there will be an "register family" option. Once that is selected, the user will be dropped directly into the family registration form. Once they fill this in and hit "next" the will be sent to the second page to register the head of household. The user can then choose to continue registering additional family members by hitting "next" or "save" and exit. When they save and exit the questionnaire, they will land on the family profile view. The exact fields collected in these forms is being confirmed and I will update the story with that information. |
|
For now, the only plan definition we will have in place is ANC, so the registration of family members won't trigger the addition of any plan definitions to their care plans. But, in the future, we would want it to be possible to automatically do so. A good example here would be family planning. All women within a certain age range are eligible for family planning services, so we would want that to be included their care plan automatically. |
|
@f-odhiambo I don't think we ever decided on how to represent families in FHIR. From the UI it seems clear this needs to be a separate resource in itself, i.e. a family isn't a group of people, it's its own object. B/c of that, using |
|
I agree. I think this use case could be represented as
|
|
I thought Group here was being used to assign a population of Patients to a CareTeam i.e. a set of patients within a village to the CHW that was responsible. I came across this yesterday - https://fhirblog.com/2020/02/10/family-fhir-with-sushi/ - which suggested:using the Patient => RelatedPerson(Patient) relationship and setting the RelationshipType. I wonder if you could use this to almost infer the Head of Household .. i.e the root of the relationship tree .. and enforced by some protocols e.g:
|
|
We're considering using Group for both of those purposes. If we use only Patient and RelatedPerson we either (1) can't represent a family separate from the people in the family, or (2) use a Patient resource that represents a family instead of a person @isabelcshaw do we need to represent a family as separate from the people in it? If not, I agree that Patient and RelatePerson will be enough |
The group resource allows other groups to be group members. That way we can have a group of family (groups) then assign a care team to the larger group. We can then use the Relateperson(patient) relationship on the patient/person group members in the family (group) to infer who is the family head. |
|
This also brings me to this discussion. It has the potential to require a UI rethink on OpenSRP web. |
|
@pld a few thoughts on the need to represent a family as separate from the people in it:
|
|
K thanks, do we have any situations where we register a family that is not associated with a structure? |
|
@pld not in the CHW workflows. We do in campaign workflows. Two other notes here: 1. It is possible for families to move. I think the most common example would usually be changing catchments, but if we wanted to maintain any separation of a family's medical history and a structure, that could be challenging. And relatedly 2. LMH hasn't mentioned this yet, but, from experience, it is possible for there to be multiple families per structure. I believe we avoid this at the moment bc OpenSRP doesn't deal with the structure concept. If I remember correctly, @mberg did have some strong feeling about wanting to keep the concepts of an address and a family separate in the long term. |
|
@isabelcshaw ok thanks, sounds like keeping families separate may not be strictly necessary but if we don't do it we'd have a bunch of pretty ugly workarounds, b/c we'd be overloading the Patient that represents the head-of-household to also represent the family, so if we can support the CarePlan, etc. generation we need off of a resource that's only representing a family (like a Group), we'd be in better shape. I duplicated some of the above in this comment thread in the sdk workflow planning doc, also putting inline below for posterity.
|
|
@isabelcshaw on this issue it's not related to a family. Anytime a women of reproductive age is registered in the system we would need to check to see if they are eligible for family planning and generate a care plan if so.
Couple of thought on the above. I am inclined right now to go with @fredhersch suggestion of having a household be based on creating a head of household and then assigning relationships. We will need to support the scenario of a family living in a compound in multiple structure. In such a scenario, would we want all family members assigned to a single HH? or would we want to register the people living in each structure (usually a wife and her kids) as seperate households? In this case we can still create a relationship by making each women the head of household but then indicating they are married to a head of household in a different family. I think keeping the app flexible and allowing people to implement this how they want is probably what we want to do. In terms of structure, I want to make sure that is decoupled. For non reveal use cases, you should be able to register a head of household and then assign them to a location. The location could be a gps point or a structure on a map. The location could have other meta data like an address, photo, etc. For multi structure families, we could map each mother and her sub-household to a different structure or we can just use the main household depending on the use case. The later approach will work fine if we aren't using the structures as a basis for coverage like we do for reveal. For the reveal use case, we need to figure out how to assign tasks to structures. Once a head of HH is assigned to that structure, certain subsequent tasks can be assigned to that person. For task assignment and capturing encounter data on structures we should probably give a bit of thought on the intervention. Eg. if you visit a structure and give a bednet or give medicine the service is done to the people living at the structure because they can take that bednet with them and leave. If you are doing something physical to the structure like spraying, the benefits of the spray is carried over to the new family that moves into that structure. So we will need to ultimately be able to assign tasks and associate events to non patients I think at the end of the day. For liberia though, I think linking everything to the head of household could probably work. |
|
Cool, how would that handle the sanitation assessment use case? Would that be a task generated for and assigned to the head of household?
We couldn't tie these to Location since as you mentioned we can have multiple HHs per structure.
To gen for the HH we'd need logic that says only generate these PlanDefinition activities for the head of household, and these would be tied to a Patient (the HH)
… On Jul 13, 2021, at 16:37, Matt Berg ***@***.***> wrote:
@isabelcshaw on this issue it's not related to a family. Anytime a women of reproductive age is registered in the system we would need to check to see if they are eligible for family planning and generate a care plan if so.
For now, the only plan definition we will have in place is ANC, so the registration of family members won't trigger the addition of any plan definitions to their care plans. But, in the future, we would want it to be possible to automatically do so. A good example here would be family planning. All women within a certain age range are eligible for family planning services, so we would want that to be included their care plan automatically.
Couple of thought on the above. I am inclined right now to go with @fredhersch suggestion of having a household be based on creating a head of household and then assigning relationships. We will need to support the scenario of a family living in a compound in multiple structure. In such a scenario, would we want all family members assigned to a single HH? or would we want to register the people living in each structure (usually a wife and her kids) as seperate households? In this case we can still create a relationship by making each women the head of household but then indicating they are married to a head of household in a different family. I think keeping the app flexible and allowing people to implement this how they want is probably what we want to do.
In terms of structure, I want to make sure that is decoupled. For non reveal use cases, you should be able to register a head of household and then assign them to a location. The location could be a gps point or a structure on a map. The location could have other meta data like an address, photo, etc. For multi structure families, we could map each mother and her sub-household to a different structure or we can just use the main household depending on the use case. The later approach will work fine if we aren't using the structures as a basis for coverage like we do for reveal.
For the reveal use case, we need to figure out how to assign tasks to structures. Once a head of HH is assigned to that structure, certain subsequent tasks can be assigned to that person.
For task assignment and capturing encounter data on structures we should probably give a bit of thought on the intervention. Eg. if you visit a structure and give a bednet or give medicine the service is done to the people living at the structure because they can take that bednet with them and leave. If you are doing something physical to the structure like spraying, the benefits of the spray is carried over to the new family that moves into that structure. So we will need to ultimately be able to assign tasks and associate events to non patients I think at the end of the day.
For liberia though, I think linking everything to the head of household could probably work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Francis also brought up whether we should use Person and not Patient here, need to figure that out. Good next step is write out a resource-diagram of a family and how we'd get household and person activities from the people resources.
… On Jul 13, 2021, at 16:54, Peter Lubell-Doughtie ***@***.***> wrote:
Cool, how would that handle the sanitation assessment use case? Would that be a task generated for and assigned to the head of household?
We couldn't tie these to Location since as you mentioned we can have multiple HHs per structure.
To gen for the HH we'd need logic that says only generate these PlanDefinition activities for the head of household, and these would be tied to a Patient (the HH)
>> On Jul 13, 2021, at 16:37, Matt Berg ***@***.***> wrote:
>>
>
> @isabelcshaw on this issue it's not related to a family. Anytime a women of reproductive age is registered in the system we would need to check to see if they are eligible for family planning and generate a care plan if so.
>
> For now, the only plan definition we will have in place is ANC, so the registration of family members won't trigger the addition of any plan definitions to their care plans. But, in the future, we would want it to be possible to automatically do so. A good example here would be family planning. All women within a certain age range are eligible for family planning services, so we would want that to be included their care plan automatically.
>
> Couple of thought on the above. I am inclined right now to go with @fredhersch suggestion of having a household be based on creating a head of household and then assigning relationships. We will need to support the scenario of a family living in a compound in multiple structure. In such a scenario, would we want all family members assigned to a single HH? or would we want to register the people living in each structure (usually a wife and her kids) as seperate households? In this case we can still create a relationship by making each women the head of household but then indicating they are married to a head of household in a different family. I think keeping the app flexible and allowing people to implement this how they want is probably what we want to do.
>
> In terms of structure, I want to make sure that is decoupled. For non reveal use cases, you should be able to register a head of household and then assign them to a location. The location could be a gps point or a structure on a map. The location could have other meta data like an address, photo, etc. For multi structure families, we could map each mother and her sub-household to a different structure or we can just use the main household depending on the use case. The later approach will work fine if we aren't using the structures as a basis for coverage like we do for reveal.
>
> For the reveal use case, we need to figure out how to assign tasks to structures. Once a head of HH is assigned to that structure, certain subsequent tasks can be assigned to that person.
>
> For task assignment and capturing encounter data on structures we should probably give a bit of thought on the intervention. Eg. if you visit a structure and give a bednet or give medicine the service is done to the people living at the structure because they can take that bednet with them and leave. If you are doing something physical to the structure like spraying, the benefits of the spray is carried over to the new family that moves into that structure. So we will need to ultimately be able to assign tasks and associate events to non patients I think at the end of the day.
>
> For liberia though, I think linking everything to the head of household could probably work.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
The other important implication of no separate family is no family registration, but we could still build a household list from the people registered as head of household
… On Jul 13, 2021, at 16:58, Peter Lubell-Doughtie ***@***.***> wrote:
Francis also brought up whether we should use Person and not Patient here, need to figure that out. Good next step is write out a resource-diagram of a family and how we'd get household and person activities from the people resources.
>> On Jul 13, 2021, at 16:54, Peter Lubell-Doughtie ***@***.***> wrote:
>>
>
> Cool, how would that handle the sanitation assessment use case? Would that be a task generated for and assigned to the head of household?
>
> We couldn't tie these to Location since as you mentioned we can have multiple HHs per structure.
>
> To gen for the HH we'd need logic that says only generate these PlanDefinition activities for the head of household, and these would be tied to a Patient (the HH)
>
>>> On Jul 13, 2021, at 16:37, Matt Berg ***@***.***> wrote:
>>>
>>
>> @isabelcshaw on this issue it's not related to a family. Anytime a women of reproductive age is registered in the system we would need to check to see if they are eligible for family planning and generate a care plan if so.
>>
>> For now, the only plan definition we will have in place is ANC, so the registration of family members won't trigger the addition of any plan definitions to their care plans. But, in the future, we would want it to be possible to automatically do so. A good example here would be family planning. All women within a certain age range are eligible for family planning services, so we would want that to be included their care plan automatically.
>>
>> Couple of thought on the above. I am inclined right now to go with @fredhersch suggestion of having a household be based on creating a head of household and then assigning relationships. We will need to support the scenario of a family living in a compound in multiple structure. In such a scenario, would we want all family members assigned to a single HH? or would we want to register the people living in each structure (usually a wife and her kids) as seperate households? In this case we can still create a relationship by making each women the head of household but then indicating they are married to a head of household in a different family. I think keeping the app flexible and allowing people to implement this how they want is probably what we want to do.
>>
>> In terms of structure, I want to make sure that is decoupled. For non reveal use cases, you should be able to register a head of household and then assign them to a location. The location could be a gps point or a structure on a map. The location could have other meta data like an address, photo, etc. For multi structure families, we could map each mother and her sub-household to a different structure or we can just use the main household depending on the use case. The later approach will work fine if we aren't using the structures as a basis for coverage like we do for reveal.
>>
>> For the reveal use case, we need to figure out how to assign tasks to structures. Once a head of HH is assigned to that structure, certain subsequent tasks can be assigned to that person.
>>
>> For task assignment and capturing encounter data on structures we should probably give a bit of thought on the intervention. Eg. if you visit a structure and give a bednet or give medicine the service is done to the people living at the structure because they can take that bednet with them and leave. If you are doing something physical to the structure like spraying, the benefits of the spray is carried over to the new family that moves into that structure. So we will need to ultimately be able to assign tasks and associate events to non patients I think at the end of the day.
>>
>> For liberia though, I think linking everything to the head of household could probably work.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Couple of follow up thoughts For the sanitation use case, we would assign the task to the head of household who then would be assigned to a location. You are probably doing a sanitation assessment at the compound level and not individual structure level anyways. If you want to do per structure you would assign to the sanitation task to the moms (other heads of households). I don't know about the person or patient. Person may makes sense but I need to understand the difference. @f-odhiambo can you provide some more context to your idea here? For family registration I don't understand the point Peter. We can either put them all in a single household linked to one structure or we can do all them as separate hh linked to a common head of hh. I don't think we need to support at this point the idea if single hh to multiple structures. This is something we have entertained for reveal but I don't think we should try and support right now. |
|
On the family registration, the UI has a screen that's "register a family" we wouldn't have that screen anymore, we'd have "register a head of household" or something like that which is a (slight?) change in UI/UX. This all sounds pretty good if we can get away with it, I might be missing something, but from a tech perspective the pro is we don't have to worry about generating things for a Group, which is an unknown and definitely outweighs the con of additional business logic to treat HHs like families |
|
You can still have a UI that says register household and we then just
register a head of household. We sort of do this already in the wcaro app I
believe
…On Tue, Jul 13, 2021 at 7:45 PM Peter Lubell-Doughtie < ***@***.***> wrote:
On the family registration, the UI has a screen that's "register a family"
we wouldn't have that screen anymore, we'd have "register a head of
household" or something like that which is a (slight?) change in UI/UX.
This all sounds pretty good if we can get away with it, I might be missing
something, but from a tech perspective the pro is we don't have to worry
about generating things for a Group, which is an unknown and definitely
outweighs the con of additional business logic to treat HHs like families
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOEQLTWL37AKYUTOUWVZ3TXTF2JANCNFSM46UCQ24A>
.
|
|
That'll work if when registering the members of the household you make users specify whether they're registering a head of household, and if they are instead of creating a new entity they're editing the entity you already created when they registered the household If you don't do that, or if people don't select that when registering the head of household, you have a patient/person that's the household separate from the head of household, which is fine as long as we don't include that resource in counts of household members and people |
From the FHIR spec, the resource Patient is used when someone is being used/tracked in a clinical setup. In a non-clinical setup, we could use
|
|
@f-odhiambo @fredhersch @brynrhodes We talked through the various options and (although semantically it's arguable a family is better represented some sort of group, or maybe organization) for CarePlan generation purposes, we know $apply works well for Patients, so we want to use that as much as possible. And this example linked from the blog article Fred shared uses Patient and RelatedPerson http://hl7.org/fhir/patient.html#maternity. A family is represented by the same Patient resource that represents the primary PoC (PPoC), membership in the family is a set of .link.other RelatedPerson resources who's RelatedPerson.patient is the non-PPoC family member. The steps for registering a family and it's members will look like:
Common operations will look like:
Limitations
|
|
@maimoonak The challenge of using the group is that the Worklofw API does not support it. The workflow API takes in Patient as a subject to generate a care plan i.e. $apply(paitent_id, plan_deifiton_id) = careplan support to add group as a param is not supported yet |
|
Could we explore the workaround if we stick to the Patient-Related Person approach |
|
Thanks everyone for the research and discussion on this. My gut feeling is that going with patients and relationships probably makes the most sense if that is the idea that is best supported / follows the design patterns most closely in FHIR. If we go this route, I think the key thing is it's important that the head of household really represents the unit where we want to assign tasks to the family level. For example, we could have a large family living on a compound. HH1 - Husband and his first wife and their children In this scenario, it would depend on how we designed the health intervention on how we registered the households. If a CHW just was registering kids and doing maternal health it would probably work that we register all family members to a single HH under the husband. If we wanted to do tasks at the structure level. Eg. do a wash check at the hut level or spray their structure, we would need to probably register each HH separately. In this case, each wife would be a head of household and have a relationship to their husband. So we'll have a situation where you have a head of household linked to another head of household but as long as their is only one head of household in the family then it's fine. They would be treated as different (but related) families in the second use case. If someone dies, do we need to migrate their encounters? We could retain the relationship still in the system. We probably just need to figure out the logic that new tasks / events are linked to the new head of household. Not sure we have to reassign data though. In general though I think we can handle most use cases with the approach of linking certain activities to the head of household and not individual members. |
|
If we wanted to follow FHIR we'd probably use Group but it's not practical b/c of $apply limitations. Let's scope using a Patient who has something of a primary point of contact (ppoc, head of household) flag, we might be able to get by without a flag and use logic but not sure. Also we're not trying to represent the detail of the family (for now), only that there's a ppoc and family members. @maimoonak and @mberg that's a good catch on death, we probably will want to migrate anything tied to the previous ppoc when the ppoc changes, like in the case of a death, probably requiring a new ppoc to be set before changing the Though, I don't think we'd need to edit the members, we'd look at the existing ppoc make sure the new ppoc points to the same RelatedPersons in its |
|
I think if the main reason we're going with this approach is The If we go with the head patient approach and represent a HH using a head patient, then 1) what does that mean for CQL authoring as now the CQL needs to understand the meaning of a head patient, and 2) how do we distinguish resources that reference the patient from resources that reference the HH (they'll all reference the same thing which is the head patient). @maimoonak mentioned we can use EDIT: sorry I missed that a discusson had already happened with Bryn. I'd still like to understand how this model works with the evaluator. |
|
@jingtang10 we have another issue on encounters here #406 |
|
@f-odhiambo my point was kinda the opposite - I think we can get it to work with encounter but how do we get it to work with all types of resources. |
|
So the overall flow for enroll family, family member, and anc entry is implemented and here are few important points and caveats and queries Patient resource has no field to mark as family head attribute and has no search params to filter except few demographics https://www.hl7.org/fhir/patient.html#search We discussed to use other entities like Flag/Observation/Encounter to use as a base to query Family Head (Flag->Patient) and then the relevant Members(Patient.link.other), however, if we have to use any other resource as a base then Group should be the one as this is the best fit for a family. The other entities would be problematic in longer run as these has large data plus queries over these would require us to be tied to use a SNOMED code display/code which can lead to data consistency issues and passing on this info to other developers in longer run. One thing that is missing in SDK but part of FHIR protocol is Common Search Params which are Profile, Tag, etc. These are fields which implementations can use to assign business context to any Resource So now it means that we should use Patient resource to represent Family independently via Profile/Tag which is embedded into patient.meta. Now issue with SDK is that ResourceIndexer is only indexing last_updated field and not other search params which means we can not query Patient on these. To make it work for time being without relying on SDK for now I explored the way it saves/updates/query and apply indexes into above mentioned class and added a class PatientExtended into fhircore which overrides the behavior of indexer and adds the tag/profile as searchable attributes and now allow querying patients via tag. Now what we do is save Patient with Flag+Extension(Family), Add tag based on this flag, (We can use Profile as well). Now we have dependency over two items in SDK (@jingtang10 ) to make it work rightway (not blocker for merging though)
I do not think that the approach of using a tag/profile is a hack itself but @jingtang10 can give a final verdict over this. We mark ANC in similar way i.e. based on flag add tag to Woman So the e2e flow works like below.
|
|
If Patient is the target, we should define a "headOfHousehold" extension (probably in WHO-Core) and use that to indicate which patient is considered head of household. Using profiles to distinguish resources is an anti-pattern in FHIR. |
|
@brynrhodes Thanks a lot for the feedback. We are not using profile now. How about using 'tag' since this is searchable (we want to query patients who are head of households). Below are patients generated by our code rightnow code (Head of household, Pregnant Member, Other Member). It has extension and tag both for now (would look into WHO extension) Head Of Household: {"resourceType":"Patient","id":"5ff09958-12c6-4996-948e-d4229a3d4d03","meta":{"profile":["http://hl7.org/fhir/StructureDefinition/Patient"], Pregnant Member: {"resourceType":"Patient","id":"a8be747b-5698-4ff1-96cd-383948137af4","meta":{"profile":["http://hl7.org/fhir/StructureDefinition/Patient"], Other Member: {"resourceType":"Patient","id":"ce515390-a4c5-4c40-91f2-97f4029bb430","meta":{"profile":["http://hl7.org/fhir/StructureDefinition/Patient"]},"name":[{"family":"jhgh","given":["hjhj"]}],"gender":"male","birthDate":"2021-08-04","link":[{"other":{"reference":"Patient/5ff09958-12c6-4996-948e-d4229a3d4d03"},"type":"refer"}]} |
|
Hi @maimoonak , that makes sense, but I would still recommend establishing an extension to explicitly indicate that a patient is a "headOfHousehold". You could provide guidance (and even a profile to enforce) that the Family tag be used in addition to the headOfHousehold extension, but tags should not be used as a stand-in for semantics, because the FHIR spec indicates that applications are not required to process tags to interpret the meaning of a resource: https://hl7.org/fhir/resource-definitions.html#Meta.tag |
|
@brynrhodes Thanks. Would add the "headOfHousehold" extension to our Patient. |
|
@jingtang10 Kindly review subsequent comments here and share your thoughts |
EDIT: created google/android-fhir#735 |
do we also need extensions to mark referenced resources as family-oriented resources rather than patient-oriented resources? i.e. if there's a task for family referencing the head of household, then we need to mark that task as a household task to distinguish other tasks related to the head patient themself. |
f-odhiambo
added
Size - L
|
@jingtang10 the profile, tags are part of fhir protocol i.e. searchable resources. I did not find extensions or these properties. If we make this part of sdk it would be great but I am not sure how do we synchronize this feature with FHIR. @pld can comment on this. |
|
#493 The was supposed to close the issue but now it needs to be on new code structure |
can you link an example here please? thanks! |
my suggestion is similar to bryn's. but not only on the patient but also on the referenced resources to distinguish a household task from a patient task. |
* Family register packages * Family Register setup * Update PatientExtension.kt * Delete PatientExtended.kt * Remove overdue filter * Family/ANC flow with ui updates * Rename method to loadResourceTemplate from loadConfig * Sync filters removed|LoadAll used in query * Add separate query for side menu * Data package restructuring|repo modifiers changed
3.5 days FTE + 20% buffer
SubTask
The text was updated successfully, but these errors were encountered: