How SEM Nexus Builds HIPAA-Compliant Patient Portals That Ship in 5 Months
Healthcare mobile apps slip more than any other category we work in. The engineering itself isn't dramatically harder than other categories — most healthcare app code is just CRUD with extra rules. What makes the category slip is that founders consistently underestimate four things: HIPAA compliance, patient UX requirements, EHR integrations, and App Store medical-content review. Each adds weeks the agency didn't budget for, and the cumulative effect is a 3-month slip.
SEM Nexus has shipped HIPAA-compliant patient portals (most notably the 360 Medical Consulting patient portal) in 5 months by treating each of these four areas as first-class engineering deliverables, not "we'll figure it out" features. This post is the playbook.
Why healthcare mobile slips (and how SEM Nexus designs against it)
Four sources of slip, each with a SEM Nexus answer.
1. HIPAA compliance, end-to-end
"We'll use a HIPAA-compliant database" is necessary but nowhere near sufficient. Real HIPAA compliance touches every layer of the stack:
- Encryption at rest and in transit — table-stakes, easy
- Access logging on every PHI touch — non-trivial; most apps don't log this thoroughly enough
- BAA agreements with every third-party vendor — auth, analytics, push notifications, error monitoring, anything that could see PHI. Each vendor has a separate BAA process.
- Workforce training documentation — required, often forgotten
- Breach notification procedures — written, not assumed
- Written security risk assessment — required documentation, not optional
We add 3–4 weeks to every healthcare build for HIPAA work explicitly. That's not slack — it's the actual time to execute the compliance properly. Founders sometimes ask if we can compress it. We can't, honestly. The compliance is the compliance.
2. Patient UX — different from consumer UX
Patients are not consumer-app users. They include older adults with poor vision and large fingers, anxious users in crisis moments, multilingual users, users with accessibility needs that are not optional. Onboarding flows that work in a fintech app feel hostile in a healthcare app.
Patterns we always include:
- Tap target size minimum 44pt × 44pt (Apple HIG minimum), realistically 56pt for primary actions
- Dynamic type support across all text. Patients with low vision use the largest accessibility text sizes
- Plain-language copy. "Your prescription is ready" beats "Rx awaiting fulfillment"
- Graceful failure on every form. Network errors, expired sessions, invalid input — all need clear, non-technical recovery paths
- No surprise dark patterns. No interstitial ads, no engagement notifications at odd hours, no pressure to enable features they don't need
We budget 2–3 weeks for the patient-UX layer beyond what a standard consumer-app build would need. Skipping it produces TestFlight betas where 3 out of 20 users can't get past sign-up.
3. EHR and clinical-system integrations
If your patient portal reads from or writes to an Electronic Health Record system — Epic, Cerner, athenahealth, or a partner platform — this is almost always under-scoped.
- Sandbox accounts take 4–8 weeks to provision
- Vendor documentation is partial
- Integrations are stateful in subtle ways (token refresh, session timeouts, locale handling)
For 360 Medical Consulting, the practice integrated with a partner scheduling system. We budgeted 5 weeks explicitly for the integration work. It came in on budget because we named it as a sprint goal, not a hand-wave.
4. App Store medical-content review
Apple's review for health and medical apps is meaningfully stricter than for consumer apps. Anything that could be interpreted as diagnosis, anything that touches medication, anything that records or analyzes biometric data, anything that claims a clinical outcome — each can trigger a held submission for 2–3 weeks while you re-write metadata or restructure the feature.
We submit healthcare apps 2 weeks earlier than the v1 launch target, on a buffer specifically for review delays. Most reviews come back clean on the first pass because we know what triggers rejection. When they don't, the buffer absorbs the rework.
Want a healthcare mobile build that ships in 5 months with HIPAA work scoped honestly? SEM Nexus's two-week discovery maps all four risk areas in writing so they aren't surprises at sprint 8.
The 360 Medical Consulting build, week by week
The 360 Medical Consulting patient portal — Angular + Ionic, HIPAA-compliant, integrated with the practice's scheduling system — shipped in 20 weeks. The week-by-week shape:
| Weeks | Work |
|---|---|
| 1–2 | Discovery: feature scope, technical recommendation, HIPAA vendor audit |
| 3–4 | Auth + HIPAA scaffolding (encryption layer, access logging, BAA work) |
| 5–6 | Primary patient flows: appointments, messaging, records view |
| 7–10 | Clinical-system integration (4 weeks provisioning + 1 week integration) |
| 11–12 | Patient UX polish: accessibility audit, dynamic type, screen-reader pass |
| 13–14 | Closed beta with 10 real patients including 3 over age 60 |
| 15–16 | Beta feedback fixes |
| 17–18 | App Store submission (early), submission held 2 weeks for medical-content review |
| 19 | Restructured metadata, resubmitted, approved |
| 20 | Public launch + monitoring |
The 5-month timeline is real. It includes the compliance work, the integration work, the UX work, and the review work — all named explicitly. There were no surprise weeks.
The HIPAA-vendor question
Most healthcare app founders don't realize how many "standard" mobile vendors require a separate HIPAA-compliant tier with a BAA:
- Firebase: HIPAA-compliant only on enterprise with a BAA from Google. Free tier is not BAA-eligible.
- OneSignal / Pusher / Twilio: HIPAA-compliant tiers exist; the contract has to include the BAA.
- Mixpanel / Amplitude / GA: generally NOT HIPAA-compliant for tracking PHI. Use a HIPAA-compliant analytics vendor or strict PHI-redaction layer.
- Sentry / Bugsnag / Rollbar: error monitoring catches stack traces that can include PHI. Need either explicit redaction or HIPAA-tier vendor agreement.
- Auth0: HIPAA-compliant on enterprise only.
Every vendor in your stack needs to either (a) have a signed BAA, or (b) not touch PHI. Auditing this is week-long work that we do during discovery. Most founders haven't started this audit before they sign with an agency, and they're surprised when it takes 3–4 weeks.
What this means for healthcare founders
If you're scoping a HIPAA-compliant mobile app, the realistic timeline is 5 months minimum with proper compliance work. Any agency quoting 3 months is either skipping compliance or planning to silently re-quote. Quoting 8+ months means the agency is including margin for the compliance work they don't know how to do efficiently.
SEM Nexus's 5-month timeline is honest. It includes:
- 2 weeks for discovery + HIPAA vendor audit
- 16 weeks of build with compliance work folded into every sprint
- 2 weeks of App Store review buffer
- Public launch at week 20
If you'd like a healthcare app built with this honesty, SEM Nexus's discovery starts with the four risk areas in writing — HIPAA, patient UX, EHR integration, App Store review. The compliance isn't optional, the time isn't padded, and the build holds because all four areas were named at sprint 0, not sprint 12.
We've shipped HIPAA-compliant patient portals before. We know where the time goes. That's why our healthcare clients ship on time when the same projects at other agencies slip by months.
