Your PI Proof File Should Be Taking Shape Now. Is It?
The 2026 Promoting Interoperability reporting window is no longer theoretical.
If your practice started the last 180-day PI performance period on July 5, your score is already being built. That means your evidence file should be taking shape too.
Not later. Not when the QPP portal opens. Not when someone on the team says, “Wait, where did we save that?”
Now.
Promoting Interoperability is not scored on good intentions. It is scored on required data, required attestations, certified technology, public health reporting evidence, security documentation, and proof that your practice can produce when it matters.
That is why every MIPS practice needs a PI proof file while the reporting period is active. The proof file is not a submission-season accessory. It is the scorekeeper.
The proof file is the scorekeeper.
It tells the story behind your Promoting Interoperability performance. It shows what your practice reported, what technology supported the reporting, what documentation confirms the work, and who reviewed each required item. It helps your team move from “we think we are ready” to “we can prove we are ready.”
That difference matters.
For 2026 MIPS Promoting Interoperability, practices must manage required measures, required attestations, CEHRT documentation, public health reporting, security documentation, and submission requirements. Missing key pieces can put the entire PI category at risk. That is a lot to leave sitting in inboxes, vendor portals, screenshots, and one person’s memory. Karen may be excellent. Karen should not be your compliance infrastructure.
What Is a PI Proof File?
A PI proof file is a central, organized collection of the documentation your practice uses to support its 2026 Promoting Interoperability reporting.
It is not just a folder; It is your practice’s evidence system. A strong proof file should show:
What reporting period your practice used
What CEHRT supported the reporting
What required measures were reported
What exclusions were claimed, if any
What attestations were completed
What public health reporting status applied
What security work was completed
What evidence supports each item
Who reviewed the evidence
When the evidence was saved
The goal is simple. If your practice submits PI data, you should be able to explain and support the submission without having to start a scavenger hunt.
Submission season should not feel like an escape room.
Why the PI Proof File Matters in 2026
Promoting Interoperability is no longer a “click the box and move on” category.
For 2026, CMS expects practices to collect PI data in certified electronic health record technology, or CEHRT, for a continuous 180-day period during the calendar year. Practices also need to address required measures and attestations. Some items carry serious consequences if they are missed.
For example, the Protect Patient Health Information objective now requires more than simply saying the practice completed a Security Risk Analysis. Practices must also attest to conducting security risk management activities. In plain English, that means you need to show that you looked at risk and acted on it.
That matters because the Security Risk Analysis is not just a MIPS issue. It also connects to HIPAA Security Rule expectations. When a practice documents the SRA properly, it protects both the PI score and the broader compliance record.
A PI proof file helps the team connect those dots.
It keeps the reporting story clean.
Start With the Reporting Period
Your proof file should begin with the reporting period.
This seems obvious, which is usually where problems like to put on a little hat and sneak in.
Save a simple document that includes:
The PI performance period start date
The PI performance period end date
The reporting path, such as traditional MIPS, MVP, APP, group, subgroup, individual, or APM Entity
The person responsible for PI oversight
The person responsible for submission
The date leadership reviewed the plan
If July 5, 2026 was your start date, your 180-day window runs through December 31, 2026. That date range should be clear in the file.
Do not rely on verbal agreement. Write it down. Save it.
Document CEHRT and CHPL Readiness
Next, your PI proof file should include CEHRT documentation.
CEHRT means certified electronic health record technology. Your practice needs to confirm that the right EHR functionality was in place for the reporting period and that the system meets certification requirements.
Your proof file should include:
Vendor name
EHR product name and version
CEHRT documentation or vendor confirmation
CMS EHR Certification ID from CHPL
Screenshots or reports showing system configuration, where useful
Notes from vendor communications
Date of verification
Name of the person who verified the information
CHPL stands for Certified Health IT Product List. It is where certified health IT products are listed, and it is used to generate the CMS EHR Certification ID.
This is not the place to guess.
If your practice cannot confirm the CHPL ID, pause and verify it. A working EHR is helpful. A verified EHR is better.
Create a Required Measures Section
Your proof file should have a section for each required PI objective and measure.
For 2026, the PI objectives include:
Electronic Prescribing
Health Information Exchange
Provider to Patient Exchange
Public Health and Clinical Data Exchange
Protect Patient Health Information
Depending on which HIE option your practice reports, CMS says practices may have 6 to 7 required measures, plus required attestations.
For each measure, save:
The measure name
The reporting period
Numerator and denominator report, if applicable
Report date
EHR source
Staff workflow owner
Any exclusion claimed
Documentation supporting the exclusion
Reviewer name
Notes on any gaps or corrections
This does not need to be fancy. It needs to be complete.
The point is to show that the measure was not just submitted. It was reviewed, supported, and tied to the correct reporting period.
Do Not Let Public Health Reporting Float Around
Public health reporting is one of the most common places where practices rely too heavily on assumptions.
The practice thinks the vendor is handling it. The vendor thinks the practice confirmed eligibility. The practice manager thinks the registry status is saved somewhere. Somewhere is not a filing system.
Your PI proof file should include a dedicated section for Public Health and Clinical Data Exchange.
For 2026, this includes required public health reporting components such as:
Immunization Registry Reporting
Electronic Case Reporting
Depending on the practice, other optional public health or registry measures may also be relevant.
For each applicable measure, save:
Registry or public health agency name
Active engagement status
Registration confirmation
Testing confirmation, if applicable
Production status, if applicable
Public health agency communications
Vendor communications
Screenshots or reports showing submission status
Exclusion documentation, if claimed
Dates tied to the reporting period
The key phrase here is active engagement.
If your practice reports public health measures, the proof file should show the level of active engagement. Do not wait until submission season to ask whether that evidence exists.
Build the Protect Patient Health Information Section
The Protect Patient Health Information objective deserves its own section.
This is where practices should store the evidence supporting:
Security Risk Analysis
Security Risk Management activities
SAFER Guide self-assessment
Related policies and procedures
Follow-up actions
Leadership review
The Security Risk Analysis, or SRA, should not be a generic document with the practice name pasted on page one. It should reflect your actual technology, workflows, ePHI systems, vendors, devices, access points, and vulnerabilities.
The second part matters just as much.
Security risk management means your practice acted on identified risks. That may include assigning owners, setting timelines, updating policies, changing access controls, enabling multifactor authentication, patching systems, training staff, or working with vendors to correct issues.
Your proof file should show both:
We assessed the risk.
We managed the risk.
That is the difference between a document and a defensible compliance record.
Save SAFER Guide Evidence
The SAFER Guide requirement is easy to underestimate.
For 2026 PI, practices must complete an annual self-assessment using the 2025 High Priority Practices SAFER Guide.
That self-assessment should not live in someone’s downloads folder under a name like “final-final-use-this-one-2.”
Save the completed self-assessment in the PI proof file. Also save:
Date completed
Team members involved
Notes from the review
Areas marked for follow-up
Action items
Responsible owners
Progress updates
The SAFER Guide connects EHR use, patient safety, and operational readiness. If your practice treats it as a checkbox, it may miss useful risks hiding in daily workflows.
And as we all know, workflows do love to hide things.
Keep Required Attestations Together
Attestations are not just yes-or-no answers. They are promises your practice should be able to support.
Your proof file should include evidence for each required attestation, including:
Security Risk Analysis and Security Risk Management
SAFER Guide self-assessment
ONC Direct Review attestation
Actions to Limit or Restrict Interoperability of CEHRT attestation
For each attestation, save:
The attestation language
The planned response
Evidence supporting the response
Reviewer name
Leadership approval, if applicable
Date reviewed
If someone asks why the practice answered “Yes,” the proof file should answer before anyone has to open their inbox.
Track Exclusions Carefully
Some PI measures allow exclusions when the practice meets specific criteria.
Exclusions can help, but they should never be treated casually.
If your practice claims an exclusion, document:
Which measure the exclusion applies to
The exclusion reason
The data or facts supporting the exclusion
The date reviewed
Who approved the exclusion
Any vendor or registry confirmation
Any applicable report showing volume or eligibility
A weak exclusion can create unnecessary risk. A well-documented exclusion helps the practice show that the decision was based on facts, not convenience.
Assign Owners and Review Dates
A proof file without ownership becomes a digital junk drawer.
Assign someone to each section:
Reporting period
CEHRT and CHPL
Required measures
Public health reporting
Security Risk Analysis
SAFER Guide
Attestations
Exclusions
Submission review
Then set review dates.
A good rhythm is monthly during the reporting period, with a more detailed review before submission season.
Your review should ask:
Are reports being saved?
Are measure values reasonable?
Are workflows still active?
Are exclusions still valid?
Are public health statuses current?
Are security action items moving?
Are attestations supported?
Are gaps documented?
This keeps the proof file alive. It also prevents the December tradition of discovering that everyone thought someone else was saving the evidence.
What Should Trigger a Second Opinion?
Your practice should consider a PI Second Opinion if any of the following are true:
Your proof file does not exist yet
Your CEHRT or CHPL information is unclear
Your PI reporting period is not documented
Your measure reports are incomplete or confusing
Your public health reporting status depends on vendor assumptions
Your Security Risk Analysis is outdated or generic
Your risk management follow-up is not documented
Your SAFER Guide self-assessment has not started
Your exclusions are not supported
Your attestations are planned, but the evidence is thin
Your team cannot explain where PI documentation is stored
These are not signs of failure. They are signs that the practice should review the evidence before it is needed.
The Bottom Line
Your PI proof file is the scorekeeper.
It helps your practice show that the technology, workflows, data, attestations, public health reporting, and security documentation all support the score you plan to submit.
Promoting Interoperability is not scored on good intentions. It is scored on required data, required attestations, CEHRT, active engagement, documentation, and proof.
The earlier you build the proof file, the more time you have to fix gaps.
The later you build it, the more likely your team is to mistake activity for evidence.
Do not wait for submission season to find out that your PI documentation is scattered, incomplete, or sitting in someone’s inbox.
Build the PI proof file now.
And if your team is not fully confident that your PI proof matches your PI plan, book a PI Second Opinion with Chirpy Bird before small gaps become submission-season problems.
