Back to IPS-Builds.com
Healthcare & Medical

HIPAA-Compliant Healthcare Software
Built from Scratch

We architect healthcare platforms with compliance designed in — not retrofitted. Row-level security, field-level encryption, PHI access logging, and RBAC enforced at the database layer. Custom integrations with EHR systems, medical devices, and clinical data sources.

HIPAA-Ready
Compliance First
PHI Encrypted
Field-Level
Audit Logging
Immutable Trail
PostgreSQL RLS
DB-Layer Security
The Right Architecture Approach

Compliance Built In, Not Bolted On

Most software teams build the application first, then retrofit compliance. This is expensive, risky, and often incomplete. HIPAA compliance bolted onto an existing schema means workarounds, patches over gaps, and security reviews that find structural problems requiring rewrites.

IPS designs HIPAA requirements into the data model from migration 001. Row-level security policies are written before the first table gets data. Audit log tables are part of the initial schema design. PHI fields are identified in the design phase and encrypted before any record is stored. Access roles are defined before the first API route is written.

This is not just more secure — it is significantly cheaper. Designing compliance in costs a fraction of retrofitting it into a system that was not built with it in mind.

Compliance Retrofitted (Common Approach)
  • App built, HIPAA review finds gaps late in the project
  • Schema redesign required to add audit tables
  • RLS policies added as afterthought, often incomplete
  • PHI fields encrypted post-hoc, application logic rewritten
  • Penetration test findings require structural changes
Compliance Designed In (IPS Approach)
  • PHI fields identified and encrypted in migration 001
  • RLS policies written before first row is inserted
  • Audit log schema part of the initial data model
  • RBAC roles defined before first API route is written
  • Compliance review finds nothing structural to fix
Services

Healthcare Platforms We Build

Every platform is custom — no templates, no off-the-shelf base with your logo on it. Built for your workflow, your compliance requirements, and your data model.

01

Patient Portals

PHI-gated portals with Supabase Auth, MFA support, session management, and row-level security enforcing that patients can only access their own records. Full audit trail of every PHI access event: who accessed what, when, from which IP address. Designed to support HIPAA’s required access controls and audit requirements out of the box.

Auth + MFAPHI-GatedAudit Trail
02

Clinical Data Platforms

Structured and unstructured clinical data ingestion, normalization, and storage. Ingest from lab systems, imaging systems, wearables, and manual entry. Store in a normalized, queryable schema with full provenance tracking. Support for time-series clinical measurements, clinical notes, structured diagnostic data, and longitudinal patient records.

Structured DataUnstructuredProvenance
03

Medical Device Dashboards

Real-time IoT data ingestion from medical devices: continuous glucose monitors, cardiac monitors, pulse oximeters, infusion pumps. Data pipelines from device to database with anomaly detection, alert thresholds, and clinical decision support triggers. Configurable dashboards with role-based data visibility and clinician-facing alert queues.

Real-Time IoTAlertsDashboards
04

Custom EHR Integrations

Integration with Epic, Cerner, Meditech, and other EHR systems via HL7 FHIR R4, HL7 v2.x, and vendor-specific APIs. We handle the authentication complexity, message parsing, data normalization, and error handling that EHR integrations require. Custom middleware layers that translate between your application data model and the EHR’s expectations.

HL7 FHIR R4Epic / CernerCustom APIs
05

Healthcare CRMs

HIPAA-aware CRMs for healthcare organizations: patient relationship management, referral tracking, care coordination, and outreach workflows. Field-level encryption on PHI fields, role-based data access limiting what each staff role can see, and full audit logging of data access and modification. Integrated with scheduling, billing, and communication systems.

Field-Level EncryptRBACReferral Tracking
06

Analytics Platforms

De-identified research and operational analytics pipelines that separate PHI from research data at the query layer. Safe harbor de-identification per HIPAA expert determination and safe harbor standards. Clinical trial data management, population health dashboards, and operational metrics for healthcare administrators — all with documented de-identification methodology.

De-IdentifiedSafe HarborResearch Data
Technical Safeguards

HIPAA Technical Safeguards We Implement

HIPAA’s Security Rule requires specific technical safeguards. Here is exactly how we implement each one, and why the database layer is the right place to enforce them.

Access Control & Authentication

