Skip to content
clinic operationscomplianceintegration

A Quality-Management System for a Regulated Stem-Cell Clinic, Firewalled From the Parent Brand

How we built a regulated-clinic management system for GIOStar: a quality-management spine plus EHR integration, with patient data firewalled from the marketing CRM.

TL;DR. JustinHarris.AI, the Las Vegas AI Consultant, built a regulated-clinic management system for a stem-cell clinic: a quality-management spine plus EHR integration that binds every biologic lot to a patient, answers a recall the EHR cannot, and firewalls patient health data so it never reaches the marketing CRM.

The problem: a regulated clinic management system your EHR cannot be

A regulated stem-cell clinic has to answer one hard question on demand: which biologic lot went into which patient, and if a lot is flagged, which patients need to be called. Most clinics assume their electronic health record (the EHR, the software that runs booking, charting, and billing) can answer that. It cannot. We tested the clinic's EHR hands-on and confirmed it directly with the vendor: it keeps one overwritable lot field per item, it has no way to pull records back out through software, and not one of its 110 built-in reports even mentions the words lot or recall. So a recall query has no answer, chain of custody lives in nobody's system, and the compliance records a regulation requires end up scattered across spreadsheets. That is the gap a real clinic management system has to close.

  • The EHR cannot bind a biologic lot to a patient in a way you can query for a recall.
  • There is no read interface to pull compliance records out of the EHR.
  • Chain of custody and QC release records have no home in the EHR at all.
  • Marketing automation, left unchecked, would drag patient health data into a tool never built to hold it.

What a clinic management system actually has to hold

The instinct is to copy the whole patient chart into a new system. That is the wrong move, and it is how clinics end up with two charts that disagree. We scoped this clinic management system to a single rule: it holds only the records a regulation enumerates AND the EHR cannot structure. Demographics, medical history, allergies, consent, routine vitals, and the doctor's notes stay in the EHR, which is their system of record. The quality-management system holds the lot ledger, the chain of custody, the QC release, the deviation and corrective-action records, and the recall query. The result is a 30-table, 475-field Airtable Enterprise base that is lean on purpose: every table earns its place because a regulation names it and the EHR cannot hold it. Nothing is duplicated for the sake of having a copy.

  • Lot-to-patient binding: every administration ties a biologic lot to the patient who received it.
  • Chain of custody: the regulated record of where a biologic was, from receipt to infusion.
  • QC release and batch disposition: the sign-off records a regulator expects to see.
  • Recall query: filter the ledger by lot, get the exact list of affected patients.

How the EHR integration and the patient-data firewall work

The clinic runs three systems, and the value is in how they are wired. OptiMantra is the EHR, the clinical head. GoHighLevel is the marketing CRM, where reviews and reactivation live. The quality-management system sits in the middle as the single source of truth for compliance and as the one gate that decides what data is ever allowed to reach marketing. When something happens in the EHR (a booking, a check-out, a billed visit), the EHR fires a webhook to a small middleware service, which acknowledges it instantly and hands the full record to the quality-management system. The QMS, and only the QMS, matches the patient, writes the clinical and compliance records, and then strips out every piece of protected health information before sending a lean event packet onward to marketing. The marketing CRM receives an appointment event and a service-line tag. It never receives a name, a date of birth, a diagnosis, a drug name, or a lot number. Because the strip logic lives in exactly one place, it cannot drift, and a drifting copy on a patient-data boundary is the kind of thing that becomes a reportable incident. The clinical record is always written first and the marketing push second, so if marketing ever fails, a compliance record is never lost.

  • The integration is one-way out of the EHR; there is no path back in, so the QMS holds the authoritative compliance copy.
  • Patient health data is stripped inside the QMS before anything reaches the marketing CRM.
  • A marketing campaign fires only when the patient's authorization is on file, checked before any message goes out.
  • Lot and chain-of-custody data are entered by staff in the QMS, because the EHR structurally cannot send them.

Why we proved the gap before we built anything

The most important decision on this project was made before a single table existed. It would have been easy to assume the EHR could not do lot-to-patient binding and start building. Instead we tested it ourselves inside the live EHR, then asked the vendor to confirm it in writing, and they did: lot-to-patient binding, chain of custody, QC release, certificate of analysis, deviation and corrective-action tracking, recall, and HCT/P biologics inventory are all outside the EHR by design, and there is no read interface to work around it. That written confirmation is now the documented reason the quality-management system exists. It is the difference between a clinic management system that is a guess and one that is a verified answer to a specific, named regulatory requirement. A staff engineer would approve the system because the system is built on evidence, not on an assumption that happened to be convenient.

  • We verified the keystone limitation by testing the live EHR directly, not by reading marketing copy.
  • The EHR vendor confirmed the limitation in writing, in plain email.
  • That confirmation is the documented justification for every regulated table in the QMS.
  • Build on proof, and the system survives the audit and the inspection that follow.

Why this is firewalled from the parent brand

This clinic operates a Las Vegas franchise of an international stem-cell organization, and the parent brand carries its own reputation, its own claims, and its own scrutiny. The quality-management system is built as a clinic-operations asset, firewalled from the parent brand entirely. It is plumbing for how the clinic runs, proves compliance, and protects patient data, not a marketing claim about the science of stem cells. That separation is deliberate. It keeps the operations work clean, it keeps the regulated records in their own auditable lane, and it means the system can be described as exactly what it is: a quality-management system and an EHR integration for a clinic that has to operate inside a regulation. The same patterns apply to any first-clinic operator running a commercial EHR that does not hold the records their regulation requires.

  • The system is clinic operations and compliance plumbing, not a brand or science claim.
  • Regulated records live in their own auditable lane, separate from anything marketing-facing.
  • The patterns are reusable for any regulated clinic whose EHR cannot hold its compliance records.
  • Operations stay clean because the boundaries are drawn explicitly, in the build itself.

Related work

Run a regulated clinic on software that cannot hold your compliance records? Get a free clinic-systems audit and we will show you exactly where the gap is and how to close it. Get your free AI Audit.

It is the system that holds the records a regulation requires and the EHR cannot structure: lot-to-patient binding, chain of custody, QC release, and a recall query. The EHR runs booking, charting, and billing; the quality-management system runs compliance.

Next Step

Want a build like this for your business?

I'll map exactly where AI can save you time, cut costs, and drive revenue.

Unlock AI Audit