For healthcare organizations managing large NP and PA teams, chart review is one of those requirements that might sound simple until you try to operationalize it at scale. Depending on the state and care model, physicians may need to review a defined sample of an APP’s patient charts, document the review, and maintain a record that can stand up to an audit.

Elevate, Zivian’s clinical quality and chart review product, was built to manage that workflow: selecting the right charts, routing them to the right physician, documenting the review, and turning required oversight into useful performance data.

There was just one obvious problem. If getting those charts into Elevate still required someone to pull them out of an EHR by hand, we had automated the workflow without removing one of its most tedious steps.

A customer asked us about exactly that last year: “Can you just pull the charts from our EHR?”

The honest answer was no.

Chart review at Zivian worked the way it works most places. Someone opens the EHR, finds the encounter, exports it, uploads it to us. It worked. It was also a person doing a machine’s job, every month, forever.

So we knew we had to fix that as part of the development of Elevate.

The fix is the less interesting half. What surprised us was the shape of the problem, and if you’ve ever built software that touches clinical data, I think you’ll recognize it.

The Tail Is Very, Very Long

Here’s the number that reframed this project for our team.

In 2024, clinicians reporting to Medicare’s interoperability program named 175 different certified health IT developers. Roughly six in ten of those clinicians were on a single vendor. Nearly a third reported using something from outside the top twenty-five.

And that only counts certified health IT. Certification is voluntary. It spread because federal incentive programs paid for it, and those programs largely never reached behavioral health, long-term care, or home health. Whole categories of care run on systems that never had a reason to certify.

Our customers live across all of it. Some are on Athenahealth, some are on Healthie. Some are on a system three people built in 2019 that does exactly what that practice needs and nothing else. Same compliance obligation, same product expectation, completely different front doors.

The first instinct is to build the Athenahealth integration, then the Healthie one, then see who asks next. That works until it doesn’t. Every new customer becomes a project, and every vendor’s quirks leak into the application. The twelfth integration costs as much as the second, and at that point you’re running a services business and calling it software.

So Why Doesn’t FHIR Solve This?

Fair question, and the answer is more encouraging than I expected going in.

Federal rules do require certified EHRs to expose a standardized API, and they’re specific about it: a pinned version of FHIR (R4), a pinned authorization model (SMART on FHIR), and a defined set of data classes under USCDI (United States Core Data for Interoperability) which has expanded with every version since. Two certified vendors will both hand you a patient record you can parse. A decade ago that would have been remarkable.

It’s even better than I’d assumed on the piece we care most about. Elevate’s job depends on attribution, which advanced practice provider saw a patient, in which location, and which physician collaborates with them. Thankfully, the standard does define a place to record the clinician who participated in an encounter. However, two gaps sat exactly where we needed them.

Gap 1: The wrong search axis

The required searches are all organized around the patient: this patient’s encounters, by date, by type, by status. There is no search by clinician.

So you cannot ask a certified system for every encounter a given NP saw last month. You get there by walking patients.

That’s the wrong shape for what we do, because state rules define chart review as a number. Mississippi, for one, has the collaborating physician review a random sample of 10 percent of an APRN’s charts or 20 charts a month, whichever is less. Sampling is the product, and sampling starts from the clinician, not the patient.

Gap 2: The missing relationship model

The relationship we care about most isn’t in the model at all. Nothing in the standard expresses “this physician is the collaborating physician responsible for this NP.”

Rendering provider, billing provider, and supervising provider stay three different answers in three different places, which matters enormously when a state board asks you to prove who reviewed what.

Everything else compounds from there. Athenahealth effectively runs two API families: a deep proprietary one where the operational data lives, and a standards-based one scoped to interoperability. Healthie’s native API is GraphQL. Neither is doing anything wrong. They’re just different, and the standard doesn’t make them the same.

Then there’s HL7 v2, still moving enormous volumes of admission, result, and scheduling traffic, and still letting organizations define their own custom segments the way it has for more than thirty years. That flexibility is why it survived. It’s also why no two v2 feeds are quite alike.

And some systems give you a file every night and that’s it. Everyone’s data comes back in roughly the same shape now. It still doesn’t mean the same things.

Three Options

We looked at three paths, and I think they’re the three anyone in this position looks at.

Integrate point-to-point, per customer. Fastest to the first customer, worst at the twentieth.

Buy a middleware layer. There are companies whose entire business is normalizing this, and for a lot of teams that’s the right call. It didn’t fit us, mostly because of that tail — the aggregators are strongest where the market is concentrated and thinnest where our customers actually are. We’d have bought the easy part and still owned the hard part.

Or stop treating integration as a feature and treat it as a data problem. That’s where we landed.

What the Team Built

The pattern comes from data engineering, where it’s usually called medallion architecture: land data raw, conform it into canonical business entities, then shape it for how it’s actually going to be used. It isn’t new and we didn’t invent it. What we did was map it onto the specific mess in front of us.

There’s an adapter for each EHR variation. Variation, not vendor — two customers on the same platform can differ enough to matter, and pretending otherwise is how quirks end up scattered through your business logic. Each adapter speaks one system’s language and nothing else.

Underneath it, we keep exactly what we received. The FHIR bundle as returned. The v2 message as sent. The CSV as dropped. This matters for two reasons.

The first is practical. When a mapping is wrong we can fix it and replay history instead of asking a customer to re-export data.

The second is the one our customers care about more. When a state board audits a collaboration, the question isn’t whether your software believes the review happened. It’s whether you can show what the source system actually said, on the date it said it, without anyone having touched it since. An unedited record of exactly what the EHR sent is the difference between an assertion and evidence. In a field where proof of collaboration can decide whether a license survives an audit, that record earns its storage many times over.

Then everything gets normalized. A Healthie appointment, an Athenahealth encounter, and a row in someone’s nightly export all become the same thing: an encounter, attributed to a provider, in a period, under a collaboration.

Here’s where I get to brag.

That normalization layer is where every hard problem in this project lives, and the team worked through them one at a time without ever letting the mess reach the product. Nothing in Elevate knows or cares which system the data came from. 

What It Gets Us

Adding an EHR is now an adapter and a mapping. The product doesn’t change. If a vendor breaks something upstream, one adapter breaks. And the hard parts stay where they belong attribution and sampling are Zivian’s value add.

We don’t treat every EHR as a new product problem. We treat it as another instance of one we’d already solved.

And when a customer asks whether we can just pull the charts, the answer is usually yes now, and it’s boring. Boring is what we were going for.

Boring for us, anyway.

For our customers it means something better: nobody has to do a machine’s job anymore, and the people who were doing it get to go back to practicing medicine.

Learn More About Zivian’s EHR-Integrated Chart Review Compliance Solutions

Zivian Health automates EHR chart retrieval, review, and compliance workflows to help healthcare organizations scale NP and PA oversight. Schedule a demo today.