3 Introduction – Bridgeframe

3.1 Why Bridgeframe Exists

Public health and information technology are increasingly intertwined. Disease surveillance systems, immunization registries, electronic lab reporting, and health analytics platforms all require collaboration between two groups that often struggle to understand each other: business analysts and public health professionals.

This chapter explains the problem, introduces the Bridgeframe approach, and sets the stage for the detailed guidance that follows.

3.1.1 The Silo Problem

Consider a typical scenario: A state health department receives funding to modernize its disease surveillance system. They contract with a software vendor whose project team includes experienced business analysts, developers, and testers. The health department brings epidemiologists, program managers, and data analysts. Both sides are competent in their respective domains. Yet within weeks, the project is mired in confusion.

The vendor’s BA asks for “user stories.” The epidemiologist provides a detailed case definition document. The BA politely explains that a case definition is not a user story. The epidemiologist wonders why the BA keeps asking about “acceptance criteria” when the CDC already publishes validation rules.

This is not a failure of intelligence or good faith. It is a failure of translation.

3.1.2 Two Parallel Worlds

Business analysis, as codified in the BABOK (Business Analysis Body of Knowledge), provides a rigorous framework for understanding needs, defining requirements, and ensuring solutions deliver value¹. Public health analysis, guided by CDC frameworks and epidemiological methods, provides an equally rigorous approach to assessing community needs, designing interventions, and evaluating outcomes^2,3.

These frameworks are parallel, not incompatible:

Business Analysis	Public Health
Stakeholder Analysis	Community Partner Mapping
Current State Analysis	Epidemiological Baseline
Requirements Specification	Program Protocol
Solution Design	Intervention Design
Implementation	Program Rollout
Evaluation	Program Evaluation

The concepts align; the terminology diverges. Bridgeframe provides the translation layer.

3.1.3 The Cost of Miscommunication

When BA and PH professionals cannot communicate effectively, projects suffer:

Inability to prove impact: Systems that cannot demonstrate public health value

More importantly, health outcomes suffer. A delayed surveillance system means delayed outbreak response. A poorly designed immunization registry means children missing vaccines. And increasingly, programs that cannot demonstrate measurable public health impact risk losing funding.

Both technical and public health teams share responsibility for proving the value of their work. Technology investments must translate to demonstrable improvements in population health, not just features delivered on time and on budget.

3.1.4 The Bridgeframe Solution

Bridgeframe offers a structured approach to bridging these domains:

Common Vocabulary: Chapter 3 provides a comprehensive dictionary mapping BA terms to PH equivalents
Phase Alignment: Chapters 4-9 walk through each lifecycle phase, showing how BA activities map to PH frameworks
Practical Examples: The CancerSurv case study (Chapter 2) demonstrates concepts in action
Implementation Science: Chapter 11 introduces CFIR and other frameworks for addressing adoption barriers

3.1.5 Start with the Client’s Framework

Before diving into requirements gathering or sprint planning, a critical first question must be answered: What frameworks does the client already use?

Public health organizations operate within established methodological traditions. They may follow CDC evaluation frameworks, use logic models for program planning, apply CFIR for implementation readiness, or adhere to agency-specific protocols. These are not obstacles to be worked around; they are assets to be leveraged.

When engaging with a public health client:

Ask early: In the first meetings, explicitly ask what frameworks, methodologies, or standards guide their work
Prioritize existing frameworks: If the client has established approaches, adapt your deliverables to align with them rather than imposing unfamiliar structures
Translate, do not replace: When BA frameworks offer value the client lacks, introduce them by mapping to familiar concepts. Present a “logic model with software requirements” rather than demanding they learn BABOK terminology
Document the bridge: Create explicit crosswalks showing how your deliverables map to their frameworks

Practical Guidance

If you are the business analyst or developer, your role is translation, not conversion. A requirements document that aligns with the client’s existing CDC program evaluation framework will gain faster buy-in than one that requires the client to learn Agile terminology. Meet them where they are.

This principle works both ways. Public health professionals engaging with IT vendors should communicate their frameworks early, providing documentation and context so the technical team can adapt their approach accordingly.

3.1.6 When to Introduce the Translation

A common pattern across public health IT projects: translation challenges emerge during software requirements gathering, by which point significant momentum (and sometimes conflict) has already built up. The teams discover they are speaking different languages only after the project is well underway.

The earlier translation happens, the better the outcome.

Ideally, translation should begin during the business case development that justifies funding. When writing grant applications or funding proposals, explicitly address:

How IT terminology maps to programmatic outcomes
What resources (training, facilitation, documentation) will be needed for cross-domain communication
Who will serve as translators or bridges between teams

