Rethinking the Architecture of Healthcare IT

Interview with Aleksey Miroff and Monte Jennings

A conversation with Monte Jennings, founder of Sentia Health, and Aleksey Miroff, healthcare technology advisor and publisher of EHRAtlas.

Healthcare organizations keep adding applications, integrations, interfaces, and layers of technology—yet many of the underlying problems remain.

Is the problem the software itself, or the architecture underneath it?

In this conversation, Monte Jennings and Aleksey Miroff explore why healthcare IT has become so complex, where architecture fits into the equation, and why adding another application is not always the answer.

This conversation is part of an ongoing EHRAtlas interview series with healthcare technology leaders who are building new technologies, rethinking existing models, and working to solve some of healthcare's most difficult technology challenges.

Monte Jennings is the founder of Sentia Health and a hands-on CIO and Master Architect with 25+ years of experience in software architecture, technology leadership, and business transformation. He believes many healthcare technology problems are fundamentally architectural—and that adding more software and complexity is often the wrong answer.

Aleksey Miroff is a healthcare technology and commercial strategy advisor and founder of EHRAtlas.com, an independent resource for comparing EHRs and navigating the rapidly changing health technology market. He also publishes a LinkedIn newsletter covering fresh news, insights, and trends across EHRs, AI, RCM, interoperability, and healthcare technology. Subscribe to follow the latest developments and conversations shaping healthcare.

____________________________________________________________________________________

The EMR Architectural Problem

Aleksey: You’re building an EMR from scratch rather than improving an existing platform. What architectural assumptions in today’s major EHRs—Epic, Oracle Health, and others—do you believe are fundamentally wrong, and what would you replace them with?

Monte: I believe there are two fundamental problems with the way many legacy EMRs have evolved.

1. Solving the General Problem: Traditional EMRs have tried to solve healthcare by building increasingly specialized software around different specialties. Why write the same core piece of software 130+ times for 130+ different specialties? The underlying clinical data model should be universal. In my architectural analysis, the system should be able to represent different types of medicine without requiring an entirely different software architecture for every specialty.

2. Text-Based Notes: The second fundamental issue is the industry’s dependence on narrative documentation. Physicians frequently talk about 'pajama time'—sitting at home at night typing notes. When clinical information is stored primarily as narrative text, it becomes harder to search, analyze, and use operationally. If clinical information is captured as structured data from the beginning, orders and downstream workflows can be automated deterministically. Crucially, our approach is based on a data-driven architecture rather than relying on generative AI to reconstruct meaning after the fact.

Can One Clinical Data Model Replace Specialty Modules?

Aleksey: You’ve argued that medicine doesn’t necessarily need separate specialty-specific documentation systems and that a universal clinical nomenclature could simplify the EMR. How would that work in practice? And what would clinicians gain—or potentially lose—from taking that approach?

Monte: The key is eliminating documentation as text and reducing complexity by eliminating specialties for the documentation.  We anchor Sentia in the Unified Medical Language System (UMLS) provided by the U.S. National Library of Medicine. Rather than making the clinician manage terminology, our system converts spoken clinical observations into standardized clinical concepts in real time.

The practitioner simply speaks. The resulting encounter is simultaneously represented as audio, readable transcript, structured JSON, and structured data displayed in a hierarchical treeview, like your file system is represented. In our architectural model, a primary care physician evaluating a common illness and a surgeon documenting a complex procedure do not need fundamentally different databases. There are no specialty-specific workflows documented in the EMR,  you don‘t need them. Instead let the doctors do what they are good at doing: delivering care.  Make the technology deal with the reality of care, not structuring the care around the system.

What Does This Change for EMR Complexity and Economics?

Aleksey: If that architecture works as you describe, what disappears? How does this shift fundamentally change both daily clinical workflows and healthcare economics, especially compared to traditional European or legacy enterprise systems?

