Healthcare Client Playbook#

Executive Summary#

Healthcare AI client engagements differ from general enterprise AI engagements in ways that are structural, not incidental. The regulatory environment (HIPAA, FDA SaMD, ONC information blocking), the clinical workflow complexity, the multi-stakeholder decision-making structure, the liability sensitivities, and the integration standards (FHIR R4, CDS Hooks, HL7 v2) all require specialized FDE knowledge that cannot be improvised from general enterprise AI experience. This chapter synthesizes the FDE engagement knowledge from throughout this section with the healthcare AI technical knowledge from Phase 5 into a unified playbook for healthcare client engagements. It is the chapter that ties together discovery, assessment, demo engineering, POC design, architecture review, value engineering, communication, and objection handling into a coherent operational guide for the healthcare FDE.

Learning Objectives#

• Apply the full FDE engagement lifecycle to healthcare client contexts with healthcare-specific adaptations at each stage
• Navigate the healthcare stakeholder landscape including CIO, CMIO, CMO, CNO, Compliance, and IT
• Conduct healthcare-specific discovery covering EHR integration, HIPAA compliance path, and clinical workflow
• Design and present value engineering models for clinical AI use cases
• Handle the most common healthcare-specific objections with substantive technical responses

Business Problem#

Healthcare organizations are under simultaneous pressure from multiple directions: CMS quality metrics and readmission penalties, Joint Commission documentation requirements, physician burnout (driven substantially by documentation burden), payer prior authorization complexity, coding accuracy requirements, and operational efficiency mandates. AI can address multiple of these pressures — but healthcare organizations are also structurally risk-averse. Clinical AI mistakes carry patient safety and liability consequences that have no analog in non-healthcare AI deployments.

The healthcare FDE must hold both realities simultaneously: the urgency of the business problem and the legitimacy of the caution. Healthcare clients are not being difficult when they require rigorous security review, clinical validation, and physician champion involvement — they are being responsible. The FDE's job is to help them move through a rigorous process efficiently, not to shortcut the process.

Conceptual Explanation#

Healthcare AI engagements follow the same eight-phase lifecycle as general FDE engagements (Discovery → Assessment → POC Design → POC Execution → Architecture Review → Production Planning → Launch → Expansion), but with healthcare-specific activities, stakeholders, and constraints at each phase.

The most structurally different characteristic of healthcare engagements is the multi-stakeholder veto structure. In a typical enterprise, the CIO and a business leader make the technology decision. In healthcare:

• CIO: owns infrastructure and IT architecture
• CMIO: owns clinical informatics and clinical AI governance
• CMO: accountable for clinical quality and physician workforce
• CNO: accountable for nursing workflow and patient safety
• Privacy Officer / Compliance: gate for any PHI-involving system
• IT Security: gate for any system connecting to the EHR
• Revenue Cycle (for administrative AI): owns billing and coding systems
• Physician Champions: peer-level advocates without whom clinical adoption will not occur

All of these stakeholders must be engaged. Missing any one of them creates a production blocker at exactly the moment the engagement is otherwise ready to move.

Core Architecture: The Healthcare Engagement Map#

Stakeholder Map by Engagement Phase#

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Discovery — Healthcare-Specific Additions#

The standard discovery framework (Chapter 2) applies fully. Healthcare-specific additions:

FHIR and EHR discovery questions:

Compliance discovery questions:

Clinical workflow discovery:

The most effective clinical workflow discovery question is "walk me through what happens from [trigger] to [outcome]" — not "how does your workflow work?" Open-ended observation questions produce more accurate current-state maps than closed-ended confirmation questions.

For discharge summary AI, the trigger is "physician decides patient is ready for discharge" and the outcome is "discharge summary filed in Epic." Walk through every step, every handoff, every system touched, and every manual intervention.

Assessment — Healthcare-Specific Dimensions#

The standard three-dimension readiness assessment (Chapter 3) applies. Healthcare-specific additions:

Data maturity — clinical data quality indicators:

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Infrastructure — healthcare-specific:

• HIPAA-eligible cloud environment confirmation (Azure, AWS, or GCP HIPAA BAA tier)
• PHI-in-cloud policy status
• Audit logging infrastructure (SIEM capability; 6-year retention achievable)
• Epic App Orchard review timeline (budget 8–12 weeks)

Organizational — healthcare-specific:

• Clinical informatics team capacity (do they have engineers who understand FHIR?)
• Model Review Board existence and composition
• Physician champion identified and available
• Change management owner (who will train physicians?)

POC Design — Healthcare-Specific#

Healthcare AI POC evaluation rubric:

For any clinical AI POC, the evaluation must be conducted by qualified clinical reviewers — not just technical metrics.

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Architecture Review — Healthcare-Specific Risk Patterns#

The standard architecture review (Chapter 6) applies. Healthcare-specific additions:

PHI data flow must be explicitly traced. Every connection through which PHI flows must be diagrammed with the security controls applied at each path. This is not optional — it is required for HIPAA Security Rule compliance documentation.

Healthcare AI-specific risk patterns (additions to the standard library):

Value Engineering — Healthcare Use Cases#

Healthcare AI value engineering centers on four primary benefit drivers:

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Common Healthcare Objections and Responses#

Healthcare-specific objections beyond the standard eight (Chapter 9):

Objection: "Epic told us not to use third-party AI tools." This objection reflects either a misquotation or a misunderstanding of Epic's actual position. Epic offers its own AI tools (Nuance DAX integration, Epic Cognitive Computing) and supports third-party SMART on FHIR applications through the App Orchard program. The objection may be a proxy for "we don't want to go through App Orchard" or "we want to wait for Epic's native AI." Acknowledge this as a valid strategic choice and ask: "What is Epic's timeline for the native capability, and is that timeline acceptable given your documentation burden?"

Objection: "We need to wait for the FDA to clarify AI regulations." FDA AI/ML guidance has been evolving since 2019 with the proposed regulatory framework. The 2022 CDS Software Guidance provided clarity on the non-device CDS vs. SaMD distinction that is sufficient for most documentation and administrative AI use cases. This objection often reflects uncertainty rather than a specific regulatory concern. Ask: "Which specific regulatory question are you uncertain about? Let's see if we can answer it directly." For documentation AI (which is typically non-device CDS), the regulatory path is well-established.

Objection: "Our physicians don't trust AI." This objection is almost always true about some physicians and false about others. The response is not to argue the point but to find the exceptions: "That's often true in the early stage — which is exactly why the physician champion approach works. Who is the most technically curious hospitalist on your team? Would the CMIO be willing to do a 30-minute session with that person before the formal evaluation?" A single trusted peer who has used the tool changes the conversation.

Objection: "We can't get PHI into the demo." This is not an objection — it is correct practice. No real PHI should appear in demo environments. Acknowledge this, explain the synthetic data approach, and show the demo with clearly labeled synthetic patient data. If the client wants to see the tool on "something that looks like our patients," arrange for de-identified data to be used in the POC, not the demo.

Architecture Diagram#

Common Mistakes#

1. Not engaging Compliance early enough. Compliance engagement that begins in week 6 of a 4-week POC produces a production blocker. Compliance must be in the discovery scope.

2. Assuming App Orchard follows a predictable timeline. App Orchard reviews vary significantly. The only way to know the timeline for a specific client is to ask their IT team who has been through it before.

3. Treating the physician champion as a nice-to-have. Clinical adoption without peer advocacy is much slower. The physician champion is a required component of the engagement, not optional polish.

4. Demo-ing with real patient data. No real PHI in demo environments — ever. Synthetic data only. The Privacy Officer's confidence in the FDE is partially determined by whether the FDE demonstrates appropriate data handling discipline.

5. Understating the physician-in-the-loop requirement. Healthcare clients expect to hear that AI drafts require physician review. Downplaying this to seem more impressive about AI autonomy backfires with sophisticated clinical audiences.

Best Practices#

• Engage the Privacy Officer in the first two weeks of every healthcare engagement
• Identify the physician champion through the CMIO — peer introduction is more effective than FDE introduction
• Submit App Orchard application during POC design phase, not after POC success
• Use the clinical evaluation rubric to produce evidence the Model Review Board will accept
• Frame all clinical AI output as "draft requiring physician review" — do not imply autonomy
• Apply the non-device CDS vs. SaMD distinction correctly — engage regulatory counsel if uncertain
• Label all clinical demo content with "Synthetic Data — Educational Example" prominently

Interview Questions#

Q: You're starting a healthcare AI engagement at a Reference Healthcare Organization that wants to deploy prior authorization AI. Walk me through your first 30 days.#

Category: System Design Difficulty: Principal Role: Healthcare FDE

Answer Framework:

Days 1–5: Pre-discovery research. Identify the EHR vendor (Epic vs. Cerner vs. other), check LinkedIn for clinical informatics and IT job titles to understand team size, research the organization's payer mix (publicly available for Medicare-dependent organizations), check if they have prior coverage of AI from conference presentations or press. Understand their integration engine (Azure Health Data Services? MuleSoft? RHAPSODY?) — this determines the prior auth data path.

