2022-01-06 DEQM/Gaps In Care Meeting

Review ANSI Anti-Trust Policy

The 29^th HL7 FHIR Connectathon, Jan 10 – 12, 2022  (virtual event): https://www.hl7.org/events/fhir/connectathon/2022/01/

2022-01 Da Vinci DEQM and Gaps in Care part of 2022-01 Clinical Reasoning

• Presentation and recording of the Clinical Reasoning Track Kickoff on January 5th is available at 2022-01 Clinical Reasoning

FHIR-26091: Provider notification when data is missing

FHIR-34364: Support behaviors for dealing with malformed submissions

FHIR-33005: Add GET examples to cover entire $care-gaps api

FHIR-26091

This ticket is about alerting providers when data is missing, but the clinician does not know if there is a gap in care. However, the payor knows a test has been performed but there is not a result for the test.

• The Mitre team has developed details to support guidance response but without a specific profile.
• The nuance here is what is the difference between missing data versus there is no evidence of a test being done.

CDEX (Clinical Data Exchange)

• There is another use case in risk adjustment clinical data exchange (CDEX). Oftentimes risk adjustment can send back a diagnosis and the payer may still want to review a chart or apply it to a quality measure.
• The IG for CDEX allows for the return of a measure quality and risk could use CCDs.
• Eric Haas is presenting the CDEX implementation guide and its features next Thursday, the 13th, on the risk adjustment use case call, which immediately follows this meeting. The call is on the HL 7 calendar.
• However, there is not a ticket for this part of the work.
  A comment was added to a ticket regarding missing data.
• The resolution description should go to CQI
• The ticket won’t change unless there is a change in the guidance work.

The group agrees to hold on sending the ticket to CQI yet.

The ticket for this work will be put on the next agenda for review.

FHIR -34364

The ticket came from a discussion from a CMS reporting program and requirements for storage.

• • Called the “cat picture problem”
  • The issue relates to validation of data and if it is the correct data.
  • There are three possible solutions.
    • From the server client validation, a solution is pre-validation, where the client has a schema and library for validation, testing, or maybe an API endpoint. The client can validate if there is correctly structured data and should there be a “cat picture” in the schema or data that is being sent.
    • Another approach is a server side workflow, where the server accepts the data and there's additional work flow around determining if the data that was received is correct and should there be “cat picture” in it or not before it's committed to a database.
    • Additionally, versioning can be turned on in the file system.

Feedback included:

• • The client side is nice to have, but if you can’t guarantee that every client will have the review then the server side is the way to go.
  • Invalid content shouldn’t get to the API. The IG shouldn’t have to support a non-conforming call.
    There was discussion regarding if the IG should have information about non-conforming
  • It might be guidance that's more specific to receiving system.
    The example was provided related to providing structured medication information and a picture of the medication bottle as well. It is clinicially relevant.
    But what does it technically mean to attach a document?

Next Steps

• • Reach out to receiving systems and the agencies that make certification requirements on receiving systems to an understanding of requirements.
  • Add on a future call to discuss these requirements.

FHIR-33005

• Pre-applied examples are given in the ticket and it is ready to move to CQI for a vote.
• Changes and the build preview will be added to the comments when brought to CQI.

• A "soft close" is thought of as one of two situations:
  • The provider took care of the future order and is letting the payor know that the gap is closed, but it will reappear in the gaps in care report if a certain length of time occurs.
  • The gap is addressed as dismissed, where the provider says it’s not true for their patient. The gap is a soft close until it is reviewed by the payor and officially closed.
• Looking for an action to address the issue but there currently isn’t an action to push a soft close or to indicate a soft close.
  • Could be addressed with prescriptions. Currently, this is a client behavior that is not covered in current functionality.
  • It would be helpful to have documented reasons for the soft close to help understand the issues.
• The item will be continued in the next agenda.