Not everything we build stays on a client’s network. When a tool turns out to be useful beyond the engagement that produced it, we put it on GitHub so other teams can use it, read it, or argue with it — and when our machines are idle, we lend the cycles to science.

Project · R · MIT

SLINK

SLINK is an R package that puts a graphical interface on probabilistic record linkage. It wraps the fastLink algorithm so that the people who actually own the data — epidemiologists, analysts, program staff — can run a linkage themselves without writing R.

The problem it solves is a familiar one in public health and any other field that accumulates records from more than one system: you have two datasets that describe overlapping populations, no shared key, and names that are spelled three different ways. Deciding which row in one file is the same person as a row in the other is a statistical judgment, not a join.

SLINK structures that judgment as three stages:

1. Configure. Upload two datasets with matching column structures, choose which columns to compare, and pick a comparison strategy per column — exact, partial, string-distance, gender, or numeric. Set the probability threshold and, where relevant, the string-distance cut points.
2. Review. The algorithm proposes candidate matches; a human accepts or rejects them, in bulk where the evidence is clear. The reviewer stays in the loop precisely because the threshold is a choice, not a fact.
3. Results. Six datasets come out the other side: the two inputs as given, the matched records from each, and the unmatched records from each — filterable and downloadable. The unmatched sets matter as much as the matches; they are where the data quality problems are hiding.

sophronio/SLINK on GitHub →

---

Project · JavaScript · Node.js

DB Viewer

DB Viewer is a small client/server application that lets the people who own a dataset make their own changes to the tables that hold it, without handing them a database client or building a bespoke admin screen for every table.

It exists because of a pattern we kept running into: a reference table — a code list, a facility roster, a set of thresholds — that changes a few times a year and is owned by someone on the program side, not the engineering side. The options are usually bad. Either an engineer applies every edit by hand, which makes a two-minute change take a week, or the table gets its own custom CRUD screen, which is a week of work per table and another thing to maintain.

DB Viewer splits into a Node.js server that talks to the database and a browser client that renders whatever tables it is pointed at, so a new table is configuration rather than code.

sophronio/DBViewer on GitHub →