MedScrub

The de identification engine is real model work and it is the differentiator: reliably locating all eighteen HIPAA identifiers across messy clinical text, reversibly, is a hard natural language problem and it is what the company actually builds. But the clinical reasoning a buyer relies on is explicitly performed by third party models the customer selects, GPT-4, Claude, Gemini, Mistral or a local model under Ollama, and MedScrub is deliberately agnostic between them. So the AI producing the clinical output is not MedScrub's AI. That is a coherent and arguably safer architecture, and it keeps the company's own model work at the privacy layer.

No oversight mechanism is described for the clinical output. There is no confidence signal, no threshold, no abstention behavior and no required review step for the visit summaries or the chart question answering. One structural point matters more than the missing parameters: because the clinical reasoning is performed by a model the customer selects, the oversight and error properties of the output depend on a component MedScrub neither controls nor evaluates.

The same summary produced through a frontier model and through a small local model are different artifacts with different failure rates, and nothing here tells a buyer which to expect. Accountability for output quality when the buyer chose the model is not addressed.

The model is whichever one the customer chooses, and the company names the options: GPT-4, Claude, Gemini, Mistral and local models under Ollama. Model agnosticism stated as a design property rather than left vague is real transparency, and it makes the content path and its cost traceable.

The single most important number is missing. For a deidentification engine, recall on identifier detection is the safety property: one missed identifier defeats the entire architecture, since the whole argument rests on nothing identifiable reaching the model. The company describes HIPAA grade FHIR accuracy without publishing a figure, a method or an evaluation set.

Whose model sees the content is the customer's choice, with the options named individually across commercial frontier models and open models runnable locally. Model agnosticism stated as a design property rather than left vague is real disclosure, because it makes each route's destination and cost explicit. The architecture then removes the question rather than answering it.

All eighteen recognized identifiers are stripped before content reaches any model, so a frontier provider never receives identifiable data at all; the substitution is reversible so clinical utility is preserved; the proxy can be self hosted; local models are supported, meaning the entire path can run without content leaving the premises; and patient data syncs into a clinical data repository the customer owns rather than into a vendor cloud.

Any one of those would be notable, and together they let an organization eliminate the exposure rather than manage it. The residual is single and it is load bearing: the whole argument rests on nothing identifiable reaching the model, and one missed identifier defeats it.

Claims without substantiation. No customer is named, no funding is disclosed, no deployment is described and no independent evaluation is published. The two quantified claims, 78 percent token cost savings and HIPAA grade FHIR accuracy, carry no baseline, method or denominator. The token saving figure is at least the kind of claim a buyer can verify quickly in a trial, but it measures cost rather than correctness.

A privacy architecture resting on several independent mechanisms rather than a single promise. All eighteen HIPAA identifiers are removed before content reaches any model, so a consumer or frontier model never receives identifiable data. The substitution is reversible so utility is preserved. The proxy can be self hosted. Local models are supported under Ollama, meaning the entire path can run without content leaving the premises.

And patient data syncs into a clinical data repository the customer owns rather than into the vendor's cloud. Any one of those would be notable; together they let an organization eliminate the exposure rather than manage it, which is engineered privacy rather than policy privacy.

Two things remain open: the recall figure on identifier detection, which is unpublished, and the hard case for any deidentification pipeline, which is an identifier spoken or written conversationally rather than in a structured field.

HIPAA framing runs through the entire product, with references to HIPAA grade accuracy, stripping all eighteen identifiers and reaching a HIPAA compliant build quickly, but no compliance statement and no business associate agreement terms are published. The claims exist and none is an assurance.

One point deserves separate attention because it is the product's core commercial argument rather than a detail: if identifiers never reach the model provider, a customer may not need a business associate agreement with that provider at all. That is a significant proposition, and it rests entirely on the recall of the identifier stripping.

No attestation and no trust center are published, and the architecture makes clear what an examination would most need to cover.

This product is deidentification infrastructure rather than a summarization application. It strips identifiers from clinical data, routes the remainder to any model endpoint, and reidentifies on return, with reversibility marketed as a headline capability.

That architecture puts the whole security question in one place. Reversible deidentification means a mapping exists somewhere that turns the stripped output back into identified data. Where that mapping is held, how it is encrypted, who can reach it, and how access to it is logged is the control that matters most, because possession of it collapses the protection the rest of the system provides. The distinction is not academic: deidentification under the privacy rule produces data that cannot readily be reidentified, whereas a system retaining the key is performing pseudonymization. Both are legitimate and they carry different obligations, and nothing published says which the vendor is doing or where the key lives.

