MIRA
Clinics sign up, pay per provider and run their own AI patient intake
We built MIRA's AI intake for the founder's own practice, then made it a product any clinic can buy. We rebuilt the backend under the intake that worked: clinics register, pay per provider and shape their templates, and names never reach the model.
Healthcare & WellnessMulti-clinic intake SaaSBuilt from zero
The challenge
The intake worked in three practices but was built for one: hard coded question flows, physician logins set in the code and no real database. Clinics now had to sign up, pay and run it alone.
What we did
We kept the intake that worked and rebuilt the backend under it: one database on Azure, three roles with clinic isolation, per-provider billing in Stripe and identifiers stripped before the model.
The outcome
MIRA became a commercial product: clinics register, pay per provider, add providers and customize intake templates, and the production site passed final QA before handover.
- Status
- Commercial product, production site through final QA
- Roles
- Super admin, clinic admin, provider
- AI boundary
- Names and birth dates never sent to the model
- Handover
- Code in the client's GitHub, billing on its Stripe
The starting point
MIRA gives pain and specialty clinics AI patient intake, with a structured summary for the physician. We built the first version for the founder's own practice, and it ran there and in two more.
What had to change
That version was built for one practice: hard coded question flows, physician logins set in the code and no multi-tenant database. To sell it, clinics had to sign up, pay, add providers and run intake on their own, without seeing each other's data.
What could not break
- The intake flow that already worked in practices keeps working
- Patient names and dates of birth never reach the model
- Each clinic is fully separate, and only the super admin sees all clinics
- Built to HIPAA practice, with the BAA and third-party audit on the client's side
- Patients answer without accounts, on a clinic iPad or from a clinic link
The calls we made
We kept the AI intake that worked and rebuilt the product around it, settling roles and data structure before any screen.
- 01
One database on Azure
The client had built a sign up page on Supabase. Splitting data across two platforms meant sync problems with Stripe, such as failed payments and account checks, and a second system to bring under HIPAA.
Ruled outSyncing the client's separate Supabase sign up with the Azure product.
- 02
Strip identifiers before the model
The commercial version collects names and dates of birth, so both are removed on our backend before any intake reaches OpenAI.
- 03
No accounts for patients
Clinic staff sign in by role, while patients answer on a clinic iPad or from a unique clinic link sent before the visit, so there is nothing for a patient to set up.
Ruled outPatient accounts.
- 04
One price per provider
Pricing by provider count means every clinic gets the same product, which removes permission checks for each tier and keeps billing to one variable.
Ruled outBasic and premium tiers with different features.
- 05
Short pages, customization last
The long pain questionnaire became short pages with buttons, like the medical history section, and template customization was built last so sign up, billing and dashboards could ship first.
Ruled outA body map for the pain questions.
How the system fits together
What we built
Self-service onboarding and billing
Clinic sign up with a confirmation email and receipt, Stripe billing per provider with subscription acceptance, service terms and discounts, and short intake links for each clinic and provider.
Multi-clinic roles
Super admin, clinic admin and provider roles with role switching and access checks, each clinic isolated, and a super admin dashboard across all clinics.
Physician dashboard
Active and archived notes with bulk archive and search, plus practice notes for each clinic.
Template customization
Clinics add, edit, delete and reorder questions, add child questions, duplicate templates and start from a prebuilt library that the super admin maintains.
Shorter pain pages
The pain questionnaire became a three page wizard with buttons, like the medical history section, so patients no longer scroll through one long page.
How it works
Sign up
A clinic registers, picks its provider count and pays through Stripe.
Set up
The clinic admin invites providers and adjusts intake templates.
Send
Each provider shares a short intake link, or patients answer on a clinic iPad.
Summarize
Names and birth dates are stripped, and AI drafts the clinical summary.
Review
The provider reads, archives and searches notes in the dashboard.
A closer look
What changed
MIRA is now a commercial product: clinics register, pay per provider, add providers and customize their intake templates, and the production site passed final QA. The code lives in the client's GitHub repositories and billing runs on the client's own Stripe account.
Under the hood
- Datics role
- Product built by Datics
- AI boundary
- Patient names and dates of birth are removed before any call to OpenAI, and the AI drafts a summary without diagnosing.
- Isolation
- Each clinic account is fully separate, with role based access for clinic admins and providers. Only the super admin sees all clinics.
- Security
- Azure with HTTPS throughout and secrets in Azure Key Vault, built to HIPAA practice. The client holds the BAA and the third-party audit.
- Billing
- Stripe callbacks tied to the number of providers each clinic adds, with provider count as the only pricing variable.
AI and models
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Scoping
Functional and non-functional documents, a gap analysis, wireframes for sign up and templates, and a proposal revised as features were cut to reach market sooner.
Backend and roles first
Multi-clinic and multi-provider support, role based access and the new backend, then sign up, the onboarding wizard and per-provider billing.
Dashboards and templates
Physician and clinic dashboards with archiving and search, then template customization in the last planned sprint.
Client feedback rounds
Subscription acceptance, confirmation emails, short intake links, practice notes, access checks, child questions, the super admin template library, discounts and bulk archive.
Production and handover
Secrets moved to Azure Key Vault, live Stripe products and final QA on the production site, then developer documentation, a walkthrough and the code in the client's repositories.
Written requirements, regular meetings
Both sides agreed to replace chat back and forth with written requirements and regular meetings with the founders.
Feedback rounds before launch
After the planned sprints, the founders reviewed the product in rounds, and we worked through the changes from each round before final QA on the production site.
Shipped into their accounts
Code went to the client's own GitHub repositories and live billing to the client's own Stripe account, with developer documentation and a walkthrough at handover.
What this unlocked
Multilingual spoken questions and sending notes into EMR systems are the next features discussed.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.