HIPAA-compliant Microsoft-Decision-1: the decision-model layer

Most of the work in a clinical back office is not generation. It is a decision: does this fax need a referral, which payer queue does this claim belong in, is this message a refill request or a billing dispute, does this drafted reply pass the review rubric. A large language model can answer all of those questions, and it will answer each one by writing a paragraph that you then have to parse.

Microsoft released Microsoft-Decision-1 on October 9, 2026 for the narrower job. It takes a state and a set of predefined questions, and it returns a calibrated probability for every option. There is no prose to parse, no JSON to repair, and no output tokens to bill.

One disclosure before the analysis. The model is proprietary and not open weights. It runs in public preview on Microsoft Foundry, which is the path we serve it through, and Microsoft also lists it on OpenRouter.

Today, Microsoft-Decision-1 is available on our HIPAA-compliant design-partner program under a signed BAA, with end-to-end encryption and strict zero data retention on prompts and outputs.

What is Microsoft-Decision-1?

Microsoft post-trained Qwen3.5-9B into a single-pass scoring model and shipped it with a 32,768-token context window. The API takes a state field and a questions object. Each question declares a type: a choice among named options, a yes or no, or an ordered rating. The response contains the selected option and a probability distribution across all of them.

Microsoft's published price is the part that gets attention: $0.042 per million input tokens, with output tokens free. That is about one seventh of the $0.30 per million input rate that DeepSeek-V4.1-Flash-1017 carries on our platform. A decision model has no output to bill because it has no generation step, which is what makes the number possible rather than generous.

Microsoft has said future iterations will be rebased on OpenAI models and its own MAI models. Read that as a signal about direction: this release is a post-trained Qwen checkpoint, and the roadmap is a Microsoft-owned base.

Why a decision model is not a small language model

The difference is not size. It is what the model spends compute on.

A general-purpose model reads your ticket, reasons about it, and writes a sentence containing the answer. For routing at volume, the reasoning and the writing are almost entirely waste. A decision model reads the state once, attends over every question in the same shared prefix, and emits a distribution. Microsoft measures the effect as 35 times faster than GPT-6 Sol at P50 latency and 2.5 times faster than H2O-Lightning-4B v1.1, the runner-up in its comparison.

The second difference matters more for patient-facing systems. A language model's confidence is not in the payload. You either trust the text or you ask a second model to grade it. A decision model's confidence is the output, so a workflow can act on it directly: auto-route above a threshold, send to a human below it, and log the probability that drove the choice. That is the shape a clinical operations team can audit.

The third difference is stability. Microsoft perturbed the same request eight ways - paraphrasing instructions, rewording option descriptions, reordering choices, renaming keys, adding formatting noise - and measured how often the decision flipped. The average was 1.3%, with zero flips when option descriptions were paraphrased or options were reversed or shuffled. For a routing rule that will run a million times, a flip rate is a more useful number than an accuracy percentage.

What Microsoft measured, and what it did not

The launch post reports the highest accuracy in a 36-benchmark comparison spanning nearly 150,000 questions kept blind from training, across routing, ranking, long context, multilingual and out-of-distribution tasks, reasoning, and safety. It also reports a safety evaluation over 5,250 requests across 11 benchmarks covering harmful content, jailbreaks, and prompt injection.

The absence of a public per-benchmark table is the honest gap in this release. Every number above is vendor-reported, and a 9B post-train can look excellent on a benchmark suite it was tuned against while behaving differently on your discharge summaries.

Where it fits in a healthcare workflow

The use cases Microsoft lists map almost directly onto the non-clinical parts of a hospital operations stack:

• Intake triage. Classify an inbound portal message as scheduling, refill, billing, or clinical escalation before anything is drafted, and route on the probability rather than on a keyword list that nobody maintains.
• Prior-authorization routing. Choose the payer, the queue, and the packet type in one pass, with a confidence that tells staff which cases need a human read.
• Agent guardrails. Before an agent executes a tool call that touches a record, score whether the action requires human approval. This is the cheapest place to put a gate.
• Quality review. Grade a drafted response against a rubric and decide accept, revise, or reject. Microsoft describes this pattern for Copilot quality work internally.
• Coding support. Suggest a category for a note or claim and attach the probability, so the coder sees which suggestions are safe to accept in bulk and which need review.
• Safety screening. Classify requests or proposed actions by risk and decide whether to allow, block, or escalate them.

The pattern is consistent: the decision model does not produce the clinical content, and it does not make the clinical call. It decides where the work goes and whether a person needs to look at it.

Limitations to keep in mind

• 32K context is a fragment, not a chart. A full encounter history does not fit. Either you summarize upstream, which reintroduces a generative step, or you scope the decision to a single document.
• It cannot explain itself. You get a distribution, not a rationale. If your governance process requires a written justification for an automated routing decision, that justification has to come from your application layer and the inputs you logged.
• Closed weights and a preview lifecycle. You cannot self-host it, and a preview designation means the question schema, the pricing, and the model identifier can change. Confirm the current terms with us before you build a regulated workflow on top of it.
• Calibration is dataset-dependent. A model that is well calibrated on support tickets is not automatically calibrated on prior-auth denials. Before you set a 0.9 auto-accept threshold, plot the reliability diagram on a few hundred of your own labelled cases.
• General knowledge is deliberately limited. This is a 9B model optimized for scoring, not a substitute for a reasoning model when the task actually requires reasoning.

What this means for the rest of the stack

Microsoft's entry validates a category that both proprietary and open models can serve on the same terms. A decision model is a small post-trained classifier with a calibrated head and a structured API, and nothing about that design requires a proprietary host.

That matters for healthcare teams because the decision layer touches every request before it reaches a generative model, including the requests that contain identifiers. A routing decision that runs outside your BAA perimeter is a data flow you have to document anyway. Keeping the whole pipeline, classifier included, inside one contracted boundary is simpler than stitching a scorer from one vendor to a generator from another. That is why we serve this one through Foundry rather than treating it as a reference design. The catalog is here. See the compliance guide.

More proprietary models are coming soon to the same platform. The right way to use Microsoft-Decision-1 in a healthcare context is as a routing tier in front of a compliant generation path, not as a clinical judgment layer.

A note on evaluation

If you are testing this model, compare decision accuracy, latency, and cost per completed decision, and include the ambiguous cases your team actually argues about. Then check calibration separately, because a model can be accurate and badly calibrated at the same time, and only the second problem breaks a threshold-based workflow. Microsoft's own guidance says the same, which is a point in its favor.

Ready to put your routing layer under a BAA? Join the waitlist.