Skip to main content

CAPABILITY · VERTICAL-SPECIFIC

Med Spa Intake & Triage

Contraindication-aware intake that routes every prospect before a human touches the file.

$8,500 build · $2,500–4,500/mo

Talk to us about a Med Spa Intake & Triage build →

What it does

Runs a structured intake collecting medical history, treatment interest, and contraindication flags. Routes clean leads to booking, flags clinical holds to the injector via Slack, and writes the intake record to your EHR. HIPAA-covered on AWS Bedrock.

Most med spa front desks are staffed by people who are good at scheduling, great at first impressions, and not trained to catch a contraindication. That's not a criticism — it's just not their job. But the calls keep coming: a patient interested in Botox who mentions she's on warfarin in passing, a laser consult candidate who used a retinoid three days ago, a filler inquiry from someone who had a recent dental procedure and isn't sure if that matters. It does matter. And the person answering the phone doesn't always know what to do with it.

The usual workaround is a paper or PDF intake form the patient fills out before the consult. The problem is timing — by the time the injector reads it, the appointment is already booked, the patient is already in the chair, and rescheduling at that point costs the practice a slot and the patient their afternoon. The flag needed to surface before the booking, not during it.

This build puts a structured intake in front of every inbound prospect — via web form, SMS, or voice — before a booking slot is ever offered. The intake collects treatment interest, medical history fields relevant to the treatment category, current medications, recent procedures, and skin history for laser candidates. When the responses come in, the system routes automatically: clean intakes with no flags go straight to the booking link. Intakes with a contraindication-relevant response — blood thinners and injectables, isotretinoin or retinoid use and laser, recent filler and proposed filler in overlapping zones — get held and a structured summary goes to the injector or nurse via Slack for a callback decision. Ambiguous responses get a second-pass clarification question before routing.

The injector or nurse makes the clinical call. The system doesn't. What it does is make sure the right information reaches the right person before a slot gets committed, not after. That's the only job.

The build runs on AWS Bedrock under a signed Business Associate Agreement, which means the PHI collected during intake — names, health history responses, contact info — stays inside a HIPAA-covered infrastructure from first touch. Intake records write to your practice management system (Boulevard or Aesthetic Record, depending on your stack) so the injector's chart prep starts with a pre-populated document, not a blank form. Golden Horizons handles the BAA, the Bedrock deployment, and the integration wiring.

Use cases

  • A patient books a Botox consult online but notes she takes a daily blood thinner. Intake flags the medication response, holds the booking, and pings the injector via Slack with the patient's full intake summary for a pre-appointment callback.
  • A laser hair removal inquiry comes in via SMS. The intake asks about isotretinoin and recent retinoid use. The patient notes a topical retinol used two days prior. The system holds the booking and routes the flag to the nurse with a suggested reschedule window.
  • A new patient submits a filler inquiry form. No contraindication flags fire. The intake writes to Aesthetic Record and the patient receives a booking link directly — no front-desk review needed.
  • A weight-loss program lead fills out the intake with a history of thyroid medication and a prior GLP-1 prescription. The system flags the medication history for provider review and routes the lead to a medical director callback queue instead of standard scheduling.
  • A semi-permanent makeup inquiry comes in. The intake screens for blood-thinning medications, skin conditions in the treatment area, and prior permanent makeup. Clean responses route to a booking link. A flagged skin condition response holds the booking and notifies the technician.
  • An HRT consultation request arrives after hours via web form. The intake collects hormone history, current medications, and relevant symptoms. The completed intake writes to the EHR and queues a provider callback for the next business morning — no slot offered until the provider reviews.

What’s included

  • Fixed scope with written acceptance criteria before any build starts
  • Customization layer for your brand voice and business rules
  • Clean handover with documented runbook and live training
  • Monthly ROI report for three months post-delivery
  • Source code delivered to your GitHub on handover

What’s NOT included

  • Third-party API subscription costs (billed to your accounts)
  • Data migration from legacy systems
  • Ongoing infrastructure costs after handover

Retainer

Monthly retainer covers monitoring, prompt tuning, config refinement, and minor integration additions. Range: $2,500–4,500/mo.

HIPAA-covered when sold to a clinical entity. Pinned to AWS Bedrock with executed BAA before go-live.

How clients use this

Fixed-scope build with clean handover, then an optional monthly retainer covering maintenance, monitoring, and minor changes. Most clients move to retainer within 60 days of delivery.

Part of

Used in: Dental Practices

Questions Med Spa Intake & Triage clients ask

Is the intake actually HIPAA-covered, and do we get a signed BAA?

Yes on both. The build runs on AWS Bedrock, which is a HIPAA-eligible service under Amazon's standard BAA. Before any PHI touches the system — meaning before the first patient fills out a form — you receive a signed Business Associate Agreement from Golden Horizons covering the build and the infrastructure. The BAA is not an add-on; it's part of every med-spa engagement. Intake responses, health history fields, and contact data stay inside the Bedrock environment. Nothing routes through a non-covered third-party service for processing. If your practice has specific data residency requirements or an existing information security policy, we review it before the build scopes so the architecture matches your compliance posture from day one.

Does the system make clinical decisions, or is that still on our injector?

The system makes routing decisions, not clinical decisions. There's a meaningful difference. When a patient discloses a blood thinner, the system flags that response and holds the booking — it does not tell the patient whether Botox is safe, whether they need to pause the medication, or what the clinical risk is. It surfaces the information to your injector or nurse with enough context for them to make that call before the appointment slot is committed. The clinical judgment stays with the licensed provider. The build is designed so that every flag results in a human review, not an automated approval or denial. If your clinical team wants to define additional flag categories or adjust the routing thresholds — say, flagging all patients on anticoagulants rather than just those on specific medications — we build to their specification.

What happens when a flagged intake needs an injector callback — does the system handle that communication?

The system handles the notification and the hold, not the callback itself. When a flag fires, the injector or designated nurse receives a Slack message with the patient's name, the treatment they inquired about, and a structured summary of the intake responses that triggered the flag. The message includes a direct link to the full intake record in your practice management system. The callback — the actual clinical conversation — happens between your provider and the patient by phone or through your existing messaging channel. After the callback, the provider can either clear the patient for booking (which releases the booking link) or document the hold. The system tracks the flag status so no flagged intake falls through the scheduling queue without a documented resolution.

Can this integrate with our existing practice management system?

The default integrations are Boulevard and Aesthetic Record, which cover the majority of med-spa stacks. If your practice runs on a different platform — Jane App, Vagaro, or a custom EHR — we scope the integration during the build kickoff. The intake record that writes to your PMS includes the fields your injectors already expect: patient name, contact info, treatment interest, and the structured health history responses. If your clinical team uses a specific chart template for pre-consult prep, we match the output format to that template so the injector isn't reading a foreign document. For practices that prefer to keep the intake record outside the PMS until provider review, the build can hold intake data in a reviewed queue and write to the chart only after the provider clears the flag.

How does the build handle liability — are we exposed if the system misses a contraindication flag?

The build is a routing and documentation tool, not a clinical safety system, and it's scoped that way in the contract. The intake questions and the flag logic are defined by your clinical team during build kickoff — we implement what your injectors and medical director specify, not a generic contraindication library we invented. That means the flag coverage is yours to define and yours to own clinically. The system's job is to make sure every patient answer reaches the right person before a booking is confirmed. It doesn't catch contraindications your intake questions didn't ask about. Standard of care and clinical judgment remain with your licensed providers. We recommend having your medical director review the intake question set and routing logic before go-live, and we structure the build documentation to support that review.

Start with an audit →