Days 6–10: Discovery kickoff. The goal is to map the current prior auth workflow from physician order to payer decision. Who submits? What system? Which payers are the highest volume and highest friction? What is the current denial rate (from RCM)? What is the appeal rate and cost? Also map the stakeholder landscape — Revenue Cycle VP, CMO, CIO, Privacy Officer, clinical informatics.

Days 11–15: Focused sessions. Privacy Officer — HIPAA compliance path, BAA status, PHI-in-cloud policy. IT Director — integration architecture, what APIs the payer portals expose (most do not have standardized APIs; some use HL7 X12 transactions), network path to payer systems. Revenue Cycle VP — current prior auth volume by service line, denial rates by payer.

Days 16–25: Assessment. Data maturity assessment: what structured data is available for prior auth criteria matching (diagnoses, lab results, prior treatment history)? Infrastructure: is the AI gateway deployed? Are payer APIs accessible from inside the network? Organization: is there a Revenue Cycle champion who will own the tool?

Days 26–30: POC Design document. Hypothesis: which service lines have the highest denial rate AND the most structured clinical data? That's the first POC scope. Success criteria: denial rate reduction measurable within the POC period (requires real submissions — not synthetic); staff time per submission. Gap analysis: most prior auth integration is not FHIR — it is payer-portal-specific, which means the integration is scraping or form automation. This must be surfaced in POC design.

Key Points to Hit:

• Pre-research: EHR vendor, integration engine, payer mix
• Discovery: workflow mapping, denial rate from RCM, stakeholder map
• Revenue Cycle VP and Privacy Officer as critical stakeholders
• Prior auth integration is often not FHIR — surfacing this early is critical
• POC scope scoped by service line, not "all prior auths"

Red Flags:

• Starting with a product demo
• Not engaging Revenue Cycle VP
• Assuming FHIR-based payer integration

Q: A CMIO asks: "If the AI makes a clinical error in the discharge summary and it harms a patient, who is liable?" How do you respond?#

Category: Architecture Difficulty: Principal Role: Healthcare FDE

Answer Framework:

This question must be answered honestly and specifically — not with a corporate deflection.

The legal framework for AI-assisted clinical documentation is still evolving, and the FDE should not provide legal advice. However, the design principle that governs liability is clear: the physician who reviews, edits, and signs the discharge summary attests to its accuracy and completeness. The physician's signature represents their professional judgment, not a rubber stamp of the AI's output.

From an architectural standpoint, the system is designed to reinforce this: the AI produces a draft that appears in a review interface, not in the medical record. The draft cannot enter the medical record without the physician's explicit approval action. There is no auto-filing. This is not just a UX decision — it is the architectural mechanism that preserves physician accountability.

The FDE should also be honest that the physician's review gate does not eliminate all liability risk — it assigns it to the physician as the responsible clinical professional. The question of whether the AI vendor bears any liability for outputs that pass physician review is a legal question that the FDE should direct to legal counsel.

Key Points to Hit:

• The physician's signature is the attestation of accuracy — that is the liability anchor
• Physician-in-the-loop is an architectural design, not just a guideline
• The FDE does not provide legal advice — direct to legal counsel for liability questions
• The physician's review gate is the primary safety and liability control

Red Flags:

• "The AI vendor is liable for errors in AI output" (legally incorrect and misleading)
• "Don't worry, our AI is very accurate" (dismisses the question)
• Providing a definitive legal opinion

Key Takeaways#

• Healthcare AI engagements require specialized knowledge across regulatory, clinical, and integration domains that cannot be improvised
• Nine stakeholders must be engaged: CMIO, CIO, Privacy Officer, IT Director, Physician Champion, CFO, CMO, and (for administrative AI) Revenue Cycle VP
• App Orchard review takes 8–14 weeks — submit in parallel with POC execution, not after
• The clinical evaluation rubric must be designed before evaluation begins and must include safety checks, not just quality thresholds
• All clinical AI output requires physician review before entering the medical record — this is a patient safety principle, not a feature limitation
• Healthcare objections on HIPAA, FDA, patient safety, and physician trust deserve substantive technical responses
• The physician champion is a required component of every clinical AI engagement — not optional

Further Reading#

• FDE Role and Responsibilities — Foundational FDE lifecycle
• Healthcare AI Landscape — FDA SaMD regulatory framework
• HIPAA and AI — PHI handling, BAA requirements
• EHR Integration — FHIR R4, SMART on FHIR, CDS Hooks technical patterns
• HMS Reference Architecture — Production architecture target for healthcare FDE engagements
• AI Safety in Clinical Settings — Clinical AI safety evaluation patterns