Not an interface developer? The same findings are written without the acronyms in The connection was the easy part, six pages, no prior knowledge assumed. It explains what a 403 is, why an empty refusal is worse than a rude one, and what the vendors’ own demonstration patients actually contain.

What this document adds

The AI MedAgent technical datasheet describes the method. This one answers the question every evaluator asks within ten minutes: can it reach the chart. It now answers it with measurements rather than with capability statements, because the two turned out to disagree in ways that matter.

It sets out what three EHR vendors will actually hand a third party, what each one costs to reach, what arrived when we asked, and the second question that follows immediately: the chart is not a live stream, so where does continuous infusion and ventilator status come from.

The integration, in one picture

What each vendor costs to reach

This is the first thing anyone building on top of an EHR needs and the last thing anyone publishes. The three vendors sit in three different tiers, and the difference is not technical.

Correction, 24 August 2026. An earlier version of this sheet said Epic refuses four of seven resource types. That was wrong. Of the four 403s, only Condition and AllergyIntolerance had their scopes granted; Procedure, Immunization and DocumentReference were never requested, and DiagnosticReport was granted and served. Two is the correct number and it is still the finding. The error was found because a reader on chat.fhir.org asked whether the Patient read also returned 403. It does not: Patient, Observation, Encounter, MedicationRequest and DiagnosticReport all returned data for the same patient on the same token.

MEDITECH row measured 24 August 2026 against the live Greenfield Workspace, patient Sarai Mccall, 321 resources returned by a single Patient/$everything call. No fee is stated in the published EULA. Every figure in this row was read from the sandbox, not from the documentation.

What the APIs actually returned

Published capability statements say what a server supports. They do not say what it will give you. Those are different questions and only one of them can be answered by reading documentation.

Read the MEDITECH column carefully too, for the opposite reason. Those figures are small because they are one real-shaped chart read in full, not a volume generator. The whole column came back in a single Patient/$everything call, 321 resources, and the bundle carried no next link, so nothing is truncated and no figure in that column is a paging cutoff. It is the only one of the four columns where the count and the total are the same number. MEDITECH is also the only server of the three that offered $everything at all.

Read the Oracle column carefully. Four of those figures are where the loader stopped paging at twenty pages, not how many records exist, and they are marked. More exist and were not read. Oracle answers Condition freely to an unauthenticated request, established by probe, but the bulk pull skipped it because Oracle ignores _count on that resource and the response runs to megabytes. A truncation point printed as a total is the same class of false statement this document is about, so it is not printed as one.

What arrived when we asked, and why it matters more than the count

An integration datasheet that only covers how to connect is half a document. The other half is what comes back, and in both certified sandboxes what came back would break a naive reader.

• A patient losing 37.6 kg in one second. Oracle's densest hour holds 26 weights ranging 45.359 to 88.904 kg. At 16:02:44 she weighs 87.543 kg and at 16:02:45 she weighs 49.895 kg. Across the whole record, 63% of the weights are an exact whole number of pounds, and the rest are round kilograms. No scale reads 64.000 kg. These are numbers typed into a test form.
• A negative potassium. 224 observations coded LOINC 2823-3, "Potassium [Moles/volume] in Serum or Plasma", carrying the unit g/dL, with eight values between −1.1 and −0.2. The code says molar concentration and the unit says mass per volume. Seven more of the same code carry mmol/L correctly.
• Forty-nine impossible vital signs in one Oracle record. A pulse of 1 bpm and a blood pressure of 1 over 1 on the same date, an oral temperature of 47.5 °C, and one temperature stamped 7 July 2099.
• Epic fails the opposite way. Its densest hour is 32 observations that are the same four values filed seven times in eight minutes: temperature 37, pulse 72, height 175 cm, weight 72.5 kg. Height re-measured every 45 seconds. Zero variance.
• The synthetic record has none of it. Zero impossible values and zero negatives across 7,766 laboratory results, because a generator does not fat-finger a decimal point. An empty result there is a fact about the source, not a clean bill of health.

None of this is a criticism of a test environment, which is what a test environment is for. It is the reason the integrity screen runs before any clinical content and prints its findings above the clinical section rather than in a footnote. A system that calculates perfectly and understands nothing averages a 37 kg swing into a trend line and hands a clinician a number.

Every figure above is reproducible from the saved records and the loaders in this repository. A reference-range check catches none of them: 45 kg and 89 kg are both plausible weights and 37 °C is a normal temperature. What fails is the rate of change, the variance, and the sign.

How the integration works

