Scaling medical content review with Amazon Bedrock: Flo Health’s RAG pipeline and AI Judges

When a single article took a week: how Flo Health rethought medical content review with Amazon Bedrock

Flo Health told AWS they had a problem: a single piece of medical article once required an average of seven working days of expert attention. That slowed editorial output for a product used by millions and forced a rethink of how to scale quality without just hiring more clinicians.

Flo turned an AWS proof‑of‑concept into a production system that treats large language models as assistants, not replacements. Using Amazon Bedrock as the foundation‑model service, the pipeline combines Retrieval Augmented Generation (RAG), multiple specialized “AI Judges, ” and a chain‑of‑thought multi‑stage prompting flow inside a three‑layer validation strategy. Flo reports a 60% reduction in average review time and a threefold increase in content throughput (Flo did not publish baseline volumes, sample sizes, or the exact measurement window; see “What Flo didn’t answer”). The numbers are internally reported and plausible given the architecture, but treat them as single‑source results until Flo publishes methodology and raw metrics.

Why medical content needs different engineering rules

Medical content must be evidence‑bound and high‑trust. Hallucinations and stale guidance are not mere annoyances, they carry clinical and regulatory risk. That shifts priorities: auditable sources, conservative human oversight, and repeatable learning loops are non‑negotiable.

  • Control layers: Flo enforces three validation layers, (1) internal medical guidelines and a 10‑point medical accuracy checklist, (2) trusted external sources retrieved via RAG (peer‑reviewed literature, clinical decision tools, regulatory guidance), and (3) human medical expert review in the final gate.
  • Data protection and governance: For any healthcare deployment ask explicitly about PHI handling, Business Associate Agreements (BAAs), encryption at rest/in transit, and audit log retention. Flo’s public writeup does not disclose whether PHI ever flows through model endpoints or whether a BAA governs Bedrock usage. Those are details you must get before production in regulated jurisdictions.

How the pipeline actually works (short, practical summary)

Flo adapted a MACROS‑style pattern, chunk content into smaller pieces, run each piece through targeted logic, then recompose. Chunking improves retrieval relevance and maps citations back to specific text spans, which helps traceability when every claim must link to a source.

The three staged flow in production:

  1. Retrieve: Canonical documents (guidelines, templates, visual assets) are stored in Amazon S3 and indexed into Amazon Bedrock Knowledge Bases for semantic search. RAG returns the documents most relevant to the content chunk being generated.
  2. Generate/Structure: Foundation models (via Amazon Bedrock) create or restructure content using templates and the retrieved context. AWS Lambda and Step Functions orchestrate the multi‑step prompts and template application.
  3. Validate: Multiple specialized LLM checks, the “AI Judges”, evaluate distinct concerns (medical accuracy, legal compliance, brand voice). Each Judge runs on a model chosen for the risk profile: faster, cheaper variants for low‑risk classification and higher‑fidelity variants for reasoning and generation. The system persists the retrieval set and Judge outputs for auditability. If checks fail, the pipeline reprocesses or routes the item to a human reviewer.

What “AI Judges” look like in practice

Think of each Judge as a small, testable microservice with its own prompt, examples, and pass/fail criteria. A medical‑accuracy Judge might accept an article chunk and return:

  • a boolean pass/fail for each factual claim,
  • a list of source citations (document + passage),
  • a confidence score, and
  • a short comment explaining the rationale and suggested edit.

That decomposition makes tuning and auditing far easier than forcing one prompt to handle accuracy, compliance, and tone all at once.

Model choices and Bedrock features Flo used

  • Flo used Amazon Bedrock as the central model platform and RAG engine; Bedrock’s Knowledge Bases and semantic search indexed their canonical docs. (Amazon Bedrock documentation and changelog confirm these primitives.)
  • Flo reported using Anthropic Claude variants (internal labels referenced as Haiku for lightweight checks and Sonnet for high‑fidelity generation) via Bedrock. Foundation models and versioning change frequently. Verify exact model versions in any replication attempt and expect migration notices in Bedrock changelogs.
  • Flo noted early brittleness with strict JSON schema outputs and used YAML to be more forgiving. Bedrock introduced structured outputs in February 2026, which reduces schema fragility at the API level.
  • Orchestration and runtime stack included AWS Step Functions, Lambda, API Gateway, DynamoDB for state, S3 for KB storage, and Contentful as the UX where editors see inline AI suggestions.

Reported outcomes, and how to interpret them

Flo reports the following production outcomes from their rollout:

  • 60% reduction in average review time per content piece. Flo reported the original baseline at seven working days per article. Baseline volumes and sample sizes were not disclosed.
  • Threefold increase in content throughput without expanding the medical team.
  • Over 70% reduction in repeated errors by capturing expert corrections as reusable rules and examples.
  • 80% reduction in routine compliance corrections.

“The traditional scaling approach of hiring more reviewers is not sustainable or economically viable.”, Flo Health engineering team

These are credible outcomes for a system that removes repetitive work and routes only ambiguous cases to experts. Still, ask for specifics: exact time windows, articles per month before and after, holdout test sizes, and the definitions used for “repeated error” and “routine compliance correction.” Without those, relative percentages are hard to evaluate for your context.

Operational hygiene you must demand

Platforms provide primitives. Governance provides defensibility. Before you sign off on a rollout, have the vendor or your team produce:

  • Metric definitions: precise calculations for review time, first‑pass accept rate, repeated error, routine compliance corrections, and the timeframe/sample used.
  • Model and prompt provenance: archived model versions, prompt versions, KB snapshots used for each article, and the ability to reproduce outputs for audits.
  • PHI/BAA confirmation: explicit statement whether PHI is processed, where it’s stored, and whether a BAA covers model and infra providers.
  • Escalation and rollback policies: thresholds that force mandatory human signoff and emergency rollback steps when model behavior regresses.
  • KB curation cadence: who owns updates to clinical guidelines, how provenance is tagged, and how often the KB is reindexed.

