From 1992 to 1995 I was a GI fellow. Nothing on the market made clinical sense for endoscopy reporting. The tools available were designed by people who had apparently never performed a procedure or written a note for one. I met a colleague in Australia, and together we built one of the first Windows-based endoscopy reporting systems in the country.

Microsoft Access. It worked.

It worked well until the United States moved deeper into ICD and CPT coding requirements and the rest of the world did not. The clinical problem had not changed. The billing environment had. Suddenly the software that made sense clinically no longer made sense commercially. A pivotal moment came when I had the opportunity to visit the IBM PC development lab and see some of the first touch-screen computer monitors and other unique, soon to become routine, storage solutions.

A few years later I spent three years consulting for a major endoscopy equipment manufacturer. They had an endoscopy report writer built by a major software company. It was not written cleanly from the ground up. It had been assembled by connecting nineteen separate databases. Nineteen. None of them communicated well with each other. The system could not be upgraded without breaking the connections among them. The software stagnated. I told them the only solution was unified architecture. They declined.

I walked away.

I have been walking away from that same conversation for thirty years.

The enterprise EHR platforms that now dominate hospital medicine are the nineteen databases at scale. More sophisticated, yes. More capable of storing data, absolutely. Fundamentally different in design philosophy? Not really. They were built to document and bill. They were hardened, over decades, to satisfy regulatory requirements, auditors, meaningful-use criteria, quality reporting mandates, billing rules, and institutional workflows. Each new layer added more fields, more clicks, more required attestations, more structured data entry, and more distance between the clinician and the thing the clinician was actually trying to say.

Epic was founded in 1979. Cerner was founded the same year. Meditech began a decade earlier. The category we call the electronic health record is rooted in software that is roughly half a century old. Those systems have been patched, acquired, merged with other vendors’ products, adapted to new regulations, and most recently fitted with artificial intelligence features on top of architectures that were not designed for them.

That matters. There is a difference between adding AI to an old records architecture and building a health care platform around AI from the first line of code.

Every major software transition has followed this pattern. The personal computer was not a faster mainframe. Salesforce was not desktop software placed on a server. The iPhone was not a better BlackBerry. Tesla was not a gasoline car with an electric variant. Stripe was not a traditional bank with an API. The new platform wins when it is built around the new paradigm, not when the old platform bolts that paradigm on as another feature.

Health care has not had that transition yet. What we have instead is a chart so dense with accumulated data that finding a single clinically relevant piece of information requires knowing where to look, clicking through multiple screens, and hoping the person who entered it used the right field. A physician seeing ten patients in a day may need to navigate dozens of pages of documentation just to identify what is new. Most of it is not new. Much of it is not clinically relevant. It is the sediment of a billing and compliance system that rewards documentation volume over clinical clarity.

And here is what that sediment actually costs. Not just dollars. Not just audit risk. Time.

A survey published this year found that 73 percent of clinicians cite time pressure as the primary obstacle to listening to their patients. Nearly nine in ten clinicians have identified a critical condition based solely on what they heard. The stethoscope, the physical exam, the conversation, the pause before a patient answers a question, these remain among the most essential diagnostic tools in medicine. We have built a system that systematically crowds them out.

So I decided to do something about it. Not another white paper. Not another conference talk. Code.

At first, the problem looked like documentation. That is where the pain is most visible. Notes are too long. Notes are too hard to write. Notes are too hard to read. Clinicians spend too much of their lives feeding the chart. But the more I built, the clearer it became that documentation was only the symptom. The real problem is that health care does not have an AI-native platform designed around the way care actually happens.

Care is not just a physician writing a note. It is a nurse noticing that a patient looks different than they did an hour ago. It is a speech therapist documenting that a patient cannot safely swallow. It is a dietitian changing the nutrition plan. It is a pharmacist seeing a medication conflict. It is a room that is not ready, a pump that is unavailable, an imaging result that has returned, a lab value that should have triggered a call, a supply that is missing, a payer rule that changes the plan, a discharge delayed because one signal did not reach the right person at the right time.

The EHR stores pieces of that story. It does not understand the story. That is the difference I wanted to build for.

