A clinical protocol is a program that has never been compiled

It is three in the morning in a district hospital and the resident on call has a laminated card in the pocket of her coat. The card says that if the lactate is above four, or the pressure is low, she is to give thirty millilitres of crystalloid per kilogram. It says to remeasure the lactate within two to four hours if the first one was above two. It says that if the pressure stays below a mean of 65 after the fluid, she is to start a vasopressor¹. She has read it a hundred times. Tonight she is reading it against a 54 kilogram woman with a lactate of 4.6, a pressure she has already checked twice, and a pump she has to programme herself.

Look at what the card is. It is a conditional. Inside the conditional there is a loop with an exit condition. There is a lookup against body weight, a threshold comparison, a timed reassessment and a branch. Every element of it has a name in computer science. None of it has ever been run by a computer. The resident is the interpreter. She is executing the program by hand, from memory, at the hour of the night when interpreters make the most mistakes, and she is doing it while she does everything else.

You carry the same thing: the vancomycin nomogram taped above the pharmacy hatch, the Child Pugh table on the hepatology ward, the insulin sliding scale on every surgical bed. Clinicians have been writing formal logic for decades. They write it in tables and flowcharts and sentences with the word if in them, and then they run it on themselves.

1The same protocol in five places

A program that only exists on paper has a specific failure mode. It gets copied, and the copies drift. The sepsis bundle on the resident's card is also an order set in the electronic record, a version in the consultant's memory, a column in the pharmacist's spreadsheet and a checklist on the audit form. The team cannot line the five of them up to see where they disagree (the audit form, which exists to catch this, is itself one of the five). The guideline that produced the card is itself a program of recommendations with strengths and qualities of evidence attached. Thirty millilitres per kilogram within three hours is a weak recommendation on low quality evidence. Antimicrobials within an hour of recognising septic shock is a strong one². By the time it is laminated, the weights have fallen off and only the thresholds survive.

The drift has been measured. When twelve published intensive insulin protocols were applied to a single hyperglycaemic patient, the recommended dose ranged from 27 to 115 units, a mean of 66.7 with a standard deviation of 27.9³. The same inputs, the same intent, a four fold spread in the output. A systematic review of twenty four glucose control protocols found that they differed in target range, in titration method and in how often the glucose was to be checked⁴. The dynamic protocols using the last two glucose values performed best. That is a statement about an algorithm. It was reached by reading twenty four prose documents side by side, because there was no other way to compare them.

Order sets, which are supposed to be the executable form, drift just as far. Fifty one hospitals in Washington State were scored on their sedation order sets against the twenty one elements of the guideline they were built from⁵. The scores ran from 0 to 19, with a median of 8. In a library of 289 alcohol withdrawal order sets from 95 organisations, a risk assessment for severe withdrawal was present in 34 percent, escalation criteria in 63 percent, and the definitions of both were inconsistent across the sets⁶. When the order set is used it helps. Across 104,662 sepsis patients in 54 hospitals the set was used in 55.5 percent of cases, and those patients had a shorter time to antibiotics, 125 against 179 minutes, with an adjusted odds of death of 0.70⁷. Four in nine patients never had the program run at all.

This is exactly why bundle compliance figures look the way they do. Across 1,794 patients in 62 countries, the three hour bundle was completed in 19 percent of cases and the six hour bundle in 36 percent⁸. Finishing them was associated with lower mortality, 20 against 31 percent. Over 29,470 patients and seven and a half years, hospitals with high adherence to the resuscitation bundle had a mortality of 29.0 percent against 38.6 percent at low adherence sites⁹. The program works when it runs. It mostly does not run, because the interpreter is a person with twenty other things to do.

Even the arithmetic is unsafe by hand. In an ambulatory chemotherapy service, 3 percent of 10,112 orders contained a medication error¹⁰. Of the adult errors, 82 percent had the potential for harm, and only 45 percent of the potentially harmful ones were intercepted before they reached the patient. Chemotherapy dosing is a function of body surface area, renal function and a lookup table. It is a program. It was being run on paper.

2Thirty years of compilers that never shipped

Informatics noticed all this a long time ago and did the obvious thing. It built languages. Arden Syntax was standardised in the 1990s for encoding medical logic as modules a hospital could share¹¹. The modules did not travel. Every query for patient data inside an Arden module was written ad hoc, inside curly braces, in whatever form the local hospital's database required. An analysis of 488 queries across 104 modules at one institution found that this nonstandard representation was exactly what impaired sharing¹². The logic was portable. The data was stuck where it was. Basically a protocol without data is a card.

