Blog

    RPM Dashboard Design

    By GauravNovember 4, 20269 mins read
    On this page

    RPM dashboard design decides how a monitoring nurse spends a shift. The same readings can produce a screen that shows the five patients who need a call first, or a wall of red numbers that takes an hour to sort by hand.

    This guide covers the clinician dashboard of a remote patient monitoring program: how to order the triage queue, which states an alert should move through, what a patient trend view needs, how the screen should track the minutes and device days that billing depends on, and how to make it usable by keyboard and screen reader.

    What does RPM dashboard design cover?

    Designing the screens your RPM nurses use?

    Agnotic builds custom RPM apps for the client, including triage queues, patient trend views, alert workflows and billing timers.

    RPM dashboard design is the work of laying out the screens a monitoring team uses each shift: a triage queue that puts the patients needing attention first, trend views that show each patient's readings in context, clear alert states from open to closed, and timers that record billable minutes and device days, all usable by keyboard and screen reader.

    The dashboard is a work tool, not a report. Its success is measured by how quickly the right patient gets the right action, and by whether the record of that action is complete when the month closes.

    How should the triage queue be ordered?

    Order the queue by patient, then by urgency, then by time waiting. One row per patient, not one row per reading, keeps a single bad morning from filling the screen.

    • Urgency first: Critical-limit breaches and escalations sit at the top, then trend alerts, then routine reviews.
    • Time waiting next: Within a tier, the patient who has waited longest comes first, with the waiting time shown on the row.
    • Ownership visible: Each row shows who has it, so two nurses do not call the same patient.
    • Technical items apart: Missed uploads and device problems go to a separate tab for the coordinator, not the clinical queue.
    • Filters that stick: A nurse can filter to their own panel, a condition or a clinic, and the filter survives a page refresh.

    Show the reason on the row in plain words, such as "weight up from usual over 3 days", rather than only a color or an icon. The nurse should be able to choose the next patient without opening any of them.

    Design for handoffs too. At shift change, the incoming nurse needs a view of open items with the last note on each, and after-hours staff need a smaller view limited to urgent items.

    Alert states from open to closed

    Every alert should move through a small set of named states, and the dashboard should show the state on every view. Without states, nobody can tell which alerts are being handled and which are forgotten.

    • 1. New: Raised by the rules, not yet seen by anyone.
    • 2. Acknowledged: A named nurse has opened it and taken ownership.
    • 3. Contacting: The nurse is trying to reach the patient, with each attempt logged.
    • 4. Escalated: Passed to a provider, with the reason and the provider named.
    • 5. Resolved: Closed with a reason from a fixed list, such as advice given, medication adjusted, visit booked or no action needed.

    Two rules keep the model honest. Clinical alerts never close automatically, even when a later reading looks normal; a person closes them with a reason. And an alert that stays new or acknowledged past a time the program sets moves up the queue and notifies a lead.

    The resolution reasons are worth more than they look. Over a few months they show which rules lead to action and which mostly close with no action, which is the evidence the clinical team needs to tune them.

    What should a patient trend view show?

    A patient trend view should show the readings over time against the patient's own range, with the events that explain changes marked on the same timeline. A nurse should understand the story in one screen.

    • Aligned measures: Blood pressure, pulse, weight and any other measures share one time axis, so a weight rise and a pressure change can be compared at a glance.
    • Personal range: The approved range shaded behind the readings, with its version and approval date available on hover or focus.
    • Events on the timeline: Medication changes, device swaps, hospital visits and nurse calls marked where they happened.
    • Gaps as gaps: Days with no reading appear as breaks, not as lines drawn straight across, so missing data is visible.
    • Source of each reading: Device readings and patient-typed readings drawn differently.

    Default to the last 14 or 30 days with a quick switch to longer views. Short views show recent change; longer views show whether this month's pattern is new or seasonal.

    How should the dashboard track time and device days?

    The dashboard should count device days and management minutes from the work itself, as it happens, not from entries typed at month end. Billing staff then check a ledger rather than reconstructing it.

    Under the CY 2026 Medicare Physician Fee Schedule final rule (CMS-1832-F), RPM device supply can be billed with 99445 for 2 to 15 days of data or 99454 for 16 to 30 days, and treatment management with 99470 for the first 10 minutes or 99457 for the first 20 minutes, plus 99458 for each additional 20. A dashboard that only counts toward 16 days and 20 minutes misses the 2026 codes.

    • Day counter: For each patient, the number of days with a qualifying device reading in the current period, visible on the queue row.
    • Minute timer: Starts when a nurse opens a patient's record for review or begins a call, pauses when they leave, and records who did the work.
    • Manual adjustments: Allowed only with a reason and the person's name, and shown differently in the ledger.
    • Period summary: A per-patient view of days and minutes against the code thresholds, so staff can see which patients are close to the next one.

    Every timer start, stop and adjustment is also an audit event. The HIPAA Security Rule at 45 CFR 164.312(b) requires audit controls that record and examine activity in systems holding ePHI, and the minute ledger is part of that activity.

    Keep billing decisions with billing staff. The dashboard shows counts and thresholds; the client's billing team decides which codes apply and when to submit.

    Which roles need their own views?

    Each role in the program needs a view cut to its job, drawn from the same data. Sharing one crowded screen across roles slows everyone down.

    • Monitoring nurse: The triage queue, the patient trend view and the actions that start the timer.
    • Provider: Escalated items only, with the nurse's summary and the trend view, plus a way to send orders or advice back.
    • Device coordinator: Missed uploads, pairing problems, low batteries and device returns, with the patient's contact details.
    • Program lead: Queue size by tier, items waiting past their target time, and resolution reasons over time.
    • Billing staff: The day and minute ledger by patient and period, with adjustments and who made them.

    Show data freshness on every view. A label with the time of the last upload for each patient, and a banner when the device feed has stopped for everyone, stops staff from trusting a quiet queue that is quiet only because nothing is arriving.

    Which accessibility rules apply to a clinical dashboard?

    Build to WCAG 2.1 Level AA at least. The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 AA for the web content and mobile apps of recipients of HHS federal financial assistance, with compliance dates of 11 May 2027 for recipients with 15 or more employees and 10 May 2028 for smaller ones, under the May 2026 interim final rule.

    Whether a staff-only dashboard falls within that scope is a question for the client's counsel. Building to the standard anyway costs little at design time, and it serves clinicians who use screen readers, magnification or keyboard-only input.

    • Keyboard queue: Every row, filter and action reachable by keyboard, with a visible focus marker and a logical tab order.
    • Real tables: The queue built as a table with header cells, so a screen reader announces the column for each value.
    • Live updates: New urgent items announced politely to screen readers without moving the user's focus.
    • More than color: Urgency shown with text and shape as well as color.
    • Text alternatives: Each trend chart paired with a short text summary and a data table view.
    • Zoom: The layout still works at 200 percent zoom on a standard laptop screen.

    RPM dashboard failure points

    • One row per reading: A patient with ten readings takes ten rows, and the patient who needs a call scrolls off the screen.
    • Color-only urgency: Red and amber carry the meaning, and some staff cannot tell them apart.
    • Auto-closing alerts: A normal reading closes a clinical alert that nobody reviewed.
    • Hidden ownership: Two nurses call the same patient while another waits.
    • Typed minutes: Time entered at month end does not match the activity log.
    • Lines across gaps: A trend line joins readings a week apart and hides missing data.
    • Refresh that resets: The queue reloads and loses the nurse's filter and place.

    Test each of these with nurses using realistic patient loads before launch. A dashboard that works with ten demo patients can fail with a full panel.

    How Agnotic can help

    A monitoring program lives or dies on the screen its nurses work from all day. Agnotic Technologies builds that screen for the client: patient-level triage queues with ownership and filters, alert state models with required closing reasons, trend views with personal ranges and event markers, and minute and day ledgers tied to the actions nurses take.

    Agnotic designs to WCAG 2.1 AA from the first wireframe and tests the dashboard with the client's nurses on realistic panel sizes before go-live.

    Build an RPM dashboard your nurses can work from

    Start with custom RPM app development, or browse more articles in the remote care hub.

    Related reading on Agnotic

    Continue with RPM alert fatigue, personal RPM baselines, RPM alerts in Epic, healthcare data visualization and RPM MVP delivery.

    Sources

    Frequently Asked Questions

    No. Show one row per patient with the reason for review, and keep individual readings in the patient's trend view.

    Talk to an engineer about your project

    We build RPM dashboards with patient-level triage queues, alert states, trend views and minute and day ledgers, designed to WCAG 2.1 AA.