Client Discovery Framework#

Executive Summary#

Client discovery is the most consequential phase of an FDE engagement — it is where the FDE builds the situational understanding that determines whether every subsequent decision is well-grounded or speculative. A structured discovery framework produces three outputs that cannot be obtained any other way: an accurate current-state architecture map, a prioritized pain point inventory, and a stakeholder influence model. This chapter defines a repeatable discovery process that works across enterprise AI engagements, with specific adaptations for healthcare clients where regulatory, clinical, and organizational complexity is higher than in other verticals. Principal AI Architects who conduct client discovery or oversee FDE teams must understand this framework to avoid the single most common FDE failure mode: beginning POC execution before the discovery phase is complete.

Learning Objectives#

• Execute a structured discovery process from pre-research through Discovery Summary delivery
• Build and maintain a stakeholder influence model that reflects real decision-making dynamics
• Design discovery questions that elicit architectural information without leading the client
• Recognize the signals that indicate discovery is insufficient before moving to Assessment
• Adapt the standard discovery framework for healthcare clients with regulatory and clinical complexity

Business Problem#

Enterprise AI engagements that begin without structured discovery consistently produce the same failure modes:

• POC scope that does not match the client's actual data environment (wrong FHIR version, missing resources, access control gaps)
• Technical architecture that conflicts with the client's security posture (discovered in week 6 of POC execution, not week 1)
• Use case prioritization that optimizes for what the product does well, not what the client most needs
• Stakeholder surprises — a new compliance officer blocks production approval because they were not included in discovery

Discovery is not a sales activity. It is an engineering activity. Its outputs directly determine whether the POC will be technically sound, whether the production architecture will survive security review, and whether the organizational conditions for adoption exist.

Why This Framework Exists#

Enterprise AI deployments involve a category of technical complexity that is invisible from outside the client organization: the integration surface between the AI system and the client's existing data infrastructure. This surface includes:

• Data quality issues that only appear when the AI system tries to use the data
• Authentication and authorization constraints that differ per system and per use case
• Network topology that determines whether AI calls can even reach external APIs
• Organizational governance that determines who can approve data access, security exceptions, and workflow changes

No amount of product documentation or vendor specification sheets can map this surface. It requires direct, structured engagement with the people and systems involved. The discovery framework is the process for mapping it systematically.

Conceptual Explanation#

Discovery has three layers, each building on the previous:

Layer 1 — Technical environment: What systems exist, how they connect, what data is available, what integration standards are in use. This is the engineering map of the client's current state.

Layer 2 — Pain points and use cases: Where the current state creates friction, what the client has already tried, which problems are important enough to fund a solution, and which AI use cases map to those problems.

Layer 3 — Organizational dynamics: Who makes decisions, who influences them, who has veto power, and what political dynamics will affect the engagement. This is the organizational map that determines whether technically correct decisions can be implemented.

All three layers must be populated before discovery is complete. An FDE who has a detailed technical map but has not talked to the compliance officer is not ready to move to Assessment.

Core Architecture: The Discovery Framework#

Phase 0 — Pre-Discovery Research (1–2 days, FDE working independently)#

Before the first client meeting, the FDE must invest time in independent research. Arriving uninformed wastes the client's time and signals a lack of preparation.

Research checklist:

# Pre-discovery research framework
# Complete before the first client meeting