The field kept trying. Asbru gave guidelines a time oriented skeleton with intentions and plans¹³. PROforma defined a process modelling language with formal operational semantics¹⁴. GLIF3 was published as a sharable representation and, in its own authors' words, ready for broader experimentation and prototype use¹⁵. When six of these models were made to encode the same two guidelines, they agreed on how to organise a plan and disagreed on decision models, goals, scenarios and structured actions¹⁶. Then came a twelve step method for marking up a guideline document, disambiguating it, and extracting executable rules¹⁷. The decade turned. By 2013 a methodological review was cataloguing modelling languages, execution engines, exception handling and the implementation barriers between them¹⁸. By 2018 the field's own leaders were writing that clinical decision support had been developed for over five decades and still lacked wide adoption. They blamed weak leadership, unclear purpose, inattention to workflow, and proprietary systems that could not talk to each other¹⁹. The newest attempt expresses measures in CQL against FHIR data, and the published work is still at the proof of concept stage²⁰.

Why did none of it stick? Read the languages and the answer is on the page. Each of them was designed for the informatician who would encode the guideline on the clinician's behalf. The clinician was the subject matter expert, interviewed and then dismissed. Every language asked her to learn the computer's vocabulary before she could write down what she already knew. Her card needed no vocabulary at all. The card won every time, because the card could be read at three in the morning.

3What happens when the logic runs

When the program does run on a machine, the effect is real and it is modest. Both halves of that matter. Across seventy trials, decision support significantly improved clinical practice in 68 percent²¹. Of the 32 systems that delivered support automatically, inside the workflow, at the time and place of the decision, with a recommendation attached, 30 improved practice. Across 122 trials and 1.2 million patients, the absolute improvement in the proportion of patients receiving the intended care was 5.8 percent²². The top quartile of systems achieved between 10 and 62 percent. The clinical endpoints moved by a median of 0.3 percent. That is what the logic looks like when it executes: a reliable few percent, and occasionally a lot. I will be plain about the limit here. Those trials measured process. The gap between a process improving and a patient surviving is wide.

The failure mode is also known. When the executable protocol is reduced to a popup, clinicians override it between 49 and 96 percent of the time²³. Acceptance falls by 30 percent with every additional reminder in the same encounter²⁴. An alert is what you get when the protocol's output is delivered without its reasoning. The resident ignores it for the same reason she trusts the card. The card shows its logic. The popup hides it.

Put those findings together and the specification writes itself. The protocol must be written by the person who owns it, in her nouns. It must execute automatically, at the bedside, with its reasoning visible. It must be in a form that two hospitals can compare line by line, so that the four fold spread in insulin dosing becomes a diff. The units must be checked, because a program that lets milligrams be compared with millimoles is a program that will one day do it. The same conclusion has been reached independently in veterinary medicine. A domain specific language was built there so that the clinicians themselves, and no longer the coding experts, could write the protocols for chronic kidney disease in cats²⁵. The nouns had to be the clinician's nouns. That was the whole design.

4A language whose nouns are the clinician's nouns

This is what MOISSCode was built to be. It is an open source language in which a protocol is declared as a protocol, takes a patient as its input, and is written in the vocabulary of the card: if the lactate is above four, administer fluids, alert the team, track the lactate. Units are part of the type system, so a pressure cannot be compared with a mass and the program will refuse to run until the mistake is fixed. A protocol reaches a validated score, a drug, a laboratory panel or a device by name, the way a clinician has always referred to them. The bundle from the resident's card, written in it, is a dozen lines. Those dozen lines can be diffed against the next hospital's dozen, which is the comparison the laminated card never allowed.

protocol Hour1Bundle {
    input: Patient p;

    track p.lactate using KAE;

    if p.lactate > 4.0 or p.bp < 65 mmHg {
        administer Fluids dose: 500 mL;
        alert "Sepsis bundle: fluids started" severity: high;
    }

    if p.bp < 65 mmHg {
        administer Norepinephrine dose: 0.1 mcg/kg/min;
        alert "MAP below target after fluids" severity: critical;
    }
}

A language does not validate a protocol. What it does is make the protocol legible enough to be argued with.

5The interpreter in the building

Go back to the resident at three in the morning. She has protocols. She has evidence that they work when they are followed, because the bundle papers show the mortality difference plainly. What she lacks is an interpreter. The card cannot check her arithmetic. It cannot remind her at the two hour mark. It cannot tell her that the version she memorised last year was revised in March. Tomorrow it will not be able to show the audit team which branch she took and why. It is a program with no runtime. She is the runtime.

The protocols were always code. They were just being run on the most expensive and least reliable interpreter in the building.