PostgreSQL Row-Level Security (RLS)
Every database query is filtered at the PostgreSQL level by user identity. A compromised application layer cannot bypass RLS to access records it should not see. This is the only architecture that provides true data isolation in a multi-tenant healthcare system — the database itself enforces access, not just the application code.
Role-Based Access Control (RBAC)
Database roles map to clinical roles: patient, care coordinator, clinician, billing staff, admin. Each role has a precisely scoped set of tables and columns it can read or write. A billing staff member cannot query clinical notes. A patient cannot view another patient’s record. These are database-level constraints, not application-level checks.
Supabase Auth + MFA Support
JWT-based authentication with configurable MFA via TOTP or SMS. Session tokens are short-lived and scoped. Auth state is enforced server-side — the database validates identity on every request, not just at login.

Data Protection

Field-Level PHI Encryption
Individually identifying PHI fields (name, DOB, SSN, address, MRN) are encrypted at the application layer before storage, using pgcrypto or application-managed keys. Encryption keys are managed separately from the database. A database dump exposes ciphertext, not plaintext PHI.
Encryption at Rest and in Transit
All data at rest uses AES-256 encryption at the storage layer. All data in transit uses TLS 1.3. No PHI moves over an unencrypted connection. Supabase handles storage encryption; application-layer encryption adds an additional layer for PHI fields.
Data Residency — US-Only Deployment
Supabase project regions and Vercel deployment regions are configured for US data residency. PHI does not leave US data centers. This is documented in your Business Associate Agreement as a verifiable control.

Audit Controls

Immutable PHI Access Logs
Every read, write, update, and delete on PHI tables is logged to an append-only audit table. Log entries cannot be modified or deleted by application code — only by a DBA with explicitly elevated privileges. Logs capture: user identity, timestamp, table, record ID, action, source IP, and session ID.
Audit Trail for Data Modifications
Before-and-after state captured for all PHI field modifications. Who changed what field, from what value to what value, at what time. Required for HIPAA accountability and useful for clinical data integrity investigations.
Audit Log Query Procedures
Pre-written SQL queries for every audit investigation scenario: all PHI access by a specific user, all access to a specific patient record, bulk export detection, off-hours access review. Your compliance officer can run these without engineering involvement.

Integrity & Availability

Breach Detection Scaffolding
Rate limiting on PHI queries, anomalous access pattern alerting (bulk PHI exports, off-hours access, unusual record access volume), and integration with monitoring systems. HIPAA requires breach detection procedures — we build the technical scaffolding that makes detection possible.
Database Backups + Point-in-Time Recovery
PITR with Supabase, tested restore procedures, and backup retention policies configured and documented to meet HIPAA contingency planning requirements. Recovery time objectives documented and verified.
Dependency and Supply Chain Auditing
Third-party libraries reviewed for known vulnerabilities. Dependency lockfile pinning, automated dependency auditing in CI, and documented update procedures. Third-party services in the PHI chain must sign BAAs — we identify all of them and help you obtain those agreements.
Technology

Our Healthcare Platform Stack

Every component chosen for HIPAA compatibility, auditability, and developer control. No black-box managed services where we cannot inspect and control what happens to PHI.

Supabase PostgreSQL
Primary data store with Row-Level Security, pgcrypto for field-level encryption, comprehensive audit logging, and Point-in-Time Recovery. Hosted in US regions. PostgreSQL is the only database we use for HIPAA workloads — its RLS implementation is best-in-class for enforcing data access at the query layer, independent of application code.
Next.js on Vercel (US Regions)
Frontend and API routes on Vercel with US-only edge region configuration. Server-side rendering with server-side PHI fetching — PHI never hits the browser unless explicitly required by the feature. Environment variables for all secrets, no client-side exposure of service keys or database credentials.
Supabase Edge Functions (Deno)
Backend logic for PHI processing, EHR integration middleware, and webhook handling. TypeScript with strict type safety. Deno’s permission model provides an additional security layer — functions declare exactly which network endpoints and environment variables they can access, limiting blast radius of any compromise.
Encryption Key Management
Application-layer encryption keys stored separately from the database using Supabase Vault or external KMS. Key rotation procedures documented and automatable. For high-compliance requirements, we integrate with AWS KMS or HashiCorp Vault for HSM-backed key management.
What You Receive

Compliance Documentation Included

