The 800-Line Requirements Worksheet: What Survives Contact With a Real EHR

Somewhere in your county's procurement folder there is a spreadsheet with more than 800 rows in it, and it is going to determine what your clinicians type into for the next decade.

I've done the requirements work on one of these. This is a field guide to the artifact — what's in it, which parts are load-bearing, which parts are archaeology, and how to turn it from a procurement formality into the most useful engineering document in the program.

The civic argument for why these programs keep failing is over on achatwithai. This is the engineering.

The shape of the artifact

A public-sector health record requirements worksheet is a workbook with one tab per functional area. The tab list is remarkably consistent across agencies, because everyone starts from someone else's copy:

| Functional area | Typical line count |

|---|---|

| Clinical record (the EHR proper) | 150–200 |

| Billing | 100–120 |

| Technical (interoperability, security, UI, workflow, support, reporting) | 150–190 |

| Registration | 60–80 |

| Health information management | 40–60 |

| Check-in / check-out | 40–60 |

| Treatment planning | 40–50 |

| Patient portal | 30–40 |

| Case management | 20–30 |

| Scheduling | 15–25 |

| Specialty programs (communicable disease, maternal/child, developmental disabilities) | 10–25 each |

| General | 60–80 |

| Interfaces | a separate matrix — see below |

Total: north of 800 individual requirements. Each row carries a criticality (Critical / Important / Desired), and each vendor must return one of five response codes:

1  Included in the current release
2  Coming in a future release        (vendor states the delivery date)
3  Not planned — possible via custom development   (vendor states hours to design/build/test)
4  Not planned — possible via third-party integration  (vendor names the partner + prior integrations)
5  Cannot be provided

That five-value scale is a genuinely well-designed instrument. It forces the vendor to distinguish *have* from *will have* from *can build for you* — a distinction that sales conversations exist to blur. And it is usually accompanied by a clause worth its weight in litigation: proposers who claim a function warrant that claim contractually, and are liable for the cost of developing or procuring anything that turns out not to exist.

Hold onto that. It's the most underused sentence in public sector software buying, and we'll come back to it.

Four things that are not requirements

Working through a worksheet like this line by line, a large fraction of the rows are not requirements at all. They fall into four recognizable classes.

1. Duplicates across tabs

The same capability appears in three, four, five places, worded differently each time, because each tab was written by a different working group and nobody ever read the workbook end to end.

Role-based security is the canonical example. You will find it as a general requirement, again in the technical tab's security section, again as "the ability to add and change permissions of role-based users," again as "the ability to provide functional security to control what processes can be performed," and again inside health information management as document-level security. Five rows. One capability. Five separate vendor responses, five test cases if anyone bothers, and five chances for the answers to disagree.

Audit logging duplicates just as badly — an audit trail requirement in the security section, a change-history requirement in billing, another in treatment planning, another in registration, plus a general one, plus a "who accessed this record" one in HIM.

The de-duplication pass is the single highest-value hour in the whole procurement, and it is almost never anyone's assigned job.

2. Solution language wearing a requirement's clothes

The system has the ability to provide drill-down capability on all screens.

That is not a need. It is a guess at an implementation, and it does three bad things at once: it pre-selects a design, it penalizes a vendor who solved the same user problem a better way, and it can't be tested — drill down to *what*, for *whom*, to accomplish *what*?

The fix is to restate it as capability plus task:

A user viewing a search result can reach the underlying record and its attachments in a single action, subject to their role permissions.

Now it's vendor-neutral, it's testable, and it names the job the user is doing. Apply that transformation across a worksheet and a surprising number of rows either collapse into each other or evaporate, because it turns out nobody could name the task.

3. Desktop-software fossils

These are real requirement classes that show up in health record worksheets written this decade:

• word-wrap in a text field without pressing return
• spell-check with an administrator-maintained dictionary
• integration with the operating system clipboard
• support for two monitors
• configurable function keys
• letting the user pick 25 / 50 / 100 results per page

Every one of these was a meaningful discriminator when the buyer's previous system was a thick client in 2004. Today they are either free with any browser or they are someone's decade-old workbook being pasted forward into a contract that a lawyer will eventually have to interpret.

They're not harmless. Each one consumes a vendor response, occupies scoring weight, and competes for attention with the requirements that actually matter.

4. Requirements with no test

The system is intuitive.

The system provides adequate reporting.

The system is user friendly.

If you cannot write the acceptance step, it is not a requirement. It's a hope with a checkbox.

The repair is to convert the sentiment into a measurable property. "Intuitive" usually means something like: *a trained user completes the five most common tasks without consulting documentation*, which is a usability test you can actually run during a scripted demo. "Adequate reporting" means naming the reports.

Some of these do survive as genuine non-functional requirements when they carry a number and a scope. A screen response time target is real if it names the operations it covers and lands in the SLA. A standard-report generation target is real if it requires the vendor to enumerate, in writing, every report that will exceed it and why. Those two are worth keeping precisely because they convert vibes into commitments.

The technical tab is where the architecture hides

