Epic Rover

What is Epic Rover?

Epic Rover is Epic's mobile app for nurses, used on hospital smartphones so inpatient staff can review and document care at the bedside instead of at a workstation. Hospitals also give Rover to other roles: Epic says transporters use it to document transports and update patient locations, and environmental services staff use it to document cleans in real time.

Rover is one of three Epic mobile apps that open.epic names together. Haiku and Canto are Epic's mobile apps for physicians on iOS and Android, while Rover serves nurses and other hospital roles. Each is tied to the same Epic record, so a value documented on the phone is the same value a physician sees at a desktop.

Who carries Rover besides nurses?

Any hospital role that moves between rooms can carry it. Epic's hospital patient flow material names two non-nursing roles directly.

• Nurses: Patient review and bedside documentation, using the phone for quick tasks and a workstation for longer charting.
• Transporters: Documenting transports and updating where the patient is, so bed boards and receiving units stay current.
• Environmental services: Documenting room cleans as they finish, which feeds bed turnaround.
• Housekeeping and clinicians together: Epic describes Parkview Health using Rover to connect housekeeping staff and clinicians.

Each role sees a different set of activities, configured by the hospital's Epic team. A vendor designing for one role should ask which Rover activities that role already has, so the new tool does not duplicate a step the staff already complete on the same phone.

How does a third-party app launch from Rover?

A third-party app launches from Rover through Epic's mobile app integration, which passes the patient context to the other app. open.epic describes Haiku, Canto and Rover as able to communicate with specialized clinical review applications in this way.

• Context hand-off: The Epic app opens the third-party app already on the right patient, so the clinician does not search twice.
• Listed integrations: open.epic names Sectra Liteview PACS, an image viewer, and Voalte, a clinical communication app.
• Return path: The user returns to Rover when finished, and any data the third-party app needs to file goes back through Epic's documented interfaces.
• Workflow-specific limits: Some workflows are platform-specific; open.epic notes that one controlled-substance reauthentication workflow is supported in Rover on iOS devices only.

The launched app still needs its own data access. If it reads the chart, it does so through Epic on FHIR with the scopes the customer approves, and if it files data, it uses the write APIs or HL7 v2 interfaces the customer enables. A launch alone gives context, not permission.

Design the launched app for one hand and short sessions. Clinicians open it in the middle of a task, often wearing gloves, so the first screen should show the one thing they came for without extra taps.

Shared phones or assigned phones?

Hospitals choose between phones shared across shifts and phones assigned to one person, and the choice shapes sign-in, security and how much staff use the app. Decide it before you design the app's login and session handling.

• Shared, unit-owned phones: Lower device count, but each user signs in and out every shift, and sessions must end cleanly between users.
• Assigned phones: Faster to pick up and use, and simpler to audit, with a higher device count and more devices to track and replace.
• Badge or proximity sign-in: Cuts the time to switch users on a shared phone, if the hospital's identity platform supports it.
• Personal devices: Harder to secure for patient data, which is why a hospital's device policy may limit clinical apps to managed devices.

Whatever the model, the vendor's app has to follow the same session rules as Rover on that phone. An app that keeps a user signed in after Rover has signed out leaves the next user looking at the last user's patient.

Bedside scanning: label side and app side

Bedside scanning works only when both the label and the scanner are reliable. The drug label side is set by FDA rules; the scanning side is a hospital hardware and configuration decision.

• Drug labels: 21 CFR 201.25 requires bar codes on the labels of human prescription drugs and certain over-the-counter drugs, containing at least the National Drug Code in a linear bar code.
• Patient wristbands: The hospital prints patient identifiers that the phone's scanner reads, so print quality and symbology have to match the scanner.
• Scanner hardware: Hospitals choose between phone cameras and dedicated scanning sleds or devices, which differ in speed and in how they read damaged labels.
• Medication records: Epic on FHIR lists MedicationAdministration as read and search, so outside apps can display administrations but not file them through that resource.