Failure modes and simple mitigations

  • Outdated retrievals: A KB contains stale guidance. Mitigation: provenance tags and automated freshness checks; route items citing >X‑month‑old guidance to review.
  • Citation drift: a model attributes a claim to the wrong passage. Mitigation: map retrieved passage offsets to generated spans and require Judge confirmation for each claim’s source.
  • False confidence from Judges: a Judge reports high confidence while missing an edge case. Mitigation: maintain precision/recall metrics per Judge and route low‑confidence or novel claims to humans.
  • Model drift after updates: post‑deployment regressions when Bedrock models change. Mitigation: gate production model upgrades behind A/B tests and snapshot prompts + KB for reproducibility.

Cost and metrics you should ask a vendor for (a concrete rubric)

When a partner claims “we tripled throughput, ” ask for this cost breakdown so you can compare against hiring reviewers:

  • Inference cost per article (USD) and average tokens consumed per article.
  • Storage cost for the knowledge base (monthly USD) and reindex frequency.
  • Orchestration execs per article (Step Functions/Lambda) and estimated per‑article runtime cost.
  • Engineering/maintenance headcount (FTEs) required to sustain the pipeline and cadence of KB curation.
  • Expected cost growth with throughput (linear? sublinear?), and a simple run rate projection for N articles/month.

How to measure outcomes properly, sample definitions

  • First‑pass accept rate: the percentage of content items that are approved for production without any human edits, measured on a rolling 90‑day sample.
  • Average review time: measured from when an item enters the medical review queue to final signoff; report mean, median, and standard deviation.
  • Repeated error: an identical editorial/clinical issue occurring in ≥2 distinct content items after correction rules had been added to the KB or prompt examples; measure per 1, 000 articles.
  • False negative rate (per Judge): proportion of unsafe/incorrect items that passed a given Judge on a holdout test set.

Practical playbook: how other regulated businesses should adapt the pattern

  • Start with a human‑in‑the‑loop pilot focused on high‑volume, low‑risk content types to gather definitions, baselines, and a labeled dataset for Judges.
  • Decompose checks into single‑concern Judges and version each Judge’s prompt and model selection.
  • Index canonical sources into a KB and persist the retrieval set with each generated artifact for auditing.
  • Implement a simple confidence routing rule: high confidence + low‑risk → expedited review; low confidence or novel claims → full human review.
  • Measure ROI by comparing incremental infra + engineering cost against the fully‑loaded cost of hiring the reviewers you’d otherwise need.

“By capturing every expert correction as reusable rules and examples rather than one‑off edits, we built a system that grows smarter with each review cycle, reducing repeated errors by over 70 percent.”, Flo Health engineering team

What Flo didn’t, or hasn’t yet, fully disclosed

Flo’s post explains architecture and reports outcomes, but several operational and compliance details remain unanswered and are critical for anyone trying to replicate or evaluate vendor claims:

  • Exact baseline and post‑rollout volumes (articles per week/month) and the measurement window for their percentage claims.
  • Whether PHI was ever processed and whether a BAA covers Bedrock/infra usage.
  • Model and prompt versioning policies and how Flo ensures reproducibility when Bedrock model families are migrated.
  • Sample audit artifacts showing a content item’s retrieved sources, Judge outputs, and final editor edits.
  • Any production incidents, rollbacks, or near misses and their remediation steps.

Four action items for product and C‑suite leaders

  1. Demand baselines and precise metrics now. Ask partners for raw volumes, definition of metrics, and sample sizes before you accept headline percentages.
  2. Insist on PHI/BAA and auditability. No deployment in regulated contexts without explicit PHI handling rules, BAAs where required, and preserved KB + prompt snapshots for audits.
  3. Require versioned prompts & KB snapshots. If a model is updated, you must be able to reproduce previous outputs for regulatory or legal inquiries.
  4. Start with model tiering and human‑in‑the‑loop pilots. Use smaller models for routine checks and higher‑fidelity models for critical generation, and keep humans in the loop for edge cases until your confidence metrics are proven.

Key takeaways, your quick Q&A

  • Did Flo actually speed up medical reviews?

    Flo Health reports a 60% reduction in review time and a threefold throughput increase; these are Flo’s internal results and plausible given their architecture, but they have not published baselines, sample sizes, or validation methodology here.

  • How does Flo prevent hallucinations and keep content auditable?

    They use RAG with Amazon Bedrock Knowledge Bases to retrieve trusted documents for each generation, persist the retrieval set alongside outputs, and run multiple specialized AI Judges plus final human review to create an auditable trail.

  • Are models replacing human experts?

    No, Flo positions AI as an assistant. The system reduces routine work and surfaces hard cases for clinicians, keeping human reviewers as the final authority.

  • What platform features made this practical?

    Amazon Bedrock’s model access, Knowledge Bases/semantic search, agentic retrieval primitives, and guardrail features supported the design. Orchestration used Step Functions, Lambda, DynamoDB, S3, and Contentful for the editor UX.

  • What should you watch out for if you build something similar?

    Model/version drift, KB curation cadence, PHI governance and BAAs, the cost of inference at scale, precise safety metric definitions, and robust escalation policies for ambiguous or novel claims.

A final pragmatic note

Flo’s framing is a useful reminder for product leaders: scaling quality in regulated domains rarely comes from full automation. The real value comes from using LLMs to remove repetitive validation work, make expert reviews faster and evidence‑backed, and capture expert corrections as reusable knowledge so the system improves with each cycle. Demand the numbers, insist on auditability, and design governance before you scale velocity, speed without traceability is a risk, not an advantage.