Solving the Data Silo: A PM's Guide to Healthcare Interoperability

Healthcare PMs don’t fail because they lack product sense — they fail because they misread the regulatory and institutional gravity of interoperability. The real work isn’t building APIs; it’s aligning payer, provider, and EHR vendor incentives under 21st Century Cures Act constraints. If you can’t

TL;DR

Who This Is For

This is for product managers with 3–7 years of experience transitioning into healthcare from B2B SaaS, fintech, or consumer tech who assume interoperability is a technical problem. You’ve shipped features at scale but have never sat through a Meaningful Use compliance review or negotiated a data use agreement with a health system legal team. You’re targeting roles at Epic, Cerner, Optum, or digital health startups funded by a16z or Rock Health.

How Is Healthcare Interoperability Different From API Integrations in Other Industries?

Interoperability in healthcare isn’t about data transfer speed — it’s about permissioned access under clinical risk. In a Q3 2022 debrief for a senior PM hire at a national payer, the hiring manager killed the offer because the candidate framed FHIR as “just another REST API.” That’s not ignorance — it’s professional malpractice in this domain.

The issue isn’t technical complexity; it’s liability attribution. When a patient’s medication list fails to sync between Epic and a specialty pharmacy, someone gets sued. In most tech companies, an API outage is a P1 incident. In healthcare, it’s a Joint Commission audit trigger.

Not integration velocity, but audit trail completeness determines success. A fintech PM might optimize for 99.99% uptime; a healthcare PM must ensure every data pull logs consent status, purpose of use, and acting clinician identity. The HL7 FHIR standard isn’t chosen for elegance — it’s mandated by CMS to reduce variability in enforcement.

In 2023, we saw three PM candidates at a Medicaid tech startup fail final rounds because they couldn’t explain how the USCDI v3 update changed data sharing requirements for behavioral health records. One had built API platforms at Stripe. It didn’t matter. You don’t get credit for past scale — only for regulatory precision.

Why Do Healthcare PMs Fail When They Come From Consumer Tech?

Consumer tech PMs fail not because they lack empathy, but because they apply engagement metrics to clinical workflows where “engagement” can be harmful. During a hiring committee at a diabetes tech company, a candidate proposed push notifications to remind patients to check A1C levels weekly. The chief medical officer walked out. Real-time alerts without clinical escalation pathways create alert fatigue — a documented cause of patient harm.

Not growth, but harm reduction is the KPI. Consumer PMs optimize for DAU/MAU; healthcare PMs answer for whether their feature increases missed diagnoses. One candidate from Instagram bragged about A/B testing 17 button colors. The debrief ended in 12 minutes.

Another mistake: assuming user = payer. In consumer apps, the person using the product pays for it. In healthcare, the clinician using your EHR tool isn’t the buyer — the hospital CIO is. Worse, the patient owns the data but has zero technical agency. This three-party dislocation breaks standard PM frameworks.

At a telehealth startup, a PM from Uber launched a “surge pricing” model for after-hours visits. The board pulled the feature 48 hours after launch. Pricing elasticity models from ride-sharing don’t survive ERISA and state insurance regulations. You’re not disrupting — you’re violating fiduciary duty.

What Does a Hiring Committee Actually Look For in a Healthcare PM Interview?

They’re not evaluating your command of FHIR resources — they’re testing your judgment under regulatory ambiguity. In a 2021 hiring round at a CMS contractor, two candidates had identical resumes: ex-Google, MBA, 5 years PM experience. One passed. One failed. The difference? The successful candidate said, “I assume any data flow I design will be subpoenaed in a malpractice case,” and built audit logging into her solution sketch.

Hiring managers don’t care about your backlog process — they need proof you’ve internalized that every feature is a potential evidence exhibit. When we ran debriefs at a national HIE, candidates who referenced ONC’s Conditions and Maintenance (C&M) certification process scored 40% higher. One even cited the 2020 Cures Act Final Rule’s §170.207 on patient access. That wasn’t memorization — it signaled operational awareness.

Interviewers will simulate a change request: “The hospital wants to block social determinants of health (SDOH) data from flowing to primary care due to stigma concerns.” A bad answer: “We should educate them on the benefits.” A good answer: “We’ll implement sensitivity flags in the FHIR meta tag and require attestation at data access.” One is advocacy; the other is risk engineering.

How Do You Prioritize Features in a Regulated Interoperability Product?

You don’t use RICE or MoSCoW — you use liability surface analysis. At a health information exchange in California, we killed a real-time ED visit notification feature because it lacked a documented care team handoff protocol. The engineering lead argued it would save lives. The legal team said it created duty of care without coverage. It died.

