Heidi, an Australian-founded AI Care Partner, has built Heidi Scribe to automate large parts of clinicians’ administrative work. The company reports the product is now used in more than 190 countries and supports roughly 2.7 million patient interactions per week. That global expansion is rooted in infrastructure choices made years before Heidi reached this scale.
Why production healthcare AI requires a different architecture
Yu Liu, co-founder and chief technology officer at Heidi, emphasizes that even a small error rate in healthcare can become a clinical safety issue. For that reason, Heidi’s architecture assumes every model output may be scrutinized, audited, and relied on in patient care. Systems must be able to show what the model saw, what it produced, and what the clinician changed for any session, even months later.
Data residency is treated as a precondition rather than an optional feature. Clinicians in Sydney, London, Tokyo, or Denver operate under different legal regimes — Australian Privacy Principles, GDPR, APPI, HIPAA — so patient data must remain in-region. To enforce this, Heidi runs fully logically isolated production deployments around the world.
Liu also stresses reducing the blast radius of change: unlike less regulated industries where teams can ship fast and fix forward, Heidi enforces safety by default. The company uses continuous integration gates on risky change classes, canary releases, and subjects even database schema and index changes to code-review processes. According to Liu, their operational speed flows from these safety practices.
Choosing a database for AI workflows
Heidi aggregates diverse medical data — forms, referrals, clinician notes and other artifacts — into a consistent format and location to feed AI workflows. Rigid row-and-column databases would not fit the heterogeneous and rapidly evolving data shapes involved.
That made a document database the natural choice. Heidi uses MongoDB and MongoDB Atlas to accommodate quickly changing AI data without constant underlying schema reshaping. An AI Scribe session is not a single record but a compound object: transcripts, structured notes, templates, documents, patient context, EHR integration state and many related artifacts that change over time. The document model lets those elements live together in structures that mirror clinical work and be evolved without migration freezes each time the product changes.
MongoDB Atlas also provided built-in, AI-ready features such as MongoDB Vector Search, removing the need for a separate bolt-on vector database. Heidi converts large volumes of medical documents into vector embeddings via LangChain in Atlas to enable semantic search that links transcribed medical terms directly to corresponding external knowledge. Liu says migrating to Atlas reduced latency on key APIs by nearly 33%.
What a trustworthy clinical RAG system requires
"Retrieval is a data architecture problem before it is an AI problem," Liu says. In consumer RAG you may retrieve from the open web and hope; in healthcare you must retrieve from the compliance surface. Heidi Evidence pulls from licensed clinical knowledge bases, including partners such as BMJ Best Practice, NICE CKS, and MIMS, and it is jurisdiction-aware so that U.K. clinicians receive U.K. guidance while Australian clinicians receive Australian formularies.
Heidi stores embeddings and vector indexes in MongoDB Vector Search inside the same regionally isolated deployments as the rest of its data. This ensures retrieval cannot cross residency boundaries physically, and avoids operating a separate vector database with its own security and compliance story. Citations in Heidi are a hard contract rather than a prompt suggestion: the model only ever sees retrieved chunks that are already bound to source records.
Regional isolation enables global compliance and scale
Each region is a full, isolated production deployment with its own MongoDB Atlas clusters, compute, and encryption keys. That infrastructure-first approach allows Heidi to answer residency questions cleanly when engaging U.S. health systems, NHS trusts, or Australian hospital groups.
Maintaining multiple isolated regions with a lean team is tractable because the database layer is managed and consistent. Heidi is also multi-cloud, so a new region can be stood up on rails the company has already built.
This architecture has been visible in U.S. deployments: Beth Israel Lahey Health, one of New England’s largest health systems, rolled out Heidi’s AI scribe after a pilot in which 74% of clinicians reported reduced after-hours documentation. MaineGeneral Health, a nonprofit system, selected Heidi as a strategic partner for rural healthcare work.
Liu notes that entering the U.S. market meant standing up another region on existing rails rather than retrofitting for HIPAA later.
Lessons learned and the roadmap ahead
Heidi’s engineers are now re-partitioning large, hot, always-on collections with MongoDB, a significant engineering effort that highlights the importance of initial partitioning and shard key choices. Liu advises that horizontal scale for the fastest-growing data should be a founding decision, similar to residency.
The company is extending beyond consult notes to support the full clinical workflow: pre-visit context, post-visit documents, referrals, and workflow automation. Heidi is also exploring how MongoDB, large language models, and its tooling can support an agentic ecosystem for clinical workflows.
Liu summarizes: reliability engineering in healthcare AI is trust engineering. A clinician’s trust can be lost as quickly by downtime, latency, or data inconsistency as by a poor note. Much of Heidi’s highest-leverage work is invisible — canary releases with automatic rollback, CI gates on database changes, and cross-region consistency checks — because clinician trust is the product, and trust is architectural.
This article was sponsored content presented by MongoDB.
