In this episode, Dr. Dan Mingle answers viewer questions about addressing the challenges of the APM Performance Pathway (APP), navigating MIPS as a radiation oncologist, getting data from ACO member practices for the APP, and more.

Click play below to listen to this episode now, or scroll down for the written summary:

Question One: APP Quality Reporting Challenges

Susan asks: “How does Mingle Health recommend addressing the challenges of the APM Performance Pathway (APP) and ensuring compliance?”

I think there are two principal driving forces determining whether you meet the quality reporting challenges of the APP and qualify to collect your shared savings.

Participant practices:

I think that effective participation in your ACO’s APP efforts should be addressed contractually. Performance, recoverable documentation, and data delivery should be either rewarded for success, or punished when substandard, or both.

Data aggregation:

You must be able to collect and aggregate data from all of your participants. That includes appropriate patient identification and deduplication across practices.

The critical decisions here include:

• How will you accomplish this?
• What vendor will help you do it?
• And is your process replicable and scalable as your ACO evolves?

Expect to add practices and providers, lose practices and providers, and see turnover in the choice of critical technology, including EHR and PMS.

If you are a frequent participant in this series, you will know that I recommend MIPS CQMs or, now, Medicare CQMs from a Qualified Registry rather than eCQMs. eCQM processes are just too rigid and fragile to accommodate all participants in most ACOs and most are susceptible to failure with even small changes in your technical environment.

Question Two: Registry Reporting Rejection Rate

George asks: “What is Mingle Health’s rejection rate for submissions to CMS?”

I can’t recall ever having a rejected submission to CMS.

Perhaps, if we look carefully enough, we’ll find evidence of an early rejection that has been subsequently repaired and successfully resubmitted.

The nature of the Registry Reporting process includes:

• We submit through an API with a nearly instantaneous indication of technical success.
• Failed submission can be repaired and resubmitted.
• We’ve done this long enough and often enough; technical failures are more likely to come from faulty code or process on Medicare’s side than from our side. We have an annual lively exchange with Medicare to help harden their upkeep.
• If we are not satisfied with a submission, we can resubmit, overwriting the earlier submission, any time up to the close of the submission window.

There’s another perspective on this at which we excel:

When practices come to us for help submitting, we have a better than 99% track record of building a successful submission with them.

Question Three: Navigating MIPS as a Radiation Oncologist

Sally asks: “I’m in solo private practice as a radiation oncologist, and I’m confused when I look at MIPS. Should I be using MIPS CQMs or eCQMs? Should I be using MIPS Value Pathways (MVPs)? Some of the measures I have used in the past are no longer available in traditional MIPS, but only in MVPs.”

Four measures have been retired from the general MIPS menu of measures and are available only in MVP measure sets, they are:

• Preventive Care and Screening: Influenza Immunization
• Breast Cancer Screening
• Colorectal Cancer Screening
• Preventive Care and Screening: Body Mass Index (BMI) Screening and Follow-Up Plan

These are not perfect measures for radiation oncologists. In my experience, these actions are not typically within the care expectations of radiation oncologists.

They are good measures because they are usually recorded in a structured fashion and many radiation oncologists have access to data that they can report and benefit from what we call the “halo effect”, which describes the common dynamic that providers can be favorably scored on care provided and documented by colleagues.

There is not yet a Radiation Oncology MVP, so you won’t find any help there yet.

I expect you can still find six measures you can report enjoying the same “halo” dynamics of the four measures that have been excluded from your use.

But your best bet is possibly the Radiation Oncology Measure Set.

There are four measures in the set. So, submitting those four measures gives you a complete score with no penalty for two missing measures. The four measures are:

• #102 – Prostate Cancer: Avoidance of Overuse of Bone Scan for Staging Low Risk Prostate Cancer Patients
• #143 – Oncology: Medical and Radiation – Pain Intensity Quantified
• #144 – Oncology: Medical and Radiation – Plan of Care for Pain
• #226 – Preventative Care and Screening: Tobacco Use: Screening and Cessation Intervention

If you do the measure group, you must submit all four measures. If you miss one of the four measures, you are likely to find your low score reflects three missing measures, not one.

If you have no patients eligible for the measure, submission of zero performance on a zero patients denominator will effectively prevent lower scoring for any missing measures.

• For example, if you don’t treat prostate cancer, you’d report a zero numerator and denominator for measure 102 and get scored on what acts like a complete three-measure set.

Question Four: Promoting Interoperability HIE Measure

James asks: “I am in a discussion with a vendor that provides integration services for health care providers. If the client they are serving has an EHR that does not directly support data exchange with their local Health Information Exchange (HIE) how would they help their client meet the requirements of the MIPS Promoting interoperability (PI) HIE measure?”

First, a quick review.

Promoting Interoperability is one of four performance categories in the Merit-based Incentive Payment System (MIPS).

The other three performance categories are Quality, Cost, and Practice Improvement Activities.

All providers who are subject to MIPS are subject to all four performance categories unless they qualify for a specific exception for any one or multiple of the categories.

Starting in the 2025 performance year, all Advanced Payment Model (“APM”) participants will also be subject to the Promoting Interoperability performance category. They will be subject to Promoting Interoperability in all cases including if they are participating in a MIPS APM or are Qualified Participants (“QP”) or partially Qualified Participants (“partial QP”) in an advanced APM.

The requirements for PI list four objectives, but you should consider it to be five:

