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.