• 1. Authenticate, however the vendor requires. Epic takes a SMART Backend Services client assertion signed with a private key, exchanged for an access token, with no human in the loop and no password anywhere. Oracle's open sandbox takes nothing at all. MEDITECH issues an OAuth2 client ID and secret after a signed agreement. The reader absorbs the difference so that nothing downstream sees it.
• 2. Read the record and normalize it. Patient, Encounter, Observation, MedicationRequest, Condition and AllergyIntolerance, reshaped into one structure and canonicalized on LOINC. Vendors disagree about display text and agree about codes, so the codes are what the engine trusts.
• 3. Screen the data before reasoning over it. Impossibility bounds per LOINC code, unit-aware, with a bound applied only when the unit matches and a mismatch reported instead. Checking a value against a bound written for a different unit invents findings, so it is refused.
• 4. Screen the medications. Eight classes, named against Wolters Kluwer's published Medi-Span module list so the coverage figure is measured against a vendor's own taxonomy rather than one of our own.
• 5. Reason, live. AI MedAgent Reasoning runs inside the CDS Hooks endpoint, after the deterministic screen and before the cards are written, and is handed the coverage statement so that it knows which classes did not run. A model reasoning without knowing its own blind spots writes confident prose over a hole.
• 6. Surface it where the decision is made. A CDS Hooks card on order-select, which fires after the clinician picks an order and before signing. CDS Hooks is a published HL7 standard and a service is an HTTPS endpoint, so building one requires nobody's permission and the same engine answers any EHR that speaks it.

What is built, what is proposed, what is unverified

The other gap: where the live device data comes from

Everything above concerns the chart. The method reasons over a stream, and two of the signals it needs are not in any FHIR surface measured here: continuous infusion status and ventilator status. Epic’s documented route for infusion pump data remains an HL7 v2 flowsheet interface with row mapping negotiated per customer, and no vendor read for this document exposes a channel-level infusion state through FHIR, which is a custom build at the customer’s expense and delivers a flowsheet summary rather than a live channel state.

The standards do not close this gap either, and the detail matters. Citations are to the IHE Devices Technical Framework Rev. 10.0, Final Text, 4 November 2024. The domain was renamed from Patient Care Device, which is why transaction identifiers keep the PCD prefix.

• IPEC does not carry what a reader needs. Its required event set is three delivery milestones: Delivery Start, Delivery Stop, Delivery Complete. There is no rate change event, no secondary-to-primary switchover event and no transition-to-KVO event. Those three are precisely the states a clinician, or a reasoning engine, must have in order to interpret an infusion record.
• DEC carries periodic observation, which is the right shape, but there is no standard subscription. Communicate PCD Data [PCD-01] is the reporting transaction. PCD-02 reads “Reserved” in DEV TF-2 Rev. 10.0. Subscription is specified only in the Subscribe to Patient Data supplement, Trial Implementation since 2007 and never promoted.
• The FHIR device path is not a published standard. The HL7 Point-of-Care Device implementation guide builds on the same ISO/IEEE 11073 information model, but it has never been published. The current artifact is a continuous build carrying “not an authorized publication”. It is buildable and it is not citable as conformance.

What the reasoning engine needs from a device cloud

Read only. Advisory only. No control path of any kind is requested, offered or implied.

Terminology. ISO/IEEE 11073-10101 nomenclature with the Rosetta Terminology Mapping value set, whose use is required in IHE DEV profiles per DEV TF-1 section 2.6, and UCUM for units. No specific MDC codes are asserted in this document. Codes look memorable and are easy to recall almost correctly, and an almost-correct code is worse than a missing one because it validates. Every code would be looked up in the published tables and agreed in writing before use.

What any such interface has to get right

These are not integration details. Each one is a way the record becomes wrong while every system reports success.

• KVO is still infusing. A pump in keep-vein-open mode delivers at a rate that has nothing to do with the order. Charting it as the administration rate misrepresents the therapy.
• A secondary pauses the primary. Treating them as concurrent double counts volume. Treating them as one channel loses the drug identity. Both are common.
• A bolus from a running container is not a new infusion. Modeling it as one corrupts the volume record and the event sequence together.
• The drug library does not travel in the message. Dose limits live in the pump, versioned per care area, and nothing in a transaction tells the receiver which version was in force.
• Patient identity binding is explicitly out of scope of the framework. The DEV Technical Framework says so plainly, which means the specification will not save anyone here. Wrong-patient association of an infusion record is among the worst outcomes in this domain, and how association is done has to be answered before anything else.

A device cloud API that handles those five is worth more than one that merely exists, and none of them is solved by choosing a transport.

What this is not

This is not a partnership with, an endorsement by, or a listed application of Epic, Oracle Health or MEDITECH. None of them certifies, endorses or verifies third-party applications, and Epic says so plainly. It is not a product, not a pilot, and not a medical device. It is a demonstration that a method already shown to work on a simulated encounter can be fed by a real chart, built so that a licensee can evaluate the integration path instead of being asked to take it on faith.

Patent and provenance

Patent pending. The method is the subject of US provisional patent applications filed in 2026. It continues one long thread of the same idea: real-time reasoning over a live physiological signal (a processed-EEG algorithm, 1986), population-scale medical-terminology reasoning (UMLS on the MediCompass platform, 2003), and now language-model reasoning over the live medication context.