If your ACO includes participating TINs running six, ten, or fifteen different EHR platforms, you already know the specific kind of headache eCQM reporting creates. It’s not that any single practice’s data is hard to pull. It’s that getting all of it into one clean, aggregated, all-payer, all-patient submission feels like trying to get a dozen different dialects to agree on the same sentence.
CMS requires Shared Savings Program ACOs to aggregate quality data across every participating TIN when reporting eCQMs, and CMS will not do that aggregation for you. The responsibility, and the risk if something goes wrong, sits entirely with your ACO.
This guide breaks down why multi-EHR aggregation gets complicated, what CMS actually requires, and what a realistic plan looks like for pulling this off without your quality team burning out in the process.
Why This Gets Complicated Fast
The core requirement is straightforward to state and genuinely difficult to execute: every participating TIN needs a certified EHR technology, or CEHRT, version of their system capable of exporting quality data in a standardized format. In practice, that means your ACO’s aggregation plan is only as strong as its least technically capable participant, and that participant is rarely the one your leadership team thinks of first when planning the year ahead.
Some EHR vendors charge fees to generate the files your ACO needs. Others produce files that are missing required elements or built on outdated specifications. A handful of practices may still be working from systems that were never designed with ACO-level aggregation in mind at all. None of this is a hypothetical concern. It’s the default starting condition for most multi-EHR ACOs, and it tends to get harder rather than easier as your ACO adds new participating TINs each year.
CMS has acknowledged this burden directly through its Complex Organization Adjustment, which recognizes the added difficulty Virtual Groups and APM Entities, including Shared Savings Program ACOs, face specifically because of this cross-TIN, cross-vendor complexity. That adjustment helps, but it doesn’t replace the operational work of actually getting your data aggregated correctly in the first place. We’ve walked through that planning process in more depth in our own roadmap for ACO eCQM reporting, if you want a deeper look at the steps involved.
The File Format That Does the Heavy Lifting
eCQM reporting relies on Quality Reporting Document Architecture (QRDA) files, but when it comes to MSSP ACO reporting, there is a strict rule of thumb: QRDA Category I files are always your starting point.
Individual practices generate QRDA I files, which capture granular, patient-level detail. For ACOs, this patient-level data is non-negotiable. Because ACOs aggregate data across multiple participating TINs, you have to perform complex patient matching and de-duplicate records for patients who visit multiple practices within your network.
You simply cannot do this with QRDA Category III files. QRDA III files are pre-aggregated at the provider or practice level, meaning the patient-level detail has already been stripped out. If you try to combine QRDA III files from different TINs, you will end up double-counting patients and skewing your quality data. Ultimately, all those QRDA I files will be aggregated into a final QRDA III file for CMS submission, but you must start with the patient-level data to get there accurately.
The eCQI Resource Center, sponsored jointly by CMS and the Office of the National Coordinator for Health IT, maintains detailed QRDA specification guidance that’s worth bookmarking if your team is building this process internally. The practical challenge is that not every EHR handles this well. Some vendors might try to hand you a pre-packaged QRDA III file, thinking they are saving you a step. Knowing early in the year whether every participating TIN’s system can reliably produce the raw, patient-level QRDA I files you actually need ensures your registry or capable EHR can properly de-dupe and match your patients, saving you considerable scrambling later.
CMS has also been investing in Bulk FHIR tooling as a longer-term alternative to the QRDA workflow, which could eventually simplify how data moves between disparate EHR systems. That work is still developing, so for the current performance year, most multi-EHR ACOs are still building their aggregation process around QRDA files rather than waiting on a future standard to solve the problem for them.

