Stream: Covid-19 Response
Topic: SANER Measures Team Discussion
Gino Canessa (Apr 29 2020 at 21:55):
Per discussion on this morning's call, created a new thread here.
I've done a pass updating what I had based on the current posted CDC Patient Impact and the FEMA Daily Reporting templates.
Based on my understanding from this morning, I'm working on the "non-computable"/"generic" versions, so I've set all the expressions to be based on the guidance text. I've tried to match the structure to the posted versions, excluding fields that don't exist in the matching documentation.
- HAPI CDC Patient Impact, FEMA
- GitHub JSON CDC Patient Impact, FEMA
I've broken up my questions/comments into a few sections below.
Critical:
-
FEMA field mapping:
- Since field names aren't specified in source, the field names in the measure don't correlate to fields in the sheet (e.g., "totalOrders" for "Cumulative Diagnostic Tests Ordered / Received").
- In my version, I have stayed with my original model (camel casing the data element text, remove '/', replace "COVID-19" with C19 (per CDC)). E.g., "cumulativeDiagnosticTestsOrderedReceived"
- I think this avoids confusion and prevents future collisions
-
This issue also occurs in the group names
- "positiveIncreasePercent" and "positivePercent" are impenetrable
- Suggest: "percentPositiveAmongNewlyResultedTests" and "cumulativePercentPositiveAmongNewlyResultedTests"
-
I think these need to match across everything we define
- Thoughts / feedback?
Measure General:
- I added
http://hl7.org/fhir/4.0/StructureDefinition/Measureto Measure.profile for version-awareness - My old version had Measure.type = composite. I've kept for now, but can remove.
- My old version had Measure.subject (Location) to allow linking to location without extensions. I've kept for now, but feel like this needs discussion
- I added Citations to RelatedArtifacts
CDC:
- Measure.group2.extension...measure-type is structure, should this be outcome?
- definition is list of markdown. I the output looks better with each definition being a line or changing it into a markdown page formatted with a header, etc. I've chosen the former for now (no real preference)
Copy/Paste errors found in published versions:
- CDC Patient Impact
- numC19Pats expression - beginning is chopped
- numC19HOPats expression - beginning is chopped
- Measure.group1.code.text "Ventilators" should be "Ventilator"
- FEMA
- Measure.author[0].telecom[0].value has a trailing space
I'm going to work on getting the generator to work with these definitions to create MeasureReports next (the structure changes broke my simpler implementation).
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 00:49):
For FEMA Tests Ordered Received, where is this information coming from (which information system)? Also does this include outpatient, inpatient and employee health testing?
Gino Canessa (Apr 30 2020 at 18:09):
I've been mulling on something here and had some brief discussions - I wanted to bring it up here in case of easy consensus, or can add it to the list for tomorrow's call.
I think we need to have the core Measure structure be each field as a group within the measure (e.g., 1:1 mapping from a CDC/FEMA field to a Measure.group), with the value being the score.
- The general structure (most recent) is that Measure groups are categories (e.g., beds), and each field is a population within the group.
- In the FEMA Daily Measure, there are already some places where that doesn't work.
- Some of the fields are the scores of the groups, while others are populations (e.g., the percentage fields).
- In our first two reports, we already need to handle two 'styles' of generating/parsing fields.
- Looking at additional forms already published, we have things like multiple-choice questions.
- So far, the best structure I found is for the field to be a group, and each choice a population within it (counting the number of positives/negatives).
- This means that we have another method of generating/parsing.
- Someone also brought up that there will likely be collisions in future requests (e.g., asking for a % positive and a % negative), which will yield large quantities of repeated data.
- While each Measure is individually clearer, we lose consistency across instances.
In short, if we try to specifically model each form individually in it's "best" way, we open the possibility of another structure for processing. I feel that's in opposition to what we're trying to achieve.
Thoughts/questions/feedback?
(apologies in advance, but tags because I'm somewhat blocked: @Keith Boone , @Hans Buitendijk , @Josh Mandel , @Michael Donnelly )
Josh Mandel (May 01 2020 at 03:41):
I had the chance to talk through these points with Gino earlier today, and I think we should take this up on tomorrow's call. It's important to make sure that our Measures tie back directly to what's in the source reporting requirements, and I'm worried that the current drafts are getting a bit "clever".
Keith Boone (May 01 2020 at 06:01):
"Doesn't really work" doesn't really tell me what the problem is.
A "Score" is a computation based on counts. % positive is a score. It's a measureValue. It's based on two populations, a numerator and a denominator, with a common initial population. These are described in Measure.
"best" is evaluating from a perspective that isn't really expressed. What I'm reading is "best" is being evaluated as what is easiest to produce based on a certain context. I agree, what you suggest is certainly extremely easy to produce.
But it lacks conveyance of meaning and semantics. We do the hard work of that by describing Measure using our expertise, which is what makes it easy to map these fields subsequently into MeasureReport. The layout of Measure tells a system where to stick stuff in a MeasureReport, and we have a very simple way to express a collection of numbers as name value pairs that can be "dumped into" a measure report based on code... be it population.code or group.code.
Yes, there's a little more complexity in the expression of MeasureReport, but not so much b/c it's guided by Measure.
Let's address this as a hot topic tomorrow as you say, b/c if you are blocked, then I am too.
As for % positive and % negative, yes, that could conceivably happen, BUT, we hope to avoid that by getting people to create measures smartly, instead of throwing spreadsheets over the wall. We're starting to get the kind of attention needed to make that happen through process and policy.
Keith Boone (May 01 2020 at 06:10):
@Josh Mandel There's measure and there's what organizations ask for. If we're going to treat them as measures, that implies a certain approach, which has a set of semantics that we should use. If we're going to treat them as fill in the blank forms, that's a different approach. They aren't "incompatible" with each other, but they do have some implications with respect to structure that we should consider. I like the idea of having an A leads to B approach from Questionnaire --> MeasureReport but we only got to that point last week and haven't adopted it fully. I think we want to explore that further. Questionnaire has less implicit structure and can easily address the "use this one common structure" mechanism to simply address the need, and that can map through to MeasureReport.
There's some benefit there as well due to alignment with the NHSN IGs which we should also review.
Keith Boone (May 01 2020 at 06:13):
The http://build.fhir.org/ig/HL7/HAI and https://build.fhir.org/ig/HL7/NHSN-LTC/ are the two NHSN FHIR IG guides that I'm aware of. @Austin Kreisler @Rick Geimer are you aware of others?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (May 01 2020 at 11:28):
and how about the HL7 ELR guide (v 2.51, not FHIR) and potentially Lab Results Reporting Initiative (LRI), and EHR-S receipt of Lab results in the EHR? LRI would communicate COVID-19 results from origination in the LIS to the hospital EHR (as long as not shared database as those aren't interfaced). Then results can be used for HAI and eCR reporting from the EHR side of the fence, so to speak. These guides aren't 100% aligned to provide complete interoperability and flow of lab results, but rather more of a point to point messaging between systems.
Josh Mandel (May 01 2020 at 15:02):
Are folks following http://build.fhir.org/ig/HL7/HAI-LTCF/ as it relates to NHSN reporting?
Josh Mandel (May 01 2020 at 15:03):
It's also defining Questionnaires for NHSN, though not specifically on COVID modiules.
Austin Kreisler (May 01 2020 at 15:56):
Those are the two FHIR IG's developed for NHSN reporting and balloted through HL7.
Josh Mandel (May 01 2020 at 16:16):
Are they meant to be a "Framework" to apply to all NHSN modules, or are they scoped to a specific set of modules?
Austin Kreisler (May 01 2020 at 16:43):
The IG's provide frameworks for the two main types of NHSN reports, individual patient reports, and summary reports. There are also examples of individual NHSN reports for each framework.
Josh Mandel (May 01 2020 at 16:45):
Are the COVID modules examples of "summary reports"? Is there info we should be using from these IGs to inform our questionnaire design?
Austin Kreisler (May 01 2020 at 16:47):
They should be, but that IG development work has not happened at this point.
Gino Canessa (May 01 2020 at 21:31):
Question (not urgent) while processing the CDC Healthcare Worker Staffing Pathway - what are we doing with text fields? In the form, there is a text box for listing what kinds of workers a facility is short (not restricted to clinical responsibility).
Simple for Questionnaire/QuestionnaireResponse. But, I'm not sure for direction what would be done generically for Measure/MeasureReport (especially in the context of aggregation).
Josh Mandel (May 01 2020 at 21:36):
Yeah, on the aggregation, could imagine just counting "Yes" values, or accumulating lists of responses... it's not clear that this is a "measure-y" thing.
Last updated: Apr 12 2022 at 19:14 UTC
