Client Communication#

Executive Summary#

Client communication is the highest-leverage non-technical skill an FDE possesses — and the most frequently underinvested. An FDE who can explain a complex AI integration risk to a CFO in two sentences, write a status report that a CIO reads in three minutes and fully understands, and escalate a blocking issue in a way that produces a decision rather than a meeting has a compounding advantage in every client engagement. This chapter provides the frameworks, templates, and principles for FDE communication across four contexts: executive briefings, technical status reports, escalation communications, and risk communications. The emphasis throughout is on precision and audience calibration — the right level of technical detail for the person receiving the communication, at the moment they need it.

Learning Objectives#

• Structure executive communications that deliver a complete message in under three minutes
• Write technical status reports that serve both technical and executive audiences without duplication
• Escalate issues in a way that produces decisions rather than additional meetings
• Calibrate technical depth to the audience's role and decision-making need
• Communicate AI risk to non-technical stakeholders without either minimizing or catastrophizing

Business Problem#

FDE communication failures are costly and common. Technical FDEs who write status reports that are too detailed lose their executive audience. FDEs who write reports that are too thin lose their technical audience's trust. FDEs who escalate issues through informal channels — Slack messages, verbal mentions — find that issues do not get resolved because no one is formally accountable. FDEs who communicate AI risk using jargon ("the embedding similarity score has drifted") create confusion rather than informed decision-making.

The consequence is not just a communication problem — it is a delivery problem. Status that is not communicated clearly is invisible. Risk that is not communicated in decision-relevant terms does not get mitigated. Issues that are not escalated in writing do not get resolved.

Why Communication Structure Matters#

The FDE communicates with stakeholders who have fundamentally different information needs and reading habits:

No single communication format serves all of these audiences. The FDE must maintain separate communication channels calibrated to each audience — or produce structured documents that different audiences can consume at different depths.

Conceptual Explanation#

Effective client communication follows three principles:

Bottom Line Up Front (BLUF): The most important information goes in the first sentence — not after the context. Executives who read only the first sentence must still understand the essential message.

Audience calibration: Technical depth is determined by the audience's decision-making need, not by the FDE's desire to demonstrate competence. A CFO making a budget decision needs dollar figures and risk levels. An IT director making an architecture decision needs technical specifics. Neither needs what the other needs.

Action orientation: Every communication should end with a clear action — a decision requested, an information delivery confirmed, or a next step assigned to a named owner. Communication that ends with "please let us know if you have questions" produces no action.

Core Architecture: Communication Frameworks#

Framework 1 — Executive Briefing (One-Pager)#

The one-pager is the primary vehicle for communicating with executive stakeholders. It must be readable in 3–5 minutes and contain everything the executive needs to make a decision or understand a situation.

# [Subject] — Executive Briefing
**Date:** [Date]
**Prepared by:** [FDE Name]
**For:** [Executive Name, Title]
**Action Required:** [Yes — Approve / Inform — No action needed]

## Bottom Line

[1–2 sentences: What do you need to know, decide, or do? 
 Write this as if it is the only sentence the executive reads.]

## Situation

[3–5 sentences: What is happening? What is the current state?
 Be specific — avoid vague terms like "progressing well" or "on track."]

## Risk / Issue (if applicable)

[Describe the risk or issue in business terms.
 Consequence if not addressed.
 Likelihood.
 What is needed to resolve it.]

## Options / Recommendation

| Option | Pros | Cons | Recommendation |
|--------|------|------|----------------|
| [A] | | | |
| [B] | | | |

## Action Required

[Specific: "Approve [X] by [Date]" or "Inform: No action needed"]

## Supporting Detail

[Optional: Link to full technical document for those who want more depth]

Example — Executive briefing for a blocking issue:

# BAA Signature Required — AI Deployment Blocked
**Date:** 2026-06-30
**For:** Chief Compliance Officer
**Action Required:** YES — Signature by [Date + 5 days]

## Bottom Line

The Anthropic Business Associate Agreement requires the Chief Compliance Officer's
signature to proceed. Without it, the discharge summary AI cannot process patient
data. The POC launch scheduled for [Date + 10 days] will be delayed.

## Situation

The AI platform requires a signed BAA with Anthropic (the AI provider) before
patient data can be transmitted for processing. This is a HIPAA requirement —
not optional. The BAA has been reviewed by legal counsel and marked ready for
signature as of [Date - 3 days].

