Healthcare-AI: Sanjay Naik's Interview Moat

Audience: Sanjay Naik — 3.5 yrs (Jio Platform Ltd, ex-Karkinos Health) — targeting MAANG SDE-II and healthtech-AI roles (Verily, Tempus, Oscar Health, Hippocratic AI, Color Health, Anthropic Health, Innovaccer, Cigna Evernorth, Walmart Health). Purpose: Turn real production healthcare-AI experience into structured, repeatable interview gold across SD, behavioral, and AI rounds.

1. Why this is your moat

Most L4 / SDE-II candidates in 2026 have toy LLM side projects. You have prod GenAI in a regulated domain. That asymmetry compounds across every round.

Round	How the moat plays
System Design	You don’t need to invent constraints — HIPAA, PHI, audit logs, idempotency under clinical urgency are lived requirements.
Coding	You frame data-structure choices with real workloads (FHIR bundles, CDC throughput, vector index sizing).
Behavioral	“Tell me about scale / ambiguity / impact” — oncology treatment plans, 40% LLM cost cut, cross-team clinician collaboration are concrete.
AI / ML	Hallucination, eval rubrics, RAG, guardrails — you’ve shipped them, not read about them.
Bar-raiser	Regulated-domain reasoning (minimum necessary, BAA, de-identification) signals seniority well beyond YoE.

The multiplier: Healthcare-AI is one of the few domains where shipping safely is part of the job spec. Frame every project as: “the system had to work, and not harm anyone.” That single sentence buys two levels of perceived seniority.

Anti-pattern: Do NOT lead with “I worked in healthcare.” Lead with the engineering: “I built a per-tenant LLM rate limiter that cut spend 40% — it ran in a HIPAA-regulated clinical pipeline.” The domain is the multiplier, not the headline.

2. FHIR / OpenEHR / HL7 — 60-second deep-dive you must own

You should be able to whiteboard a FHIR resource server in under 5 minutes. Internalize this.

FHIR in one paragraph

FHIR (Fast Healthcare Interoperability Resources) is HL7’s modern healthcare interop standard. It is a resource-based RESTful API — every clinical concept (Patient, Observation, Encounter) is a Resource with a stable URL, exchanged as JSON or XML. Resources are versioned, referenceable across servers, and composable via Bundles. Spec: hl7.org/fhir/R5.

Core resources you must name without hesitation

Resource	Holds	Common use
`Patient`	Demographics, identifiers (MRN, Aadhaar)	Root of every clinical record
`Observation`	Lab/vital/measurement (BP, HbA1c, biopsy result)	Numeric + coded clinical findings
`Condition`	Diagnosis (ICD-10 / SNOMED)	Active/resolved problem list
`MedicationRequest`	Prescription	E-prescribing
`Encounter`	Visit / admission	Anchor for all clinical events in a session
`DiagnosticReport`	Radiology / pathology report	Wraps `Observation`s + narrative
`AllergyIntolerance`	Allergies / adverse reactions	Critical for safety checks
`CarePlan`	Treatment plan, goals, activities	Your oncology treatment plan project maps here
`Procedure`	Surgery, chemo session	Linked to `Encounter`
`Practitioner` / `Organization`	Provider, hospital	Authorship + provenance

REST API shape

GET  /fhir/Patient/123
GET  /fhir/Observation?patient=123&code=http://loinc.org|4548-4   # HbA1c
POST /fhir/Patient
PUT  /fhir/Patient/123
GET  /fhir/Patient/123/$everything                                # operation
POST /fhir   { "resourceType": "Bundle", "type": "transaction" }  # atomic batch

$search parameters are typed (token, reference, date, quantity, string).
Bundle of type transaction is atomic — all or nothing — your CDC pipeline must respect this.
_include / _revinclude fetch linked resources in one round-trip (avoid N+1).

SMART-on-FHIR (auth)

