FHIR Chat · Evaluation of arbitrary population types · cql

Stream: cql

Topic: Evaluation of arbitrary population types

Sean McIlvenna (Apr 16 2021 at 19:29):

I'm looking at measures that have populations that aren't very typical... I'm finding that the logic in HAPI for measure evaluation would have problems processing logic for non-standard populations. For example, I see:

switch (populationType) {
  case INITIALPOPULATION:
    ...
  case NUMERATOR:
    ...
}

Which would be a problem for a measure that doesn't have a population type of INITIALPOPULATION, NUMERATOR, DENOMINATOR, etc.
Are there any plans to broaden this logic to support arbitrary population types?

Sean McIlvenna (Apr 16 2021 at 19:33):

Are there any plans to support stratifiers?

Sean McIlvenna (Apr 16 2021 at 19:36):

And, lastly (I think), is there any documentation on how the hapi-fhir-jpaserver-cql module evaluates a given Measure? Seems like there's lots of logic/decisions in the code, and I'm trying to figure out how best to share that logic (requirements?) with an analyst responsible for developing a measure that can be evaluated using HAPI.

Bryn Rhodes (Apr 16 2021 at 21:04):

Hi Sean, the populationType code system in the base specification is based on the standard population types from specifications currently in use, but we specifically made the binding extensible to support other calculation methodologies (FHIR-Saner has already defined some of these in their implementation guide). The HAPI server evaluation logic understands the population types in the base spec, so would have to be extended to support additional ones.

Bryn Rhodes (Apr 16 2021 at 21:07):

For stratifier calculation, that is something we are in the process of adding, we'll be testing that in the upcoming connectathon.

Bryn Rhodes (Apr 16 2021 at 21:09):

And for communicating requirements, there's been quite a bit of work in that space recently, take a look at some of the examples in the May ballot of the QM IG: http://build.fhir.org/ig/HL7/cqf-measures/Measure-measure-exm125-FHIR.html

Bryn Rhodes (Apr 16 2021 at 21:16):

We're working on refining the presentation, but the information is there for what would be the human readable content of the measure. Does that help?

Sean McIlvenna (Apr 16 2021 at 23:09):

Thanks for that info @Bryn Rhodes! Saner is one of the measures that I had in mind... Saner, for example, creates different populations for each calculable metric. For example, a population for the # of total patients with COVID, another population for the # of total patients with COVID on a ventilator, etc. If we developed another measure that behaved similarly with the use of populations but for fundamentally different calculations than SANER, I get the impression we would have to coordinate with you to add support for those populations..??

Sean McIlvenna (Apr 19 2021 at 15:20):

Got a chance to check out that link @Bryn Rhodes ... that's not quite what I had in mind. That's per-measure documentation. What I had in mind was more-so system documentation describing how HAPI processes a measure/CQL.

Bryn Rhodes (Apr 22 2021 at 18:50):

Hi @Sean McIlvenna , unfortunately there's not a lot of documentation there. At the highest level, it works by switching on the scoring type and evaluating the population criteria appropriate for that population type, patient-at-a-time, aggregating results if it's a summary request. So handling new scoring types/population types would be a matter of introducing new cases in that switch. Note that there is some refactoring going on in this layer right now and that should be done pretty soon, it might make sense to wait for the result of that and see how to apply in that newly refactored evaluation logic?

Sean McIlvenna (Apr 22 2021 at 21:28):

No worries. After discussing with Rick for a bit, I think the proper way of handling this would actually be to create a separate Measure.group for each data element, each with a population of initial-population. So, rather than abstracting at Measure.group.population, abstracting at Measure.group.

Sean McIlvenna (Apr 22 2021 at 21:28):

Regardless, you're probably right, it makes sense to hold off until your refactoring is done.

Sean McIlvenna (Apr 22 2021 at 21:29):

With all of that said, I'd love to see more documentation on how this module of HAPI processes a given Measure.

Last updated: Apr 12 2022 at 19:14 UTC