Research Only Helps When It Turns Into Action

“The research says…” is where many public systems stop.

A paper is cited. A slide is added to a training. A report is uploaded. A committee receives a recommendation. A clinician is told to use a new practice. A school is handed a checklist. A family gets a resource sheet.

Then the real questions begin.

Who does what differently tomorrow morning? What exact behavior changes? What information has to be visible? What can the user do if speech fails? What training does the worker need? What happens when the local office has two staff instead of twelve? What does the rural version look like? What gets printed? What gets entered into a system? What will show that the change helped rather than merely being completed?

Evidence, recommendation, implementation, and evaluation are different jobs

This distinction matters because a scientifically supported intervention can still fail in routine practice.

It can be too expensive. It can require a specialist who is not available. Staff may not have time. The form may be unreadable. The training may not survive turnover. The policy may conflict with another policy. The clinic may have no quiet room. The person may not use speech. The school may apply the practice in a way that changes the part that made it effective.

Implementation science does not ask only, “Does it work?” It asks what helps or blocks adoption, delivery, scale, and sustainment.

The evidence-to-action pipeline

A public research page should have an output—not merely a conclusion

Research does not automatically dictate the decision

Evidence-to-decision frameworks exist because a recommendation can require more than an estimate of effect.

The GRADE Evidence-to-Decision approach explicitly separates the evidence profile from judgments that may include benefits and harms, certainty, values and preferences, resources, equity, acceptability, and feasibility. CDC’s current ACIP Evidence-to-Recommendations process similarly makes those factors transparent when moving evidence toward a recommendation.

Write an implementation contract before building the tool

Context is not an excuse. It is part of implementation.

The Consolidated Framework for Implementation Research—CFIR—organizes determinants across the innovation, outer setting, inner setting, individuals, and implementation process. The point is not to decorate a project with a framework name. The point is to make the barriers visible before blaming the user or worker.

“Staff did not use it” is not a root cause.

Did staff know it existed? Were they trained? Did the form take 45 seconds or 12 minutes? Was the tool inside the software they already use or on another website? Did supervisors expect it? Did the workflow create duplicated documentation? Did the person need a printer? Was there an alternative when the AAC device was unavailable?

Implementation failures are often design information.

Use implementation strategies, not wishes

The Expert Recommendations for Implementing Change—ERIC—compiled 73 named implementation strategies. They include strategies such as assessing readiness and barriers, auditing and feeding back performance, developing educational materials, conducting educational meetings, identifying champions, changing record systems, revising professional roles, and using implementation advisers.

The practical lesson is simple: “train everyone” is not an implementation plan.

Training may be one strategy. A durable change can also require prompts, supervision, data feedback, workflow redesign, leadership support, policy change, technical assistance, user-facing materials, and an owner responsible for maintenance.

Measure whether it reaches real life

A webpage can have 30,000 visits and still fail if the people who most need it cannot use it.

A training can have 98% completion and still fail if field behavior does not change.

A referral program can send 2,000 referrals and still fail if families arrive at the wrong service, cannot get transportation, or never receive a second route after denial.

Implementation outcomes are not the same as user outcomes

Those outcomes come from a widely used implementation-outcomes taxonomy developed by Proctor and colleagues. They should sit beside service and person-level outcomes—not replace them.

A practice can be highly feasible and accomplish nothing. It can be effective but impossible to sustain. It can be adopted quickly while creating inequitable access. Measure the implementation and the human result.

What research-to-action looks like in ANCHOR settings

A script is sometimes the missing implementation technology

“Clinicians should use shared decision-making” is an aspiration until the clinic has a way to do it.

A practical conversion might be:

That does not mean one script is proven as the universally correct wording. It means the evidence-informed objective has been turned into something a worker can actually perform and a user can recognize.

Checklists should carry decisions—not citations

A field checklist should not become a miniature literature review.

Put evidence in the source layer. Put the actionable decision in the field layer.

For example, a public-safety field card does not need a paragraph about autism prevalence. It may need:

