Forem: Monfort Brian N.

Healthcare Systems Aren’t Broken. They’re Fragmented.

Monfort Brian N. — Tue, 19 May 2026 14:50:18 +0000

Part 1 of an ongoing series on OSS interoperability layers, workflow architectures, and automation pipelines I've been building.

Over the past several months, I've been studying how real-world healthcare systems actually operate beneath the dashboards, reports, and interfaces.

One thing became very clear:

Most healthcare systems aren't failing because the software is missing. They're failing because the software ecosystems don't work together.

The invisible operational chaos

From the outside, many national and regional healthcare systems look digitally mature. You'll commonly find:

DHIS2 for national reporting and analytics
OpenMRS/ OpenClinic for clinical records
RapidPro for messaging workflows
SMS gateways and mobile reporting systems
Laboratory information systems
Surveillance dashboards
Community reporting channels

On paper, this looks modern.

But inside operations, a different reality appears

Data gets entered multiple times across disconnected systems
Reporting chains still depend on Excel handoffs
Surveillance workflows run on delayed batch syncs, not real-time streams
Manual validation loops eat operational time
Alerts exist but aren't wired to a specific response action
Lab systems don't automatically update surveillance platforms
Field teams re-enter data manually into centralized dashboards

The systems exist. The orchestration layer doesn't. [1]

Research on integrated care systems consistently shows this isn't a technology gap; it's a coordination failure between tools built in isolation. [2]

What Rwanda's eIDSR quietly revealed

One of the most instructive examples I found was Rwanda's electronic Integrated Disease Surveillance and Response system(eIDSR) built on DHIS2.

The system is genuinely impressive. It captures disease surveillance data in near real-time, generates outbreak alerts, and supports epidemic response coordination.

But what stood out wasn't the technology.

It was what the implementation documentation openly acknowledged. [3]

Even after successful deployment, the system still faced:

Interoperability friction with laboratory systems
Fragmented reporting workflows at the facility level
Follow-up on data inconsistencies
Excessive manual validation steps
Disconnected response tracking; alerts without linked actions
Operational burden on frontline workers

In other words, even a strong digital health system struggles when workflows remain fragmented across disconnected operational layers.

That's not a software problem. That's a systems integration problem.

The real problem isn't data collection

Healthcare has no shortage of tools. The real bottleneck is what happens between them.

Most operational inefficiencies happen at the seams:

Between labs and surveillance systems
Between clinics and reporting layers
Between field workers and centralized dashboards
Between alerts and actionable response workflows

When systems don't talk, humans fill the gap. Clinicians, data clerks, and coordinators become what I'd call the "human API layer" manually moving information between disconnected platforms.

At scale, that creates invisible operational load: [1]

Transcription errors
Duplicated effort
Delayed surveillance loops
Incomplete follow-ups
Reporting fatigue
Inconsistent decision signals

What I started building

This is where my work began, not replacing existing systems, but building the orchestration layer that makes them work as one.

The stack I'm working with:

OpenMRS · DHIS2 · RapidPro · Africa's Talking
Custom n8n nodes as the workflow bridge
Event-driven routing replacing batch sync
FHIR-normalized data before it hits the orchestration engine
Reusable interoperability pipelines for fragmented environments

The shift in practice looks like this:

A real workflow walkthrough is coming in the next post.

Not because people worked harder. Because the systems stopped fighting each other.

Beyond healthcare

Healthcare is the first domain I'm exploring publicly, but the same fragmentation patterns appear across:

Fintech for fragmented payment settlement workflows
Agriculture for siloed field data and supply chain reporting
Logistics for disconnected supply chain visibility layers
Public sector operations ....

Different industries. Same orchestration problem.

Why OSS matters here
These ecosystems already run on open-source infrastructure. That's the advantage because it means interoperability doesn't have to be locked behind expensive proprietary middleware.

With open tools, we can build:

Reusable connectors between platforms
Shared workflow architectures
Event-driven automation layers
Interoperable public infrastructure
Africa-first operational systems designed for real constraints

That's the part that genuinely excites me.

