Everybody Agreed Until Somebody Wrote It Down

The leadership meeting went well. A rural health center had decided to bring in a tele-endocrinologist. Diabetes was the most common chronic condition on its panel, and the nearest endocrinologist was a three-hour round trip away. Around the table, everyone agreed: the medical director, the nurse manager, the practice manager, the IT manager and the billing supervisor. The decision took twenty minutes.

A few weeks later, the practice manager finally sat down to write out her thoughts on what the new service actually needed to do. That’s when the agreement fell apart.

The nurse manager had pictured patients coming into the clinic, with a nurse in the room to take vitals, check feet and present the patient to the specialist on screen. The medical director had pictured patients connecting from home, sparing them a drive many of them skipped. Both were reasonable. They were also two different services, with different staffing, scheduling and space.

The medical director had also assumed the endocrinologist would work inside the clinic’s electronic health record, reviewing the patient’s history and labs and documenting the visit directly in the chart. The IT manager had assumed all along that granting an outside specialist access would take too much work. In his version, the endocrinologist’s notes would arrive as documents and be attached to each patient’s record by hand.

The billing supervisor had assumed the clinic would bill for each visit and be reimbursed, as it did for its own providers. Then the endocrinology group’s contract arrived. The group didn’t want the clinic billing on its behalf. It wanted to charge the clinic a fee for every consult. Now the question of where patients would be also mattered for revenue, because a visit hosted at the clinic may allow the clinic to bill an originating-site facility fee to offset that cost.

Nobody had misled anyone. Each of them had simply agreed to a different service.

Everybody agreed until somebody wrote it down.

As Rural Health Transformation Program (RHTP) funding reaches rural hospitals, clinics and health centers, this gap becomes more expensive. Funding brings timelines, and timelines bring pressure to pick a platform and get started. The organizations that do well will be the ones that write down what they need before they look at what anyone is selling.

When the Demo Becomes the Requirements

Here’s what usually happens instead. A decision is made, someone calls a few vendors, and the demos begin. Each demo is polished. Each shows features the team hadn’t thought of. By the third demo, the team is comparing products to each other rather than to anything they need, because nothing they need has been written down.

We call this the Vendor Trap. When requirements don’t exist, the most persuasive demo quietly writes them. The service gets designed around what the product does, and the workflows bend to fit. Months later, staff are working around the technology instead of with it.

“Vendor” here means anyone you’re buying from. That could be a technology company selling a platform, or a specialty group or telepsychiatry provider selling clinical capacity. The trap works the same way with both, and so does the remedy.

It’s also the 90/10 Rule at work. Technology is roughly 10% of telehealth success, and the other 90% is the systematic implementation around it. Choosing the technology first means making the 10% decision before anyone has thought through the 90%.

In the Ingenium Implementation System, a new service moves through five phases: Selection, Verification, Solutionization, Validation and Deployment. Requirements live inside Solution Design within Solutionization, before Technology is chosen. By the time a vendor is in the room, the team should already know, in writing, what the service must do.

Writing requirements also tends to surface questions that reach back to the Business Case, such as who bills, who pays whom and what each visit costs. It’s far better to find those on paper than in the first month’s claims.

Five Questions Before the First Demo

Requirements work moves through five stages. Each stage answers one question, and each produces something written down.

Vision: What should be? Start with the problem, stated plainly: patients with poorly controlled diabetes wait months for specialty care, and many never make the drive. Then state the change you intend: specialist expertise that patients can reach close to home.

Present & Past: What was, and what is? Before designing anything new, study what exists. Who is involved today: patients, front desk, nurses, clinicians, billing, IT? How does a specialty referral move now, step by step? What breaks, and what works? This is where the health center would have discovered its different ideas about the service before they cost anything.

Needs: Why are we doing this? Business needs come from the outcomes the organization is after and from the need for the service to sustain itself. Stakeholder needs come from the people who will deliver and use the service: The endocrinologist needs current labs and vitals before the visit. The patient needs to connect without a tech-support call. Billing needs to know who bills and what each visit costs the clinic. IT needs to know where the specialist documents. Write each need as a single statement, and prioritize it.

Process: What will it look like? Describe in words how the service will work: the patient’s path from referral to follow-up, and who does what along the way. Then set the success criteria for what “working” will mean, and make them specific, measurable and time-bound.

Requirements: What is expected? Finally, translate all of it into three things:

• Functions: what the service or solution must do.

• Definitions: the terms and rules everyone must share. For example, what counts as a “completed visit”?

• Constraints: the limits the service must respect, such as privacy, accessibility or the bandwidth available in patients’ homes.

Notice what is missing from all five stages: any vendor’s name.

The Line Not to Cross

The most common failure in requirements work isn’t skipping it. It’s crossing from what into how before anyone notices.

A requirement says what the service must do: “Specialist recommendations are in our EHR within two business days.” A specification describes how: “We’ll use the group’s referral portal.” Both are reasonable statements, but only the first belongs in requirements.

The difference matters because once requirements start naming the how, the team stops evaluating needs and starts evaluating a product, usually the one they saw most recently. A requirement written as a what leaves room for several vendors to meet it and lets the team compare them on equal footing. A requirement written as a how has already chosen the vendor.

A simple test: if only one product could satisfy a sentence, the sentence is a specification. Move it out.

Two Things Most Teams Leave Out 💡

Current qualities, not only current deficiencies. Most needs assessments are inventories of pain. They list what’s broken, slow or frustrating, and they stop there. But every existing process also contains things that work, often things nobody mentions because they’ve always been there.

Back at the health center, the nurse care manager called every patient with diabetes a week before a specialty appointment to make sure their labs had been drawn. Nobody had written that down, because nobody thought of it as part of the process. When the endocrinology group’s schedulers started booking patients directly, the calls stopped, and the specialist began seeing patients without current labs. Visits were rescheduled, and some patients didn’t come back.

Redesigns that catalog only deficiencies reliably destroy something that was working. Write down the qualities too, and make preserving them a requirement.

Success criteria are a requirements deliverable. Success criteria tend to show up late, after launch, when someone asks how it’s going. By then they’re usually defined by whatever the system happens to report. Set during requirements, before any design exists, they become the permanent reference that every later measure traces back to. They also become the assumptions and metrics a proof of concept tests before full deployment, so the team learns early whether the service works the way it was designed to.

It Scales Down as Well as Up

This may sound like a lot for a rural clinic launching one service, but it isn’t. For a single service, it’s often a few pages and two or three brief working sessions with the people who will deliver it, especially under the guidance of an experienced consultant. A multi-site program takes more work, but the process is the same.

The pattern underneath every stage stays simple: gather the information, write it down, review it, and confirm it with the people who asked for it. Writing it down is what surfaces the disagreements, and confirming it is what resolves them.

This approach began as Contextual Requirements Development, which I developed at Mayo Clinic’s Division of Engineering in the mid-2000s. Over twenty years, it has held up at every scale I’ve applied it to, from designing a house and planning a vacation to developing an app, or an organization-wide telehealth program.

Write It Down Before Someone Else Does

RHTP-funded organizations will be held to outcomes. Before anyone can design a service that reaches those outcomes, they have to be turned into something concrete, and requirements are where that happens.

If you don’t write down what your service must do, someone else will. Usually it’s the vendor with the best demo, and their version will be built around what their product does well.

The meeting you want is the one where everyone agrees, then somebody writes it down, and everyone still agrees.

If your organization is preparing to put RHTP funding to work, our RHTP Implementation Support page describes how we help rural clinics, health centers and hospitals define what they need before they choose how to get it.