class PreDiscoveryResearch:
    """
    Structured research template for FDE pre-discovery.
    Complete as much as possible from public sources before engaging the client.
    """
    
    # Technical environment signals
    ehr_vendor: str           # Search LinkedIn jobs, conference presentations, public RFPs
    cloud_provider: str       # Azure/AWS/GCP signals from job postings, press releases
    it_security_posture: str  # SOC 2? HITRUST? Joint Commission accreditation?
    integration_standards: list[str]  # FHIR version, HL7 v2, API standards
    
    # Organizational signals
    org_size: str             # Bed count, revenue, employee count
    annual_encounter_volume: int  # Inpatient discharges, outpatient visits
    it_org_size: str          # LinkedIn search for IT/informatics staff
    ai_experience: str        # Prior AI vendor relationships, conference talks, press
    
    # Pain point signals
    known_regulatory_pressures: list[str]  # CMS requirements, Joint Commission findings
    financial_pressures: str  # Recent earnings calls, news articles (public companies)
    operational_pressures: str  # Readmission penalties, documentation burden, coding backlogs
    
    # Competitive signals
    existing_vendors: list[str]  # Current HIT vendors, known AI experiments
    rfp_history: str           # Prior AI RFPs (often public for government entities)

Public sources to check:

• LinkedIn — org structure, job titles, open positions (signals what skills they are building)
• Healthcare: state licensing databases, Joint Commission public reports, CMS star ratings
• Press releases and local news — recent technology announcements
• Conference presentations (HIMSS, HL7, Epic UGM) — published implementations
• GitHub — open-source contributions by their engineering staff

Phase 1 — Discovery Kickoff Session (90–120 minutes)#

The discovery kickoff is a structured conversation, not a product presentation. The FDE facilitates; the client talks. The ratio should be approximately 30:70 (FDE speaking : client speaking).

Session structure:

SEGMENT 1 — Current State Architecture Walk (30 min)
"Walk me through what happens from [trigger event] to [outcome] in your current process."

Capture:
- Systems involved (names, versions, vendors)
- Data flows between systems
- Manual steps and handoffs
- Integration standards (FHIR R4? HL7 v2 ADT? API? SFTP?)
- Who touches the process and when

SEGMENT 2 — Pain Point Inventory (25 min)
"Where does this process break down? What takes the longest? What do people complain about?"

Capture:
- Specific failure modes with frequency
- Time estimates per step
- Downstream consequences of failures
- What has already been tried

SEGMENT 3 — Prior AI Experience (15 min)
"Have you evaluated AI tools in this area before? What happened?"

Capture:
- Prior AI experiments and their outcomes
- Vendors evaluated
- Why prior attempts failed or succeeded
- Current vendor relationships in the AI space

SEGMENT 4 — Data Availability and Access (15 min)
"Who controls access to [EHR FHIR APIs / data warehouse / document store]?
 What is the process for getting a new application connected?"

Capture:
- FHIR API access process (App Orchard, SMART on FHIR registration)
- Data governance and approval process
- Timeline expectations for access provisioning
- Known access restrictions (PHI in cloud, off-premises restrictions)

SEGMENT 5 — Stakeholder Map Draft (10 min)
"Who else needs to be involved in this evaluation?
 Who has to approve moving to production?"

Capture:
- Decision-maker names and roles
- Influencer names and roles  
- Gate functions: compliance, legal, IT security
- Missing stakeholders to schedule separately

Phase 2 — Follow-Up Technical Sessions (as needed)#

After the kickoff, the FDE typically needs focused sessions with specific technical stakeholders:

Integration / IT Architecture session: Deep-dive on network topology, security architecture, integration engine (Azure Health Data Services, MuleSoft, RHAPSODY, etc.), FHIR API access process.

Clinical Informatics session: Clinical workflow detail, EHR configuration, clinical champion identification, Epic module configuration (which Epic modules are live and configured).

Compliance / Privacy Officer session: HIPAA requirements specific to this use case, BAA process and timeline, security review requirements, PHI handling constraints.

Data Engineering session: Data quality assessment, available data history, known data quality issues, transformation requirements.

Phase 3 — Discovery Summary Document#

The Discovery Summary is the FDE's primary deliverable from the discovery phase. It is shared with the client and serves as the foundation for the Assessment phase.

# Discovery Summary — [Client Name]

## Executive Summary
[3-sentence summary of what was learned and what it implies for the engagement]

## Current State Architecture

### Technical Environment
| System | Vendor/Version | Integration Method | Notes |
|--------|---------------|-------------------|-------|

