FHIR Chat · Clarifications from yesterday's call · Covid-19 Response

Stream: Covid-19 Response

Topic: Clarifications from yesterday's call

---

Josh Mandel (Apr 07 2020 at 17:14):

Catching up with @Gino Canessa and we're confused on a few points (given our decision to wrap the entire CDC report in a single MeasureReport, and the entire FEMA report in another single MeasureReport).

1. Did we decide that it's okay not to populate Measure.type, and instead add extensions at the Measure.group level to convey any necessary type info?

2. Did we decide that it's okay not to populate Measure.scoring, and instead add extensions at the Measure.group level to convey any necessary scoring info?

3. Did we decide that for MeasureReport, we won't constrain ourselves to a single scoring type across groups? (In other words, did we decide to allow for a mix of ratios and counts across the groups in a given report? In other other words: we shouldn't need to add "fake" denominators of 1 to simple count-type measures.)

I believe the answer is yes to all three. Did anyone have a different take-away?

Bryn Rhodes (Apr 07 2020 at 17:59):

You _could_ do that, but you wouldn't be communicating the scoring semantics. Is that okay? I didn't see that as one Measure, I saw it as at least 3 for the CDC (for Location/Bed, Location/Ventilator, and Patient).

Josh Mandel (Apr 07 2020 at 18:02):

Yesterday on the call we decided between "3 MeasureReports that together correspond to the CDC form" and "1 MeasureReport that by itself corresponds to the CDC form" and we selected the latter. @Keith Boone it'd be great if you can chime in here to make sure we're on the same page.

Josh Mandel (Apr 07 2020 at 18:02):

you wouldn't be communicating the scoring semantics.

I think the intention would still be to communicate this, but in extensions (on Measure.group) if necessary.

Vassil Peytchev (Apr 07 2020 at 18:18):

Josh Mandel said:

you wouldn't be communicating the scoring semantics.

I think the intention would still be to communicate this, but in extensions (on Measure.group) if necessary.

As an observer from the sidelines I am probably missing something, but all these extensions seem to make things more complicated, not less.

Bryn Rhodes (Apr 07 2020 at 18:56):

I tend to agree, it feels like working against the resource rather than with it, since the resource can already say these things, though it admittedly requires three, not one (at least for the CDC content).

Gino Canessa (Apr 07 2020 at 19:11):

The issue is currently in the FEMA reports - some fields are counts and some are ratios. If we want to include all of them in the same Measure / MeasureReport, then we need to:

• change all fields to proportions
• have a mix of proportions and cohorts
• exclude the ratios as they are based on counts already present

