Throughout my career, I’ve watched brilliant teams stumble, not because they lacked expertise, but because they were speaking entirely different professional languages.
My formal training is in social sciences and public health, where business analysis concepts weren’t part of the curriculum. But my career path led me through various technical roles (working for technology companies and alongside them) where I absorbed the terminology, tools, software, and processes that business analysts and project managers use daily. This dual exposure showed me both the value and the difficulty of blending these perspectives.
2.1 The Translation Challenge
When I joined projects bridging IT and public health, I saw the same friction points repeatedly:
- Business analysts asking for “user stories” while epidemiologists stared blankly
- Developers requesting “non-functional requirements” while program managers wondered if that related to grant compliance
- Agile sprints clashing with PDSA cycles or action research, even though both are iterative improvement frameworks
- Stakeholder maps that missed community partners because they weren’t “decision-makers” in the traditional IT sense
The IT world optimizes for efficiency and profit. Public health optimizes for equity and outcomes. Both are rigorous disciplines with systematic frameworks. Yet when they collaborate, the translation gap creates delays, misaligned expectations, and sometimes outright project failure.
2.2 Lessons from Both Sides
I’ve experienced this challenge from multiple angles:
Introducing IT tools to public health teams. I’ve worked with groups who had strong public health backgrounds and wanted to streamline collaboration, tracking, and communication. I introduced project management software (including Azure DevOps, because it was the best tool available to us). But I ran into constant friction translating the software’s terminology (sprints, agile, user stories, backlogs) into concepts that made sense for public health professionals and their workflows.
Watching tech-dominated engagements produce suboptimal products. I’ve also seen the reverse: public health organizations relying heavily on technology vendors where the frameworks, project management styles, and terminology of business analysts dominated the engagement. The public health perspective got lost, and the resulting products didn’t fit how health departments actually operate.
2.3 Finding Common Ground
Bridgeframe exists because I needed it. Every time I translated a clinical workflow into a requirements document, or explained why a “user story” doesn’t capture a patient journey, I wished for a reference guide that mapped these concepts clearly.
This toolkit distills what I’ve learned from CDC surveillance systems, COVID-19 contact tracing implementations, tuberculosis intervention trials, and countless cross-functional team meetings. It’s designed for the health informatician sitting between two worlds: ensuring the IT team’s technical specifications align with the health department’s programmatic goals.
2.4 A Work in Progress
I want to be clear: I am not positioning myself as an expert on business analysis, and Bridgeframe is not intended as an authoritative guide. This is a draft that I will continue to develop and refine.
The examples throughout this book (including the CancerSurv case study) are illustrative and fictitious. They are designed to be relatable, to help professionals in both domains recognize common patterns and challenges. The intent is educational and informative.
My hope is that Bridgeframe stimulates discussion and points readers toward the established frameworks and resources that offer deeper expertise: BABOK for business analysis, CDC evaluation frameworks for public health, CFIR for implementation science, and the many other rigorous methodologies developed by true experts in these fields.
If this toolkit helps even a few teams find common ground, or sparks conversations that improve how we build health information systems, it will have served its purpose. I welcome feedback, corrections, and contributions as this resource evolves.
André van Zyl
Intersect Collaborations