6 Planning & Needs Assessment

6.1 Planning & Strategy / Needs Assessment

Every successful project begins with understanding the problem. In business analysis, this phase is called Strategy Analysis or Planning. In public health, it is the Needs Assessment or Community Health Assessment. Both seek to answer the same fundamental question: What problem are we solving, and for whom?

6.1.1 The Dual Framework

BA Perspective	PH Perspective
Business Need	Public Health Challenge
Current State Analysis	Epidemiological Baseline
Future State Vision	Program Goals & Intended Outcomes
Stakeholder Identification	Community Partner Mapping
Feasibility Assessment	Resource & Capacity Analysis

6.1.2 Start Translation Early

Many health IT projects encounter translation challenges only when they reach software requirements definition. By then, both teams have invested time and developed expectations using their own terminology. Untangling miscommunication while simultaneously trying to make progress creates unnecessary friction.

The business case is the ideal moment to introduce translation.

When building the justification for funding (whether a grant application, budget request, or vendor RFP), explicitly consider:

What terminology gaps exist between the technical and programmatic teams?
What training or facilitation will help teams communicate effectively?
Who will serve as translators or bridges between domains?
What documentation will help each team understand the other’s frameworks?

Including these considerations in the business case accomplishes two things:

Resource discovery: The funding request captures the full scope of what the project needs, including human and process elements, not just technical deliverables
Early alignment: Teams enter requirements gathering with shared vocabulary, reducing costly clarification loops later

CancerSurv Example

The CancerSurv grant application included a budget line for “cross-domain facilitation workshops” and allocated time for the project manager to develop a terminology crosswalk document before vendor selection. When TechHealth Solutions came on board, the state team provided this crosswalk in the kickoff meeting, establishing shared language from day one.

6.1.3 Defining the Problem

6.1.3.1 Business Analysis Approach

In traditional BA, the business need emerges from organizational pain points:

Revenue decline
Operational inefficiency
Compliance gaps
Competitive pressure
Technology obsolescence

The BA documents this in a Business Case that quantifies the problem, proposes solutions, and projects return on investment.

6.1.3.2 Public Health Approach

In public health, the need emerges from population health data:

Disease incidence and prevalence
Health disparities across demographics
Service access gaps
Outbreak patterns
Unmet community needs

The epidemiologist documents this in a Needs Assessment that quantifies health burden, identifies determinants, and prioritizes interventions.

CancerSurv Example

Business Need (BA framing): The legacy mainframe system is approaching end-of-life. Maintenance costs have increased 40% over three years. The system cannot support modern interoperability requirements or remote work.

Public Health Challenge (PH framing): Cancer data completeness has declined to 89%, below the CDC target of 95%. Late-stage diagnoses are increasing in rural counties, suggesting gaps in early detection. The current system cannot support the real-time analytics needed to identify and address disparities.

Both framings describe the same project. The BA framing emphasizes operational efficiency; the PH framing emphasizes health outcomes. Effective planning addresses both.

6.1.4 Current State Analysis

6.1.4.1 Documenting What Exists

Before defining requirements, understand what currently exists. The approaches differ in emphasis but serve the same purpose:

BA Current State Analysis:

Process maps (BPMN diagrams)
System inventories
Pain point interviews
Performance metrics
Technical debt assessment

PH Epidemiological Baseline:

Disease surveillance data
Demographic health profiles
Service utilization patterns
Health equity indicators
Environmental and social determinants

6.1.4.2 Data Sources for Current State

BA Data Sources	PH Data Sources
System logs, usage analytics	Disease registries, vital records
User surveys, interviews	Community health surveys (BRFSS)
Process documentation	Clinical guidelines, protocols
Financial reports	Grant reports, program evaluations
Vendor assessments	CDC/state health department data

6.1.5 Future State Vision

6.1.5.1 Defining Success

The future state describes what success looks like. Again, the framing differs:

BA Future State:

System capabilities and features
Process improvements
Performance targets
Technical architecture
Integration landscape

PH Program Goals:

Health outcome improvements
Disparity reductions
Service access expansion
Quality metrics
Population health indicators

6.1.5.2 SMART Objectives

Both domains benefit from SMART objective setting:

Component	BA Example	PH Example
Specific	Reduce case entry time	Increase early-stage cancer detection
Measurable	From 15 to 8 minutes per case	From 45% to 55% of cases
Achievable	Based on vendor benchmarks	Based on peer state performance
Relevant	Supports registrar productivity	Supports prevention targeting
Time-bound	Within 6 months of go-live	Within 2 years of program launch

CancerSurv Example

SMART Objective (Dual Framing):

BA: “Within 6 months of CancerSurv deployment, average case abstraction time will decrease from 15 minutes to 8 minutes, as measured by system audit logs.”

PH: “Within 2 years of CancerSurv deployment, data completeness will increase from 89% to 95%, enabling accurate survival analysis and disparity identification for the state cancer plan.”

Both objectives are valid; both should appear in project documentation.

6.1.6 Proving Impact: Defining Success Metrics That Matter

During the Planning phase, both teams must establish not just technical deliverables but proof points that demonstrate public health value and return on investment. This is not an afterthought for the Evaluation phase; impact measurement must be designed into the project from the beginning.

6.1.6.1 Why This Matters Now

When funding is constrained, every technology investment must justify its worth. Programs that cannot demonstrate measurable health outcomes or cost savings risk elimination. Grant proposals that lack data-driven proof of impact are increasingly non-competitive.

This creates a shared responsibility between technical and public health teams:

Technical teams (BAs, developers, product managers) must design systems that capture and report impact metrics automatically
Public health teams (epidemiologists, program managers, evaluators) must define what “success” looks like in measurable, system-capturable terms

Neither can succeed without the other. A system that tracks technical performance but not health outcomes cannot justify continued funding. A program with strong outcomes but no data to prove them cannot compete for resources.

6.1.6.2 Focus on Outcomes, Not Just Outputs

During planning, resist the temptation to define success solely through system features or process metrics. Instead, establish clear lines of sight from technical deliverables to health outcomes:

Don’t Just Measure…	Instead, Translate To…
System processes 12,000 records annually	Faster outbreak detection through real-time analytics
Achieved 95% data quality scores	Enabled accurate survival statistics that guide treatment protocols
Implemented HL7 FHIR integration	Reduced registrar burden by 40%, allowing focus on complex cases
Built analytics dashboard	Identified cancer disparities 6 months faster, enabling targeted screening

CancerSurv Example

During the Planning phase, the CancerSurv project team established paired metrics that satisfy both technical and programmatic accountability:

Baseline Metrics: - Legacy system processes 12,000 cases annually with 87% data completeness - 6-month lag between data collection and annual reporting - Manual processes consume 15 minutes per case for abstraction - Limited ability to identify geographic or demographic disparities

Target Metrics (Technical + Health Outcomes):

Data Completeness: Increase from 87% to 95% within 18 months
- Technical benefit: Meets CDC/NPCR reporting standards
- Health outcome: Approximately 960 additional cases fully documented, strengthening survival analyses and disparity assessments
Reporting Timeliness: Reduce lag from 6 months to 3 months
- Technical benefit: Automated data pipelines and validation
- Health outcome: Policy decisions about screening programs informed by more current data
Workflow Efficiency: Reduce abstraction time from 15 to 8 minutes per case
- Technical benefit: Improved UI/UX and automated coding suggestions
- Health outcome: Registrars can process more cases or dedicate time to complex case resolution
Disparity Identification: Enable real-time geographic and demographic analysis
- Technical benefit: Analytics dashboard with interactive mapping
- Health outcome: Target screening and prevention resources to underserved populations faster