### Current Workflow
[Step-by-step description of the current state process with identified pain points]

### Data Availability
| Data Source | Format | Access Method | Quality Assessment |
|-------------|--------|--------------|-------------------|

## Pain Points — Prioritized

| Priority | Pain Point | Estimated Impact | Source |
|----------|-----------|-----------------|--------|
| 1 | [Highest priority] | [Time/cost/quality] | [Who identified it] |

## AI Use Case Candidates

| Use Case | Alignment to Pain Points | Technical Feasibility | Organizational Readiness |
|----------|------------------------|----------------------|--------------------------|

## Stakeholder Map

| Name | Role | Decision Authority | Current Stance | Next Step |
|------|------|--------------------|---------------|-----------|

## Open Questions — Must Resolve in Assessment

[List of specific technical and organizational questions that must be answered
 before committing to a POC approach]

## Timeline Constraints

[Known deadlines, budget cycles, procurement gates, seasonal constraints]

## Recommended Next Step

[Specific recommendation: what the Assessment phase should focus on,
 what access is needed, what meetings should be scheduled]

Architecture Diagram#

Implementation Patterns#

Healthcare Discovery — Reference Healthcare Organization HMS Example#

The following illustrates a discovery session for a clinical documentation AI engagement at a large Reference Healthcare Organization.

Key healthcare-specific discovery questions:

HEALTHCARE_DISCOVERY_QUESTIONS = {
    "ehr_integration": [
        "Which version of Epic are you running and what's your upgrade cadence?",
        "Do you have FHIR R4 enabled and configured in your Epic instance?",
        "Have you gone through Epic's App Orchard review process before?",
        "What integration engine sits between Epic and your other systems?",
        "Do you use SMART on FHIR for any existing applications?"
    ],
    "data_access": [
        "Who approves new applications for FHIR API access?",
        "What is the typical timeline from request to approved API credentials?",
        "Are there restrictions on PHI leaving your on-premises environment?",
        "Do you have a Business Associate Agreement template we should review?",
        "What cloud providers are pre-approved for PHI workloads?"
    ],
    "clinical_workflow": [
        "Walk me through your current discharge summary process from physician to filing.",
        "Who is responsible for the discharge summary? Attending? Resident? NP?",
        "What template or format is currently used for discharge summaries?",
        "How long does a physician typically spend on a discharge summary?",
        "What is your readmission rate, and do you have attribution to documentation quality?"
    ],
    "regulatory": [
        "What is your current status with Joint Commission documentation requirements?",
        "Do you have an internal compliance review process for new AI applications?",
        "Is your legal team involved in AI vendor selection, and what do they look for?",
        "Have you engaged with the FDA on any AI tools that touch clinical workflows?",
        "What is your process for validating AI tools before clinical deployment?"
    ],
    "organizational": [
        "Who is the clinical champion for this initiative — do you have a physician sponsor?",
        "What is your IT change management process for clinical system changes?",
        "Have you deployed AI tools before? What was the change management experience?",
        "Who needs to be in the room when we make an architecture decision?",
        "What is the approval path for a new software application from IT through clinical leadership?"
    ]
}

Stakeholder map for a healthcare clinical documentation engagement:

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class Stakeholder:
    name: str
    role: str
    department: str
    decision_authority: str   # "Approve" | "Influence" | "Veto" | "Inform"
    current_stance: str       # "Champion" | "Neutral" | "Skeptical" | "Unknown"
    concerns: list[str] = field(default_factory=list)
    next_action: Optional[str] = None