OAuth2 + OpenID Connect profile on top of FHIR. Scopes are resource-scoped: patient/Observation.read, user/*.write, launch/patient. EHR-launched apps get a context (patient, encounter) in the launch token. Spec: hl7.org/fhir/smart-app-launch.

OpenEHR vs FHIR

Axis	FHIR	OpenEHR
Model	Resources (~150 fixed types)	Reference Model + Archetypes + Templates (community-defined, infinite)
Use	Exchange / API between systems	Persistence / EHR storage with full clinical fidelity
Querying	REST + `_search`	AQL (Archetype Query Language)
Versioning	Resource-level	Composition-level, full audit
Strength	Simple, web-native, fast adoption	Rich semantics, future-proof clinical models

Mnemonic: FHIR is the API; OpenEHR is the database. Many modern stacks store in OpenEHR and expose FHIR at the edge.

HL7 v2 vs v3 vs FHIR

Standard	Year	Format	Status
HL7 v2.x	1989+	Pipe-delimited (`MSH	^~&
HL7 v3 / CDA	2005	XML, RIM-based	Heavyweight, used for document exchange (C-CDA)
FHIR	2014+	JSON/XML REST	Modern default; mandatory under US 21st Century Cures Act

5-minute FHIR resource server whiteboard

┌──────────────┐    HTTPS+OAuth   ┌──────────────────┐
│  EHR / App   │ ───────────────▶ │  FHIR Gateway    │  (auth, rate-limit, audit)
└──────────────┘                  └────────┬─────────┘
                                           │
                            ┌──────────────┼──────────────┐
                            ▼              ▼              ▼
                     ┌────────────┐ ┌────────────┐ ┌────────────┐
                     │ Validator  │ │  Search    │ │ Operations │
                     │ (profiles) │ │  Engine    │ │ ($everything)│
                     └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
                           │              │              │
                           └──────────────┴──────────────┘
                                          │
                                          ▼
                                  ┌────────────────┐
                                  │ Resource Store │ (Postgres + JSONB
                                  │  + Indexes     │  or OpenEHR backend)
                                  └────────┬───────┘
                                           │
                                          ▼
                                  ┌────────────────┐
                                  │  Audit Log     │ (immutable, append-only)
                                  └────────────────┘

Key talking points: profile validation (US Core / IPS), terminology service for codings (SNOMED, LOINC, ICD-10), _history for versioning, subscriptions (Subscription resource → webhooks), conditional create/update with If-None-Exist.

3. HIPAA + compliance vocabulary

Memorize these — interviewers in healthtech love to test fluency.

Term	One-line definition	Your Jio application
PHI	Protected Health Information — health data tied to an identifier	All patient records in MDM Admin / Treatment Plan
PII	Personally Identifiable Information (broader than PHI)	Name, Aadhaar, phone — present in `Patient` resource
BAA	Business Associate Agreement — contract with any vendor that touches PHI	Required before any LLM API call hits patient data
Encryption at rest	DB / S3 / EBS encrypted with KMS-managed keys	Postgres TDE, S3 SSE-KMS
Encryption in transit	TLS 1.2+, mTLS between MS	Spring Cloud Config, inter-service mTLS
Audit log	Who-accessed-what-when, immutable, queryable	Append-only Kafka topic + S3 archive, 6-yr retention
De-identification — Safe Harbor	Remove 18 specified identifiers (HIPAA §164.514(b)(2))	PHI scrubber before embedding for vector search
De-identification — Expert Determination	Statistician certifies low re-id risk	Used when Safe Harbor strips too much signal
Minimum Necessary	Only access the PHI required for the task	RBAC + attribute-based scopes (oncologist ≠ admin)
Access controls	Role-based + context-aware (break-glass)	Keycloak + custom claims
Breach Notification Rule	<60 days notice to HHS + affected individuals if >500 records	Incident playbook + SIEM alerts
HITECH	2009 amendment — strengthened HIPAA, added BA liability	Mention to signal depth
42 CFR Part 2	Stricter rules for substance-use treatment records	Niche but impressive

Behavioral hook: “At Jio, every LLM call passed through a PHI redactor before leaving the VPC. Tokens that matched names, MRNs, or addresses were swapped for opaque placeholders and re-hydrated on the response. This let us use third-party LLMs under our BAA without exposing raw PHI.”

4. Clinical AI / LLM productionization — questions you’ll get asked

Q1. “How do you ensure your clinical LLM doesn’t hallucinate?”

Answer (90 seconds):

Grounding via RAG — every clinical statement must cite a retrieved chunk from this patient’s FHIR record. No retrieval, no claim.
Citation linking — each sentence in the output carries [Observation/abc123] style refs; UI renders them as deep-links.
Confidence thresholds — model returns logprobs / self-rated confidence; below threshold → mark as “needs review” instead of hiding.
Human-in-the-loop for diagnosis-affecting outputs — clinician must approve before it lands in the chart.
Eval rubrics scored offline + online: factuality (does claim match source?), completeness (did we miss a critical lab?), harm (could acting on this hurt?).
Constrained decoding — structured output (JSON schema) prevents free-form fabrication.

Q2. “How do you rate-limit LLM APIs?” — your actual project

See Section 5 for the full SD answer.

Q3. “How do you A/B test a clinical AI feature?”

You don’t A/B test on outcomes that affect care. Instead:

Stage 1: Shadow mode      → AI runs, output logged, never shown
Stage 2: Clinician review → AI output visible to clinician only; collect agree/disagree
Stage 3: Opt-in pilot     → 1-2 sites, informed consent, IRB if research
Stage 4: Outcome metrics  → time-to-decision, missed-finding rate, clinician trust score
Stage 5: Gradual rollout  → percentage ramp with kill-switch

Metrics are never just accuracy — you measure clinical utility (did it change the decision? did it save time? did anyone get hurt?).

Q4. “How do you handle bias in clinical AI?”

Eval slices by demographics: age, sex, ethnicity, urban/rural, payer. Track per-slice precision/recall.
Debias prompts: explicit instruction “do not weight ethnicity unless clinically indicated.”
Model cards (Mitchell et al.) document training data, intended use, known limitations, slice performance.
Counterfactual tests — swap demographic tokens, assert output stable.
Continuous monitoring — drift detector on production slices.

Q5. “What’s RAG and when wouldn’t you use it?”

RAG = retrieve relevant docs → stuff into prompt → generate grounded answer. Pipeline: chunk → embed → vector index → query embedding → top-k retrieval (often hybrid BM25 + dense) → re-rank → prompt → generate → cite.

When fine-tuning beats RAG:

Knowledge is small, static, and frequently re-used (e.g., your house style for discharge summaries).
You need strict output format that RAG context keeps drifting from.
Latency budget too tight to retrieve.
You want to encode skill (reasoning style), not facts.

Real answer: Hybrid. Fine-tune for format/style + RAG for patient-specific facts.

Q6. “Design a clinical summarization system”

Full HLD:

┌──────────────┐
│ EHR (FHIR)   │
└──────┬───────┘
       │ FHIR Subscription / webhook (CDC)
       ▼
┌──────────────────────┐
│ Ingestion Service    │  ── validate, dedup, normalize codes (SNOMED↔ICD)
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐
│ PHI Redactor         │  ── safe-harbor scrub before any external call
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐
│ Chunker (per         │  ── chunk boundary = Encounter, not token count
│  Encounter)          │
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐
│ Embedder + Vec Store │  ── e.g., pgvector or Qdrant, per-tenant namespace
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐    ┌──────────────────┐
│ Retriever (hybrid    │◀──▶│ Re-ranker        │
│  BM25 + dense)       │    │ (cross-encoder)  │
└──────┬───────────────┘    └──────────────────┘
       │
       ▼
┌──────────────────────┐
│ Prompt Composer      │  ── template + guardrails + tools
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐    ┌──────────────────┐
│ Rate Limiter ───────▶│    │ Cache (semantic) │
│  + Router            │◀───┤  + Exact KV      │
└──────┬───────────────┘    └──────────────────┘
       │
       ▼
┌──────────────────────┐
│ LLM Provider         │
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐
│ Output Validator     │  ── JSON schema, citation check, harm filter
└──────┬───────────────┘
       │
       ▼
┌──────────────────────┐
│ Audit Log + UI       │
└──────────────────────┘

Guardrails to call out: structured outputs, citation-coverage check (every claim has a ref), forbidden-phrase filter (“you should…”), max-token cap per request, per-tenant cost cap.

5. AI Rate Limiter — the gold answer (5-minute SD)

This is your project. Own it. Drive the whiteboard.

Requirements (clarify first — buys 30 seconds and trust)

Per-tenant LLM quotas (RPM, TPM, $/day).
Cost cap — hard ceiling per tenant per day; soft alerts at 80%.
Latency-aware — prefer cached / smaller model when SLA tight.
Fair queuing — no tenant starves another.
Priority lanes — clinical-urgent (e.g., ER summarization) jumps the queue.
Observability — per-tenant, per-model, per-prompt-template dashboards.
Survive provider outage and Redis outage.

HLD

Client ──▶ API GW ──▶ Rate Limiter Middleware ──▶ Router ──▶ Cache? ──▶ LLM Provider
                            │                       │            │
                            ▼                       ▼            ▼
                       Redis (sliding         Model Picker   Response Cache
                        window +              (cheap-first,   (semantic +
                        token bucket)          escalate)       exact-KV)
                            │
                            ▼
                       Local in-mem fallback (if Redis down)
                            │
                            ▼
                       Audit + Metrics (Kafka → Prom + S3)

Java sketch — sliding window + token bucket per tenant

public class TenantRateLimiter {
    private final StringRedisTemplate redis;
    private final long windowMs;
    private final int maxRequests;
    private final int burst;

    public Decision check(String tenantId, int estimatedTokens) {
        String key = "rl:" + tenantId + ":" + (System.currentTimeMillis() / windowMs);
        Long count = redis.opsForValue().increment(key);
        if (count == 1) redis.expire(key, Duration.ofMillis(windowMs * 2));

        if (count > maxRequests) return Decision.QUEUE;          // fair-queue lane
        if (estimatedTokens > tokensRemaining(tenantId)) return Decision.DOWNGRADE;
        return Decision.ALLOW;
    }
}

Trade-offs (call out unprompted — bar-raiser signal)

Algorithm	Pros	Cons	When
Fixed window	Trivial, cheap	Boundary spikes (2x burst at window edge)	Rough coarse limits
Sliding window log	Exact	Memory grows w/ requests	Low-volume premium tenants
Sliding window counter	Cheap + accurate enough	Slight approximation	Default for LLM APIs
Token bucket	Smooth bursts, refill rate intuitive	Two params to tune	Per-tenant TPM (token-per-min) caps
Leaky bucket	Smoothest egress	Adds latency	Downstream provider protection

You combined sliding window (for request count) with token bucket (for tokens, since tokens are the cost driver in LLMs).

Why 40% cost cut — itemize the levers

Semantic + exact-KV cache (≈18%) — dedupe near-identical clinical prompts within a session.
Cheaper-model routing (≈12%) — Haiku/Flash for extraction, Sonnet only for summarization; classifier picks.
Request dedup / coalescing (≈4%) — collapse identical in-flight requests.
Batch API (≈3%) — overnight bulk re-summarization at 50% rate.
Prompt compression (≈3%) — system prompt KV-cached + dropped boilerplate.

(Always present the breakdown — “40%” alone sounds made up; itemized lands as engineering.)

Failure modes

Rate-limit storm (every tenant retries at second 0 after limit reset) → add jitter, exponential backoff with cap, per-tenant cooldown.
Redis outage → local in-process token bucket with conservative limits + circuit-break to provider; alert.
Provider 5xx / 429 → retry with backoff, then failover to secondary provider with feature flag.
Hot tenant → per-tenant queue with bounded depth; reject with 429 + Retry-After.
Cost runaway → hard daily $ cap; tenant gets degraded model after soft cap.

Extensions (mention 1-2, signals seniority)

Cost forecasting per tenant (linear regression on rolling TPM).
Anomaly alerts (3-sigma on cost/hour).
SLO-driven routing — if p95 > SLA, drop to cheaper/faster model automatically.
Per-prompt-template cost attribution → chargeback to product teams.

6. Clinical Data Extraction with Factory Pattern — LLD

Problem: Unstructured medical reports arrive in PDFs, scanned images, HL7 v2 messages, and free text. Map them all to FHIR Observation / DiagnosticReport.

Class diagram

                  ┌────────────────────────────┐
                  │      ReportParser          │  «interface»
                  │  + parse(InputStream): RD  │
                  │  + supports(MimeType): bool│
                  └─────────────┬──────────────┘
                                │
       ┌────────────────────────┼────────────────────────┬────────────────┐
       ▼                        ▼                        ▼                ▼
┌──────────────┐         ┌──────────────┐        ┌──────────────┐  ┌──────────────┐
│ PDFParser    │         │ ImageParser  │        │ TextParser   │  │ HL7v2Parser  │
│ (Tika+rules) │         │ (OCR+LLM)    │        │ (LLM extract)│  │ (HAPI)       │
└──────────────┘         └──────────────┘        └──────────────┘  └──────────────┘
                                                                        │
                                ParserFactory                           │
                                + get(MimeType): ReportParser ──────────┘
                                                                        
       Each parser emits:  ReportData (normalized DTO)
                                ▼
                         ┌──────────────────┐
                         │  FHIRBuilder     │  ── code lookup (SNOMED/LOINC),
                         │  + build(RD):    │     unit normalization, ref
                         │     Bundle       │     resolution
                         └──────┬───────────┘
                                ▼
                  Bundle { Observation, DiagnosticReport, Patient? }

Java sketch

public interface ReportParser {
    boolean supports(MimeType mt);
    ReportData parse(InputStream is) throws ParseException;
}

@Component
public class ParserFactory {
    private final List<ReportParser> parsers;   // Spring auto-injects all

    public ReportParser get(MimeType mt) {
        return parsers.stream()
            .filter(p -> p.supports(mt))
            .findFirst()
            .orElseThrow(() -> new UnsupportedMimeTypeException(mt));
    }
}

@Service
public class IngestionService {
    public Bundle ingest(MultipartFile file, String patientId) {
        ReportData data = factory.get(file.getMimeType()).parse(file.getInputStream());
        return fhirBuilder.build(data, patientId);   // returns FHIR Bundle
    }
}

Why Factory wins here

Alternative	Why it loses
If/else switch in service	Violates OCP; every new format = surgery on hot path
Strategy injected per call	Caller needs to know type — pushes decision upstream
Visitor on ReportData	Source data isn’t yet ReportData — chicken/egg
Factory + interface	New parser = new `@Component`. Zero changes elsewhere. Open-Closed honored.

Bonus interview points:

Each parser is independently testable (just feed bytes, assert ReportData).
LLM-based parsers wrap calls in your rate limiter + cache from §5.
Add a ParserMetrics decorator for per-format success rate.
Idempotency: hash the input → skip if already ingested.

7. CDC pipeline — sub-3-sec sync (Debezium)

Project: keep Postgres read-replica in sync with Mongo source-of-truth in <3 sec, end-to-end, for clinical data.

Architecture

┌──────────────┐  oplog tail  ┌────────────────┐  Avro+SR  ┌──────────────────┐
│   MongoDB    │ ───────────▶ │   Debezium     │ ────────▶ │      Kafka       │
│ (write side, │              │   Connector    │           │ (topic per coll, │
│  source-of-  │              │ (Kafka Connect)│           │  partitioned by  │
│  truth)      │              └────────────────┘           │   patientId)     │
└──────────────┘                                           └────────┬─────────┘
                                                                    │
                                                                    ▼
                                                          ┌────────────────────┐
                                                          │ Consumer Service   │
                                                          │  - validate        │
                                                          │  - transform       │
                                                          │  - upsert idemp.   │
                                                          └────────┬───────────┘
                                                                   │
                                          ┌────────────────────────┼────────────────────┐
                                          ▼                        ▼                    ▼
                                  ┌──────────────┐         ┌──────────────┐    ┌──────────────┐
                                  │  Postgres    │         │  DLQ topic   │    │  Audit Log   │
                                  │ (read-opt.)  │         │  + replay    │    │  (immutable) │
                                  └──────────────┘         └──────────────┘    └──────────────┘

Why this design

Mongo source-of-truth for one MS (write-heavy, flexible schema for evolving clinical forms).
Postgres read-side for analytics, joins, FHIR _search.
Debezium oplog tailing avoids dual-write — no chance of write succeeding in Mongo but failing in Postgres.
Outbox pattern variant: if you can’t use Debezium (e.g., on-prem hospital DB), write to a Mongo outbox collection in same txn → Debezium ships that collection.
Partition by patientId in Kafka → strict per-patient ordering, parallelism across patients.
Idempotent upsert in consumer (ON CONFLICT DO UPDATE with version guard from Mongo _v).

Failure handling

Failure	Response
Consumer poison message	Skip → DLQ topic with full payload + error. Replay tool reads DLQ.
Postgres outage	Consumer pauses, Kafka retains (7-day retention), catches up on recovery
Mongo failover	Debezium reconnects to new primary, resumes from last offset
Schema change	Avro + Schema Registry with `BACKWARD` compatibility enforced
Out-of-order events	Mongo doc `_v` (version) compared on upsert; older drops

Schema evolution

All Kafka payloads in Avro, schemas in Confluent Schema Registry.
Compatibility: BACKWARD (consumers using new schema can read old data).
New optional fields only; never delete or rename — deprecate then drop after 2 release cycles.

Map to Verily / Tempus interview Q: “Design EHR sync”

Hit these talking points:

Source-of-truth must be one system (otherwise reconciliation hell).
Log-based CDC beats poll-based (lower latency, no missed updates).
Partition for ordering at the right grain (patientId not recordId).
Idempotency with version guards.
Outbox if you control the writer but not the DB log.
Replay is a feature, not an afterthought — DLQ + offset rewind tool.
Schema registry for forward/backward compat in a long-lived stream.
Audit every transformation — compliance demands lineage.

8. Companies where this differentiator dominates

Company	Role focus	Why your healthcare-AI fits
Verily	SWE — life sciences data platforms	FHIR-native pipelines, clinical research data; your CDC + interop story lands directly
Tempus	SWE — oncology AI	Direct overlap — your oncology treatment plan + risk scoring is their core product
Oscar Health	Backend — claims + member experience	Healthcare insurance interop, FHIR US Core, prior-auth automation
Hippocratic AI	AI Engineer — safety-focused clinical LLMs	RAG + guardrails + eval rubrics — your exact toolkit
Color Health	Backend — genetic + clinical decision support	FHIR + clinical workflows; your factory-pattern extractor maps directly
Innovaccer	Backend — Healthcare Data Activation Platform	CDC + interop is the platform; you’ve built mini-version of their stack
Cigna Evernorth	SWE — care management + claims	Massive scale, FHIR APIs for value-based care
Walmart Health	Backend — clinics tech	FHIR for patient data exchange, scheduling
Anthropic — Claude for healthcare	SWE — applied	LLM productionization + safety; rate limiter story shines
AWS HealthLake / Bedrock	Solutions Engineer	FHIR-native data lake; you can speak both customer and stack
Abridge	AI Eng — clinical scribe	Real-time clinical LLM productionization
Commure / Athelas	SWE — physician AI platform	RAG over EHR, FHIR everywhere
Iodine Software	SWE — clinical AI for CDI	LLM + clinical documentation
Notable Health	SWE — clinical automation	RAG, EHR integration, factory-pattern extractors

Tier-1 best fit for your 3.5-yr profile: Tempus, Innovaccer, Hippocratic AI, Color Health, Abridge, Commure. These value the domain and hire SDE-II / mid-level aggressively.

9. Resume framing tip per audience

A. MAANG generalist (Google, Meta, Amazon, Microsoft)

Lead with technical complexity. Domain is a sentence at the end.

- Designed and shipped Debezium-based CDC pipeline (Kafka, Avro, Schema Registry) syncing 
  Mongo → Postgres with sub-3-second p95 latency; partitioned by tenant for strict ordering 
  and idempotent upserts. (healthcare data interop)

- Built per-tenant LLM rate limiter (Redis sliding-window + token-bucket hybrid) with 
  semantic caching and model-routing, cutting API spend 40% across production workloads. 
  (clinical AI services)

B. Healthtech (Tempus, Verily, Innovaccer, Oscar)

Lead with FHIR, HIPAA, clinical impact. Tech stack is the proof.

- Architected FHIR-compliant clinical data platform mapping unstructured oncology reports 
  (PDF/image/text/HL7v2) to Observation/DiagnosticReport resources via a Factory-pattern 
  extractor pipeline. HIPAA-compliant with PHI redaction, audit logging, and BAA-governed 
  LLM access. Stack: Spring Boot, Kafka, Debezium, Postgres, pgvector.

- Productionized clinical LLM summarization with RAG over patient FHIR records, citation 
  linking, and clinician-in-the-loop review; cut clinician documentation time by [X]%.

C. AI-first (Anthropic, Cohere, OpenAI, Hippocratic, Adept)

Lead with LLM productionization, evals, safety. Domain second.

- Built production LLM-gateway with per-tenant quotas, cost caps, model-routing 
  (cheap-first escalation), semantic+KV caching, and prompt-compression — 40% cost 
  reduction in regulated (HIPAA) healthcare workloads.

- Designed eval pipeline (factuality, completeness, harm) for clinical summarization, 
  with demographic slice tracking and shadow→pilot→GA rollout — zero adverse incidents.

- RAG over FHIR-structured EHRs with hybrid retrieval (BM25 + dense), citation-coverage 
  guardrail, and structured-output JSON-schema validation.

10. Reading list to deepen this moat (2026)

Specs & primary sources (skim, bookmark, quote in interviews)

HL7 FHIR R5 Spec — Resource Index — skim every resource name and one-line purpose.
US Core Implementation Guide — what US payers/providers actually require on top of base FHIR.
SMART App Launch Framework — OAuth profile.
HIPAA Security Rule (HHS) — administrative, physical, technical safeguards.
HIPAA De-identification Guidance — Safe Harbor vs Expert Determination.
42 CFR Part 2 — substance-use record protections.
openEHR Architecture Overview — archetypes & templates.

Patterns & engineering

“Building Generative AI Services with FastAPI” patterns — streaming, structured outputs, retries, idempotency.
Anthropic Prompt Engineering docs — system prompts, XML structure, prefilling.
Anthropic Tool Use — function calling patterns.
Debezium docs — connector configs, snapshot modes, signaling.
Confluent Schema Registry compatibility modes.

Papers (skim abstracts + conclusions — quote in AI rounds)

Med-PaLM 2 (Singhal et al., 2023) — clinical LLM eval methodology.
Hippocratic AI safety paper — red-teaming clinical LLMs.
Almanac / Retrieval-augmented clinical models — RAG for medicine.
Foundation Models in Healthcare (Moor et al., Nature 2023).
Mitchell et al. — Model Cards for Model Reporting (FAT* 2019).
Lost in the Middle (Liu et al., 2023) — context-position effects on retrieval.

Practical / community

HAPI FHIR — reference Java FHIR server; clone, run, query.
Synthea — synthetic FHIR patient generator; use for demos + interviews.
FHIR Bulk Data Access spec — $export for analytics workloads.

2-week study plan

Day	Focus
1–2	FHIR R5 resource list + REST + Bundles
3	SMART-on-FHIR + OAuth scopes
4	HIPAA Security Rule + De-identification
5	OpenEHR vs FHIR — write 1-pager from memory
6–7	Whiteboard FHIR server end-to-end; clone HAPI FHIR locally
8	Debezium hands-on with Synthea data
9	Rate-limiter mock interview (record yourself, 5 min)
10	Clinical summarization HLD (record, 10 min)
11	Factory-pattern LLD (record, 5 min)
12	Read Med-PaLM 2 + Hippocratic safety; write 1-pager rebuttal
13	Mock behavioral — 5 STAR stories anchored in oncology projects
14	Cross-company resume rewrite (3 versions per §9)

Quick-reference cheat card

FHIR:     resources, REST, JSON, Bundles, $search, SMART OAuth
OpenEHR:  archetypes + templates, AQL, persistence layer
HIPAA:    PHI, BAA, audit, encryption, min-necessary, safe-harbor
RAG:      chunk → embed → hybrid retrieve → re-rank → cite → validate
Rate-lim: sliding-window + token-bucket, semantic cache, model router
CDC:      Debezium → Kafka(Avro) → idempotent upsert, partition by patientId
Factory:  ReportParser interface → PDF/Image/Text/HL7v2 → FHIRBuilder
Evals:    factuality + completeness + harm, slice by demographic, shadow→pilot

Closing mantra: the system had to work, and not harm anyone. Lead with that, and the 3.5-year experience reads as 6.