%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2494f7', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#01272f', 'lineColor': '#777777', 'secondaryColor': '#00a4bb', 'tertiaryColor': '#01272f', 'edgeLabelBackground': '#ffffff'}}}%%
flowchart TB
P1["<b>Ch 6: Planning & Strategy (BA) | Needs Assessment (PH)</b><br/><br/>BA Terms: business need, current state, future state, stakeholder identification<br/>PH Analog: public health challenge, epidemiological baseline, program goals<br/>Frameworks: SMART, RACI, SIPOC, 5 Whys, Fishbone<br/>Artifacts: business case, needs assessment, stakeholder map, current-state analysis"]
P2["<b>Ch 7: Elicitation (BA) | Stakeholder Engagement (PH)</b><br/><br/>BA Terms: interviews, workshops, document analysis, observation, prototyping<br/>PH Analog: key informant interviews, focus groups, community engagement<br/>Frameworks: facilitation techniques, participatory research methods<br/>Artifacts: interview notes, workshop outputs, elicitation findings"]
P3["<b>Ch 8: Requirements Analysis (BA) | Data Analysis & Logic Models (PH)</b><br/><br/>BA Terms: functional requirements, NFRs, data requirements, business rules<br/>PH Analog: program activities, implementation characteristics, case definitions<br/>Frameworks: MoSCoW, INVEST, UML, ERD; Logic Model, Theory of Change<br/>Artifacts: requirements specification, data dictionary, logic model, RTM"]
P4["<b>Ch 9: Design & Solution Definition (BA) | Intervention Design (PH)</b><br/><br/>BA Terms: solution architecture, interface design, integration design<br/>PH Analog: intervention framework, program design, service delivery model<br/>Frameworks: UML, CFIR implementation planning<br/>Artifacts: architecture diagrams, prototypes, implementation strategy"]
P5["<b>Ch 10: Implementation (BA) | Program Execution (PH)</b><br/><br/>BA Terms: sprint, release management, UAT, go-live, defect management<br/>PH Analog: PDSA cycle, phased rollout, pilot evaluation, program launch<br/>Frameworks: Agile/Scrum, Kanban; PDSA, implementation science<br/>Artifacts: release notes, test results, training materials, change log"]
P6["<b>Ch 11: Evaluation (BA) | Program Evaluation & QI (PH)</b><br/><br/>BA Terms: solution evaluation, KPI tracking, ROI, lessons learned<br/>PH Analog: program evaluation, health indicators, cost-effectiveness, QI<br/>Frameworks: CDC Evaluation Framework, RE-AIM, PDCA/PDSA<br/>Artifacts: KPI dashboard, evaluation report, after-action review"]
P1 --> P2
P2 --> P3
P3 --> P4
P4 --> P5
P5 --> P6
P6 -.->|"Iterate and Improve"| P1
linkStyle 5 stroke:#333333
5.1 The BA-PH Translation Guide
This chapter provides a comprehensive mapping between Business Analysis (BA) terminology and Public Health (PH) equivalents. Use this as a reference throughout your work on hybrid projects.
5.1.1 Core Process Mapping
The BA lifecycle aligns with public health program phases:
| BA / BABOK Phase | Public Health Equivalent | Key Activities |
|---|---|---|
| Strategy Analysis | Community Health Assessment | Define the problem using epidemiological data vs business metrics |
| Requirements Analysis | Data Analysis & Logic Models | Model processes, define indicators |
| Solution Evaluation | Program Evaluation (CDC Framework) | Measure outcomes against targets |
| Change Management | Implementation Science | CFIR, RE-AIM for adoption barriers |
5.1.2 The Complete BA-PH Process Workflow
The following diagram illustrates the six-phase analysis process covered in Part II of this book, showing how each BA phase maps to its Public Health equivalent. Note the iterative feedback loop from evaluation back to planning, reflecting the continuous improvement philosophy shared by both domains.
Each phase produces artifacts and applies frameworks that translate across domains. The following sections detail the terminology mappings for each phase.
5.1.3 Terminology Translation Table
5.1.3.1 Planning & Strategy Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| Business Need / Business Case | Public Health Challenge / Health Need | In PH, the driver for change is health equity or social determinants, not profit |
| Current State Analysis | Epidemiological Baseline | Document existing conditions: disease incidence, service gaps, health disparities |
| Future State / Vision | Program Goals & Intended Outcomes | Define success via improved health indicators, not market share |
| Constraints / Assumptions | Social Determinants / Policy Constraints | Include funding limitations, regulatory requirements (HIPAA), cultural barriers, equity considerations |
5.1.4 Stakeholder & Communication Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| Stakeholder | Interest Holder / Community Partner / Rights Holder | See detailed note below on terminology considerations |
| Stakeholder Analysis | Community Partner Mapping | Identify power dynamics, health equity implications |
| Requirements Workshop | Community Engagement Session | PH emphasizes participatory approaches and cultural competency |
WarningA Note on ‘Stakeholder’ Terminology
While “stakeholder” is standard in BA/Agile contexts (and used throughout this book for clarity), it carries colonial connotations in public health settings. The term evokes land claims and power imbalances, potentially disempowering Indigenous peoples and marginalized communities.
Preferred alternatives in public health contexts:
- General Use: Interest Holders, Parties/Affected Parties, Beneficiaries, Actants
- Action-Oriented: Constituents, Key Informants, Knowledge Users, Rights Holders
When writing for mixed audiences, acknowledge both terms. When writing for public health audiences exclusively, favor the alternatives.
5.1.4.1 Requirements & Analysis Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| User Story | Service-User Scenario / GPS Format | GPS = “Given [context], the Person [role] Should [action]” for clinical settings |
| Epic | Grant Objective / Program Goal | High-level outcome (e.g., “Reduce TB incidence by 10%”) |
| Requirements | Program Protocols / Clinical Guidelines | Business rules are often legally or clinically mandated in PH |
| NFRs (Non-Functional Requirements) | Implementation Characteristics (CFIR) | Scalability = Outbreak Resilience; Security = HIPAA/Trust |
| Process Model (BPMN) | Intervention Flowchart / Logic Model | Visualize Inputs → Activities → Outputs → Outcomes |
| Data Model / Schema | Case Definition / Data Dictionary | ER diagrams vs epidemiological case criteria |
| Use Case Diagram | Patient Journey Map | UML diagrams vs mapping patient experience through care continuum |
5.1.4.2 Agile & Iteration Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| Sprint | PDSA Cycle / Adaptive Management | Plan-Do-Study-Act: cyclic improvement framework |
| Backlog | Workplan / Action Items | Prioritized list of features vs outreach tasks |
| Sprint Review / Demo | Progress Reporting | Often aligned with grant reporting periods |
| Retrospective | After-Action Review | Systematic reflection on what worked and what needs improvement |
5.1.4.3 Quality & Evaluation Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| KPI (Key Performance Indicator) | Health Indicator | “15% improvement in customer satisfaction” vs “10% reduction in infection rate” |
| Acceptance Test Plan | Evaluation Protocol | Test cases vs data collection and analysis plan |
| Quality Assurance | Quality Improvement (QI) | Systematic checks, continuous improvement cycles |
| Bug / Defect | Adverse Event / Variance | System error vs deviation from expected health outcome |
| Lessons Learned | After-Action Review | Retrospective analysis, sharing successes and gaps across organization |
5.1.4.4 Design & Implementation Terms
| BA / Agile Term | Public Health Equivalent | Context / Nuance |
|---|---|---|
| Prototype / Mockup | Pilot Study / Field Test | Software wireframe vs PH intervention pilot in limited population |
| Risk Analysis | Community Risk Assessment | Standard risk assessment vs PH frameworks (CFIR, RE-AIM) |
| Go-Live | Program Launch / Rollout | System deployment vs intervention implementation |
| Training Plan | Capacity Building | End-user training vs workforce development |
5.1.5 Alternative User Story Formats for Public Health
The standard “As a [user], I want [feature], so that [benefit]” format often fails in clinical contexts. Use these alternatives:
5.1.5.1 GPS Format (Given-Person-Should)
“Given [clinical context], the [health worker role] should [specific action] to [health outcome].”
Example:
“Given a positive TB test result, the contact tracer should initiate household investigation within 48 hours to prevent secondary transmission.”
5.1.5.2 Service-User Scenario
A narrative vignette describing a patient’s journey through the system:
“Maria, a 45-year-old farmworker, visits a mobile clinic for diabetes screening. She speaks primarily Spanish and has no regular primary care provider. The system must support her preferred language, connect her to follow-up care, and track her screening results for population health reporting.”
5.1.5.3 Situational Protocol
Context-specific workflow tied to clinical guidelines:
“When a laboratory reports a confirmed measles case, the system shall generate a contact list and notify the assigned epidemiologist within 4 hours.”
5.1.6 The Logic Model as Requirements Framework
In public health, the Logic Model serves a similar purpose to a requirements specification. Understanding this mapping helps BA professionals communicate with PH colleagues:
flowchart LR
A[Inputs<br/>Resources] --> B[Activities<br/>What we do]
B --> C[Outputs<br/>Direct products]
C --> D[Outcomes<br/>Short-term]
D --> E[Impact<br/>Long-term]
| Logic Model Component | BA Equivalent |
|---|---|
| Inputs | Resources, Constraints, Assumptions |
| Activities | Functional Requirements, Use Cases |
| Outputs | Deliverables, System Features |
| Outcomes | Success Metrics, KPIs |
| Impact | Business Value, Strategic Objectives |
NoteCancerSurv Example
In CancerSurv, the Logic Model framing helped translate between teams:
- Input: Grant funding, registrar staff, hospital data feeds
- Activity: Case abstraction, data quality checks, interoperability
- Output: Complete case records, quality reports, data submissions
- Outcome: 95% data completeness, timely NPCR submissions
- Impact: Accurate survival statistics, targeted prevention resources
5.1.7 Data Standards as Requirements
In public health IT, data standards are non-negotiable requirements, not optional “technical details”:
| Standard | Purpose | BA Implication |
|---|---|---|
| HL7 | Messaging between systems | Define trigger events (e.g., “ADT A01, Admit Patient”) |
| FHIR | Modern API-based exchange | Specify FHIR Resources (Patient, Observation) |
| USCDI | Federal data interoperability | Required for ONC certification |
| ICD-10 / ICD-O-3 | Diagnosis coding | Validation rules in requirements |
| SNOMED CT | Clinical terminology | Concept mapping specifications |
| LOINC | Lab test coding | Interface specifications |
5.1.8 Data Architecture: Medallion Architecture for Public Health
Modern data platforms often use a medallion architecture, a design pattern that organizes data into progressively refined layers: Bronze, Silver, and Gold. Originally popularized by Databricks around 2020 for their “Lakehouse” architecture, the term uses the metaphor of precious metal refinement to represent the purification of raw data into actionable insights.
While the specific “medallion” terminology is relatively new, the underlying concept evolved from traditional data warehousing layers (staging → cleansed → presentation) used since the late 1990s. Although often discussed in cloud computing contexts, medallion architecture applies equally to desktop and local server environments.
WarningTranslation Required: Avoid ‘Medallion’ Jargon with Public Health Colleagues
The terms “Bronze,” “Silver,” and “Gold” layers are IT/data engineering jargon that will cause confusion when speaking with public health professionals. Most epidemiologists and program staff have never encountered this terminology and will not understand what you mean.
When working with public health clients, use familiar terms instead:
| Instead of saying… | Say this… |
|---|---|
| “Bronze layer” | “Raw data,” “source files,” “incoming data” |
| “Silver layer” | “Cleaned data,” “standardized data,” “processed data” |
| “Gold layer” | “Final reports,” “line lists,” “analysis-ready data,” “dashboards” |
| “Land it in Bronze” | “Store the raw file first” |
| “Promote to Gold” | “Move it to the final/reporting layer” |
Reserve medallion terminology for conversations with data engineers, IT architects, and other technical staff who share this vocabulary. The underlying concepts are universal; only the labels differ.
5.1.8.1 Mapping Medallion Layers to Public Health
The medallion layers map directly to standard stages of public health surveillance and clinical data management:
| Medallion Layer | Cloud Concept | Desktop/Local Equivalent | Public Health Equivalent | Practical Application |
|---|---|---|---|---|
| Bronze (Raw) | Data Lake, blob storage | Raw data folder, incoming file directory, source database tables | Ingestion / Source Systems | Original, unprocessed data from EHRs, medical devices, lab results, vital records, and external APIs |
| Silver (Cleansed) | Data warehouse staging, transformed datasets | Cleaned spreadsheets, normalized database tables, staging folders | Normalization / Harmonization | Standardizing data to common formats (FHIR, OMOP), de-identifying PHI for HIPAA compliance, harmonizing lab units and coding schemes |
| Gold (Curated) | Analytics layer, data marts, OLAP cubes | Final reports, pivot tables, analysis-ready datasets, exported summaries | Actionable Insights / Reporting | Line lists for contact tracing, outbreak predictive models, patient cohorts for research, operational dashboards, CDC/NPCR submissions |
TipDesktop Analogy
Think of medallion architecture like organizing files on your computer:
- Bronze = Your “Downloads” or “Inbox” folder with raw files exactly as received
- Silver = A “Working” folder where you’ve cleaned up, renamed, and standardized files
- Gold = Your “Final Reports” folder with polished, ready-to-share documents
Even an Excel workbook can implement this pattern: raw data on a “Source” tab (Bronze), cleaned data on a “Processed” tab (Silver), and summary tables/charts on a “Dashboard” tab (Gold).
5.1.8.2 User Roles by Layer
Different team members interact with different layers based on their roles and responsibilities. In well-resourced organizations, distinct roles handle each layer; in smaller programs, a single person may be responsible for all three.
Who Creates Each Layer?
| Layer | BA/IT Role (Creates) | Public Health Role (Creates) |
|---|---|---|
| Bronze | Data engineers, ETL developers, integration specialists | Data managers, IT staff, interface analysts |
| Silver | Data engineers, data analysts, data quality specialists | Epidemiologists, data quality analysts, cancer registrars |
| Gold | BI developers, analytics engineers, data scientists | Epidemiologists, biostatisticians, program analysts |
Who Consumes Each Layer?
| Layer | BA/IT Role (Consumes) | Public Health Role (Consumes) |
|---|---|---|
| Bronze | Data engineers (for troubleshooting), compliance/audit teams | Data managers (validation), security officers, auditors |
| Silver | Data analysts, data scientists (for detailed analysis) | Epidemiologists (case-level analysis), registrars, researchers |
| Gold | Executives, business users, ML engineers (for models) | Contact tracers, program managers, leadership, partner agencies, the public |
WarningReality in Resource-Constrained Settings
The role separation above represents an ideal state. In many public health settings, particularly local health departments or small programs, a single epidemiologist or data manager may be responsible for all three layers: receiving raw data files (Bronze), cleaning and standardizing them (Silver), and producing reports and line lists (Gold).
This is common and acceptable. The medallion architecture is a logical framework, not an organizational mandate. What matters is maintaining the conceptual separation of data stages, even when one person performs all the work. This separation enables:
- Clear documentation of what transformations occurred
- Ability to reprocess from raw data if errors are discovered
- Easier handoff if responsibilities change
5.1.8.3 What Layer Does a Line List Belong To?
A line list, the tabular record of cases used for outbreak investigation and contact tracing, is a Gold layer artifact. Here’s why:
- It serves a specific operational purpose (contact tracing, outbreak response)
- It draws from cleansed, deduplicated Silver layer data
- It is structured for end-user consumption by epidemiologists and contact tracers
- It represents a curated, analysis-ready dataset rather than raw source data
The raw lab reports and case notifications are Bronze; the standardized, deduplicated case records are Silver; the line list exported for the contact tracing team is Gold.
5.1.8.4 Strategic Benefits for Public Health
- Improved Data Quality and Trust
-
Each layer acts as a governance checkpoint. Data in the Bronze layer may contain duplicates, inconsistencies, and errors. By the time data reaches Gold, it has been validated, deduplicated, and enriched. This is critical for clinical decision-making and regulatory reporting.
- Security and Compliance
-
The layered architecture supports role-based access control. Data engineers may access Bronze (raw PHI for integration work), while analysts work primarily in Silver (de-identified or limited datasets), and program staff view only Gold (aggregated, anonymized dashboards). This minimizes unnecessary exposure of sensitive patient information.
- Scalability for Outbreak Response
-
The architecture handles varying data volumes, from routine surveillance to pandemic surge. Bronze ingests high-velocity real-time streams; Silver performs complex transformations at scale; Gold delivers rapid insights to decision-makers.
NoteCancerSurv Example
In CancerSurv, the medallion architecture maps to existing workflows:
- Bronze: Raw HL7 messages from hospital pathology systems, vital records death certificates, lab reports
- Silver: Deduplicated patient records, standardized ICD-O-3 codes, NAACCR-compliant case abstracts
- Gold: Annual incidence reports for NPCR, survival analysis dashboards, geographic cancer cluster maps for epidemiologists
TipTranslation Tip
When a data engineer says “we need to land this in Bronze first,” they mean the data should be ingested in its raw form before any processing. This is equivalent to a public health analyst saying “we need to see the source data before any transformations.”
5.1.9 Quick Reference Card
For easy access during meetings, here are the most commonly needed translations:
| When they say… | They might mean… |
|---|---|
| “What’s the user story?” | “What is the service-user scenario or clinical workflow?” |
| “Let’s do a sprint” | “Let’s run a PDSA cycle” |
| “What are the NFRs?” | “What are the implementation characteristics?” |
| “Stakeholder meeting” | “Community partner engagement session” |
| “Business case” | “Public health challenge / needs assessment” |
| “Acceptance criteria” | “Evaluation protocol measures” |
| “Technical debt” | “System sustainability issues” |
| “MVP (Minimum Viable Product)” | “Pilot intervention” |
| “Land it in Bronze” | “Ingest raw data before any processing” |
| “Promote to Gold” | “Data is ready for reporting and analytics” |