For Cohort Module:
Just to provoke the thought process following are two scenarios for two different cohorts:
1- Pregnant woman with Convulsions OR PIH:
We may need to capture
Cohort:
Cohort Unique ID
Cohort Programme (A program can have multiple cohorts OR it could be a parent Cohort)
Cohort Name
Cohort Location (optional)
Cohort StartDate
Cohort EndDate
Other possible cohort related properties
Cohort Details (Encounters and Obs)
Cohort memberS:
Unique Id in cohort
Address (person address)
Other demographics (person/patient properties)
Location in Cohort (For ex if associated with hospital)
Join and Termination Date
Other possible properties
Other details or encounters for person
2- Household (HH)
HH or Cohort:
HH ID / Cohort Unique ID
Cohort (A parent Cohort with which each HH would be associated with)
HH Name / Cohort Name
HH Location (optional)
HH Head
Cohort StartDate
Cohort EndDate
Other possible cohort / HH related properties
HH Details (Encounters and Obs)
HH members:
Unique ID in HH
Relationship with HH Head
Location (Could be different from HH depending on HH definition for the programme)
Address (person address or if same as of HH address, or HH Head address some way of linking it)
Other demographics (person/patient properties)
Join and Termination Date
Other details or encounters for HH member
As you can see both studies are completely different but also merge-able to be captured using same data model, forms and data storage etc. Considering the above two case studies as final product or test cases for our final product, could you
0 - Do a research about why Health people need cohorts, what does it mean, and how it is different from Normal Health records in EMR
1 - Find out the lacking in current core cohort and encounters model
2 - Compare with current HH module data model
3 - Suggest or discuss the possible solutions
4 - Using any of your favorite UML diagram, model the cohort module.
Please note that this list is not to burden you, its just to give you a direction. Especially the last one! Also we would keep it refining all the way through project life cycle so make sure to use a UML tool (a suggestion could be Astah Community edition) so that you can easily modify the diagram. Also you already have explored cohortbuilder, HH module, and reporting module. Based on your experience with that do you find any thing missing from list above?
I would like to know if I need to include it in the UI mockups and regarding the HH head, can he/she be any member in the household ? or is there any specific criteria to satisfy to be a HH head ?.
I will make note of the points and will come up with the answers asap .
The HH Head could be any member of household assigned as HH Head by user
or data entry person. It does not have any criteria as this could change per study basis. UI mockups is a
good idea but not mandatory for the list above.
A cohort is a group of patients experiencing similar symptoms which can be monitored over a period of time.Detailed patient data and biological samples are obtained of all the patients in a cohort to understand and analyse for trends.Using established resources, saved both time and money and allows to speed up development for new tests and apply them sooner.
We can group the encounters if it is for the same patient. Since each visit to the hospital is considered as an encounter, the patient can visit the hospital due to various reasons and consult different providers depending on the symptoms.We can group the encounters of a patient into one.
Similarly can be done in observations, where in observations are recorded at that moment of time. History of observations needs to be maintained. In case of pregnancy concept, the observation needs to be carried forward, which is not seen in the current module.
With respect to the current HH module, we can add the following suggestions to improvise the experience of using HouseHold and make it easier for the user. The current data model focuses on membership, encounters, observations, location, HH head etc.
Thanks alot @burke , this is really helpful and can capture most of the data a cohort may need.
However, few questions below:
Cohort role: What does cohort member role mean? I tried searching this in articles about how cohorts are organized but could not figure out?
Cohort group/parent:
1- In studies, sometimes we need to expand a cohort and thus want to merge/scale multiple cohorts into single main cohort.
2- Also, different cohorts need to be combined into same program/department/management
Both of above scenarios could be handled by allowing a parent-child relationship between cohorts.
3- This becomes a real critical requirement when it comes to household. Because household data would be captured under a program/study/cohort, but then each household itself is a cohort/group with several members associated. So, each member belongs to a household and household belongs to a cohort.
Cohort level data: cohort_visit, cohort_encounter, cohort_obs seem to represent cohort-member data as currrently for patients in openmrs. Do we have any provision for cohort level observations/encounters.
For ex: many times we need to capture data for current state of cohort (any critical failure of system occurred, something changed in flow etc). This would become a genuine requirement when it comes to household, since we also need to capture observations for each household as well as for each household member.
Probably adding tables to maintain relationship between cohorts and adding tables to capture data for cohort encounters and observations would resolve the issues.
But is there any other better way that we can capture encounters and obs for cohort and cohort members in same table.
@sharonvarghese probably it would be a good idea to start creating ERD based on the model Burke has shared. This would also help you in understanding the missing components better.
Also to get better understanding of project its always better to get end user perspective. Following are very good articles about how to design a cohort.
We can also work more to add a randomizer component in our module later on. Keeping provision for this would be a good idea.
Thanks for the suggesstions and links to understand the module better. Will update you asap about my understanding with the ER Diagram and will also consider an end user’s perspective in improvising the module and also will research more about including a randomizer component .
The intention of cohort_member.role was to allow the role of a member within the cohort to be optionally defined. For household cohort types, this could be things like Head of Household, Spouse, Child, Sibling, Relative, Other, etc. A treatment group cohort might specify roles like Leader, Secretary, etc.
Ah. This point highlights a critical missing piece to my data model: the actual member. I had specified cohort_member, but hadn’t actually linked to the member itself. I updated my earlier post to include this. At first, I thought of responding to you with “Cohorts are groups of people” and questioning how consumers of these cohorts would deal with consuming a variable hierarchy. On further reflection, I think we can meet your needs not with creating a separate hierarchy; rather, by allowing a member of a cohort to be either a person or another cohort. Using the member’s role, one could create fairly sophisticated relationships between cohorts.
The cohort service could hide this complexity by allowing naive consumers to simply ask for all people in a cohort and do the traversal of nested cohorts under the hood. Clients aware of the nesting could use it directly, but we wouldn’t want to force all code needing cohorts to have to deal with this complexity.
Actually visit, encounter, and obs tables are used for collecting patient-level data. My proposed cohort_visit, cohort_encounter, and cohort_obs would be used to collect similar data for groups of people (i.e., cohorts). The reason I suggest replicating the existing patient-level tables as closely as we can is so we could potentially re-used logic, provide consistency for developers interacting with both patient-level & cohort-level data, and leave the door open to possibly merging these in the future. I would not try to merge them now (e.g., in FHIR’s Observation.subject, observations can be for either person or cohort), since we have lots of code in core and across modules that assumes visit, encounter, and obs data applies only to people.
= required