← Back to blog

· Lex Hamilton

What Changed at Orinyx, and the Feedback Behind Each Change

Orinyx now serves the people who build healthcare AI agents. The free Orinyx MCP opens October 29. Here is what it checks, what it does not, and which failures and feedback changed its design.

Last reviewed: October 2026

Orinyx now builds for the people who write healthcare AI agents: developers shipping agents that produce medication orders or claims, and healthcare consultants who build agents for their clients. Hospitals are no longer the first buyer. The first product is the free Orinyx MCP, which opens on Thursday, October 29, 2026. It checks an agent's medication orders and claims against cited FDA label text with fixed rules, on synthetic data only. No language model decides a verdict.

A disclosure before anything else: I'm Lex Hamilton, and I build Orinyx. This is the builder's account of what changed and why, including the failures that forced the changes. Read it with that interest in mind.

Table of contents

Who is Orinyx for now?

Orinyx now serves developers building healthcare AI agents and the consultants who build those agents for clients. It began as an independent safety layer pitched to hospital leadership, the chief medical information officers and quality leaders who sign off on clinical AI, and most of this blog was written for them.

The argument has not changed. When the system that produces a clinical claim is also the system that checks it, you have a self-assessment, and a self-assessment is a different thing from a check. That is the case made in why an AI system can't audit its own output, and it is the reason Orinyx has no clinical AI product of its own.

What changed is where the check sits. An agent's medication output can be tested long before a hospital sees it, by the person writing the agent, on every change they make. So the free Orinyx MCP is built for that person. A paid Orinyx API for organizations comes after launch. It has no published price, and this post names none.

Hospitals still shape the design, because that is where an agent's output finally lands in front of a clinician. The rule that governs every result is the same one it always was: Orinyx flags; the clinician decides.

What does the free Orinyx MCP check?

The Orinyx MCP checks each medication order or claim an agent produces against FDA label text and names the label section it checked against. The Model Context Protocol, or MCP, is a standard way for an AI application to connect to outside tools and data (modelcontextprotocol.io). The Orinyx MCP is a server that speaks it, so an agent can call Orinyx the way it calls any other tool.

The reference text is FDA's: drug labeling published in Structured Product Labeling format and served through openFDA, plus FDA's over-the-counter monographs for products such as acetaminophen. Each result cites the section it used.

Two tools do most of the work. verify_order_text takes orders exactly as written, and Orinyx splits each one into dose, route and frequency claims with a fixed grammar. verify_medications takes structured claims. It runs on your machine over stdio, or as a hosted connector with sign-in, in Claude Code, Claude Desktop, Cursor or any MCP host.

The limits apply to everyone who uses it. Synthetic data only: never send real patient records, names, dates or record numbers. There is no EHR connection, because the MCP talks only to the Orinyx API. And Orinyx makes no clinical decision. A supported claim agrees with the cited label text, which is not a judgment that the order suits a patient.

What are the four answers it can give?

Every claim gets exactly one of four answers, and none of them is "safe":

  • SUPPORTED: consistent with the cited label text. Not a judgment that the order suits a patient.
  • FLAGGED: the cited label says otherwise, at a severity (minor, moderate or major) set by Orinyx's rule, with the label section cited.
  • UNREADABLE: the order cannot be read as written. It comes back first, and nobody should act on it until the clinician clarifies it.
  • NOT VERIFIED: Orinyx could not check the claim, which does not mean it is correct.

The missing fifth answer is deliberate. Abstain means unchecked, never safe. A tool that turns "I could not check this" into silence teaches the people reading it to stop looking, which is the failure described in automation bias in clinical AI.

What failure taught Orinyx to lead with "not verified"?

A synthetic acetaminophen order showed that a confident answer can look exactly like a checked one. In testing earlier this month, Orinyx received an order for acetaminophen 1,500 mg every four hours. Six doses in a day is 9,000 mg. FDA's over-the-counter monograph for internal analgesics sets the adult limit at 4,000 mg in 24 hours, unless a doctor directs otherwise (FDA OTC Monograph M013, §M013.50(d)(2)).

Orinyx missed the total. It lost the frequency along the way and still answered in reassuring language while its checking was incomplete. For a tool whose whole job is to say what it checked, that is the worst kind of miss, and I would rather show it to you than a clean demo.

