As a dev, there is nothing I hate more than spreadsheets of "enterprise digital transformation" or 40-page PDFs of "perfect world" scenarios that sound smart in a meeting but totally lack actual logic.
We’ve all seen those requirements: "System should magically sync legacy data with the new cloud DB." That usually results in hours of Slack argument threads. ALL. DAY.
😫 Too many times, the BA writes the "dream," and the technical nightmares are left for the devs to figure out.
That was my baseline until I got pulled into a high-stakes HealthTech build with Mai Anh Le, our Lead BA at Sun*. After watching her navigate a cross-border EHR modernization project, I’ve had to completely rethink what a BA actually does.
👇 Here is what I learned from a global scaling EHR integration project with a BA who actually knew what "business logic" she needed to analyze and what requirements should be delivered to the tech team:
1. Map the physical user movement before designing the schema
I used to grab a ticket and start thinking about database tables immediately. But this time, I realized that in HealthTech, digitalization is a failure if it adds 30 seconds of friction to a doctor’s day.
Instead of jumping into system design, our BA made us spend the first two weeks mapping how work actually happens in a clinic. We traced every step—from a patient touching an IoT device to how that data hits a nurse's dashboard.
💡 If you don't understand the "day-in-the-life" workflow, you’ll build "clean code" for a theoretical flow that won't survive a "busy Tuesday" in a real clinic. Now, I don't touch a feature until I know why it exists in the physical world.
2.Clinical hardware defines the logic of the tech you develop
It’s a rookie mistake to assume you can build one "universal" ingestion engine. Every clinical device is its own isolated ecosystem with its own assumptions about data hand-offs.
With our BA's guidance, I learned that a neurology treatment plan isn't just "different data", it’s a different architectural requirement based on the specific hardware being used.
💡 Treating medical devices as generic inputs is the fastest way to accrue technical debt you can't pay back. We used HAPI FHIR, Node HL7, and RabbitMQ not just to move data, but to handle the unique "semantics" of each piece of clinical hardware.
3. Compliance is an architectural constraint, not a documentation task
"GDPR or HIPAA was just a checklist for the legal team ?". I was wrong. When scaling a healthcare service from one territory to another, compliance changes the very way you handle data provenance and storage.
Our BA approached compliance as a core product requirement. We embedded granular Role-Based Access Control (RBAC), encryption, and full audit trails directly into the system architecture from day one.
If you try to think compliance later, thank again. You'll for sure end up refactoring the entire core. To avoid this, she relied on a rigorous checklist I now use for every sprint:
- Who actually uses this system?
- Which stakeholders are involved at each step?
- Where does the data hand off?
- What does the receiving system actually expect?
4. Front-load the Analysis to Prevent 11th-hour Structural Rework
We had 60 days to launch a global EHR system across Europe and Asia.
We spent the first two weeks "quietly" mapping every handoff and system boundary. I thought we were losing time. I was wrong (for the second time). Because she locked the logic down early, our engineering team executed the build with nearly zero structural rework.
💡 Speed doesn't come from typing faster; it comes from not having to build the same feature twice. We launched on time because our foundation was solid, not because we rushed the implementation.
5. Use AI for fast research, but use human experience for risk mitigation
We used AI daily to summarize FHIR R4 guides, which boosted our research efficiency by about 70%. But I noticed a pattern: while AI gives you the answers, a Lead BA knows if you’re asking the right questions.
💡 AI is a powerful engine for information retrieval, but it is terrible at judging clinical risk. In high-stakes environments, you need a human who has seen how systems fail in the real world to decide which AI-generated suggestions are safe to implement.
Working with a Lead BA who understands systems thinking changed my perspective. A great BA isn't a "requirement gatherer"—they are a Strategic Risk Mitigator. When the BA handles the logic, we Devs can focus on building high-performance systems that actually change lives.
👉 Have you ever had a project saved (or ruined) by a BA’s logic? Let’s swap stories in the comments.
👉 Check out more insights in healthcare technology development here!
Top comments (0)