Moving clinical data between systems runs on established standards, and today’s models are capable enough to deploy. Yet projects still stall. More often than not, the hold-up is a permission nobody has granted or a step nobody wrote down.

Richard “RJ” Kedziora has seen these challenges play out firsthand. Since co-founding Estenda in 2003, he has worked across EMR integrations, grant-funded research, and AI projects for MedTech and Life Sciences organizations.

In a recent Designwave Podcast conversation, RJ shared where healthcare technology projects most often get stuck. Six recurring patterns emerged, and almost none of them are engineering problems.

Why People and Process Decide Whether Healthcare AI Works

• Start with who can approve access to the data

Healthcare has never been short of technology. RJ runs through what already sits inside a hospital.

"There's a lot of technology in healthcare. Think x-rays, MRIs, CT scanners, lots of technology … in terms of drug development. But data is really the last thing that the industry has embraced."

That gap has largely closed on the technical side. FHIR and HL7 are established standards for moving clinical data between systems, so the engineering in an EMR integration is well understood and repeatable. What remains is getting permission to run it.

RJ also added, "It's no longer a technical challenge to integrate with an EMR, or get data out of a system. It's not a technical challenge. It's very much a people and process challenge. How do we get the right permissions to be able to do the integrations? The technology is established."

A model needs data to be built and a live feed to stay useful, so approval is needed at the start and again at deployment. Teams that budget engineering time without budgeting approval time lose their schedule to someone else's review cycle.

Before integration work starts, a team needs to know these three things:

• Who has the authority to approve access to this dataset

• What agreement has to be signed before work can begin

• How long institutional review usually takes at this organization

Those answers set the schedule. Our data analytics work starts there, with the access path.

• Design for the people who will actually use it

Asked why people and process get overlooked, RJ points first to the technology mindset.

“Particularly for technology people, we love the challenge of figuring out how to solve that problem. There’s a lot of pride, and rightfully so, in how you implement solutions such that they are efficient and scalable. But you always have to consider that real-world scenario.”

An efficient system still has to work for the person using it. As RJ explains, developers can sometimes focus so heavily on the technical challenge that they lose sight of the end user and what they are going through.

His own parents are a simple example. Both turn 80 this year, but their relationship with technology could not be more different.

“My mother has embraced technology. She loves her smartphone. My father, on the other hand, hates technology.”

For patient-facing technology, that difference matters. Designing around assumptions such as age or digital confidence can quickly exclude the very people a solution is intended to help.

“So as you’re designing those solutions, you have to consider that people aspect of developing the solutions.”

Designing around real users shapes our custom software development work. It also determines who gets included or left behind, something we explored further in what it takes to build AI that includes underserved patients.

• Write the process down so the work is repeatable

RJ's definition of process is short. "In terms of process, that's how stuff gets done."

Without one, people spend time working out what the next step should be. "If you don't know what to expect, or the process, the steps that you need to take to develop that solution or to get permission to a certain data set to do integration, it's really hard to figure out what needs to be done."

He uses dataset permissions as the example, which connects back to the first problem. An approval is easier to secure when the organization already has a written path for requesting one.

At Estenda, we work to a certified process. "We are an ISO 13485 certified organization, which means we have a well-documented software development process that we follow. So as we hire new people and bring them in, here is our process for software development. It's very SOP-driven and template-driven, which helps us out on onboarding new people."

ISO 13485 is the quality management standard for medical devices. Documentation at that level does three things:

• New engineers learn the method from the documentation rather than from whoever has time

• Work stays consistent when a team grows partway through a build

• Auditors have something concrete to inspect

That discipline runs through our implementation and support work, and regulators are now trying to apply similar thinking to AI itself, which we covered in is AI in healthcare moving faster than we can regulate it.

• Agree on scope before the build starts

Software projects run over budget or get abandoned in every industry, and RJ has seen the high end of the published figures.

"You hear a lot of software projects fail, and if you look at the metrics, I've seen as high as 80 percent of software projects fail. It's true in many industries; it's true in health care as well."

He gives one main cause. "I think a lot of that comes down to scope management and discovery."

Doing discovery well means agreeing early on what the project will deliver, for what budget and over what timeframe. Without that agreement, a team can deliver exactly what it planned and still be seen as late, because each side expected something different.

"If you're not on the same page with the client, or if you're internal to an organization, there are certain expectations of how long your project is going to take. If you're not on the same page, it's not going to be very successful."

RJ also questions what that number actually counts. "There are projects that blatantly just don't work or go way over budget. But did you just poorly estimate it at the beginning, or was the scope just not clearly understood?"

Grant-funded research leaves no room for drift. Estenda's work includes government and foundation grants and military healthcare projects, where budget and timeframe are fixed in advance. "If you go over by a month, you're not getting paid for that, because the grant is very fixed price."