I published that miss instead of fixing it quietly, and I posted it in two developer communities on Reddit so people could pick it apart. The first changes that came out of it were about saying what was and was not checked:

  • That order now gets an answer that leads with not verified and says why.
  • A liquid dose written in millilitres with no concentration names the missing fact. Orinyx never invents a strength.
  • A number the parser could not place is reported as unread instead of disappearing.

The next change does the daily arithmetic for plain fixed schedules: it states the assumption it made (round-the-clock dosing), states the total it reached, and flags a total above the label's daily maximum. As-needed orders, dose ranges and "while awake" schedules will still come back not verified, because there the arithmetic would be a guess. Until that change reaches the connector, each dose is checked on its own against the label's stated ceiling, and the daily total is not computed.

Why does an order that cannot be read get its own flag?

An order nobody can read needs a different answer from an order Orinyx simply has no rule for, and a tester's session on October 6 showed why. Three synthetic orders went through the connector, among them "wafarin 5 mb by intramuscular injection." The misspelled drug name stopped the lookup, "mb" is not a unit, and all three came back not verified.

That answer was accurate and still not good enough. The agent folded each order into a single claim, so the intramuscular route was never checked at all. Then the agent suggested its own correction.

So Orinyx now has a fourth answer, UNREADABLE, decided the same day:

  • Every part of the order that could not be read is reported, not just the first one.
  • Orinyx may show a suggestion, such as warfarin for "wafarin", labelled for the clinician to confirm and marked as not checked. A suggestion never feeds a verdict.
  • A drug name is unreadable only when it matches neither Orinyx's own drug list nor the RxNorm list of currently prescribable names. A real drug Orinyx does not cover stays NOT VERIFIED, because an unfamiliar drug is not an unreadable one.
  • Free-text orders are split into dose, route and frequency by a fixed grammar, and each part is checked separately, so one unreadable word no longer hides the rest of the order.

The connector gives agents one standing instruction from that session: pass orders exactly as written, never write a corrected or completed order yourself, and quote the order as it was given.

Why does Orinyx refuse to guess at drug names?

Looser name matching would let Orinyx recognize more orders, and in medication a near miss is a different drug. Testing showed three ways it goes wrong:

  • Penicillin. An early version matched the bare word by its first letters and landed on oral penicillin V potassium. A correct order for an injection would then have been flagged for the wrong route, with full confidence.
  • Ferrous gluconate. A matcher stripped the salt, kept "ferrous," and landed on ferrous sulfate, a different salt with a different dose basis. Every dose check after that would have used the wrong label.
  • Metoprolol. The word names two products, succinate extended-release and tartrate immediate-release. Resolving it to either one decides something the order never said.

RxNorm, the National Library of Medicine's drug vocabulary, treats a brand name, a branded drug and a clinical drug as three different things, and only the drugs carry a dose form (RxNorm term types). A list that maps every brand straight to its generic throws the formulation away.

So Orinyx does no fuzzy matching and no live vocabulary lookup when a request comes in. Recognition grows through a review batch, one row per proposed brand name, and an accepted row carries a person's note on the formulation. Bare names that could mean several products, such as penicillin or insulin, come back not verified. It is slower, and every name Orinyx recognizes has a person's sentence behind it.

What did developers tell me, and what did it change?

Developers told me, in discovery conversations and on Reddit, that an agent's final response is a claim and not proof. Since mid-October I have logged everything they say as customer feedback, and three themes kept returning:

  • They check database state, API responses and saved diffs instead of trusting an agent's summary of what it did.
  • A language-model judge can approve a convincing answer that is wrong, so a model grading a model can repeat the original failure.
  • Agents sometimes complete part of a task, or report success without the evidence to back it.

The connector answers them with rules you can check against its output:

  • No model judges. Verdicts come from fixed rules over label text, so a developer can reproduce them. Where a rule already exists, nobody needs a probabilistic model to apply it. The independence argument behind this is set out in who verifies the AI that verifies healthcare AI.
  • Unchecked is never shown as clean. A run with zero flags is not a safety clearance, and not verified is reported as its own result, never folded into supported. The command-line tool planned for after launch keeps the same separation in its exit codes: 0 clean, 2 flagged, 3 not verified, 1 error.
  • Evidence travels with the answer. A supported or flagged answer carries its source, label section, source ID and URL. A citation that is incomplete is marked as one, and the result says not to rely on it. The explanation sentence is written for a person; software reading a result should read the verdict and citation fields and never parse the sentence.

