FHIR-53276 Add canonical profile reference support to Group characteristics

[bkaney]

Add extension to enable Group.characteristic to reference canonical profiles for cohort definitions, allowing characteristics to specify "instances that conform to the referenced profile" as inclusion criteria.

Changes:

• Add GroupCharacteristicValueCanonical extension

  • Extends Group.characteristic.valueReference to support canonical URLs
  • Enables referencing FHIR profiles as cohort inclusion/exclusion criteria

• Update CRMIGroupDefinition profile

  • Add valueReference.extension for valueCanonical
  • Enable profile conformance as a characteristic type
  • Document intended use for cohort definitions

• Add ExampleCohortDefinition instance

  • Demonstrates adult diabetes patient cohort
  • Shows three characteristic types:
    • Disease diagnosis (valueCodeableConcept with SNOMED)
    • Age criteria (valueQuantity with LOINC age code)
    • Profile conformance (valueReference with canonical extension)
  • Uses semantically appropriate codes (SNOMED, LOINC vs generic)

This enables expressing cohort criteria where membership is based on conformance to specific FHIR profiles, complementing traditional clinical and demographic characteristics.

[joonatanv2]

Happy to see CRMI got started with the idea so quickly! First, some context; Joonatan from Duodecim here, working on most of the clinical reasoning -module in Finland, from practice guidelines to quality measures -- lately with some overlap in the medication definition -space as well. I suggested @bkaney that a conceptual Group resource might be a good alternative for defining what I'll call "clinical concepts" here. That is, the case feature definitions of CPG. My claim is that identifying such facts about a patient is a ubiquitous need in our context, sometimes with a particular value, such as the value of an Observation, attached.

From my perspective, clinical concepts are defined at least in the following contexts, which I'll point out from the Quality Improvement Ecosystem diagram:

1. EBM -- the EBM-on-FHIR IG has various profiles of CohortDefinition specifying inclusion and exclusion criteria. These are used at many levels, with the StudyEligibilityCriteria and RecommendationEligibilityCriteria being especially relevant.
2. CPG -- the CPG IG is centred around CaseFeatureDefinition, which is a combination of assertion and inference logic, mostly defined as CQL. Being able to assert these explicitly by the means of a generated SDC Questionnaire seems like the only unique requirement. There are also other definitions, such as PathwayEnrollmentCriteria, which seem to be less well-defined.
3. CDS -- implementers of CDS systems may have their own representations of clinical concepts. Even if they are to use FHIR -based clinical reasoning, going with CQL is only one way of building a library of clinical concepts from which various rules can be composed. If interfacing with forms is important, one could also do that via. modular SDC Questionnaires and Template -based extraction.
4. QM -- the QM IG shares many of its executional aspects with CPG, i.e. both can share CQL logic. Interestingly enough, the Measure resource itself has a striking structural similarity to the Group profiles used in EBM. Both define cohorts with inclusion and exclusion criteria, with Measure performing this through a number of sequential population types.
5. Analytics -- the SQL-on-FHIR IG interfaces with external analytic tools through flat ViewDefinition resources. It shouldn't be too difficult to see how a ViewDefinition could be linked to a particular Group.characteristic, even if the joins that constitute the final concrete group are left out.

In our use experience, these effectively reduce to:

• EBM → CPG/CDS → QM/Analytics, i.e.
• CohortDefinition → CaseFeatureDefinition → Measure/ViewDefinition, or
• Custom executors for Group → CQL executors for PlanDefinition → CQL/FHIRPath/SQL-on-FHIR for ViewDefiniton

