Building the Healthcare Brain What a Claude-First Healthcare FDE pod actually does.
A day-in-the-life field note on the 2-person POD model in production. The decisions, the handoffs, the customer-side rhythm. How a Domain Operator coordinates with a Forward Deployed Engineer to ship agentic AI into a regulated payer workflow without losing audit-grade defensibility.
~4,200 words · By the Genzeon Platforms Healthcare FDE practice · Published May 18, 2026
A Claude-First Healthcare FDE pod is a 2-person customer-embedded team. Seat 1 is a Domain Operator leading clinical, regulatory, and operational integration with the customer. Seat 2 is a Forward Deployed Engineer leading Claude-deep platform engineering, multi-model orchestration, and runtime model routing. The pod ships agentic AI into the customer’s production environment using Claude Code as the mandated development methodology and a multi-model runtime architecture — Claude API for frontier workloads where Anthropic is the preferred provider, local models for PHI-bound reasoning inside the customer perimeter. The pod is the deployment unit, not the individual.
Healthcare AI sales pitches are everywhere. Healthcare AI operations is less visible.
Most public material on healthcare AI is sales material. Most of what production deployment actually looks like — the daily rhythm, the handoffs, the moments when a decision has to be made fast — doesn’t make it into the marketing layer. This field note is the operational version.
The audience for this note is the senior buyer who has seen the pitches and wants to understand what they would actually be paying for. CMOs, VPs of UM, CIOs, Heads of Compliance, Chief Engineering Officers. The argument is operational, not architectural. The architectural argument lives in the Healthcare Brain substrate whitepaper; the compliance argument lives in the Medical PA Compliance Engineering whitepaper; this note documents how the pod that ships those architectures actually operates.
Names and identifying details from the example engagements have been changed; the operational patterns are real.
Two seats. One deployment unit.
The pod is the smallest viable unit for a Claude-First Healthcare FDE engagement. Smaller doesn’t work for the reasons documented below; larger is just multiple pods.
Seat 1 — the Domain Operator. Senior operator with clinical, regulatory, and operational depth in the customer’s context. Comes from a background spanning some combination of utilization management, payer operations, clinical informatics, regulatory affairs, and healthcare technology integration. The Domain Operator is the customer-facing partner: at the table for the CMO conversation, the UM operations review, the compliance audit walk-through, the medical-policy committee meeting. The Domain Operator owns the outcome the customer signs off on.
Seat 2 — the Forward Deployed Engineer. Senior engineer with deep, daily Claude implementation experience — Claude Code as the development environment, the Claude API for production agent calls, multi-model orchestration patterns, eval-suite construction, prompt-pack engineering. The Forward Deployed Engineer is the technical owner of how Claude shows up in the customer’s deployment. (After June 2026 certification completion, this seat’s public title becomes "Claude Architect"; the role responsibilities remain the same.)
The pod is the unit, not the individual. Genzeon Platforms does not staff Healthcare FDE engagements as single-operator placements. The 2-person structure is operational doctrine because the work itself splits cleanly along the clinical/regulatory axis versus the technical/Claude axis — and forcing one person to operate both surfaces well, daily, customer-side, is the single most common failure mode we have seen in the broader healthcare-AI consulting market.
What the pod actually does, hour by hour.
An archetype of a typical week, mid-engagement, on an embedded pod placement at a Medicaid managed care organization preparing for the January 2027 FHIR PA API compliance deadline. Names changed; operational rhythm real.
Customer standup — clinical side
The Domain Operator joins the customer’s UM operations standup. The customer’s associate medical director walks through the previous week’s case volume by service category and flags three borderline determinations for review.
Domain OperatorPod sync — the week ahead
The Domain Operator and Forward Deployed Engineer sync on the customer signals from the standup. Decision: one of the borderline determinations involves a service category that surfaces twice this week, so it’s a candidate for an updated rule-pack adjustment. The Forward Deployed Engineer takes it.
Domain OperatorForward Deployed EngineerRule-pack drafting in Claude Code
The Forward Deployed Engineer drafts an updated criterion decomposition for the service category in question. Claude Code is the development environment: the engineer authors the rule-pack markdown with Claude’s assistance, reviews the LCD policy source verbatim, and writes the corresponding eval cases that the rule pack will be tested against. The work takes ~3 hours including the eval suite.
Forward Deployed EngineerClinical sign-off on the rule-pack draft
The Domain Operator walks the draft rule pack through the customer’s clinical leadership. The medical director and the UM lead read the criterion decomposition and the source-policy citations together. Approval comes back with one wording change. The pod ships the corrected pack to the customer’s staging environment by end of day.
Domain OperatorEval suite runs overnight; results triaged
The Forward Deployed Engineer reviews the overnight eval-suite run on the new rule pack against the customer’s retrospective case dataset. Two cases produced unexpected non-affirmations. Investigation: both cases involve clinical context that the rule pack underweights. The engineer files them as edge cases for the next iteration.
Forward Deployed EngineerCustomer CTO conversation — FHIR API readiness
The Forward Deployed Engineer joins the customer’s CTO conversation on the FHIR PA API build for the January 2027 deadline. The Domain Operator is on the call as well, primarily listening. The conversation is technical: Da Vinci PAS implementation guide alignment, the SMART App Launch 2.0.0 integration, how the substrate routes between the FHIR PA API and the existing X12 278 pipeline during the transition window.
Forward Deployed EngineerDomain OperatorFHIR Implementation Guide work in Claude Code
The Forward Deployed Engineer continues the FHIR PA API integration work in Claude Code. The Da Vinci CRD response format and the DTR Questionnaire population are being wired into the substrate’s adapter layer. Claude Code helps draft the FHIR Questionnaire schema mapping; the engineer reviews it against the implementation guide and the customer’s test cases.
Forward Deployed EngineerCustomer compliance officer conversation
The Domain Operator meets with the customer’s Chief Compliance Officer to walk through the audit-ledger structure for the public reporting that’s due to CMS by March 31. The conversation is regulatory: which metrics will be reportable, how the audit ledger feeds the reporting pipeline, what the per-criterion citation chain looks like to a CMS auditor.
Domain OperatorCross-pod sync on routing logic
The Forward Deployed Engineer joins a cross-pod technical sync. Engineers from another customer engagement are running into a multi-model routing edge case where a clinical record is long enough that local-model summarization is producing inconsistent quality. The decision is escalated to the platform team: this is a substrate-level routing-policy question, not a per-customer config.
Forward Deployed EngineerOperational review with customer UM ops
The Domain Operator leads the weekly operational review with the customer’s UM operations leadership. The agenda covers the previous week’s auto-affirmation rate trend, the volume of cases that flowed to human clinical review, the median TAT, and the rate of provider follow-up calls. Each metric is read against the engagement’s success criteria. The Forward Deployed Engineer is on the call to answer the technical questions when they come up.
Domain OperatorForward Deployed EngineerPod-internal: prompt-pack architecture refinement
The two seats spend an hour together on the prompt-pack architecture for the next phase of the engagement — specifically, how the rule-pack inheritance model handles state-specific Medicaid variations the customer operates across. Claude Code is in the loop for the engineering work; the conversation includes domain interpretation of the state Medicaid policy differences.
Domain OperatorForward Deployed EngineerCustomer leadership readout
The Domain Operator delivers the weekly readout to the customer’s senior leadership: CMO, VP UM, CIO. Content covers the metrics review, the rule-pack changes shipped during the week, the audit-ledger health, and any operational items that need attention. The Forward Deployed Engineer is in the room.
Domain OperatorInternal practice contribution
Both seats spend Friday afternoon on practice-level contribution: a write-up of the routing edge case from Wednesday for the shared engineering library, a refinement of the medical-policy mapping checklist for the FDE field guide. The expectation across the Claude-First practice is that operational learning from one engagement flows back to the practice library so the next pod inherits the improvement.
Domain OperatorForward Deployed EngineerA few patterns from this archetype are worth naming explicitly. The Domain Operator seat is heavier on customer-facing time and clinical/regulatory conversation; the Forward Deployed Engineer seat is heavier on engineering and substrate work. But the seats overlap on every customer-facing conversation that has technical substance — the CTO conversation, the routing-policy questions, the operational review when a metric raises a model-quality question. Neither seat handles those conversations alone.
When does the pod call Claude, and when does it not?
The most operationally consequential decision in a Claude-First deployment is the routing decision: which workload runs on which model tier. The Forward Deployed Engineer owns this decision; the Domain Operator owns the customer policy that constrains it.
The substrate handles the routing at the inference level, but the routing policy is configured by the pod during the engagement. The decision is not "Claude versus not-Claude" — it is "which model tier earns this specific workload." A worked example follows.
The case: A customer’s prior-authorization request arrives via the FHIR PA API. It contains a Patient resource, Coverage, ServiceRequest, eight DocumentReferences (one of which is a 14-page consult note in unstructured text), and a QuestionnaireResponse partially completed. The customer’s policy is HIPAA-bound with a strict perimeter requirement: nothing identifiable leaves the customer’s VPC.
Intake and classification — local model. The 14-page consult note is summarized, the documents are classified by type, and the completeness of the QuestionnaireResponse is assessed. All inside the customer perimeter. No frontier-model call.
Criterion evaluation — primarily local, selectively Claude API. The relevant coverage policy is decomposed into atomic criteria. Most criteria evaluate cleanly on the local model. One criterion involves complex temporal reasoning across the patient’s clinical history; the substrate routes this single criterion-evaluation to the Claude API (via Bedrock, in the customer’s VPC). The de-identification layer scrubs PHI before the call.
Determination synthesis — local model. The criterion-level evaluations are aggregated into a determination. The per-criterion citation chain is constructed. The audit-ledger entry is generated. All local. No frontier-model call.
Non-affirmation routing — if applicable, evidence package construction. If the determination is non-affirmation, the substrate constructs the evidence package for the licensed human clinical reviewer. The package includes the unmet criteria, the source policy quoted verbatim, the patient’s submitted documentation, and the suggested additional documentation that would change the determination. Constructed locally.
Member communication draft — primarily local, selectively Claude API. When the determination requires a plain-language member notification, the PES One Engagement Lobe drafts the message. Most communications draft cleanly on the local model. Edge cases — rare conditions, multi-determination cases, language-specific framing — may route to Claude API.
The architecture is multi-model. In this case, exactly one substrate-level call to the Claude API happened, on one criterion, with PHI scrubbed before the call. The remainder of the workload ran on local models inside the customer perimeter. The Forward Deployed Engineer on the pod tunes this routing during the engagement. The eval suite holds the routing accountable: if the local-model criterion evaluation degrades in quality, the routing policy can shift more criteria to the Claude API; if the local model is performing well, the API budget can be reserved for the highest-complexity cases.
For a customer running entirely sovereign with no frontier-model access, the same workflow runs but step 02’s Claude API call is replaced with a higher-tier local model and the routing policy reflects that. The audit trail and the citation chain look identical in either configuration.
How the two seats hand work to each other.
A 2-person pod only works if the handoffs are operationally clean. (The 2-person pod — one Domain Operator and one Claude Architect-certified Forward Deployed Engineer — is the minimum it takes to have an impact; pods commonly scale to 4–5 people, with no fixed maximum. This note follows the minimum pod precisely because clean handoffs matter most when the team is smallest.) Five patterns worth naming.
Handoff 1: Clinical question → technical implication. The Domain Operator surfaces a clinical pattern from the customer’s UM operations — for example, that a particular service category produces a higher-than-expected rate of non-affirmations on first review. The Forward Deployed Engineer takes this as a candidate for rule-pack refinement, runs the relevant cases through the eval suite, and proposes either a criterion adjustment or an evidence-extraction improvement.
Handoff 2: Technical limit → clinical conversation. The Forward Deployed Engineer identifies a constraint — a model behaving inconsistently on a specific document type, an eval result that suggests the routing policy is under-serving a workload class. The Domain Operator takes this into the clinical conversation: does the customer have additional documentation patterns they could provide for this document type, or is there a clinical context that the eval suite is missing.
Handoff 3: Regulatory change → substrate change. CMS issues a guidance update or a state Medicaid policy revises. The Domain Operator flags it within hours. The Forward Deployed Engineer maps the change to substrate-level work — rule-pack updates, API surface changes, audit-ledger field additions — and the pod ships the change on a timeline measured in days.
Handoff 4: Audit question → substrate evidence. The customer’s compliance officer asks how a specific determination was made. The Domain Operator pulls the audit-ledger entry. The Forward Deployed Engineer can walk the technical layer if needed: which model tier produced which intermediate output, what the citation chain looks like at the schema level, where the human reviewer attestation came from. The two seats together can defend any individual determination to an external auditor.
Handoff 5: Customer escalation → coordinated response. A high-visibility determination — a complex case, a provider escalation, a member appeal that has reached executive leadership — reaches the pod. Both seats engage. The Domain Operator handles the customer-facing conversation; the Forward Deployed Engineer is available in the room with the substrate evidence in real time. Neither seat goes alone on high-stakes escalations.
Patterns from operating Claude-First pods in production.
The Claude-First Healthcare FDE practice is still maturing. A few learnings have already stabilized into how we staff and operate the pods.
Pattern 1: The clinical seat must come from healthcare, not from generic consulting. The Domain Operator role does not work as a "smart generalist" assignment. The customer-facing conversations are with clinicians, compliance officers, and operations leaders who have been doing this work for fifteen years. Without depth, the conversations don’t land and the pod loses customer-side trust within weeks. The role is structured as a healthcare-domain career path, not a consulting-firm rotation.
Pattern 2: The technical seat must operate Claude daily, not occasionally. Claude Code, the Claude API, and multi-model orchestration are evolving fast. A Forward Deployed Engineer who touches Claude weekly does not perform the role at the level required. The seat is for engineers whose daily work, across multiple engagements and platform contributions, is Claude-deep. This is also why the Anthropic Academy certification (in progress as of May 2026, completing in June) became a practice requirement — it formalizes the depth-of-practice standard the role demands.
Pattern 3: The pod has to ship in the customer’s environment, not parallel to it. The early version of the practice experimented with "parallel build" engagements — where the pod built in a Genzeon-side environment and handed deliverables over to the customer. That model failed predictably: the deliverables didn’t fit the customer’s integration surface, the audit trail didn’t map to the customer’s reporting pipeline, and the customer’s engineering and clinical teams didn’t develop the operational ownership needed to run the system after handoff. The current model is customer-environment-first: the pod ships into the customer’s production environment from week one, with all the access, observability, and integration friction that implies.
Pattern 4: Routing-policy decisions are clinical decisions in disguise. The substrate-level decision about which model tier handles which workload looks technical, but it is consequential clinically. Routing a criterion-evaluation to a lower-tier local model that produces slightly less consistent reasoning is a clinical decision; routing it to the Claude API at higher cost is a clinical decision. The pod treats routing-policy reviews as joint clinical/technical conversations, not as engineering optimization.
Pattern 5: The practice library is the moat. A single pod can ship a great engagement. A practice of pods sharing operational learning across engagements ships better engagements faster, every quarter. The contribution rhythm — Friday afternoons spent feeding learning back to the shared library — is the structural mechanism that prevents the practice from being a collection of individually skilled operators.
Common questions.
Could we hire just the Domain Operator without the Forward Deployed Engineer?
The pod is the unit. Genzeon Platforms does not staff Healthcare FDE engagements as single-operator placements because the Claude-deep technical work and the clinical/regulatory work are genuinely different competencies. Engagements that try to fit both into one operator typically lose ground on the side that’s second priority for that individual.
How is a Claude-First pod typically engaged?
Three engagement shapes are standard: a 30-day architecture sprint to deploy a proof-point on a defined workflow; a 12–16 week embedded pod placement to ship a full production deployment; or a continuous operation engagement with multiple pods across a customer’s agentic-workflow portfolio. Engagement terms are tailored per customer; the pod structure is consistent.
Which Claude model does the pod use in production?
The substrate routes to whichever Anthropic model is appropriate for the workload at the time of the call. The routing policy is calibrated per engagement during the deployment phase. Model selection is not a fixed configuration — the substrate is built to evolve as Anthropic ships new model tiers, which is one of the operational benefits of the Claude-First methodology.
What if our deployment requires zero external API calls for PHI?
The sovereign deployment pattern handles this. The substrate runs entirely on local models inside the customer perimeter. The routing policy is configured to keep all PHI-bound workloads on local-tier inference; no frontier-model calls leave the perimeter for those workloads. The Forward Deployed Engineer on the pod is responsible for the routing configuration that enforces this. The audit trail and citation chain are identical to the hybrid configuration.
What happens after the engagement ends? Does our team operate the system?
The handoff is built into the engagement from week one. The customer’s clinical, IT, and compliance teams operate alongside the pod throughout the engagement so the operational ownership accrues to the customer in real time. After the embedded pod placement ends, customers typically continue with a lighter continuous-operation engagement — one pod, part-time, supporting the customer’s now-owned production system.
Why call it a pod rather than a team?
"Pod" signals the small, fixed, complementary-role structure. A team can be five or fifty; a pod is two by definition, and the two roles are intentionally distinct. The naming is operational doctrine, not branding — it’s how engagements are quoted, staffed, and managed internally.
Are your engineers Claude-certified?
Senior engineers on the Claude-First practice are deepening their Claude implementation expertise through internal certification on Claude Code, Claude API integration, and multi-model orchestration patterns. Anthropic Academy Claude Architect certification is in progress for the practice and is expected to complete in June 2026.
Continue the argument.
The Claude-First Healthcare FDE practice.
The methodology, the 2-person POD model, the engagement shapes, and how to engage a pod.
See the practice page Full FDE practiceDomain Operator field guide.
The broader Healthcare FDE practice context. Specialist tracks, engagement shapes, US + India delivery model, integration depth across FHIR R4 / X12 / EMR.
See the full practice Architecture whitepaperInside the Healthcare Brain.
The architecture the Claude-First pod deploys. Triple-Tier Agentic Architecture, six substrate principles, governance invariants, patent foundation. ~5,800 words.
Read the whitepaperTalk to a Domain Operator pod lead.
A 30–45 minute conversation with the senior leadership of the Claude-First Healthcare FDE practice. Bring a deployment scenario, an architectural question, or a pilot shape you want to test.
Schedule a conversation →