What is a BAA and why does it matter?
Under HIPAA, any vendor that receives, maintains, transmits, or processes Protected Health Information (PHI) on behalf of a covered entity (your practice) is a Business Associate. Before that relationship begins, both parties must sign a Business Associate Agreement - a contract that specifies how PHI will be protected, what breach notification looks like, and what happens if the vendor is compromised.
This applies to your cloud hosting provider. If patient data lives on their servers - even encrypted - they are a Business Associate and a BAA is legally required. Operating without one is a HIPAA violation, regardless of how secure your application code is.
Important: A signed BAA does not make a provider HIPAA-compliant on its own. It establishes legal responsibility. You still need to configure the platform correctly - encryption at rest, TLS in transit, access controls, audit logging - which the Digital Wellness Academy platform does by default.
The BAA checklist
- ✓Hosting provider has signed a BAA with your practice (not just with Digital Wellness Academy)
- ✓Database encryption at rest enabled (AES-256 minimum)
- ✓TLS 1.2+ enforced on all network connections
- ✓Audit logging active on all PHI-adjacent reads and writes
- ✓Access controls scoped - providers see only their own patients
- ✓Breach notification procedure documented and tested
- ✓Third-party APIs that touch PHI also have BAAs (none in Digital Wellness Academy - by design)
Which hosting providers will sign a BAA?
This list covers the most common providers evaluated by healthcare IT teams. Always verify directly with the provider - BAA availability changes, and you need a current signed copy on file.
Providers that will sign a BAA
| Provider | BAA Availability | Notes | Best for Digital Wellness Academy |
|---|---|---|---|
| Amazon Web Services (AWS) | ✓ Available | Self-service BAA via AWS Artifact console. Covers EC2, RDS, S3, ECS, EKS, and most HIPAA-eligible services. Comprehensive compliance program. | EC2 + RDS + S3 for most deployments; ECS/EKS for container orchestration |
| Google Cloud Platform (GCP) | ✓ Available | BAA signed online via GCP console. Strong healthcare compliance program (HIPAA, HITRUST). Cloud Run and Cloud SQL are HIPAA-eligible. | Cloud Run (containers) + Cloud SQL (Postgres) + GCS (S3-compatible) |
| Microsoft Azure | ✓ Available | BAA included in Microsoft Online Services Terms. Broadest set of HIPAA-eligible services of any major provider. Strong for enterprise buyers already in the Microsoft ecosystem. | Azure App Service + Azure Database for PostgreSQL + Azure Container Instances |
| DigitalOcean | ✓ Business plan | BAA available on Business plan ($15/seat/month). Simpler than the hyperscalers. Good option for small practices that want a straightforward managed Postgres + Droplet deployment. | Managed PostgreSQL + Droplet (Docker) + Spaces (S3-compatible) |
| IBM Cloud | ✓ Available | BAA available; IBM has a strong healthcare pedigree (Watson Health history). Less common for new deployments but well-suited for enterprise health systems. | Code Engine (containers) + IBM Db2/PostgreSQL |
| Oracle Cloud Infrastructure | ✓ Available | BAA available. Strong choice if the practice already uses Oracle for EHR or billing systems. OCI's Always Free tier can cover dev/staging. | Container Instances + Autonomous Database (Postgres-compatible) |
| Rackspace | ✓ Available | Managed cloud with dedicated HIPAA support. Good for practices that want white-glove management rather than self-service infrastructure. | Managed hosting tier |
| Vercel (Enterprise) | ✓ Enterprise only | BAA only on Vercel Enterprise plan. Vercel Hobby and Pro plans do NOT qualify. For Next.js-native deployments this is the most frictionless path - but Enterprise pricing applies. | Next.js app layer only (pair with a BAA-compliant Postgres/Redis provider for data) |
Providers that will NOT sign a BAA
| Provider | BAA Status | Why it matters |
|---|---|---|
| Hostinger | ✗ No BAA | Shared hosting architecture with no HIPAA offering. Cannot be used for any patient-facing application that processes PHI. Suitable for static marketing pages only if no patient data is involved. |
| Vercel (Hobby / Pro) | ✗ No BAA | Free and Pro plans have no BAA option. Common mistake: developers deploy a Next.js app to Vercel Pro thinking the encrypted deployment is HIPAA compliant. It is not - the missing BAA is the gap. |
| Netlify | ✗ No BAA | No BAA available on any plan. Do not use for clinical applications. |
| GoDaddy / Bluehost / DreamHost | ✗ No BAA | Shared hosting providers. No BAA, no dedicated infrastructure, no HIPAA eligibility. Appropriate only for static marketing sites with zero PHI. |
| Railway / Render (standard plans) | ⚠ Verify | Popular developer-friendly PaaS options. BAA availability is limited or absent on standard plans - verify directly before any clinical deployment. |
Provider BAA policies change. Always verify directly with the vendor and get a current signed copy before go-live. This table reflects information available as of April 2026.
How the Digital Wellness Academy platform is designed to be portable
Every infrastructure choice was made to avoid provider lock-in. A practice that starts on AWS can move to GCP or DigitalOcean without rewriting the application.
Fully containerized (Docker)
The entire stack ships as a docker-compose.yml: Next.js app, PostgreSQL, Redis, and the FastAPI MAIA classifier sidecar. Any cloud that can run containers can run Digital Wellness Academy - no proprietary runtime dependencies.
Standard PostgreSQL - no proprietary DB
The data layer runs on vanilla PostgreSQL. No Aurora-specific extensions, no Cosmos DB APIs, no Google Spanner. You can run managed Postgres on AWS RDS, GCP Cloud SQL, Azure Database for PostgreSQL, DigitalOcean Managed Databases, or self-hosted - the application doesn't care.
S3-compatible object storage
File storage uses the S3 API (via MinIO in dev). In production, point the S3_ENDPOINT env var at AWS S3, GCS (S3-compatible), DigitalOcean Spaces, Backblaze B2, or any other S3-compatible provider. No code change required.
AI safety service is self-hosted
The MAIA distress classifier runs in its own Docker container - not on a third-party API. This means patient text never crosses an external API boundary, and the classifier moves with the deployment. Swap cloud providers; the safety layer follows.
Crisis detection is expanding beyond English: a multilingual MAIA distress classifier covering English, Spanish, and Brazilian Portuguese has been trained and validated on a Nebius L40S GPU. English runs at the production safety bar today; Spanish and Brazilian Portuguese are in clinical review before activation.
Environment-variable configuration
All provider-specific values - database URL, Redis endpoint, S3 bucket/endpoint, SMTP provider, Stripe keys - are injected via environment variables. Switching providers is a config change, not a code change. No hardcoded provider SDKs in the application layer.
Database migrations are versioned
Schema migrations live in code, versioned with the application. On a new deployment (or a provider migration), the Docker entrypoint runs migrations automatically before starting the server. Fresh database, correct schema, zero manual steps.
Typical migration path when a practice goes live
AI coaching & the LLM BAA question
This is the question every HIPAA-conscious IT team asks - and the answer is more nuanced than most platforms admit.
The rule: a BAA is required whenever PHI crosses an API boundary
If a coaching prompt contains a patient's name, diagnosis, assessment scores, or any other PHI, the LLM provider receiving that prompt is a Business Associate and must have a signed BAA. The cleanest solution is to not cross any external boundary at all.
When coaching context contains only course/lesson content (no patient identity, no clinical history, no assessment scores), no PHI crosses the API. OpenRouter works fine here and no BAA is needed with the LLM provider.
OpenRouter is a routing proxy and does not offer a BAA. If a coaching prompt includes clinical context from the therapeutic school (PHQ-9 scores, provider notes, treatment goals), OpenRouter cannot legally be in the request chain. The platform detects this mode and routes around it.
When therapeutic integration is active, the platform bypasses OpenRouter and calls OpenAI or Anthropic directly. Both offer BAAs under their enterprise agreements. The practice's Digital Wellness Academy deployment is configured with direct API keys for this mode.
The platform supports routing all AI coaching through a small open-source model running locally on the VPS via Ollama. When inference happens entirely within your own infrastructure, no PHI crosses any external boundary - and no LLM vendor BAA is required at all.
- → Fine-tune a 3-7B model on your content using QLoRA - free GPU hours on Kaggle (30hr/week) or Colab are sufficient
- → Deploy quantized GGUF weights via Ollama on any GPU-enabled instance (VPS GPU addon, RunPod serverless, or dedicated inference node)
- → Platform calls an internal endpoint - inference stays within your infrastructure boundary
- → Optimization School continues using OpenRouter (no PHI, no change needed)
Zero PII shared by default
Most mental health platforms share everything with the practice automatically. Digital Wellness Academy inverts this: nothing is shared unless the practice explicitly opts in. This architecture serves two goals - HIPAA risk containment and learner trust.
Platform is a closed loop
By default, no patient data flows to the practice. The learner's course activity, assessment scores, mood logs, and distress events stay inside the platform. The practice has no visibility - not because of a technical limitation, but because this is the default state.
- ✓Works for Optimization School - no BAA needed, no clinical oversight required
- ✓Works for self-directed therapeutic learners who aren't connected to a provider on the platform
- ✓AI coaching uses PHI-free prompts - OpenRouter is compliant in this mode
Practice enables provider coordination
When a practice enables therapeutic integration, a provider-patient relationship is established on the platform. The patient must consent. Once linked, the provider gains access to a scoped dashboard showing that patient's PHQ-9/GAD-7 trends, course activity summaries, and distress alerts - nothing else.
- →Requires: cloud hosting BAA + Digital Wellness Academy BAA + patient consent
- →AI coaching switches to direct OpenAI/Anthropic (bypasses OpenRouter)
- →Provider sees aggregated outcomes - never raw journal text or free-form responses
- →Crisis alerts route to the assigned provider immediately
- →Audit log captures every PHI-adjacent event with retention enforced at 2557 days
What providers see - and what they never see
This applies to the opt-in therapeutic integration mode. In default mode, providers see nothing.
- ✓ PHQ-9 / GAD-7 / PCL-5 score trends over time
- ✓ Which courses are enrolled and completion status
- ✓ 30-day mood rolling average (numeric, not text)
- ✓ Active alert episodes: urgency tier, transcript excerpt (alias-coded), pre-computed lesson suggestions
- ✓ Days active on platform in last 30 days
- ✗ Routine thought records, journal entries, or free-text responses (these stay between the patient and their reflection; only the transcript excerpt at the moment of an alert episode is surfaced, alias-coded)
- ✗ Lesson content the patient viewed
- ✗ Quiz answers or individual question responses
- ✗ Optimization School activity (isolated by design)
- ✗ Data from other providers' patients
- ✗ Any data if the patient revokes consent
Frequently asked questions
Does Digital Wellness Academy sign a BAA with licensee practices?
Yes. Digital Wellness Academy signs a BAA with every licensed practice before go-live. This covers Digital Wellness Academy's role as the platform provider. The practice also needs a separate BAA with their chosen cloud hosting provider, since that provider hosts the actual infrastructure.
Can I run Digital Wellness Academy on my own on-premises servers?
Yes. Because the platform is fully containerized with no cloud-specific dependencies, it can be deployed on bare-metal servers in a HIPAA-compliant data center or on-premises. You would still need physical security controls, encrypted storage, and documented breach procedures - but the application itself has no requirement for a specific cloud provider.
Does the MAIA classifier send data to any external API?
No. The classifier runs entirely within your infrastructure. Patient text is sent to an internal FastAPI container, processed in memory, and the text is discarded after inference - only the label and confidence score are stored. No patient text ever crosses an external API boundary.
What about the AI coaching features - do those send data to OpenAI or Anthropic?
This depends on which school the patient is enrolled in and whether the practice has opted into therapeutic integration.
- ✓Optimization School (default): No PHI involved. Coaching prompts contain only course/lesson context - no patient name, diagnosis, or clinical history. OpenRouter is fine here; no BAA required with the LLM provider.
- ⚠Therapeutic School with practice integration enabled: If the practice opts into the provider-coordination layer, coaching prompts may include clinical context (assessment scores, treatment goals). In this mode, the system bypasses OpenRouter and calls OpenAI or Anthropic directly - both offer enterprise BAAs. OpenRouter cannot be used for PHI-adjacent LLM calls because OpenRouter does not offer a BAA.
- ✓✓Self-hosted LLM (advanced): A fine-tuned open-source model (Phi-3 Mini, Mistral 7B) running on your own VPS via Ollama removes the AI vendor from the equation entirely. No external LLM API call is made, so no LLM vendor BAA is needed. The coaching inference stays within your existing hosting BAA boundary - note that this eliminates the AI vendor BAA, not the hosting provider BAA, which is still required.
The AI coaching feature can also be disabled entirely for therapeutic-school deployments that prefer to keep all AI inference on-platform via the MAIA classifier only.
We're already on AWS - how long does BAA setup take?
AWS BAA activation is self-service through the AWS Artifact console and takes under 10 minutes. The main timeline driver is internal legal review on the practice side. Most practices complete BAA setup within 1-3 business days once legal has reviewed the AWS Online Service Terms. Digital Wellness Academy provides a go-live checklist that includes BAA verification as a gate.
Ready to start the compliance conversation?
Our onboarding team will walk your IT department through the BAA checklist, provider selection, and deployment architecture. Most practices are live within 30 days.