Last Tuesday I sat in the audience at The Shop at the CAC for a StartupNOLA panel on AI in healthcare. Aimee Quirk and Denise Basow from Ochsner Health, joined by Jared Quoyeser of Louisiana Impact Fund, walked us through what it looks like for a health system to build with AI in 2026. Ochsner has more than a hundred AI projects in some stage of development, citing 15 as major.
While the details around what these projects encompass was not divulged, one can assume patient data is probably in the mix.
A few days later, I was talking with a friend who’s a physician at Ochsner. She mentioned that she’d recently stopped using her ambient AI scribe and wasn’t comfortable with every word she and her patients exchanged being captured by an AI model. She quickly followed up with, “not that I’m doing anything wrong.” I brought up 1984 and we ended up talking for a while about the potential implications of every clinical encounter being recorded, indexed, and stored somewhere. It has been said that privacy is a prerequisite for freedom.
The disconnect between these two worlds, a tech forward administrator and a doctor with a simple concern, is hard not to ponder. It seems after decades of work, the shift from how we can make healthcare data liquid to where it actually ends up has reached a critical point remarkably quickly, and somewhat silently.
Getting there
For at least the last quarter century (a nice throwback – https://dynamichealthit.com/post/what-is-the-hitech-act/), the overarching goal in health IT has been making patient data universally available. It should follow the patient between systems, between providers, between care settings.
That argument largely won. HITECH, Meaningful Use, 21st Century Cures Act, HL7’s FHIR standard, USCDI, and TEFCA together built most of the technical and regulatory scaffolding for moving clinical data.
DHIT built much of our work around that scaffolding. ConnectEHR, Dynamic FHIR API, and TIE all helped to develop a world where patient data moves. So this next part is going to sound a little strange coming from us.
Now what?
The interoperability fight always implicitly assumed a particular consumer at the other end of the pipe: another clinician, treating the same patient, in a defined care relationship. That’s the use case that was sold, and for good reason. It’s important. It’s the one HIPAA’s treatment, payment, and operations exceptions were written around. It’s the one most patients picture when they’re told their record will “follow them.”
But is there a dark side to interoperability? Once data is liquid, the end user can be changed and data can be carried to anyone permitted to receive it. Or not.
Recently, KFF Health News reported that HHS has been approaching state health information exchanges seeking access to detailed, identifiable patient records. Several state HIEs declined, citing their existing data-use agreements. The federal proposal reportedly included a per-person payment to the HIEs in exchange for the data feed.
I’ll leave it up to you to hold whatever political view you want about that. The structural question is an interesting one. When a new requester shows up with a new purpose, the consent framework that existed at the point of data capture — “information will be shared with your care team and applicable public health authorities” — doesn’t always anticipate the new endpoint.
The interoperability question used to be can the data move? The harder question, now, is should it move to this requester, for this purpose, under this consent?
That’s a governance problem. And as an industry that helped build the infrastructure, it might be time to shift our focus to protecting it.
TEFCA
A parallel story has been playing out on the patient-direct-access side. TEFCA includes an exchange purpose called Individual Access Services (IAS) — the flagship consumer use case, where patients use a third-party app to pull their records from any provider connected to any QHIN.
The wrinkle is what happens once the records arrive at the app. The provider sending them is bound by HIPAA. The QHIN routing them is bound by TEFCA’s Common Agreement. The app that ultimately holds them is bound by neither. It sits outside the HIPAA perimeter and is governed only by its own privacy policy. That can mean almost anything: data resale, model training, downstream sharing with brokers, or just weak security and an eventual breach. Patients consenting to “share my records with this app” rarely understand that the legal regime changes the moment those records cross the app boundary.
In late April, the American Hospital Association formally asked the Sequoia Project to delay the implementation of the IAS Standard Operating Procedure version 3.0, citing gaps in identity verification, patient matching, and consent that the current procedure doesn’t adequately address. Hospitals worry that the same pipes they’ve built so much trust around could be the cleanest available pathway for getting clinical data out of their HIPAA perimeter and into an app that may do almost anything with it.
Meanwhile
While the data-access debate plays out, the speed at which data can be used is increasing exponentially. Anthropic recently published internal data on how much of its own AI development is now done by AI. As of May 2026, more than 80% of the code merged into Anthropic’s codebase is written by Claude, not a human engineer.
Anthropic says this trend points to recursive self-improvement: AI systems capable enough to design and train their own successors with diminishing human involvement. They note they are not there yet. But the curve they show is steep, and the second of their three scenarios, where AI labs see compounding efficiency gains while humans still set research direction, is the one they describe as most likely.
Healthcare’s data governance frameworks were written for a world where the consumer of patient data was a person or a clearly-bounded program. They were not written for a world where the consumer is a training set, the trainer is another model, and the rate of model capability improvement compounds quarterly.
This is the dark side of interoperability that we haven’t talked much about. Not because what we built is wrong, but because the question of who and what gets to utilize it has outpaced the rules we built.
Bolt-on, for governance too
Our positioning as a vendor has been bolt-on solutions, and the same instinct applies here. The answer to AI-era data governance is not to undo two decades of interoperability work.
What’s missing is a governance layer on top of the existing infrastructure. A short, unfinished list of what that layer would include:
- Purpose binding at the data layer. Remember when Provenance was introduced in USCDI? See here. A FHIR resource leaving a source system should carry not just provenance but allowed downstream use.
- Granular, refreshable consent. Consent collected once at intake, in a packet most patients didn’t read, is not consent for a data flow that didn’t exist when the form was signed.
- Auditability for model training. If clinical data trains a model that influences clinical decisions, there should be a record. Who, what, when, on whose data, under what permission.
- A defensible “no.” Health information exchanges turning down federal data requests are not obstructionists; they’re functioning as the consent intermediary the system was designed to have. That role needs to be reinforced, not eroded under pressure.
- Real vetting for IAS providers. TEFCA’s Individual Access Services SOP governs how patient-directed apps query the network. The current version doesn’t require ongoing security audits, doesn’t bind apps to a stated purpose, and doesn’t restrict what apps can do with data after retrieval. The AHA has asked Sequoia to delay implementation until those gaps are addressed.
None of this is anti-interoperability. It’s the next layer of work for an interoperability industry that finished the first layer.
Where DHIT could sit in this
We’re not going to set national policy on our own. But we’ve spent many years connecting EHRs, certifying APIs, and making compliance feasible for organizations that may not have the resources to rebuild. That puts us close to the data flows.
The product roadmap, our customer conversations, and the way we describe what “interoperability” is for should all start reflecting the fact that the hard part is behind us, and the harder one might just be beginning.
