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.