This early attention accomplishes two things: it surfaces potential friction points before they become costly, and it ensures that resource discovery includes the human and process elements needed for successful collaboration, not just technical requirements.

Practical Guidance

If you are writing a grant proposal or business case for a health IT project, include a line item for “cross-domain facilitation” or “terminology alignment workshops.” This signals awareness of the challenge and secures resources to address it.

When translation training happens before or alongside business case development, teams enter requirements gathering with shared vocabulary and mutual understanding. When it happens only during software requirements definition, teams must untangle miscommunication while simultaneously trying to make progress.

3.1.7 Who Should Use This Book

This book serves multiple audiences:

For IT Business Analysts entering public health:

Learn the regulatory context (HIPAA, CDC reporting requirements)
Understand grant-driven funding and its implications
Adapt Agile practices for public health workflows

For Public Health Professionals working with IT teams:

Translate your needs into requirements language
Participate effectively in sprint planning and reviews
Evaluate vendor proposals with confidence

For Project Managers and Leaders:

Build teams with shared vocabulary
Anticipate common friction points
Structure projects for hybrid success

CancerSurv Example

Throughout this book, we follow the CancerSurv project: a state health department modernizing its cancer registry system. In the Introduction, the challenge is framed as both a Business Need (replace aging mainframe with modern cloud platform) and a Public Health Challenge (ensure timely, complete cancer data for prevention planning and disparity identification).

3.1.8 What Bridgeframe Is Not

This book does not replace domain-specific training. Business analysts should still study the BABOK and pursue relevant certifications. Public health professionals should still learn epidemiology, biostatistics, and program evaluation. Bridgeframe provides the bridge between these bodies of knowledge, not a substitute for them.

Similarly, this book does not cover software development practices, database design, or clinical medicine in depth. It focuses specifically on the analysis phase: understanding needs, defining requirements, and evaluating solutions.

3.1.9 Moving Forward

The following chapter introduces CancerSurv in detail, providing the context you will need to engage with examples throughout the book. Chapter 3 then provides the terminology dictionary, a reference you will return to often. From there, we proceed phase by phase through the analysis lifecycle.

Welcome to Bridgeframe. Let us build this bridge together.