The first principle was clinical reasoning. A system should be trained to support the way clinicians are trained to think: Gather the history, examine the patient, review the data, synthesize what it means, identify what is uncertain, develop a differential, and communicate the plan clearly to the people who need to act. Current AI documentation tools often match patterns in text. That is useful, but it is not the same as supporting the clinical reasoning process.

The second principle was the whole care team. Not just the physician. Not just the billing encounter. Nurses, advanced practice providers, medical assistants, therapists, dietitians, social workers, pharmacists, schedulers, billing teams, administrators, facilities staff, inventory teams, all of them touch the system. All of them generate signals. All of them need the right information in the right context.

The third principle was enterprise context. A clinical decision is not made in isolation from operations. If a physician orders a test, the system should know whether the scanner is available, whether the transport team can move the patient, whether the contrast is in stock, whether the patient has the right access, whether the result has returned, and whether the care team has seen it. If a CEO asks what it costs to perform a procedure, the answer should not be a billing abstraction. It should include staff, provider time, room use, utilities, equipment, disposables, drugs, implants, and reimbursement context.

The fourth principle was evidence. If AI is going to participate in clinical workflows, it cannot be a black box that produces confident-sounding recommendations without showing its work. Every recommendation needs evidence quality, conflicts of interest, and patient-specific applicability. The point is to move beyond “the model said so” toward traceable, clinically meaningful reasoning.

The fifth principle was accountability. Health care cannot run on clever demos. It needs audit trails, vulnerability and remediation logs, compliance records, interface schemas, data dictionaries, topology maps, and periodic internal failure-mode reviews. If a future consultant, investor, or hospital partner asks what was tested, what failed, what was fixed, and what remains open, the answer should not be a story. It should be a ledger.

That is what I am building.

It is an agentic, multi-modal health care AI platform built on a compound engineering architecture spanning clinical, operational, financial, facility, inventory, knowledge, and compliance workflows. It is not an EHR with AI added on top. It is not a scribe. It is not a dashboard. It is not a chatbot. It is an attempt to build the platform health care would have designed if the starting point had been clinical reasoning, team communication, operational awareness, and AI-native architecture, rather than billing, regulatory documentation, and fifty years of accumulated patchwork.

This is pre-production work. It still has gates to close, tests to pass, modules to harden, and evidence to generate before anyone should confuse it with a deployed clinical system. That distinction matters. In health care, claiming too much too early is not confidence. It is a safety risk.

But the direction matters too. The physician who is not hunting through a chart has time to sit down, make eye contact, and listen. The nurse whose observations are captured in context has more time for the bedside. The care team that sees new results when they matter can act sooner. The administrator who can understand cost, capacity, staffing, and resource constraints in one place can make better decisions. The hospital that can keep more routine AI inference and medical knowledge work inside its own controlled infrastructure can reduce unnecessary external exposure.

That is not documentation automation. That is a different architecture for health care.

I built the first version of an endoscopy reporting system because the available tools did not make clinical sense. Thirty years later, the problem is larger. So is the build.

Brian Hudes is a board-certified gastroenterologist with more than 30 years of clinical experience, serving as chief of gastroenterology and medical director of GI and endoscopy at Ascension Sacred Heart Hospital in Pensacola, Florida, a 550-bed Level I trauma center, and as assistant professor of medicine at Florida State University College of Medicine. A recipient of his specialty board’s 30-year certification award, he has spent his career at the intersection of complex clinical care and the structural forces that shape how medicine is practiced, financed, and delivered.

Dr. Hudes brings a rare dual perspective to health care commentary: that of a frontline proceduralist who has navigated decades of declining reimbursement, rising administrative burden, and accelerating system consolidation, and that of a health care technology entrepreneur who has spent years studying why the systems around medicine so often fail the people practicing it. His health care IT work began during his GI fellowship in 1995, when he co-developed one of the first Windows-based endoscopy reporting systems in the United States.

Having practiced through every era of modern health care technology, from paper charts and handwritten orders to early electronic health records and today’s enterprise systems, Dr. Hudes writes with a grounded perspective on administrative cost growth, physician workforce shortages, end-of-life ethics, and the widening gap between what clinicians need and what the industry builds. Professional updates are available on LinkedIn.