# Reference Healthcare Organization — HMS discharge summary engagement
stakeholder_map = [
    Stakeholder(
        name="[CMIO]",
        role="Chief Medical Information Officer",
        department="Clinical Informatics",
        decision_authority="Approve",
        current_stance="Champion",
        concerns=["Physician adoption", "Documentation quality assurance"],
        next_action="Identify physician champion from their network"
    ),
    Stakeholder(
        name="[CIO]",
        role="Chief Information Officer",
        department="IT",
        decision_authority="Approve",
        current_stance="Neutral",
        concerns=["Epic integration complexity", "Security review timeline", "IT resource requirements"],
        next_action="Schedule architecture session with IT director"
    ),
    Stakeholder(
        name="[Privacy Officer]",
        role="Privacy and Compliance Officer",
        department="Compliance",
        decision_authority="Veto",
        current_stance="Unknown",
        concerns=["HIPAA BAA", "PHI in cloud AI systems", "Audit logging"],
        next_action="Schedule dedicated compliance session — do not proceed without this"
    ),
    Stakeholder(
        name="[IT Director]",
        role="IT Director, Clinical Systems",
        department="IT",
        decision_authority="Influence",
        current_stance="Skeptical",
        concerns=["Epic App Orchard timeline", "IT resource burden for integration"],
        next_action="Deep-dive on FHIR access process and timeline"
    ),
    Stakeholder(
        name="[Physician Champion]",
        role="Hospitalist / Attending Physician",
        department="Clinical",
        decision_authority="Influence",
        current_stance="Unknown",
        concerns=["Workflow disruption", "Liability for AI-generated content"],
        next_action="CMIO to identify and introduce; schedule clinical workflow session"
    ),
]

Data quality pre-assessment questions:

Before committing to a discharge summary AI POC, the FDE must assess the data quality of the FHIR resources the AI will consume:

def assess_fhir_data_quality(fhir_client, sample_encounter_ids: list[str]) -> dict:
    """
    Run against a sample of encounters (minimum 20) to assess data quality
    before committing to a discharge summary AI POC.
    
    Educational example — not for clinical use.
    """
    results = {
        "sample_size": len(sample_encounter_ids),
        "conditions_present": 0,
        "medications_present": 0,
        "vitals_present": 0,
        "labs_present": 0,
        "notes_present": 0,
        "conditions_avg_count": 0,
        "medications_avg_count": 0,
        "data_quality_issues": []
    }
    
    for encounter_id in sample_encounter_ids:
        conditions = fhir_client.get_conditions(encounter_id)
        medications = fhir_client.get_medications(encounter_id)
        vitals = fhir_client.get_observations(encounter_id, category="vital-signs")
        labs = fhir_client.get_observations(encounter_id, category="laboratory")
        
        if conditions:
            results["conditions_present"] += 1
            results["conditions_avg_count"] += len(conditions)
        else:
            results["data_quality_issues"].append(
                f"Encounter {encounter_id}: No conditions in FHIR — check Epic FHIR configuration"
            )
        
        # Similar checks for medications, vitals, labs...
    
    # Calculate rates
    n = len(sample_encounter_ids)
    results["conditions_completeness"] = results["conditions_present"] / n
    results["medications_completeness"] = results["medications_present"] / n
    
    # Flag for POC viability
    results["poc_viable"] = (
        results["conditions_completeness"] >= 0.80
        and results["medications_completeness"] >= 0.80
    )
    
    return results

Enterprise Considerations#

Discovery at scale: An FDE portfolio of 20+ accounts cannot run fully bespoke discovery for each engagement. Standardized templates, shared stakeholder databases, and discovery playbooks by vertical (healthcare, financial services, retail) allow the FDE team to maintain quality while increasing throughput.

Discovery documentation as institutional knowledge: Discovery summaries accumulate knowledge about client environments that is valuable beyond the individual engagement. Common patterns (Epic App Orchard timeline, Azure pre-approved PHI environments, Joint Commission documentation requirements) should be extracted into playbooks that the entire FDE team can reference.

When discovery reveals a misfit: Sometimes discovery reveals that the client's environment is not compatible with the product in its current state — wrong FHIR version, on-premises-only requirement, insufficient data quality. The FDE's responsibility is to communicate this clearly, even if it delays the engagement. Proceeding with a POC in a misfit environment wastes both parties' resources.