• one lead speaker when feasible;
• one instruction at a time;
• do not require eye contact as proof of comprehension;
• preserve AAC/written communication when safety permits;
• separate immediate threat from unusual behavior;
• document the communication method that worked.

The training manual can show the evidence and legal basis. The field card protects performance under pressure.

Do not standardize the person out of person-centered care

Evidence can support a standard process without forcing one standard accommodation.

A system can standardize the question—“What communication method works right now?”—while allowing the answer to be speech, writing, AAC, gestures, interpreter support, or another method.

It can standardize the need to ask about sensory barriers without assuming everyone needs dim lights.

It can standardize a pre-visit access check without making every person complete the same 40-question form.

Implementation should standardize reliability where reliability matters and preserve individual adaptation where the person matters.

Adaptation should be visible, not accidental

Real settings will adapt a practice.

A rural clinic may combine roles. A school may deliver the same support through a different staff member. A mobile service may replace a paper form with a tablet. Spanish language access may require different examples and phrasing. A nonspeaking user may need the entire workflow to be operable without speech.

The risk is not adaptation itself. The risk is changing something essential and continuing to claim the original evidence without documenting what changed.

Record:

• what changed;
• why it changed;
• who requested it;
• whether it affects the mechanism or only delivery;
• what outcome will reveal whether the adaptation helped or harmed.

De-implementation is action too

Research-to-action is not always “add another program.”

Sometimes the evidence and field data support stopping a practice that is ineffective, burdensome, inaccessible, duplicative, harmful, or no longer justified.

Implementation science literature explicitly includes de-implementation: reducing or removing low-value or harmful practices.

For ANCHOR, that could mean removing a duplicate form, ending a phone-only intake requirement, retiring an outdated resource list, stopping a training scenario that teaches the wrong response, or eliminating a referral step that does not add value.

Failure data belong in the evidence loop

CDC’s updated Program Evaluation Framework emphasizes evaluation as an iterative process and explicitly ends with acting on findings. Its current framework also builds in collaboration, fair and just evaluation, learning, relevance, rigor, transparency, and ethics.

Evaluation is not the autopsy after a program ends. It can be the steering mechanism while the program is alive.

Do not measure only what the system can easily count

Systems naturally collect what their software already records.

Logins. Training completions. Referrals sent. Appointments scheduled. Forms submitted. Cards printed.

Those are implementation signals. They are not automatically outcomes.

Also ask:

• Did the person get the needed support?
• Did communication become easier?
• Did distress decrease or merely become less visible?
• Was travel reduced?
• Did a rural user reach the same service standard?
• Did Spanish-language users receive equivalent information?
• Did high-support-needs users remain in the system?
• Did workers use the tool correctly?
• Did another burden shift onto the family?
• Did complaints reveal a pattern that utilization data hid?

Public implementation should show its assumptions

Research translation must preserve uncertainty

Turning evidence into a tool does not give permission to delete the uncertainty.

If evidence is preliminary, the action can be a cautious pilot rather than a permanent mandate.

If evidence is indirect, the implementation plan can state what local evidence will be collected.

If studies disagree, the tool can present options rather than claiming one universal answer.

If a practice has potential benefit and meaningful burden, the script should make both visible.

The action should match the strength of the evidence.

Evidence-to-Action Build Sheet

What this means for ANCHOR Research

The Research Desk should not end at “source found.”

A useful research workflow can produce several layers:

1. Source layer: the study, review, guideline, official dataset, law, or other primary source.
2. Evidence layer: what it found, certainty, population, limits, conflicts, and applicability.
3. Decision layer: what ANCHOR, a partner, a professional, or a person is considering doing with that information.
4. Action layer: the checklist, route, script, card, workflow, curriculum, policy option, or software behavior.
5. Implementation layer: owner, training, technology, staffing, partner route, communication, funding, timeline.
6. Measurement layer: implementation outcomes plus the actual human outcome.
7. Learning layer: feedback, complaints, failed referrals, field observations, corrections, and revision history.

That is how research stops being a library at the edge of the system and becomes part of the system’s operating logic.