For a vendor, the last point is the important one. Medication administration documentation stays in Epic's own workflow, and a third-party app that supports it should read, display and link back rather than try to record the dose itself.

Security controls for clinical phones

Phones that show ePHI are covered by the HIPAA Security Rule like any workstation. These standards shape mobile design.

• Workstation use and security: 45 CFR 164.310(b) and (c) require policies for how workstations that access ePHI are used and physical safeguards that limit access to them, which applies to clinical phones.
• Device and media controls: 45 CFR 164.310(d)(1) requires policies for the receipt and removal of hardware and media containing ePHI, which covers phone issue, return and disposal.
• Unique user identification: 45 CFR 164.312(a)(2)(i) makes it a required specification, which rules out a shared login for a shared phone.
• Automatic logoff: 45 CFR 164.312(a)(2)(iii) is an addressable specification, so the hospital implements it or documents an equivalent, such as a short screen lock with re-authentication.

Multi-factor sign-in is good practice on clinical phones but is not required by the current Security Rule. HHS proposed making it required in its January 2025 Security Rule NPRM, which is still a proposed rule.

Wiping matters as much as signing in. A phone that is lost on the bus or sent for repair should be wiped remotely through the hospital's device management system, and the vendor's app should hold no patient data on the phone that would survive that wipe.

What should a vendor test on the hospital's phones?

Test on the hospital's own managed phones, with its device management profile, Wi-Fi and scanners, not on a developer's handset. Some defects appear only under the hospital's configuration, such as a blocked camera permission or a forced screen lock.

• Launch from Rover: The app opens on the right patient every time, including after the user switches patients in Rover.
• Session end: Signing out of Rover, or a shift change on a shared phone, also ends the app's session.
• Network loss: The app shows a clear state when Wi-Fi drops in a stairwell and recovers without losing the user's entry.
• Device policy: Screen lock, copy and paste limits and camera rules set by device management do not break core tasks.
• Data at rest: Nothing about the patient remains on the phone after the session ends or the device is wiped.
• Gloved use: Buttons and scan targets work for staff wearing gloves, in bright and dim rooms.

Repeat the set after every operating system update and every Epic upgrade on the hospital's schedule. Phone fleets update on their own calendar, and a change in either can break a launch or a session rule overnight.

What stops a mobile rollout from sticking?

Rollouts stall when the phone is slower than walking to a workstation. The failure points below are the ones to design out.

• Slow sign-in: Long passwords on shared phones at every shift change, so staff skip the phone and use a workstation.
• Weak Wi-Fi: Dead spots in stairwells, elevators and older wings that drop sessions mid-task.
• Battery and charging: No charging plan, so phones die in the middle of a shift.
• Scanner mismatch: Wristbands or labels the phone cannot read on the first try.
• Too many apps: Separate logins for Rover, a communication app and a vendor tool, each with its own timeout.
• No unit champions: Staff who were never shown the tasks the phone makes faster.

Pilot on one unit, fix what nurses report, then expand. A vendor that joins the pilot early sees the sign-in, Wi-Fi and scanning issues before they become support tickets against its own app.

How Agnotic can help

A hospital mobile tool has to fit on the same phone as Rover and behave the same way. Agnotic Technologies builds those tools: native and cross-platform apps that launch from Epic's mobile apps with patient context, read the chart through Epic on FHIR, file data through the interfaces the hospital enables, and follow the hospital's sign-in, timeout and device management rules.

Agnotic tests on the hospital's managed devices and scanners, joins unit pilots, and builds to HIPAA Security Rule safeguards for mobile, including no patient data left on the device, and repeats its device tests after operating system and Epic upgrades.

Sources

• open.epic: Clinical interfaces, including Mobile App Integration for Haiku, Canto and Rover
• Epic: Hospital patient flow, Rover for transport and environmental services
• open.epic: FHIR interfaces, including MedicationAdministration
• 21 CFR 201.25: Bar code label requirements
• 45 CFR 164.310: Physical safeguards
• 45 CFR 164.312: Technical safeguards
• Federal Register (Jan 2025): HIPAA Security Rule proposed rule