These metrics were not arbitrary technical goals. They directly map to CDC reporting requirements, state strategic health objectives, and competitive grant criteria. By establishing them during Planning, the team ensured that both the business case and the system requirements aligned around demonstrable impact.

6.1.6.3 Making the Case to Multiple Audiences

Success metrics serve different stakeholders with different priorities. Plan for multiple reporting formats:

For CDC/NPCR Program: - Annual performance reports demonstrating compliance with NPCR standards - Data quality metrics (completeness, timeliness, validity) - Comparison to national benchmarks

For State Legislature and Budget Offices: - Budget justifications showing public health value per dollar invested - Efficiency gains (e.g., “Automation saves 140 hours/month, equivalent to $X salary”) - Health outcomes (e.g., “Earlier detection in rural counties reduced late-stage diagnoses by 12%”)

For Hospital Partners and Data Submitters: - Evidence that data submission yields insights valuable to their quality improvement efforts - Feedback reports showing how their data contributes to statewide cancer prevention - Reduced burden through automated electronic reporting

For Registry Staff: - Tangible improvements in workflow efficiency and job satisfaction - Recognition of their work’s impact on community health - Career development opportunities through new technical skills

Design for Impact from Day One

Proving impact is not solely the responsibility of the public health team’s evaluation unit. Business analysts, developers, and product managers must design impact measurement into the system architecture from requirements gathering forward. This means:

Including “evaluation metrics capture” as functional requirements, not optional features
Designing data models that support both operational reporting and outcome analysis
Building dashboards and export functions that generate grant-ready reports automatically
Architecting audit logs that track not just system usage but workflow improvements

Likewise, epidemiologists and registry staff must collaborate with technical partners early to define what “success” looks like in measurable, system-capturable terms. Vague goals like “improve cancer outcomes” must translate to specific, quantifiable indicators the system can track.

6.1.6.4 Building Impact into the Business Case

The business case or grant application developed during this Planning phase should explicitly address impact demonstration:

Resource Allocation: - Budget line items for evaluation tools, data visualization platforms, or analytics staff - Time allocated for defining metrics and establishing baselines - Training for staff on using system-generated reports for grant writing

Long-term Sustainability: - How will the system prove its value over time to justify continued funding? - What ongoing performance indicators will be tracked and reported? - Who is responsible for translating technical metrics into health outcome narratives?

Competitive Positioning: - How does this project’s approach to impact measurement differentiate the proposal? - What evidence-based outcomes make the case more compelling than competing priorities?

When both technical and public health teams embrace this shared responsibility for proving impact, technology investments do more than deliver features on time and on budget. They deliver demonstrable improvements in population health, which justifies existing funding and unlocks new opportunities. Public health leaders and elected officials are far more likely to protect and expand programs that show tangible results: reduced cancer mortality, eliminated disparities, dollars saved through prevention.

6.1.7 Stakeholder / Community Partner Identification

6.1.7.1 Mapping the Landscape

Identifying who participates in the project requires understanding both organizational and community perspectives:

flowchart TB
    subgraph Internal["Internal Partners"]
        A[Registry Director]
        B[Cancer Registrars]
        C[Epidemiologists]
        D[IT Department]
    end
    
    subgraph External["External Partners"]
        E[Hospitals]
        F[Laboratories]
        G[CDC/NPCR]
        H[Vital Records]
    end
    
    subgraph Community["Community"]
        I[Cancer Survivors]
        J[Advocacy Groups]
        K[Researchers]
    end
    
    A --> B
    A --> C
    A --> D
    E --> B
    F --> B
    G --> A
    H --> C
    I --> J
    J --> A
    K --> C

Figure 6.1: Stakeholder/Community Partner Landscape

6.1.7.2 Power-Interest Analysis

The classic BA power-interest grid maps to PH community engagement levels:

Quadrant	BA Approach	PH Approach
High Power, High Interest	Manage closely	Active partnership
High Power, Low Interest	Keep satisfied	Inform and consult
Low Power, High Interest	Keep informed	Empower and involve
Low Power, Low Interest	Monitor	Ensure representation

