OccupationalData.employmentStatus backbone element feels a bit awkward to me. It feels inconsistent, such that it would be better to choose #1 or #2 (not a hybrid of both).

1) If we expect implementers to have the OccupationalData.employmentStatus.effective_x_ dates, then I would expect OccupationalData.employmentStatus (backbone element) to have a cardinality of 0..* to convey history, such as "subject was employed from 2000-2005, then unemployed in 2006, then employeed again from 2007 until today" regardless of job

2) If we don't expect implementers to have the OccupationalData.employmentStatus.effective_x_ dates, then I wouldn't want a backbone element or effective dates. It should collapse down to a single "top level" current OccupationalData.employmentStatus of type CodeableConcept. The backbone element isn't needed if there is only one current status and the effective date could be reframed as the OccupationalData.date

My preference is more aligned with #2 or better yet folding the employmentStatus.code into the job list. Without the value set for employmentStatus.code, it is hard to conclude whether one status at the top level will suffice.

For example, will student be supported in the employmentStatus.code value set? If so, then the cardinality of employmentStatus gets tricky if the student is also employed part-time. Does employed trump student? Likewise, does employed trump retired (for a subject who retires from their usual work/first career and now is part-time in a second career)?

Note: our system tracks this data generically as a person/organization relationship, which means the "job" or org relationship can be to either an employer or school and the status is specific to a single person/organization relationship.