Final thought

Systems thinking isn't about building more dashboards. It's about reducing the invisible friction between the platforms we already depend on.

Sometimes the biggest innovation isn't a new platform. It's finally making existing platforms communicate properly.

From Operations to Insight: Designing a KPI Layer for Banking Performance

Monfort Brian N. — Tue, 03 Feb 2026 23:24:31 +0000

Most systems in banking are built to run operations, not to explain them.

They process transactions, manage queues, and keep branches moving. But when leadership asks simple questions: What’s happening right now? Where are we losing time? Which branch is underperforming today? those systems rarely have answers ready.

This is the gap.

Not a lack of systems.
Not a lack of data.
But a lack of decision-ready metrics.

This project focused on closing that gap inside a retail banking environment without replacing any system, and without relying on APIs.

The Gap Between Activity and Understanding

At branch level, everything was active:

Customers taking tickets
Staff serving continuously
Services being delivered across counters

Data was being generated all day.

Yet operational teams were still:

Reviewing performance at the end of the month
Working with static Excel exports
Reconciling inconsistent figures
Making decisions without current visibility

The system was optimized for transactions.
The business needed it to be optimized for understanding.

The Constraint

The Queue Management System (QMS) was operationally reliable, but analytically limited:

No usable API
No structured data access
Export formats inconsistent
No direct link between system outputs and business KPIs

This wasn’t a tooling issue, it was a modeling problem.

The Shift: From Extraction to Interpretation

Instead of forcing deeper integration, the approach changed:

Don’t change the system.
Change how it's data is interpreted.

The goal became clear:

Design a KPI layer that translates operational data into consistent, decision-ready metrics automatically.

Architecture Overview

A lightweight, fully automated pipeline was designed to sit on top of the existing system.

1. Data Acquisition Layer

Rather than relying on unstable exports, the system was used as the entry point.

A scheduled automation:

Accesses the system daily
Extracts two structured datasets [Staff and Service activity]
Stores them securely in a raw data zone

No manual effort.
No dependency on internal system changes.

The most reliable integration is often the one that works with the system, not against it.

2. KPI Transformation & Modeling Layer

This is where the system becomes useful.

Two datasets, each partial on their own [Staff-level activity and Service-level transactions]

Combined, they form the foundation of operational intelligence.

Inside this layer:

Data is standardized and cleaned
Time values are normalized
Datasets are aligned and combined
Metrics are aggregated
KPIs are computed using business rules
Missing insights are reconstructed through derived logic

This is not traditional ETL, it is a KPI modeling engine.

Designing the KPI Layer

Not all metrics come directly from the system.

They fall into two categories:

Direct Metrics (Immediately available)
Derived Metrics (Reconstructed through logic)

The Unified KPI Dataset

The output is a single, structured dataset designed for immediate use.

It includes:

Operational volumes
Time-based performance metrics
Service and staff indicators
Pre-computed KPIs

No raw fields. No ambiguity. No recalculations in BI tools.

3. Distribution Layer

Once validated, the dataset is automatically delivered to analytics tools.

Scheduled refresh
No manual handling
Direct dashboard consumption

By the start of each day:

KPIs are current
Dashboards reflect real activity
Teams operate with clarity

What Changed

Before:

Delayed reporting cycles
Fragmented metrics
Manual data preparation
Limited operational visibility

After:

Daily KPI availability
Consistent definitions
Fully automated pipeline
Real-time branch performance visibility

The system didn’t change.
The visibility did.

Why This Matters

This pattern extends beyond banking.

Insurance, Telecom, and Public systems face the same challenge:

Systems generate data BUT they don’t generate insight.

By introducing a KPI layer:

Data becomes decision-ready
Performance becomes measurable in real time
Bottlenecks become visible early
Operations become proactive

Final Thought

Operational excellence doesn’t start with dashboards.

It starts with designing the layer that makes those dashboards meaningful.

You don’t need perfect systems.
You need a reliable way to translate what they produce into what the business needs to see.

Because you can’t improve what you can’t see and you can’t see it if your data arrives too late.