A short one. Something went live on aimedagent.net this week, and I would rather you try it than read about it.

Smart Formulary

Before a smart pump can program itself from an order, four systems have to agree on the drug: the order screen the doctor uses (CPOE, computerized provider order entry), the pharmacy, the label on the bag, and the pump’s own drug library. When they disagree, the pump drops to basic mode, with no dose limits. I spent a good part of my career watching that happen. Smart Formulary finds the disagreements before the pump does. Its two tools, One Formulary and Library Match, run in your browser, upload nothing, and are free and open source.

Smart Orders

This is the new one. Pick a synthetic patient. The chart sets up a published pharmacokinetic model, which is the math of how a body moves a drug: how fast it arrives, where it spreads and how fast it clears. The model does the arithmetic. AI MedAgent reads the chart and the FDA label, explains the result, and says what it could not check. Out comes a draft IV order with a goal, a flow pattern and a time not to give more.

Try Mrs. R, 79, heart failure, a slow circulation. The usual way is a weight-based dose given fast, then a second dose at 45 seconds because nothing seems to be happening. In the simulation both doses arrive together, and the predicted level peaks at more than three and a half times the target. The drug was never failing. It was stuck in traffic [3, 4]. The model-informed order gives a smaller dose more slowly, reaches the target, and says in writing: do not repeat for 210 seconds.

Fair warning on that example. The slow-circulation adjustment is an illustrative extension of published findings, not a validated model.

Credit where it is due

Dr. N. Ty Smith, a mentor of mine, spent decades showing that the circulation changes the drug and the drug changes the circulation. In 1972, with Anton Zwart and Jan Beneken, he coupled the two on an analog computer [1]. That work grew into BODY, a PC simulation with more than 200 variables in which a teacher could build a patient and watch the same drug land differently in a different body [2].

BODY could teach the lesson. It could not reach a real patient, because there was no electronic chart to read and nothing that could reason over it. Now there is both. AI is what finally carries Ty’s lesson from the classroom to the bedside, and I am not going to be shy about saying so.

What it is not

A demonstration on synthetic patients. One drug, propofol, on the Schnider model, built from 24 adult volunteers aged 25 to 81 [5]. Every order is drafted, never placed; a clinician accepts or rejects it. Software that calculates a patient-specific dose is a medical device function under FDA’s clinical decision support guidance [6], and none of it is for clinical use.

Come and check it out

aimedagent.net, box 03, Smart Formulary and Smart Orders.

Next up: taking AI MedAgent from the ICU into the home. More later this month.

References

[1] Smith NT, Zwart A, Beneken JEW. Anesthesiology 1972;37(1):47-58. Also Zwart A, Smith NT, Beneken JEW. Multiple model approach to uptake and distribution of halothane: the use of an analog computer. Comput Biomed Res 1972;5(3):228-238.

[2] Smith NT. PC-based “BODY” simulation presents anesthesia learning chance, challenge. APSF Newsletter 1999;14(2). https://www.apsf.org/article/pc-based-body-simulation-presents-anesthesia-learning-chance-challenge/

[3] Krejcie TC, Avram MJ. What determines anesthetic induction dose? It’s the front-end kinetics, doctor! Anesth Analg 1999;89:541-544.

[4] Upton RN, et al. Cardiac output is a determinant of the initial concentrations of propofol after short-infusion administration. Anesth Analg 1999;89:545-552.

[5] Schnider TW, Minto CF, Gambus PL, et al. The influence of method of administration and covariates on the pharmacokinetics of propofol in adult volunteers. Anesthesiology 1998;88:1170-1182.

[6] US Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff. Revised January 2026.

Daniel Pettus spent his career in medical device and health IT leadership at Alaris, CareFusion and BD and contributed to IHE Patient Care Device interoperability standards. AI MedAgent is a research demonstration of a patent-pending method. Synthetic data only. Not for clinical use.

Inside the Loop, Issue 25 | Daniel C. Pettus | 12 October 2026

Ami, Take One

I took Ai MedAgent home: a first pass at a consumer version on an iPhone, written with help using AI in a week with tools already on my Mac. It ran. Apple’s Health app humbled it. The part that matters was never built. Take two is coming, and so is a bigger step in critical care.

Readers of the last few issues know Ai MedAgent as a critical care idea: a reasoning layer that watches a running infusion (an IV drug being pumped into a patient) against the order, the labs and the patient’s own trend, and speaks to the nurse only when something changes. This issue is about what happened when I tried to take that idea home, to the kitchen table, where most medicine actually gets taken.

Short version: I built a first pass, it ran on a phone, and it taught me more in a week than the concept paper did in a month. It is not finished and it is not dead. It is on the bench. One housekeeping note before we start: every number, every medicine and every device you see in this article belongs to a simulated patient.

First, the part I keep underselling

A few readers have told me, kindly, that they never picked up from earlier issues that AI is the backbone of all of this. That is my fault, and I am done being shy about it. AI is the only reason Ai MedAgent exists at all. The concept is mine and so is the judgment, but the thing that reads a running infusion, the labs, the order and the public library at the same time and reasons over them in real time is a large language model, the kind of AI behind the chat assistants most people have now tried, and nothing I built in a career of building devices could do that. The code that turns the method into working software was written by an AI, with me describing what it had to do and arguing with it until it did. The public data in the next few sections is read by an AI. The question Ami writes for your doctor is the kind of sentence only a reasoning model can write from your own records. Take the AI out and what is left is a slide deck and a retired engineer. I built things for a career and none of them could reason. This can. That is the whole story, and I should have said it in the first issue.

Why bother, and where the idea came from

The obvious reason first. An ICU patient has a nurse, a pharmacist and a monitor watching every drop. The rest of us have a pill organizer and good intentions. The chemistry is the same; the oversight is not. If reasoning over data helps at the bedside, it ought to help at the breakfast table.

The less obvious reason is in the photograph below. In the late 1990s, at iMetrikus, we built AirWatch, a hand-held lung monitor for people with asthma. You blew into it, it showed your reading and the percentage of your own best, and it kept a seven-day grid in green, yellow and red. It sent the readings down a phone line, and your doctor got a report by fax and internet [1]. And when you hit a hundred percent, a small character on the screen put on a crown. All the hard work was hidden behind that face. That is the design inspiration for Ami, thirty years on: one face, one honest verdict, and the machinery out of sight.

AirWatch also taught me the second half of the idea. Around 2001, at the same company, I used the Unified Medical Language System for the first time. The UMLS is the National Library of Medicine’s metathesaurus, a dictionary of dictionaries begun in 1986, a single key that ties together more than a hundred medical vocabularies so that a drug, a lab or a diagnosis means the same thing no matter which system wrote it down [2]. It was, and is, free. It was also enormous. We loaded it off a stack of CDs. Making it useful to a consumer and a clinician at the same time took a room full of programmers, a complicated database integration that broke every time a vocabulary was reissued, and a large and redundant server farm that hummed in a locked room and cost more than the people. That was my first use of public data to add to what a patient and a doctor knew, and it was a brute-force achievement.

The drawing above is mine, dated June 2002, version three, for the hosting center at AboveNet in San Diego where all of this ran. It is worth a minute, because it is what a connected health application cost to deploy then, and the concept was exactly the one in this article: acquire data from providers and from consumers, normalize it with the UMLS, reason over it, and hand the knowledge back to the person and the clinician over the internet. Read it left to right. Two banks of modems, 192 of them on eight telephone trunk lines, because the devices in people’s homes phoned in. Two redundant firewalls and two load balancers at the front door. Two application servers, each with two processors and four gigabytes of memory, which was a lot. A Citrix gateway so clinicians could reach the system from their offices, and separate FTP and email servers behind their own firewalls. Then the two database engines on the right: one for transactions, one for analytics, each with its own disk array, both carrying the UMLS. Four protected zones, a monitoring system we called Big Brother, and a locked cage in somebody else’s building. By my count, sixteen servers and two disk arrays, before the people who kept them alive.

Nearly every piece of that room has since been replaced. The second drawing shows the same deployment today. The modem racks are gone because the Health app already holds what the devices used to phone in. The application servers are the phone in your pocket. The two database engines are the Health app on one side and the National Library of Medicine’s own servers on the other, which now serve RxNorm and the UMLS to anyone who asks. The firewalls, the Citrix gateway, the FTP and email servers and Big Brother are all Apple’s problem, which is what the App Store is. The programmers are mostly replaced by AI coding, with one person describing the work. The analytics engine is a few cloud functions, small programs that run on rented computers only when called and cost nothing when idle. The brittle integration is a weekly download of RxNorm, the Library’s dictionary of drug names, and a question put to the same public services, read by a reasoning model, an AI that can work through a problem rather than just look up an answer, and that does not care which vocabulary a word came from [3]. The problem that took a building in 2001 fits in a weekend in 2026. That is not a small change. It is the whole reason a retired engineer can try this at all.

Meet Ami

Ami is the home version. One face, one sentence, every morning. Most days the face is quiet and the sentence says nothing changed, which is the point: a smoke detector that chirps every day gets its battery pulled. On the day something does change, the face changes, the sentence says what, and a button offers the one question worth asking your doctor, already written, with the source underneath it. You read it, copy it into your patient portal, the website or app your doctor’s office gives you for messages and results, and send it. Ami never sends anything itself.

Underneath, it reads what the phone already holds. Since 2018 an iPhone has been able to carry your hospital’s records inside the Health app, in FHIR (pronounced “fire”), the standard format hospitals now use to pass a patient’s records between systems, and UC San Diego Health was among the first twelve systems to connect [4]. A ring or a watch writes sleep and heart rate into the same place. Ami reads from there, on the phone, and keeps nothing on a server, because it has no server. There is not a line of network code in it.

And a ruler, because I have spent enough years near FDA to respect the fence. Ami never says a medicine caused anything, never suggests a dose or a time, and never uses a diagnostic threshold. It reads, compares, and asks.

The other lens

The data from your doctors and your devices is wonderful. It is also only half the picture, and the half most people never see is free, because your tax dollars already paid for it. Sitting on public servers right now, maintained by the National Library of Medicine, FDA, CDC and CMS, is a very rich set of health information that looks at your medicines and your conditions from a different lens: not what your chart says about you, but what the world knows about the things in your chart.

For scale. PubMed, the Library’s index of medical research, holds more than forty million citations [5]. ClinicalTrials.gov, the public registry of medical studies, lists close to half a million of them [6]. MedlinePlus, the Library’s plain-language service, covers more than a thousand conditions and fifteen hundred medicines, and in one recent year 418 million people used it [7]. DailyMed carries the current FDA prescribing information for the drugs on the US market, the same label your pharmacist reads [8]. RxNorm is refreshed every week [3]. FDA publishes its recalls and its drug shortages as open data feeds, CMS publishes what Medicare drug plans cover and what pharmacies actually pay for each drug, and CDC publishes the adult vaccine schedule [9]. None of it is behind a paywall. None of it knows your name.

The problem was never that this library did not exist. The problem, for an ICU patient and for a person at the kitchen table alike, has been the three steps in front of it: how to get at it, how to normalize it so a drug on your list matches a drug in the library, and how to reason over what comes back. In 2001 that took the room I just described. It now costs pennies. A real-time question from a reasoning model into these data marts (large public collections of data built to be searched), organizing what returns and reasoning over the findings against one person’s list, runs for a few cents on the larger models and a fraction of a cent on the smaller ones, at the published rates [10]. That is the secret sauce, whether the person is on a ventilator or at the kitchen table. It is also the thread through my patent filings: the five provisional applications behind Ai MedAgent all rest on the same invention, a reasoning model working over these public data marts joined to a person’s own data, in an ICU bed or at a kitchen table. The critical care model looks more complex, and in many ways it is, but the data exists and it is already flowing. The home market is less controlled, not less rich. The theory is to put the same reasoning power in both rooms.

A small fee and a name problem

I had never built an iPhone app. The entry fee is a modest annual registration as an Apple Developer, plus an identity check that rejected my passport and then my driver’s license before I worked out why: my Apple account said Dan and my documents say Daniel. Apple is strict about who you are. Change the name, pass the check, pay the fee. One afternoon.

The tools were the easy part. Xcode, Apple’s own programming environment, is a free download that runs natively on the Mac, and the language, Swift, is Apple’s too. The app is seven files, written the way I described in Issue 24: I said what the thing had to do, the machine wrote the code, and I argued with it until it did the right thing [11]. The first build failed with seven errors because a library that used to come along for free no longer does. One line fixed it. The first run on the phone produced a popup that said Unable to Verify App, which cleared after I deleted the app, restarted the phone and ran it again from the cable. Welcome to iOS development, everyone said.

Why Apple, and not Android? Two reasons, one small and one that matters. The small one: my office is an Apple shop, a Mac Studio, a few Mac Pros and the laptops, so the tools were already on the desk. The one that matters is privacy and security for a first launch. An iPhone app ships as compiled, signed machine code, which is hard to take apart, while most Android apps ship as an intermediate form that free tools can turn back into readable source in minutes [12]. The Health app’s data sits in Apple’s most protected storage class and is end-to-end encrypted when it syncs [13]. None of that makes Android impossible; a private and secure Android version can be built and will be. It means that for take one, Apple’s stricter architecture gives me the simplest honest sentence about privacy, and the simplest sentence is the one a consumer will believe.

Then it ran, on a real phone, reading a ring, a watch and a clinic’s records through the Health app, with no server anywhere. The tools were built in and easy. Getting it right for a consumer, as you are about to see, is not.

The first morning

The first thing the test run reported was a nineteen-hour night. Nobody sleeps nineteen hours. A Health app on an ordinary phone holds sleep from a ring, a watch and the phone itself, and in a household that shares one Apple account to keep purchases simple, from a second person’s watch as well. Ami had added them all up. That is a real lesson about home data and it took three fixes: read one source per night and merge the overlaps; let the person switch off a device that is not theirs; and show, under a gear icon, exactly what Ami can see and where each piece came from. I had designed Ami on the assumption that a phone holds one person’s data. Many phones do not.

The second thing it reported was every prescription the connected clinic had ever written, going back years. Accurate, and useless, until it was sorted into what the person takes now and what they took once, with a switch on each row in case Ami guessed wrong. The hospital version of Ai MedAgent never has this problem; a pharmacist reconciled the list before the first dose. At home, the list is the problem.

Then I opened Apple’s own Health app to check my work, and that is where the story turns.

Apple already built the floor

Since iOS 16 in 2022 the Health app has had a Medications feature. You point the camera at the bottle, it reads the label, you set the schedule, it reminds you on your watch, logs each dose, and flags interactions, including with alcohol [14]. Alongside that sit the hospital records I mentioned, every lab and every prescription, nicely laid out. Put the first pass of Ami next to it and Ami is a subset with a friendlier face. A consumer would open the two side by side and reasonably ask why they needed the second one. I asked myself the same question and did not like my answer. Add the market: the App Store carried 2,172,472 apps last year [15].

That is the honest result of take one. Not that the idea is wrong, but that the floor is higher than it was, Apple owns it, and anything worth building has to start above it. The other lens is above it. The first pass never got there.

A consumer is not an ICU patient

My issue with Ami was never whether I could finish the development. It is that the consumer is not the same person as the patient in the ICU, in what they perceive as valuable and in what they will tolerate on a phone screen. The nurse wants everything; the consumer wants nothing, until the one morning she wants exactly one thing.

I may also have made an early developer’s mistake. I wrote up the concept and asked a few people I trust to read it. They were generous with their time, and their responses were what I would call predictable: privacy, security, too many apps already, and too invasive. Those are fair instincts. They are also, for Ami specifically, backwards, and the fault is mine for not showing it. So let me show it now, against the things already in most homes.

The video doorbell sends what it sees to the company’s servers, and in 2023 the Federal Trade Commission found that employees and contractors had been able to watch customers’ videos without their knowledge [16]. A home alarm installer’s technician pleaded guilty in 2021 to using his access to watch inside about two hundred customers’ homes [17]. The golf app on many phones records every spot its owner stood, ties it to a name, an email and a phone number, and by its own App Store privacy label uses that data to track its owner across other companies’ apps [18]. The receipt-rewards app pays you in points because brands pay it for what you bought [19]. Each of those is a product people like and keep, and I am not telling anyone to delete them. I am pointing out that none of them is private, and nobody calls them invasive.

Ami shares nothing about you with any outside source. As built, there is not a line of network code in it. When the other lens is added, the one thing that will leave the phone is a question about medicines and conditions, de-identified, meaning stripped of anything that says who you are: no name, no account, no contacts and no identifier attached, sent to the public library and to a reasoning model that keeps nothing. The reasoning is over the medicines, not over you. If I ever ship Ami, saying that clearly and first is the job, and I plainly did not do it the first time. Maybe I should also have waited until it was buttoned up in my own eyes before asking. I am no Steve Jobs, but when he was asked about the difficulty of designing products by focus group he said that a lot of times people don’t know what they want until you show it to them [20]. Not sure. But maybe.

I have been here before. Around 2000, iMetrikus launched MyHealthChannel, a free consumer website for people with chronic conditions, with a personal health journal and information tailored to the person’s own history [21]. We later had a Yahoo partnership behind it, discounts included, as I recall. Consumers were hard to win over then, even when the technology was useful, and nothing I saw this month suggests that has changed. Been here before. Never give up.

Why the hospital version is different

Walk back into the ICU and every one of the home problems disappears. The data is already flowing: the pump, the monitor, the lab system, the order. The list is reconciled. The user is a nurse who is paid to look and a pharmacist who is paid to care. The moment is now, because the drug is running now. Nobody installs anything and nobody has to be persuaded that a second app is worth having, because there is no app. There is a quiet layer that reasons over what is already there and speaks when something changes. Better therapy, in real time, by reasoning instead of reacting: that is the case Ai MedAgent was built to make, and the home experiment made it sharper, not weaker.

On regulation, since it is easy to blame for a pause: most of the public-data layer sits inside FDA’s fence. The agency’s January 2026 wellness guidance and its software policy leave room for medication tracking, for drug interaction information written for patients, and for preventive reminders from established authorities [22][23]. What sits outside the fence is the sentence I most wanted to write: your heart rate plus your beta blocker (a common heart and blood pressure medicine) suggests. That one is a medical device, and it should be. The boundary is real, and the next pass will be built with it in view, not against it.

Now what

Ai MedAgent for critical care is my primary focus and it keeps moving. The next enhancement is what I am calling Smart Formulary and Smart Orders: using AI to read the hospital’s own drug library (its approved list of drugs, concentrations and dose limits, loaded into every pump), the pharmacy order and the pump’s limits together, before the first drop, so that the order the pharmacist verifies is an order the pump can actually run, and so that the gap between them is caught by a reasoning model instead of by a nurse at two in the morning. The method is in my fourth provisional patent application, the first filing that holds a date while the full application is prepared. Announcements to follow.

Ami will see improvements too. It has a way to go, and I did not give take one enough runway before judging it. The goal has not changed: a non-invasive butler that watches, quietly, for the health-related things your own records and the public library could tell you about, and speaks only when one of them touches your life. It will be a challenge in the consumer market. I have been here before, and the technology has never been better. Never give up.

Questions, and a promise

Questions, and I promise to read every answer.

Answers, arguments and better ideas go to aimedagent.net/contact. Pick “something else” in the first box and I will know what it is about. More to come.

About me

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, was a founding member of the iMetrikus team, and contributed to IHE Patient Care Device interoperability standards. He is co-inventor on US patent 7,375,647 and has filed five provisional applications on the reasoning method behind Ai MedAgent™. He writes Inside the Loop from Murrieta, California.

The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices to the record, and what finally changed. pettusbook.com.

Ai MedAgent™ is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not FDA cleared. Synthetic patients and simulated feeds. See it at aimedagent.net. Ami is an unreleased experiment and is not available to download.

Footnotes on request: https://aimedagent.net/contact

Inside the Loop, Issue 24 | Daniel C. Pettus | October 2026

Last week a few friends asked what I was doing with AI, and whether it had anything to do with the book. The second question is easy. It is the whole reason for the book. The first one deserves a straight answer, because there is a lot of noise about what AI does and does not do, and I have now spent about a year finding out for myself.

So here is the accounting. Not dramatic. The case does not need it.

The same story, told four times