6.1.8 Feasibility Assessment

6.1.8.1 Can We Do This?

Both domains assess feasibility before committing resources:

BA Feasibility Dimensions:

Technical feasibility (Can we build it?)
Economic feasibility (Can we afford it?)
Operational feasibility (Can we run it?)
Schedule feasibility (Can we deliver on time?)

PH Feasibility Dimensions:

Evidence base (Does the intervention work?)
Resource availability (Do we have funding, staff?)
Political will (Is there leadership support?)
Community readiness (Will the population engage?)
Ethical considerations (Is it equitable?)

Bridging Tip

When presenting feasibility to mixed audiences, address both technical and programmatic dimensions. A system that is technically feasible but lacks community buy-in will fail. An intervention with strong evidence but no technical infrastructure cannot scale.

6.1.9 Deliverables from This Phase

BA Deliverable	PH Deliverable	Purpose
Business Case	Needs Assessment Report	Justify the project
Stakeholder Register	Community Partner Map	Identify participants
Current State Analysis	Epidemiological Baseline	Document starting point
Future State Vision	Program Goals	Define success
Feasibility Study	Readiness Assessment	Confirm viability

6.1.10 Common Pitfalls

For BA professionals entering PH:

Underestimating regulatory constraints (HIPAA, IRB)
Ignoring health equity implications
Treating clinical workflows like business processes
Missing grant-cycle dependencies

For PH professionals working with BA:

Providing needs assessments instead of requirements
Assuming IT teams understand clinical context
Underspecifying data quality needs
Ignoring change management complexity

6.1.11 Moving Forward

With the problem defined and feasibility confirmed, the next phase focuses on Elicitation: gathering detailed information from stakeholders and community partners about their specific needs and constraints.

