@wyclif expressed concern about this approach on the ticket (TRUNK-5331), so I’m bringing that discussion back here.
Personally, am not sold in on making start date nullable, I feel like a null startDate is bad data, a null start date doesn’t make sense.
I still think we can fix the bugs without making start date null by just fixing the implementation of Cohort.intersect.
I should have shared my complete thought process earlier. My bad. (And it’s fair to say that I have not thought this through as well as I should, so I’d like some confirmation here one way or the other!)
My thinking is that in the TRUNK-4906 (Expanded Cohort Details) ticket, we introduced some new complexity, without properly addressing backwards-compatibility, or maintaining the simpler use case.
In fact @mseaton complained about this here: Omission of patient from CohortMembership model. There’s a use case for “simple cohorts” which are just a list of patients, and you don’t indicate the start or end date, in addition to these new “expanded” cohorts. (@jdick mentioned it here.)
So, I’m trying to respond to those complains and introduce some backwards-compatibility retrospectively, without removing changes that have already been released.
My proposal is that if you write your code without using dates, then Cohorts work in the old way. For example:
Cohort favorites = service.getCohort("Favorites");
Alternately, if you want the complexity, then you specify dates:
Cohort nutritionStudy = new Cohort();
nutritionStudy.addMembership(new CohortMembership(selectedPatientId, enrollmentDate));
(If we had a time machine I would suggest we go back and leave Cohort as-is, and introduce a new DateRangeCohort. But we’ve already released a platform version with the new code.)