How to Write an RTLS RFP for Elopement and Staff Duress: Performance-Based Specifications That Get Honest Bids

By the MGM Solutions team – life-safety RTLS specialists since 2002.

Many requests for proposal for patient elopement or staff duress systems are written by copying the
brochure of the system the facility already knows. The specification ends up listing one vendor’s
features, sometimes down to model numbers, and every other bidder either bids a near copy or does not
bid at all. The facility gets fewer choices, less price competition, and a contract that describes a
product instead of the protection it actually needed.

There is a better way. A performance-based RTLS RFP states what the system must accomplish, how
quickly, and where, and then tells bidders how those claims will be tested before the system is
accepted. This guide walks through how to write one for life-safety uses.

Start With the Outcome, Not the Product

Before writing a single requirement, the project team should agree on the outcomes in plain
language. For elopement, that might be: staff are alerted within seconds when an at-risk patient
leaves a defined area, and responders can see where the patient is going, including outside the
building. For duress: any staff member can silently call for help from anywhere they work, and
responders see the exact room.

Those outcome statements become the backbone of the specification. Every requirement that follows
should trace back to one of them. If a requirement cannot be traced to an outcome, ask why it is
there. Often the answer is that it was copied from a brochure.

Federal buyers will recognize this approach. The Federal Acquisition Regulation directs agencies to
state requirements in terms of functions and performance where practical, and brand-name-only
requirements need a written justification. Private and state buyers are not bound by the FAR, but the
logic is the same: performance language gets more qualified bids.

Specify Coverage Where Risk Actually Is

Coverage is where life-safety RFPs most often go wrong. A requirement to “monitor exit doors” will
be met by a door-only system that sees nothing between the doors and nothing outside them. If your
risk includes stairwells, courtyards, parking areas, or patients removing their tags, the RFP has to
say so.

Write coverage as a map, not a sentence. Attach floor plans and site plans, mark the areas that
require room-level location, the areas that require boundary detection, and the outdoor areas that
must be covered. Our article on
full-floor RTLS versus
door-only monitoring explains why this distinction drives both safety and price.

Turn Every Claim Into a Testable Requirement

Words like “real-time,” “accurate,” and “reliable” mean nothing in a contract unless they come with
a number and a test. The table below shows the difference.

Two requirements deserve special attention. First, supervision: the system should tell staff when a
tag stops reporting, is removed, or is running low, rather than failing silently. We explain why in
Understanding
RTLS Tag Battery and Tamper Supervision. Second, alert latency, measured end to end from the event
to the alert in a responder’s hand, as covered in our
article on alert
latency.

Ask About the Network Underneath

Many RTLS proposals depend on the hospital’s Wi-Fi or a Bluetooth beacon network. That can work for
asset tracking, but life-safety alerts carried over a shared network compete with everything else on
it. The RFP should ask each bidder to state what network the system depends on, what happens to alerts
when that network is congested or down, and who is responsible for maintaining it. Our pillar page on
why Wi-Fi, BLE, and 900 MHz fall short
for life-safety RTLS explains the questions to ask.

Questions That Belong in Every Life-Safety RTLS RFP

1. What areas, indoors and outdoors, does the proposed system cover, and at what location
   resolution in each?
2. What is the end-to-end alert time from a boundary crossing or duress press to a staff
   device?
3. How does the system detect and report a removed tag, a dead battery, or a failed receiver?
4. What network does the system depend on, and what happens to alerts if that network fails?
5. Can elopement, staff duress, infant security, and asset tracking run on the same infrastructure,
   or does each require separate hardware?
6. How does the system integrate with access control, elevators, cameras, and nurse call?
7. Provide references at comparable facilities, with contacts who can describe performance after
   several years in service.

We use a similar checklist with our own prospects, and our
comparison of campus-wide RTLS
approaches shows how different system types answer these questions. Ask every bidder, including
us, to answer in writing.

Make Acceptance Testing Part of the Contract

The single most effective protection in an RTLS contract is a written acceptance test that mirrors
the requirements: walk tests, timed alerts, tag removal, outdoor coverage, and duress presses in every
zone, performed before final payment. When bidders know their claims will be measured, the proposals
get more honest. For the financial side of the decision, see
How to Build a
Business Case for Hospital RTLS.

Frequently Asked Questions

Related reading:
5 Questions Every
Hospital CIO Should Ask Before Buying RTLS  • 
RTLS Solutions for Hospital CIOs
 • 
Campus-Wide
Elopement Prevention