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.
Where the code lives
github.com/sophronio
Our public organization on GitHub. Issues and pull requests are welcome on any repository.
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:
- 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.
- 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.
- 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.
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 →
Using one of these?
Open an issue on the repository if something is broken or missing. For engagements built on this work — record linkage, data modernization, or anything else in the same neighborhood — talk to us through the main company site.