...all of which deal with identical clinical concepts, such as the example "adult diabetes patient", from different perspectives. (Note that I'm not claiming that the use cases are identical in general.)

As an operator that deals with all of these levels in-house, Duodecim is particularly interested in CRMI being the scope for unifying the defining of clinical concepts as (computable) knowledge artifacts. Our initial goal was to find a terminology through which we could refer to the "same" clinical concept across the entire cycle, but why stop there? Ultimately, I would like to see an operation like Group/$expand (or perhaps Group/$match), which would "concretize" or exapnd a conceptual group into the actual included instances. This is somewhat analogous to ValueSet expansion. The important bit here is that both the case for population-level cohorts and the per-patient clinical concepts are the same thing, with the latter being expanded against a single potential instance. This would enable using the same definitions (again, CPG case features) even in large populations without per-patient CDS calls, with something like the SQL-on-FHIR.

While the symmetry between CPG(CDS) and QM is relatively well-known in FHIR, I'd also like to underline that there is an equivalent symmetry between EBM and Analytics. Both are concerned about defining cohorts for secondary use. Both often interface with external formats, such as OMOP, for their datasets. I'd also wager that many of the same people are involved, likely from university hospitals. There is a lot that can be shared here. I don't see any fundamental reason as to why these two pairs couldn't use the same clinical concepts, at least technically. Why couldn't a RecommendationEligibilityCriteria be a PathwayEnrollmentCriteria and/or a (a set of) CaseFeatureDefinition resources?

[joonatanv2]

Onto more practical points about this PR; I had an exchange with Brian Alper, who's been pioneering EBM-on-FHIR and the various profiles on the Group resource. Let me start by stating that I personally dislike the idea of bypassing CPG with an EBM-on-FHIR variant. This is antithetical to interop within the standard itself, which sets a bad example. Instead, better sharing of the clinical concepts should make it far easier for the evidence to flow from the research (in the form of various resources, such as RecommendationEligibilityCriteria) to CPG and the workflow considerations (i.e. PlanDefinition) that entails. I am aware of projects such as the CPG-on-EBM-on-FHIR IG, which have seen success. My hope is that introducing better support for Group -based clinical concepts into CRMI would be a step in the direction of better integrating EBM and CPG without the need for an additional IG. (This isn't me trying to discredit the hard work of anyone, but rather trying to find a better way of interfacing across the Quality Improvement Ecosystem!) I understand that this isn't just a technical undertaking, but we might start from there.

With that said, Brian Alper and I agreed that coordinating approaches to the Group resource and CohortDefinition across EBM and CPG would be ideal. CRMI would be the space to do that. While I won't claim to speak on behalf of Brian, or anyone else, I'll try and summarise some of the findings for this purpose.

On a high level, similar levels of capability seem to be required:

• PublishableCohortDefinition -- Descriptive cohort definitions for sharing the eligibility criteria for the understanding of study protocols use for regulatory decision-making.
• ComputableCohortDefinition -- Sharing the eligibility criteria to enable computable matching against datasets that are not in FHIR, such as Redcap or OMOP. That is, a computable cohort definition that a matching algorithm can recognise.
  • I see an opportunity for collaboration between EBM and the Analytics / SQL-on-FHIR groups in this space, given that there is a shared interest in interfacing with OMOP datasets and ETL in general. With the possible interplay between Group.characteristic and ViewDefinition, this should already be a technically similar use-case.
• ExecutableCohortDefinition -- Sharing the executable script for eligibility criteria.
  • There is a characteristicExpression extension, which could be used.

The matching (or what I called "expanding") of the cohort definition boils down to understanding three things:

1. The cohort definition itself,
2. The dataset you are searching in, and
3. The matching algorithm.

From this point of view, using the Group.characteristic field to detail information about the dataset, i.e. the profile of the FHIR resource, is mixing up the first and second concern. "This patient resource follows the US Core profile" is not exactly a descriptive characteristic of the cohort from a non-technical standpoint.

I do think it warrants discussion (perhaps on the Wednesday call) to determine whether or not using profiles as characteristics is a good idea. If the primary use-case this seeks to enable is the tracking of data requirements such that the matching algorithm could be implemented, then perhaps a dedicated Group.extension:dataRequirement could be considered instead, akin to the characteristicExpression of EBM?

---

There are a lot of good examples of the Group resources used in EBM. I'll share a couple of the ones Brian provided:

• https://build.fhir.org/ig/HL7/ebm/Group-171819.json.html
• https://fevir.net/resources/Group/170443
• https://fevir.net/resources/Group/32139
• https://fevir.net/resources/List/396954