Downcoded
August 25, 20264 min readFree

Ask Your Payer What It Knows About Your Patients

On January 1 every Medicare Advantage organization, state Medicaid program and marketplace issuer has to run an API that hands your practice its record of your patients. The free specification that says how you ask was republished on August 22, and it changed because implementers pointed out that the first version would have shipped entire histories for thousands of attributed members in one request.

One sentence in the specification describes the January 1 deadline better than the rule that created it:

"The API will enable a provider to ask a Payer 'What do you know about my Patients?'"

That line sits on a page called Provider Access API (v2), inside a free implementation guide that HL7 republished on August 22. Which is 132 days before every impacted payer has to be able to answer the question (chart below).

The deadline comes from CMS-0057-F, final in February 2024. By January 1, 2027 an MA organization or a state Medicaid or CHIP fee-for-service program has to stand up a Provider Access API; Medicaid and CHIP managed care plans pick it up in the rating period beginning on or after that date, and marketplace QHP issuers in the plan year.

CMS wrote the obligation and left the mechanics to somebody else. The rule recommends the implementation guides rather than requiring them, and the guide it points at for the clinical and prior authorization half of that API is the Da Vinci Payer Data Exchange guide, PDex.

The Version CMS Named Is Two Releases Old

The final rule recommends PDex STU 2.0.0, which was current when the rule published. The guide has shipped twice since: 2.1.0 in June 2025, and 2.2.0 three days ago.

Here is where it gets interesting. In April, CMS's own follow-on proposed rule (CMS-0062-P, published April 14, comments closed June 15) took a look at the same guide and wrote that the PDex enhancements for "payer to payer bulk data exchange, payer to provider exchange, and explanation of benefits are currently in draft form and have not appeared in ballot, but have been tested at multiple Connectathons."

That proposed rule would also flip the guides from recommended to required, naming an unexpired adopted version of PDex for both the Provider Access API and the Payer-to-Payer API.

Four months after CMS put that sentence in the Federal Register, the draft stopped being a draft.

Thousands of Members You Never Asked About

Version 1 of the Provider Access API worked off the payer's attribution list. You called $davinci-data-export and the payer returned what it had on the members attributed to your organization.

The work group's own change log is unusually blunt about how that plays out at scale:

"Without this refinement a unparameterized request by a provider to the davinci-data-export operation could result in all information for all attributed members to be returned to the provider. This is a dramatically bigger API request that could result in entire histories for thousands of members to be compiled and returned to the requesting provider."

Version 2 adds a match step in front of the export. You submit the members you are treating or about to treat, each with a treatment attestation.

The payer applies its own business rules and its own opt-out check, then hands back a group identifier, and you export against that group.

Three buckets come back:

  • Matched, the members the payer agrees you have a treatment relationship with.
  • NonMatched, the ones it could not resolve.
  • ConsentConstrained, the ones who opted out of Provider Access sharing.

The export operation itself did not change, so nothing already built against v1 breaks. Version 1 stays in the guide on purpose, for value-based and risk-bearing arrangements where the payer's attribution list is exactly the thing you want.

For the regulated exchange, the guide is explicit: payers SHALL support the v2 attestation workflow, and provider and EHR systems reaching an in-network payer's CMS-mandated API SHOULD use it.

Scoped to the people you are actually treating.

The Part Worth Stealing

Every payer policy this desk covers arrives as a finished document with no visible argument behind it. PDex 2.2.0 is the opposite, and the record is free to read.

  • The change history for this one release names 84 distinct JIRA tickets.
  • The peer review that drove it "generated over 50 tickets," per the guide's own summary.
  • Reconciliation was approved as a block vote at the HL7 Financial Management Work Group on May 18, recorded in the guide as 5-0-0.
  • Six changes are filed under a heading that says Breaking Changes, each with the ticket number that produced it, rather than buried in a diff.
  • Seventeen narrative pages moved from informative to trial-use, which turns their SHALL and SHOULD wording into conformance language.

The people are named too. Mark Scrimshire of OnyxHealth.io is the primary author, Robert Dieterle and Viet Nguyen are the project leads, Point of Care Partners coordinates, and the participant list runs through Epic, Cerner, Optum, Allscripts and Blue Cross Blue Shield of Alabama.

Payers and vendors argued this out in public and published the transcript.

Cost to read it: nothing. It is on hl7.org under a Creative Commons license, no login, with a zip download if you want it offline.

Final Thoughts

None of this guarantees your payers will be ready. The guide is trial-use, CMS has not yet finalized the rule that would make any version mandatory, and a specification landing 132 days before a compliance date is a specification landing late.

What it does give you is a question with a right answer. When your vendor or your clearinghouse tells you they are on top of the January Provider Access work, the follow-up is which version of PDex, and whether they are building the v1 attribution flow or the v2 attestation flow.

One of those answers means you pull payer records for the patients on this week's schedule. The other means you wait on a bulk file covering everyone the plan thinks belongs to you.

Thanks for reading.