Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Why Does Healthcare AI Stall at the EHR? Interoperability, Remote Sessions and Tapped-Out Teams
What revenue cycle leaders say about getting documentation out of client systems, and how to scope a pilot that answers the question
In brief
-
AI coding needs two inputs, the documentation and the patient metadata, and getting them out of the EHR is the critical failure point.
-
Many providers give outside teams access only through a remote session to a single application, so there is no API to call.
-
Asking each client to build an HL7 interface slows every engagement, so teams want to retrieve documents the way a person would.
-
RPA teams are stretched, and writing new scripts is slower than the business needs.
-
Reading data from an image of a remote screen needs testing and accuracy metrics before anyone relies on it.
-
Good buyers run pilots with fixed scope, agreed success factors and a clear go or no-go decision.
AI can now code a chart. Getting the chart to the AI is the hard part. In my work with a healthcare services company that codes and bills for hospitals and physician groups, the conversation kept returning to the same obstacle: the EHR belongs to the client, the access path is narrow, and the automation team is already busy. This article sets out what the company's AI engineer and one of its technology executives told me, and what it means for anyone planning AI in revenue cycle work.
Interoperability is the failure point
“Healthcare especially, the critical failure point almost always is interoperability. Right now we have a client, we have our coding platform, and pretty much we just need two things. We need the patient documentation, and then we need that patient metadata, like their date of birth, that sort of stuff.”
AI engineer, healthcare services company
Federal law defines interoperability as health IT that enables the secure exchange of electronic health information with, and use of it from, other health IT without special effort on the part of the user (21st Century Cures Act, 2016). In practice, many provider relationships still fall short of that, and the coding vendor is left to bridge the gap with people.
One application, one remote session
The engineer described how the work is done today for many clients.
“What happens today with a lot of our clients is that we have a human who's going into, in a lot of cases, a Citrix session. They're logging into EHRs and they're looking up the documentation and then doing the medical coding. And so there's always this issue of: okay, we have a platform, now we have AI coding, it's fantastic, but we need to get the PDFs out of the platform, or out of the EHRs.”
AI engineer, healthcare services company
The technology executive explained why there is no easier route.
“They get a URL that takes them to a Citrix environment where they log into that, and then the EHR is only available through that Citrix session. But you're still interacting with the screen on a Windows machine.”
“Think of it as an internal system that they own and manage and run that we need to get access to. But one of the challenges is, in lieu of having them be able to create an API for us to download information, we would want an AI, some sort of AI automation, to be able to log in with the credentials, go in, pull the data out, be able to look up the data, but not have it […] pull in anything that's sensitive, but we need that information out of that system.”
Technology executive, healthcare services company
The automation must use the same access a person has, retrieve what the task needs, and keep everything else out.
Why asking the client is the slow path
The standard alternative is to ask each client for an interface, usually built on HL7 standards, to send documents automatically. The engineer described why that slows things down: every engagement starts with a request to the client's IT team. The pitch he wants to make is the opposite.
“If we can go to them and the sell is: hey, you don't have to do anything. We have this secure solution that's going to allow us to get the documentation out. That's our biggest hurdle, because once we have that, then the AI can do the medical coding on our platform.”
AI engineer, healthcare services company
The automation team is already stretched
“The problem with just regular RPA on that stuff is, we have a staff that's pretty tapped out already. And developing new RPA code, it's slower than we want it to be. And if we can do it faster, cheaper, more secure, these are some of the no-brainer use cases that we would want to implement.”
Technology executive, healthcare services company
This is the economics of most automation programs in healthcare. Demand for new workflows grows faster than the team that builds them. An approach that lets the person who knows the task describe it, watch an agent perform it and then approve the result takes pressure off the scarce scripting team.
What needs proof before anyone relies on it
When an application is delivered through a remote session, an agent sees an image of the screen rather than the page's underlying text. Reading data from that image is doable, but it needs testing and accuracy metrics on the client's real screens before anyone relies on it. A pilot should be designed to answer exactly that question.
What a security leader calls RPA 2.0
A security leader at the same company gave the problem a useful name in a later conversation. He described RPA 2.0: automation built on AI agents that can adapt when a process or a screen changes, instead of breaking the way a scripted bot does, while keeping the controls and data protection that healthcare requires. His advice on getting there was practical. Start small with one focused use case, make today's automation more resilient first, mask sensitive data before any AI is exposed to it, and scale only after the first use case shows value.
That sequence fits the staffing reality above. A tapped-out RPA team does not need a bigger backlog of brittle scripts. It needs automation that tolerates change, built on a foundation where the AI never holds the patient identifiers it is working with.
How a disciplined buyer scopes a pilot
The technology executive described his company's method for any proof of concept, and it is a good template for any buyer.
“We like to solidify scope between the two of us, so we don't continually increase scope on you guys. It's not fair. So we would want to clearly identify the scope of what the proof of concept or pilot would be, and then we try to identify success factors. What are we trying to accomplish? Does it meet our criteria for what we consider jointly as success? Because if we document all of that stuff up front and we document timelines and who's responsible on our end, I just don't want things to just sit out there floundering.”
“At the end of the proof of concept, we can make a very easy, distinct decision either way, whether we go forward or not go forward.”
Technology executive, healthcare services company
He added that the business case comes before the request for money, and that the security officer is brought in early. Both are good practice. A pilot that cannot show its value against agreed success factors, or that the security team has not seen, rarely survives the budget conversation.
Where RedactSure fits
RedactSure works inside the browser session a coder or account manager already uses, with no per-application integration and no change to user permissions. Patient identifiers become tokens before the AI reads the screen, a named person approves consequential actions, and every step is logged. RedactSure is in pilot with organizations in regulated industries.
Frequently asked questions
Why is interoperability the main barrier to AI medical coding?
Because the AI needs the documentation and patient metadata from a client's EHR, and many clients provide access only through a remote session rather than an interface. Without a feed, a person has to retrieve the documents manually.
Can an AI agent retrieve documents through Citrix?
It can operate a remote session the way a person does, but it sees an image of the screen, so data extraction needs to be tested for accuracy on real client screens before anyone relies on it.
What makes a good healthcare AI pilot?
Fixed scope, success factors agreed in advance, named owners and timelines, early involvement of the security officer, and a business case ready before the request for funding, so the outcome is a clear go or no-go.