Those 2 concepts are Measurement concepts of ‘gestational age in weeks’, so you won’t have that value in the set of concepts up front, it’s based on the patient record.
I glossed through the algorithm (from the paper, not from the repo, but my own notes on it) and there is part of the algorithm that does this:
select PERSON_ID, Category, /*convert gestational weeks to days */
case when category='GEST' and value_as_number is not null then 7*value_as_number
when category='GEST' and gest_value is not null then 7*gest_value
else null end as gest_value, start_date
This part of the algorithm finds those codes with category = ‘GEST’ and returns either the value_as_number from the measurement/observation record or the hard-coded gest value from the algorithm specification. The idea is that one way or another, you will get a gest value to subtract from the marker event date. There is a possible null value in that table (the final else) and so, if there is a case where a GEST category comes back with a null gest_value, I think the right thign to do is drop those pregnancy markers (via a WHERE clause filter) because the purpose of the GEST category markers is to tell you ‘age of gestation’ and if we don’t have the value in that category, the it’s an incomplete record and it should be dropped.
I would not change the dateadd() in the algorithm to sometimes subtract the gest_value and sometimes subtract 1 day. The purpose of the gest_value is to offset the event date to a pregnancy start date, therefore, it’s better to drop the rows that do not have a gest_value in that pregnancy marker event.
But, I would need to do a through review of the algorithm to ensure that didn’t have negative impact. From your summary report, it looks like you did’t ever have a case where the start date was the p.event_date -1 day, so, you are probably finding all the gestational values in your data to produce the episodes.