The technical tab is usually the largest and the most revealing, because it's where the buyer's real constraints leak out. It typically sections into interoperability, information security, user interface, workflow, system support, and reporting. A few rows in there are worth more than the other 700 combined.

Data portability. Import/export against standard formats — XML, CSV, JSON, searchable text-based PDF, spreadsheet. Unglamorous, and it is your entire exit strategy. A health record you cannot get your data out of is a health record you will still be running in 2041.

Web services and APIs. Older worksheets specify particular integration technologies by name, which dates them instantly and constrains the field for no benefit. Reworded generically — *the system exposes documented programmatic interfaces for the capabilities in the interface matrix* — it stops being a technology preference and starts being an architectural requirement.

A centralized, updatable data dictionary describing table structures and metadata. This one is quietly critical and routinely under-weighted. Everything downstream — ad hoc reporting, analytics, the state submissions you're legally required to file — depends on somebody being able to find the field. A vendor who cannot produce a current data dictionary is telling you something important about what reporting will feel like.

Field-level masking by role. Tax IDs, account numbers, dates of birth, payment card and bank details, government identifiers. This is where the worksheet stops being generic software procurement and becomes health care: the mask list is a de facto privacy policy, and it should be written by the people who own that policy rather than inherited from a template.

Roll-back and recovery, stated separately from backup. Plenty of worksheets require backups and never require the ability to *restore to a point in time*. Those are different capabilities and only one of them saves you.

Severity-tiered support response times — a 30-minute response for a system-down event, an hour for major functional impairment, hours for non-critical. Worth keeping in the requirements rather than leaving to the master agreement, because it's the only place where the buyer's tolerance is stated in the same document as the functionality it protects.

The interface matrix is a different animal

Tucked at the end of most of these workbooks is a small table that carries more schedule risk than any other page: the list of third-party systems the new record must talk to, each tagged SEND, RECEIVE, or BOTH.

For a county behavioral health or public health agency, that list reliably includes a general ledger and cash receipts system, payroll and time reporting, accounts payable, a community services management system, the state Medicaid management information system, a state payment portal, and one or more public web services for transparency reporting.

Two features of that list matter enormously and are usually noticed too late.

First, the versions. These matrices routinely name platforms and database versions that were current fifteen or twenty years ago — a financial package built on a long-unsupported development stack, a database release well past end of life, a "proprietary" platform with no version at all. That is not an embarrassment; it is the actual operating environment, and it is *the* cost driver. An integration against a documented modern API and an integration against a 2008-era system with no API are the same row in the spreadsheet and differ by an order of magnitude in effort.

Second, "all modules must natively integrate with one another" is the most consequential row in the workbook. It looks like boilerplate. It is the difference between buying a suite and buying a collection of separately-acquired products with an integration tax you will pay forever.

The interface matrix deserves its own treatment, which is the next post in this series.

Make the worksheet the acceptance test plan

Back to that warranty clause.

Eight hundred vendor responses constitute the most detailed specification of the delivered system that will ever exist for this program — written by the vendor, signed before money moves, legally binding. And on most programs it goes in a drawer at contract award and is never opened again.

Then, in year two, a gap appears. It gets handled as a change order. The agency pays a second time for a capability it was already warranted.

The fix costs almost nothing:

1. Keep the requirement IDs stable from worksheet, through contract, into the test plan. Same identifiers, end to end.
2. Generate an acceptance test case for every response coded `1`. This is mechanical — it's a row-to-row transform, and it is exactly the sort of tedium worth automating.
3. Track every `2` as a dated commitment with the vendor's stated release, and review the list on that date rather than discovering the slip organically.
4. Cost every `3` before signature. The hours the vendor quoted for custom development are an estimate you can hold them to; the hours they'd quote after award are a negotiation you will lose.
5. Treat every `4` as a second vendor relationship, with its own contract, support path, and failure mode. A third-party integration is not a feature; it's a dependency with a phone number.

The behavioral effect of announcing this up front is larger than the process itself. A sales engineer types a different number in the response column when they know it becomes a test case with their name on it in eleven months.

What a good worksheet looks like when you're done

• Substantially fewer rows than you started with, because the duplicates merged and the fossils were removed.
• Every row testable. If you can't write the acceptance step, the row doesn't ship.
• Every row capability-shaped, not solution-shaped — describing the job to be done, not the widget that does it.
• Criticality honestly distributed. If 70% of your requirements are Critical, none of them are; you've just given up your ability to trade.
• Requirement IDs stable and carried into the contract and the test plan.
• The interface matrix priced separately from the functional requirements, because it behaves like a separate project — because it is one.

None of this is clever. It's just the work, and it's the work that decides whether the next decade of clinical documentation is a tool or a tax.

---

Next in this series: The Interface List Is the Project — HL7 v2, FHIR, and the twenty-year-old financial system nobody wants to talk about. Then: Federating a Nation's Health Record.

The policy argument these posts sit underneath: The National Health Record a Republic Can Actually Build and How You'd Actually Deliver It.