## Risk

If the BAA is not signed by [Date + 5 days], the POC launch date moves to [Date + 25 days].
This delays the physician evaluation period and the production decision by 15 calendar days.

## Action Required

Sign the Anthropic BAA via [DocuSign link / physical document]. 
Please confirm completion to [FDE contact] by [Date + 5 days].

Framework 2 — Technical Status Report#

Status reports serve two audiences with different needs. The recommended structure uses a header section for executives and a detail section for technical stakeholders — one document, two depths.

# Discharge Summary AI — Status Report
**Report Period:** [Start Date] – [End Date]
**Author:** [FDE Name]
**Distribution:** [CMIO, IT Director, Clinical Informatics Lead]

---

## EXECUTIVE SECTION (3-minute read)

### Overall Status: 🟡 ON TRACK WITH ATTENTION ITEMS

| Dimension | Status | Notes |
|-----------|--------|-------|
| Timeline | 🟢 On Track | POC execution on schedule for [Date] completion |
| Quality | 🟡 Monitoring | Edit rate 28% — within target but monitoring closely |
| Blocking Issues | 🟡 One item | BAA signature pending — see Action Items |
| Technical | 🟢 On Track | Integration complete; evaluation in progress |

### This Week
- Completed FHIR integration; retrieving patient data from Epic sandbox
- Generated 20 of 50 required encounter drafts for physician evaluation
- Hospitalist evaluation sessions scheduled for next week

### Next Week
- Complete remaining 30 encounter draft generations
- Begin physician evaluation (2 hospitalists, 25 encounters each)
- Resolve BAA signature blocker

### Action Items

| # | Action | Owner | Due | Status |
|---|--------|-------|-----|--------|
| 1 | Sign Anthropic BAA | Compliance Officer | [Date] | BLOCKING — escalated |
| 2 | Schedule physician evaluation kickoff | Clinical Informatics | [Date] | In progress |

---

## TECHNICAL SECTION (for IT Director / Clinical Informatics Lead)

### Integration Status

**FHIR Data Retrieval:** Complete
- Patient resource: ✅ Available (100% of test encounters)
- Condition resource: ✅ Available (96% of test encounters, 4% missing ICD-10 codes — using text description)
- MedicationRequest: ✅ Available (89% of encounters — acceptable threshold)
- Observation (vitals + labs): ✅ Available (94% of encounters)

**AI Gateway:** Deployed in Azure test environment
- Endpoint: [internal URL]
- Model version: claude-sonnet-4-6 (pinned)
- Audit logging: Enabled; logs to [log destination]
- No raw PHI in logs: ✅ Confirmed via log inspection

### Quality Metrics (Week 3 data — 20 encounters generated)

| Metric | Target | Current | Trend |
|--------|--------|---------|-------|
| Physician edit rate | < 30% | 28% | Stable |
| Section completeness | > 95% | 97% | Stable |
| Generation latency (p95) | < 30s | 22s | Stable |
| Medication accuracy | > 90% | 91% | Monitoring |

### Technical Issues

**Issue:** 4 of 20 encounters had missing ICD-10 codes in Condition resource
**Root Cause:** These encounters were documented before the ICD-10 mandate; codes exist only as free text
**Impact:** Minor — AI uses diagnosis text; clinical output not meaningfully affected
**Resolution:** Added free-text fallback to FHIR context builder

### Architecture Changes

None this week. Architecture is stable as reviewed on [Date].

Framework 3 — Escalation Communication#

Escalation communications must produce a decision. They are not status updates — they describe a situation that requires action above the FDE's authority level.

# [ESCALATION] [Issue Name] — Decision Required by [Date]
**To:** [Decision-maker name and title]
**From:** [FDE name]
**CC:** [Account lead, Client engagement manager]
**Priority:** [High / Critical]

## Situation

[What has happened? Be specific. Dates, numbers, facts.]

## Impact if Not Resolved by [Date]

[Quantify the impact. "The POC will be delayed by 15 days" is better than 
 "Progress will be affected."]

## Root Cause

[Why did this situation occur? One sentence.]

## Decision Required

[Exactly what decision needs to be made, by whom, by when.]

## Options

