The Part Everyone Skips

Part 1 argued that national health records fail on architecture, not ideology — monoliths on a political clock lose, federated infrastructure wins. That’s the what.

This is the how, and it’s less interesting to argue about, which is exactly why it decides the outcome.

Here’s the uncomfortable observation about every program in Part 1: none of them failed for lack of money, executive sponsorship, or technical talent. HealthCare.gov had the full weight of a presidential priority. The NHS programme had £12 billion and a Prime Minister behind it. The VA’s vendor builds one of the two dominant health record platforms on earth and has done so successfully at hundreds of private health systems.

They failed at things that don’t photograph well: knowing what they were actually buying, deleting requirements that shouldn’t exist, and finding out whether anyone was really using the thing.

Step One Is Subtraction

I’ve done the requirements work on a public-sector health record procurement. Here is what that artifact actually looks like, and it generalizes across essentially every county and agency buying one.

The requirements worksheet runs north of 800 individual line items, spread across a dozen-plus functional areas: billing, registration, scheduling, case management, check-in/out, health information management, treatment planning, the clinical record itself, a patient portal, communicable disease tracking, plus general, technical, and interface sections. Each line gets a criticality — critical, important, desired — and each vendor must return a response code per line: in the current release, coming in a future release, possible with custom development, possible via a third party, or cannot be provided.

That structure is genuinely good. What happens inside it is the problem.

Working through a worksheet like that line by line, a large fraction of the items fall into four buckets that have nothing to do with what the organization needs:

1. Duplicates across tabs. The same capability appears in the technical section, the general section, and two functional sections, worded slightly differently each time. Role-based security gets specified five separate ways. Audit logging shows up in six. Nobody notices, because nobody reads 800 lines end to end — they read their tab.

2. Solution language masquerading as requirements. “The system must provide drill-down capability on all screens.” That’s not a need; it’s a guess at an implementation. It pre-selects a design, blocks a vendor who solved the same problem better, and is untestable as written — drill down to what, for whom, to accomplish what task?

3. Desktop-software fossils. Real examples of the genre: word-wrap in text fields without pressing return. Spell-check with an administrator-editable dictionary. Integration with the operating system clipboard. Support for dual monitors. These were meaningful discriminators in 2004. Today they either come free with any browser or they’re someone’s decade-old worksheet being copy-pasted forward, unexamined, into a contract.

4. Requirements with no test. “The system is intuitive.” “The system provides adequate reporting.” If you can’t write the acceptance step, it isn’t a requirement — it’s a hope with a checkbox next to it.

A disciplined pass deletes or merges a large share of an 800-line worksheet and rewrites much of the remainder into capability language. “Drill-down on all screens” becomes: a user viewing a search result can reach the underlying record and its attachments in one action, subject to their role permissions — testable, vendor-neutral, tied to an actual task.

This is the highest-leverage work in the entire program and it is nearly always done by whoever has spare capacity, or skipped in favor of pasting the last agency’s worksheet. It is a specialist skill. It should be a named role with a budget line.

Requirements Are Contract Terms, and Almost Nobody Uses That

Buried in the instructions of a well-built procurement worksheet is a sentence with enormous latent power: proposers who state that a function is available are contractually obligated to warrant that claim, and are liable for the cost of developing or procuring it if it turns out not to exist.

Think about what that means. Every “1 — included in the current release” is a warranty. Eight hundred of them is the most detailed specification of the delivered system that will ever exist, signed by the vendor, before a dollar is spent.

And then, on most programs, that document goes in a drawer. Nobody traces it into test cases. Nobody checks at go-live whether the forty things marked “current release” actually shipped. When a gap appears in year two, it gets handled as a change order — the buyer pays a second time for something already warranted.

The single cheapest process improvement available to any agency buying a health record: make the requirements worksheet the acceptance test plan. Same IDs. Same numbering. Every warranted item gets a test case and a sign-off. Vendors behave differently when they know the “1” they typed will be executed against them in eleven months. So do their sales engineers, at the moment they type it.

The People Half: Adoption Is Won in Configuration, Not Training

The standard model treats adoption as a training problem downstream of a build. That is backwards, and it’s why so many go-lives produce a system everyone technically uses and quietly works around.

Configuration determines effort. A workflow that adds clicks will be circumvented — with a sticky note, a personal spreadsheet, a phone call, or free-text where a structured field should be. A workflow that removes clicks sells itself and needs no change management campaign. So the adoption work happens before go-live, in build decisions: specialty-specific order sets, sensible defaults, favorites lists, alert thresholds tuned so the alerts still mean something.

The principle I’d hold every design decision against: make the right way the easiest way. If a compliant action requires more effort than a non-compliant one, the compliance rate is set by that gap, and no amount of training or policy memo closes it.

Three other things that consistently separate the go-lives that hold from the ones that decay:

Champions from every role and every shift, not just day shift. Peers are more trusted messengers than IT. A night-shift nurse with no superuser on their shift is on their own at 2 a.m., which is exactly when the workaround gets invented that becomes permanent.

Say out loud that the first two weeks will be slower. Setting that expectation converts early frustration into patience. Not setting it converts it into a story about how the new system is broken — and that story, once it sets, outlives the problem that caused it.

