Human-in-the-loop for clinical products
A clinician reviews it before the patient does.
The reviewing clinician approves from their phone between patients, and the review is recorded without a second system.
How does a healthcare AI product get clinician review before output is used?
Pushary puts a named clinician in front of the step where output leaves your product. Wrap the note, the message, or the order in decisions.ask() and the agent holds until they approve, decline, or return corrections. Nothing proceeds on a timeout, and the review is written to a durable ledger with the clinician and the timestamp.
Where it stops
The calls that should not be automatic
- signNote(encounterId, draft)
- A signed note becomes the record of what happened in that encounter, and it is what every downstream decision and claim is built on.
- messagePatient(patientId, draft)
- A patient reads a message from your product as coming from their clinician, and they act on it accordingly.
- suggestOrder(patientId, order)
- Anything that looks like an order needs the person who carries the clinical responsibility to be the one placing it.
- flagAbnormalResult(resultId)
- Deciding what counts as abnormal enough to act on is clinical judgement applied to one patient, not a threshold applied to a population.
The integration
Two calls inside the step you already have
Wrap the action, not the whole agent. Everything the agent does that is safe keeps running without asking anyone.
import { createPusharyServer } from "@pushary/server"
const px = createPusharyServer({ apiKey: process.env.PUSHARY_API_KEY! })
async function releaseNote(encounter: Encounter, draft: NoteDraft) {
// Only a reference and a short summary leave your system.
const decision = await px.decisions.ask({
externalId: encounter.clinicianId,
type: "select",
question: `Sign the note for encounter ${encounter.reference}? ${draft.changedSections} sections drafted.`,
options: ["Sign", "Return for edits", "Discard draft"],
})
if (decision.answer !== "Sign") {
return returnForEdits(encounter.id, decision.answer)
}
return signNote(encounter.id, draft)
}Who answers
The approver is usually not an engineer
The approver is a clinician between patients, and the amount of attention available for your review queue is measured in seconds rather than minutes. That constraint is usually treated as a reason to make review lighter, and it is really a reason to make the request reach them where they are. A queue in your web application competes with the chart, the phone, and the person in front of them. A single narrowed question on the device in their pocket does not. Pushary addresses them by the id already on the encounter and returns their answer to your code, so the review step you designed happens inside the visit rather than at the end of the day.
Can any of this touch protected health information?
Design it so it does not have to. The pattern we recommend for clinical products is to pass a reference and a minimal summary in the question, keep the note and the record in your own environment, and treat Pushary as the layer that carries the decision rather than the content. The default asset stored is the decision and policy event, not the underlying document. Whether your specific deployment needs a business associate agreement and what your obligations are is a question for your own compliance counsel, and you should ask them rather than rely on a vendor page. Pushary is GDPR-aligned. It holds no HIPAA attestation, no SOC 2, and no ISO certification, and we will not claim otherwise.
Worth reading: HHS guidance on the HIPAA Privacy Rule.
Embed it in your product. Your users never see a Pushary login or bill.
FAQ
Questions, answered
Put a person on the step that needs one.
Connect a user with one tap, ask a human with one call, and act on a fail-closed decision. Every decision is saved to a durable ledger you can audit.