My book lays out a career spent chasing one idea: that data becomes information, information becomes knowledge, and knowledge, if you are lucky and patient, becomes wisdom at the bedside. Every job I had moved that idea one notch. None of them finished it.

It started in anesthesia. In 1988 we introduced ARKIVE, an anesthesia record keeper that listened to the gas machine, the monitors, the ventilator and the IV pumps and wrote the record while the clinician worked [1]. We collected every number in the room. We did not yet know what to do with most of them. That was the data step, and I thought it was the hard one.

Around 2001, at iMetrikus, I used the Unified Medical Language System for the first time. The UMLS is the National Library of Medicine’s metathesaurus, begun in 1986, a single key that ties together more than a hundred vocabularies so that a drug, a lab or a diagnosis means the same thing no matter which system wrote it down [2]. We loaded it off CDs. It was free then and it is free now. That was the first time I understood that the normalization problem was bigger than the collection problem, and that the government had already paid for most of the answer. Information, not just data.

Then came the fifteen years at Alaris, which became Cardinal Health, then CareFusion, then BD [3]. That stretch is where the value of data stopped being a theory. The Medley pump shipped in 2001, and for a while our older one- and two-channel pumps outsold it; nurses were right to be skeptical of a new box. What changed the market was not the box. It was Guardrails, which put the hospital’s own dose limits inside the pump; CQI reporting, which turned every override into a number a pharmacy committee could act on; wireless and a server to carry data sets down and events up; and finally auto-programming, where the pump took its settings from the verified order in the EHR [4][5][6]. Alaris went from about 32 percent of installed US channels in 2002 to more than half the market by 2019 [4][7]. Knowledge, applied.

By the time I retired in May 2019, BD held several of the assets that touch a dose on its way to a patient: pharmacy systems, IV compounding, automated dispensing, and the infusion pumps. Every one of them generated data. We did real work to connect them, and patients were safer for it. I am proud of that work.

What I came to realize

I also came to realize, somewhere in those last years, that we were pushing the status quo as far as it would go and no further. The fundamental problems were the same ones I had met with the UMLS in 2001.

Data by itself is noise. It has to be normalized and codified before it means anything, and in a hospital that starts with the formulary. Four systems describe the same drug four ways, and nobody owns the dictionary.

Territory. Who owns the patient’s medication record: the device company, the hospital, or the EHR vendor? Everyone had an answer and the answers did not agree.

Workflow and the single source of truth. A pump knows what it is doing. The pharmacy knows what it dispensed. The EHR knows what was ordered. Each is correct about its own piece, and the patient is the only place the pieces meet.

Do not get the wrong idea. We improved a lot of patient encounters. But the barriers were still standing when I left, and for BD things got harder afterward. The Alaris system went on a distribution hold in 2020 and did not get its new clearance until July 2023 [8]. Credibility is slow to earn and quick to lose. I do not keep in close touch with former colleagues, and they have their own work to do. That is another story and not this one.

What retiring does not do is erase what you learned. The accumulation stays. It just stops having anywhere to go.

Then I started experimenting

About a year ago I began working with AI. Not as a chat tool, although I use that too. I started to see that the years of learning could be pointed at something I had wanted to do for decades: change the way we manage therapy for critical care patients. The premise is basic. Move from an event-driven reaction to proactive therapy. Try to see a little way into the future using the data already flowing through local connectivity, joined to the lesson of 2001, the free medical data available to anyone, and then put reasoning over the top of all of it.

What AI let me do was turn methods and concepts into a working series of applications. That sentence hides the important part, so let me say it plainly.

AI does not invent. That is still a human job, at least for now. The concept came from me, the knowledge of the space came from me, and the judgment about what was worth building came from me. What I did not have was the ability to write the software. This was going to be a series of connected applications running on a server and in the cloud, which means code, and a lot of it. The last time I wrote commercial code was the late 1980s, in PL/M, a language anyone under fifty has never heard of [9]. There was a reason for that language, and it is not important here.

So I learned to be precise about what I asked. I used Claude on the desktop, Opus for some tasks and Fable for others. I wrote a standing set of instructions that governs every session: be honest first; validate every reference the way a journalist would; tell me when I am wrong; no flattery; and, because I can spot it a mile away, no em dashes. I learned that the machine will cheerfully build the wrong thing if you describe it loosely, and that most of my job was describing the right thing.

It took cloud functions to reach the public data marts and feed the reasoning engine. It took patience. It took iterations, a great many of them, and more than one evening where the honest instruction came back to bite me: the machine told me a number in my own film was wrong, and it was.

What came about

Here is what exists today, one line each, and where the code lives. Everything on aimedagent.net runs on simulated patients and is a proof of concept, not a product.

• AI MedAgent medication pass. A synthetic patient moves through an encounter while a reasoning model reads the chart and four public data sources live and writes advisories a clinician approves. aimedagent.net; public repository on GitHub.

• The closed-loop demonstration. The model proposes act, hold or escalate within clinician-set bounds, and the server enforces the bounds afterward. Same site, same repository.

• A CDS Hooks service. Order-select and patient-view hooks that return cards with a coverage statement saying exactly which checks ran and which did not. aimedagent.net/cds-services.

• The PCD-E sandbox. A public door for infusion pump data in IHE PCD-01, with a reference client and keys you mint yourself. It refuses anything that looks like a real patient before it reads a byte. aimedagent.net/device.

• The EHR lab. FHIR connectors to the Epic, Oracle Health and MEDITECH sandboxes, and a consult engine that ran over their records and over Synthea patients. Private, not published, because it holds the credentials.

• One Formulary. A browser-only checker that reads a hospital’s infusion formulary and reports what stands between it and pump auto-programming, against ISMP, ASHP and IHE. Open source, Apache 2.0, on the site.

• OpenBedside. An open-source gateway between bedside devices and the EHR, standard library only, 36 tests, Apache 2.0. Written up in Issue 23. github.com/danielpettus/openbedside [10].

• Open MedPass. A barcode medication pass against the VA’s open-source VistA that programs a simulated pump by PCD-03. Demonstrated on video in September.

• A simulated Oracle Health hospital. A listener that joins Oracle sandbox events and OpenBedside device feeds into one hospital view. aimedagent.net/oracle; the listener is private.

• Smart Formulary and Orders. The method in my fourth provisional application and a private working model of a model-informed IV order. Patent pending; not public.

• The film. Nine scenes of a patient’s medications, drawn in code and rendered frame by frame, four minutes, no narration. It is below.

• The book. The interior and the cover were typeset by scripts the machine and I wrote together. The words are mine.

Could I have done any of this without AI? No. I want to be careful here because it is easy to overstate. I could have written the concept. I have been writing it for years. I could not have built it, and a concept that cannot be clicked is a slide.

I am proud of what one person was able to put together in under a year.

So, yes and no

Did AI help me realize a vision of proactive care using local and public data, reasoned over in real time? Yes. The demonstration is real, it is live, and anyone can go and press the buttons. And no. I know this business. It is full of invented-here silos, and the regulatory requirements are real and they are not optional. It was never my intent to build a product for commercial sale. My intent was to prove that we can change for the better, and that AI can dramatically accelerate the raw development work that used to stand between an idea and a demonstration.

AI still needs the human to have the concept, the knowledge of the field, and the judgment about what to build and how. That part has not changed and I do not expect it to soon. What has changed is everything after that.

For me, AI worked. And it worked brilliantly.

If your organization is heading in this direction and wants an advisor who has already made the mistakes, or would rather license the method and build it properly, reply below. It reaches me.

Contact Me

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, was a founding member of the iMetrikus team, and contributed to IHE Patient Care Device interoperability standards. He is co-inventor on US patent 7,375,647 and has filed four provisional applications on the reasoning method behind Ai MedAgent™. He writes Inside the Loop from Murrieta, California.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices to the record, and what finally changed. pettusbook.com.}

^{Ai MedAgent™ is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not FDA cleared. Synthetic patients and simulated feeds. See it at aimedagent.net.}

Notes

^{[1] Pettus, D. The Technology Was Never the Problem. 2026. The ARKIVE anesthesia record keeper was introduced at the American Society of Anesthesiologists meeting, 1988; see the chapters on ARKIVE. pettusbook.com.}

^{[2] National Library of Medicine. Unified Medical Language System (UMLS), nlm.nih.gov/research/umls. Begun 1986 under Donald A. B. Lindberg; integrates more than 100 vocabularies, including RxNorm, SNOMED CT and LOINC; license free of charge. Accessed 6 October 2026.}

^{[3] Cardinal Health acquired ALARIS Medical Systems in 2004; CareFusion was spun out of Cardinal Health in 2009; BD completed its acquisition of CareFusion on 17 March 2015. CareFusion, Wikipedia, accessed 6 October 2026, and the companies’ own releases.}

^{[4] ALARIS Medical Systems, Inc. Annual Report on Form 10-K for the year ended 31 December 2002. “We shipped the first Medley System in May 2001 and we implemented full market release in January 2002.” Installed base: approximately 32% of US large volume infusion channels, with Baxter 33%, Abbott 26% and B. Braun 6%. sec.gov.}

^{[5] ALARIS Medical Systems, Inc. First quarter 2004 results. Enterprise-wide networked Medley demonstrated at HIMSS, 23 February 2004, “currently on patients at several institutions across the United States.” sec.gov.}

^{[6] CareFusion and Cerner implement integrated solution at Children’s Hospitals and Clinics of Minnesota, 30 November 2012: the pump programmed from the verified order by scanning a barcode. See also Pettus, D. Worth the Effort? Closed-Loop Infusion Pump Integration with the EMR. AAMI BI&T 2013;47(6):467, doi.org/10.2345/0899-8205-47.6.467.}

^{[7] iData Research. Best-Selling Large Volume Infusion Pumps in the United States: BD held over 50% of the large volume pump market in 2019. idataresearch.com. Accessed 6 October 2026.}

^{[8] MedTech Dive. BD gains FDA clearance to relaunch Alaris infusion pump after recalls. 510(k) clearance 21 July 2023; distribution hold since 2020. Accessed 6 October 2026.}

^{[9] PL/M, Programming Language for Microcomputers, developed by Gary Kildall at Intel in 1973 for the Intel 8008. Wikipedia, accessed 6 October 2026.}

^{[10] Pettus, D. OpenBedside, release 0.2.0, 26 September 2026, Apache License 2.0. github.com/danielpettus/openbedside. And Inside the Loop, Issue 23, Why I Gave Away the Plumbing.}

^{[11] The film: A Day in the Life of a Patient’s Medications. Ai MedAgent™, October 2026. YouTube link to be inserted. Not FDA cleared. Synthetic patient. Proof of concept live at aimedagent.net.}

What is real: the reasoning, which runs today at aimedagent.net. What is not: Eleanor, who is synthetic, and the screens, which are drawn. Not FDA cleared. Patent pending. A proof of concept, not a product.

This readership will check the numbers, so here they are. The norepinephrine bag is 4 mg in 250 mL, 16 mcg/mL, and the pump rates are computed for a 58 kg patient. The cefepime adjustment follows the label table for a creatinine clearance of 11 to 29 mL/min.

Does it matter? I think the whole encounter reasoned over at once, local data and public data together, with the pump in the loop, is the piece that forty years of interoperability work never delivered. I am retired, so I am not looking for a job. I am looking for a home for the work: an organization heading this way or one that would rather license the IP and build it properly.

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

The VA solved that problem for me decades ago without meaning to. VistA, the EHR that still runs most VA hospitals, is public domain. So I brought it home and built a medication pass around it, with OpenBedside feeding simulated pump data and AI MedAgent reasoning over the record.

It took a weekend and no license fees.

Get the pieces:

• VistA for Docker (WorldVistA): github.com/WorldVistA/docker-vista

• OpenBedside: github.com/danielpettus/openbedside

• AI MedAgent: aimedagent.net

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

Inside the Loop, Issue 23 | Daniel C. Pettus | 28 September 2026

For about a year I have been saying the same thing to anyone who would listen, and to a few who would rather not. AI in healthcare is stuck at the keyboard. It writes the note, summarizes the chart and answers the question. That is chat. It is useful, and it is not the prize.

The prize is reasoning. A model in the cloud that reads the public knowledge of medicine and the live state of one patient at the same time, and keeps asking one question: is what is happening to this person still consistent with what we believe is happening to her, and is what we are doing about it still the right thing to be doing? Not waiting for an alarm. Not waiting for a tired nurse to spot the trend at three in the morning, with two sicker patients down the hall. Predicting the better therapy before the event, instead of documenting the event after it.

That is the whole idea. Move from chat to reasoning, and from reacting to predicting.

From an idea to something you can click

It went from an idea to a method written out in plain language, to three provisional patent applications filed on 11 June, 10 July and 11 July 2026, to a full demonstration running online at aimedagent.net. The patient in that demonstration is simulated. The reasoning is real, and it runs every time someone presses the button.

I have spent forty years watching good ideas die in the gap between a slide and a hospital. I did not want this one to die there, so I built it. Retirement is excellent for that. Nobody schedules a meeting to discuss whether you should.

It has not been a straight line. The first version of the demonstration told me it was running live when it was not. A system that will tell you it is live when it is not is worse than no system at all, so I took it down and rebuilt it. Today every alert says whether it was generated live or written in advance, and every response says how many of the eight standard medication safety checks it was able to perform. On one vendor’s certified test record, the honest answer was two of eight. That half is the point.

The data was already there, and we already paid for it

This is the part that still surprises people. Most of what a reasoning engine needs to know about drugs, devices, evidence and outcomes is published by the federal government, free, through public interfaces. Taxpayers paid for it years ago. Here are the public data marts, by who publishes them.

The National Library of Medicine. RxNorm and RxClass say what a drug is and what class it belongs to.[1] DailyMed holds 159,397 drug labels submitted to the FDA.[2] ClinicalTrials.gov lists 598,690 registered studies.[3] The Unified Medical Language System maps more than a hundred vocabularies, including SNOMED CT, LOINC and ICD-10-CM, into more than a million concepts.[4] PubMed indexes more than 40 million citations.[5] LiverTox and LactMed answer two questions every clinician eventually asks: can this drug hurt the liver, and is it safe while breastfeeding?[6]

The Food and Drug Administration, through openFDA. 20.7 million drug adverse event reports. 26.1 million medical device adverse event reports. 5.2 million device identifier records. And the working inventory of the drug supply: 262,887 labels, 138,184 product listings, 17,965 recall enforcement reports and a live list of shortages.[7]

The CDC and CMS. The vaccine adverse event reports and the CDC WONDER public health databases.[8] The NPPES registry, the national directory of provider identifiers.[9] Medicare Part D data on who prescribes what.[10]

The consortia. CPIC publishes guidelines on the genes that change how a drug should be dosed.[11]

Twenty-six million device reports. That is not a dataset you skim over coffee. That is twenty-six million times a device surprised someone enough to file a report, and it is sitting there, free, waiting for something that can read it all at once.

None of this is new. My own company loaded the federal reference data off CDs in 2001. What is new is a machine that can be handed the whole picture and reason over it in seconds. The data got fast. Healthcare did not.

In fairness to my own demonstration, it queries four of these live today: RxNorm and RxClass, the FDA’s drug adverse events, DailyMed and ClinicalTrials.gov. The rest are next. And one honest gap. The free source that mattered most for drug interactions is gone: the National Library of Medicine discontinued its drug interaction service on or about 2 January 2024.[12] Interactions now come from licensed drug knowledge bases. AI MedAgent has a socket for one, deliberately empty, and it says so on the screen rather than pretend.

Reasoning needs ears

Knowledge is half of it. The model also needs to listen, to the chart and to the machines at the bedside. A reasoning engine that knows every drug label ever written, but not that this patient’s creatinine doubled overnight or that her pump dropped to keep-vein-open an hour ago, is a very well-read bystander.

The EHR has a door now. Every certified EHR in the United States has had to offer a standardized FHIR interface since the end of 2022.[13] It is open. It is not free, and getting in is uneven: when I read live records from the Epic, Oracle Health and MEDITECH sandboxes, it took under an hour, a day, and a wait on a human being. But the door is there.

The devices are another story. Most infusion pumps, monitors and ventilators speak their manufacturer’s own protocol, through the manufacturer’s own gateway, reachable through agreements that take months and lawyers. The standards exist, and they are not new. The IHE Patient Care Device profiles for HL7 were first tested at a Connectathon in January 2007 and shown live at HIMSS in New Orleans a month later.[14] I sat in on that work. Nearly twenty years on, the standards are mature. Access is the problem.

And the device that matters most is the one hardest to reach. In 2010 the FDA reported more than 56,000 adverse event reports associated with infusion pumps over five years, more than 500 associated deaths, and 87 pump recalls between 2005 and 2009.[15] Pumps deliver the drugs with the least room for error, and they know exactly what is going into the patient right now. That makes the pump the most important feed a medication reasoning engine can have. I spent years inside the companies that build those gateways. I know how much work is in one, and why nobody gives them away.

I built the ears, and gave them away

As newer device makers enter the market, I decided not to wait for the old doors to open. I built a medical device gateway and interface engine, called it OpenBedside, and released it as free, open-source software under the Apache License 2.0.[16] Anyone can download it, use it, change it and build it into a product. No fees, no royalties, no permission needed.

It takes data from an infusion pump, normalizes it, and delivers it to the hospital EHR as standard IHE HL7 messages. It stores and forwards, so nothing is lost when the network drops. It registers devices, so nothing unknown reaches a chart. It finds each device’s patient from the pump itself, from the hospital’s admission feed or from a nurse, and when those sources disagree it names nobody rather than the wrong somebody. It has a live web page that shows every device, every message and every decision. It is plain Python with no outside dependencies, and a device maker connects its own pump by writing a single adapter. It starts with IV pumps, and it is built for ventilators next.

Why would a retired guy give away the plumbing? Selfish. I need these feeds to close the reasoning loop, and waiting for every manufacturer to open its own door could take another twenty years. If OpenBedside helps a new pump company connect in a month instead of a year, some of that data may one day feed AI MedAgent. If it never does, it still helps somebody. I can live with either outcome.

What this is, and what it is not

AI MedAgent is a research demonstration: simulated patients, synthetic data, advisory only, not a medical device. OpenBedside is test software as well. It has no encryption yet, so it belongs on test networks with made-up patients. Reasoning at the bedside is a future capability that I am demonstrating now. It will take time, testing and investment, and the regulators will have their say, as they should.

It will happen. The data is free. The EHR door is open. And the device door now has a key anyone can copy.

See AI reasoning in action at aimedagent.net. Download the free, open-source gateway at github.com/danielpettus/openbedside. And if you make pumps or ventilators, fork it. I would rather be copied than ignored.

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

Notes

^{[1] National Library of Medicine. RxNav: RxNorm API and RxClass API, lhncbc.nlm.nih.gov/RxNav. Accessed 27 September 2026.}

^{[2] National Library of Medicine. DailyMed, dailymed.nlm.nih.gov. Home page count of labeling submitted to the FDA, 159,397, accessed 27 September 2026.}

^{[3] National Library of Medicine. ClinicalTrials.gov, application programming interface version 2, total registered studies, 598,690, retrieved 27 September 2026.}

^{[4] National Library of Medicine. Unified Medical Language System (UMLS), nlm.nih.gov/research/umls. More than 100 source vocabularies, including RxNorm, SNOMED CT, LOINC and ICD-10-CM, and more than one million concepts. No charge for the license.}

^{[5] National Library of Medicine. PubMed, pubmed.ncbi.nlm.nih.gov. Home page: more than 40 million citations. Accessed 27 September 2026.}

^{[6] National Institute of Diabetes and Digestive and Kidney Diseases and National Library of Medicine. LiverTox: Clinical and Research Information on Drug-Induced Liver Injury, NCBI Bookshelf, ncbi.nlm.nih.gov/books/NBK548157. National Library of Medicine. Drugs and Lactation Database (LactMed), NCBI Bookshelf. Accessed 27 September 2026.}

^{[7] US Food and Drug Administration. openFDA, open.fda.gov/apis. Totals from each endpoint’s meta record, retrieved 27 September 2026: drug adverse events 20,692,690 (data updated 30 July 2026); device adverse events 26,136,889 (8 September 2026); device unique identifiers 5,182,695 (2 September 2026); drug labels 262,887 (25 September 2026); NDC product listings 138,184 (23 September 2026); drug recall enforcement reports 17,965 (9 September 2026); drug shortages 1,601 (25 September 2026). openFDA states that its data are unvalidated and are not to be relied on for medical decisions.}