Security Considerations#

Discovery sessions involve the FDE learning details about the client's technical environment, including security architecture. FDEs must:

• Never share client architecture details with other clients or in public forums
• Treat discovery notes as confidential client information
• Not store discovery documents in unsecured personal systems
• Understand that asking about HIPAA compliance and PHI handling is standard practice — clients expect it

In healthcare engagements, the HIPAA Privacy and Security Rule governs even the discovery conversation if PHI is discussed. FDEs should not receive actual patient data during discovery — sample records should be synthetic or de-identified.

Healthcare Example#

A Reference Healthcare Organization is evaluating AI for prior authorization. The discovery process surfaces a critical finding: their payer portal integration is built on HL7 v2 messages through a RHAPSODY integration engine, not FHIR. The AI product was designed assuming FHIR-based payer APIs. This discovery finding changes the POC architecture significantly — the integration must be designed against HL7 v2 message parsing, not FHIR resource consumption.

Without structured discovery, this finding would have emerged in week 4 of POC execution, requiring a restart. Discovered in week 1, it shapes the POC design before any code is written.

Common Mistakes#

1. Skipping pre-discovery research. FDEs who arrive at discovery without having researched the client spend the first 30 minutes establishing basic facts that were publicly available. This burns discovery time and signals poor preparation.

2. Letting the product drive the conversation. "Here's what our product does — which of these use cases fit you?" is a sales motion. The discovery question is "What is your most painful problem right now?" Use cases emerge from pain points, not from product features.

3. Leaving without a complete stakeholder map. If the FDE does not know who the compliance officer is and has not scheduled a meeting with them, discovery is not complete.

4. Not documenting open questions. The most important output of a discovery session is the list of questions that were not answered. "We don't know whether PHI can leave the on-premises environment" is a discovery finding that must be resolved before POC design.

5. Treating the Discovery Summary as a status update. The Discovery Summary should contain enough information that a different FDE could pick up the engagement without losing context. It is institutional knowledge, not a meeting summary.

6. Accepting the stakeholder's self-assessment of data quality. "Our data is very clean" is not a data quality assessment. The FDE must run actual queries against a sample of the data before committing to a POC approach.

Best Practices#

• Spend 1–2 days on pre-discovery research before the first client meeting
• Open every discovery session with "Walk me through the current process" before introducing any product context
• Maintain a 30:70 speaking ratio (FDE:client) in discovery sessions
• Never end a discovery session without documenting the open questions that remain
• Include the compliance officer in discovery for any use case involving PHI — not as an afterthought
• Run a data quality pre-assessment before committing to a POC approach
• Share the Discovery Summary with the client for accuracy review before treating it as authoritative
• Define "discovery complete" as: technical environment mapped, pain points prioritized, all key stakeholders interviewed, open questions documented

Trade-offs#

Depth vs. speed: Thorough discovery takes 2–4 weeks. Clients often push for faster timelines. The FDE must hold the line on discovery quality, because inadequate discovery leads to POC restarts — which are far more expensive.

Discovery as a commitment signal: A structured, thorough discovery process signals that the FDE is serious. It also signals that the FDE is not going to cut corners. Some clients interpret this as bureaucracy; the FDE must frame it as due diligence that protects the client's time investment.

Breadth vs. focus: In a complex enterprise environment, discovery could continue indefinitely as new systems and stakeholders emerge. The FDE must define "good enough" for discovery and move to Assessment — otherwise the engagement never progresses.

Interview Questions#

Q: Describe your process for conducting technical discovery with a new enterprise client.#

Category: System Design Difficulty: Senior Role: FDE / AI Architect

Answer Framework:

Technical discovery has three sequential layers: pre-research, structured sessions, and documentation. Pre-research (1–2 days) uses public sources to establish baseline knowledge about the client's technology environment, organizational structure, and known pain points before the first meeting. This is non-negotiable — arriving uninformed wastes the client's time.

