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.

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:

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

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:

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

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.

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference. mermaid sequenceDiagram participant FDE as FDE (Pre-Research) participant KO as Discovery Kickoff participant FU as Follow-up Sessions participant DS as Discovery Summary

FDE->>FDE: Research: EHR vendor, cloud provider,<br/>org size, public AI history (1-2 days) FDE->>KO: Facilitate 90-min structured session<br/>(30:70 listen ratio)

KO->>KO: Current state architecture walk KO->>KO: Pain point inventory KO->>KO: Prior AI experience KO->>KO: Data access and governance KO->>KO: Stakeholder map draft

KO->>FU: Identify gaps requiring focused sessions FU->>FU: IT architecture session FU->>FU: Clinical informatics session FU->>FU: Compliance/privacy session FU->>FU: Data engineering session

FU->>DS: Draft Discovery Summary DS->>DS: Share with client for accuracy review DS->>DS: Publish as Assessment phase input

## 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.

## Healthcare Example

> **Educational Example — Illustrative Discovery. Not intended as clinical guidance.**

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

## Further Reading

- [FDE Role and Responsibilities](01-fde-role-and-responsibilities.md) — The FDE engagement lifecycle
- [AI Readiness Assessment](03-ai-readiness-assessment.md) — What happens after discovery
- [EHR Integration](../07-Healthcare-AI/03-ehr-integration.md) — FHIR R4 and CDS Hooks technical patterns
- [HIPAA and AI](../07-Healthcare-AI/02-hipaa-and-ai.md) — PHI handling requirements for discovery conversations
- [Healthcare Client Playbook](10-healthcare-client-playbook.md) — Healthcare-specific discovery patterns