^{[8] US Department of Health and Human Services. Vaccine Adverse Event Reporting System (VAERS), data sets, vaers.hhs.gov/data. Centers for Disease Control and Prevention. CDC WONDER, wonder.cdc.gov.}

^{[9] Centers for Medicare and Medicaid Services. NPPES NPI Registry and API, npiregistry.cms.hhs.gov.}

^{[10] Centers for Medicare and Medicaid Services. Medicare Part D Prescribers by Provider and Drug, data.cms.gov.}

^{[11] Clinical Pharmacogenetics Implementation Consortium. CPIC Guidelines, cpicpgx.org.}

^{[12] National Library of Medicine. RxNav Drug Interaction API notice: “The Drug-Drug Interaction API will be discontinued on or about January 2, 2024.” lhncbc.nlm.nih.gov/RxNav/APIs/InteractionAPIs.html.}

^{[13] Office of the National Coordinator for Health Information Technology. 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, Final Rule, 85 FR 25642, 1 May 2020, and 45 CFR 170.315(g)(10), the standardized FHIR API criterion. Compliance deadline 31 December 2022.}

^{[14] IHE International. IHE Patient Care Devices Domain: Rich History, Promising Future. 28 January 2019. First profiles tested at the January 2007 Connectathon at RSNA headquarters; demonstrated live at the HIMSS Annual Meeting, New Orleans, February 2007.}

^{[15] US Food and Drug Administration. FDA Launches Initiative to Reduce Infusion Pump Risks. News release, 23 April 2010: more than 56,000 adverse event reports over five years, more than 500 deaths associated with infusion pump use, 87 recalls between 2005 and 2009.}

^{[16] Apache Software Foundation. Apache License, Version 2.0, January 2004, apache.org/licenses/LICENSE-2.0. OpenBedside source: github.com/danielpettus/openbedside.}

Inside the Loop, Issue 22 | Daniel C. Pettus | 23 September 2026

Brisbane, 2017, and the medication pass nine years later.

On 8 August 2017 I presented at HIC 2017, the national conference of the Health Informatics Society of Australia, in Brisbane.[1] I was a vice president at BD. The abstract, the talk and the poster made one argument: the medication pass in an acute care hospital is a relay of roughly thirty steps, and risk and delay are documented at nearly every hand-off.

IV medications got the most attention, and they deserved it. IV infusion errors have been identified as carrying the greatest potential for patient harm.[2] But the poster drew two lanes, not one. Oral medications had their own shortages, substitutions, missing doses and calls back to pharmacy. Plenty of risk and plenty of ways to fail, with no pump in sight.

We showed where BD’s products fit with the EHR to close those gaps. It was a vendor poster. It was also well received, because the problem it described was the one every nurse and pharmacist in the room worked inside every day.

The name Australia already had

The title of our abstract used a term Australia had already made standard: Electronic Medication Management Systems, or EMMS.[3] The Australian Commission on Safety and Quality in Health Care publishes a national guide to implementing them, now in its third edition.[4]

In the United States we still buy CPOE, pharmacy, dispensing, the eMAR, barcode administration and smart pumps as separate systems with separate owners, and we have no single word for the whole. Australia named it. The name is nine years older than this article and it still fits. We should use it here.

Nine years on

I am retired now. This year I launched a concept and a method for using AI reasoning to optimize a patient’s therapy proactively at the bedside, especially in critical care. Looking back at the 2017 poster, I asked two questions. Has the medication pass improved? And would a reasoning layer have a place in it?

The answer to the first, not surprisingly, is: not much.

• In a review of 2,809 admissions at eleven Massachusetts hospitals in 2018, an adverse event occurred in 23.6 percent of admissions. Adverse drug events were the most common type, 39 percent of all events.[5]

• Across 2,314 hospitals tested with the Leapfrog CPOE evaluation tool from 2009 to 2018, median performance at catching potentially harmful orders rose from 53.9 percent to 65.6 percent. About a third still get through.[6]

• With smart pumps connected to the EHR, one multi-hospital study still counted 96.5 errors per 100 infusions, down from 114.6.[7]

The slices of cheese are thicker than they were. The holes still lineup.[8]

IVs should not be the only focus

The founding study of adverse drug events traced where the errors behind preventable harm began: 56 percent at ordering, 34 percent at administration. Nearly half of the ordering errors were caught before they reached the patient. None of the administration errors were.[9] Two thirds of the errors start before anyone touches a pump. Fixing the IV is necessary. It is not sufficient.

One source of truth, fed from the start

We should accept the eMAR and barcode administration as the single source of truth for what a patient received. It is the last record before a drug reaches the patient, and it is the one the nurse signs.

But truth at the end of the chain depends on alignment at the start. The drug the nurse scans must be the same drug, in the same concentration and units, that pharmacy built into the formulary, the prescriber ordered, the pharmacist verified and the pump library expects. When those disagree upstream, the eMAR records the disagreement faithfully. Alignment starts at the formulary and does not end until the patient is discharged.

The eMAR itself has improved. It now runs on the nurse’s handheld: Epic’s Rover app, for example, supports medication administration and IV infusions at the bedside.[10] That is real progress. What has not changed is the workflow behind it. The EMMS still lacks a common, connected process from formulary development onward.

The free data we leave on the table

There is a vast amount of drug data and knowledge online, and most of it is free. The National Library of Medicine’s Unified Medical Language System maps more than a hundred vocabularies, including RxNorm, into more than a million concepts.[11] DailyMed holds 159,318 labeling documents submitted to the FDA.[12] openFDA publishes the adverse event reports submitted to the agency since 2004, refreshed every quarter.[13]

These data marts are large and complex. Querying and reconciling them by traditional methods is hard and far too slow for the pace of a medication pass. The best way I have found to access and reason over them is AI working at speed: normalizing a local drug name to its RxNorm concept, reading the label, checking what has been reported, and bringing the result to the clinician while the order is still open.

That comes with a condition: the right controls. Regulators already require them. Since January 2025, certified health IT that supplies predictive decision support must make 31 source attributes available to users and apply risk management practices.[14] In my own work the controls are simple and not negotiable: advisory only, every finding traceable to its source, a report of what could not be checked, and a clinician who decides.

Can AI help?

Possibly. A reasoning layer that follows one patient across the whole EMMS, from formulary to discharge, could see what no single system in the relay sees: a home anticoagulant left off the admission orders, kidney function falling on two renally cleared drugs, a blood pressure trend that never crosses an alarm threshold. That is a hypothesis, not a result. It needs testing, and it needs investment to test it.

I rebuilt the 2017 walk as an interactive page, with the published evidence at every step and an AI MedAgent layer running alongside. Step through it at aimedagent.net/medication-pass.html, then tell me what has changed where you work.

We still have a long way to go.

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

Notes

^{[1] Health Informatics Society of Australia. HIC 2017, the 25th Australian National Health Informatics Conference, Brisbane, 7 to 9 August 2017. Proceedings: Integrating and Connecting Care, IOS Press, 2017.}

^{[2] Maddox RR, et al. Intravenous Infusion Safety Initiative: Collaboration, Evidence-Based Best Practices, and “Smart” Technology Help Avert High-Risk Adverse Drug Events and Improve Patient Outcomes. In: Advances in Patient Safety: New Directions and Alternative Approaches, Vol. 4: Technology and Medication Safety. Agency for Healthcare Research and Quality, 2008.}

^{[3] Pettus D, et al. Interoperable Electronic Medication Management Systems brings technology, products, and administration into one solution. Abstract, HIC 2017. Author’s files.}

^{[4] Australian Commission on Safety and Quality in Health Care. Electronic Medication Management Systems: A Guide to Safe Implementation. Third edition. Sydney: ACSQHC, 2019.}

^{[5] Bates DW, et al. The Safety of Inpatient Health Care. New England Journal of Medicine. 2023. doi:10.1056/NEJMsa2206117. 2,809 admissions, 3 large and 8 smaller Massachusetts hospitals, 2018.}

^{[6] Classen DC, et al. National Trends in the Safety Performance of Electronic Health Record Systems From 2009 to 2018. JAMA Network Open. May 2020. Figures as reported by The Leapfrog Group and University of Utah Health.}

^{[7] Skog J, Rafie S, Schnock KO, et al. The impact of smart pump interoperability on errors in intravenous infusion administrations: a multihospital before and after study. Journal of Patient Safety. 2022. PMID 35344977.}

^{[8] Reason J. Human error: models and management. BMJ. 2000;320(7237):768-770. PMID 10720363.}

^{[9] Bates DW, Cullen DJ, Laird NM, et al. Incidence of adverse drug events and potential adverse drug events: implications for prevention. JAMA. 1995;274(1):29-34. PMID 7791255.}

^{[10] University of Iowa Health Care, Epic Support, Rover: medication administration, IV infusions and flowsheet documentation in the Rover app. Accessed 23 September 2026.}

^{[11] National Library of Medicine. Unified Medical Language System (UMLS), nlm.nih.gov/research/umls. More than 100 source vocabularies, including RxNorm, and more than one million concepts. No charge for the license.}

^{[12] National Library of Medicine. DailyMed, dailymed.nlm.nih.gov. Home page count of labeling submitted to the FDA, 159,318, accessed 23 September 2026.}

^{[13] US Food and Drug Administration. openFDA Drug Adverse Event API, open.fda.gov/apis/drug/event. FDA Adverse Event Reporting System data from 2004, updated quarterly.}

^{[14] Office of the National Coordinator for Health Information Technology. HTI-1 Final Rule, Decision Support Interventions Fact Sheet, December 2023, and 45 CFR 170.315(b)(11). 31 source attributes for predictive decision support interventions; risk management practices; effective 1 January 2025.}

Inside the Loop, Issue 21 | Daniel C. Pettus | 22 September 2026

I spent forty years getting technology into hospitals. Alaris, CareFusion, BD. I am retired now, which means I can say what I think, and what I think is that the investment community is about to make the same mistake in both directions at once. Fund things that say AI and are not. Walk past things that are, because nobody in the room could tell the difference.

This is not a piece telling you to be careful. You have lawyers for that, and the medical device sector is better at regulation than at almost anything else. This is a piece telling you the next wave is real, that it will take risk capital to happen, and that the thing most likely to stall it is not caution. It is not knowing.

The worst outcome is to do nothing because you do not know.

Where the money is, in three numbers

Silicon Valley Bank’s seventeenth Healthcare Investments and Exits report, published in January 2026, put total healthcare venture investment at $46.8 billion in 2025, down 12 percent. Of that, AI took 46 percent, more than $18 billion. The device sector grew 1.5 percent. [1]

The pool shrank, half of it went to AI, and devices stood still. An acute care device with a real model inside it lives in the seam between those two numbers, too much hardware for the software money and too much model for the device money, and neither bench has the people to judge it.

Rock Health, in its first half 2026 report, put the shift in one sentence. [2]

“Investors and buyers are not asking, ‘Who has AI?’ but instead, ‘Who has something AI alone can’t provide?’”

Good. That is the right question. What follows is how to answer it.

Where clinical AI is today

At scale, it is at the keyboard.

Ambient scribes, the tools that listen to a visit and write the note, are the first wave and they are real. The Peterson Health Technology Institute reported in March 2025 that adoption “is on track to be one of the fastest in recent healthcare history,” that the tools are “potentially effective at reducing clinician documentation time and cognitive load,” and that the financial impact is still unproven. [3] All three of those things are true at once. It is a good product category solving a real problem for exhausted people.

The other place AI has landed is imaging. Of the 903 AI-enabled devices authorized through August 2024, 76.6 percent were radiology, according to Windecker and colleagues in JAMA Network Open. [4] Software that reads a picture and hands a finding to a physician who was already going to look at that picture.

Notice what those two waves have in common. They wait to be asked. A scribe listens to a visit that was already scheduled. A radiology model reads a study someone already ordered. Neither one is watching the patient at three in the morning, and three in the morning is where patients are lost.

The next wave: from chat to continuous

The wave that changes outcomes is the one where the model does not wait to be asked.

It sits in the data stream. Monitors, infusion pumps, ventilators, labs, the chart. It watches continuously, it reasons about trajectory rather than thresholds, and it either proposes an action to a clinician or, eventually and carefully, takes one. That is the difference between a tool that helps a doctor write faster and a tool that notices a patient declining between the scheduled observations, in the hours when nobody is looking because nobody was due to look.

This is not science fiction.

It has already been done, once, at scale

Automated insulin delivery. In September 2016 the Medtronic MiniMed 670G was approved as the first hybrid closed loop system, a continuous glucose sensor feeding an algorithm feeding an insulin pump. [5] In December 2019 Tandem’s Control-IQ was authorized as the first interoperable automated glycemic controller, software that, in the regulator’s own words, can “automatically increase, decrease and suspend delivery of basal insulin to the patient based on insulin delivery history, iCGM readings and predicted glucose values.” [6]

Continuous sensing, a predictive model, a therapy device, and a closed loop between them, deployed at scale, worn by children. It worked under specific conditions: one variable, one drug, one patient who owns the device and lives with it. Acute care is harder on every one of those axes. But the sentence “it cannot be done” is no longer available to anyone.

It has started in the hospital

On 2 April 2024 the Prenosis Sepsis ImmunoScore became the first AI tool authorized for sepsis. It draws up to 22 inputs from the electronic health record and produces a risk category for sepsis within 24 hours. [7] Narrow, early, explicitly an aid and not a decision. And a model reasoning over live hospital data about what is going to happen next, which is the shape of everything that follows.

The first wave helped clinicians type. The second wave reads pictures. The third wave watches the patient. The third wave is where the outcomes are, and it is the one your diligence process was never built to evaluate.

What “AI integration” actually means

Here is the part of the brochure nobody unpacks, and it is the part I have spent my career inside. Getting clinical technology to change an outcome is four steps, in order. Acquire the data. Normalize the data. Reason over the data. Connect it to a human being. A real product has something at every step. A brochure has something at step three and a picture of the rest.

1. Acquire. Is the data actually flowing?

The brochure says: “Integrates with the EHR.”

The real thing has: a named feed, a named standard, a named direction. And there are two feeds, not one. The stream is what is happening to the patient right now: pumps, monitors, ventilators. It comes off the device network through IHE and HL7 to a gateway. The chart is who it is happening to: orders, labs, allergies, history. It comes through the FHIR interfaces that every certified EHR in the United States has been required to expose since the end of 2022. [8] No single source carries both. Ask which one they have connected. Most have neither, and the ones with one will tell you they have both.

2. Normalize. Do the systems speak the same language?

The brochure says: “Works with any data source.”

The real thing has: a data dictionary, and I want to spend longer here than on the other three, because this is the step that quietly kills projects and it is the step almost nobody funds.

Without normalizing the data, and without an agreed dictionary of terms underneath it, none of the reasoning works. Not some of it. None of it. A model reasoning over a stream where the pump says one thing, the lab says another and the chart says a third is not reasoning. It is guessing with confidence, and confident guessing at a bedside is the thing every one of us in this industry has spent a career trying to remove.

The good news is that the hard part of this was solved a long time ago and it is sitting in plain sight. The National Library of Medicine started the Unified Medical Language System in 1986. It brings together more than a hundred clinical vocabularies, including RxNorm, SNOMED CT, LOINC and ICD-10-CM, into a single Metathesaurus of more than a million concepts, and it assigns each concept one identifier, a CUI, that is the same no matter which vocabulary a system happens to speak. The license is free. [9] It is public infrastructure, paid for already.

My personal experience with UMLS goes back to the early 2000s, and it is where I learned that the same-language problem is solvable if someone is willing to do the unglamorous work. Take the simplest case that matters, formulary alignment. A hospital’s master formulary, its order sentences, its pump drug library and its dispensing cabinet all name the same drug and concentration slightly differently. Map each of them to the same concept identifier and they can finally agree. Fail to, and every downstream system is reconciling by string match and hoping.

That is where AI earns its first honest keep, and it is not glamorous either. A model plus the public data sources, RxNorm, openFDA, DailyMed, is very good at the first pass of that mapping, at proposing the concept a local term most likely means and flagging the ones it is not sure of for a pharmacist to settle. It is the step that has to be done before any of the other steps in AI reasoning can be trusted. And I will be honest about its limit: public data gets you the first pass, not the last word. A licensed drug knowledge base and a person with a license still stand behind the final mapping, and any vendor who tells you otherwise has not shipped into a pharmacy.

Ask the founder to show you the dictionary. Not describe it. Show it. The mapping table from their sources to a common concept set, with the un-mapped terms listed. The companies that have one will bring it to the meeting. The companies that do not will talk about the model.

3. Reason. What does the model actually do?

The brochure says: “AI-powered.”

The real thing has: what goes in, what comes out, how fast, what it does when an input is missing, and the one thing that never makes the slide: what it reports that it could not check. A model that watches trajectory over an hour and flags a patient nobody has looked at is a different object from a model that waits for a number to cross a line. And an engine that reports its own blind spots is checkable. One that does not is a brochure.

4. Connect. Who acts, and who let them?

The brochure says: “Clinical decision support.”

The real thing has: a named role, a named moment in that person’s existing workflow, a named governance body that approved the change to that workflow, and an answer for what happens when the human disagrees. This is the step where the hospital’s buying committee lives, where pharmacy owns the configuration and nursing owns the response and security owns the door. It is also the step my industry spent forty years underestimating, which is how I know it is the step you will underestimate too.

The pattern across all four: a brochure asserts a capability as a noun. A real product can describe it as a verb. What changes, for whom, at what hour, and under whose authority.

What it is worth, and what it costs

I will not do the pom-poms. Here is the honest ledger.

What it accomplishes. It catches the trajectory that no threshold catches. It sees the interaction between two systems that neither system sees alone, a drug on a pump and a lab value in the chart. It gives the night shift, which is understaffed everywhere, a second set of eyes that does not get tired. And it does the one thing five decades of connectivity never did: it puts a reasoning step between the data and the human, instead of just moving the data faster.

What it risks. A model wrong at scale is wrong in every bed at once. Automation bias is real, it has been measured, and clinicians do defer to confident software. [10] Nobody has yet settled who is liable for a model’s recommendation, and the first lawsuit will settle it for everyone. And the industry it is breaking into is a status quo industry with policies, committees and buyers who have been burned by five previous nouns and are not wrong to be skeptical of the sixth.

Why it is still worth the risk. Because the alternative is the current state, and the current state is patients declining between observations while the data that would have told you sits in three systems that do not talk. That is not a hypothetical cost. It is the one we are paying now, and we have simply stopped counting it.

Five questions that separate the real thing from the brochure

None of these is about the regulator. Founders in this sector can handle the regulator. These are about whether the thing exists.

1. Which feed do you have running, the stream or the chart? Show me. Not a diagram. The data, moving, today. A company that has the chart connected through FHIR is real. A company that has device data flowing through a gateway is rare. A company that says it has both and cannot show either has a slide.

2. Show me the dictionary. The mapping from your sources to a common concept set, with the un-mapped terms listed. If there is no dictionary, there is no normalization, and if there is no normalization the model is reasoning over noise.

3. What does the model report when it cannot check something? If the answer is silence, you are funding confidence, not reasoning. The second output, what it could not see, is the one that tells you whether the engineers understood the problem.

4. Who acts on the output, at what point in their existing workflow, and who approved putting it there? A physician champion is not an answer. A committee minute is.

5. What is the smallest version of this running today, and can I see it? Not the vision. The thing. A small working example beats a large described one every time, and it is the single most reliable tell I know.

A small thing, by design

I should show you what I mean by that last question, since I am asking you to apply it to others.

I have a demonstration running at aimedagent.net. It is not a product and it is not a company. It is a reasoning layer sitting between a patient’s data and a clinician, built to show one thing: that the third wave can be built today, with the standards and the public data that already exist. I am not selling it. I am pointing at it, because it is easier to argue about something you can see.

Read the diagram against the four steps. Acquire: two feeds, the stream and the chart, which one is simulated and which one is live. Normalize: the row along the bottom, RxNorm, openFDA, DailyMed, ClinicalTrials, the free public vocabularies doing the same-language work. Reason: the dark box in the middle, trajectory rather than threshold, and it reports what it could not check as a first-class output, not a footnote. Connect: the clinician at the top. Reads it, and decides. Nothing happens without them.

