PulseLink

Event-driven, offline-first healthcare system that converts patient data into real-time outbreak, workforce, and supply intelligence for frontline health response.

Comment

Inspiration

Every year, 2.5 million avertable deaths occur in Africa and other low-resource areas due to fragmented, delayed, and disconnected healthcare data systems. Furthermore, over 60% of health facilities in Africa continue to use paper-based records, directly leading to the aforementioned issues.

These numbers aren't just statistics, they represent real people whose outcomes are shaped by how quickly and effectively healthcare systems can respond. But without any effective systems in place to facilitate care-- both on the CHW and patient side-- that help could never arrive.

And so, PulseLink was inspired by this gap between ground-level health signals and real-time operational response. We wanted to build a system where patient data immediately translates into actionable intelligence for NGOs and community health workers, even in environments with limited connectivity.

What it does

PulseLink is a unified, offline-first healthcare intelligence system that connects patient reporting, outbreak detection, workforce coordination, and supply logistics into a single real-time operational network for NGOs and community health workers.

At the core of the system is a patient intake workflow where community health workers or field users submit structured symptom reports. Each submission captures key information such as symptoms, duration, location, and basic patient metadata, which is then converted into a standardized patient record. From there, the system immediately assigns a risk score and adds the patient into a shared regional surveillance dataset.

As more patients are added, PulseLink continuously analyzes incoming data through a real-time outbreak detection layer. This layer compares recent case activity against historical baselines to identify abnormal spikes in specific regions, automatically flagging potential outbreak zones and assigning severity levels based on case concentration and risk.

In parallel, the same dataset feeds into a workforce coordination system that tracks community health worker capacity. Each region is evaluated based on active patient load, allowing the system to identify overloaded areas and highlight where additional field support may be needed.

At the same time, PulseLink monitors vaccine availability and medical supply status across regions. It tracks stock levels, expiry conditions, and cold-chain safety, then combines this with patient demand and outbreak severity to calculate supply pressure in real time. This ensures that regions with rising cases and limited resources are prioritized for resupply.

All of these signals are brought together in an AI decision engine that doesn’t rely on external models, but instead uses deterministic, explainable logic. It combines outbreak trends, workforce constraints, and supply conditions to generate operational recommendations that are fully traceable back to visible system inputs.

Finally, because the system is designed for low-connectivity environments, all of this runs offline-first. Data is stored locally, actions are queued when offline, and synchronization happens automatically when connectivity is restored, ensuring the system stays functional in unstable field conditions.

How we built it

We built PulseLink as a local-first web application using React and TypeScript, structured around one simple idea: every piece of intelligence in the system should come from a single shared source of truth, the patient data.

On the frontend, we used React to build the main dashboards for patient intake, surveillance, and NGO coordination. TypeScript runs across the project to keep everything consistent, especially for core data like patients, vaccines, regions, and CHW assignments. This helped prevent inconsistencies as the system grew and more modules started interacting with the same data.

Instead of building isolated features, we designed PulseLink around an event-driven flow. Every time a patient is added, that single action triggers updates across the rest of the system. It feeds into outbreak detection, updates CHW workload in that region, adjusts supply pressure, and informs the AI decision engine. So instead of separate features working independently, everything reacts to the same underlying data in real time.

For the map, we used Leaflet to visualize patient distribution across Africa. Each marker is generated from live patient data and changes based on risk level, so users can immediately see where pressure is building geographically instead of interpreting raw tables or charts.

A lot of the “intelligence” in the system is built using deterministic logic rather than external AI models. Outbreak detection compares recent case activity against historical baselines, CHW workload is calculated from active patient counts per region, and supply pressure combines demand, outbreak severity, and workforce load into a single score. The goal was to keep everything explainable and predictable.

We also designed the system to work fully offline. All data is stored locally using LocalStorage, so the system doesn’t break without internet. On top of that, we built a sync queue that stores actions while offline and automatically synchronizes them when connectivity returns.

For visualization and usability, we used Chart.js for outbreak trends and Framer Motion for smoother transitions between states, especially during simulations or live updates.

Overall, what we built isn’t a collection of separate features, it’s one connected system where every action flows through the same data pipeline and updates everything else automatically.

Challenges we ran into

One of the biggest challenges I ran into wasn’t on the coding side, but on the presentation and delivery side of the project.