Monte: Potentially, a significant amount of complexity. You reduce the need for manually maintained specialty templates, repetitive documentation, manual coding workflows, and the endless clicks of legacy systems. For complex cases, one encounter can serve as a template for another, reproducing documentation and orders automatically.  That doesn’t include all the efficiencies gained by getting rid of the legacy EMR vendors and the legacy insurers in favor of talking to the system and getting paid for procedures in real time with no claims, no denials, no networks, and no medical coding.

According to my modeling, native structured data directly alters the underlying cost structure. Traditional enterprise platforms—including major legacy systems used globally—require heavy administrative labor, manual billing infrastructure, and ongoing translation middleware. By capturing structured clinical data upfront and linking it directly to operational processes. Like imaging, scheduling, pharmacy, et al, you eliminate major administrative cost drivers. Sentia's internal target simulations model a potential reduction of more than 25% in hospital operating overhead by removing these redundant administrative steps.

From EMR Architecture to Rural Hospital Economics

Aleksey: Your model for working with a rural hospital is particularly unconventional: implementing the system with little or no upfront software cost in exchange for future economics. Why do you believe this model can work, and could it become a viable alternative for financially challenged rural hospitals?

Monte: Smaller hospitals face acute cost pressure and lack negotiating leverage with commercial payers, yet must support the same heavy administrative machinery. Once Sentia is deployed, we envision coverage models where Sentia acts as a direct insurer, TPA, or Direct Universal Care facilitator charging a flat $10 per member per month administrative fee plus actuarial risk.

To illustrate this math simply: consider a single isolated procedure like an open appendectomy costing $5,000 with an incidence of 120 per 100,000 people. That equates to $6.00 of annual risk per person, or $0.50 per member per month. It is important to emphasize that this single-variable calculation is purely an illustrative building block from my analysis to demonstrate risk isolation; full health coverage requires comprehensive actuarial modeling across high-cost, correlated, and catastrophic risks. The goal is to calculate actual expected care costs directly rather than layering traditional insurance overhead on top.

Can the RCM Tax Actually Be Eliminated?

Aleksey: The appendectomy example illustrates the isolated mathematics, but healthcare risk is obviously more complicated than one procedure. How do you account for catastrophic and correlated risk, and who ultimately bears that risk?

Monte: Those are critical questions. The model must account for the full actuarial risk of the covered population. In my view, the opportunity is to eliminate unnecessary administrative layers between patient, provider, and payment. If clinical data, coverage, and payment systems are connected natively, many RCM, coding, and denial management processes become obsolete. We aren't automating existing RCM complexity with more software; we are redesigning the transaction so those steps are no longer necessary.

Beyond AI: Can Architecture Do What AI Cannot?

Aleksey: You’ve been very critical of the idea that AI can simply automate coding, claims, denials, and collections. What do you believe AI can realistically accomplish today, and where does it fall short?

Monte: Generative AI excels at interpreting information, but falls short executing deterministic financial or clinical processes because probabilistic models can output plausible answers without actually completing the task. Based on my analysis, if a human has to verify every AI output, the economics collapse. Rather than asking AI to infer what happened after the fact, we structure the underlying clinical transaction correctly from the start.

What Would Happen to RCM?

Aleksey: So are you saying RCM disappears entirely, or that the traditional definition of RCM becomes much smaller?

Monte: Our objective is to eliminate traditional RCM. Healthcare should work like a real-time transaction: when an encounter is completed, structured data triggers immediate settlement. That eliminates the financing and administrative machinery of claims processing. AI should not be expected to compensate for an architecture that creates unnecessary complexity in the first place.

Target Modeling Metrics: Understanding the Projections

Aleksey: You’ve referenced potential targets of a 65% reduction in patient costs and more than 25% reduction in hospital operating overhead. How should health system leaders interpret these metrics?

