Please revise the conformance requirements to make clear what packaging tools are responsible for producing and what consumers can expect from this information as related to the represented measure. Specific areas of concern to consider:

1. the current list of conformance requirements don't use any conformance verbs. Only the last one uses the word "should" but not capitalized as expected for conformance requirements. Based on my reading, the first 4 entries in the list constitute an algorithm for identifying and mapping ELM elements to FHIR DataRequirement entries. These should be sub-points under currently entry 5 which should be updated to indicate that systems "SHOULD" (as a conformance verb) populate DataRequirements based on this algorithm.
2. the current description does not make clear that the algorithm is partial and not guaranteed to return all details of all data requirements for all measures. I've included a specific example below for illustration. I don't believe that it is possible or wise to detail a complete algorithm for data requirements extraction here. However I do think it is appropriate and advisable to include some language indicating that the set of data requirements returned from this algorithm will not always be complete

Specific example of a case where a code filter on a data requirement won't be picked up by the algorithm for retrieves currently described in the section:

CQL:

ELM: the Condition fetch is separate from the code filter for the stroke conditions in the ELM…

Data Requirements: …so the stroke condition codes don’t show up in the data requirements per the logic outlined in the IG