Health Tech PM System Design: HIPAA and Data Infrastructure

TL;DR

HIPAA compliance is the non-negotiable baseline, not a differentiator—candidates fail when they treat it as a feature rather than a constraint. The best answers frame data infrastructure around patient trust, not cost optimization. Hiring managers at companies like Teladoc or Flatiron discard answers that conflate HIPAA with GDPR.

Who This Is For

This is for PMs targeting Series B+ health tech startups or public companies like Epic, where system design interviews probe HIPAA depth, not surface-level buzzword compliance. You’ve likely shipped a product in a regulated space but need to articulate how constraints shape architecture, not just features.

How do you design a HIPAA-compliant patient data pipeline?

HIPAA isn’t a checkbox—it’s the architectural foundation, and the pipeline’s failure mode is a data breach, not latency. In a debrief at a digital therapeutics startup, the hiring manager killed a candidate’s answer because they proposed storing PHI in a data lake with role-based access, ignoring that HIPAA requires access logs tied to individual users, not just permissions. The pipeline must enforce end-to-end encryption, immutable audit trails, and a zero-trust model where even DBAs can’t see raw PHI.

Not X: Starting with scalability or cost.

But Y: Starting with who can access what, under what conditions, and how that’s audited.

The counter-intuitive insight: the most HIPAA-compliant systems are often the least flexible. A candidate’s proposal to use a serverless architecture was rejected because the startup’s legal team required dedicated, isolated instances for PHI—serverless shared tenancy introduced unacceptable risk. The trade-off isn’t performance vs. compliance; it’s innovation velocity vs. legal exposure.

What’s the difference between HIPAA and GDPR in system design?

HIPAA is a floor; GDPR is a ceiling with sharper teeth but narrower scope. In a hiring committee at a telehealth unicorn, the debate hinged on a candidate’s answer conflating the two: HIPAA covers PHI, GDPR covers all personal data, but GDPR’s right to erasure conflicts with HIPAA’s retention requirements for medical records. The candidate’s system design allowed patient-initiated deletion of lab results—legally impossible under HIPAA.

Not X: Treating them as interchangeable frameworks.

But Y: Designing for the strictest requirement in overlapping areas (e.g., GDPR’s 72-hour breach notification vs. HIPAA’s 60 days).

The organizational psychology principle: engineers optimize for flexibility; legal teams optimize for risk. The PM’s job is to force the trade-off into the open. A candidate who proposed a “compliance layer” abstraction lost points because it masked the hard choices. The best answers name the conflict: “We’ll store PHI in isolated US-based databases to satisfy HIPAA, and non-PHI user data in EU-based servers with GDPR-compliant deletion hooks.”

How do you handle third-party integrations with PHI?

Third-party risk is the most underweighted variable in health tech system design interviews. At a Series C mental health platform, the hiring manager grilled a candidate on their proposal to use Segment for analytics. The candidate’s answer—“we’ll sign a BAA”—was insufficient. The follow-up: “How do you ensure Segment’s sub-processors (e.g., AWS) also comply?” The correct answer: no PHI leaves your environment unless the vendor is HIPAA-certified, and even then, only via encrypted, logged APIs with data minimization.

Not X: Assuming a BAA solves everything.

But Y: Treating third parties as potential breach vectors and designing as if they will fail.

The framework: classify vendors by data sensitivity. Tier 1 (PHI): isolated, audited, no sub-processors. Tier 2 (de-identified data): BAAs + regular audits. Tier 3 (anonymous usage stats): no PHI, standard contracts. A candidate who didn’t segment vendors this way was flagged as “not thinking like a health tech PM.”

Where does consent management fit into the system design?

Consent isn’t a feature—it’s a legal gate that can invalidate your entire data model. In a debrief at a chronic disease management startup, the candidate’s system stored patient consent as a boolean in the user profile table. The hiring manager’s objection: consent is time-bound, revocable, and granular (e.g., share lab results with Dr. X but not Dr. Y). The correct design: a separate consent log with timestamps, versions, and cryptographic signatures to prove non-repudiation.

Not X: Modeling consent as a simple user preference.

But Y: Treating it as a legally binding audit trail with its own lifecycle.