As the sole developer of PulseLink, I wasn’t just responsible for building the system, I also had to design, structure, and present the entire demo under strict time constraints.

Since this was my first hackathon, I didn’t have much experience balancing depth with timing or structuring a live demo in a way that felt both complete and concise. A lot of the challenge came from figuring out how to explain a fairly complex system with multiple interconnected parts without losing clarity or going over time.

On top of that, recording the demo took multiple iterations. I had to refine pacing, cut sections that were too detailed, and restructure the flow so each feature could be shown clearly without breaking the overall narrative. A small timing issue in one section often affected the rest of the recording, which made consistency harder than expected.

There was also a constant tradeoff between showing enough technical depth to be credible and keeping the demo understandable for judges in a limited timeframe. That balance ended up being one of the hardest parts of the entire project.

In the end, this part of the process taught me just as much as the technical build itself, especially around communication, prioritization, and how to present complex systems clearly under pressure.

Accomplishments that we're proud of

One of the main things I’m proud of is that PulseLink ended up being a fully connected system rather than a collection of separate features. From a single patient input, the platform updates outbreak detection, CHW workload, supply pressure, and decision support in a coordinated way.

I’m also proud that we built a system that behaves like a real operational tool for NGOs, not just a demo interface. The Africa map, outbreak detection layer, workforce tracking, and supply monitoring all work together in real time to reflect what’s happening across regions.

Another key accomplishment is that we built a deterministic, explainable decision engine without relying on external AI models. Every recommendation is derived from visible inputs like patient risk, outbreak trends, CHW capacity, and supply constraints, which makes the system transparent and traceable.

We also successfully implemented a full offline-first architecture. The system continues working without internet, with local storage handling all core data and a sync queue managing updates when connectivity returns.

Finally, I’m proud that I was able to build and deliver the entire project independently while also handling design and presentation under time constraints. For a first hackathon, bringing together system design, implementation, and communication into a cohesive product was a significant learning experience.

What we learned

Before this project, my experience was mostly limited to Python, and I had very little exposure to TypeScript or full-scale web application design. A lot of what went into PulseLink required learning as I built, not just new tools, but also how to think in terms of complete systems rather than individual features.

On the technical side, I learned how important it is to design around data flow instead of isolated components. Building PulseLink forced me to think carefully about how a single input, a patient report, can propagate through multiple interconnected systems like outbreak detection, workforce tracking, and supply pressure without breaking consistency.

I also learned how powerful local-first and event-driven design can be in real-world applications. Instead of relying on external infrastructure, I had to design a system that could continue working offline while still behaving like a live intelligence platform. That shifted how I think about reliability and system constraints.

But beyond the technical side, the biggest shift was perspective.

While building PulseLink, I started to better understand what it actually means to design for low-resource healthcare environments. Constraints like limited connectivity, delayed reporting, and fragmented systems aren’t edge cases, they are the default in many real-world settings. That changed how I approached every design decision.

I also learned how important communication is when building systems like this. Even if something is technically strong, it only becomes meaningful if it can be clearly explained to the people using it.

Overall, this project taught me that building software in healthcare isn’t just a technical challenge. It’s a balance between clarity, reliability, and real-world constraints, and that balance matters just as much as the code itself.

What's next for PulseLink

The next step for PulseLink is moving it from a strong prototype into something that can realistically operate in real-world NGO and healthcare environments.

One of the main priorities is deployment readiness. This includes adding authentication and role-based access so different users like community health workers, coordinators, and administrators can safely interact with the system. It also includes audit logs so actions can be tracked over time.

Another key area is data security and privacy. Since PulseLink handles sensitive patient information, future versions would include encryption and stronger privacy protections to ensure data is handled responsibly in real-world deployments.

From there, the focus would shift toward real-world connectivity. While the system is currently fully offline-first, a production version would integrate SMS or USSD reporting for low-tech environments, along with possible connections to real supply and logistics systems.

Another direction would be improving the intelligence layer over time. With more data, the system could evolve into stronger forecasting tools for outbreak trends and supply demand patterns, while still keeping outputs explainable.

Finally, there’s the broader challenge of real-world rollout, including deployment across regions, supporting offline devices, and coordinating multiple areas without losing data consistency.

Overall, the goal isn’t just to add more features, but to evolve PulseLink into a deployable public health tool that can operate reliably in the environments it was designed for.

Built With

Share this project:

Updates