It is small on purpose. It is advisory only. It is patent pending. And it exists so that when I say the third wave is real, I am not asking you to take my word for it.

I invite the investment community to pay attention. Not to this. To the class of thing it is. That is where the value of AI reasoning is heading, and it is going to need people with capital who can tell it apart from the noun on the slide.

Where this leads

I have no idea. Neither do you. Anyone who tells you they know how clinical AI plays out over the next decade is selling something, and it is probably in a brochure.

But the inevitable is the inevitable. The models are good enough. The interfaces exist. The vocabularies were built forty years ago and are sitting there free. The first authorizations are on the books. What is missing is the capital to carry the real ones across the gap between a demonstration and a deployment, and the judgment to know which ones those are.

We are going to see a massive change in how care is delivered over the next several years. It will take risk investment to make it happen. Many will fail. Some will break out. The ones that break out will change healthcare, and I would like it to be for the better, which is why I am writing to the people who decide what gets funded rather than to the people who build it.

You now have four steps and five questions. That is more than most of the market has.

The AI in the brochure is not the risk. The risk is that you cannot tell it from the real thing, and so you fund neither.

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.

The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.

AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net

Notes

^{[1] Silicon Valley Bank, a division of First Citizens Bank. AI Investment Accounted for Nearly Half of Healthcare Investment in 2025; Silicon Valley Bank Releases 17th Healthcare Investments and Exits Report. Press release, 8 January 2026. Total healthcare venture investment $46.8 billion in 2025, down 12 percent; AI 46 percent and more than $18 billion; device sector growth 1.5 percent.}

^{[2] Rock Health. H1 2026 digital health funding report, July 2026, as reported by Fierce Healthcare, July 2026. Rock Health counts digital health, which is predominantly software and services, not acute care devices.}

^{[3] Peterson Health Technology Institute. Leading Health Systems: AI-Powered Scribes Alleviate Clinician Burnout; Financial Impact Unclear. 25 March 2025.}

^{[4] Windecker D, Baj G, Shiri I, et al. Generalizability of FDA-Approved AI-Enabled Medical Devices for Clinical Use. JAMA Network Open. 2025;8(4):e258052. Published 30 April 2025. 903 devices authorized through 31 August 2024; radiology 692 (76.6 percent); cardiology 10.1 percent; neurology 3.2 percent.}

^{[5] US Food and Drug Administration. Approval of the Medtronic MiniMed 670G hybrid closed loop system, September 2016, described by the agency as the first device approved in the United States to automatically monitor glucose and provide appropriate basal insulin doses in people 14 and older with type 1 diabetes.}

^{[6] US Food and Drug Administration. FDA authorizes first interoperable, automated insulin dosing controller designed to allow more choices for patients looking to customize their individual diabetes management device system. Press announcement, 13 December 2019. Tandem Diabetes Care Control-IQ Technology, De Novo pathway.}

^{[7] US Food and Drug Administration. De Novo DEN230036, Sepsis ImmunoScore, Prenosis, Inc. Decision date 2 April 2024. Up to 22 predetermined inputs from the electronic health record; risk of presence of or progression to sepsis within 24 hours; intended for use in conjunction with other laboratory findings and clinical assessments.}

^{[8] Office of the National Coordinator for Health Information Technology. 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, Final Rule, 85 FR 25642, 1 May 2020, and 45 CFR 170.315(g)(10), the standardized FHIR API criterion. Compliance deadline 31 December 2022. ONC reported on 10 February 2023 that more than 95 percent of certified health IT developers met the deadline.}

^{[9] National Library of Medicine. Unified Medical Language System (UMLS), nlm.nih.gov/research/umls. Begun in 1986 under NLM Director Donald A. B. Lindberg. The Metathesaurus integrates more than 100 source vocabularies, including RxNorm, SNOMED CT, LOINC and ICD-10-CM, into more than one million concepts, each carrying a Concept Unique Identifier. There is no charge for the UMLS license.}

^{[10] Goddard K, Roudsari A, Wyatt JC. Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association. 2012;19(1):121-127.}

She said it standing next to a pump I had just finished demonstrating, in a critical care unit in Brisbane. “We love the technology from the U.S., but we think your healthcare system is nuts. How a modern country like the U.S. does not see a person’s right to healthcare is simply nuts to us.” She was not being unkind. She was being Australian, which means she said the quiet part in a normal speaking voice and went back to work.

I laughed. Then I flew home. It took me the better part of twenty years to notice that she had described, from memory and in two sentences, a table it has just taken me a week to build.

Fourteen countries, one narrow vantage point

Over forty years I was inside hospitals in fourteen countries: the United States, Japan, Australia, Canada, Ireland, the United Kingdom, Sweden, the Netherlands, Germany, Austria, France, Italy, Belgium and Finland. Some for a day, some for months. I was there because a sale had reached the point where somebody on the hospital side wanted to talk to the person who understood the network, the interfaces, and what was going to happen to their data. Most of that time was spent in critical care and the operating room. I was not around for admissions or discharges, and I am not going to say I know how those went.

What I do know is what the room looked like when a hospital decided whether to let my equipment in. I will come back to that, because it turned out to be the most surprising thing in the whole exercise.

This issue follows Issue 04, “We Broke It. We Know It. And We Keep Paying for It Anyway.” Same subject, different method. That one set the United States against the average. This one asks the same four questions of every country I stood in: what it costs, whether you have a right to it, how good it is, and what comes out the other end. The US goes last each time, so you have the comparison in hand before the home team comes up.

Three things’ Americans get wrong about everyone else

The picture most of us carry is that every other rich country runs one tax-funded system, with private insurance as a luxury on top. It is about two-thirds right, and the other third is where the argument lives.

1. Not all of them are tax funded. Germany, Austria, Belgium and, in large part, France run on compulsory contributions to sickness funds, not general taxation. Japan is statutory insurance too, employer-based or municipal, with 30 percent coinsurance and a monthly cap. The Netherlands has no public insurer at all: every resident must buy a policy from a private insurer, at a premium that cannot vary with health, plus an income-related contribution. [1] The honest sentence is “every country but the US guarantees enrollment,” not “every country but the US pays through taxes.”

2. Private insurance is four different products. In Canada it is barred from covering anything the public plan covers. In France it is nearly universal, 96 percent, and pays the co-pays; in Japan 95 percent of households hold a supplement. In Ireland (46 percent), Australia (45 percent with hospital cover), Austria (about four in ten) and the UK (12 percent) it buys a faster or more private route to the same care. In Germany, 11 percent of the population has opted out of the public system entirely. [1]

3. The United States is not the private outlier it looks like. Federal, state and local government sponsor 47 percent of US health spending. [2] In the OECD accounts, US government and compulsory spending came to $12,324 per person in 2024, which is more than the total spending per person, public and private together, of every other country on this list. [3] The American taxpayer already funds the most expensive public health system in the world. The private system sits on top of it.

On “right versus privilege,” the legal picture is narrower than the slogan. Of these fourteen, Italy, Finland and Japan put a right to health in the constitution. Sweden puts it in statute, England in the NHS Constitution, France in an entitlement called PUMa, the Netherlands in a legal duty to insure, Canada in the conditions attached to federal money. [4] Austria has no explicit constitutional right at all; a Vienna constitutional lawyer says so in as many words, and the system covers 99.9 percent of the population anyway. [5] The United States has no general right to coverage. It has EMTALA, a legal right to emergency stabilization regardless of ability to pay, [6] which explains a great deal about where the American system spends its money. We guarantee the most expensive door in the building and nothing behind it.

Question one: what does it cost?

No suspense here. The United States spent $14,823 per person in 2024 on the OECD basis, or $15,474 on our own government’s count, 18 percent of everything the country produces. [3] [2] Germany is next at $9,584, and Germany has more hospital beds per person than any country on this list except Japan, and keeps people in them. Japan, with the longest-lived population on the list, spent $5,790. Italy, third longest-lived, spent $5,337. [3] Whatever we are buying with the extra six to nine thousand dollars a head, it is not years.

Question two: is it yours by right?

Thirteen of the fourteen answer yes, and they answer it before you get sick. Enrollment is automatic or compulsory, the insurer must take you, and the premium or the tax does not depend on your health. The mechanics differ. A Swede is covered by a region, a German by a sickness fund, a Dutchman by a private insurer he was obliged to choose, a Japanese worker by his employer’s society. The result is the same: nobody in those thirteen countries walks into a hospital wondering whether they are covered. [1]

The fourteenth answers “it depends.” It depends on your employer, your age, your income, your state, and this year’s plan documents. Two-thirds of Americans hold private coverage and about a third are in a public program, and the two groups overlap and change every year. [7] The nurse in Brisbane did not have a policy view about this. She simply could not understand why a country that could build the pump she was standing next to had not settled the question.

Question three: how good is it?

This is where the American reader expects to win, and on one measure he does. The care is excellent for the people who reach it. Anyone who has watched an American ICU work knows that, and the international evidence is not shy about it either. The OECD’s PaRIS survey of 107,011 primary-care patients in nineteen systems put American respondents at 94 percent reporting good, experienced quality, near the top, and 65 percent trusting the system, above the nineteen-system average. The catch is in the sample: the American respondents were Medicare beneficiaries aged 65 and over, which is to say the one group of Americans with guaranteed coverage. The report adds, without editorial comment, that the US spends more than double per person what some countries with comparable scores spend. [8]

Take the whole population and the picture changes. The Commonwealth Fund’s Mirror, Mirror 2024 compared ten rich countries on access, equity, administrative efficiency, care process and outcomes. Australia came first, the Netherlands second, the United Kingdom third. The United States came tenth, and on administrative efficiency it shared last place with Switzerland. [9] Ipsos asks thirty countries every year whether the care “you and your family have access to” is good. In 2025 the thirty-country average was 43 percent. Australia said 64. Britain said 54, down from 73 seven years earlier, which is the largest collapse in the table and a story for another issue. Ireland said 44. [10] Satisfaction and survival turn out to be different things, and I will show you the survival numbers next.

Question four: what comes out the other end?

Two measures, and they say the same thing from opposite directions. On life expectancy at birth the United States, at 78.4 years, is between two and a half and six years behind everyone else on the list. [3] On treatable mortality, which counts deaths under 75 that timely and effective care should have prevented, the US loses 92 people per 100,000 against 74 in the United Kingdom, 63 in Germany and 46 in France. That is between 18 and 46 more deaths per 100,000 every year than a country that spends half as much. [3]

There is no standardized cross-country readmission indicator; every country defines the window and the denominator differently, and anyone who has run a readmission program knows the rate is a definition before it is an outcome. For the record, the US all-payer 30-day all-cause rate was 14.0 per 100 admissions in 2020, 17.0 for Medicare and 8.7 for the privately insured. [11] Make of that gap what you will.

One more thing the data refuse to do: sort the systems by ideology. Length of stay does not line up with public versus private. It lines up with bed supply and discharge culture, and Japan proves it. The most beds, the longest stays, an average of 25.6 days across all beds because Japanese hospitals double as long-term care, [12] the longest lives, and the second lowest spending on the list. [3] If more money and shorter stays bought outcomes, Japan would be the sick man of the group. It is the opposite.

The room was the same in fourteen countries

Now the part I did not expect when I started writing this down.

The mechanics of buying a piece of equipment differ from country to country, and they matter for how the money arrives. In the United States about 98 percent of hospitals buy through group purchasing organizations, typically two to four of them, then the deal goes through the system’s capital committee and a value analysis committee, in private, one health system at a time. [13] In the European countries on this list any public hospital purchase above about EUR 216,000 ($248,000) goes to open tender under the EU procurement directive, and the buyer is usually a region or a national purchasing body: the 21 Swedish regions, France’s UniHA buying EUR 7.7 billion ($8.8 billion) a year for 1,550 hospitals, NHS Supply Chain in England. [14] Japan is its own animal. The ministry sets a national fee schedule, repriced every two years from a survey of what hospitals actually paid, so the price of a device category is a matter of public record before the salesman arrives. [15] Someone, in every one of those thirteen countries, has the authority to say no to a price on behalf of a great many beds at once. And when they decide to say no, they mean it: two Swedish regions have just walked away from an American electronic record after spending SEK 7.3 billion ($740 million) between them. [16]

And none of that changed who was in the room. In every one of these fourteen countries the people who decided whether my equipment came in were the same four: a nurse, a biomedical engineer, someone from IT, and an administrator holding a budget that was never big enough. The clinicians had a powerful say everywhere. The departmental silos existed everywhere. The budget strain was the same shape everywhere, whether the money came from a region, a sickness fund, a ministry fee schedule or a GPO contract. The pitch was the same. The questions were the same. The arguments between nursing and IT were, word for word, the same. What differed was how many signatures the money needed and how long it took to arrive.

I had assumed, for most of my career, that the American system produced a different kind of customer. It does not. It produces the same customer with a worse deal.

Who gets to keep the difference

Every country on this list has insurers, and most of them make insurance compulsory. What differs is whether the insurer may keep the difference between what it collects and what it pays out, and what it may pay the person who runs it.

Germany’s statutory sickness funds are public-law bodies and may not make a profit. The chief executive of the largest one, Techniker Krankenkasse, was paid EUR 409,875 ($470,000) in 2025, and it made the newspapers because it was the first time the figure had passed EUR 400,000. [17] The Netherlands caps health-insurer executive pay by statute at EUR 327,000 ($375,000) for 2025, rising to EUR 366,000 ($419,000) this year; its largest insurer reports spending 98 percent of the basic premium on care. [18] Swiss basic insurance must be run without profit, and the two largest insurers paid their chief executives just under CHF 1 million ($1.2 million) each, which the Swiss federal government thinks is too much; it proposed in August to cap the job at a cabinet minister’s salary. [19] Australia’s largest private insurer, Medibank, is a listed company and made A$500.8 million ($357 million) last year; Britain’s Bupa has no shareholders and reinvests what it earns. [20]

Now the United States, 2025, from the companies’ own filings and the proxy statements they filed this spring. UnitedHealth Group, revenue $447.6 billion, net income $12.1 billion, chief executive paid $60.9 million, of which $60 million was a one-time option award on his return to the job. CVS Health, the owner of Aetna, revenue $402.1 billion, net income $1.8 billion, chief executive $21.2 million. Cigna, revenue $274.9 billion, net income $6.0 billion, chief executive $22.9 million. Elevance, revenue $199.1 billion, net income $5.7 billion, chief executive $22.6 million. [21]

Add it up and the four largest American health insurers took in $1.32 trillion in 2025, roughly 4 percent of everything the country produced, [22] passing through four companies on the way to a bedside. To be fair about the denominator, a large share of that is pharmacy and services business at CVS and at UnitedHealth’s Optum rather than premium, which is its own story about what an American insurer has become. The point is not that anyone broke a rule. It is that the other thirteen countries wrote one, and we did not.

Those four companies earned $25.6 billion of net income between them in 2025 and paid their chief executives about $127 million. Spread over 340 million Americans, [23] that is about $75 a head in profit and under 40 cents a head in executive pay, out of $15,474 a head in health spending. [2] Said that way it sounds like nothing, and an opponent will say it that way. The profit is the visible tip. The paperwork is the iceberg

On the narrow OECD definition, the cost of governing and administering the financing of health care, the United States spends 7.6 percent of its health dollars against 3.8 percent in comparable countries: $925 per person against $245. [24] Count what hospitals and doctors spend on billing as well, as Himmelstein and Woolhandler did, and American administration reaches 34 percent of health spending, $2,497 per person, against $551 in Canada. [25] Take whichever definition you like. The gap is $680 to about $1,900 for every man, woman and child, every year, and it is the one line in the budget where we buy nothing at all. Not a nurse, not a bed, not a year of anyone’s life. The insurer profit is what the system pays its owners. The administrative gap is what it pays to keep several thousand hospitals and several hundred insurers negotiating with each other, alone, one contract at a time.

And then there is the hospital

The insurer is the easy villain. The hospital is the harder one, because the hospital is where the care happens, and because an American hospital can be owned by investors and most people never notice. Of 5,121 community hospitals in the United States, 1,224 are investor-owned. Roughly one in four. [26]

Four of them are public companies and must file their numbers. In 2025, HCA Healthcare took in $75.6 billion and earned $6.784 billion. [27] Tenet Healthcare took in $21.3 billion and earned $1.407 billion. [28] Universal Health Services took in $17.4 billion and earned $1.489 billion. [29] Community Health Systems took in $12.5 billion and earned $509 million. [30] Together: $126.8 billion of revenue and $10.2 billion of profit, a net margin of about 8 percent. For a hospital, 8 percent is a very good year. For a business, it is unremarkable. Hold that thought.

The pay is less unremarkable. Tenet paid Saum Sutaria $43.1 million, of which $18 million was a one-time retention grant made in January 2025 under a contract that runs to 2028. HCA paid Sam Hazen $26.5 million. Universal Health Services paid Marc Miller $16.1 million. Community Health Systems paid Kevin Hammons $4.8 million, and he became chief executive partway through the year, so that is a part-year figure. Each company also must disclose what its median employee made, and the ratio between the two. Tenet: median $60,657, ratio 711 to 1. HCA: median $62,955, ratio 420 to 1. Universal Health Services: median $57,048, ratio 283 to 1. [31]

Read those medians again, because they are the people I have spent this whole issue describing. Sixty thousand dollars a year is the middle of the workforce at a company whose chief executive cleared forty-three million.

Now the same honest arithmetic I ran on the insurers, because it cuts the same way. Ten point two billion dollars of hospital profit, spread over 340 million Americans, [23] is about $30 a head. The four chief executives together cost about 27 cents a head. Add the insurers from the last section and you get roughly $105 per American per year in corporate profit and executive pay, out of $15,474 in health spending. [2] Under one percent. Anyone who tells you that eliminating corporate profit fixes American health care is selling something, and I am not going to help them sell it.

But here is the number the per-person arithmetic hides, and it is the one I would put in front of a hospital board. In 2025 HCA spent $10.067 billion buying back its own shares and paid another $679 million in dividends. That is $10.7 billion returned to shareholders in a year the company earned $6.8 billion. [27] The size of the profit is not the story. What the profit is for is the story. It did not become a nurse, a bed, or a night shift that was fully staffed. It became a smaller share count.

And before anyone reaches for the obvious conclusion, the profit motive is not the American disease. Germany, which beat us on every outcome in the table, has a larger share of its hospitals in private for-profit hands than we do: 729 of 1,807, four in ten, though they hold only 21 percent of the beds because they tend to be smaller. [32] German investors own German hospitals and expect a return, same as here. The difference is what they are allowed to charge. German hospital payment runs on a DRG system that applies to all hospitals irrespective of ownership, at a base rate negotiated for the whole state. [33] A for-profit hospital in Bavaria bills what the public hospital across town bills. It competes on cost, not on price. An American hospital charges what it can negotiate, and RAND found private plans paying 254 percent of Medicare rates in 2022. [34]

The question is not whether a hospital may earn a profit. Thirteen countries on this list say it may. The question is who sets the price it earns that profit on. In thirteen countries that is a public decision, made once, for everybody. Here it is a private negotiation, and the hospital has the better lawyers.

What the nurse knew

The clean version of the American argument is “social medicine versus free enterprise.” Fourteen rows do not support that frame. The US taxpayer already funds the most expensive public health system on earth; the market sits on top of it. Germany, Austria, Belgium, France, Japan and the Netherlands are not tax-funded, and the Netherlands is private insurance all the way down, yet all six land in the middle on cost and at or near the top on outcomes. Ireland and Australia run two-tier systems with roughly half the population holding private cover, and Australia ranks first of the ten in Mirror.

The line that separates the thirteen from the one is not public versus private, and it is not taxes versus premiums. It is two sentences long. Everyone is enrolled, by law, before they get sick. And somebody has the authority to say no to a price. The other thirteen also wrote rules about who may profit, on the premium and on the bed, and about what the people running those businesses may be paid. We did not, and the difference shows up as a doubling of administrative cost and an executive pay band that no other country on the list would recognize.

And the room was the same in all fourteen. That is the part that took me forty years to notice and a nurse in Brisbane one sentence to say. The nurses, the biomeds, the IT people and the administrators wanted the same things, asked the same questions, fought the same silos and ran out of the same money. The technology traveled fine. The idea that care is a right did not make the return trip.