Fix the small irritants fast. A broken default or a missing favorite, fixed within a day of go-live, buys more credibility than any communication plan. It demonstrates that feedback goes somewhere.

The Process Half: Measure Adoption From the Audit Trail

This is the piece I’d most want to import into public sector delivery generally, because it replaces opinion with data that already exists.

Every action in a modern health record is traceable — who did it, when, how it was entered, whether an alert fired, whether it was overridden, whether the output routed electronically or got printed. That audit trail is treated as a compliance artifact. It is also the only honest adoption measurement system you will ever have.

So full adoption is measured, not declared. For a medication ordering change, the dashboard is small and specific: percentage of prescriptions sent electronically versus printed; free-text medication entries (a signal that the formulary content is inadequate, not that staff are lazy); interaction-alert override rates (a signal of alert fatigue); refill turnaround; help-desk tickets by role and location.

Every one of those metrics has a diagnosis attached to it, and this is the part that matters ethically as much as operationally: outliers get supportive, private follow-up, and the data almost always reveals a barrier rather than resistance. A clinician printing everything usually has a routing problem nobody fixed. A unit with high override rates usually has alerts that are wrong. If the dashboard is used as surveillance, staff learn to defeat the dashboard, and you’ve traded a workflow problem for a data-integrity problem.

The same logic extends to obligations that are easy to assert and hard to verify. Take language access — a patient safety issue, not an administrative one, because a patient who isn’t understood can’t report symptoms accurately or give informed consent, and language access failures fail silently: the person who wasn’t understood doesn’t file a ticket. Federal obligations here are longstanding (Title VI of the Civil Rights Act, Section 1557 of the ACA, the CLAS standards), and a growing number of states now additionally require credentialed interpreters from a state registry with the interpreter’s identity documented for each encounter.

Read as a delivery spec rather than a legal one, that is a data model: preferred spoken language and preferred written language as structured fields, captured separately for the patient and for a parent or guardian, surfaced in the chart banner, driving scheduling and longer visit slots automatically, with documentation of modality and interpreter identity taking a few clicks so compliance is a byproduct of normal charting rather than a separate task. Then the measurement follows for free: concordance — of encounters flagged as needing an interpreter, what share show documented interpreter use? The gap is the safety metric. And “no qualified interpreter was available” needs its own structured value, because that is information the program needs, not a failure to bury.

That is the pattern to generalize: every obligation you’re serious about becomes a structured field, a workflow default, and a metric — or it becomes a policy nobody can prove.

Why a Small Team Can Beat a Systems Integrator

Now the part where I’m arguing my own book, so weigh it accordingly.

SQUEIL Ops is a spec-driven delivery system — an agent pipeline sitting behind a governance layer. The relevant properties for this class of work are not the AI parts. They’re these:

Specs are the artifact, not a by-product. In SPEED, the specification is the durable thing and the implementation is derived from it. That inverts the usual public-sector outcome, where the requirements document is a procurement formality and the real system is whatever got built. When the spec is canonical, “does the delivered system match what was warranted” is a query, not an archaeology project.

Traceability is structural. Every decision has a record; every requirement traces to the decision that motivated it and forward to the implementation and its evidence. That’s the thing that answers a clinician asking “why are we doing this?” with a specific safety or regulatory reason instead of “because IT said so” — which is, in practice, the difference between adoption and compliance theater.

The mechanical work is machine work. De-duplicating 800 requirements, spotting five phrasings of the same security control, flagging every untestable line, cross-referencing an interface list against the requirements that depend on it — that is exactly the labor that gets skipped because it’s tedious, and exactly what a well-supervised pipeline does at a cost that makes it worth doing properly. The judgment calls stay human. The reading does not have to be.

Small teams can’t afford the failure mode that kills big programs. The dominant pathology in Part 1 was scope defined after contract signature. An integrator earns on scope growth. A small team dies of it. That misalignment is worth more than it sounds.

Where I’d temper the claim: none of this substitutes for clinical domain depth, and a small team cannot carry the risk of a nationwide deployment. The realistic role is the front half — requirements, workflow design, integration specification, acceptance criteria, and the measurement layer — plus governance of whoever builds the back half. That front half is a small fraction of a program’s budget and determines most of its outcome.

What I’d Insist On

If I were structuring one of these programs, five things would be non-negotiable, and each one maps to a specific failure in Part 1:

  1. A requirements reduction pass, by a named owner, before the RFP goes out. Against the NPfIT failure: scope undefined at signature.
  2. The requirements worksheet is the acceptance test plan. Against the warranty that nobody enforces.
  3. Incremental delivery where each increment is independently useful. Against the big-bang bet that four consecutive administrations keep funding an invisible thing.
  4. Adoption measured from the system’s own audit trail, reviewed at 30/60/90 days, used supportively. Against declaring success at go-live and finding out in year three.
  5. A published interface inventory before vendor selection. Because the interface list is where the real cost hides, and it’s the subject of the technical companion piece.

None of that is innovative. All of it is boring. That is rather the point: the interesting parts of these programs are the parts that were never the problem.

The engineering detail lives at DevForge Academy: the anatomy of a requirements worksheet that survives procurement, why the interface list is the project, and federating a nation’s health record.

Part 1 is the argument this rests on: The National Health Record a Republic Can Actually Build.