Stream: Da Vinci
Topic: DEQM Gaps in Care
KASI GADE (Mar 08 2022 at 01:23):
Hello @Yan Heras or @Linda Michaelsen, I work in a payor org and we're looking to expose care gaps data as per the IG. A few questions:
- It appears that the purpose of the DetectedIssue resource is to convey the status of the care gap. Why not embed that as an extension on the MeasureReport resource instead?
- The cardinality on Composition suggests that it can focus on a particular MeasureReport and have multiple DetectedIssue resources under "entry" element. Does it mean a specific measure for a member can have multiple care gaps? When would this happen?
- The cardinality on DetectedIssue suggests that a care gap can point to more than one MeasureReport. What would be the use case for this?
- What would be the source of the Measure library resources? Would it come from HL7 or would each org come up with their list of measures?
- Is the MeasureReport expected to be generated on the fly when requested by the client or a resource persisted on the FHIR server, one per patient per measure per year and just presented to the client when requested?
Linda (Mar 09 2022 at 17:52):
To answer #1 - Our thought behind Detested Issue was that a receiving system could use it to track the status on their system. Also there is new work being done where the Detected Issue resource will allow for the Guidance Resource to advise the user on what to do to close the gap (join DEQM to follow this work). You can tell by the group.measureScore element on the MeasureReport if the status is 1
Linda (Mar 09 2022 at 17:54):
#4 - Measure Resource and referenced Library would come from the entity creating the measure, such as CMS, NCQA, professional associations, etc
Linda (Mar 09 2022 at 17:57):
#5 - $care-gaps expects the operation to be run upon request and generate the Care Gap Composition. You could generate MeasureReports and retrieve them with something like $report described in the Risk Adjustment IG but once a year would not serve people well if they are trying to close gaps by generating he report, using $submiti-data to close the gaps and then run the Care Gaps report again
Linda (Mar 09 2022 at 18:02):
I am intentionally not speaking to #2 and #3 because I haven't had time to look at the IG - hoping @Sam Sayer or @Rob Reynolds can help there. I do know that a Care Gap Report (Composition) is for a single member and can have 1 to many MeasureReports and their evaluatedResources. Each MeasureReport references a single Measure and each Measure should have a DetectedIssue if that helps. I can't address the multiple DetectedIssue until I or hopefully Sam/Rob can look at and address
Kasi Gade (Mar 09 2022 at 19:11):
Linda said:
To answer #1 - Our thought behind Detested Issue was that a receiving system could use it to track the status on their system. Also there is new work being done where the Detected Issue resource will allow for the Guidance Resource to advise the user on what to do to close the gap (join DEQM to follow this work). You can tell by the group.measureScore element on the MeasureReport if the status is 1
Would the Measure resource not have the detail about how the measure is calculated and thereby how to close it (qualifying numerator criteria)? Would the guidance is subjective and vary with patient? Could there be more than 1 Guidance resources to close a given care gap?
Kasi Gade (Mar 09 2022 at 19:16):
Linda said:
#4 - Measure Resource and referenced Library would come from the entity creating the measure, such as CMS, NCQA, professional associations, etc
Do these entities already have Measure libraries that are ready for us to use? I'm curious there'll be a new instance of each measure published by these entities for every new measurement year since the measure specs tend to change on an annual basis. Also, if our org wants to track custom measures, I assume we can create our own library in our FHIR server. Do you see any issues with that?
Kasi Gade (Mar 09 2022 at 19:27):
Linda said:
#5 - $care-gaps expects the operation to be run upon request and generate the Care Gap Composition. You could generate MeasureReports and retrieve them with something like $report described in the Risk Adjustment IG but once a year would not serve people well if they are trying to close gaps by generating he report, using $submiti-data to close the gaps and then run the Care Gaps report again
Is the expectation that the receiving systems gets the same MeasureReport & DetectedIssue resources (including FHIR id) every time they run the $care-gaps for the same patient and measure and period?
Sam Sayer (Mar 09 2022 at 19:43):
For #3: Are you referring to the cardinality of evidence.detail?
Kasi Gade (Mar 09 2022 at 19:55):
Sam Sayer said:
For #3: Are you referring to the cardinality of evidence.detail?
Yes Sam
Matthew Gramigna (Mar 09 2022 at 22:27):
Kasi Gade said:
Hello Yan Heras or Linda Michaelsen, I work in a payor org and we're looking to expose care gaps data as per the IG. A few questions:
- It appears that the purpose of the DetectedIssue resource is to convey the status of the care gap. Why not embed that as an extension on the MeasureReport resource instead?
- The cardinality on Composition suggests that it can focus on a particular MeasureReport and have multiple DetectedIssue resources under "entry" element. Does it mean a specific measure for a member can have multiple care gaps? When would this happen?
- The cardinality on DetectedIssue suggests that a care gap can point to more than one MeasureReport. What would be the use case for this?
- What would be the source of the Measure library resources? Would it come from HL7 or would each org come up with their list of measures?
- Is the MeasureReport expected to be generated on the fly when requested by the client or a resource persisted on the FHIR server, one per patient per measure per year and just presented to the client when requested?
I can speak a bit towards 2., as it's something we've considered for our prototype of a $care-gaps implementation.
We think of one DetectedIssue resource as one "gap" that can be addressed via some action (e.g. ordering a colonoscopy for a patient). Some Measures could have a Numerator statement that is the and of 2 queries for data for example. So in order for the patient to be in the Numerator, they need these two specific pieces of data to both be present. In our implementation of $care-gaps, it would generate a DetectedIssue resource for each piece of that and clause, and treat each piece as its own gap. If you resolve one of them, one DetectedIssue would go away, but the other would remain.
Matthew Gramigna (Mar 09 2022 at 22:29):
It's also important to note for 5. that since $care-gaps takes in periodStart and periodEnd, we'd want the MeasureReport to adhere to that measurement period too, so it wouldn't seem feasible in that case to store pre-calculated MeasureReports on the system since the reporting period can be changed at request time
Kasi Gade (Mar 09 2022 at 23:36):
Matthew Gramigna said:
Kasi Gade said:
Hello Yan Heras or Linda Michaelsen, I work in a payor org and we're looking to expose care gaps data as per the IG. A few questions:
- It appears that the purpose of the DetectedIssue resource is to convey the status of the care gap. Why not embed that as an extension on the MeasureReport resource instead?
- The cardinality on Composition suggests that it can focus on a particular MeasureReport and have multiple DetectedIssue resources under "entry" element. Does it mean a specific measure for a member can have multiple care gaps? When would this happen?
- The cardinality on DetectedIssue suggests that a care gap can point to more than one MeasureReport. What would be the use case for this?
- What would be the source of the Measure library resources? Would it come from HL7 or would each org come up with their list of measures?
- Is the MeasureReport expected to be generated on the fly when requested by the client or a resource persisted on the FHIR server, one per patient per measure per year and just presented to the client when requested?
I can speak a bit towards 2., as it's something we've considered for our prototype of a $care-gaps implementation.
We think of one DetectedIssue resource as one "gap" that can be addressed via some action (e.g. ordering a colonoscopy for a patient). Some Measures could have a Numerator statement that is the and of 2 queries for data for example. So in order for the patient to be in the Numerator, they need these two specific pieces of data to both be present. In our implementation of $care-gaps, it would generate a DetectedIssue resource for each piece of that and clause, and treat each piece as its own gap. If you resolve one of them, one DetectedIssue would go away, but the other would remain.
In such cases, how would we convey the overall status of the patient's measure? Is that via the 0/1 in the group.measureScore? Do you have an example of a measure that requires two independent actions taken to satisfy the measure numerator?
Kasi Gade (Mar 09 2022 at 23:57):
Matthew Gramigna said:
It's also important to note for 5. that since $care-gaps takes in periodStart and periodEnd, we'd want the MeasureReport to adhere to that measurement period too, so it wouldn't seem feasible in that case to store pre-calculated MeasureReports on the system since the reporting period can be changed at request time
That's interesting. Based on this statement in the IG, it seems like the periodStart and periodEnd only serve to identify prospective (current year) vs retrospective (any prior year) measures. The MeasureReport and DetectedIssue resources returned for a retrospective measure would be the same regardless of what month and date is passed in the period dates as long as the year part is the prior year. So the FHIR server could have a single instance of each MeasureReport per patient per measure per year and keep updating its "group" element as new evidence is evaluated. However, a MeasureReport for a group of patients would need to be put together on the fly based on the data in each patient's persisted MeasureReport. Does my understanding align or oppose the intent of the IG? Given that our current evaluation of evidence to determine measure outcomes and care gaps happens in commercial third-party software that runs on scheduled batch cycles, we can't technically do on-the-fly calculations anyway. At least not until the FHIR server is fed with CQL for each measure.
Rob Reynolds (Mar 10 2022 at 00:15):
@Kasi Gade
Regarding 3.
It seems that way within just the context of DetectedIssue.
However, if you consider the context of how you got to the DetectedIssue, it's not the case that a DetectedIssue can refer to more than one MeasureReport.
Composition has a section element that is 1..*. The section states that each section corresponds to an individual MeasureReport.
Within that context, the section has an entry element that is 1..*. All of those entry elements (which are references to DetectedIssue) correspond to the same individual MeasureReport.
The DetectedIssue Profile specifies that it "indicates that the measure reported has n open or closed gap..." Which is the "measure reported"? The MeasureReport that is in context from the Composition section.
You can have 1..* evidence and the detail can be a MeasureReport or GuidanceResponse, but if it is a MeasureReport, it must be the measure reported, which is the MeasureReport that is in context from the Composition section.
Rob Reynolds (Mar 10 2022 at 00:21):
There could maybe be a Conformance Requirement added to make that more clear.
I don't think we'd want to restrict it to "one and only one" though. What if someone wanted to add n number of extensions that each had distinct meanings?
Kasi Gade (Mar 10 2022 at 00:51):
Rob Reynolds said:
There could maybe be a Conformance Requirement added to make that more clear.
I don't think we'd want to restrict it to "one and only one" though. What if someone wanted to add n number of extensions that each had distinct meanings?
If it's not restricted to 1, could a DetectedIssue in this profile have 0 references to MeasureReport and 1 or more GuidanceResponse? What would it mean? If it contains more than 1 MeasureReport, what would it mean?
Rob Reynolds (Mar 10 2022 at 14:45):
@Kasi Gade
If it's not restricted to 1, could a DetectedIssue in this profile have 0 references to MeasureReport and 1 or more GuidanceResponse?
Yes
What would it mean?
It would mean the evidence detail for the DetectedIssue is communicated in 0 MeasureReports and 1 or more GuidanceResponses.
If it contains more than 1 MeasureReport, what would it mean?
It may just be phrasing, but I don't think it can "contain more than 1 MeasureReport". It could have multiple evidence details associated with the same ("measure reported") MeasureReport. What that would mean is TBD. I don't have an example of what information one might communicate that way. I'm just saying I don't feel confident there is nothing anyone would ever want to communicate that way so let's not intentionally preclude it.
Sam Sayer (Mar 10 2022 at 15:46):
@Kasi Gade A GuidanceResponse is supposed to represent a way of closing a gap (e.g. for colon cancer screening, you'd have one ach for colonoscopy and fecal blood occult test) . There is not a lot of detail in the current IG, as this was put in for backwards compatibility and will be profiled in a future update
Kasi Gade (Mar 10 2022 at 17:16):
Sam Sayer said:
Kasi Gade A GuidanceResponse is supposed to represent a way of closing a gap (e.g. for colon cancer screening, you'd have one ach for colonoscopy and fecal blood occult test) . There is not a lot of detail in the current IG, as this was put in for backwards compatibility and will be profiled in a future update
In that example, would there be separate DetectedIssue resources for colonoscopy and blood test? Or a single DetectedIssue resource that refers to separate GuidanceResponse resources for colonoscopy and blood test?
Matthew Gramigna (Mar 10 2022 at 17:19):
Kasi Gade said:
Sam Sayer said:
Kasi Gade A GuidanceResponse is supposed to represent a way of closing a gap (e.g. for colon cancer screening, you'd have one ach for colonoscopy and fecal blood occult test) . There is not a lot of detail in the current IG, as this was put in for backwards compatibility and will be profiled in a future update
In that example, would there be separate DetectedIssue resources for colonoscopy and blood test? Or a single DetectedIssue resource that refers to separate GuidanceResponse resources for colonoscopy and blood test?
The latter, since there is one "gap" that can be closed in multiple different ways. There would be two guidance responses contained in that detected issue, one for colonoscopy and one for blood test
Rob Reynolds (Mar 10 2022 at 17:21):
@Matthew Gramigna
I also like the idea you presented earlier where you have multiple DetectedIssues, one for each component.
Matthew Gramigna (Mar 10 2022 at 17:23):
Rob Reynolds said:
Matthew Gramigna
I also like the idea you presented earlier where you have multiple DetectedIssues, one for each component.
It's all pretty early in theory still, I dug up this picture from a slide deck about it from a while ago haha image.png
Left side is one gap that can be closed in 3 different ways. Right side is 3 gaps where each can be closed in one way
Rob Reynolds (Mar 10 2022 at 17:24):
One think I would mention related to that though is that, in the interest of modeling intentionally (instead of by inference), the DetectedIssue can be of type "closed-gap". So
If you resolve one of them, one DetectedIssue would go away, but the other would remain.
becomes:
If you resolve one of them, one DetectedIssue becomes a "closed-gap", but the other would remain (an "open-gap").
Rob Reynolds (Mar 10 2022 at 17:25):
@Matthew Gramigna
Yeah, I really like that.
Kasi Gade (Mar 10 2022 at 20:57):
@Rob Reynolds
Would it make sense to put the DetectedIssue resources in the 'focus' in the Composition resource? A few reasons:
- The operation is $care-gaps, implying the intent to get care gaps and corresponding guidance to close any open gaps.
- There could be a DetectedIssue resource which may not point to any MeasureReport.
- There could be a DetectedIssue resource which may point to multiple MeasureReport resources. May be closing this one gap addresses the numerators of multiple measures.
Rob Reynolds (Mar 14 2022 at 16:47):
@Kasi Gade
Very interesting. I think I'm with you on #1 and #2. Need to think about #3.
Kasi Gade (Mar 15 2022 at 17:30):
Rob Reynolds said:
Kasi Gade
Very interesting. I think I'm with you on #1 and #2. Need to think about #3.
Also, could we allow more valid values for the status in DetectedIssue, like when the gap is no longer valid when the patient is excluded from the member or loses coverage or some other reason.
Kasi Gade (Mar 16 2022 at 20:35):
@Rob Reynolds
Is there an example of the GuidanceResponse usage in the context of the Care Gaps IG? I didn't find it in the sample posted on the IG website.
Paul Denning (Mar 18 2022 at 14:59):
Go to https://projecttacoma.github.io/fqm-execution-demo/
On the left select from connectathon repository menu, pick EXM130-7.3.000 then
on the right select from the menu "tests-denom-EXM130-bundle.json"
Output type gaps in care,
check box calculate HTML (if you want to see CQL with highlighting)
click calculate
note tabs across the top for raw json, highlighted html and accordion
under raw json tab you can download the json
Accordion tab shows the 5 GuidanceResponses in a more readable form
Last updated: Apr 12 2022 at 19:14 UTC