--- title: "Planning & Needs Assessment" --- ## Planning & Strategy / Needs Assessment Every successful project begins with understanding the problem. In business analysis, this phase is called **Strategy Analysis** or **Planning**. In public health, it is the **Needs Assessment** or **Community Health Assessment**. Both seek to answer the same fundamental question: What problem are we solving, and for whom? ### The Dual Framework | BA Perspective | PH Perspective | |:---------------|:---------------| | Business Need | Public Health Challenge | | Current State Analysis | Epidemiological Baseline | | Future State Vision | Program Goals & Intended Outcomes | | Stakeholder Identification | Community Partner Mapping | | Feasibility Assessment | Resource & Capacity Analysis | ### Start Translation Early Many health IT projects encounter translation challenges only when they reach software requirements definition. By then, both teams have invested time and developed expectations using their own terminology. Untangling miscommunication while simultaneously trying to make progress creates unnecessary friction. **The business case is the ideal moment to introduce translation.** When building the justification for funding (whether a grant application, budget request, or vendor RFP), explicitly consider: - What terminology gaps exist between the technical and programmatic teams? - What training or facilitation will help teams communicate effectively? - Who will serve as translators or bridges between domains? - What documentation will help each team understand the other's frameworks? Including these considerations in the business case accomplishes two things: 1. **Resource discovery**: The funding request captures the full scope of what the project needs, including human and process elements, not just technical deliverables 2. **Early alignment**: Teams enter requirements gathering with shared vocabulary, reducing costly clarification loops later ::: {.callout-note title="CancerSurv Example"} The CancerSurv grant application included a budget line for "cross-domain facilitation workshops" and allocated time for the project manager to develop a terminology crosswalk document before vendor selection. When TechHealth Solutions came on board, the state team provided this crosswalk in the kickoff meeting, establishing shared language from day one. ::: ### Defining the Problem #### Business Analysis Approach In traditional BA, the business need emerges from organizational pain points: - Revenue decline - Operational inefficiency - Compliance gaps - Competitive pressure - Technology obsolescence The BA documents this in a **Business Case** that quantifies the problem, proposes solutions, and projects return on investment. #### Public Health Approach In public health, the need emerges from population health data: - Disease incidence and prevalence - Health disparities across demographics - Service access gaps - Outbreak patterns - Unmet community needs The epidemiologist documents this in a **Needs Assessment** that quantifies health burden, identifies determinants, and prioritizes interventions. ::: {.callout-note title="CancerSurv Example"} **Business Need (BA framing):** The legacy mainframe system is approaching end-of-life. Maintenance costs have increased 40% over three years. The system cannot support modern interoperability requirements or remote work. **Public Health Challenge (PH framing):** Cancer data completeness has declined to 89%, below the CDC target of 95%. Late-stage diagnoses are increasing in rural counties, suggesting gaps in early detection. The current system cannot support the real-time analytics needed to identify and address disparities. Both framings describe the same project. The BA framing emphasizes operational efficiency; the PH framing emphasizes health outcomes. Effective planning addresses both. ::: ### Current State Analysis #### Documenting What Exists Before defining requirements, understand what currently exists. The approaches differ in emphasis but serve the same purpose: **BA Current State Analysis:** - Process maps (BPMN diagrams) - System inventories - Pain point interviews - Performance metrics - Technical debt assessment **PH Epidemiological Baseline:** - Disease surveillance data - Demographic health profiles - Service utilization patterns - Health equity indicators - Environmental and social determinants #### Data Sources for Current State | BA Data Sources | PH Data Sources | |:----------------|:----------------| | System logs, usage analytics | Disease registries, vital records | | User surveys, interviews | Community health surveys (BRFSS) | | Process documentation | Clinical guidelines, protocols | | Financial reports | Grant reports, program evaluations | | Vendor assessments | CDC/state health department data | ### Future State Vision #### Defining Success The future state describes what success looks like. Again, the framing differs: **BA Future State:** - System capabilities and features - Process improvements - Performance targets - Technical architecture - Integration landscape **PH Program Goals:** - Health outcome improvements - Disparity reductions - Service access expansion - Quality metrics - Population health indicators #### SMART Objectives Both domains benefit from SMART objective setting: | Component | BA Example | PH Example | |:----------|:-----------|:-----------| | **Specific** | Reduce case entry time | Increase early-stage cancer detection | | **Measurable** | From 15 to 8 minutes per case | From 45% to 55% of cases | | **Achievable** | Based on vendor benchmarks | Based on peer state performance | | **Relevant** | Supports registrar productivity | Supports prevention targeting | | **Time-bound** | Within 6 months of go-live | Within 2 years of program launch | ::: {.callout-note title="CancerSurv Example"} **SMART Objective (Dual Framing):** *BA:* "Within 6 months of CancerSurv deployment, average case abstraction time will decrease from 15 minutes to 8 minutes, as measured by system audit logs." *PH:* "Within 2 years of CancerSurv deployment, data completeness will increase from 89% to 95%, enabling accurate survival analysis and disparity identification for the state cancer plan." Both objectives are valid; both should appear in project documentation. ::: ### Proving Impact: Defining Success Metrics That Matter During the Planning phase, both teams must establish not just technical deliverables but **proof points** that demonstrate public health value and return on investment. This is not an afterthought for the Evaluation phase; impact measurement must be designed into the project from the beginning. #### Why This Matters Now When funding is constrained, every technology investment must justify its worth. Programs that cannot demonstrate measurable health outcomes or cost savings risk elimination. Grant proposals that lack data-driven proof of impact are increasingly non-competitive. This creates a **shared responsibility** between technical and public health teams: - **Technical teams** (BAs, developers, product managers) must design systems that capture and report impact metrics automatically - **Public health teams** (epidemiologists, program managers, evaluators) must define what "success" looks like in measurable, system-capturable terms Neither can succeed without the other. A system that tracks technical performance but not health outcomes cannot justify continued funding. A program with strong outcomes but no data to prove them cannot compete for resources. #### Focus on Outcomes, Not Just Outputs During planning, resist the temptation to define success solely through system features or process metrics. Instead, establish clear lines of sight from technical deliverables to health outcomes: | Don't Just Measure... | Instead, Translate To... | |:----------------------|:------------------------| | System processes 12,000 records annually | Faster outbreak detection through real-time analytics | | Achieved 95% data quality scores | Enabled accurate survival statistics that guide treatment protocols | | Implemented HL7 FHIR integration | Reduced registrar burden by 40%, allowing focus on complex cases | | Built analytics dashboard | Identified cancer disparities 6 months faster, enabling targeted screening | ::: {.callout-note title="CancerSurv Example"} During the Planning phase, the CancerSurv project team established **paired metrics** that satisfy both technical and programmatic accountability: **Baseline Metrics:** - Legacy system processes 12,000 cases annually with 87% data completeness - 6-month lag between data collection and annual reporting - Manual processes consume 15 minutes per case for abstraction - Limited ability to identify geographic or demographic disparities **Target Metrics (Technical + Health Outcomes):** 1. **Data Completeness**: Increase from 87% to 95% within 18 months - *Technical benefit*: Meets CDC/NPCR reporting standards - *Health outcome*: Approximately 960 additional cases fully documented, strengthening survival analyses and disparity assessments 2. **Reporting Timeliness**: Reduce lag from 6 months to 3 months - *Technical benefit*: Automated data pipelines and validation - *Health outcome*: Policy decisions about screening programs informed by more current data 3. **Workflow Efficiency**: Reduce abstraction time from 15 to 8 minutes per case - *Technical benefit*: Improved UI/UX and automated coding suggestions - *Health outcome*: Registrars can process more cases or dedicate time to complex case resolution 4. **Disparity Identification**: Enable real-time geographic and demographic analysis - *Technical benefit*: Analytics dashboard with interactive mapping - *Health outcome*: Target screening and prevention resources to underserved populations faster These metrics were not arbitrary technical goals. They directly map to CDC reporting requirements, state strategic health objectives, and competitive grant criteria. By establishing them during Planning, the team ensured that both the business case and the system requirements aligned around demonstrable impact. ::: #### Making the Case to Multiple Audiences Success metrics serve different stakeholders with different priorities. Plan for multiple reporting formats: **For CDC/NPCR Program:** - Annual performance reports demonstrating compliance with NPCR standards - Data quality metrics (completeness, timeliness, validity) - Comparison to national benchmarks **For State Legislature and Budget Offices:** - Budget justifications showing public health value per dollar invested - Efficiency gains (e.g., "Automation saves 140 hours/month, equivalent to $X salary") - Health outcomes (e.g., "Earlier detection in rural counties reduced late-stage diagnoses by 12%") **For Hospital Partners and Data Submitters:** - Evidence that data submission yields insights valuable to their quality improvement efforts - Feedback reports showing how their data contributes to statewide cancer prevention - Reduced burden through automated electronic reporting **For Registry Staff:** - Tangible improvements in workflow efficiency and job satisfaction - Recognition of their work's impact on community health - Career development opportunities through new technical skills ::: {.callout-important title="Design for Impact from Day One"} Proving impact is not solely the responsibility of the public health team's evaluation unit. Business analysts, developers, and product managers must design impact measurement into the system architecture from requirements gathering forward. This means: - Including "evaluation metrics capture" as functional requirements, not optional features - Designing data models that support both operational reporting and outcome analysis - Building dashboards and export functions that generate grant-ready reports automatically - Architecting audit logs that track not just system usage but workflow improvements Likewise, epidemiologists and registry staff must collaborate with technical partners early to define what "success" looks like in measurable, system-capturable terms. Vague goals like "improve cancer outcomes" must translate to specific, quantifiable indicators the system can track. ::: #### Building Impact into the Business Case The business case or grant application developed during this Planning phase should explicitly address impact demonstration: **Resource Allocation:** - Budget line items for evaluation tools, data visualization platforms, or analytics staff - Time allocated for defining metrics and establishing baselines - Training for staff on using system-generated reports for grant writing **Long-term Sustainability:** - How will the system prove its value over time to justify continued funding? - What ongoing performance indicators will be tracked and reported? - Who is responsible for translating technical metrics into health outcome narratives? **Competitive Positioning:** - How does this project's approach to impact measurement differentiate the proposal? - What evidence-based outcomes make the case more compelling than competing priorities? When both technical and public health teams embrace this shared responsibility for proving impact, technology investments do more than deliver features on time and on budget. They deliver **demonstrable improvements in population health**, which justifies existing funding and unlocks new opportunities. Public health leaders and elected officials are far more likely to protect and expand programs that show tangible results: reduced cancer mortality, eliminated disparities, dollars saved through prevention. ### Stakeholder / Community Partner Identification #### Mapping the Landscape Identifying who participates in the project requires understanding both organizational and community perspectives: ```{mermaid} %%| label: fig-stakeholder-map %%| fig-cap: "Stakeholder/Community Partner Landscape" flowchart TB subgraph Internal["Internal Partners"] A[Registry Director] B[Cancer Registrars] C[Epidemiologists] D[IT Department] end subgraph External["External Partners"] E[Hospitals] F[Laboratories] G[CDC/NPCR] H[Vital Records] end subgraph Community["Community"] I[Cancer Survivors] J[Advocacy Groups] K[Researchers] end A --> B A --> C A --> D E --> B F --> B G --> A H --> C I --> J J --> A K --> C ``` #### Power-Interest Analysis The classic BA power-interest grid maps to PH community engagement levels: | Quadrant | BA Approach | PH Approach | |:---------|:------------|:------------| | High Power, High Interest | Manage closely | Active partnership | | High Power, Low Interest | Keep satisfied | Inform and consult | | Low Power, High Interest | Keep informed | Empower and involve | | Low Power, Low Interest | Monitor | Ensure representation | ### Feasibility Assessment #### Can We Do This? Both domains assess feasibility before committing resources: **BA Feasibility Dimensions:** - Technical feasibility (Can we build it?) - Economic feasibility (Can we afford it?) - Operational feasibility (Can we run it?) - Schedule feasibility (Can we deliver on time?) **PH Feasibility Dimensions:** - Evidence base (Does the intervention work?) - Resource availability (Do we have funding, staff?) - Political will (Is there leadership support?) - Community readiness (Will the population engage?) - Ethical considerations (Is it equitable?) ::: {.callout-tip title="Bridging Tip"} When presenting feasibility to mixed audiences, address both technical and programmatic dimensions. A system that is technically feasible but lacks community buy-in will fail. An intervention with strong evidence but no technical infrastructure cannot scale. ::: ### Deliverables from This Phase | BA Deliverable | PH Deliverable | Purpose | |:---------------|:---------------|:--------| | Business Case | Needs Assessment Report | Justify the project | | Stakeholder Register | Community Partner Map | Identify participants | | Current State Analysis | Epidemiological Baseline | Document starting point | | Future State Vision | Program Goals | Define success | | Feasibility Study | Readiness Assessment | Confirm viability | ### Common Pitfalls **For BA professionals entering PH:** - Underestimating regulatory constraints (HIPAA, IRB) - Ignoring health equity implications - Treating clinical workflows like business processes - Missing grant-cycle dependencies **For PH professionals working with BA:** - Providing needs assessments instead of requirements - Assuming IT teams understand clinical context - Underspecifying data quality needs - Ignoring change management complexity ### Moving Forward With the problem defined and feasibility confirmed, the next phase focuses on **Elicitation**: gathering detailed information from stakeholders and community partners about their specific needs and constraints.