HIPAA compliant app development, control by control.

Sitting above all five is the minimum necessary standard, and it’s the one that reshapes a schema. A role check at the route (is this user a clinician, yes, render the chart) satisfies nothing. Minimum necessary is a row-level and column-level question: this clinician, for this encounter, may see these fields of this patient, and the billing coder beside them may see the diagnosis codes but not the psychotherapy notes. You get there with Postgres row-level security or an equivalent policy layer in the data access path, plus a break-glass route that grants emergency access and screams about it in the audit log. Decide it in week one and it’s a schema convention. Decide it in month six and it’s a rewrite of every query, the same arithmetic we lay out in our piece on rewriting versus refactoring a legacy codebase.

What follows is an illustration, not a description of delivered work. The telemedicine app architecture we’d propose puts every PHI read behind a single data access layer that emits an audit event with actor, patient, purpose and timestamp to an append-only store the application role cannot delete. That store has to outlive the record it describes. When a record is amended or purged, the trail of who read it must remain, so it can’t be a foreign key into the table it audits. Video runs through a HIPAA-eligible provider under a BAA rather than hand-rolled WebRTC, and clinical documents live in an object store with server-side encryption, deny-by-default policies and access logging turned on before the first upload rather than after.

The failure modes are boringly consistent, and three of them are logging bugs. PHI written into application logs and shipped to a third-party error tracker that has no BAA. Push-notification payloads carrying a patient name or an appointment reason, rendered on a lock screen by an operating system nobody in your compliance scope controls. The fix there is a content-free ping and a fetch after unlock, a decision that belongs in the mobile app architecture rather than patched later. Video-consult recordings landing in an unaudited bucket because a convenience feature shipped ahead of the retention policy. And session tokens with no server-side revocation, so a lost device stays authenticated for the life of the JWT.

The clinician and patient surfaces themselves are ordinary product engineering, built the way we build any Next.js web application with server components, a typed data layer, and real accessibility work, because a portal that fails keyboard navigation fails a meaningful share of the people it exists for. You can see how we write up scope and tradeoffs in the builds we have published.

If what you need is scheduling, charting, e-prescribing, claims and a patient portal for a practice, buy a vertical SaaS. Athenahealth, DrChrono and SimplePractice already carry the certified EHR module, the clearinghouse relationships, the prescribing integrations and the compliance paperwork, and no custom build at any budget we’d quote reaches parity. Video is the same story. Buy a HIPAA-eligible telehealth vendor rather than commissioning WebRTC infrastructure.

Custom earns its place when the workflow is the product and no vendor sells it: a remote monitoring pathway, a specialist triage tool, a payer-side data product, an app that has to sit on top of an EHR through SMART on FHIR rather than replace one. That’s the boundary, and it’s the same one we draw in choosing between in-house, an agency and a freelancer.

On budget, our published bands apply here without a healthcare surcharge: platforms from $28,000, mobile from $20,000, MVPs from $24,000, AI pilots from $7,500. Integration count and audit surface move the number inside those bands, not the word HIPAA. One SMART on FHIR connection to a sandbox is a few weeks. Three EHR vendors, an HL7 v2 feed and a de-identified analytics path is a different project.