One developer told me to stop hand-writing test scenarios: generate every combination of dose, frequency, unit and boundary value, implement the calculation twice, and treat any disagreement as a finding. Those boundary cases are going into the test plan. More work that answers the same feedback lands after launch, and I will describe it when it ships, not before.

Some replies were skeptical, and fairly so. People asked whether informal testing belongs in healthcare at all, and what reference standard Orinyx checks against. The reference standard is the FDA label text each answer cites. Reddit gave me informal technical feedback on synthetic data. Physicians are in design sessions, and the independent scored exam, written by a tester and a clinical reviewer, has not been taken. Nothing in this post is a claim about clinical accuracy. How that exam is meant to work is in benchmarking clinical AI, and why accuracy alone cannot settle the question is in why you can't make clinical AI accurate enough to skip governance.

What does it not check yet?

As of today there are nine gaps. The first six come back not verified, with the reason stated. The last three are limits of the surface. None of them comes back as a pass.

  • A dose the label states only as a starting dose or a single value, not a range. Orinyx says it has no labeled range to compare against.
  • Total daily exposure. Each dose is checked against the label's stated ceiling, but dose times frequency across a day is not yet computed.
  • Frequencies written as "every N hours" may come back unparsed. The order's other claims are still checked.
  • A liquid dose in millilitres with no concentration. It names what is missing and never invents a strength.
  • Which product label is cited when several share an ingredient, such as a brand, a salt form, or a pediatric versus an adult product. That selection is being tightened.
  • Interaction evidence excerpts, which may be cut short in the explanation text.
  • Patient context and allergies on the order-text tool. It reads only what the order states: drug, dose, route, frequency. A structured contraindication claim is checked against the label's contraindications section by literal match, so supported means the label lists that condition, not that a conflict with a patient was found.
  • An order that leaves out the route or the frequency. It is checked only on what it states and is not flagged as incomplete. Treat the absence as unchecked.
  • Scored exams. They need a provisioned account, so a free MCP credential sees exam calls refused by design.

Treat anything on this list the way you treat a not verified answer: unchecked, so your own review still applies.

What can builders do, with or without Orinyx?

Most of what made these changes necessary applies to any agent that touches medications, whatever tool checks it:

  • Keep the checker apart from the generator. Published research shows language-model evaluators recognize and favor their own outputs (Panickssery et al., 2024). Where a check can be a fixed rule, make it one.
  • Count "could not check" as a result. Show it, count it, and never let it render as success.
  • Pass orders through exactly as written. An agent that fixes an order before checking it has made a clinical decision nobody reviewed.
  • Test the edges, not the happy path. Dose, frequency and unit combinations near a label's ceiling are where arithmetic and parsing fail.
  • Put the evidence where the reviewer will look. In interviews with 17 experienced developers, Dhanorkar, Passi and Vorvoreanu found that reviewers of agent work lean on heuristics such as treating test results as guarantees of correctness (arXiv:2606.05391). A result that carries its own evidence gives that reviewer something real to check.
  • Use synthetic data while you test. No real patient belongs in a test run.

To try the Orinyx MCP, join the list at orinyx.io/developers. It opens October 29, to the list first, in order, and self-serve access is being built for launch week, so access arrives that week. Questions go to hello@orinyx.io.

If you build agents that touch medications, what would a verification tool have to show you before you wired it into a real project?

Frequently asked questions

What is the Orinyx MCP?

A free MCP server for developers building healthcare AI agents. It checks an agent's medication orders and claims against cited FDA label text with fixed rules, using synthetic data only. No language model decides a verdict.

Does Orinyx decide whether an order is safe?

No. Each claim comes back supported, flagged, unreadable or not verified. Supported means the claim agrees with the cited label text, not that the order suits a patient, and not verified means unchecked, never safe. Orinyx flags; the clinician decides.

Do I need patient data to use it?

No. Synthetic data only. Never send real patient records, names, dates or record numbers. The Orinyx MCP does not connect to an EHR.

When can I use it, and what does it cost?

The Orinyx MCP is free for developers and opens October 29, 2026, to the list at orinyx.io/developers first, in order. Self-serve access is being built for launch week. A paid Orinyx API for organizations follows after launch; no price has been published.

Further reading

Related in this series