--- title: "Introduction" --- ## Why Bridgeframe Exists Public health and information technology are increasingly intertwined. Disease surveillance systems, immunization registries, electronic lab reporting, and health analytics platforms all require collaboration between two groups that often struggle to understand each other: **business analysts** and **public health professionals**. This chapter explains the problem, introduces the Bridgeframe approach, and sets the stage for the detailed guidance that follows. ### The Silo Problem Consider a typical scenario: A state health department receives funding to modernize its disease surveillance system. They contract with a software vendor whose project team includes experienced business analysts, developers, and testers. The health department brings epidemiologists, program managers, and data analysts. Both sides are competent in their respective domains. Yet within weeks, the project is mired in confusion. The vendor's BA asks for "user stories." The epidemiologist provides a detailed case definition document. The BA politely explains that a case definition is not a user story. The epidemiologist wonders why the BA keeps asking about "acceptance criteria" when the CDC already publishes validation rules. This is not a failure of intelligence or good faith. It is a failure of translation. ### Two Parallel Worlds Business analysis, as codified in the BABOK (Business Analysis Body of Knowledge), provides a rigorous framework for understanding needs, defining requirements, and ensuring solutions deliver value[@iiba_babok_2015]. Public health analysis, guided by CDC frameworks and epidemiological methods, provides an equally rigorous approach to assessing community needs, designing interventions, and evaluating outcomes[@cdc_cdc_2025; @kidder_cdc_2024]. These frameworks are parallel, not incompatible: | Business Analysis | Public Health | |:---------------------------|:--------------------------| | Stakeholder Analysis | Community Partner Mapping | | Current State Analysis | Epidemiological Baseline | | Requirements Specification | Program Protocol | | Solution Design | Intervention Design | | Implementation | Program Rollout | | Evaluation | Program Evaluation | The concepts align; the terminology diverges. Bridgeframe provides the translation layer. ### The Cost of Miscommunication When BA and PH professionals cannot communicate effectively, projects suffer: **Inability to prove impact**: Systems that cannot demonstrate public health value More importantly, health outcomes suffer. A delayed surveillance system means delayed outbreak response. A poorly designed immunization registry means children missing vaccines. And increasingly, programs that cannot demonstrate measurable public health impact risk losing funding. **Both technical and public health teams share responsibility for proving the value of their work.** Technology investments must translate to demonstrable improvements in population health, not just features delivered on time and on budget. ### The Bridgeframe Solution Bridgeframe offers a structured approach to bridging these domains: 1. **Common Vocabulary**: Chapter 3 provides a comprehensive dictionary mapping BA terms to PH equivalents 2. **Phase Alignment**: Chapters 4-9 walk through each lifecycle phase, showing how BA activities map to PH frameworks 3. **Practical Examples**: The CancerSurv case study (Chapter 2) demonstrates concepts in action 4. **Implementation Science**: Chapter 11 introduces CFIR and other frameworks for addressing adoption barriers ### Start with the Client's Framework Before diving into requirements gathering or sprint planning, a critical first question must be answered: **What frameworks does the client already use?** Public health organizations operate within established methodological traditions. They may follow CDC evaluation frameworks, use logic models for program planning, apply CFIR for implementation readiness, or adhere to agency-specific protocols. These are not obstacles to be worked around; they are assets to be leveraged. When engaging with a public health client: 1. **Ask early**: In the first meetings, explicitly ask what frameworks, methodologies, or standards guide their work 2. **Prioritize existing frameworks**: If the client has established approaches, adapt your deliverables to align with them rather than imposing unfamiliar structures 3. **Translate, do not replace**: When BA frameworks offer value the client lacks, introduce them by mapping to familiar concepts. Present a "logic model with software requirements" rather than demanding they learn BABOK terminology 4. **Document the bridge**: Create explicit crosswalks showing how your deliverables map to their frameworks ::: {.callout-tip title="Practical Guidance"} If you are the business analyst or developer, your role is translation, not conversion. A requirements document that aligns with the client's existing CDC program evaluation framework will gain faster buy-in than one that requires the client to learn Agile terminology. Meet them where they are. ::: This principle works both ways. Public health professionals engaging with IT vendors should communicate their frameworks early, providing documentation and context so the technical team can adapt their approach accordingly. ### When to Introduce the Translation A common pattern across public health IT projects: translation challenges emerge during software requirements gathering, by which point significant momentum (and sometimes conflict) has already built up. The teams discover they are speaking different languages only after the project is well underway. **The earlier translation happens, the better the outcome.** Ideally, translation should begin during the business case development that justifies funding. When writing grant applications or funding proposals, explicitly address: - How IT terminology maps to programmatic outcomes - What resources (training, facilitation, documentation) will be needed for cross-domain communication - Who will serve as translators or bridges between teams This early attention accomplishes two things: it surfaces potential friction points before they become costly, and it ensures that resource discovery includes the human and process elements needed for successful collaboration, not just technical requirements. ::: {.callout-tip title="Practical Guidance"} If you are writing a grant proposal or business case for a health IT project, include a line item for "cross-domain facilitation" or "terminology alignment workshops." This signals awareness of the challenge and secures resources to address it. ::: When translation training happens before or alongside business case development, teams enter requirements gathering with shared vocabulary and mutual understanding. When it happens only during software requirements definition, teams must untangle miscommunication while simultaneously trying to make progress. ### Who Should Use This Book This book serves multiple audiences: **For IT Business Analysts entering public health:** - Learn the regulatory context (HIPAA, CDC reporting requirements) - Understand grant-driven funding and its implications - Adapt Agile practices for public health workflows **For Public Health Professionals working with IT teams:** - Translate your needs into requirements language - Participate effectively in sprint planning and reviews - Evaluate vendor proposals with confidence **For Project Managers and Leaders:** - Build teams with shared vocabulary - Anticipate common friction points - Structure projects for hybrid success ::: {.callout-note title="CancerSurv Example"} Throughout this book, we follow the CancerSurv project: a state health department modernizing its cancer registry system. In the Introduction, the challenge is framed as both a **Business Need** (replace aging mainframe with modern cloud platform) and a **Public Health Challenge** (ensure timely, complete cancer data for prevention planning and disparity identification). ::: ### What Bridgeframe Is Not This book does not replace domain-specific training. Business analysts should still study the BABOK and pursue relevant certifications. Public health professionals should still learn epidemiology, biostatistics, and program evaluation. Bridgeframe provides the bridge between these bodies of knowledge, not a substitute for them. Similarly, this book does not cover software development practices, database design, or clinical medicine in depth. It focuses specifically on the analysis phase: understanding needs, defining requirements, and evaluating solutions. ### Moving Forward The following chapter introduces CancerSurv in detail, providing the context you will need to engage with examples throughout the book. Chapter 3 then provides the terminology dictionary, a reference you will return to often. From there, we proceed phase by phase through the analysis lifecycle. Welcome to Bridgeframe. Let us build this bridge together.