1. **Option A:** [Description] — enables [outcome A] by [date]
2. **Option B:** [Description] — enables [outcome B] by [date]

**Recommendation:** Option [X] because [one-sentence rationale]

## Background

[Optional: 2–3 sentences of additional context for those who need it]

Principles for effective escalations:

• Never escalate without a recommendation. "We have a problem, what should we do?" is not an escalation — it is a complaint.
• Quantify the impact. Escalations that describe impact vaguely ("this could slow us down") do not produce urgency. Escalations that specify impact precisely ("this delays the POC launch by 15 days, moving the production decision from Q3 to Q4") produce urgency.
• Identify the decision-maker precisely. An escalation sent to a distribution list is not escalated to anyone.
• Give a decision deadline. "By [Date]" makes the timeline concrete.

Framework 4 — AI Risk Communication#

Communicating AI risk to non-technical stakeholders requires translation from technical to consequence language:

def communicate_ai_risk(
    risk_name: str,
    technical_description: str,
    clinical_consequence: str,
    affected_patients_per_day: float,
    current_status: str,     # "Active" | "Monitoring" | "Mitigated"
    mitigation: str,
    decision_required: bool,
) -> str:
    """
    Format an AI risk for non-technical clinical leadership communication.
    Educational example.
    """
    status_indicator = {
        "Active": "⚠️ Active — Action Required",
        "Monitoring": "🔍 Monitoring — No Immediate Action",
        "Mitigated": "✅ Mitigated — No Action Required"
    }[current_status]
    
    report = f"""
## AI Risk: {risk_name}
**Status:** {status_indicator}

**What is happening:**
{clinical_consequence}

**Scope:**
Estimated to affect approximately {affected_patients_per_day:.0f} patient encounters per day
during current usage levels.

**How we're addressing it:**
{mitigation}
"""
    
    if decision_required:
        report += "\n**Decision Required:** See escalation communication."
    
    return report.strip()

Architecture Diagram#

Implementation Patterns#

Communication Calendar#

For an active FDE engagement, maintain a regular communication cadence:

COMMUNICATION_CALENDAR = {
    "weekly": [
        {
            "document": "Technical Status Report",
            "audience": "IT Director, Clinical Informatics Lead",
            "day": "Friday",
            "timing": "End of business",
            "length": "1–2 pages"
        }
    ],
    "biweekly": [
        {
            "document": "Executive Summary",
            "audience": "CMIO, CIO",
            "day": "Wednesday (alternating)",
            "timing": "Morning — for review before afternoon executive meetings",
            "length": "Half page"
        }
    ],
    "monthly": [
        {
            "document": "Value Realization Report",
            "audience": "CMIO, CFO (if production)",
            "day": "First business day of month",
            "timing": "For inclusion in monthly leadership reviews",
            "length": "1 page + KPI dashboard"
        }
    ],
    "as_needed": [
        {
            "document": "Escalation Communication",
            "audience": "Relevant decision-maker",
            "timing": "Within 24 hours of issue identification",
            "SLA": "Response required within 48 hours of delivery"
        },
        {
            "document": "Architecture Decision Record",
            "audience": "IT Director, Clinical Informatics",
            "timing": "Within 48 hours of a significant architectural decision"
        }
    ]
}

Healthcare Considerations#

Healthcare executives have specific communication sensitivities:

Patient safety language: Any communication that touches patient safety must be precise. "The AI could hurt patients" is catastrophizing. "Without the physician review gate, AI-generated medication information could reach the medical record unchecked" is accurate and actionable.

Regulatory language precision: HIPAA, CMS, and FDA communications require precise regulatory language. "This is a HIPAA violation" and "This creates HIPAA risk" have very different implications. Use the correct framing.

Clinical authority: Do not use clinical language to make clinical judgments. "The AI's medication recommendations are accurate" is a clinical claim that requires physician review. "The AI's medication recommendations matched the pharmacy-verified discharge list in 91% of test encounters" is a measurement.

CMIO vs. CIO: These two stakeholders have different primary concerns. The CMIO cares about clinical quality, physician adoption, and patient safety. The CIO cares about integration architecture, security, and operational reliability. Status reports that conflate these concerns serve neither audience well.

Common Mistakes#

1. Burying the key message. Opening with three paragraphs of context before stating the main point means executives stop reading before reaching the main point. Lead with the conclusion.