She was right. It is nuts. And it is the most expensive nuts in the world.

About the author

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

^{Reference Notes provided on request}

INSIDE THE LOOP · No. 19

Here is a definition. Read it and tell me what it describes.

“This pitfall can be caused by allowing events or the situation to control pilot actions. A constant state of surprise at what happens next may be exhibited...”

I have cut five words off the end. Put them back and it reads: “...when the pilot is getting behind the aircraft.”

That is the Federal Aviation Administration, in the Pilot’s Handbook of Aeronautical Knowledge, listing the operational pitfalls every pilot is trained to recognize and avoid. Getting Behind the Aircraft is one of twelve, sitting in a list with get-there-itis and scud running and flying outside the envelope. [1]

Now read it again and put a nurse in it. Allowing events to control your actions. A constant state of surprise at what happens next. I spent forty years in and around intensive care and I cannot think of a better description of a bad night on a busy unit. The difference is that aviation named it, taught it, tested for it, and built a profession around avoiding it.

We call it Tuesday.

Staying ahead of the airplane

The opposite has a name too, and it is not a technical term. Pilots call it staying ahead of the airplane. It means that at any moment you already know what the next three things are, you have the frequencies loaded, the approach briefed, the fuel figured, and the alternate picked, so that when something moves you are adjusting a plan rather than inventing one.

The failure mode is task saturation, and the FAA describes it better than I could:

“The first effect of high workload is that the pilot may be working harder but accomplishing less. As workload increases, attention cannot be devoted to several tasks at one time, and the pilot may begin to focus on one item. When a pilot becomes task saturated, there is no awareness of input from various sources, so decisions may be made without complete information.” [1]

Working harder but accomplishing less. Focusing on one item. Decisions made without complete information. Show that paragraph to a charge nurse at 4 a.m. and watch her face.

Aviation formalized the discipline in the 1990s as Threat and Error Management, developed at the University of Texas by Robert Helmreich and his group and endorsed by the International Civil Aviation Organization in 1999. [2] A threat is something outside your control that raises complexity, an error is something you do that shrinks your margin, and an undesired aircraft state is where you end up if you miss both.

The FAA’s Risk Management Handbook lists the defenses against all that. I want you to read the list in order, because the order is the argument. Checklists and standard procedures. A second person. External resources. Clear communication and briefings. Situational awareness. Planning for what comes next. Time management. Teamwork. Automation management. And then, last:

“Flying Skills (The Last Resort)” [3]

Last. In a federal handbook. The individual’s skill at the controls is the bottom of a list of eleven defenses, the thing you fall back on when everything upstream has already failed.

Now consider how we tell stories about ourselves. The brilliant intensivist who catches it at three in the morning. The nurse who just knew. Every one of those is a story about the last resort, and we tell them as triumphs. Aviation writes the same story up as a near miss and asks why it got that far.

Request deviation

Here is what proactive looks like in practice, and it is unglamorous.

A line of thunderstorms is building across the route. The FAA’s thunderstorm guidance is blunt about the geometry: “Do avoid by at least 20 miles any thunderstorm identified as severe or giving an intense radar echo.” [4] Twenty miles. At cruise that is about three minutes of flying, which means the decision has to be made long before the airplane is anywhere near it.

And nobody is going to make it for you. From the same document: “Don’t assume that ATC will offer radar navigation guidance or deviations around thunderstorms.” [4] The Aeronautical Information Manual is equally direct about timing: “It is very important, therefore, that the request for deviation or radar vector be forwarded to ATC as far in advance as possible.” [5]

So the proactive pilot asks. Center, request twenty degrees left for weather. And the reason to ask early is not politeness. It is that by the time the deviation is obvious to everybody, it is also unavailable, because the airspace you wanted is already full of aircraft whose crews asked before you did.

That is the whole discipline in one transaction. See it coming. Ask for room. Get it while there is still room to get.

The instrument is not the answer, and aviation says so in writing

If you think the fix here is a better display, aviation has already been where you are going. Modern cockpits have datalink weather. A moving map, color returns, the whole picture. And the National Transportation Safety Board felt strongly enough about how pilots were using it to issue a safety alert. The capital letters are theirs, not mine:

“Weather conditions depicted on the mosaic image will ALWAYS be older than the age indicated on the display... In extreme latency and mosaic-creation scenarios, the actual age of the oldest NEXRAD data in the mosaic can EXCEED the age indication in the cockpit by 15 to 20 minutes... Remember that the in-cockpit NEXRAD display depicts where the weather WAS, not where it IS.” NTSB Safety Alert SA-017 [6]

Onboard radar has its own problem, and the FAA names it: attenuation. A heavy cell absorbs the signal and the radar simply does not see what is behind it. The industry calls the result a radar shadow. [4] You are looking at a screen that appears to show clear air on the far side of the storm, and it is showing you nothing at all.

I have been staring at that alert for a week, because it is our problem exactly.

The electronic health record shows you where the patient was. The last chemistry panel was drawn two hours ago and resulted forty minutes ago. The blood pressure on the flowsheet is a point, not a trajectory. And the first storm hides the second one: the sepsis you are treating is absorbing all the attention in the room while the bleed behind it goes undetected. Radar shadow, with a chart instead of a screen.

Aviation did not answer that by buying a better radar. It answered it by teaching pilots that the instrument lies in known ways, then building a procedure that assumes it.

Storm to storm

Is critical care actually reactive? I think we can stop arguing about it, because it is measured.

Start with the metric. The Agency for Healthcare Research and Quality defines failure to rescue as a “failure or delay in recognizing and responding to a hospitalized patient experiencing unexpected deterioration.” [7] They measure it. The national observed rate for AHRQ’s Patient Safety Indicator 4, death among surgical inpatients with serious treatable complications, is 151.17 per 1,000. [8]

Roughly fifteen out of every hundred surgical inpatients who develop a serious complication that we know how to treat die of it. Read the word treatable again. That is not a metric about disease. It is a metric about attention.

Then look at what the attention is spent on. A 2014 study of five intensive care units at the University of California, San Francisco, counted every alarm for thirty-one days: 2,558,760 of them across 77 beds, including 187 audible alarms per bed per day. Of the arrhythmia alarms the investigators annotated, 88.8 percent were false positives. [9] If a flight deck generated that, the aircraft would be grounded and somebody would lose a certificate.

And then the part that should have humbled us and did not. In 2005 the Lancet published MERIT, a cluster randomized trial of medical emergency teams across twenty-three Australian hospitals. It is the closest thing we have to a real test of whether a rapid response system makes a hospital proactive. Calls to the emergency team rose from 3.1 to 8.7 per thousand admissions. Cardiac arrests, unplanned intensive care admissions and unexpected deaths did not change. [10]

We nearly tripled the number of times somebody shouted for help, and nothing happened. Activity is not anticipation. Twenty-one years later, the Agency for Healthcare Research and Quality’s own 2024 review of rapid response systems says the evidence for them is “low due to methodological weaknesses of the studies.” [7]

What actually changed in aviation, and it was not equipment

On 27 March 1977 two Boeing 747s collided on the runway at Tenerife and 583 people died. The Spanish investigators found that the KLM captain, the airline’s chief of flight training and the man in its own advertising, began the takeoff roll without clearance. Here is the finding, and I would like every chief of service in America to read it:

“Perhaps influenced by his great prestige, making it difficult to imagine an error of this magnitude on the part of an expert pilot, both the copilot and the flight engineer made no further objections.” Subsecretaria de Aviacion Civil, Spain, 1978 [11]

Twenty-one months later, on 28 December 1978, United Airlines Flight 173 circled Portland troubleshooting a landing gear indication until it ran out of fuel and came down in a suburb, eight miles from the runway. The National Transportation Safety Board added this to the probable cause: “Contributing to the accident was the failure of the other two flight crewmembers either to fully comprehend the criticality of the fuel state or to successfully communicate their concern to the captain.” [12]

Two people in a cockpit knew. Neither could make the senior man hear it. That is not a technology problem and no amount of instrumentation was ever going to fix it.

In 1979 NASA convened a workshop called Resource Management on the Flightdeck. [13] What came out of it became Crew Resource Management, and it is now federal law: under 14 CFR 121.404 no US air carrier may use a person as a flight crew member, flight attendant or dispatcher without it. [14] The FAA’s own advisory circular on the subject, in print since 2004, states the objective in a sentence I wish somebody would tape to a hospital wall:

“CRM should become an inseparable part of the organization’s culture.” FAA Advisory Circular 120-51E, 22 January 2004 [15]

Now the honest part, because I am not going to hand you a myth. I am not telling you that Crew Resource Management produced aviation’s safety record, and you should be suspicious of anyone who does. The same forty years brought ground proximity warning systems, TCAS, glass cockpits and routine flight data monitoring. The fatal accident rate for US scheduled carriers fell from roughly 0.08 per hundred thousand flight hours in the mid-1980s to five or six thousandths by the late 2000s, with several recent years at zero, and the honest attribution is all of the above together. [16] The best formal review of CRM training, published in Human Factors in 2006, concluded that its effect on organizational safety “remains unclear.” [17]

So here is the narrower claim, and I think it is the one that survives. The technology arrived in cockpits that had been taught how to use it. Ours arrived in units that had not.

A rule is not a culture

One more aviation story, because it is the one that keeps me honest about my own industry.

On 11 September 1974 an Eastern Air Lines DC-9 descended into the trees short of Charlotte while the crew discussed politics and used cars. Seventy-two of the eighty-two people aboard died. [18] In January 1981 the FAA adopted what everyone calls the sterile cockpit rule, 14 CFR 121.542: below ten thousand feet, no conversation, no reading, no activity that is not required to fly the airplane. [19]

On 12 February 2009 a Colgan Air turboprop crashed on approach to Buffalo. Fifty people died. Among the Safety Board’s findings: the flight crew’s failure to adhere to sterile cockpit procedures, the two pilots having held what the report calls an almost continuous conversation during the descent. [20]

Twenty-eight years after the rule. A rule is what you write down while you are hoping a culture will follow. Sometimes it does not, and then you write the rule again in a different report.

We copied the paperwork

Healthcare has been importing aviation’s methods for twenty years, and the results tell you precisely what we imported.

In 2009 the New England Journal published the World Health Organization surgical safety checklist study: eight hospitals on four continents, death rate down from 1.5 percent to 0.8 percent, complications from 11.0 to 7.0. [21] Everybody read it. Ontario read it, and made the checklist mandatory across the province.

In 2014 the same journal published what happened. One hundred and one hospitals, more than two hundred thousand procedures. Mortality 0.71 percent before, 0.65 percent after. Complications 3.86 percent before, 3.82 percent after. The authors’ conclusion: “Implementation of surgical safety checklists in Ontario, Canada, was not associated with significant reductions in operative mortality or complications.” [22]

Same nineteen lines of paper. In eight hospitals that chose to change how they worked, it saved lives. Across a province that was told to use it, it did nothing measurable. The variable was never the checklist.

To be fair in both directions, the 2009 study was a before-and-after design with no control group and heavy implementation support, which is exactly the point. Compare Peter Pronovost’s Keystone work in 103 Michigan intensive care units, published in 2006: a catheter checklist inside a full unit-based safety program, median bloodstream infection rate from 2.7 per thousand catheter days to zero. [23] Same tool. Wrapped in a culture it worked. Handed down as a mandate it did not.

As for team training, the Agency for Healthcare Research and Quality owns TeamSTEPPS, Crew Resource Management’s direct descendant in American medicine. Read its own evidence page. It says the research describes implementation approaches and evaluation efforts. It does not claim the program improves patient outcomes. [24] When the agency that built it will not say that, I am not going to say it for them.

Where the analogy breaks

If I only gave you the flattering half of this I would deserve the letters I would get, so here is the strongest case against everything above.

Two intensive care physicians published a piece in Critical Care this March making the objection better than I can. Their line is: “ICU work rarely has a true cruise phase.” [25] An airliner spends hours in a low workload state with the autopilot on, which is exactly when a crew briefs the arrival and studies the weather. A nurse with five patients has no cruise. The quiet hour in which to get ahead does not exist, so telling her to get ahead is telling her to do a thing the shift does not contain.

They make a second point I cannot argue with. Aviation manages fatigue structurally, with duty time limits and mandated rest written into federal regulation. Healthcare, in their words, has protections that “remain dangerously supple.” [25]

And Richard Cook and Jens Rasmussen described the deepest version of this two decades ago. A system under relentless efficiency pressure goes, in their phrase, solid: it operates with no spare capacity at all, and a system with no slack cannot anticipate anything, because anticipation is something you do with capacity you are not currently using. [26] The intensive care unit is chronically full. The airplane is not.

So let me put the uncomfortable version on the table. Aviation did not only change its culture. It changed its labor rules, it funded the rest periods, and it built a confidential reporting system a pilot can use without ending a career. We copied the posters and skipped the payroll.

If you want the proactive posture, you have to buy the conditions that make it possible. I do not know a hospital system that has.

Which is why I built the thing I built

AI MedAgent is not a product. I want to be clear about that, because I have spent a career watching a reasonable idea get turned into a SKU about eighteen months before it was ready, and I am not doing that now.

It is a concept, running on simulated patients and synthetic data, built to ask one question honestly. If the reasoning ran continuously rather than at the moment somebody happened to look, could you see the storm far enough out to ask for the deviation while there was still room to turn?

On a simulator the answer is often yes, and I am not claiming that as a discovery. The trend was always visible. The information was in the chart the whole time. What was missing was anybody continuously looking at it, and a reason to act on a signal that has not yet become an emergency.

But the demonstration is the easy half, and I know it, because I have just spent two thousand words explaining why. A model can see the trajectory. Whether anyone is permitted to act on it at three in the morning, whether the nurse who raises it is thanked or told she is being dramatic, whether the unit has enough slack in it to turn twenty degrees left, none of that is in the software. That is the culture, and there is no version of this where technology fixes it for us.

Ahead of the airplane

Pilots got there. It took Tenerife, and Portland, and a workshop at NASA, and a federal rule, and then thirty more years of a profession slowly changing the story it told about what a good pilot is. They did not get there because somebody shipped a better radar.

And I keep coming back to that list of defenses. Eleven of them, in order, with the individual’s own skill at the controls sitting at the bottom, labeled in the regulator’s own words as the last resort. That is a profession that decided, in writing, that being ahead of the airplane matters more than being brilliant behind it.

I would like to read a sentence like that about us one day. Right now the Federal Aviation Administration has the better description of our working conditions, and it files it under pilot error.

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

References

^{1] Federal Aviation Administration, Pilot’s Handbook of Aeronautical Knowledge, FAA-H-8083-25C, Chapter 2, Aeronautical Decision-Making, 2023 edition. Operational pitfalls list and the workload management passage.}

^{[2] Merritt A, Klinect J. Defensive Flying for Pilots: An Introduction to Threat and Error Management. University of Texas Human Factors Research Project, 12 December 2006. ICAO Doc 9803, AN/761, Line Operations Safety Audit, first edition 2002.}

^{[3] Federal Aviation Administration, Risk Management Handbook, FAA-H-8083-2A, Chapter 6, Threat and Error Management, 2022 edition.}

^{[4] Federal Aviation Administration, Advisory Circular 00-24C, Thunderstorms, 19 February 2013, paragraph 10. Twenty mile avoidance, the caution not to assume ATC will offer a deviation, and radar attenuation and shadow.}

^{[5] Federal Aviation Administration, Aeronautical Information Manual, ATC In-Flight Weather Avoidance Assistance. Paragraph numbering varies by edition.}

^{[6] National Transportation Safety Board, Safety Alert SA-017, In-Cockpit NEXRAD Mosaic Imagery. Capitalization is in the original.}

^{[7] Agency for Healthcare Research and Quality, Making Healthcare Safer IV, March 2024. Failure to rescue definition, and Winters BD, Rosen M, Sharma R, Zhang A, Bass EB, Failure To Rescue: Rapid Response Systems, for the evidence grade.}

^{[8] Agency for Healthcare Research and Quality, Quality Indicators, Patient Safety Indicator Benchmark Data Tables v2024, July 2024. PSI-4, Death Rate among Surgical Inpatients with Serious Treatable Complications, national observed rate 151.17 per 1,000, computed from HCUP State Inpatient Databases 2019 to 2021.}

^{[9] Drew BJ, Harris P, Zegre-Hemsey JK, et al. Insights into the Problem of Alarm Fatigue with Physiologic Monitor Devices. PLOS ONE 2014;9(10):e110274.}

^{[10] Hillman K, Chen J, Cretikos M, et al. Introduction of the medical emergency team (MET) system: a cluster-randomised controlled trial. The Lancet 2005;365:2091-2097.}

^{[11] Subsecretaria de Aviacion Civil, Spain. Report on the collision of KLM Flight 4805 and Pan American Flight 1736 at Tenerife, 27 March 1977, as reproduced in the FAA Lessons Learned library.}

^{[12] National Transportation Safety Board, Aircraft Accident Report AAR-79-07, United Airlines Flight 173, Portland, Oregon, 28 December 1978.}

^{[13] Helmreich RL, Merritt AC, Wilhelm JA. The evolution of Crew Resource Management training in commercial aviation. International Journal of Aviation Psychology 1999;9(1):19-32.}

^{[14] 14 CFR 121.404, Crew and dispatcher resource management training.}

^{[15] Federal Aviation Administration, Advisory Circular 120-51E, Crew Resource Management Training, 22 January 2004.}

^{[16] Bureau of Transportation Statistics, National Transportation Statistics, Table 2-9, sourced to NTSB aviation accident statistics, US Part 121 fatal accidents per 100,000 flight hours.}

^{[17] Salas E, Wilson KA, Burke CS, et al. Does Crew Resource Management Training Work? An Update, an Extension, and Some Critical Needs. Human Factors 2006;48(2):392-412.}

^{[18] National Transportation Safety Board, Aircraft Accident Report AAR-75-09, Eastern Air Lines Flight 212, Charlotte, North Carolina, 11 September 1974.}

^{[19] 14 CFR 121.542, Flight crewmember duties. Adopted 19 January 1981.}

^{[20] National Transportation Safety Board, Aircraft Accident Report AAR-10/01, Colgan Air Flight 3407, Clarence Center, New York, 12 February 2009.}

^{[21] Haynes AB, Weiser TG, Berry WR, et al. A surgical safety checklist to reduce morbidity and mortality in a global population. New England Journal of Medicine 2009;360:491-499.}

^{[22] Urbach DR, Govindarajan A, Saskin R, Wilton AS, Baxter NN. Introduction of surgical safety checklists in Ontario, Canada. New England Journal of Medicine 2014;370:1029-1038.}

^{[23] Pronovost P, Needham D, Berenholtz S, et al. An intervention to decrease catheter-related bloodstream infections in the ICU. New England Journal of Medicine 2006;355:2725-2732.}

^{[24] Agency for Healthcare Research and Quality, TeamSTEPPS evidence base landing page, last reviewed July 2023.}

^{[25] Lobo-Valbuena B, Alcantara Carmona S. Beyond the pilot analogy. Critical Care 2026;30:123.}

^{[26] Cook R, Rasmussen J. Going solid: a model of system dynamics and consequences for patient safety. Quality and Safety in Health Care 2005;14(2):130-134.}