A HIPAA-compliant platform is only part of what you need. We deliver the documentation your compliance program requires alongside the software.

Security Architecture Document
Written description of every technical safeguard, how it is implemented, and what threat it addresses. Required for your HIPAA Security Rule risk analysis and risk management plan.
PHI Data Flow Map
Every path PHI takes through the system: which tables, which API endpoints, which third-party services receive or process PHI. Essential for identifying all required Business Associate Agreements.
RLS Policy Documentation
Every RLS policy documented with what it permits, what it blocks, and how to verify it works correctly. Includes testable assertions for each policy so your team can verify the controls remain in place after future changes.
Audit Log Query Guide
SQL queries for every audit investigation scenario: all PHI access by a user, all access to a specific patient record, bulk export detection, off-hours access review. Your compliance officer can run these without engineering involvement.
BAA Preparation Support
We identify every service provider in the PHI chain, help you prepare Business Associate Agreements with each one, and sign a BAA with you as your software development partner before any work involving PHI begins.
FAQ

Healthcare Software Questions

The questions healthcare organizations ask most often. Answered directly.

What does HIPAA-compliant software actually require technically?
HIPAA Security Rule specifies three safeguard categories: administrative, physical, and technical. Technical safeguards include: access controls assigning unique user IDs and restricting PHI access to authorized users; audit controls logging all activity on PHI systems; integrity controls ensuring PHI is not improperly altered; and transmission security encrypting PHI in transit. Row-level security at the database layer cannot be bypassed by application bugs — the database enforces access rules independently.
Do you sign a Business Associate Agreement (BAA)?
Yes. Any software developer who accesses, stores, or transmits PHI on behalf of a Covered Entity is a Business Associate under HIPAA and must sign a BAA. We sign a BAA with every healthcare client before any work involving PHI begins. We also identify every other service provider in your PHI data flow requiring a BAA and help you prepare those agreements. Do not work with a team that refuses to sign a BAA.
Can you integrate with Epic, Cerner, or other EHR systems?
Yes. We integrate via HL7 FHIR R4, HL7 v2.x, and vendor-specific APIs. Epic SMART on FHIR, Cerner FHIR API, and Meditech Expanse are integrations we encounter most frequently. EHR integrations are genuinely complex: authentication is non-trivial, message formats vary by EHR version and configuration, and error handling requires EHR-specific knowledge. We treat these as dedicated engineering projects with proper test environments.
How do you handle PHI in a multi-tenant architecture?
Multi-tenant healthcare requires complete data isolation between tenants. Every PHI table has a tenant_id column, and RLS policies enforce that every query is filtered to the authenticated tenant. A query from Tenant A will never return Tenant B records, even if application code omits a WHERE clause. We test this isolation explicitly for each RLS policy, confirming cross-tenant access is blocked at the database level.
What is the difference between HIPAA-compliant and HIPAA-certified?
There is no such thing as HIPAA certification. No government body certifies software as HIPAA-compliant. Anyone claiming their software is HIPAA-certified is either misinformed or misleading you. HIPAA compliance is a legal obligation resting with Covered Entities and their Business Associates. We build platforms implementing all required technical safeguards, but compliance also requires your organizational policies, staff training, risk assessments, and incident response procedures.
How long does it take to build a HIPAA-compliant platform?
A HIPAA-compliant MVP with authentication, PHI storage, audit logging, and RLS policies typically takes 8 to 14 weeks. A full-featured clinical platform with EHR integrations and comprehensive audit infrastructure runs 4 to 9 months. HIPAA compliance does not add as much time as teams fear when designed in from the start. Retrofitting compliance onto an existing non-compliant system can easily take as long as rebuilding from scratch.
What does custom healthcare software development cost?
HIPAA-compliant platforms start at $45,000 for a focused application: a patient portal, a clinical data viewer, or a compliant CRM module. A full-featured clinical platform with EHR integrations runs $90,000 to $200,000 or more. We price fixed-scope projects at a fixed fee with a full specification written before development begins. Contact us with your use case for a detailed estimate.
Start a Project

Ready to Build Healthcare Software That Is Actually Compliant?

Describe your use case. We will map the PHI data flows, identify compliance requirements, and give you a concrete technical plan: what we will build, what safeguards we will implement, what it will cost, and how long it will take. No vague proposals.