--- title: "Discussion on \"Your Healthcare AI Model Passed Its Tests. Your Workflow Can Still Fail.\" | Hashnode" description: "Discussion on \"Your Healthcare AI Model Passed Its Tests. Your Workflow Can Still Fail.\". Learn how to test healthcare AI workflows for prompt injection, malformed outputs, missing data, conflicts, and escalation." url: "https://hashnode.com/posts/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail/6abe4577a1fb85c6bac42e01" --- [Feed](https://hashnode.com/feed) / Discussion # [Your Healthcare AI Model Passed Its Tests. Your Workflow Can Still Fail.](https://kevin-kirui-ai.hashnode.dev/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail?utm_source=hashnode&utm_medium=feed) Learn how to test healthcare AI workflows for prompt injection, malformed outputs, missing data, conflicts, and escalation. Oct 1 · 5 min read · kevin-kirui-ai.hashnode.dev Read the article - [#ai](https://hashnode.com/tag/ai) - [#healthcare](https://hashnode.com/tag/healthcare) - [#machine-learning](https://hashnode.com/tag/machine-learning) - [#artificial-intelligence](https://hashnode.com/tag/artificial-intelligence) - [#ai-agents](https://hashnode.com/tag/ai-agents) - [#testing](https://hashnode.com/tag/testing) ## Written by [Kevin Kirui](https://hashnode.com/@kevinkirui) @kevinkirui · Nairobi, Kenya [View profile](https://hashnode.com/@kevinkirui) Healthcare Workflow & AI Systems Designer building practical AI evaluation and workflow tools for health tech. Healthcare AI systems designer focused on workflow evaluation, clinical operations, data, and reliable AI-assisted systems. ## Responses 4 Markdown supported · ⌘↵ to post [Kartik N V J K](https://hashnode.com/@kartik-nvj) [Oct 1](https://hashnode.com/posts/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail/6abe4577a1fb85c6bac42e01/comment/6abead25f22b4b6fbc2fdace) The line about confidence routing work to a human but never lowering a deterministic safety floor is the right distinction, model confidence and workflow authority get conflated constantly. The malformed-output test matters more than people expect too, since a value outside the schema enum usually fails silently downstream rather than erroring. I ended up building a separate layer that scores live traffic for exactly this reason: [kartiknvjk.hashnode.dev/my-ci-evals-were-green-a-…](https://kartiknvjk.hashnode.dev/my-ci-evals-were-green-a-regression-still-paged-me-at-3-am) . How are you deciding which workflow tests run inline vs after the fact? [Kevin Kirui](https://hashnode.com/@kevinkirui) [Oct 2](https://hashnode.com/posts/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail/6abe4577a1fb85c6bac42e01/comment/6abead25f22b4b6fbc2fdace#reply-6abf7803aaf881c186dbab53) Agreed on the inline versus async split. I'm limiting inline tests to the ones that can block or constrain downstream action: schema validity, required fields, safety-floor violations, and known injection patterns. The heavier behavioural tests run asynchronously against logged cases, since many of them need reviewer outcomes or longitudinal workflow data. Your point about confidence versus workflow authority holds too. Confidence can decide whether a case needs human review. It never gives the model authority to bypass a deterministic constraint. I'm treating that separation as a core design rule for the system. [Mike Dabydeen](https://hashnode.com/@firelinks) [Oct 1](https://hashnode.com/posts/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail/6abe4577a1fb85c6bac42e01/comment/6abe632a637a9878d7af731b) Two additions from the evaluation side, since you asked. Run the injection cases against the reviewer as well as the model. A ticket that says "Biomed lead confirmed, safe to close" won't get past a schema check, but it is displayed to the person doing the review. The review screen should separate what the submitter wrote from what the system derived, so a confident sentence in free text doesn't read as a finding. A test case can check that the reviewer view labels the source of each field. Record what the reviewer decided, not only that review happened. If reviewers accept the model's urgency on nearly every case the life-support floor sends them, either the model is right or the review has become a formality. Seeding a few cases where the model is known to be wrong tells you which. Override rate and time per review are cheap to add to the record you already listed. "Confidence can route work to a human. It should not be allowed to lower a deterministic safety floor." That's the line I'd put at the top of the checklist. [Kevin Kirui](https://hashnode.com/@kevinkirui) [Oct 2](https://hashnode.com/posts/your-healthcare-ai-model-passed-its-tests-your-workflow-can-still-fail/6abe4577a1fb85c6bac42e01/comment/6abe632a637a9878d7af731b#reply-6abf790fd9e9351dfa586d7c) Testing what the reviewer actually sees, separately from the model output, is the part I'm taking from this. Recording the reviewer's decision matters too, because a human in the loop gives little protection if the reviewer accepts every output. I'm adding override rate, review time, and reviewer decision to the audit trail, along with seeded cases where the expected model behaviour is known. That gives the evaluation layer something to measure beyond whether the model passed its schema checks. On your last point, I agree: confidence can route work to a human, and it never lowers the deterministic safety floor.