Skip to main content

Clinical workflow improvement

Map the assessment workflow before buying software

A practical method for documenting how assessments move through a clinic, finding failure points, and turning observed work into software requirements.

Start with observed work, not the desired process

Choose one common assessment pathway and follow a recent synthetic example from the event that triggers it to the point where a clinician has reviewed and recorded the result. Include administrative work, respondent actions, clinical review, and any export or filing step. AHRQ recommends examining both clinical and administrative workflow when planning health IT because technology can change both. [1]

  • Record who starts each step and what information they need.
  • Name the system, inbox, spreadsheet, paper form, or verbal handoff used.
  • Measure waiting time separately from hands-on work where records make that possible.
  • Capture the common path and at least one late, missing, duplicated, or incorrectly routed assessment.

Put ownership and handoffs on one page

Use one lane for each role or system and arrange steps in time order. Draw a handoff whenever responsibility or the system of record changes. Mark decision points explicitly, such as whether an assessment is due, complete, readable, or ready for clinician review. AHRQ's workflow toolkit includes process-mapping approaches intended for health IT planning and redesign. [1]

  • Trigger: the event that makes an assessment due.
  • Assignment: the person responsible for selecting and sending it.
  • Completion: the respondent's route, support needs, and deadline.
  • Review: the named role that checks the returned information.
  • Record: the destination for the response, score, note, or report.
Lirena original visual

The current-state workflow lens

A five-step process for turning observed assessment work into evidence-based software requirements.

  • Trace

    Follow one assessment from trigger through review and recording.

  • Map

    Place roles, systems, decisions, queues, and handoffs in lanes.

  • Classify

    Separate delay, rework, respondent friction, and control failures.

  • Specify

    Convert each finding into a demonstrable requirement scenario.

  • Validate

    Check the map and exceptions with the people who do the work.

A five-step process for turning observed assessment work into evidence-based software requirements. This diagram was created by Lirena for this guide.

Separate delay, rework, and control failures

Do not label every problem as inefficiency. Delay is time spent waiting. Rework is a step repeated because the first attempt failed. A control failure is uncertainty about authorization, review, status, or the authoritative record. These categories lead to different requirements and make vendor comparisons more precise.

  • Delay: an assessment sits in a shared inbox without an owner.
  • Rework: staff re-enter the same demographic data in two systems.
  • Control failure: nobody can show who viewed or changed a record.
  • Respondent friction: instructions, access, or support break the completion path.

When digital responses need to reach an electronic health record, AHRQ advises treating usability, workflow integration, burden, and equity as implementation concerns rather than assuming the connection alone will solve them. [2]

Turn findings into scenarios a supplier can demonstrate

Write each requirement as an observable scenario: actor, trigger, expected behavior, evidence, and failure response. For example, ask a supplier to show how an administrator identifies an overdue assessment, how responsibility is reassigned, and what audit evidence remains. This is more discriminating than asking whether the product has reminders or reporting.

  • Must-have scenarios address safety, governance, accessibility, and continuity.
  • Should-have scenarios remove frequent delay or rework.
  • Could-have scenarios improve convenience without carrying the workflow.
  • Every scenario names the evidence that will prove it during a pilot.

Validate the map before it becomes a buying brief

Run a short playback with each role shown on the map and with people who understand the respondent experience. Ask what is missing, what happens in exceptions, and which step creates the most avoidable work. W3C guidance recommends involving users, including people with cognitive and learning disabilities, in design and testing rather than relying on assumptions about their needs. [3]

Sources and further reading

  1. Workflow Assessment for Health IT Toolkit (opens in a new tab)Agency for Healthcare Research and Quality. Accessed 2026-07-13. Official workflow assessment tools and health IT implementation context for ambulatory care.
  2. Integrating Patient-Generated Health Data into Electronic Health Records in Ambulatory Care Settings: A Practical Guide (opens in a new tab)AHRQ-funded project team. Published 2021-12. Accessed 2026-07-13. AHRQ-funded practical guide covering workflow, burden, usability, equity, and change management; its findings do not necessarily represent official AHRQ or HHS views.
  3. Making Content Usable for People with Cognitive and Learning Disabilities (opens in a new tab)World Wide Web Consortium. Published 2021-04-29. Accessed 2026-07-13. Informative W3C guidance on user needs, design patterns, and inclusive testing.

Next step

See how Lirena supports clinic workflows

Walk through assignment, completion, scoring, review, and reporting with your own workflow scenarios.

Book a workflow demo