Client Discovery Framework

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:

python

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

text

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.

markdown

# Discovery Summary — [Client Name]

## Architecture Diagram

```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

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

Client Discovery Framework#

Conceptual Explanation#

Core Architecture: The Discovery Framework#

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

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

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

Phase 3 — Discovery Summary Document#

Common Mistakes#

Best Practices#

Trade-offs#

Interview Questions#

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

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

Key Takeaways#