In practice, anyone consuming the FEMA report would know what the score for field 'x' is (e.g., if it's a count or a percentage). In the first method, the generation isn't as simple (counts are added as ratios with denominator 1). In the second method, we don't describe the scoring method at top level. In the third, we rely on someone else doing additional processing.

If we don't like any of the choices, then we need to revisit the decision to have all of the fields in a single Measure / MeasureReport.

I assume that whatever path we take will be mirrored in the CDC version - which is simpler today, but can/will evolve over time (so needs to account for the possibility of ratios).

Josh Mandel (Apr 07 2020 at 19:24):

Also to be clear about what went into the decision yesterday: The goal is to make reports as clear and straightforward as possible. We are not trying to make the measure definitions themselves "simple", when this is at odds with making the reports simple.

Keith Boone (Apr 07 2020 at 21:05):

Yes, since we are going to be developing the Measure resources in this project, with people who can get into some of the complexity of details. But MeasureReport is what others would see (if they are lucky, some are just going to be seeing CSV files or even ick: XLSX files), because the idea is to slip into existing reporting mechanisms until they are able to consumer FHIR MeasureReport resources.

Josh Mandel (Apr 07 2020 at 21:06):

Keith, can you confirm my 3 questions from above? All "yes"?

Hans Buitendijk (Apr 07 2020 at 21:07):

I'm about to update the organization of the measure spreadsheet to align with the direction and use of Measure attributes and plan to use @Gino Canessa samples, unless there is a more current version.

Gino Canessa (Apr 07 2020 at 21:09):

The samples I've posted now have everything as ratios (based on my understanding from yesterday) - I would wait until we have clarification on that before moving forward.

Once it's clear the correct path, I will push an update (should take 5 mins or so)

Hans Buitendijk (Apr 07 2020 at 21:15):

@Gino Canessa : The basic structure of CDC data at the Measure level and individual measures at the Measure.group.etc. level would not be impacted by that, right? Just different values. Intent is to create a separate level with the Measure level data, while the current sheet would then have less rows, just a pointer, to the common data. Terminology gets somewhat wonky, as the Measure is effectively a measure group, but so be it.

Gino Canessa (Apr 07 2020 at 21:22):

The choices result in different shapes of ...group.population in measures and reports. For example

• numTotBeds as cohort: population has one value of coding initial population
• numTotBeds as proportion: population has two values: numerator (value) and denominator (1)

I'm not sure exactly what you are working on, so I'm not sure if there is a difference for you.

Abbie Watson (Apr 07 2020 at 21:33):

Having the report in ratios seems like it's a matter of presentation, in some regards. Similar to C degrees vs F degrees. The underlying metric is actually the same, but is being interpreted by different frameworks/jurisdictions. Why not build the ratio portion into the application? Why not have a microservice translate non-ratio reporting into ratioed reporting at the point of entering the new jurisdiction?

Hans Buitendijk (Apr 07 2020 at 21:43):

@Gino Canessa I don't think that makes too much of a difference to the spreadsheet structure, while it can be tweaked when it is final, while changing agreed to values for specific attributes can be updated once finished.

Keith Boone (Apr 07 2020 at 21:49):

Josh Mandel said:

Catching up with Gino Canessa and we're confused on a few points (given our decision to wrap the entire CDC report in a single MeasureReport, and the entire FEMA report in another single MeasureReport).

1. Did we decide that it's okay not to populate Measure.type, and instead add extensions at the Measure.group level to convey any necessary type info?

2. Did we decide that it's okay not to populate Measure.scoring, and instead add extensions at the Measure.group level to convey any necessary scoring info?

3. Did we decide that for MeasureReport, we won't constrain ourselves to a single scoring type across groups? (In other words, did we decide to allow for a mix of ratios and counts across the groups in a given report? In other other words: we shouldn't need to add "fake" denominators of 1 to simple count-type measures.)

I believe the answer is yes to all three. Did anyone have a different take-away?

All yes.

Josh Mandel (Apr 07 2020 at 21:50):

Thanks Keith! (Implications are that the core resources should support (1) and (2), and CQM profiles should allow (3).)

Gino Canessa (Apr 07 2020 at 22:05):

