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.

Why a Healthcare-Specific Playbook#

Healthcare FDE work has a body of specialized knowledge that accumulates through repeated engagement:

• Which Epic modules are required for FHIR access (and which Epic versions support FHIR R4)
• How long App Orchard reviews typically take and how to support the submission
• What questions the Privacy Officer will ask and what documentation they need
• Which clinical use cases produce physician champion enthusiasm vs. resistance
• How to frame value engineering for a CMO vs. a CFO vs. a CMIO
• How to discuss FDA regulatory classification without creating unnecessary alarm
• How to design a clinical AI evaluation that produces evidence a Model Review Board will accept

This chapter captures that accumulated knowledge in a retrievable form.

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#

from dataclasses import dataclass, field
from enum import Enum

class StakeholderPriority(Enum):
    CRITICAL = "critical"     # Must be engaged — their absence blocks progress
    IMPORTANT = "important"   # Should be engaged — their absence creates risk
    INFORM = "inform"         # Keep informed — do not need to lead decisions

@dataclass
class HealthcareStakeholder:
    role: str
    department: str
    priority: StakeholderPriority
    primary_concern: str
    what_they_need_from_fde: str
    phases: list[str]              # Which engagement phases they are active in
    engagement_approach: str

HEALTHCARE_STAKEHOLDER_MAP = [
    HealthcareStakeholder(
        role="CMIO (Chief Medical Information Officer)",
        department="Clinical Informatics",
        priority=StakeholderPriority.CRITICAL,
        primary_concern="Clinical quality, physician adoption, patient safety",
        what_they_need_from_fde=(
            "Clinical evidence of output quality; physician champion identification; "
            "clear FDA regulatory assessment; governance pathway"
        ),
        phases=["Discovery", "Assessment", "POC Design", "POC Execution", "Architecture Review", "Launch"],
        engagement_approach="Technical peer + clinical quality partner; they speak the clinical and technical language"
    ),
    HealthcareStakeholder(
        role="CIO (Chief Information Officer)",
        department="IT",
        priority=StakeholderPriority.CRITICAL,
        primary_concern="Integration architecture, security, IT resource burden, vendor management",
        what_they_need_from_fde=(
            "Architecture review; Epic integration design; security documentation; "
            "total cost of ownership; IT resource requirements"
        ),
        phases=["Discovery", "Assessment", "Architecture Review", "Production Planning"],
        engagement_approach="Technical peer; focus on architecture, not AI capability"
    ),
    HealthcareStakeholder(
        role="Privacy Officer / Compliance",
        department="Compliance / Legal",
        priority=StakeholderPriority.CRITICAL,
        primary_concern="HIPAA compliance, PHI handling, BAA coverage, audit logging",
        what_they_need_from_fde=(
            "BAA; PHI data flow diagram; audit log specification; data residency confirmation; "
            "security attestations (SOC 2, HIPAA attestation); data processing addendum"
        ),
        phases=["Discovery", "Assessment", "Architecture Review", "Production Planning"],
        engagement_approach="Compliance partner; provide documentation proactively; answer questions with specifics not generalities"
    ),
    HealthcareStakeholder(
        role="IT Director, Clinical Systems",
        department="IT",
        priority=StakeholderPriority.IMPORTANT,
        primary_concern="Epic integration complexity, IT resource allocation, integration timeline",
        what_they_need_from_fde=(
            "FHIR integration specification; App Orchard submission support; "
            "integration architecture detail; timeline realism"
        ),
        phases=["Assessment", "POC Execution", "Architecture Review", "Production Planning"],
        engagement_approach="Engineering partner; speak concretely about integration patterns; acknowledge complexity"
    ),
    HealthcareStakeholder(
        role="Physician Champion",
        department="Clinical (usually hospitalists, specialists, or informaticists)",
        priority=StakeholderPriority.CRITICAL,
        primary_concern="Clinical workflow impact; time savings; liability for AI output; peer perception",
        what_they_need_from_fde=(
            "Hands-on time with the tool; evidence of clinical accuracy; "
            "clear explanation of the physician-in-the-loop design; peer champion network"
        ),
        phases=["POC Design", "POC Execution", "Launch", "Expansion"],
        engagement_approach="Peer-to-peer (via CMIO introduction); let them drive the evaluation; capture their feedback verbatim"
    ),
    HealthcareStakeholder(
        role="CFO",
        department="Finance",
        priority=StakeholderPriority.IMPORTANT,
        primary_concern="ROI, payback period, total cost, budget alignment",
        what_they_need_from_fde=(
            "One-page financial model; conservative assumptions; payback period; "
            "what happens if adoption is lower than projected"
        ),
        phases=["Assessment", "Production Planning"],
        engagement_approach="Financial language only; no technical details; use illustrative figures with explicit caveats"
    ),
    HealthcareStakeholder(
        role="CMO (Chief Medical Officer)",
        department="Clinical Administration",
        priority=StakeholderPriority.IMPORTANT,
        primary_concern="Physician satisfaction, clinical quality, patient safety, malpractice risk",
        what_they_need_from_fde=(
            "Evidence that physician workload is reduced; evidence that patient safety is maintained; "
            "physician champion endorsement"
        ),
        phases=["POC Execution", "Production Planning", "Launch"],
        engagement_approach="Clinical outcomes language; physician satisfaction data; safety first framing"
    ),
]

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:

HEALTHCARE_DATA_QUALITY_INDICATORS = {
    "condition_documentation_quality": {
        "good": "ICD-10 codes present with descriptions; structured problem list",
        "acceptable": "Mixed ICD-10 and text descriptions; problem list supplemented by note parsing",
        "poor": "Free text only; no structured problem list; codes only without descriptions",
        "check": "Count Condition resources with both code AND text in sample encounters"
    },
    "medication_reconciliation_quality": {
        "good": "All active medications with dose, route, frequency, and indication",
        "acceptable": "Active medications with dose and route; indication incomplete",
        "poor": "Medication list without reconciliation status; PRN meds mixed with scheduled",
        "check": "Count MedicationRequest resources with status = 'active' in sample encounters"
    },
    "flowsheet_completeness": {
        "good": "Vital signs charted every 4–8 hours; trends available",
        "acceptable": "Vital signs charted at admission and nursing shift assessments",
        "poor": "Sparse vital signs; only admission vitals available",
        "check": "Count Observation resources with category=vital-signs per 24 hours in sample"
    }
}

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.

@dataclass
class ClinicalAIPOCEvaluationRubric:
    """
    Standard evaluation rubric for clinical AI POC.
    Must be reviewed and approved by the CMIO or clinical champion
    before evaluation begins.
    
    Educational Example — Not intended as a clinical evaluation standard.
    Adapt to specific use case and institutional requirements.
    """
    
    # Primary clinical quality metric
    primary_metric: str = "Physician edit rate"
    primary_definition: str = (
        "Proportion of AI-generated sections that require substantive edit "
        "(defined as: addition, deletion, or change of clinical fact) before "
        "physician would accept the section"
    )
    primary_threshold: float = 0.30  # < 30%
    
    # Secondary metrics
    secondary_metrics: list[dict] = None
    
    # Safety-critical checks (these are pass/fail, not thresholds)
    safety_checks: list[dict] = None
    
    # Evaluation logistics
    minimum_encounters: int = 50
    minimum_evaluators: int = 2  # At least two physicians for inter-rater reliability
    encounter_selection: str = "Random selection from previous 90 days, stratified by primary diagnosis"
    
    def __post_init__(self):
        if self.secondary_metrics is None:
            self.secondary_metrics = [
                {
                    "metric": "Section completeness",
                    "definition": "All required sections per HMS template present in draft",
                    "threshold": 0.95
                },
                {
                    "metric": "Medication accuracy",
                    "definition": "Discharge medications in AI draft match pharmacy-verified list",
                    "threshold": 0.90
                },
                {
                    "metric": "Factual accuracy",
                    "definition": "No clinical facts in AI draft that contradict the EHR source data",
                    "threshold": 1.0  # Zero tolerance for contradictory facts
                }
            ]
        
        if self.safety_checks is None:
            self.safety_checks = [
                {
                    "check": "No medication not in the patient's record appears in the draft",
                    "consequence_if_failed": "STOP — patient safety risk; do not proceed to production"
                },
                {
                    "check": "No diagnosis not documented in the patient's record appears in the draft",
                    "consequence_if_failed": "STOP — clinical accuracy risk; prompt redesign required"
                },
                {
                    "check": "Allergy information in draft matches allergy record",
                    "consequence_if_failed": "STOP — patient safety risk; immediately investigate"
                }
            ]

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:

HEALTHCARE_VALUE_DRIVERS = {
    "discharge_summary_ai": {
        "primary_benefit": "Physician documentation time reduction",
        "time_saved_minutes": "15–25 min per discharge (illustrative — measure client baseline)",
        "annual_volume": "Annual inpatient discharges",
        "value_calculation": "Time saved × encounters × physician hourly rate",
        "secondary_benefits": [
            "Discharge summary completeness → reduced documentation deficiency citations",
            "Faster discharge process → improved bed turnover",
            "Physician satisfaction → retention"
        ],
        "kpi_baseline_measurement": "EHR audit log analysis — note open to note signed timestamp",
        "data_required": "Annual discharge count; current documentation time (time-motion study)"
    },
    "prior_auth_ai": {
        "primary_benefit": "Denial rate reduction + staff time savings",
        "denial_rate_reduction": "2–4 percentage points (illustrative)",
        "staff_time_per_auth": "15–30 min currently; 5–10 min with AI assist",
        "value_calculation": "Denial reduction × average claim value × capture rate + staff time savings",
        "secondary_benefits": [
            "Faster authorization → reduced care delays",
            "Staff satisfaction → retention"
        ],
        "kpi_baseline_measurement": "RCM system denial rate by payer; staff time-motion study"
    },
    "medical_coding_ai": {
        "primary_benefit": "Coding accuracy improvement + coder time savings",
        "accuracy_improvement": "1–3% CC/MCC capture improvement (illustrative)",
        "value_calculation": "CC/MCC capture improvement × average DRG weight difference × payer mix",
        "secondary_benefits": [
            "Query reduction — coders spend less time clarifying with physicians",
            "Audit readiness improvement"
        ],
        "kpi_baseline_measurement": "Current CC/MCC capture rate; query rate; coding time per encounter"
    },
    "patient_engagement_ai": {
        "primary_benefit": "30-day readmission reduction",
        "readmission_reduction": "0.3–0.7 percentage points (highly variable — measure carefully)",
        "value_calculation": "Readmission reduction × encounters × avoided readmission cost",
        "caveat": (
            "Readmission reduction attribution is complex. "
            "Recommend a controlled study design before claiming causal attribution. "
            "All figures are illustrative — verify with current clinical literature."
        ),
        "kpi_baseline_measurement": "Current 30-day readmission rate by DRG; current follow-up call rate"
    }
}

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#

Implementation Patterns#

Healthcare Engagement Startup Checklist#

For any new healthcare client engagement, verify the following in the first two weeks:

HEALTHCARE_ENGAGEMENT_STARTUP = {
    "stakeholders": [
        "CMIO identified and engaged as executive sponsor",
        "CIO briefed on initiative",
        "Privacy Officer / Compliance included in discovery scope",
        "Physician champion identified (via CMIO) — introductory session scheduled",
        "IT Director, Clinical Systems engaged for integration planning",
    ],
    "regulatory": [
        "FDA use case classification completed (non-device CDS or SaMD?)",
        "HIPAA PHI data flow mapped at high level",
        "BAA requirement identified; Anthropic BAA process initiated",
        "ONC information blocking rules assessed if relevant to use case",
    ],
    "technical": [
        "Epic version confirmed; FHIR R4 availability confirmed",
        "App Orchard process timeline understood",
        "PHI-in-cloud policy confirmed with Compliance",
        "FHIR sandbox access timeline understood",
        "Integration engine type confirmed (Azure Health Data Services, MuleSoft, RHAPSODY, etc.)",
    ],
    "value": [
        "Primary pain point quantified (time-motion, RCM data, or EHR audit log)",
        "Annual volume for use case confirmed (discharges, prior auths, encounters)",
        "Financial decision-maker identified (CFO or CMO depending on use case)",
    ]
}

Epic App Orchard Timeline Planning#

App Orchard is consistently the longest lead-time item in Epic-based healthcare AI deployments. FDEs who do not surface this in week 1 create a production delay that is entirely foreseeable.

APP_ORCHARD_TIMELINE_GUIDE = {
    "submission_to_first_review": "2–4 weeks",
    "first_review_to_conditional_approval": "4–6 weeks (if documentation is complete)",
    "conditional_approval_to_full_approval": "2–4 weeks (security questionnaire, pen test review)",
    "total_typical_range": "8–14 weeks from submission to production access",
    "acceleration_factors": [
        "Complete documentation package submitted at first submission",
        "HIPAA attestation and SOC 2 report available",
        "Client IT team responsive to Epic questions",
        "FHIR scopes are minimal (patient/* not system/*)"
    ],
    "delay_factors": [
        "Incomplete documentation requiring resubmission",
        "Broad FHIR scopes (system-level) requiring additional justification",
        "Security questionnaire questions not answered promptly",
        "New client IT contact mid-review"
    ],
    "fde_action": (
        "Submit App Orchard application in parallel with POC execution — not after POC success. "
        "Provide complete documentation package to reduce resubmission cycles. "
        "Factor 10–12 weeks into production planning timeline."
    )
}

Healthcare Considerations#

The entire chapter is healthcare context. The most important principles to carry:

1. Never skip the Compliance stakeholder. The Privacy Officer or Compliance Officer has veto authority over any PHI-involving system. Engaging them late in the process is the most common cause of near-production blockers.

1. The physician champion is not optional for clinical AI adoption. An AI tool that physicians don't trust will not be used, regardless of technical quality. The champion is the trust transfer mechanism.

1. App Orchard is the longest lead-time item. Submit in parallel with POC execution. 10–12 weeks is the realistic planning figure.

1. Clinical safety objections deserve serious engagement. A physician who asks "what if it gives the wrong medication?" is not being obstructive — they are asking the most important question. Engage with the safeguard design specifically, not with general accuracy claims.

1. All clinical AI output requires physician review before entering the medical record. This is not a technical constraint — it is a patient safety and liability principle. It must be present in every clinical AI design.

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

Glossary#

CMIO (Chief Medical Information Officer): The physician executive responsible for clinical informatics, EHR governance, and clinical technology strategy. Primary sponsor for clinical AI deployments.

App Orchard: Epic's third-party application marketplace and security review program. Required for SMART on FHIR applications accessing production Epic environments.

DRG (Diagnosis-Related Group): The CMS payment classification system for inpatient hospitalizations. CC/MCC (Complication/Comorbidity and Major CC) modifiers affect DRG weight and reimbursement.

CC/MCC Capture Rate: The proportion of inpatient encounters for which complications or comorbidities are captured in the coded diagnosis, affecting DRG weight and reimbursement.

HL7 X12: The ANSI-standard electronic transaction format used for prior authorization and claims (EDI 278, 835, 837). Distinct from HL7 FHIR — most payer prior auth portals use X12 or proprietary web portals, not FHIR.

Model Review Board (MRB): A governance body that reviews and approves clinical AI deployments. Required for Tier 1 and Tier 2 use cases per the HMS AI Platform governance framework.

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