Not user demand, but insurance underwriting determines priority. A feature that reduces readmissions by 5% but increases documentation burden by 10 minutes per patient will be rejected by hospital systems. Their E&M coding revenue loss outweighs the quality metric gain.

We once had a PM propose a centralized patient consent dashboard. It made sense — until we modeled it against state-by-state consent laws. California’s CMIA, New York’s SHIELD Act, and Texas’ medical privacy rules conflict on data revocation timelines. The solution wasn’t UX — it was legal jurisdiction routing. We built a rules engine that applied consent logic based on patient ZIP + data recipient type. That became our top roadmap item — not because clinicians asked for it, but because risk officers approved it.

What Technical Concepts Must a Healthcare PM Actually Understand?

You don’t need to write FHIR paths — but you must know when to use Observation vs. DiagnosticReport resources. In a debrief for a clinical decision support role, a candidate said, “We’ll store lab results in a JSON blob.” The architect stopped the interview. That’s not ignorance — it’s disqualification.

Not software patterns, but data provenance defines system design. A PM must ask: “Is this value authored by a machine or a licensed clinician?” That determines whether it’s auditable. One startup failed an OCR audit because their AI-generated radiology summaries were stored with the same metadata as radiologist-signed reports.

You must understand the difference between push (IHE PIX/PDQ) and query-based (IHE XDS.b) exchange models. At a regional HIE, we rejected a vendor because their “interoperable” solution only supported push. We needed on-demand access for emergent care. The PM didn’t know the distinction. The deal collapsed.

Work through a structured preparation system (the PM Interview Playbook covers FHIR resource modeling with real debrief examples from Epic and federal HIE projects).

Preparation Checklist

Map one FHIR use case (e.g., bulk data export) to a specific stage in the revenue cycle (e.g., HCC coding)
Memorize the three required APIs under the 21st Century Cures Act: Patient Access, Provider Directory, Payer-to-Payer
Practice explaining how USCDI v3 expands on v2 with SDOH and mental health data
Draft a data use agreement clause limiting liability for inaccurate patient-entered data
Simulate a stakeholder objection from a hospital CIO fearing HIPAA violations from API access
Work through a structured preparation system (the PM Interview Playbook covers FHIR resource modeling with real debrief examples from Epic and federal HIE projects)
List three differences between HL7 v2, C-CDA, and FHIR in clinical context — not technical specs

Mistakes to Avoid

BAD: Framing interoperability as a developer experience problem. Saying, “We’ll reduce integration time from 6 months to 6 weeks.” That’s irrelevant. Health systems don’t care about onboarding speed — they care about audit compliance.

GOOD: “We’ll reduce integration risk by pre-certifying our FHIR server against ONC’s Cures Act certification criteria, so legal teams can approve in 2 weeks.” That speaks to procurement cycles.

BAD: Prioritizing a feature because a clinician requested it. A cardiologist may ask for real-time device data feeds, but if it bypasses the EHR’s change management process, it’s shadow IT.

GOOD: “We’ll route pacemaker data through the EHR’s clinical inbox with embedded CPT code suggestions, so it becomes billable and auditable.” That aligns with institutional incentives.

BAD: Using Jira epics labeled “Interoperability Workstream.” That’s vagueness — a red flag.

GOOD: “Epic Care Everywhere integration via IHE XDS.b, Phase 1: patient matching using MPI with match confidence scoring >95%.” Specificity signals operational maturity.

FAQ

What’s the salary range for healthcare PMs working on interoperability?

$150K–$220K base at large health systems or vendors like Epic; $180K–$275K at well-funded startups if you have FHIR implementation experience. Compensation scales with regulatory domain knowledge — not just technical understanding.

How many interview rounds should I expect at a healthcare tech company?

Six on average: recruiter screen, PM interview, technical deep dive, regulatory scenario, stakeholder role-play, and hiring committee review. The technical round will include a FHIR resource modeling exercise — not system design.

Do I need a clinical background to be a healthcare PM?

Not a degree, but you must speak the liability language of care delivery. A nurse practitioner PM isn’t inherently better — but they’re less likely to propose features that create duty of care gaps. Your judgment must be clinically informed, not clinically sourced.

What are the most common interview mistakes?

Three frequent mistakes: diving into answers without a clear framework, neglecting data-driven arguments, and giving generic behavioral responses. Every answer should have clear structure and specific examples.

Any tips for salary negotiation?

Multiple competing offers are your strongest leverage. Research market rates, prepare data to support your expectations, and negotiate on total compensation — base, RSU, sign-on bonus, and level — not just one dimension.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.