2. Using technical jargon with executive audiences. "The vector similarity score is below threshold" means nothing to a CMO. "The AI's knowledge base may contain outdated clinical guidelines" means something they can act on.

3. Escalating without a recommendation. Escalations that present a problem without a recommendation force the executive to solve a problem they don't have context for. Always include a specific recommendation.

4. Status reports with no status. "We are making good progress on the integration" is not a status. "FHIR data retrieval complete; AI gateway deployed; beginning physician evaluation on [Date]" is a status.

5. Not establishing communication expectations at engagement start. Cadence, format, and audience expectations should be agreed in the first week. Improvised communication at the end of an engagement is less effective than a disciplined cadence established from the start.

6. Communicating AI risk with false precision. "The AI has a 3.7% hallucination rate" implies a precision that evaluation datasets do not support. "In our evaluation, the AI produced clinically inaccurate content in approximately 4 of 50 encounters — all identified and corrected during physician review" is more honest and more actionable.

Best Practices#

• Establish communication cadence, format, and audience in the first week
• Lead with the bottom line — always
• Write separate executive and technical sections in status reports — not a single document that tries to serve both
• Escalations must include a specific recommendation and decision deadline
• AI risk communications use consequence language, not technical language
• Never quantify AI risk with false precision — use ranges or approximate counts
• Produce all escalation communications in writing — verbal escalations are not escalations

Trade-offs#

Detail vs. readability: More detail increases completeness but reduces the probability that the document is fully read. The right level of detail is determined by the audience's decision-making need, not by the FDE's desire to demonstrate thoroughness.

Frequency vs. quality: Weekly status reports that are comprehensive take 2+ hours to produce. The FDE must balance communication investment against execution time. Template-based reports that take 30 minutes to complete are more sustainable than reports that take 3 hours.

Interview Questions#

Q: A critical blocking issue has emerged in a healthcare AI engagement that requires the client's Chief Compliance Officer to make a decision within 48 hours. How do you communicate this?#

Category: Behavioral Difficulty: Senior Role: FDE

Answer Framework:

The escalation communication follows the BLUF structure: situation, impact, decision required, options, recommendation — in that order, in writing, within 24 hours of the issue emerging.

The message to the CCO is a one-page escalation document, not an email thread. It opens with the bottom line: "A HIPAA Business Associate Agreement must be signed to proceed with the POC, and the [Date] launch date is at risk if it is not signed by [Date + 2 days]." The body quantifies the impact precisely — 15 days delay, Q3 vs. Q4 production decision, and any downstream consequences for budget cycles or contract milestones. It presents two options (sign by [Date + 2], or reschedule launch to [Date + 17]) with a clear recommendation. It ends with a specific request: "Please confirm your decision by [Date + 1 day] so we can adjust the POC schedule."

In parallel, I notify the FDE's internal account lead so they are not surprised if the CCO escalates internally.

Key Points to Hit:

• Written escalation, not a verbal mention or Slack message
• BLUF structure: bottom line first
• Quantified impact, not vague language
• Specific recommendation
• Concrete decision deadline
• Internal notification to account lead in parallel

Red Flags:

• Verbal escalation only
• Escalation without a recommendation
• Vague impact description ("this could slow us down")

Key Takeaways#

• Bottom Line Up Front: the most important message goes in the first sentence
• Four communication formats: executive one-pager, technical status report, escalation, risk communication
• Calibrate technical depth to the audience's decision-making need — not to demonstrate competence
• Escalations must include a recommendation, quantified impact, and decision deadline
• AI risk communications use consequence language, not technical jargon
• Establish communication cadence, format, and audience in the first engagement week
• Written escalations produce decisions; verbal escalations produce meetings

Glossary#

BLUF (Bottom Line Up Front): A military communication principle: state the conclusion first, then supporting information. Prevents key messages from being missed by readers who stop reading early.

Architecture Decision Record (ADR): A document that records a significant architectural decision, its context, the options considered, and the rationale for the choice made.

Value Realization Report: A monthly post-deployment report that compares actual KPI performance against the pre-deployment value model projection.

Further Reading#

• Value Engineering — Financial frameworks for executive communications
• Common Objections — Communication patterns for objection handling
• Healthcare Client Playbook — Healthcare-specific communication patterns for CMIO and compliance audiences