Patient Matching and Deduplication: The Real Bottleneck
Aggregating files is one problem. Making sure the same patient doesn’t get counted twice across two different EHRs, or missed entirely because their record looks slightly different in each system, is a bigger one. Without a shared patient identifier across systems, your ACO has to build its own approach to matching and deduplication.
CMS takes this seriously enough that it may request documentation of your ACO’s internal policies for patient matching and deduplication, since federal regulation requires quality data to be true, accurate, and complete. An aggregation process that quietly double-counts or drops patients isn’t just a data quality problem. It’s a compliance exposure.
The lack of a universal patient identifier across EHR systems means most ACOs end up building matching logic based on a combination of demographic fields, name, date of birth, and sometimes address, rather than a single clean key. That approach works, but it requires careful validation, since even small formatting inconsistencies across EHRs, like how a hyphenated last name gets entered, can cause the same patient to be treated as two different people in your aggregated dataset.
Not sure how solid your current patient matching approach actually is across your participating TINs? Contact us today and our team can review your process before submission season.
The “Lowest Common Denominator” Rule for Collection Types
Here’s a critical detail that trips up a lot of ACOs: CMS allows your ACO to select a different collection type for each required quality measure. You could report Measure A via eCQM and Measure B via MIPS CQM, and each would be scored according to its own specifications and benchmarks.
What you cannot do is retain eCQM status if you mix collection types within a single measure.
Technically, a Qualified Clinical Data Registry (QCDR) can ingest different data collection types from different participating TINs for the exact same measure. For example, TIN A might send perfect eCQM data, while TIN B can only manage manual MIPS CQM data.
But here is the catch: when the QCDR aggregates that mixed data and submits it to CMS, the entire measure is automatically dropped to the MIPS CQM (MCQM) collection type. CMS enforces a strict “lowest common denominator” approach per measure. In stark terms, one TIN’s inability to submit eCQM data can drag the entire ACO’s submission down for that measure.
Because eCQMs and MIPS CQMs are scored against different benchmarks, unexpectedly dropping to a MIPS CQM submission can lower your ACO’s final score.
This reality changes how you need to plan for multi-EHR ACOs:
- 100% Uniformity is required per measure: You don’t need every single TIN to be eCQM-ready across all measures, but you absolutely need 100% eCQM data across all TINs to successfully claim eCQM status for any single measure.
- Plan measure-by-measure: The smart planning question isn’t, “Can our whole ACO handle eCQM reporting?” It’s, “For which specific measures do we have absolute, 100% eCQM readiness across every TIN?”
If even one TIN is struggling to generate eCQM data for a specific measure, the practical answer is often to proactively choose MIPS CQM for that measure across the whole ACO. Acknowledging that limitation early is often what separates ACOs that hit a wall from ones that find a workable, highly-scoring path forward.

What a Realistic Aggregation Plan Actually Looks Like
A few steps tend to separate ACOs that get through reporting season smoothly from those that don’t:
- Inventory every participating TIN’s EHR vendor, CEHRT status, and file format capability, QRDA I, QRDA III, or neither, before the performance year gets underway
- Identify which TINs will need vendor support or fee negotiation to produce usable files
- Document your patient matching and deduplication methodology in writing, not just as an informal practice
- Decide collection type on a measure-by-measure basis rather than assuming one approach fits every measure across the whole ACO
- Build in time for a mid-year check on file quality, since a formatting problem discovered in December leaves no room to fix it
Trying to map out which of your participating TINs are actually ready for eCQM aggregation this year? Contact us and our team can help you build that inventory before it becomes a year-end scramble.
How Patient360 Helps Multi-EHR ACOs Aggregate With Confidence
As one of the original 16 CMS Qualified Registries, in continuous operation since 2009, Patient360 works directly with ACOs navigating exactly this kind of cross-EHR aggregation challenge. Our ACO Reporting and eCQM Registry Reporting services are built to take on the aggregation work itself, rather than leaving your quality team to manually reconcile files from a dozen different vendors.
Multi-EHR aggregation will probably never feel effortless, given how much variation exists across EHR vendors and practice sizes within a typical ACO. But it can feel manageable, provided your ACO goes in with a clear inventory of what each participating TIN can actually produce, a documented patient matching approach, and a collection type strategy chosen measure by measure rather than assumed at the ACO level.
The ACOs that struggle most tend to be the ones that treat aggregation as a submission-season problem rather than a year-round operational one. By the time the reporting deadline arrives, there’s very little room left to fix a mismatched file format or a patient-matching gap discovered too late. Building the inventory and the documentation earlier in the year turns a last-minute crisis into a routine check.
If your team is heading into reporting season without that groundwork in place, reach out to Patient360, and let us help you build it before the deadline pressure sets in.
