Building the Healthcare Brain The Claude-First Healthcare FDE.
A capability-transfer engagement model for healthcare organizations building their own AI capability with Claude. Claude Code is mandated across every Healthcare Brain platform team. Where production agents call frontier models, Anthropic is the preferred provider. Sovereign and PHI-bound reasoning runs on local models inside the customer perimeter. The architecture is multi-model and customer-residency-aware; the development methodology is Claude-first.
Claude-First Healthcare FDE is Genzeon Platforms’ service for deploying agentic AI into payer, provider, and federal-program healthcare workflows. Engagements are staffed as 2-person pods: a Domain Operator (DO) as the clinical, regulatory, and operational lead, and a Forward Deployed Engineer (FDE) — a trained and certified Claude Architect — as the technical and Claude-deep implementation lead. Claude Code is mandated for platform development; the production substrate is multi-model. Live in CMS Medicare via the WISeR Innovation Model since January 1, 2026.
What Claude-First actually means.
Claude-First Healthcare FDE is Genzeon Platforms’ delivery methodology where every customer engagement is built and shipped using Claude as the primary development environment and Anthropic as the preferred provider for frontier model workloads — with multi-model production deployments that may include local, sovereign models for PHI-bound reasoning. The methodology is about how Genzeon Platforms builds and ships, not a claim that every line of inference in every deployment runs on Claude. Four operating commitments structure the practice.
-
Claude Code is the mandated development environment.
Every Healthcare Brain platform team writes, refactors, tests, documents, and reviews code with Claude Code. This is a build-time tooling decision, not a runtime architecture claim. It applies to the engineers working on HIP One, PES One, CPS One, and the underlying agentic substrate. The mandate is operational, not aspirational — it shows up in our developer workflows, our PR templates, and our internal engineering rituals.
-
Anthropic is the preferred provider for frontier model workloads.
Where production agents need to call a frontier model — for tasks like complex clinical reasoning, document understanding at long-context scale, or multi-step planning — Anthropic is our preferred provider. This is a model-selection preference, expressed in code, not an exclusivity contract. Customers who require an alternative frontier provider for legitimate operational reasons can be accommodated; the default goes to Anthropic.
-
Local models run sovereign and PHI-bound reasoning.
A substantial portion of clinical reasoning in Genzeon’s production deployments runs on local models inside the customer perimeter. This is the sovereign-deployment pattern that PHI-bound workloads require. Local model selection is workload-specific: smaller models for administrative pre-screening, mid-sized models for criterion evaluation, larger models reserved for the cases where frontier reasoning earns the cost. The substrate routes the workload to the right tier.
-
The architecture is multi-model. The methodology is Claude-first.
These are different layers and they should not be conflated. Multi-model architecture is what we ship to customers — it's what makes sovereign deployment, customer-perimeter inference, and workload-tier routing possible. Claude-first methodology is how we build what we ship. The methodology is consistent across every platform team; the architecture is configured per customer.
This articulation matters because the alternative — claiming "powered by Claude" as a blanket statement — misrepresents what production healthcare AI actually looks like. A health plan’s prior-authorization deployment may have Claude in the loop on some agents and a fine-tuned local Llama derivative on others, with the substrate orchestrating between them. Genzeon Platforms is honest about the architectural mix because customer-residency, latency, and cost characteristics all depend on understanding what runs where.
Two seats. One deployment unit.
A 2-person pod — one Forward Deployed Engineer who is a trained and certified Claude Architect, paired with one Domain Operator — is the minimum it takes to have an impact. The pod is the deployment unit, not the individual; the seats coordinate daily and co-own the engagement. We don’t cap the maximum: pods scale with the outcome (commonly 1–2 Domain Operators and 2–3 Forward Deployed Engineers), but two is the floor, never the ceiling. Both seats are certified, not just experienced: our Forward Deployed Engineers are Claude Architect–certified through the Anthropic Academy — a growing team — and our Domain Operators are certified through Genzeon’s own domain curriculum, published openly at the Healthcare Brain Academy.
Domain Operator (DO)
The customer-facing senior operator. The person at the table when the CMO asks why a case was denied, when the UM lead asks how the auto-affirm rate is trending, when the compliance officer asks about the audit trail.
- Clinical and medical-policy mapping (LCDs, NCDs, payer companion guides)
- Regulatory framework alignment (CMS-0057-F, CMS-0062-P, state AI laws)
- Workflow integration with customer's existing UM stack and EMR
- Operational KPI calibration (auto-affirm rate, TAT, productivity gains)
- The customer-facing audit conversation, end-to-end
Forward Deployed Engineer (FDE)
The technical owner of how Claude shows up in the customer’s build — through Claude Code in the platform engineering work, through the Claude API where it’s called by production agents, and through the orchestration layer that decides when to call Claude vs. a local model.
- Claude Code-driven platform engineering work for the customer’s deployment
- Multi-model orchestration: when to call the Claude API vs. local model
- Context engineering for clinical documents and long-form policy
- Prompt-pack architecture and the rule-pack engine integration
- Agent tool integration (FHIR, X12, EMR APIs) and eval-suite construction
One person rarely does both well. The clinical, regulatory, and operational competency belongs in customer-side conversations — with CMOs, UM leads, compliance officers, and clinical staff. The technical, model-orchestration, and Claude-implementation competency belongs in engineering and architecture conversations. The pod model puts the right operator in each conversation while keeping them coordinated as a single deployment unit. They share the customer’s production environment as their primary workplace; they share the audit trail; they share the success criteria.
The two-seat structure layers on top of the existing US + India delivery model. A typical pod has the Healthcare FDE in US time zones for customer-facing presence, and the Forward Deployed Engineer distributed across the US + India follow-the-sun rhythm for engineering velocity. The pod is one team across two time zones.
How Claude Code shapes the way we ship.
Claude Code is the mandated development environment across every Healthcare Brain platform team. This shows up in the engineering work itself — not as a marketing statement, but in the cadence and quality of what gets shipped.
The Healthcare Brain’s platform engineering — the rule-pack engine, the audit ledger, the channel orchestrator, the FHIR PA API surface, the agent runtime — gets built with Claude Code in the loop on every commit. The mandate is operational. New engineers onboard into a Claude Code-first workflow on day one. Pull requests carry Claude Code context. Documentation, test scaffolds, and refactoring proposals come through the same toolchain.
What this gives the customer. Customers do not buy Claude Code — it is an internal Genzeon engineering tool. What customers experience is the second-order effect: tighter release cycles, faster turnaround on customer-specific rule packs, and a platform that gets better between minor releases rather than only at major milestones. When a CMS rule changes, or a payer’s medical-policy library is updated, the platform team can ship the corresponding rule-pack and adapter code on a timeline measured in days, not quarters.
What it doesn’t mean. Claude Code being mandated for platform development is not the same as Claude being the model behind every production inference. The runtime architecture is multi-model, as documented in Section 1. Conflating build-time tooling and runtime architecture is a category error worth being explicit about, especially with sophisticated buyers who will ask the question.
Where Claude runs in production — and where it doesn’t.
A workload-by-workload view. The architecture routes specific inference tasks to specific model tiers based on residency requirements, latency sensitivity, and clinical complexity. Claude is one tier among several.
| Workload | Typical model tier | Why |
|---|---|---|
| Platform development — all teams | Claude Code (build-time) | Mandated development environment. Code authoring, refactoring, testing, documentation, review. |
| Clinical record summarization (PHI-bound) | Local model, customer perimeter | Data residency. PHI does not leave the customer’s VPC. |
| Medical-necessity criterion evaluation | Local model + Claude API (selectively) | Local for the bulk of evaluation; Claude API for cases requiring deep reasoning across long clinical context, where Anthropic’s frontier capability earns the cost. |
| Document classification + intake triage | Local model, customer perimeter | High volume, low complexity. Local models handle this efficiently. |
| Long-context policy synthesis | Claude API (Anthropic preferred) | Long-context handling is where frontier models earn their keep. Anthropic is the preferred provider. |
| Member-facing engagement (PES One) | Microsoft Healthcare Bot + local model | Voice / IVR / digital intake runs on the Microsoft Healthcare Bot infrastructure with model selection per task. |
| Governance and audit-trail synthesis (CPS One) | Local model, customer perimeter | Compliance synthesis stays inside the perimeter. Audit ledger does not call external APIs. |
The orchestration decision. The Healthcare Brain’s substrate makes the model-routing decision at the inference level — not at the application level, and not by configuration alone. The decision incorporates the workload characteristics, the customer’s residency policy, the document sensitivity classification, and the latency budget. The Forward Deployed Engineer on the deployment pod owns this routing configuration: the calibration of when each tier is invoked, the cost-versus-quality tradeoffs, and the eval-suite that holds the routing accountable.
What Anthropic-preferred means in practice. When the routing decision says "frontier model required for this task," the call goes to the Claude API by default. Customers running on cloud infrastructure with Bedrock or Vertex AI access typically reach the Claude API through those channels. Customers in sovereign deployments may not have any frontier-model access for PHI-bound tasks at all — in which case the routing keeps the workload local, with no degradation in the audit trail or governance posture.
Three shapes. Pick the one that fits.
Claude-First Healthcare FDE engagements come in three shapes. The shape is the commitment surface; the pod is the same.
30-day Claude-First architecture sprint.
A focused, fixed-scope engagement to deploy a Claude-First pod into the customer’s environment, instrument the model-routing decisions, build the eval suite, and ship a production-ready proof point on a defined workflow. Best fit for customers evaluating a Claude-First approach before committing to a longer engagement.
Embedded pod for production deployment.
A 12–16 week production deployment with the pod customer-side throughout. The Healthcare FDE leads the clinical, regulatory, and operational integration; the Forward Deployed Engineer leads the platform engineering work in Claude Code and the runtime model orchestration. Standard shape for customers moving an agentic workflow into live production.
Multi-pod continuous engagement.
Multiple pods deployed across the customer’s portfolio of agentic workflows, with the platform shipping daily. Best fit for large payers, health systems, or federal-program operators with several production AI workloads simultaneously. The pod structure remains 2 + 2 + 2; the coordination layer adds a Practice Lead.
Healthcare FDEs with deep Claude implementation experience.
The Claude-First Healthcare FDE practice draws from Genzeon Platforms’ senior engineering and clinical-domain pool. The technical seat is staffed by senior engineers with deep, daily Claude implementation experience across Claude Code, the Claude API, and multi-model orchestration patterns.
Every Forward Deployed Engineer on the practice has shipped production Claude integrations into healthcare workflows under HIPAA constraints. Every Healthcare FDE on the practice has operated customer-side in payer, provider, or federal-program environments. The two roles are complementary by design.
The practice is growing. Healthcare FDE candidates and senior engineers who want to work at the intersection of healthcare regulatory complexity and frontier AI implementation can contact the team directly.
Your team learns alongside our published curriculum.
A Claude-First Practice engagement is, structurally, knowledge transfer. The Healthcare Brain Academy is the same curriculum our team completes before customer engagement — we run it alongside your team, with engagement-specific extensions for your stack and your buyers.
Builders Tracks 1–4
Medical coding literacy. Regulatory framework. Production discipline. Clinical validation. The curriculum every Healthcare FDE completes — now run for your team, with hands-on application to your Claude-based agents.
See the Builders curriculum → For your customer-facing teamClient Engagement Tracks 1–4
Health insurance fluency. Workflow literacy. Use-case depth. Competitive positioning. The shared vocabulary your internal customers and external client-facing teams operate from.
See the Client Engagement curriculum →Healthcare Brain Academy is published, free, and open. Customers do not pay for curriculum access. The Claude-First Practice engagement adds hands-on application against your workflows, your codebase, and your audit posture — the work that turns curriculum knowledge into shippable agentic AI in your environment.
Common questions about Claude-First Healthcare FDE.
What does Claude-First mean at Genzeon Platforms?
Claude-First is Genzeon Platforms’ development methodology, not a single-model architectural claim. Claude Code is mandated as the development environment across every Healthcare Brain platform team. Where production agents call frontier models, Anthropic is the preferred provider. Sovereign and PHI-bound reasoning runs on local models inside the customer perimeter. The architecture is multi-model and customer-residency-aware; the development methodology is Claude-first.
What is the 2-person POD model?
Every Claude-First Healthcare FDE engagement is staffed as a 2-person pod. Seat 1 is a Healthcare FDE — the clinical, regulatory, and operational lead, customer-side embedded. Seat 2 is a Forward Deployed Engineer — the technical and Claude-deep implementation lead. The Healthcare FDE owns the outcome the customer signs off on; the Forward Deployed Engineer owns how Claude Code, the Claude API, and local model orchestration deliver against that outcome. The pod is the deployment unit, not the individual.
Does Genzeon Platforms use Claude exclusively?
No. The architecture is multi-model. Claude Code is mandated for platform development across every Healthcare Brain team. The Claude API is used by some production agents where frontier-model reasoning is required. A substantial portion of clinical reasoning runs on local models deployed inside the customer perimeter — this is the sovereign-deployment pattern that PHI-bound workloads require. When frontier models are called, Anthropic is the preferred provider.
How does Claude Code shape platform development?
Claude Code is the mandated development environment for every Healthcare Brain platform team. Engineering teams use Claude Code for code authoring, refactoring, test generation, documentation, and review. This is a build-time tooling decision, not a runtime architecture claim. The platforms shipped to customers run on the multi-model substrate described in the Healthcare Brain architectural whitepaper.
Why a 2-person pod rather than a single FDE?
Healthcare AI deployments demand two distinct competencies in close coordination. The clinical, regulatory, and operational competency belongs in customer-side conversations — CMOs, UM leads, compliance officers. The technical, model-orchestration, and Claude-implementation competency belongs in engineering and architecture conversations. One person rarely does both well. The pod model puts the right operator in each conversation while keeping them coordinated as a single deployment unit.
How does Claude-First work for sovereign deployments?
For sovereign or strict-residency deployments, Claude-First applies fully to the development methodology — the platform engineering work still happens with Claude Code — but the runtime architecture may have no frontier-model access at all. In those configurations, the production substrate runs entirely on local models inside the customer perimeter. The Forward Deployed Engineer on the pod is responsible for the runtime model routing, including the case where the routing decision is "always local for this customer." The methodology remains intact; the architecture is configured to the residency policy.
Can the Claude API run in our Bedrock or Vertex AI environment?
Yes. Customers with Amazon Bedrock or Google Vertex AI access typically reach the Claude API through those channels for the workloads where frontier-model reasoning is invoked. This is the hybrid deployment pattern: customer-perimeter inference for PHI-bound tasks, plus Claude API access through Bedrock or Vertex for the workloads where frontier models earn the cost. Routing happens at the substrate level.
Who decides when to call Claude vs. a local model?
The Healthcare Brain substrate makes the routing decision at the inference level based on workload characteristics, residency policy, document sensitivity, and latency budget. The Forward Deployed Engineer on the deployment pod owns the routing configuration — the calibration of when each tier is invoked, the cost-versus-quality tradeoffs, and the eval suite that holds the routing accountable. Customer compliance officers sign off on the routing policy as part of standard engagement approval.
How long does a Claude-First engagement take to reach production?
The 30-day architecture sprint shape ships a production-ready proof point on a defined workflow in 4–6 weeks. The embedded pod placement shape takes 12–16 weeks to a full production deployment. Continuous-operation engagements run open-ended. Genzeon Platforms went from CMS WISeR contract award to live Medicare prior authorization production in approximately six months, which represents the federal-regulatory-context envelope; most commercial engagements move faster.
Continue the argument.
What a Claude-First Healthcare FDE pod actually does.
A day-in-the-life narrative of the 2-person pod in production. The decisions, the handoffs, the customer-side rhythm. ~4,000 words.
Read the field note The full FDE practiceHealthcare FDE 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 whitepaperEngage a Claude-First Healthcare FDE pod.
A 30–45 minute conversation with the senior engineering and clinical leads who would staff your pod. Bring an architectural question, a compliance scenario, or a pilot shape you want to test.
Schedule a conversation →