Note that for implementations that support profile-informed CQL, this means that the result of retrieve expressions must respect the profile stated in the templateId element of the retrieve. This is not to say that the FHIR resource must declare profiles to which they conform, only that with profile-informed authoring, there is an expectation that the ELM expects that FHIR resources returned through a retrieve will conform to the stated profiles. How that conformance is guaranteed is left up to implementations.
This means that it is not at all obvious how to implement a retrieve with a templateId, as there is no expectation that the resource instances in the Bundle will have declared the profiles they are conformant too. On the other hand, validating each and every resource in a bundle is far to resource intensive. Still, the templateId is important, as it also acts as a filter on the bundle to get a subset of entries.
Luckily, most (all?) of the current (QICore) profiles, and thus templateIds we encounter in the wild are actually simple fixed code profiles on the default coded property, so we could go for a strategy where we filter based on the default property.
As an aside, one could argue that the cql2elm compiler, knowing the profiles, would be able to generate Retrieves that filter on property rather than templateId, but that's another discussion.
After we have integrated #388, we will have access to the "TemplateId" for a
Retrieve.Section https://build.fhir.org/ig/HL7/cql-ig/using-modelinfo.html#profile-informed-modelinfo states:
This means that it is not at all obvious how to implement a retrieve with a templateId, as there is no expectation that the resource instances in the Bundle will have declared the profiles they are conformant too. On the other hand, validating each and every resource in a bundle is far to resource intensive. Still, the templateId is important, as it also acts as a filter on the bundle to get a subset of entries.
Luckily, most (all?) of the current (QICore) profiles, and thus templateIds we encounter in the wild are actually simple fixed code profiles on the default coded property, so we could go for a strategy where we filter based on the default property.
As an aside, one could argue that the cql2elm compiler, knowing the profiles, would be able to generate Retrieves that filter on property rather than templateId, but that's another discussion.