Productionizing a Vibe-Coded Healthcare Denial Review Application Built on Base44
[ client & product overview/ ]
ClinicalDenialPro began as an internal tool created directly by a physician using Base44. The prototype combined clinical-domain knowledge with AI-assisted transcription and document generation and had already been used successfully at one location.
That success created the next problem. The tool was no longer just an experiment. Real patient data was already being processed, other users were beginning to rely on it, and Anova was considering broader deployment across its hospital operations.
The software therefore needed to move from a working physician-built prototype to a production system that could handle PHI across multiple users and sites with controlled access, auditability, recovery, monitoring, and ongoing engineering support.
[ product workflow/ ]
How ClinicalDenialPro Works
Denial-appeal drafting is a separate workflow: the advisor enters the clinical context, Claude generates the draft, and the saved letter remains searchable with its downloadable PDF.
ClinicalDenialPro workflow showing where the physician advisor works directly and where the system assists with transcription and document generation.
Case management. Site and physician values come from organization-managed lists that administrators can update without a deployment.
Analytics across denial-review activity. The dashboard shows overturn rates, status-review outcomes, and physician response rates, filterable by provider and date. Screenshots show synthetic demonstration data.
Executive Summary
But broader adoption changed the engineering requirements.
ClinicalDenialPro was already processing real patient information. MEV’s Phase 0 assessment found that the prototype’s access model, backup strategy, data exports, speech processing, admin functions, and hosting needed changes before it could scale under HIPAA.
MEV first mapped the real data flows and audited the production dataset. The assessment covered 1,325 case rows and 237 generated letters and established a verified baseline for migration.
- contain immediate PHI and operational risks without breaking the working clinical workflow
- re-engineer the application around controlled AWS infrastructure, server-side authorization, MFA, auditability, encrypted storage, reliable backups, and protected AI and speech-processing paths
The production migration and cutover are now complete. ClinicalDenialPro runs on the rebuilt AWS platform, every product screen uses the new API, and the Base44/low-code SDK is no longer part of the active production application.
[ productionization scope/ ]
Audit PHI flows and security risks in a Base44 healthcare application
Contain unsafe PHI paths before the full rebuild
Migrate healthcare data without losing historical case records
Replace the Base44 Backend with FastAPI and PostgreSQL
Enforce healthcare organization boundaries across the backend
Move AI and dictation into a HIPAA-covered AWS boundary
Add Auditability, Backup, Recovery, Monitoring, and CI/CD
[ constraints/ ]
The application was already useful and already handling PHI
MEV could not simply rebuild the application from scratch and assume the behavior would remain equivalent. The productionization work had to preserve the user flow, AI prompts, payer-document formats, case history, search, analytics, and peer-to-peer tooling while substantially changing the infrastructure underneath.
Unsafe Data Paths Had to Be Closed Without Losing the Existing Dataset
Healthcare Data Access Had to Move Beyond the Frontend
This is especially problematic when moving from a small pilot toward multiple users, sites, and covered entities.
MEV therefore moved the authorization model from what the browser displays to what the backend permits.
AI and Voice Were Valuable Product Features but Also PHI Data Paths
[ how we did it/ ]
MEV started with the working Base44 application, production data, users, service functions, exports, AI calls, speech processing, backups, and third-party dependencies.
This established what the application actually did, where PHI moved, which parts of the physician workflow had to remain unchanged, and which prototype assumptions could not survive broader deployment.
The assessment also created the source-of-truth dataset used later for migration reconciliation.
The original application had no proper recoverable backup.
That determined the remediation sequence:
Create backup → verify record counts and sample data → close the email path → verify the old endpoints no longer work.
Once the backup was verified, the team removed the recurring export, its sending functions, and related triggers. Containment also included revoking excessive admin access, purging inactive accounts, rotating service keys, and removing exposed debug/migration functions.
The rebuilt application exposes one public domain through CloudFront. Static frontend assets serve from S3, while /api traffic routes to an internal load balancer and the FastAPI app. PostgreSQL remains private. Cognito, Amazon Bedrock, and Amazon Transcribe are invoked server-side rather than from browser code. The backend controls authentication, tenant access, validation, persistence, exports, analytics, and data writes.
Prototype: the frontend requested and filtered data
Production: the backend determines what an authenticated user is allowed to retrieve or change
MEV tested a repeatable migration process covering cases, users, denial letters, site assignments, duplicates, dates, and identifiers. The Phase 0 dry run showed zero record loss.
.svg)
Voice input was part of the useful physician workflow, but the prototype relied on browser speech recognition. Because dictated clinical narratives can contain PHI, MEV replaced browser speech recognition with HIPAA-eligible Amazon Transcribe.
The production flow is:
Physician dictates → application sends audio through the controlled AWS path → Amazon Transcribe creates the transcript → transcript returns to the application → physician reviews it.
- The browser Web Speech API is removed from the production flow, and typed input remains available if transcription fails.
- This allowed the product to preserve dictation without preserving the prototype's uncontrolled speech-processing path.
- Dictation and AI drafting are pinned to approved US regions at application startup rather than selected dynamically for individual requests.
Peer-to-peer workflow with in-app dictation. Voice input is processed through the application rather than the browser's native speech service. Screenshots show synthetic demonstration data.
Claude was already producing useful denial-review documents, so MEV did not replace the model simply because the surrounding architecture changed.
The migration approach was:
Existing prompts → preserved first → Claude accessed through Amazon Bedrock → output compared with the prototype → prompt tuning only after migration validation.
The design also removes patient identifiers before the model request where possible and restores them only during final document rendering.
This separates the two engineering questions, making regressions easier to diagnose during migration:
- Does the migrated AI workflow behave like the working prototype?
- Can the prompts be improved afterward?
AI-assisted denial-appeal workflow. The advisor enters clinical facts in natural language and selects relevant diagnosis sections before generating the draft. Screenshot uses synthetic demonstration data.
The Base44 prototype contained physician/advisor names directly in application code and enums. That becomes problematic once the application is used operationally: adding or deactivating a physician should not require a software deployment, and organization-specific rosters should not depend on browser-side values.
MEV redesigned these rosters as database-managed entities associated with the appropriate organization and site.
Site and physician values now come from organization-managed application data rather than hardcoded frontend values. Authorized administrators can update these lists without a software deployment. The backend validates the organization and site context when those values are used. This is a common productionization step that is easy to overlook: prototype configuration becomes managed business data.
ClinicalDenialPro supports two separate covered entities within one deployment. Organization scope is applied in a shared backend access layer that every data query passes through rather than being implemented separately in individual screens or endpoints. The application derives that scope from authenticated identity rather than trusting organization values supplied by the browser.
MEV also made the boundary testable: every backend route is classified for its organization scope, and the test suite fails if a route is introduced without that classification. This turns organization isolation into an application-wide engineering rule rather than something each developer has to remember to add.
AWS CloudTrail records cloud infrastructure activity, but it cannot answer application-level questions such as who viewed a specific patient record.
To close this gap, ClinicalDenialPro records all patient-data reads and modifications in a dedicated application audit trail.
Rather than logging raw DB ops, MEV built the audit trail around user intent. Batch actions (like loading 50 cases at once) share a single request ID to map to one browsing event, while analytics dashboards emit aggregate logs to avoid false patient-read triggers.
Letter-generation events also record the model that actually produced the response.
CloudTrail → AWS infrastructure activity
Application audit log → patient-data activity
Rather than running a one-off export script, MEV built the Base44-to-PostgreSQL migration as a repeatable, multi-stage pipeline:
- Dry-Run Validation: Writes nothing by default. The initial pass flags invalid records—such as missing IDs or schema mismatches—logging the original source ID and rejection reason for review.
- Strict Reconciliation: Migrated records are explicitly reconciled against the source dataset rather than assumed correct upon import completion. This prevents the pipeline from silently guessing, altering, or dropping sensitive healthcare data.
- Zero-Loss Cutover: The Phase 0 rehearsal reconciled all target tables with zero record loss, paving the way for a seamless production cutover.
.svg)
Flow-migration diagram
The production workflow is now supported by repeatable engineering controls rather than knowledge held only by the physician who originally built the prototype.
Backend changes must pass linting, formatting, strict type checking, and automated tests against a real PostgreSQL database. Frontend changes must pass linting, tests, and a production build.
CI additionally checks the full database migration chain, audits dependencies for vulnerabilities, and scans the built application image.
Every backend route is also checked for organization-boundary classification before it can pass the test suite.
The production migration and cutover are complete, and the frontend no longer contains the low-code SDK. A test fails the build if the SDK is imported or added back.
Before and After
HIPAA Safeguards in Production
Because ClinicalDenialPro handles PHI under HIPAA, productionization also required changing how patient data is accessed, stored, transmitted, audited, and processed by AI and speech services.
[ results/ ]
Production Migration and Cutover Completed
Zero Record Loss in the Phase 0 Migration Dry Run
Core Clinical Workflows Running on the Rebuilt Platform
HIPAA Access and Audit Controls Enforced
[ portfolio/ ]
