I can try to explain the first part, but for adding the additional analyses (that groups procedures) you’d have to look at the condition group logic to apply it to procedures and then create a custom feature in Atlas by providing the custom SQL (described here).
Re: Condition Group Eras
There’s 3 parts here: Domain, Grouping and Eras. The Domain is simple, it’s using conditions. The Era means that it is going to read out of the Era table (for the domain: condition). The Grouping is done by using CONCEPT_ANCESTOR, and every parent from every child coming from the condition_era table will have an ancestor concept, and each person will contribute to the ancestor concept at most once. So consider the following 2 patients in a hypothetical cohort:
Patient 1: 3 diagnoses: pain in right shoulder, pain in left shoulder, pain in shoulder
Patient 2: pain in right shoulder
Given that pain and right shoulder and pain in left shoulder are children of pain in shoulder:
The characterization of this would show there was 1 person with pain in left shoulder, 2 people had pain in right shoulder, 2 people had pain in shoulder. If you look closely at the condition group logic you will note that they are limiting which ancestors that can be chosen for groping, and there’s a branch of code specifically for ‘Condition Occurrence’ or ‘Condition Era’: In the case of condition, they are excluding parents that are like ‘Clinical Finding’…everything is a clinical finding in condition, so that makes sense, but they have other exclusions too. So, to answer the question about what the logic is for identifying the groups: you can see it in the SQL. If you are going to do the same thing with procedures, you will need to consider what level in the CONCEPT_ANCESTOR you are too broad and no longer want to roll-up children to an ancestor.