Link v1.0 — a facility workbench, not another EMR

There are too many electronic medical records in health systems and not enough tools that clinicians actually want to use. We set out to build something different.

Link is not a comprehensive EMR. It's a workbench — a practical tool for the clinical team at a facility to manage a patient encounter from arrival to discharge, make better decisions along the way, and close the loop with follow-up and reporting.

What we left out

The easiest way to describe Link is to start with what it's not.

Link doesn't manage patient billing or insurance. In Ethiopia, most facilities are public and don't do complex billing. Adding billing logic to the system just slows it down. If a facility needs billing later, that integration can be added. But we didn't build it into v1.0.

Link doesn't manage lab operations, supply chain, or pharmacy stock. Those are important, but they're not core to the clinical encounter. ForLab+ already handles supply chain. Labs and pharmacies have their own workflows. Link integrates with them but doesn't own them.

Link doesn't support complex customization or configuration. Every health system wants to customize EMRs to their specific workflow. That's reasonable, but it's also expensive and creates fragmentation. Link follows a single clinical workflow designed around how Ethiopian health facilities actually work. We accept that some sites will find it rigid. Most will find it faster to learn and use.

Link doesn't aggregate data across multiple facilities or produce complex population health analytics. Those are valuable, but they're not the priority for v1.0. A facility workbench is local by definition. Analytics can wait.

What we built

Link has 15 modules organized around the flow of a clinical encounter:

**Intake and triage.** Registration, vital signs, chief complaint, basic screening.

**Assessment.** Clinical examination, history, relevant lab or imaging findings.

**Decision support.** 200+ diagnostic algorithms covering common primary care conditions. The system presents diagnostic probabilities and treatment recommendations but never prescribes. The clinician decides.

**Documentation.** Diagnosis, risk stratification, treatment plan.

**Pharmacy.** Prescription entry, drug interaction checking, dispensing verification.

**Follow-up.** Referral, appointment scheduling, outcome tracking at next visit.

**Offline operation.** Every module works without internet. Data syncs when connectivity is available.

This is intentionally tight and linear. A clinician comes in, sees a patient, moves through the modules in sequence, and has a complete record and plan at the end. No hunting for information across tabs or systems.

Why offline matters

Offline capability is not a feature in the way that dashboards or customization are features. It's foundational. If Link only works online, then a facility on spotty internet can't use it. It becomes a system for two or three urban hospitals, not a facility workbench.

Going offline-first changes everything. It means the entire system has to work locally. No cloud, no API calls, no sync complications. The database lives on the facility's server. When the facility has internet, data syncs to the central system. When they don't, Link keeps working.

This also aligns with our commitment to data sovereignty. Ethiopian patient data lives in Ethiopia, on a facility's network, not in a cloud provider's infrastructure on someone else's continent.

The hard design choice: what makes a clinician trust a system

The hardest part of building Link was not the technical architecture or the decision support algorithms. It was this question: When a clinician sees something on the screen, do they believe it?

Many EMRs fail at this point. They're full of features that "should" be useful but don't earn trust because they're slow, inaccurate, or get in the way of the actual clinical decision.

We spent months with clinicians at pilot sites just watching them work. What information do they actually need? When? How do they respond to decision support? Do they override it, and when? Do they use it as a thinking tool or as a final answer?

From that, we built Link on a principle: the system provides evidence and options; the clinician decides. We don't tell a clinician they "must" do something. We show them the algorithms recommend certain actions based on the patient's presentation and the evidence base. Then they use their judgment.

This is harder to build than a prescriptive system, but it's what makes clinicians trust it. They're in control.

Last reviewed: March 2026