^{#PatientSafety #CriticalCare #HumanFactors #AviationSafety #HealthIT}

People ask me what it is like to retire after forty years in healthcare technology. One word: wonderful. It was a transition for sure. It is hard to step away from work that mattered, and some of mine did. I discovered how public data marts can be used for patient outcomes, helped connect wireless enabled infusion pumps to the medical record back when most people thought that was a solved problem, and AAMI was kind enough to give the write-up an award. I helped write interoperability standards that hospitals still run on. I am named on two patents and have three more provisional patents currently in-play.

This issue is different, before you get three paragraphs in and wonder what happened to the AI-in-healthcare newsletter you signed up for. I am taking an afternoon off. No interoperability, no infusion pumps, no argument with an electronic health record. Those will be back soon.

First, a word about the man writing this. I am a baby-boomer, which means I have had a front-row seat for a world changing its mind: the moon landing, solid-state electronics and the invention of the microprocessor, the iPhone, and now artificial intelligence. I will be the first to admit that seventy years of accumulated data includes a lot of useless slop. The rest, however, is irreplaceable, and I think my generation of retirees is underused for exactly that reason. I wrote a book in retirement to memorialize my own piece of it, what worked and what failed, and the best part turned out to be reconnecting with friends and colleagues from decades back. I still advise and consult in the industry I left, and I still research on my own, because like building a Tesla coil in 1964 it keeps the brain engaged. I ride my bike for cancer research with UCSD’s Curebound event. And when AI arrived and I understood it as a reasoning tool rather than a chatbot, it changed everything, because for the first time I could see a way at the problem that has bothered me my whole career: we are taught in healthcare to react to events. I want to change that, and I will have a great deal more to say about it next issue. Back to this one.

For now, the rest of the week. The honest list is ordinary. I play golf. I play pickleball, which is what golf turns into when you want to be home by lunch. I ride my bike, and we travel. And then there is the part that is harder to explain, so I will just tell you where it comes from.

A garage, around 1965

When I was a boy, our garage belonged to my brother Mike. He hand-built giant Tesla coils, with the stated goal of a homemade particle accelerator. He built amateur radios from surplus parts. And he built guitar and stereo amplifiers, from schematics, one wire at a time. I did not understand most of it. I understood that a person could sit down with a drawing and a box of parts and, some evenings later, make something work. That has never left me.

When I need to put the world down for a while, I go back there. I build hand-wired tube guitar amplifiers from that era, the way they were built then, and I let the smell of warm solder do what it does. Call it meditation with a voltmeter.

The kit

I do not build from scratch. I start with a kit and then make my own changes. The current one is a Fender Princeton Reverb, the AA1164 circuit Fender built in Fullerton starting in 1964. Leo Fender’s shop was the next town over from our garage, which I did not appreciate at the time. This build is around 12 watts, two 6V6GT power tubes, a tube-driven spring reverb and tremolo, a 10-inch speaker. Fender’s control panel calls the tremolo “vibrato.” It is tremolo. Every part is hand-wired to a steel chassis, one lead at a time, because that is how it was done in 1964 and that is how Mike did it.

What draws me to it is a sheet of paper. Fender published the entire design: the schematic, the layout, every resistor and capacitor value, and the DC voltage you should measure at each point when the amplifier is healthy, with a note across the top saying the readings may vary plus or minus 20 percent. A 1964 guitar amplifier told you everything inside it, what it should read when it was well, and how far off was still fine. I have spent a career wishing certain other devices came with a sheet like that. I promised no healthcare this issue, so I will leave it there.

The Dan modifications

A kit is a starting point. Rob Robinette, who runs the most generous free amplifier site on the internet, publishes a layout of suggested changes to the AA1164, and I used it as my map. On top of that I made two changes of my own.

The first was grid stopper resistors on the tubes, a small part that keeps the amplifier from oscillating at frequencies only dogs and oscilloscopes can hear. The second is the one I care about, and it needs one sentence of explanation. Bias is the idle setting on a tube, the same idea as the idle on a car engine: a small steady voltage that sets how hard the tube works when no one is playing. Set it too hot and the tube runs itself into an early grave. Set it too cold and the amp sounds thin and harsh. The original circuit fixes that idle with a single resistor and calls it done. I replaced it with an adjustable one, a potentiometer, a pot to anyone who has ever turned a volume knob, and mounted it so I can reach it without pulling the chassis out of the cabinet. Every manufacturer’s 6V6 has its own personality, and every pair needs its own bias to sound right and live long. So, I swap power tubes the way other people swap guitar strings, bias each set, and write the numbers in a notebook.

Three hundred and sixty-eight volts at 20.6 milliamps. Multiply them and you get about 7.6 watts of heat at the tube’s plate, idling. The current datasheets rate a 6V6 at 14 watts; the 1940s sheets said 12. The rule of thumb is to idle at no more than 70 percent of the rating, and I am sitting somewhere between 55 and 65 percent depending on which sheet you believe. I did not take the kit’s word for it. I measured. Mike would have measured.

The crackle

A while after one of my builds, the amplifier developed a crackle. Intermittent, which is the worst kind, because an intermittent fault is never there when you are looking at it. I put the scope on it, then the meter, and then I did what I did in 1965. I called my brother. Two Pettuses and a Fluke found it in the preamp: a cold solder joint, a connection that looked fine and was not. Reflow one joint and the crackle was gone. Sixty years on, same brother, same bench, same lesson. The drawing tells you what should be there. The instrument tells you what is.

I do not play guitar

I should admit this before someone asks to hear the amp. I own a Fender Stratocaster and a Fender Jazz Bass for the same reason a mechanic takes the car around the block: it is how I find out whether the thing I built works. I attempt to play bass, with the emphasis on attempt. What I play, nearly every day, is drums.

Two bass drums, tuned not to match

I am a trained drummer and have been since I was eight. My first professional kit was a Rogers, bought in 1967 with two bass drums, back when Rogers built them in Dayton, Ohio and sold a factory twin-bass outfit with Louie Bellson’s name on it. I have been rebuilding that kit ever since, the way some men keep buying the same car. Today it is a Roland V-Drums set with the new V51 module, and I modify every electronic kit I own to look like 1967: two separate bass drums, the snare between them, and one more floor tom than a reasonable person needs.

The two bass drums are tuned not to match, on purpose. Ginger Baker taught me that, and not from a record. I was lucky enough to grow up when the legends played within driving distance, and I saw Cream several times around Los Angeles and Hollywood. The best of them was the Shrine, with my best friend and fellow drummer Rik. The ticket was $3. Ginger’s kit carried a 22-inch drum under the left foot and a 20 under the right, wide open and pitched apart so the two feet spoke as two voices, which is what he had heard in African drumming long before he drove a Range Rover across the Sahara to go play with Fela Kuti. In heavy metal the fashion runs the other way: tune both drums the same so two feet sound like one very fast drum. Neither is wrong. The style tells you the tuning.

Jazz got into me early enough that in retirement I wrote a play about it, a one-act set in 1948 New York with a live band written into the script as a character. It is called A Song Is Born, it lives at a-song-is-born.com, and it has gone exactly nowhere, which has not stopped me liking it.

An afternoon in Bonham’s chair

Last February our community’s music club gave me an afternoon to tell the rock drummer’s story from the 1970s to today, studio and stage. I brought the e-kit, a PA, and a screen full of pictures.

We started with the Wrecking Crew, which most of the room had never heard of, and neither have most of you, and that is the point. They were a loose group of Los Angeles session musicians who, through the 1960s and into the 70s, played on more hit records than any band you can name and almost never got credit on the sleeve. Hal Blaine on drums. Carol Kaye on bass. A young Glen Campbell on guitar before anyone knew his name. Leon Russell on keys. When you hear Good Vibrations, Be My Baby, Bridge Over Troubled Water, Strangers in the Night or the Monkees’ theme, you are hearing them. I spent some hours in those same Hollywood studios myself, cutting demo tapes for local garage bands, close enough to the real thing to know exactly how far away I was.

And I did something I could not have done five years ago. Software can now take a finished stereo recording and pull it back apart into its instruments, drums here, bass there, vocals on their own, as if someone had handed you the original multitrack tape from 1971. I ran the originals through it, pulled the drum tracks out, and dropped the rest into Logic Pro, which is the recording studio that now lives inside a Mac: the tape machine, the mixing desk and the effects rack of 1975, in one window. Then I sat in the chair. Bonham’s chair on Stairway to Heaven. Ginger Baker’s on White Room. Mick Fleetwood’s on Dreams. Mitch Mitchell’s on Fire. Jonathan “Sugarfoot” Moffett on Billie Jean. And Steve Smith’s on Don’t Stop Believin’, which a right-handed drummer like me must play open-handed, left hand leading, and which I would not recommend trying in front of people the first time.

For the finale I told the room something I had been a little sheepish about. Late last year I released a seven-song album, every note of it generated with AI from prompts I wrote, under my own name. It was an experiment, and the results are remarkable, and I will be the first to say what is missing: it is artificial. No human emotion, and no human mistakes, which turn out to be the same thing. It was educational to see how far AI has gone in a completely different direction from the one I work in, reasoning over critically ill patients, where a mistake is not a style.

What I learned is simple, and it is the reason I said yes to the afternoon. The machine separated the stems in seconds, cleaner than any studio could have done with a razor blade and a week. It wrote an album, of sorts, in a couple of days. What it could not do was the thing the whole talk was about. Technology has changed everything about how music gets made, the tape, the machines, the room, and one thing has not moved an inch: the human being at the center of it. I watched a ballroom full of people lean forward when the groove landed, and no software did that. Time is the drummer’s whole job. You cannot fake time. You can only keep it. And when a machine keeps it perfectly, something is missing, and everyone in the room can hear what it is.

That, in one sentence, is also how I feel about the AI I use for my current experiments in healthcare, and for AI MedAgent. It does the reasoning. It does it fast and it does it well. The concept, the vision, the reach, and the judgment about what is worth building still come from a person in a chair. I promised not to overdo that here, so that is all I will say.

Back soon

The amplifier is warm. Mike is a phone call away. Nobody told me retirement would sound like this, and I would not trade it.

Next issue, back to health technology, and it picks up something I said at the top of this one. Airline pilots have a phrase for the discipline that critical care does not have: staying ahead of the airplane. The FAA also has a name for the failure, and when you read its definition you will think somebody was describing a bad night in an intensive care unit. Next time: what aviation learned about asking for a deviation long before the storm, why the fix was never the equipment, and why I built AI MedAgent to make that argument rather than sell anything. Until then, thank you for letting me take the afternoon off.

^{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.}

^{The serious version of the day job is a book. The Technology Was Never the Problem: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.}

^{AI MedAgent is a research demonstration of a patent-pending method. Advisory only. Not a medical device. Not for clinical use. Simulated patients, synthetic data only. aimedagent.net}

^{#Retirement #TubeAmps #Drums #MakerLife #HealthIT}

I spent forty years connecting medical devices to hospital records, and I helped write some of the standards that do it. So I want to say something that will sound strange coming from me. The plumbing was never the point.

In 2013 the West Health Institute measured what medical device interoperability was worth and put the number above thirty billion dollars a year [1]. That number was real then and it is real now. But it measured the pipe. The larger prize was never the connection itself. It is the data that moves through the connection once it exists, joined to the public knowledge the country already paid to build, carried in a common language all the way back to the UMLS, and reasoned over while the patient is still in the bed. In critical care, where the sickest patients throw off the most data and the least of it is used to look forward, that prize is almost entirely unclaimed.

I have written that argument up as a white paper. Seventeen pages, in the style of the West paper I admire, and free. It is not an article. It is meant to be handed to a CMIO, a pharmacy director, a pump vendor, or a standards committee, and to survive the person in the room who checks the numbers. So every number in it is cited to its primary source, an appendix lists each one and where it came from, and the two places where I am giving you my read rather than a sourced fact say so in plain words.

What it argues, in one paragraph. About 88 percent of US hospitals run smart pumps and somewhere between 9 and 15 percent have the pump talking to the record, thirty years into the effort. Closing that gap is worth doing and worth West’s thirty billion. But a hospital that has finished the plumbing and done nothing further has built a very reliable way to fill in a flowsheet. The value is in joining the patient’s live stream to the public knowledge, the FDA labels, the adverse event reports, the terminologies, through the common language that already exists, and reasoning over it forward, before a slow harm becomes an obvious one, then handing what it finds, with its evidence, to a human who can act. Two ordinary bedside cases show what changes. In both, the pipe did its job and the value was still left on the table.

The PDF is attached below. The permanent home, with a citable DOI, is pettusbook.com/plumbing. Share the link anywhere you like. If you find a number that does not hold, tell me, and I will publish the correction rather than quietly fix it.

Whitepaper Plumbing Was Never The Problemsept2026

292KB ∙ PDF file

Download

Interoperability was the pipe. The value is the data that flows through it, joined to the public knowledge the country already built, carried in a common language back to the Unified Medical Language System, and reasoned over at the bedside, while the patient is still in the bed.

Download

It is the companion to my book, The Technology Was Never the Problem. The book says the technology was never the barrier. The paper says the plumbing was never the point. Same spine, next chapter.

Dan

^{[1] West Health Institute. The Value of Medical Device Interoperability: Improving Patient Care with More Than $30 Billion in Annual Health Care Savings. March 2013. All other figures are sourced in the paper itself, references 1 through 13.}

INSIDE THE LOOP · No. 17 · FOR SUBSCRIBERS

A note for the people who fund this work. The last few issues were free. This one is for you, because it is the honest story behind the project, the part I keep out of the public posts. Thank you for making it possible to keep going.

I am retired. I could be doing almost anything else with my evenings. Instead, most nights, I am at a keyboard building something I give away for free, and if you asked me for the business reason, I would not have one. Let me tell you how that happened, because I have come to believe the why matters more than the what.

It started as a small idea. In critical care, the sickest patients throw off a flood of data, and nearly all of it is used to record what already happened. I wanted to see whether a machine could read the public medical data, the drug labels, the adverse event reports, the guidelines any of us can download, and reason forward instead of backward. Not to replace a clinician. To hand one a proactive second look, before a slow harm turned into an obvious one. That was the whole idea. Read the open data, reason toward a safer next step.

Read more

A short one, between the regular issues. The next full issue is on its way. I wanted to get this into your hands now, because it is live and it is free.

Every hospital that turns on pump auto-programming spends weeks in a room with a pharmacist, a nurse, and a spreadsheet. They reconcile the formulary line by line, so the drug a physician orders is the same drug, at the same concentration, in the same units, that the pump will accept. Miss one line and the order will not program, and the dose limits quietly stay off.

I have argued for years that this is a data problem, not a technology problem. Four systems have to say the same thing about the same drug: the order, the pharmacy label, the formulary, and the pump library. When they disagree, nobody is wrong on purpose. The mismatch just sits there until a go-live finds it, or until a patient does.

So I built something that finds the mismatches in a few seconds. It is called One Formulary. You drop in a continuous-infusion formulary, a CSV or a spreadsheet, and it checks every row against the national standard concentrations, the ISMP smart pump guidance, and the order-to-pump rules. Twenty-six checks across names, concentrations, units, limits, and order sentences. It shows you exactly where two systems that must agree do not, and it cites the published rule behind each finding. It never recommends a dose. It is an alignment check, not clinical advice, and it says so on the page.

It runs entirely in your browser. Nothing is uploaded, there is no account, and there is no cost. It is open source under the Apache license, so you can read every rule and feedback is encouraged.

The part that bothers me is simple. The standards it checks against have been public for years. The reconciliation it does in seconds is the single most time-consuming step of every pump integration I have watched. A retired engineer built this in a few weeks. The companies that sell the pumps could have handed the same thing to every customer a decade ago, at no cost. They did not, so I did.

Run it on a real formulary and tell me what you find. If it flags something it should not, or misses something it should catch, I want to hear it. The rules are open, and they are meant to be argued with. That is the point.

There is more, and this next part is aimed squarely at the people who build the pumps.

Library Match takes an aligned formulary and checks it against your drug library, the set of dose limits the pump actually enforces. Every maker builds that library differently and exports it differently, so the tool assumes no one format. You map your own export onto a short, neutral set of columns, and it tells you, care area by care area, which entries will auto-program with the dose limits on and which will drop to a manual infusion with none, and why. That reconciliation is the step that eats months at every install.

Then there is the handshake. A third view walks the whole path an order takes: the CPOE order sentence, the formulary, the drug library, and the actual messages that carry the order to the pump and bring the pump’s answer back, built on the published IHE and HL7 standards. It is a plain, working demonstration of what full auto-programming interoperability looks like, end to end.

None of it is proprietary to anyone. It is built on standards that have been public for years. Take a look, and do it better. I will retire the whole thing the day one of you ships something that makes it unnecessary.

Start here · https://aimedagent.net/one-formulary.html

Library Match · https://aimedagent.net/library-match.html

The full handshake · https://aimedagent.net/close-the-loop.html

#InfusionPumps #MedicationSafety #Pharmacy #HealthIT #Interoperability #ISMP #Baxter #BD #Alaris #ICUMedical #BBraun

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two US patents. He is the author of The Technology Was Never the Problem, available in paperback and Kindle, and the builder of the AI MedAgent research demonstration at aimedagent.net, where One Formulary is free and open source. Advisory only. Not a medical device. Not clinical decision support.

Substack added a button this summer. Any reader can press it and get a number: how much of what you just read was written by a machine. Press it on this newsletter and you get 100 percent. Fully AI. I am not going to argue with it. The number is correct.

I write about medical device data and hospital IT. I spent forty years in it. I am also, by my own honest measure, a poor writer. The ideas arrive fine. Getting them onto a page that someone wants to finish is a different skill, and it is not mine. So I use AI to do the writing, the way I would hand a draft to an editor who never sleeps and never tires of my sentences. Every fact in here I checked myself. Every claim is mine. I read it, corrected it, and signed it. The machine did the typing. It did not do the thinking.

That distinction is the whole point, and I can prove it with the thing I built.

The idea came first

A while back I sat down and drew a straw man. Not on a computer. On paper. The question I was chasing was easy to say and hard to do: why does critical care wait for a patient to crash before it reacts? A rising potassium, a falling kidney function, a new drug stacked on two others that push the same direction. The signals are already there, in systems that already exist, hours before anyone gets paged. Nothing reads them together. Nothing looks ahead.

So I sketched something that would. Pull a patient’s data from the places it already lives. Put it into one clean stream. Reason over it looking forward instead of back. Then hand a plain warning to the person who can act. Four steps. I have argued for years that healthcare is not a technology problem, it is a data problem, and this was the shape of an answer.

Every part of that, the concept, the method, the goal, the first ugly drawing, was mine. A machine does not wake up wanting to catch a dangerous potassium before it happens. A person who has spent a career watching the misses does.

What the machine did

This is where AI earned its place. I gave it my specifications, and it built to them. It wrote an interactive website. It wrote the reasoning code that reads a patient forward instead of back. It wrote the cloud code that reaches out to public health data, which sits at the base of my invention and the patents I filed. It wrote the documentation, including the datasheets that are open and downloadable at aimedagent.net, so anyone can read the concept and judge it for themselves. Every piece was built to my specs, checked at every step, and corrected when it was wrong, and it was wrong plenty.

What that bought me was time. Building this the old way, alone, would have taken a year or more of coding and testing before I had anything to show. It was live in weeks. I did not save a little time. I skipped past the part that used to stop retired people like me from ever testing an idea, and landed at the part that matters: does the thing actually work.

Watch it work

Look at the screen at the top of this post. One case is running on the site right now.

A simulated 78-year-old woman. Septic shock, kidneys failing, on a ventilator and three drugs. Her potassium is 5.0 and creeping up. A new order arrives for spironolactone, which happens to raise potassium, on top of an ACE inhibitor she is already taking that does the same. Three forces, one direction, in a patient who cannot afford it.

An ordinary monitor waits. It alarms when the potassium crosses a red line, which is to say after the problem has already arrived. My system flags it while the number is still climbing and writes the clinician a short note in plain English: the trajectory, the reason, the options. Reactive medicine waits for the crash. This looks down the road and taps you on the shoulder before you get there.

What it is, and what it is not

I want to be careful about what I am claiming. That patient is simulated, and the screen says so in plain sight. The system connects to test copies of hospital software, not to a real medical record, and it is not cleared to treat anyone. It is a proof of concept, running live, that a person can open and try. It is not running on a single real patient, and I built that honesty into the product on purpose. The idea is strong enough that it does not need to be oversold.

The person has to drive

None of this is hands-off. AI will hand you a wrong answer with complete confidence and a straight face. It does not know when it is out of its depth. The person in the chair has to know enough to catch the bad answer and throw it out. Point it carelessly and you get carelessly wrong results, delivered beautifully. The tool is only as good as the judgment steering it, and mine came from forty years of being in the room.

Why I am telling you

I believe in this enough that I filed three provisional patents this summer, in my own name, without a lawyer. Not because a machine had a good idea, but because I did, and the machine let me build it fast enough to find out I was right.

People are worried about where AI is taking us. They should be. It is still worth seeing clearly what the tool actually is when someone who knows their field drives it. It is not the author. It is the fastest, most tireless assistant ever made, and it will do great good or real harm depending entirely on who is holding it. The rules for all of this are not written yet. I found a way to use it that let a retired engineer turn a paper sketch into a working system in weeks, and it has changed everything I do.

So yes, a machine wrote this. I built the thing it is about. Read it anyway.

I will keep posting, with AI as my editor. Every idea, every concept, every claim is mine, and I check every fact before it goes out. I just cannot say it as clearly as my editor can. If you scan this and it says AI, that is the typing, not the thinking. More on the way.

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two US patents. He is the author of The Technology Was Never the Problem, available in paperback and Kindle, and the builder of the AI MedAgent research demonstration at aimedagent.net. Advisory only. Not a medical device. Patient shown is synthetic

INSIDE THE LOOP · ISSUE 15

As of this week anybody can run AI MedAgent. No access code, no form, no email to me. There is one catch, and it belongs at the top: every live run costs me money, real money, paid to a cloud AI company out of a retired engineer’s pocket. So instead of a gate there is now a daily allowance, 150 runs a day and six to a visitor, and when it is used the page says so in plain words and labels anything it shows after that as a note written in advance, not generated live.

The last part matters. The one time a screen of mine pretended, it pretended to me. The first version of this demonstration displayed traffic to the public data sources that was not happening, and said in text that it was live. I believed it for three days. I pulled it, rebuilt it, and wrote a chapter about it.[1] Nothing on the site pretends any more. Every alert now shows the federal data it read, with the date of the data and the exact web address that produced it, so you can open a second tab and check me. That is why the gate had to go.

The hypothesis, in one paragraph

A large language model, reasoning continuously over a patient’s live data and the free federal reference layer, can see a trajectory before any threshold is crossed and say so, once, in time to change the therapy. It can hold the whole picture, the numbers and the sentences and the timing, and ask the question nobody wrote down in advance: is what we are doing for this person still the right thing to be doing? And it can do that at a marginal cost close to nothing, because the knowledge is public and the reasoning is a commodity. That is the claim. It is testable rather than proven, and the site exists so that people can test it.

Where it came from

Not from a lab. From the book, and from the forty years underneath it. My industry spent those years getting very good at two things: acquiring data from machines and making one system’s words mean the same as another’s. We called those two things the whole job. In 1989 I sat in a hospital cafeteria and watched a resident get his Saturdays back from a ten-second query against data that had been sitting unread for years. In 2001 a woman typed my feet hurt today into a system I helped build and it sat in a text field, in her own words, for years, because nothing in the building could be curious about it. The machine that could read it did not exist at any price.

Then it did, and it came from outside medicine. So I went to work the only way a retired man can: at a desk at home, with a cloud model, a credit card, and the public data marts the taxpayer built and gives away. RxNorm for what a drug is. openFDA for what has gone wrong with it across the population. DailyMed for the approved label. ClinicalTrials.gov for what is being studied.[2] All free, all machine readable, all ignored by an industry whose picture of clinical knowledge is shaped by the products that have salespeople.

Why this is not the AI you have been reading about

Three kinds of medical AI have earned their headlines this year. All three are valuable and I hope all three keep going. The first reads the chart and writes the summary, so the physician does not spend the evening typing. The second is the chat in the office or on your phone, which answers the question you asked. The third reads the image and finds the cells a tired eye would miss. Good, good, and good.

They share a shape. Each one is asked. Each one answers about something that has already happened, or a question already formed. Each one answers once. Every one of them is a superb version of the thing my industry has always built: a machine that responds when a human turns to it.

AI MedAgent is the other shape. Nobody asks it anything. It reads the stream continuously, every few minutes, all night, at the same level of attention on the two hundredth pass as on the first. It is not looking at what happened; it is looking at what is happening and where it is heading. It reasons against the largest clinical reference library in the world, which is public. It projects: at this trajectory, on these drugs, with this kidney function, is the therapy still right, and if not, what is the smallest change worth making now. And it is judged on its silence as much as its speech. A threshold alarm has no basis for silence; it only has a basis for noise. A system that holds the whole picture can look at a patient at three in the morning and conclude that everything is consistent, and say nothing, and that silence is a finding.

Not a chat. A colleague who never leaves the room and rarely speaks.

How it grew

It started with a synthetic patient and real reasoning. The patient was invented and labeled as such on every screen; the reasoning was generated live over the values on the screen and the federal sources. That proved the method was doable and credible, which was the scope I had set myself, and it proved nothing about a real hospital.

So the next step was the chart. This summer, from a laptop, with no hospital relationship, I connected to the developer sandboxes of Epic, Oracle Health and MEDITECH over FHIR, the standard interface federal certification requires every certified vendor to expose.[3] Those are vendor test records, not real patients, and I say so wherever the results appear. What came back was an education. Getting in was three completely different jobs, one under an hour, one a day, one waiting on a human being to answer an email. One vendor lists in writing which resources a key opens and then does not open two of them, and the refusal arrives with nothing attached. And the data itself: a pulse of 1, a temperature of 47.5 degrees Celsius, a patient who lost 37.6 kilograms in a single second, every one of them stored and served back without complaint. That is why the engine now reports, on every single call, how many of the eight standard medication checks it was actually able to perform. On one certified record the answer was two.[4]

The chart, it turned out, is only half of the patient. It says who this is and what was ordered. It cannot say what the infusion pump did between the moments somebody looked, or that a channel went to keep-vein-open, or what the ventilator was set to at 2:14. No open requirement covers that data; the device standards exist and are thinly adopted, and after two decades of asking manufacturers to change regulated products nothing is coming. So rather than wait, I built the receiving end. There is now a public inbound endpoint that accepts infusion pump and ventilator data, either as the HL7 messages a device gateway already emits or as a five-minute summary in plain JSON, mints its own key with nothing but an organization name, and returns a conformance report on what it received. The specification is open, free and unencumbered, and if it takes a team more than an afternoon to implement, I have written it wrong.[5]

And so that the reasoning can land where a decision is made rather than on a page of mine, the engine also answers as a CDS Hooks service, the published mechanism by which an electronic record calls out to an outside service at the moment an order is selected. Anyone can verify that endpoint from a browser without asking permission.[6]

Why the gate went

The access code was never about protecting anything. It was about the meter. A demonstration that queries a cloud model on every alert costs a few cents an encounter, which is nothing until a link leaks and the nothing starts to multiply. So I put a code on the door and a form behind it, and then I watched what a form does to a reader who arrived from a link with thirty seconds of curiosity. It ends the visit. I had built a gate to save pennies and it was costing me the only thing the site is for, which is a stranger seeing the method run.

So the gate is gone and the meter is capped instead, twice: a hard spend limit at the cloud provider that no traffic can exceed, and the daily allowance on the site that tells you when it is reached. When the allowance is used, you will see a red notice, and every note after it will carry the words validated note, not live. I would rather you see less and know exactly what you are seeing.

What I would like you to do

Go to aimedagent.net and press Start. When the encounter pauses, read the advisory, then read the gray panel under it. That panel is the federal evidence the reasoning used: the drug class from RxNorm, the top reported reactions from the FDA with the report counts and the data date, whether the label is on file, how many trials are registered. Click any of the source links and compare the numbers in the other tab. Then read the line that says how many checks it could not perform, because that line is the half of the design I am proudest of.

If you work near an operating room, watch this space; the next case I am building runs during a procedure, where the clinician already reasons in real time and is busiest at exactly the moments that matter.

The technology was never the problem. The gate was, and it is gone.

_References

_{[1] Pettus D. The Technology Was Never the Problem. Inside the Loop Press, 2026. Chapter 21, “It Said It Was Live.”}

_{[2] RxNorm, National Library of Medicine, nlm.nih.gov/research/umls/rxnorm. openFDA, U.S. Food and Drug Administration, open.fda.gov. DailyMed, National Library of Medicine, dailymed.nlm.nih.gov. ClinicalTrials.gov Data API, National Library of Medicine, clinicaltrials.gov/data-api/api.}

_{[3] 45 CFR 170.315(g)(10), “Standardized API for patient and population services,” adopted in the ONC 21st Century Cures Act Final Rule, 85 FR 25642, 1 May 2020. ecfr.gov.}

_{[4] AI MedAgent EHR Integration Datasheet, v0.3, 25 August 2026, and “The connection was the easy part,” 25 August 2026, both at aimedagent.net/docs.html, with every request and response recorded.}

_{[5] PCD-E Sandbox Ingest Specification, v0.4, 31 August 2026, aimedagent.net/epoch. Built on IHE Devices Technical Framework Rev 10.0 (Final Text, 4 November 2024) and ISO/IEEE 11073-10101:2020.}

_{[6] HL7 CDS Hooks specification, cds-hooks.hl7.org. Service discovery for this demonstration at aimedagent.net/cds-services.}

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two US patents. He is the author of The Technology Was Never the Problem, available in paperback and Kindle, and the builder of the AI MedAgent research demonstration at aimedagent.net. Advisory only. Not a medical device. Patient shown is synthetic.

From midnight (PDT) tonight through Sunday the sixth, the Kindle edition of The Technology Was Never the Problem is free. No catch, nothing to sign up for, and you do not need a Kindle device, because the app reads it on a phone.

Get it free on Amazon

The book opens with an infusion pump set to deliver 28.8 milliliters an hour. The number should have been 1.2. Three weeks later Denise Melanson was dead of fluorouracil toxicity.

I spent forty years building the machines that were supposed to prevent that. Brain monitors in operating rooms. Anesthesia records in Vienna. A box on a kitchen counter that read twenty one different glucose meters. Infusion pumps wired into the hospital records I helped write the standards for.

Every one of them worked exactly as designed. Almost none of them changed what happened to patients, and it took me until I retired to work out why.

That is the argument. The book is the honest version of it, written by somebody who signed off on the compromises rather than somebody studying them from the outside. Chapter 22 is my own list of everything still wrong with the demonstration I built to prove the last part of it.

Why give it away. Because a first book nobody has read is a manuscript with an ISBN on it. If you have been reading these letters and wondered whether the longer version is worth an evening, this is the cheapest possible way to find out. It costs you nothing and it costs me nothing, which makes it a fair trade.

Five days. Then it goes back to $9.99 and I will not bring it up again for a while.

Normal service Monday.

Get it free on Amazon

Dan

INSIDE THE LOOP · ISSUE 14

The problem, before anything else

A nurse who walks past a bed can see the patient. Software cannot see anything. It only knows what it is handed.

So, every argument about whether artificial intelligence can help in critical care collapses into a plumbing question that almost nobody finds interesting: what is the software allowed to receive, and how often. Everything else is downstream of that.

I have spent two issues describing the plumbing, and several of you have told me, fairly, that I went too far down the pipe. So, this one starts where it should have started. Here is the problem. Here is why it reaches a patient. Here is what I did about it.

Why any of this: reasoning is not chatting

Nearly everything written about AI in medicine so far describes a conversation. A clinician types a question and gets an answer back. That is useful and I am not dismissing it.

It is also not what a patient in an intensive care unit needs, because a patient in an intensive care unit is not asking anything.

What that patient needs is something watching. Continuously. Not answering questions but forming and revising an opinion, minute by minute, about whether the therapy currently running is doing what somebody hoped it would do.

That is a different machine entirely. A chat model waits to be asked. A reasoning engine is never not thinking, and the quality of its thinking is capped, absolutely and without appeal, by the freshness and completeness of whatever arrives at its input.

Which is why I keep writing about pipes.

What continuous reasoning has to be told

Four things. None of them exotic.

• Who the patient is. Diagnoses, allergies, weight, and the laboratory results, which are doing more work here than the phrase suggests. Creatinine says what the kidneys will do with the drug. Lactate says whether the tissue is getting oxygen. Potassium says whether the heart is about to misbehave. A blood gas says whether the ventilator is helping.

• What was ordered. The drug, the dose, the route, the intent behind it.

• What was actually given. Not the order. The delivery.

• What the patient did in response, and when. Heart rate, blood pressure, oxygen saturation, what the ventilator was doing while it happened.

You would expect the first two to be easy and the last two to be hard. That is roughly right, and the line does not fall where almost anybody would draw it.

The half that opened

To explain why the chart is reachable I must explain two acronyms. I will be quick. If you already know them, skip four paragraphs and no harm done.

HL7 is the language hospital software uses to talk to itself. The organization was founded in 1987, and the version most hospitals still run, version 2, works like a fax. A machine sends a message whether or not anybody is ready for it. If the receiving system was not listening at that moment, the message is gone. You cannot ask it a question. It only pushes.

FHIR, pronounced “fire,” is the same organization’s modern design, and the change is much simpler than the jargon built around it. Instead of a message you must catch as it flies past, FHIR gives you an address. You ask for the patient’s medication list, and it comes back, right now, in a structure software can read.

Push versus pull. That is the whole distinction, and it decides what a piece of software is capable of knowing.

Then, in May 2020, the federal agency that certifies electronic health records turned that design into an obligation. The regulation is 45 CFR 170.315(g)(10). It requires a certified electronic health record to expose a standardized FHIR interface, release 4, so that an outside application can be authorized to read a patient’s record. The compliance deadline was 31 December 2022. Miss it and you lose certification, and losing certification means losing the customer.

One line of regulation. A hard date. A consequence that lands on the vendor rather than the hospital.

That is why, this summer, from a kitchen table, with no hospital, no contract, no funding and no introductions, I connected a reasoning demonstration to live patient records at Epic, Oracle Health and MEDITECH. Fifteen years ago the idea would have been laughable. It took a laptop and an afternoon, and in MEDITECH’s case a form and some patience. None of the three asked me for money.

Regulation does not get much affection in my industry. This one worked.

And it carries the labs. Laboratory is one of the data classes the rule names, so a certified record has to hand over the creatinine and the lactate and the blood gas through the same door as everything else, coded in LOINC, a vocabulary the Regenstrief Institute has given away free and in perpetuity for thirty years. Tell me in 2005 that an unaffiliated outsider would read a patient’s potassium out of three major health records in an afternoon and I would not have believed you.

And the line is not where you would draw it

Here is where my own framing needed correcting, and the corrected version is sharper.

For two issues I have been saying chart on one side, bedside on the other. That is wrong, and a reader who works in this field would catch it. Pulse oximetry is in the rule. So is inhaled oxygen concentration. Both are produced by machines, and both are federally required to be available through that same interface. Plenty of device data comes out.

The real line is written in one sentence of federal regulation, and it is worth reading slowly. Under 45 CFR 171.102, electronic health information means protected health information “to the extent that it would be included in a designated record set.” The designated record set is the legal medical record. That is the whole test.

What lands in the legal record is open. What stays in the machine is not.

A potassium gets charted, so you can have it. A saturation gets charted once an hour, so you can have that one number. The reading the monitor took thirty seconds later is not in the record, so there is nothing to be entitled to. The ventilator’s setting history is not in the record. The pump’s event log is not in the record. None of it was ever written down anywhere a rule could reach.

The half that did not

Which brings us to the third row, and to the infusion pump.

There is no equivalent rule. Not a weaker one. Not a delayed one. There is no rule.

The federal regulation governing infusion pumps, 21 CFR 880.5725, describes what the device is and says nothing whatsoever about a data interface. FDA published final guidance on interoperable medical devices in September 2017, and in section VI.F that guidance states, in its own words, that “conformance with recognized consensus standards is voluntary for a medical device manufacturer,” and that “manufacturers may choose to use their own design preferences for their interface (in lieu of a published consensus standard).”

Read that twice. The federal government requires a chart vendor to open a standard door, and explicitly permits a device vendor to build whatever door it likes, or none.

I am not calling that corrupt. It is a coherent position with real arguments behind it. But it produces a specific outcome, and the outcome is that my demonstration can read that a physician ordered vancomycin and cannot read whether the pump delivered it, paused, ran at keep-vein-open for forty minutes, or was switched to a secondary line.

It can see what was intended. It cannot see what occurred.

And before anybody suggests the answer is simply to chart it, note what the rule actually covers. The required data set includes the medication, the dose and the units. It does not include the administration. Medication administration, the record of what was given and when it was given, is not in the version of the standard the law currently requires. It appears for the first time in a draft version that has not been adopted. So even the charted version of what the pump did has no federal obligation behind it.

I spent forty years building the machines on the wrong side of that gap, which is either qualification or penance depending on the day.

One more thing about the open half, because it is not as open as it looks

I went and read what a certified record is actually obliged to hand over for a lab result, and the answer surprised me enough that I checked it twice, in two versions of the specification.

You get the value. You get one time attached to it. What you do not get, as a guaranteed matter, is when the blood was drawn or when the result came back.

The field that carries result-available time is not a required element. The field that carries specimen collection time is not a required element either. And the data element called laboratory results date and timestamps is sitting in the candidate list, not the adopted one. Specimen collection date and time does not appear in the required set until a draft version that has not been adopted.

In an intensive care unit that gap has a name, and the name is turnaround time. A potassium drawn at 03:12 and resulted at 04:47 is a different fact from a potassium drawn at 04:40. One of them tells you where the patient is now. The other tells you where the patient was an hour ago, and treating the second as the first is how people get hurt.

Which is the same failure as Goldman’s slide, only on the half of the record everybody assumes is solved. The door is open. What comes through it still cannot reliably tell you when it happened.

Access: TBD

Here I have to correct myself, because last issue I overstated this and several readers wrote in to say so.

I wrote that there was no endpoint anywhere that would tell software what a pump had been doing for the last five minutes. There is tooling and some of it is very good. Dräger publishes two open source projects, one of them still actively maintained this year. OpenICE came out of the MD PnP program at Massachusetts General. VSCapture names the ventilators and pumps it supports out loud. The people who built these did the work and the industry mostly ignored them, so let the record show they exist.

Every one of them is something you download and run on your own machine. Not one of them is an address you can point a device at.

That distinction sounded small to me too, once. It is the whole thing. A download serves somebody who already has the device, the network, a spare machine and a free week. An address serves a stranger with five minutes.

And there was exactly one address. NIST built it, and the IHE device connectathon test tool is the only thing that has ever spoken the infusion and monitoring profiles at a public hostname. Generations of pump engineers tested against it.

NIST is sunsetting its entire Health IT Program. On the page documenting where each tool goes, updated 21 July 2026, the entry for the device tool reads: transition to IHE, in discussion. New tool URL, blank. Access, TBD. Timeline, TBD. The two hostnames that actually received device messages no longer resolve.

NIST did nothing wrong here. A program ended and the people running it published a transition plan and a consent window, which is more diligence than most sunsets get. IHE may well pick it up, and “in discussion” is not “abandoned.”

While I was in there I looked up the connectivity standard that governs the analyzers themselves, the blood gas and bedside chemistry machines that produce a good share of the numbers above. It is a document published in July 2006. Its own standards body has formally archived it as no longer under review. There is no second edition after it and no third edition at all. It costs money to read. And the FDA re-recognized it as a consensus standard in May of last year.

But as of this morning, the answer to “where do I send a device message to find out whether it means anything to anybody” is a blank field on a government transition page.

So I put one up

Rather than write a third essay about the gap, I built the missing address and pointed the request the other way round.

It is inbound only, and that single decision drives everything else. A vendor sends what its gateway already emits to an EMR today. Nothing to build, nothing to expose, no new surface added to a regulated product. One command generates a synthetic five-minute window and sends it, and it needs no device, no account and no email to me.

What comes back is not an echo. It is a summary of the window, and the difference matters more than it sounds.

Last issue I used a slide of Julian Goldman’s: a monitor showed 84 percent oxygen saturation at 14:07 and alarmed, and the anesthesia record for that same period shows an unbroken normal line. His caption was two words, sampling error. A five-minute point sample reproduces that failure exactly, because the event happened between samples. A five-minute summary that carries the minimum value and the timestamp of the minimum does not, and it costs four extra numbers.

One finding from the build I will give away, because it matters more than my sandbox does. The standard profile that carries infusion events requires exactly three of them: delivery started, delivery stopped, delivery complete. A rate change is not an event. A switch back from a secondary line is not an event. Going to keep-vein-open is not an event. Those are three of the states a clinician most needs in order to read a pump record honestly, and every one of them has to be guessed at from periodic readings. The detail is on the site.

The protocol detail, the message formats and the working client all live on the site, and I have deliberately kept them off this page. Links are at the bottom, and none of them asks you for anything.

What this is a step toward

AI MedAgent has changed shape roughly every six weeks this year, and looking back the sequence was not random even though it did not feel planned at the time.

It began as a method and a concept, now patent pending under a US provisional application filed this year. Then a simulated demonstration, to see whether continuous reasoning over a critical care picture produced anything a clinician would recognize. Then a connection to the public federal data marts, so the reasoning would be checked against something other than my opinion: FAERS, the FDA adverse event system, held 20,692,690 reports when I queried it this month, alongside RxNorm and DailyMed for drug identity and labeling and more than 600,000 registered studies at ClinicalTrials.gov. Then live chart connectivity at three electronic health record vendors. And now an open test bed for infusion and ventilator data.

Each step exists to prove or disprove one hypothesis, so I will state it plainly and you can hold me to it.

With continuous data at its input and access to the public health data marts for grounding, an AI reasoning engine can take the first useful step toward proactive prediction of therapy in critical care.

I do not know that it can. That is what a hypothesis is. What I do know is that it cannot be tested at all while half the inputs are unreachable, and that has been true for twenty-two years while everybody agreed it was a problem.

My hope is that some version of this eventually becomes a standard, tested in real clinical studies, measured against real outcomes. That is a long way off and it is not mine to declare. First things first: access to the data, and an open front door for the half of it that never had one.

The old door came off its hinges in July. I would be glad to take mine down the day somebody puts that access field back to something other than TBD.

Until then it is up, it is free, and nobody has to ask me for permission.

Learn more or test live

• Test it live. aimedagent.net/sandbox.html mints your own key and sends a synthetic five-minute window. No approval step, no form, nobody to email, including me.

• Read before you send. aimedagent.net/device returns the capability statement as JSON and needs no key at all. It tells you both doors, the limits and exactly what is logged.

• The argument in full. aimedagent.net/epoch.html is the proposal this sandbox came out of: why a summary of a window rather than a sample of it, with the evidence behind it.

• Every document. aimedagent.net/docs.html has the ingest specification, the reference client and the datasheets.

• Buying pumps this year? aimedagent.net/pump.html is a free scoring sheet for pump and gateway connectivity on a hospital network. Sixty-three criteria, my own, built to establish what questions to ask before the contract rather than after. Adjacent to this article rather than part of it.

_{Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He writes Inside the Loop at insidetheloopdp.substack.com.
Everything in this issue is one chapter of a longer argument. The Technology Was Never the Problem is that argument in full: forty years of trying to connect medical devices, what actually stopped it, and why the answer was never engineering. Paperback and ebook at pettusbook.com.
AI MedAgent is a research demonstration. Advisory only. Not a medical device. Not for clinical use.}

References

^{[1] 45 CFR 170.315(g)(10), the standardized API certification criterion, requires a certified health record to respond to requests for a patient’s data according to the standards adopted at 45 CFR 170.213 and 170.215. ONC Cures Act Final Rule, 85 FR 25642, published 1 May 2020. The compliance deadline was 31 December 2022 under 45 CFR 170.404. Read 30 August 2026. https://www.ecfr.gov/current/title-45/section-170.315 and https://www.ecfr.gov/current/title-45/section-170.404}

^{[2] The data set the rule points at is the United States Core Data for Interoperability, adopted at 45 CFR 170.213. Two versions are currently adopted: USCDI v1, which expired 1 January 2026, and USCDI v3, which has not. USCDI v3 is what is operative. https://www.ecfr.gov/current/title-45/section-170.213 and https://isp.healthit.gov/united-states-core-data-interoperability-uscdi}

^{[3] The FHIR standards required alongside it are adopted at 45 CFR 170.215: FHIR release 4.0.1, US Core implementation guide STU 6.1.0, and SMART App Launch 2.0.0. US Core STU 3.1.1 expired 1 January 2026. https://www.ecfr.gov/current/title-45/section-170.215}

^{[4] HL7 International, the body behind both HL7 version 2 and FHIR, was founded in 1987. https://www.hl7.org/about/index.cfm}

^{[5] Laboratory is a USCDI data class. Its v3 elements are Tests, Values and Results, Specimen Type and Result Status. The corresponding FHIR artifact is the US Core Laboratory Result Observation Profile, which is a SHALL in the US Core server capability statement, with the observation category fixed to laboratory and the test code bound to LOINC. Read 30 August 2026. https://isp.healthit.gov/uscdi-data-class/laboratory and https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-observation-lab.html}

^{[6] LOINC is published by the Regenstrief Institute and licensed at no cost worldwide in perpetuity, with attribution. Version 2.83 was released 19 August 2026 and Regenstrief described the collection as more than 109,000 concepts at the previous release. LOINC is adopted in the certification rule at 45 CFR 170.207(c)(1). https://loinc.org/license/ and https://loinc.org/downloads/}

^{[7] Epic, Oracle Health and MEDITECH connections were made by the author between June and August 2026 using developer sandbox programs open to any registrant. No hospital, no contract, no fee. Oracle Health documents an unauthenticated open endpoint that returns laboratory observations; Epic publishes its capability statement without authentication but requires a registered client to read data. https://fhir.epic.com/ and https://docs.oracle.com/en/industries/health/millennium-platform-apis/mfrap/op-observation-get.html}

^{[8] The rule about what is reachable is 45 CFR 171.102, which defines electronic health information as electronic protected health information “to the extent that it would be included in a designated record set” as defined at 45 CFR 164.501. Read 30 August 2026. https://www.ecfr.gov/current/title-45/section-171.102}

^{[9] Vital Signs is also a USCDI data class, and its elements include Pulse Oximetry and Inhaled Oxygen Concentration, each bound to LOINC and UCUM. This is why a flat claim that device data is not reachable would be wrong. The corresponding profile constrains a vital sign to one numeric value with one unit and one time, and does not require the record to say which device produced it. https://isp.healthit.gov/uscdi-data-class/vital-signs and https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-vital-signs.html}

^{[10] 21 CFR 880.5725 is the classification regulation for the infusion pump. It describes what the device is and contains no data interface requirement of any kind. https://www.ecfr.gov/current/title-21/section-880.5725}

^{[11] FDA, “Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices,” final guidance, September 2017. Section VI.F, page 12, quoted verbatim from the guidance PDF on 30 August 2026: “Conformance with recognized consensus standards is voluntary for a medical device manufacturer,” and “Alternatively, manufacturers may choose to use their own design preferences for their interface (in lieu of a published consensus standard) for their medical devices.” https://www.fda.gov/media/95636/download}

^{[12] Medication administration is not in the version of USCDI the rule currently requires. The v3 Medications class covers Medications, Dose, Dose Unit of Measure, Indication and Fill Status. Medication administration elements first appear in draft USCDI v7 and are not adopted. https://isp.healthit.gov/uscdi-data-class/medications}

^{[13] On lab timing: in US Core STU 6.1.0, the element carrying result-available time is not a must-support element, and the element carrying specimen collection time is not must-support in the specimen profile either. Checked again in STU 8.0.1 with the same result. The USCDI element “laboratory results: date and timestamps” is a level 0 candidate, not adopted, and specimen collection date and time first appears in draft v7. The only guaranteed result-available timestamp is on the diagnostic report, at panel rather than analyte granularity. Read 30 August 2026. https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-specimen.html and https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-diagnosticreport-lab.html}

^{[14] The open source device tooling referred to is SDCcc and sdc11073, both from Dräger, OpenICE from the MD PnP program at Massachusetts General Hospital, and VSCapture. All are downloads rather than hosted services. Verified 28 August 2026. https://github.com/Draegerwerk/SDCcc and https://www.openice.info/}

^{[15] NIST is sunsetting its Health IT Program. The disposition page for the IHE device connectathon tool, updated 21 July 2026, records the transition as “Transition to IHE (In discussion)” with the new tool URL blank, access TBD and timeline TBD. The account and data migration consent window ran 24 June to 31 July 2026. The two hostnames that received device messages, ihe-pcd-con.nist.gov and ihe-pcd-precon.nist.gov, both return NXDOMAIN. Verified 28 August 2026.}

^{[16] The point of care connectivity standard is CLSI POCT01-A2, “Point-of-Care Connectivity; Approved Standard, Second Edition,” published 28 July 2006. CLSI lists it as archived and no longer under review. There is no third edition. It is a paid document. FDA recognizes it as a consensus standard, recognition number 7-335, recognition date 26 May 2025. https://clsi.org/shop/standards/poct01/}

^{[17] The infusion event profile referred to is Infusion Pump Event Communication in the IHE Devices technical framework. Its required event set is delivery start, delivery stop and delivery complete. It carries no rate change, no secondary to primary switchover and no transition to keep-vein-open. The table often cited as settling how to infer them is headed “Clinical Scenarios” and is not normative. Verified against the supplement on 29 August 2026. https://www.ihe.net/resources/technical_frameworks/}

^{[18] The 84 percent oxygen saturation at 14:07 with an unremarkable anesthesia record for the same period is Julian Goldman’s slide, presented in 2016. His caption was “sampling error.”}

^{[19] Federal data marts named in the closing section, queried 30 August 2026: the FDA adverse event reporting system held 20,692,690 reports, last updated 30 July 2026; ClinicalTrials.gov held more than 600,000 registered studies; RxNorm and DailyMed are cited without counts because no single authoritative figure is published for either. https://open.fda.gov/apis/drug/event/ and https://clinicaltrials.gov/}

^{[20] AI MedAgent is patent pending under a United States provisional application filed in 2026. It is a research demonstration, advisory only, not a medical device, and not for clinical use.5 CFR 170.315(g)(10), “Standardized API for patient and population services.” ONC Cures Act Final Rule, 85 FR 25642, published 1 May 2020. Compliance deadline 31 December 2022 per 45 CFR 170.404. Required standards: FHIR release 4 (4.0.1), US Core 6.1.0, SMART App Launch 2.0.0.}

My brother Michael got one of the first paperbacks. He wrote to say that he and a friend were both having trouble reading it. Light grey, low contrast, hard on older eyes.

He was right, and it was not his eyes.

The body text in the first printing was not black. It was set to 90% black.

On a screen, 90% black and 100% black are indistinguishable. That is not a figure of speech. I looked at that file for weeks, ran it through a proof review, and approved a printed proof, and at no point did anything on my display tell me the text was not black. The difference is invisible until it reaches a press.

On a print-on-demand press it is not invisible at all. Anything that is not solid black gets broken into a halftone dot pattern rather than laid down as solid toner. At ten and a half point on cream paper, that reads exactly as Michael described it.

It was not the ink. The file told the press to print 90% black, and the press did precisely what it was told. The figure captions were worse than the body text, at 73 to 75% black in eight and a half point type.

Measured off the actual file at 400 dots per inch, the darkest pixel in the body text never got below 90% black. Corrected, it reaches true black, and ink density improves by 39%.

It is fixed as of 30 August, on both Amazon and Ingram. Every copy printed from here carries the corrected interior.

If you bought a copy in the first two weeks and you are finding it hard to read, write to me and I will replace it. No proof of purchase, no argument, no form. Just tell me where to send it.

I will not pretend this is not funny. I have written a book about an industry that keeps shipping things which technically work, checked against instruments that cannot see the failure, by people who had no reason to doubt what they were looking at. Then I shipped one.

The part worth keeping is not the defect. It is that exactly one person told me. Everybody else who noticed would have read it slightly annoyed, or assumed their eyes were going, and said nothing.

That is the whole argument of the book, and it took nine days for my own object to demonstrate it.

Thank you, Mike.

Dan

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He is the author of The Technology Was Never the Problem, at pettusbook.com, which is about this subject and how forty years of it actually went. AI MedAgent is a research demonstration. Advisory only. Not a medical device. Not for clinical use.

Update, 28 August 2026

A correction to the infusion event section below, found while researching the follow-up.

I wrote that rate change, secondary-to-primary switchover and transition to keep-vein-open are three states that “IHE’s own infusion event profile does not carry, and that a reader currently has to infer from periodic observations.” I finished with “nobody has ever asked it to say so.”

The first half is half right. The last sentence is wrong.

IPEC has no dedicated event type for any of the three, and that much holds. It does not need one. The supplement specifies each transition as an ordered pair of the three required delivery events, with the clinical meaning carried in the pump status and mode attributes. A rate change is a stop followed by a start. A transition to keep-vein-open is a completion followed by a start in KVO status. A secondary finishing and the primary resuming is a completion in piggyback mode followed by a start in nominal mode. It is in Table X.1.2.1-3 of the IPEC supplement, revision 1.4, published in 2014. No inference from periodic observations is required.

And somebody did ask. BD and Baxter both publish IHE integration statements claiming IPEC conformance. I spent part of my career at the first of those, on the system that did it, and I should have remembered that before writing the sentence.

What survives is sharper than what I wrote. Delivery Stop does not mean the infusion stopped. It fires on a rate change, a secondary start, a bolus, a VTBI change and a delayed start. A receiver that reads it as an ending is wrong more often than it is right, and it is wrong silently. The meaning is in the attributes, and knowing which attribute to read takes a mapping table that does not travel with the message.

INSIDE THE LOOP · ISSUE 13

This one is free. No paywall, no email required, nothing behind it. Read on.

Two numbers

At 14:07 a patient monitor showed an oxygen saturation of 84 percent. It alarmed. A clinician was standing there.

The anesthesia record for that same five minutes shows an unbroken line of normal saturation.

That is not my case. It is a slide Julian Goldman put in front of an audience in 2016, and his caption on it is two words: sampling error. The monitor knew. The record did not. Nothing was broken and nothing warned anybody, because the record was built to store a reading every so often and the event happened in between.

I have been carrying that slide around for a while. This month I finally went and found out why, twenty-two years after this problem was named, nothing has fixed it.

The part that worked

This summer I connected a reasoning demonstration to live records at Epic, Oracle Health and MEDITECH. Epic and Oracle took a laptop and an afternoon. MEDITECH took a form, a welcome packet, a license agreement and a wait. None of the three took money, and none of them required a hospital, a contract, or knowing anybody.

That is remarkable and almost nobody says so. Fifteen years ago the idea that an unaffiliated retired person could read a structured patient record from the three largest electronic health record companies in the country, from a kitchen table, would have been absurd. It happened because of one line of federal regulation, 45 CFR 170.315(g)(10), with a compliance deadline of 31 December 2022. Meet it or lose certification. Over 95 percent of certified developers complied.

The part that did not

Now try the other half. There is no endpoint, anywhere, at any price, that will tell a piece of software what an infusion pump has been doing for the last five minutes in a form it can reason over. Not a hard endpoint. Not an expensive one. Not a slow one. There is no endpoint.

My demonstration can read that a physician ordered vancomycin. It cannot read whether the pump delivered it, paused, ran at keep-vein-open for forty minutes, or was switched to a secondary line. It can see what was intended. It cannot see what occurred.

Any continuous reasoning system needs four things: what was ordered, what was given, what the patient did in response, and when each happened. The first two are in the chart. The second two are only at the bedside.

This is not a complaint about my own project. Every serious continuous-reasoning system now being built for critical care arrives at the same wall, and most of them are being built by people with far more money than me.

Why it never got fixed, in one table

The tempting answer is that the economic case was never made. It was, and finding the paper that made it was the most useful hour of the month.

In March 2013 the West Health Institute in La Jolla published a study putting the annual addressable waste from the lack of medical device interoperability at 36 billion dollars. On the day it came out, their chief medical officer testified to the House Energy and Commerce Subcommittee on Health and the paper went into the record. FDA still links to it today, calling it the business case for medical device interoperability.

It failed anyway. The reason is in the same paper, in a figure almost nobody quotes.

Ninety-three percent of the benefit accrues to providers. Zero percent accrues to the device manufacturers who were being asked to build it. That is not a failure of persuasion. It is an accounting identity, and no amount of further advocacy was ever going to move it.

West Health left the field in 2015. Their site today is about aging and healthcare affordability, and device interoperability appears nowhere in its nine initiatives. The 2013 paper is still on their server. Every internal link to it is gone.

What I am proposing, and the one correction that makes it work

A five-minute summary from the gateway that manufacturers already ship. Not a stream, which nobody wants to carry. Not a sample, which brings me back to Goldman’s slide.

A five-minute point sample reproduces his failure exactly. It misses every event shorter than the interval, which is most of the events worth reasoning about. A five-minute summary does not. Per metric: the count of samples the device actually took, the minimum and the timestamp of the minimum, the maximum and its timestamp, the first value, the last value, and the mean. Seven or eight numbers where a one-hertz stream would have produced three hundred.

Under that scheme Goldman’s missing de-saturation is not missing. It is a minimum of 84 with a timestamp of 14:07 inside an otherwise unremarkable epoch, and any engine reading the record can see both the excursion and the fact that the patient recovered. Roughly a forty-fold reduction in volume that increases rather than decreases what a reader can conclude.

And one thing nobody currently carries: a context block. What else did the device know about itself during that interval? Sensor attached or detached. Cuff cycling on the same limb. Service or calibration mode. Channel switched from primary to secondary. Transition to keep-vein-open.

Look hard at those last two. Rate change, secondary-to-primary switchover and transition to keep-vein-open are precisely the three infusion states that IHE’s own infusion event profile does not carry, and that a reader currently has to infer from periodic observations. The pump knows all three. Nobody has ever asked it to say so.

Then it stops asking

Everything above still asks a manufacturer to build something. Twenty-two years of history says any ask of a manufacturer, however small, does not get answered.

So turn it around. I build the receiver. A public endpoint, the schema published beside it, an API key by email, and a standing invitation to every pump, ventilator and monitor manufacturer to point a simulator at it. Not a product. Not a hospital. Not a patient. The output of the test rig already sitting on their integration bench.

The ask collapses from “implement a profile and ship it” to “POST a JSON body to a URL with one header.” An engineer can try it on a Friday afternoon without telling anybody, and that clause is not a joke. Every path this field has offered for twenty-two years required a public commitment: join a consortium, sign the procurement language, register a system for a Connectathon, ballot a profile. A test endpoint requires none.

What it costs is the part that should embarrass all of us. Twenty participants sending one bundle every five minutes is about five dollars a month. Registering one system for the IHE North America Connectathon last published at 8,500 Canadian dollars, plus 2,000 per participant per week, in person, once a year. A year of the endpoint costs less than two minutes of that. The reason this was never built is not cost, and has not been for at least a decade.

Three things that did not survive checking

Nobody works at the front of a field without this happening, and a field where it never happens to anybody is a field where nothing is being attempted. All three are in the memorandum with the evidence attached.

• The premise I started from was that Goldman had given up and the program was dead. He has not and it is not. He won the 2026 J.S. Gravenstein Award, and in February 2025 he was named principal investigator on an ARPA-H award of up to 20.8 million dollars. The confusion is real and it is the program’s own fault: there are two websites and the abandoned one ranks first.

• A five-minute interval looked like it might sit outside FDA’s definition of a device function. It does not. FDA reissued its clinical decision support guidance on 29 January 2026 and the language now reads “continuous, near-continuous, or otherwise streaming measurement.” One of its own worked examples is hourly pulse oximetry read out of an EHR, and FDA calls that a device function. The epoch does not escape it, and the memorandum says so.

• A lapsed domain belonging to one of the dead organizations was reported here as pointing at an offshore gambling site. It points at a village hall in Oxfordshire. Fixed, and dated in the text, because it will move again.

The part I would like you to argue with

The memorandum is twenty pages, thirty-seven sources, and every claim in it was checked directly this month rather than taken from the literature. It is free, there is no paywall on it either, and it is at aimedagent.net/epoch .

One claim in it I would especially like tested. I searched 135,000 lines of OpenICE, the field’s reference open-source interoperability platform, for any code that computes a summary over a window of time. There is none. Not deprecated, not half-built. Absent. If prior art exists for an interval-summary device interface and my search missed it, now is the useful time to say so, before I put it in front of a standards body.

Corrections get published with the name of whoever caught it. That is how the Epic finding in my last issue got fixed, and the person who caught that one asked exactly one good question.

Daniel Pettus spent forty years in medical device and health IT leadership at Alaris, CareFusion and BD, contributed to IHE Patient Care Device interoperability standards, and is named on two United States patents. He is the author of The Technology Was Never the Problem, at pettusbook.com, which is about this subject and how forty years of it actually went. AI MedAgent is a research demonstration. Advisory only. Not a medical device. Not for clinical use.