• Electronic Prescribing
• Health Information Exchange
• Provider to Patient Exchange
• Public Health and Clinical Data Exchange

Though not listed as an objective, there are several other requirements that can be lumped under the heading “Infrastructure.”

“Infrastructure” includes several required actions and attestations concerning the EHR technical environment and its security.

The question that was asked is about the second objective: Health Information Exchange (“HIE”). More specifically, the question is about the second of three options providers have for satisfying the HIE objective.

To satisfy the HIE objective in PI, a provider must achieve one of these three options or document valid exclusions. If the HIE objective is not satisfied, the practice or provider will not be credited with any score in the PI Category.

The options are:

Support Electronic Referral Loops

This has two elements. You must achieve both or qualify for one or the other exclusion:

• Electronically Send Health Information in support of a patient referral or transfer AND
• Electronically Receive and Reconcile Health Information when accepting a patient referral or transfer

Bi-directional Exchange with a Health Information Exchange organization (“HIE”)

The ultimate vision behind this measure is that every EHR comes with functionality that can be enabled using an administrative tool, inputting the network address of your HIE and designating what information you want to push or send and what information you want pull or receive. It should be no harder than enabling your email address and your email server in your email client.

Enabling Exchange under TEFCA

Trusted Exchange Framework and Common Agreement (TEFCA) is a specific national infrastructure for bidirectional HIE.

If your EHR does not come with that functionality, or if it does but is not adequate for your needs, you have other options that fall generally under three categories: Buy it, build it, or engage it.

To explain:

• Buy it:
  • Buy a product off-the-shelf to do it. An interface engine is the likely option. You install it, configure it, run it. It will operate between the EHR and the HIE technical environments.
• Build it:
  • A skilled software engineer or database engineer should be able to accomplish this using any of several coding or database tools. It will operate between the practice EHR and the HIE technical environments.
• Engage a vendor:
  • The vendor will buy it or build it. They will either set it up in the practice environment to connect the practice directly to the HIE, or they will be an intermediary with a 3-way connection between Practice-Vendor-HIE

To get credit, it has to be operational for at least 180 days in the performance year.

The final hurdle is certification. If it is installed and running, it is not going to count unless it is certified. Somebody has to certify it. It can be the practice/health system, the HIE, or the third-party vendor.

Certification needn’t be a barrier to getting this operational. If your HIE connection works, certification should be achievable.

Certification is going to show that you understand the requirements of the data exchange and that your tool works. It doesn’t matter if you’ve built it or bought it, you’ll need to show that you can make it work with a sample data set.

Neither certification, nor the cost of certification is trivial. But the cost should not be astronomical and the effort will be more tedious than difficult.

Your resource for all certification questions is: www.healthit.gov

• Choose the “Certification of Health IT” topic
• You will find:
  • A list of the vendors that are approved to certify your process
  • Specification and guidance documents
  • The legislation and rules underpinning all of it

To get certified you will:

• Engage and pay a certification vendor
• The vendor will review with you the requirements and your product functionality
• When you agree that you are ready, they will connect remotely and watch you run a test data set through your system
• When you get it right you will be certified
  • You will be listed on the Healthit.gov website
  • You will enter a maintenance of certification program that involves an annual fee and less stringent periodic attestation requirements.
  • You will typically not be subject to a direct observation again unless or until you significantly alter your system, or the certification requirements significantly change

Any of the involved parties can be the certified party: the EHR, the practice/health system, the HIE, or the third-party vendor.

In this case, it makes sense to me, for a vendor that is setting up HIE connections for multiple health care practices and EHRs, that you provide the functionality and obtain the certification to benefit all the providers, practices, EHRs, and HIEs you serve.

Question Five: Getting Data from ACO Member Practices

Bernice asks: “How does Mingle Health “go get” the data from ACO member practices?”

It’s become an interesting exercise in problem-solving. Most of us here at Mingle perversely enjoy that challenge. There is always a way. There is always a best way, though the best might not necessarily be an easy way.

It generally involves a discussion of each practice’s resources and barriers. It might be self-guided using our self-help tools. Our staff might guide the discussion, or you may have a local technology-oriented infrastructure that can pitch in.

It’s always useful to look first for technical interoperability tools. Certification regulations are steadily pushing these to broader availability and better operability.

But many remain unusable. Barriers include:

• Content that is missing key data for patient identification, eligibility determination, or performance determination
• Documentation workflows that do not populate structured data fields
• Excessive cost to purchase the module from the vendor

Most EHRs and Practice Management systems have innate reporting capabilities. Often, they are not suitable for similar reasons to interoperability tools.

Sometimes, they can and do produce big raw flat files of data that include the required data for the measures. These may have a lot more than we need, but that’s fine. It’s easy to disregard data, but impossible to infer data.

All EHRs and PMs are built on a database, and every database can be technically queried for the data we need.

Think again about those big raw datasets. It requires read access to the database, which is sometimes legally denied by contract, physically blocked by whoever is hosting your application, or you may not have access to someone with the technical expertise to go get it.

That technical expertise to go get it:

• Might be available from the vendor
• Or it could be available from the host
• Or from the revenue cycle/billing company
• Or you could find the expertise available for hire

If all else fails, chart abstraction is available to anyone with adequate knowledge medical concepts and the willingness to open and read charts and record the data in a spreadsheet format to provide to the registry vendor.