The insight: consent is the only part of your system where the absence of data (revoked consent) is as critical as its presence. A candidate who didn’t account for “consent withdrawal” propagating to all downstream systems (e.g., analytics, ML training) was cut for missing a 6-figure legal risk.

How do you design for interoperability (HL7, FHIR) without violating HIPAA?

Interoperability is where most health tech PMs reveal their lack of domain depth. At a hospital EMR integration project, the candidate proposed using FHIR APIs to sync patient data between systems, but didn’t specify how PHI would be tokenized or encrypted in transit. The hiring manager’s note: “FHIR is a format, not a security protocol.” The fix: wrap all FHIR payloads in TLS 1.2+, use OAuth 2.0 with scopes tied to minimum necessary PHI, and log every access attempt.

Not X: Assuming HL7/FHIR handles compliance.

But Y: Treating interoperability standards as data formats that must be secured separately.

The counter-intuitive observation: the more interoperable your system, the higher the breach risk. A candidate who designed a “universal patient record” with open APIs was rejected because the surface area for attacks scaled with the number of integrations. The best answers limit interoperability to necessary partners and enforce strict rate-limiting and anomaly detection.

How do you balance analytics with HIPAA compliance?

Analytics in health tech is a minefield because most BI tools aren’t HIPAA-native. In a hiring debate at a mental health app, the candidate suggested using Amplitude for product analytics with PHI scrubbed via regex. The legal team’s response: regex isn’t deterministic (e.g., “Patient ID: 12345” might evade a pattern match). The solution: either use a HIPAA-certified analytics vendor (e.g., mPulse Mobile) or build a separate, air-gapped analytics environment with de-identified data.

Not X: Relying on scrubbing tools to anonymize PHI.

But Y: Designing analytics as a separate system with its own compliance boundaries.

The framework: the “minimum necessary” rule. If your analytics requires patient ZIP codes, you’re violating HIPAA unless you can prove it’s essential for treatment. A candidate who included demographics in their analytics schema without justification was flagged for “over-collection.”

Preparation Checklist

Map every data flow involving PHI to a HIPAA requirement (e.g., §164.308 for access controls, §164.312 for encryption).
Design a consent model with versioning, timestamps, and cryptographic proof—assume auditors will demand evidence.
Classify all third parties by data sensitivity and draft BAAs for each Tier 1 vendor.
Isolate PHI in dedicated, encrypted storage with zero-trust access—no shared tenancy.
Model interoperability (HL7/FHIR) as a risk vector, not just a feature—specify encryption and audit logs for every integration.
Build analytics in a separate environment or use HIPAA-certified tools—never mix PHI with standard BI pipelines.
Work through a structured preparation system (the PM Interview Playbook covers HIPAA-compliant data pipelines with real debrief examples from Flatiron and Teladoc).

Mistakes to Avoid

Treat HIPAA as a feature, not a constraint

BAD: “We’ll add HIPAA compliance as part of our Q3 roadmap.”

GOOD: “Our architecture assumes every component will be audited for HIPAA, so we’re designing for encryption at rest and in transit from day one.”

Assume de-identification is sufficient for analytics

BAD: “We’ll hash patient IDs and use that for analytics.”

GOOD: “We’ll use a HIPAA-certified vendor for analytics or maintain a separate, air-gapped environment with no PHI.”

Ignore sub-processor risk in third-party integrations

BAD: “We’ll sign a BAA with AWS.”

GOOD: “We’ll restrict PHI to isolated AWS accounts with no sub-processor access, and audit all data flows quarterly.”

FAQ

Does HIPAA apply to all health tech products?

No—HIPAA only applies if you’re a covered entity (e.g., hospital) or business associate (e.g., EMR vendor) handling PHI. A wellness app tracking steps isn’t covered unless it touches medical data.

Can you use serverless for PHI?

Rarely. Most serverless providers (AWS Lambda, Firebase) use shared tenancy, which violates HIPAA’s isolation requirements. Dedicated instances or HIPAA-certified serverless (e.g., AWS Lambda in a HIPAA account) are required.

How do you handle patient requests to delete data under HIPAA?

You can’t. HIPAA requires retention of medical records for 6 years (or per state law). GDPR’s right to erasure doesn’t apply to PHI under HIPAA. Design for retention, not deletion.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.