Thanks! Pushed out updates. The CDC and FEMA measures no longer specify a scoring model and have composite type. Do we just want to use the structure definition system to add those fields to groups (e.g., system: http://hl7.org/fhir/R4/StructureDefinition/Measure, code: Measure.scoring)?

Hans Buitendijk (Apr 07 2020 at 22:27):

Suggest to add Measure.author. Would be CDC/NHSN and FEMA respectively.

Hans Buitendijk (Apr 07 2020 at 22:51):

@Gino Canessa : Measure.relatedArtifact is missing data in the example (https://github.com/microsoft-healthcare-madison/learning-spike-erp/blob/master/generated/t0/Measures-CDC.json). Not sure whether you still need to apply that. Suggestion was to use relatedArtifact.document and include an extension for publication status so we could use relatedArtifact.type, relatedArtifact.label, relatedArtifact.display, relatedArtifact.extension-status, relatedArtifact.document.url, and relatedArtifact.document.creation. See values for CDC and FEMA for each here: https://docs.google.com/spreadsheets/d/1TS_r8gfjZPXREOvEJaAzK-rweh8whrSH9OM6ZTA4yss/edit#gid=1223398589 in the MeasureGroup tab. Can you use the values from the spreadsheet to be in sync?

Hans Buitendijk (Apr 07 2020 at 22:54):

I am confused why the subject of the sanerCDC measurement group is Location as it includes ventilator and patient data. Should we suggest that Measure.subject[x] can repeat? Picking one does not work either.

Hans Buitendijk (Apr 07 2020 at 23:01):

Added group.code.coding.display for a measure title.

Hans Buitendijk (Apr 07 2020 at 23:01):

We lost a place to put the guidance provided for each measure. We could use group.code.text, but that does not seem right. Suggest an extension of group.extension-guidance. Alternative, could go into the population.criteria.description for either the numerator or denominator, whichever one fits best. Then perhaps the expression is only used if computable.

Hans Buitendijk (Apr 07 2020 at 23:27):

Should group.code.text fit better in group.description?

Keith Boone (Apr 08 2020 at 05:41):

In the examples I'm preparing, COVID 19 Patient measures aren't based on Location, but rather Encounter.
That's because through Encounter, you can get to diagnosis, and condition reported in encounter, and location.
So, three groups, Location, Order/Result, Encounter

Gino Canessa (Apr 08 2020 at 15:22):

@Hans Buitendijk : I have added many of the fields from the example locally.

• Why is the Measure.Author set to CDC/FEMA? They authored the relatedArtifact documents, but I do not believe they are authoring these measures
• I cannot find a RelatedArtifact extension-status in the registry, where is the definition for it?
• I believe the subject being Location was that it is a Location answering these questions, whatever type they are

Hans Buitendijk (Apr 08 2020 at 15:30):

@Gino Canessa If Measure.author is meant to be the author of the FHIR expression of the measure, the definition should make that much more clear. We should JIRA that. We then need an extension on the Measure.relatedArtifact to capture the author there.
relatedArtifact.extension-status does not exist yet. I thought @Bryn Rhodes would address that. May want to add author as well.
I read the meaning of Measure.subject differently. With the example value used, that would work on the MeasureReport, but would be too specific for the Measure definition as that is independent of that location. Rather it is the FHIR resource that represents the source of the information (at least how I understood it). That is not available in Measure.group where it wouuld be most applicable, while Measure.subject's use is questionable when the group includes different measures related to different FHIR resources. Sounds like we need to discuss this. I cannot make today's call, but would on Friday, or we need to grab some time tomorrow (12-1pm ET would work for me) with those interested to resolve.

Gino Canessa (Apr 08 2020 at 15:30):

Also, I believe the spreadsheet should remove the scoring values, based on the discussion of this thread

Gino Canessa (Apr 08 2020 at 15:38):

Should we use RelatedArtifact.citation for that?
edit: re: author of related artifacts.

Hans Buitendijk (Apr 08 2020 at 18:58):

@Gino: I removed Measure.scoring.

Eric Haas (Apr 09 2020 at 15:55):

@Hans Buitendijk what is the spreadsheet for?

Eric Haas (Apr 09 2020 at 16:34):

These decisions are giving me heartburn... I feel like we are playin fast and loose with measure after all the work that has gone into the QM IG. I think it exposed some gaps in the documentation either in the IG or the resources. The basic question is how making one big old measure a benefit?

Keith stated the benefit of the measure is to computationally create the MR. But, if there is not standard approach to authoring measures then that concept is shot to hell. You are still stuck coding to each measure.

Hans Buitendijk (Apr 09 2020 at 16:36):

@Eric Haas to have something readable for those who rather not read .json across multiple pages. I can see that once we have settled, somebody creates that spreadsheet, while at this point we can use both perspectives to auger gather input. @Keith Boone is actually using it if I understand correctly to generate from that, but he can confirm that.

Eric Haas (Apr 09 2020 at 16:41):

what form? The MeasureReport?

Hans Buitendijk (Apr 09 2020 at 17:52):

@Eric Haas : Not sure what the question is and to whom. What he spreadsheet represents? Measure. Or is the question for @Keith Boone what he is generating?

Keith Boone (Apr 10 2020 at 01:20):

Hans Buitendijk said:

Gino Canessa If Measure.author is meant to be the author of the FHIR expression of the measure, the definition should make that much more clear. We should JIRA that. We then need an extension on the Measure.relatedArtifact to capture the author there. ...

Hmm: Measure.relatedArtifact.resource can point to DocumentReference which covers just about any sort of metadata requirements you need.

---

Last updated: Apr 12 2022 at 19:14 UTC