The deployment split compounds it. Self hosted and air gapped options are offered alongside a cloud service, which is strong provision. It also means the vendor's controls cover different ground in each mode, and in a self hosted deployment much of the burden sits with the customer, who may not realize the attestation they were shown describes a boundary they are not inside.

One marketing claim overstates. The product is described as making any AI feature that touches clinical data compliant in one line. Deidentification is a technical control. Compliance is a regime that also requires agreements, risk analysis, access management, workforce training and breach procedures, none of which an interface call supplies. That claim is aimed at developers.

There is no clearance, device authorization or pathway statement, and none attaches to the product itself. This is infrastructure: it removes identifiers, routes data to a model endpoint chosen by the customer, and restores identifiers on return. It makes no clinical claim and reaches no clinical conclusion.

The scoping question that matters turns on what the vendor advertises its customers can build.

The published use cases include differential diagnosis, treatment suggestions and drug interaction checking, and separately chatbots for symptom checking and care navigation. Those are not documentation. Differential diagnosis and treatment suggestion are the core of clinical decision support, and a patient facing symptom checker falls where the exemption reasoning fails outright, because a patient cannot independently review the basis of a recommendation the way a professional can.

The regulatory obligation for any of those attaches to whoever builds and markets the resulting feature, not to the de identification layer beneath it. That allocation is correct, but the company leaves it implicit, while the marketing frames these as things a developer can add in one line. A developer who reads that may reasonably conclude the hard problems have been solved for them. The privacy plumbing has been solved. The device classification question for a diagnostic feature has not, and it will land on them.

So the question for this vendor is what it tells its customers about their own obligations.

MedScrub publishes no fairness, subgroup or demographic performance disclosure of any kind, and for this product the gap carries particular weight. De identification engines are known to perform unevenly across naming conventions: a model trained predominantly on Western given and family names detects them more reliably than names from other traditions, and the same applies to address formats and identifier patterns.

If recall varies by population, then the privacy protection this product sells is itself unevenly distributed, and the people least protected are precisely those whose names the training data underrepresents. It is the same structural shape seen in patient matching accuracy and in speech recognition across accents. Published recall broken down by name origin would be a differentiating disclosure and no vendor in this space offers it.

The architecture is described precisely enough to show where it fails, which is a real form of accountability. Identifier stripping before the model, reversible substitution, a self hostable proxy and support for local inference are each stated as design properties, so a reader can trace the data path end to end and identify the single point on which everything depends. That point is unmeasured.

For a deidentification engine, recall on identifier detection is the safety property rather than one metric among several: precision failures cost utility, since an over redacted note is merely less useful, while a recall failure sends a real patient identifier to a third party model and defeats the entire architecture in one instance.

The company describes its accuracy in general terms without publishing a figure, a method or an evaluation set, and no warranty, indemnity or remediation commitment attaches. The hard cases are where such systems actually break: an identifier written conversationally inside a clinical note, a name in a quoted patient statement, an employer or a rare condition that identifies by combination rather than by pattern. Structured field redaction is close to solved and free text is not.

Real integration is described and no system is named. The product pulls conditions, laboratory results, vitals, medications and imaging from the EHR and syncs them into a customer owned clinical data repository, and FHIR accuracy is referenced, which implies standards based exchange. But no EHR vendor, integration mechanism, certification or marketplace listing is published, so an organization cannot tell whether its own system is supported without asking. The developer facing surfaces, an HTTP API and an MCP server, are integration points in their own right, and unusually current, but they serve builders rather than answering the EHR question.

Three independent choices are offered rather than one: the de identification proxy runs self hosted or in the cloud, the models can be frontier services or local models under Ollama, and the patient data repository is owned by the customer rather than held in the vendor's cloud. Taken together, an organization can construct a path in which no patient content and no de identified content ever leaves infrastructure it controls. What is missing is narrow: the cloud option comes with no residency regions, hosting detail or portability commitment, and nothing describes what the vendor can see in a self hosted deployment.

Pricing is absent entirely: no price, tier or pricing mechanism is published.

The 78 percent token cost saving claim is a cost argument rather than a price, and it describes savings on the customer's own model spend rather than on what MedScrub charges. The two should be assessed separately, because a product can reduce inference spend and still cost more than it saves.

Coverage is described by use case rather than by care setting or specialty, and no clinical setting is named anywhere. The clinician facing functions are population health screening, pre visit planning and chart question answering, which point toward ambulatory primary care without saying so, and the developer facing use cases span intake and symptom checking chatbots, coding assistance, referral routing, care plan generation and staging environment data. That is breadth of application rather than depth in any setting, and no specialty specific behavior, instrument or terminology handling is described.