That constraint is what builds the discipline. Our strategy engagements front-load discovery for the same reason, and we map the route from a loose idea to a validated product in what it takes to get a healthcare product to production.

• Bring the funding conversation in early

In US healthcare, the people who use a product and the organization that pays for it are usually different parties. As RJ pointed out: "You could be developing an app for a patient, like the patient is going to actually use it, and you're going to share the information with the doctor. But neither of those two people is going to pay for the solution. The insurance company will pay for it."

A product can be designed around the patient, validated with the clinician, and still have no route to reimbursement, because the party funding it was never in the room. That question belongs in discovery.

"So how do you have the insurance company, a representative of the insurance company, as part of that conversation, to make sure that their interests actually come along in the process?"

RJ added: "Making sure everybody is on the same page, making sure you have the right people involved. So in health care, who is the end user? The doctor, the nurse, the patient involved, and the insurance company."

Three groups usually need to agree, each for different reasons:

• The clinician, who is being asked to change how they work

• The patient, who has to keep using the product after the first few weeks

• The payer, whose reimbursement decision determines whether it reaches scale

RJ notes this is harder in the US than in countries with a single national payer. "It makes it a little more difficult here, because we don't have a government-level population care-based system."

Working through that alignment is a standing part of our healthcare, medical, and software research engagements, and you can see how it plays out across our case studies.

• Keep a clinician reviewing what the AI produces

Healthcare may have been slow to embrace data, but large language models are gaining ground quickly. RJ points to ambient listening as one of the clearest examples.

"They are the first to embrace this new generation of large language models, particularly in the area of ambient listening. So as you go to your healthcare provider, instead of them typing on a keyboard and looking at a monitor because they have to record that information in the EMR, now they can just have that conversation with a patient."

Accuracy is often the concern with AI, but RJ argues that the comparison should be with the process it replaces, not with perfection.

"With the world of AI, there's a lot of criticism that it can hallucinate, that it's not perfect. Well, people, you and I, we are not perfect either. Everyone sort of glosses over that."

That does not mean accepting errors. Models need to improve, and their outputs still need human review.

"It is important that the AIs get better, that large language models get better and improve. But think about where they are today. They're very capable. You do have to review the outputs of what happens. But you have to compare and think about, what is the current state of that human doing that?"

Clinical documentation is a good example. Before ambient AI, a scribe might take notes in the room, or recordings could be transcribed later. Neither approach was error-free.

"Prior to the AIs and large language models doing the ambient listening, you might have a scribe in the room that's writing it down. Or just do a manual recording and have somebody somewhere else dictate those notes for you. Those people weren't perfect either. There are rates related to that as well."

Clinicians still had to review those notes.

"So even then, you had to review your notes, even though a human was doing it. Now the AI can do it much more efficiently."

The principle stays the same: use AI to make the process more efficient, but keep human review where it matters. Our AI/ML services help build that oversight into healthcare workflows. The same approach is also improving adjacent areas, including healthcare software testing quality.

Frequently Asked Questions

Why do healthcare AI projects stall when the technology works?

The blockers sit upstream of the code. Data permissions, unclear scope, missing stakeholders, and undocumented process hold up more projects than model performance does. RJ describes EMR integration as a people and process challenge, since the standards for moving data have been established for years.

What makes healthcare data hard to access?

Approvals cause the delay. FHIR and HL7 move records reliably, so the hold-up comes from securing agreements and institutional sign-off. Teams that treat access as an engineering task underestimate the timeline, because the slow part is a review they do not control.

Why do healthcare software projects run over budget or stall?

Scope management and discovery account for much of it. Figures as high as 80 percent get quoted, though RJ questions what that number counts. Many projects were estimated poorly at the start, or had scope the two sides never clearly agreed on.

Who should be involved in a digital health project?

The clinician whose workflow changes, the patient who uses the product, and the payer who funds it. US healthcare separates the user from the buyer, so a patient app can be built without the insurer ever being consulted. Bringing a payer in early protects the product after launch.

Does hallucination make AI unsafe for clinical use?

It makes review essential. Human scribes had their own error rates, and clinicians were already reviewing those notes before AI existed. Keeping that step in place, with a clinician verifying output, is what makes a deployment defensible and sets the right benchmark.

Why does documented process matter in healthcare software?

It makes delivery repeatable and auditable. A certified process under a standard like ISO 13485 gives new team members a path to follow and auditors something to inspect, and it keeps quality consistent as a team grows.

Ready to Move Your AI Initiative Past the Pilot Stage?

Getting healthcare AI into production takes a partner who handles the permissions, the stakeholder alignment, and the scope discipline alongside the engineering. Estenda brings more than two decades of digital health, MedTech, and Life Sciences experience to that work, under a certified development process, from discovery through deployment and support.

Book a free 30-minute consultation with a digital health architect to talk through where your initiative is stuck, with no obligation. Reach out at estenda.com/contact-us or email info@estenda.com. Explore our full range of services at estenda.com.