Monte: To be clear, these figures represent target modeling metrics based on Sentia's internal architectural simulations rather than empirical production measurements. The 65% reduction reflects target savings achieved by stripping out traditional insurance overhead and administrative friction in our model. The 25%+ hospital overhead reduction models the administrative labor eliminated through native data capture, automated processes and automated orders. Redesigning the transaction allows us to model a fundamental shift in healthcare economics compared to traditional, high-overhead legacy EMR and insurance platforms.

Is Healthcare Really Too Complex?

Aleksey: If you could change one fundamental assumption about healthcare IT—whether it’s EHR design, interoperability, AI, RCM, or how hospitals buy technology—what would you change?

Monte: I would challenge the assumption that healthcare administrative software must be uniquely complex because clinical work is complex. Legacy EHRs try to satisfy too many competing requirements simultaneously. In my technical assessment, if the underlying architecture were simple enough, healthcare organizations wouldn't need multi-year, multi-million dollar implementations to make it work.

Rethinking Interoperability

Aleksey: You’re also critical of standards like HL7, FHIR, and DICOM. Are you arguing that these standards are fundamentally unnecessary, or that they are being used to compensate for incompatible underlying architectures?

Monte: These “standards” like everything else in medicine are overly complicated and for no good reason. Precisely like the EMR, we need a universal nomenclature to define a base set of concepts suitable for documenting the entire encounter.  HL7 still uses text, just put into an amazingly complicated format.  FHIR is HL7 in an API format.  There are dozens of channels and thousands of properties.  With the appropriate nomenclature, we can exchange identifiers that modify each other.  For example, the abdominal pain concept can be modified with hypogastric region.  That means that with a patient identifier, and a created by and a created date, we can describe any disease, occurrence, measurement, treatment. Observation or anything else pertaining to a patient with a UMLSId, a ParentUMLSId and a value; just six properties, not thousands.

Rethinking Hospital Workflows

Aleksey: You’ve also compared hospital operations to an assembly line. What does that mean in practical terms?

Monte: Let’s look at an example.  Instead of assigning a nurse to fixed groups of rooms, where one nurse is overwhelmed while another waits, assign work to people via a centralized, prioritized task queue. The next available qualified clinician takes the next new task, and works it until it is complete. In our operational analysis, combined with reduced documentation friction, this workflow redesign significantly increases operational efficiency.  Nobody gets overwhelmed and misses assignments, nobody is standing around unless everyone is standing around.

What Is the Hardest Problem You Haven’t Solved?

Aleksey: You’ve described a fundamentally different architecture for EHRs, healthcare payments, and hospital workflows. What is the hardest healthcare workflow for Sentia today—the area where your architecture has not yet eliminated the complexity you’re describing?

Monte: The real target now is adoption.  We solved the simple medical record, imaging, telemedicine, scheduling, automated task queueing instead of workflow, instant financial reporting in the ERP style Practice/Hospital Management System, and automating the entire health insurance industry. The real problem is getting the powers that be to actually understand why the systems they use are causing the problems they have, and how there is a better way.  I’ve studiously avoided technical terms here but really the technical terms have to be understood to avoid the mistakes we’ve made to this point.  Until practice and hospital administrators can see how this works and why it is better, they, and we, will continue to have the same old problems

So What Would Healthcare Look Like?

Aleksey: If your thesis is correct, what does healthcare look like five or ten years from now?

Monte: Ideally, much simpler and much cheaper. The clinician speaks instead of typing. Information is structured as it is created. Orders and processes are triggered automatically. Transactions settle cleanly. Technology becomes less visible because it no longer forces clinicians to adapt their work to the software. Healthcare does not need another layer of technology—it needs a different foundation.

The Bigger Question

This conversation challenges core assumptions: moving from specialty modules to universal models, narrative text to native structured data, heavy RCM infrastructure to real-time settlement, and AI workaround layers to clean architectural design.

The question is no longer whether such an architecture can be built, it is built, but whether it can be proven at scale in complex real-world health systems.

As Monte puts it: "Healthcare does not have a medical problem; it has an architectural problem."