A vibe-coded healthcare prototype can reach a working demo before anyone has reviewed where patient data travels.
That creates an engineering problem once the app starts handling protected health information. Generated code may expose database credentials in the client bundle, return records before authorization runs, or send PHI to services without a Business Associate Agreement.
20 checks MEV engineers use before a healthcare app handles PHI
Based on healthcare project work, MEV engineers use this 20-point checklist to review AI-built healthcare applications before production. It covers the technical controls that need attention before the app handles protected health information.
- Sign a BAA with every vendor in the PHI path.
- Determine whether FDA medical device requirements apply.
- Complete a security risk analysis and inventory every location containing ePHI.
- Configure session expiration.
- Enforce role and relationship-based authorization on the server, down to the record level.
- Scope database credentials to the access each service requires.
- Keep secrets on the server and out of browser code.
- Tokenize identifiers where appropriate and store the mapping separately.
- Encrypt PHI wherever it is stored, including file storage.
- Keep deidentified datasets outside production.
- Test backup restoration.
- Remove identifiers before model calls and keep them out of logs.
- Verify model provider retention settings and endpoint eligibility.
- Add prompt injection defenses before model input can trigger tool calls.
- Put limits on model usage per user and across the application.
- Build handlers that can recover from failures without losing events.
- Maintain an access log the application cannot rewrite.
- Configure alerts for suspicious access.
- Test database queries against production-scale data.
- Choose the EHR integration path before the application's data model becomes expensive to change.
For developers, several architecture decisions deserve attention first.
1. Trace the PHI flow before changing code
Start by mapping every place electronic protected health information enters, moves, and gets stored.
Inspect:
- database tables and file storage
- logs and monitoring destinations
- analytics integrations
- model providers
- backups and preview environments
Generated applications can create storage buckets or outbound integrations during development. Reviewing the schema alone will miss those paths.
Run the application while recording outbound network calls. Compare what you observe with the vendors listed in your architecture.
Every vendor receiving PHI needs to fit your HIPAA arrangement, including the platform used to create or host the prototype.
2. Enforce authorization before records leave the server
One pattern we see in generated apps fetches a broad patient dataset and filters records in frontend code.
The UI may display the expected records while the network response contains data for other patients.
Put access checks on the server.
For healthcare applications, role-based access control usually needs record-level relationships as well. A nurse role defines the type of access. The patient's relationship to that nurse defines which records the account can read.
Database row-level security or backend middleware can enforce this before the query result reaches the browser. Test the rule with a second account and call the endpoint directly.
3. Audit your client bundle and Git history for secrets
Vite exposes environment variables prefixed with VITE_. Next.js does the same with NEXT_PUBLIC_.
A generated fix for an environment variable problem can therefore move a credential directly into browser JavaScript.
Git history creates a second exposure path. Removing .env from the current branch leaves earlier commits intact.
Use this remediation order:
Rotate exposed credentials and revoke the old values.
Move private credentials behind your backend.
Remove the secrets from repository history.
Search the production bundle before deployment.
Rotation belongs first because repository cleanup leaves copied credentials usable.
4. Give LLM tools the same permissions as users
Model integrations add another access path to patient records.
If an LLM can call a record lookup tool, run that request through the same authorization layer used by your application. Give each tool a scoped credential and validate model-supplied arguments on the server.
This matters for prompt injection. A document uploaded by a patient can contain instructions intended for the model. Tool permissions determine how far such an instruction can reach.
OWASP ranks prompt injection first among its risks for LLM applications.
5. Design webhooks for retries and partial failure
EHR and scheduling systems often send clinical events through webhooks. Processing the entire event before returning a response creates problems when either side times out.
A safer flow looks like this:
sender → signature verification → queue → 200 response → worker
Store processed event IDs so retries remain idempotent.
The queue preserves the event when downstream processing fails, while signature verification protects the public webhook endpoint.
Plan EHR integration before your schema settles
Epic and Oracle Health integrations commonly involve HL7 v2, FHIR, or both. An interoperability layer may sit between your application and the hospital system.
That choice affects your data model.
FHIR already defines relationships between resources such as patients and encounters. If your generated schema models those concepts differently, integration can force changes across queries and production data later.
We have seen the same principle matter during broader hardening work. In one Base44 healthcare application MEV is rebuilding, the audit found more than 28 publicly exposed debug endpoints. The migration dry run later moved 1,325 case records, 1,037 patients, and 237 letters with zero record loss.
If you already have a working AI-generated prototype, vibe-coded app hardening covers the engineering work required to take that codebase through audit, remediation, and production preparation.
Top comments (0)