The discovery kickoff session (90–120 minutes) is a structured conversation with a defined agenda: current state architecture walk, pain point inventory, prior AI experience, data access process, and stakeholder map draft. The FDE facilitates and listens; the client talks. The ratio should be 30:70. After the kickoff, follow-up focused sessions with specific stakeholders (IT architecture, clinical informatics, compliance) resolve the technical questions that need specialized knowledge.

The Discovery Summary document captures current state, pain points, stakeholder map, and — critically — the open questions that must be resolved before POC design. The summary is shared with the client for review. Discovery is complete only when all key stakeholders have been interviewed, technical environment is mapped, and open questions are documented.

Key Points to Hit:

• Pre-research before first meeting
• Structured agenda with defined time segments
• Listen-first ratio (30:70)
• Discovery Summary as institutional knowledge document
• Definition of "discovery complete" includes compliance officer

Red Flags:

• Starting discovery with a product demo
• Skipping the compliance/privacy stakeholder
• Treating "discovery" as a single meeting

Q: During discovery, you learn that the client's EHR is running on FHIR STU3, not R4, and your product assumes FHIR R4. How do you handle this?#

Category: Architecture Difficulty: Principal Role: FDE

Answer Framework:

This is a critical discovery finding that must be surfaced immediately, clearly, and without minimizing its impact. The wrong response is to proceed with the POC and discover the incompatibility during execution.

First, I verify: is this a configuration issue (FHIR R4 is available but not enabled) or a version issue (their Epic version does not support R4)? Epic versions prior to approximately 2018 may not have FHIR R4 available. This requires a technical conversation with the EHR team.

If it is a genuine version gap, the FDE has three options to present to the client: (1) the POC scope is modified to avoid FHIR API dependence and uses a different integration path (direct database query via Clarity reporting, CSV export); (2) the client's Epic upgrade timeline is assessed — if they are upgrading to an R4-capable version within 6 months, the POC can be designed against R4 with the understanding of the timeline; (3) the product team is engaged to assess whether an STU3 integration path is feasible.

This finding belongs in the Discovery Summary as a blocking open question with resolution options. It must be resolved before POC Design begins.

Key Points to Hit:

• Verify before concluding (configuration vs. version issue)
• Surface clearly and without minimizing
• Present resolution options rather than a single recommendation
• Document as open question; resolve before POC Design
• Engage product team if STU3 support is needed

Red Flags:

• Proceeding with the POC and hoping to work around it
• Treating it as a minor issue

Key Takeaways#

• Discovery is an engineering activity, not a sales activity — its outputs directly determine POC architecture
• Pre-discovery research is required before the first client meeting
• The discovery kickoff should maintain a 30:70 speaking ratio (FDE:client)
• Three layers must be completed: technical environment, pain points, and organizational dynamics
• The compliance/privacy stakeholder must be included in discovery for PHI use cases
• Data quality must be assessed empirically, not accepted from the client's self-report
• Discovery is complete when: environment is mapped, stakeholders are interviewed, open questions are documented
• Discovery findings that reveal product-client misfits must be surfaced immediately

Glossary#

Discovery Summary: The structured document that captures current state architecture, pain points, stakeholder map, and open questions from the discovery phase.

FHIR R4: HL7 FHIR Release 4, the current production standard for healthcare API interoperability. The version assumed in Phase 5 EHR Integration patterns.

App Orchard: Epic's third-party application marketplace and review process for new integrations. Approval typically takes 6–12 weeks.

RHAPSODY: A healthcare integration engine commonly used for HL7 v2 message routing in hospital environments.

Further Reading#

• FDE Role and Responsibilities — The FDE engagement lifecycle
• AI Readiness Assessment — What happens after discovery
• EHR Integration — FHIR R4 and CDS Hooks technical patterns
• HIPAA and AI — PHI handling requirements for discovery conversations
• Healthcare Client Playbook — Healthcare-specific discovery patterns