blog / § 03 · methods

What sociologists can learn from clinical trials

ALCOA+, audit trails, edit checks, queries, double data entry and database lock: what they are, and why they matter to qualitative and quantitative researchers alike.

In a clinical trial, an error in the data can cost someone their health: if the wrong blood pressure or the wrong dose ends up in the spreadsheet, the conclusion about the drug will be wrong. Over the decades, a whole culture of data handling has grown up there, with its own rules, roles and checks. From the outside, it looks like bureaucracy. From the inside, it is a set of habits that make it possible, years later, to answer the question “where does this figure come from?” from the records rather than from memory.

Sociological data is about people too. An error in it rarely kills anyone, but it quietly shifts the conclusions, and nobody notices. Below are six clinical practices that I think are worth bringing into sociology. Not wholesale, but in their logic.

ALCOA+: nine questions for any record

The acronym originated at the FDA, the US regulator, and has since acquired a plus. It reads well as a checklist of questions to ask of any record in a study:

Letter Requirement The sociologist’s question
A Attributable Who recorded, coded or corrected this?
L Legible Could I read it without the software I made it in?
C Contemporaneous Was it recorded when it happened, or reconstructed afterwards?
O Original Where is the source: the audio, the paper questionnaire, the first file?
A Accurate If it was corrected, can you see what changed and why?
C Complete Has anything gone missing without a trace?
C Consistent Are the same things recorded in the same way?
E Enduring Will the data survive to be reanalysed in ten years’ time?
A Available Can you quickly retrieve what you need when someone asks?

None of these points requires sophisticated technology. All that is required is that the answer to each question exists next to the data, not in someone’s head.

The audit trail: a memory that doesn’t lie

In a clinical trial, every change to a record leaves a trace: who, when, the old value, the new value, the reason. This is called an audit trail. The trace cannot be deleted; you can only add a new change on top.

Compare this with ordinary work in a spreadsheet. You replace “Manc” with “Manchester” in two hundred cells, and that’s it: the spreadsheet is clean, and the knowledge that it was ever messy is gone. For a single replacement, that doesn’t matter much. For forty replacements made by three people over six months, it is a different spreadsheet altogether, and nobody will be able to reconstruct where it came from.

The good news is that the log can be kept automatically. And if each entry also contains a fingerprint of the previous one (a hash chain), even an edit made directly in the database will show up.

Edit checks: catch the error while everyone still remembers

Edit checks are rules that fire at the moment of entry: an age of 214, an interview date in the future, more years in work than years alive. In clinical research they are written before the study begins, alongside the forms.

The key idea is timing. An error found on the day of entry is corrected by the person who had the questionnaire in their hands. An error found a year later, during analysis, has to be guessed at.

Queries: a question instead of a correction

When a clinical data manager sees an odd value, they don’t correct it themselves. They raise a query, a question to whoever entered the data: “Age 214 — a typo? Please check against the source document.” The answer and the correction are stored together with the question.

In sociology this carries over almost word for word. A coder reads “I arrived in 2009” in a transcript, but according to the questionnaire the participant was nine at the time: that is a question for the interviewer, not a silent fix. A transcriber has marked “[inaudible 00:14:32]”: that is a question for the person who conducted the interview and may remember. The difference is small but fundamental: the correction is made by the person who has grounds for it, and those grounds stay on record.

Double data entry: two people are better than one

In clinical trials, paper forms are often entered twice, by two people working independently, and the discrepancies are then checked against the paper. It is expensive, but the number of entry errors drops dramatically.

For three hundred paper questionnaires, that is a couple of extra days. In qualitative analysis this practice has long had a close relative: double coding and inter-coder agreement (Cohen’s kappa, for example). The logic is the same: one pair of eyes makes mistakes unnoticed; two pairs make them noticeable.

Database lock: the point after which nothing gets adjusted

Before analysis, a clinical database is “locked”: after the lock, changes are possible only through a documented unlock. This guards against the most human of temptations — tweaking the data once you have seen the result.

For a sociologist, a lock is not a ban on changing your mind. A qualitative codebook lives and changes, and that is fine. A lock fixes a moment: “chapter 3 was written on this data and this version of the rules”. If something changes later, the chapter at least knows what it was based on.

What is not worth importing

Clinical data culture grew up in a world of regulators, insurers and enormous budgets. Standard operating procedures for every action, a signature on every page, software validation at great expense: sociology does not need any of this and could not afford it anyway. What it needs is the logic: the source stays intact, changes are visible, decisions are explained, and data is checked early.

How it works in corpus

In corpus, these practices are built in so that you don’t have to remember them: the hash-chained activity log keeps itself, correcting a text creates a new version, and cleaning survey data means applying rules, each with a reason, on top of the raw responses. Edit checks, queries, double entry of paper questionnaires, source verification and data freeze before analysis are all part of the “checks and queries” module.