A hospital RTLS deployment follows five phases: site survey, infrastructure validation, gateway installation and tag deployment, system integration, and go-live. The full sequence takes 8 to 24 weeks depending on facility size and existing infrastructure. That range is not a vendor estimate — it is what real IT directors encounter once they are accountable for the project plan.

The problem is not the technology. The problem is that no one tells you, before you sign the contract, who owns what. Hospital IT thinks the vendor handles infrastructure. The vendor thinks hospital IT has already opened the firewall ports. Clinical engineering assumes someone else completed the device inventory. Meanwhile, the go-live date slips by six weeks and the CFO wants answers.

This guide covers what each of the five phases actually requires, which tasks belong to hospital IT versus clinical engineering versus the vendor, what your infrastructure must look like before a single gateway goes on the wall, how CMMS integration works at a workflow level, and what the documented ROI numbers from the field look like. Use it to build your project plan — or to pressure-test the one your vendor already gave you.

Real-time location systems (RTLS) in hospitals use hardware tags attached to equipment or worn by staff, gateways mounted on ceilings or walls to receive tag signals, and a software layer that translates those signals into location data displayed on a live map. The practical result: a nurse can see exactly where the nearest available IV pump is without leaving the floor.

Every implementation, regardless of vendor or facility size, moves through the same five phases. The phases are sequential — skipping or compressing any one of them is the primary reason hospital RTLS projects run late or fail to achieve expected accuracy at go-live.

According to HIMSS, inefficient medical equipment management costs US hospitals $14 billion annually. Nurses spend up to 60 minutes per shift searching for lost equipment. The operational problem is real. The technology works. The implementation execution is where hospitals leave money on the table.

Only 20% of healthcare facilities have deployed RTLS to date, according to Penguin’s AI and Location Intelligence whitepaper. The gap between the known ROI and actual adoption comes down to one word: complexity. A structured deployment framework closes that gap.

The most common cause of delayed RTLS go-lives is infrastructure assumption. Vendors quote aggressive timelines — sometimes as short as two weeks — that are only achievable when a specific infrastructure condition is already met: BLE-enabled Wi-Fi 6 access points, live and configured, across the entire facility. When that infrastructure is not in place, the two-week estimate becomes a twelve-week scramble.

The second most common cause is role ambiguity. In a typical hospital RTLS project, three internal teams and one vendor are involved: hospital IT, clinical engineering, biomed, and the RTLS vendor. Without a written responsibility matrix assigned before kickoff, tasks fall through the gaps between teams.

The single document that determines whether an RTLS deployment finishes on time is not the vendor’s implementation guide. It is the responsibility matrix — the one that names exactly which team owns each task in each phase.

For deeper context on how hospital asset tracking with BLE compares to earlier infrastructure approaches — and why the infrastructure gap exists — that background informs every timeline discussion you will have with a vendor.

A hospital with Wi-Fi 6 and BLE radio already enabled across its facility can reduce deployment time by 40 to 60 percent compared to a facility starting from a legacy Wi-Fi 4 or 5 baseline. That is not a marketing claim. It is a direct consequence of skipping Phase 1 remediation work.

What happens: The vendor conducts a physical walkthrough of every space in scope. Hospital IT confirms network readiness. Clinical engineering completes the device inventory. Duration: 1–3 weeks for a 200-bed facility; 3–5 weeks for a 500-bed facility or multi-building campus.

Every item on this list must be confirmed before Phase 2 begins. If it is not confirmed, document the gap and schedule remediation as a Phase 1 deliverable.

BLE 5.1-compatible access points: This means 802.11ax (Wi-Fi 6) access points with the BLE radio enabled in firmware. Wi-Fi 6 hardware that has BLE disabled at the firmware level does not count. Confirm with your network vendor before the site survey date.

VLAN configuration for IoT devices: RTLS tags and gateways communicate on the network. They need a dedicated IoT VLAN, isolated from clinical systems, with appropriate QoS settings. Your IT team owns this — not the vendor.

Gateway power source: Most modern BLE gateways run on PoE (Power over Ethernet). Confirm that ceiling drops in the target areas support PoE. Where they do not, AC power with a secondary adapter is an option — but it adds installation time and cost.

Server or cloud instance provisioning: The RTLS software layer needs a home. Cloud deployment is faster. On-premises requires a server provisioned, racked, and connected to the network before gateway installation begins.

Firewall rules: Tag-to-gateway and gateway-to-server communication requires specific ports open. The vendor provides the port list. Hospital IT opens and validates the rules. This task is frequently missed until a gateway goes live and no data appears on the dashboard.

Device inventory: Clinical engineering completes a full audit of which equipment categories receive tags — IV pumps, infusion stations, wheelchairs, stretchers, portable monitors — and how many units exist per category. Incomplete inventories cause tag quantity errors that delay procurement and push go-live by weeks.

Explore Penguin’s hospital asset tracking solutions for a complete picture of what asset categories benefit most from RTLS tagging at each accuracy tier.

Behavioral health units require a different site survey protocol. Gateway density must be higher — typically 1 gateway per 400–600 square feet rather than the standard 800–1,000 square feet — because sub-room accuracy within a single ward is a life-safety requirement for staff duress scenarios. The Phase 1 survey must map seclusion rooms, elopement risk corridors, and staff-only access points separately. Staff training requirements in Phase 4 also differ for behavioral health teams.

What happens: The vendor designs gateway placement based on the Phase 1 site survey. Facilities installs gateways. Tags are programmed and assigned to assets. Duration: 2–4 weeks for a 200-bed facility; 4–8 weeks at scale.

Gateway density directly determines location accuracy. Zone-level accuracy — knowing which room an asset is in — requires roughly one gateway per 800 to 1,000 square feet in standard hospital construction. Sub-room accuracy, needed for workflow automation and staff duress, requires higher density: one gateway per 400 to 600 square feet.

Thick concrete walls, masonry construction, and seclusion room shielding all reduce effective gateway range. The site survey heat map from Phase 1 should identify these areas and flag them for increased density. Skipping this step is the most common cause of accuracy complaints after go-live.

Tag programming happens in parallel with gateway installation. Each tag is assigned an asset ID that maps to a record in your CMMS or EHR. This mapping must be validated before go-live — an asset tagged with the wrong ID produces location data that is worse than useless in an emergency.

What happens: The RTLS software connects to the hospital’s existing clinical and operational systems. Duration: 2–4 weeks, often running in parallel with late-stage Phase 2 work. This phase has the highest failure risk of any phase — and the highest long-term value when done correctly.

EHR integration links location data to patient records and clinical workflows. HL7 is the messaging standard that governs this connection. Your EHR vendor’s integration team must provide API access credentials and sandbox environment access before the RTLS vendor can begin configuration. Hospital IT owns the process of obtaining these credentials — the vendor cannot request them on your behalf.

The practical output of EHR integration is asset availability displayed in clinical context. A nurse checking the EHR for a patient’s IV pump order can see, in the same interface, whether the pump assigned to that patient is in the room or was pulled for another patient two floors up.

CMMS integration is the most underrated component of a hospital RTLS deployment — and the most skipped. Here is what it actually does in practice.

When a tagged IV pump leaves the ICU and enters a soiled utility room, the RTLS system logs that event. If that pump has been in circulation for 90 days since its last PM (preventive maintenance), the RTLS event triggers a work order in the CMMS automatically. The biomed engineer does not search for the pump. The CMMS already knows where it is and has pre-assigned the work order to the next available tech.

When the pump moves from the soiled utility room to the biomed shop, the RTLS logs that transition. When it returns to the clean equipment room, a second event updates the CMMS record. The entire maintenance lifecycle — from trigger to return — is documented without a single manual entry.

This is why 50% of IV pumps sitting idle most of the day in a typical hospital, according to Penguin’s AI and Location Intelligence whitepaper, is both a problem and an opportunity. The idle pump is not being maintained because no one knows it needs it. CMMS integration closes that loop.

For a detailed breakdown of how RTLS event data connects to CMMS workflows and biomed dashboards, the guide on how RTLS integrates with hospital CMMS platforms covers the technical and operational specifics in full.

CMMS API integration works across most enterprise CMMS platforms via standard REST API calls. The RTLS vendor configures the event rules — which location transitions trigger which work order types. Clinical engineering defines the maintenance rules — which equipment categories, which PM intervals, which priority levels. Both teams must be in the same room for this configuration session.

Nurse call integration routes RTLS-generated alerts — staff duress events, equipment boundary violations, wander-prevention triggers — through the existing nurse call infrastructure. This avoids adding a parallel notification system and uses the communication channels nurses already trust. The vendor connects to the nurse call API. Hospital IT validates that the alert routing rules match the facility’s emergency response protocols.

What happens: The vendor delivers role-specific training. The system enters a parallel-run period. Go-live is declared when accuracy benchmarks and alert workflows are validated. Duration: 1–3 weeks.

Training should never be a single all-staff session. Different roles need different content. Nurses need to know how to read the asset map and interpret location alerts. Biomed engineers need to understand the CMMS integration dashboard and how to validate work order triggers. Security teams need to know how to respond to duress alerts, including how to read room-level location data under time pressure.

The parallel-run period — typically one to two weeks — runs the RTLS system live while staff continue using existing tracking methods. This surfaces accuracy gaps before the old methods are retired. Any zone with accuracy below the agreed benchmark triggers a gateway density review before the old method is turned off.

Go-live is not the end of the project. Battery management, tag replacement cycles, and NIST certification cycles for location accuracy all begin at go-live. The service tier SLA your vendor offers determines how these ongoing requirements are handled — and the cost difference between SLA tiers frequently exceeds the hardware cost difference between vendors.

Print this. Put it in the project kickoff deck. Assign a named owner to every row before the contract is signed.

Network readiness validation — confirming BLE 5.1-capable access points are live and BLE radio is enabled in firmware across all zones in scope.

IoT VLAN configuration — creating and configuring the isolated network segment for RTLS gateways and tags, including QoS rules.

Firewall rule implementation — opening the specific ports required for tag-to-gateway-to-server communication, as specified by the vendor’s network requirements document.

Server or cloud instance provisioning — standing up the environment where the RTLS software layer runs before gateway installation begins.

EHR API access credentials — obtaining sandbox and production API access from the EHR vendor’s integration team and providing them to the RTLS vendor at the Phase 3 kickoff.

Ongoing network monitoring — post go-live, IT monitors gateway connectivity and flags any access point firmware updates that could affect BLE radio function.

Device inventory audit — a complete, categorized count of every asset category receiving a tag, with current CMMS asset IDs for each unit. This is the document that determines tag quantities for procurement.

CMMS maintenance rule configuration — defining which equipment categories trigger which PM work orders at which intervals, and what priority level each work order carries in the CMMS queue.

Biomed integration requirements sign-off — clinical engineering signs off on the CMMS integration configuration before go-live, confirming that automated work order triggers match actual maintenance protocols.

Tag-to-asset mapping validation — confirming that each physical tag is correctly matched to the right CMMS asset record before go-live. A single mismatch here creates downstream maintenance documentation errors.

Post-go-live battery management — tracking tag battery life and scheduling replacement cycles. For facilities using rechargeable tags, clinical engineering manages the charging schedule.

Site survey and heat map production — walking every space in scope, mapping RF signal propagation, identifying density gaps caused by wall construction, and producing a gateway placement design document.

Gateway placement design — specifying the exact location, mounting height, and orientation of each gateway, with density adjusted for accuracy tier requirements in each zone.

Tag programming and configuration — programming each tag with the appropriate beacon interval, asset ID, and alert rule parameters before distribution to clinical engineering for physical assignment.

Software configuration — setting up the RTLS platform, map layers, alert rules, dashboard views, and user roles before go-live.

Training delivery — delivering role-specific training for nurses, biomed engineers, security staff, and administrators, with separate sessions for each role.

Go-live support — staffing the deployment with a technical resource on-site for the duration of the parallel-run period, resolving accuracy gaps before the legacy tracking method is retired.

SLA-covered post-go-live support — covering battery management alerts, firmware updates, accuracy recertification cycles, and integration troubleshooting under the agreed service tier.

Penguin’s PenTrack asset tracking platform is built on BLE 5.1 hardware with an AI/ML location algorithm at its core. The algorithm — based on the MUSIC (Multiple Signal Classification) approach — analyzes signals across all antenna elements simultaneously rather than relying on a single angle estimate. In plain English: instead of asking “what angle did this signal arrive from?”, the algorithm asks “what does the complete picture of signals across all antennas tell us about where this tag is?” The result is room-level and sub-room accuracy on standard, off-the-shelf BLE 5.1 hardware.

This matters most in the environments where accuracy is hardest to achieve: thick-walled ICUs, shielded procedure rooms, and behavioral health units with seclusion room construction. The MUSIC algorithm resolves location in high-multipath environments — where signals bounce off walls, floors, and ceilings — without requiring proprietary supplemental hardware.

PenTrack operates across a location accuracy continuum. Presence detection gives floor-level and building-level awareness. Asset tracking delivers zone and room-level accuracy. Workflow-level tracking achieves sub-room precision — bed-level, bay-level — for clinical workflow automation. Hospitals can start at any tier and expand accuracy by adding low-cost BLE beacons and locators without replacing the core infrastructure.

The Penguin deployment model maps directly to the five-phase framework above. Site survey and gateway placement design are Penguin deliverables. The hospital IT team handles network readiness and firewall configuration with Penguin’s infrastructure requirements document as the guide. Integration connects to EHR, CMMS, nurse call, and access control systems through standard APIs and HL7.

For safety-critical applications — staff duress, wander prevention, infant protection — PenTrack works alongside PenSafe, Penguin’s safety-oriented product line, using the same BLE 5.1 infrastructure investment across both asset tracking and staff safety use cases.

A 200-bed hospital deploying RTLS on a modern BLE 5.1 infrastructure can expect total project costs in the range of $300,000 to $500,000. That figure includes hardware (gateways, tags, any PoE infrastructure upgrades), software licensing, integration work, and go-live support. Facilities upgrading from legacy proprietary RTLS systems — which required infrared or ultrasound supplemental hardware — frequently find that the BLE 5.1 replacement costs significantly less than the original system, despite delivering higher accuracy.

The ROI case is documented. A major health system in North Carolina documented $10 million in annual savings from RTLS asset tracking, as reported by HIT Consultant. That figure reflects reduced equipment purchases from better asset utilization, eliminated travel nurse hours spent searching for equipment, and reduced equipment rental costs.

Clinician hunt time — the minutes nurses spend searching for equipment instead of caring for patients — drops by 30% with AI and RTLS, according to Penguin’s AI and Location Intelligence whitepaper. For a 200-bed hospital, that translates to hundreds of nursing hours recovered per month.

The 50% IV pump idle rate in a typical hospital is the clearest signal of where the financial return comes from. Idle pumps are not generating value. They are sitting in a hallway, untracked, while the purchasing department orders more because clinicians report a shortage. RTLS reveals that the shortage is a location problem, not an inventory problem. Facilities that deploy RTLS consistently achieve a 15 to 20% reduction in IV pump inventory through better utilization, according to Penguin’s AI and Location Intelligence whitepaper.

For a complete breakdown of documented ROI figures from healthcare RTLS deployments, the analysis of documented ROI from healthcare asset tracking provides category-by-category financial modeling.

Payback timelines vary by facility size and use case mix. Asset tracking alone — without integration or advanced workflow features — typically achieves payback in 18 to 36 months. Full deployment with CMMS integration and workflow automation compresses that timeline, because the automated work order reduction saves biomed labor hours from day one of go-live.

Use these questions in every vendor conversation. If a vendor cannot answer all of them with specifics, that is a signal worth acting on before the contract is signed.

Does the vendor’s go-live timeline assume BLE-enabled Wi-Fi 6 is already in place? Ask this directly. An aggressive timeline that assumes infrastructure you do not yet have is not a competitive advantage — it is a scope gap that becomes your problem at week three.

What is the vendor’s written responsibility matrix? If the vendor does not have a documented responsibility matrix — specifying which tasks belong to hospital IT, clinical engineering, and the vendor in each phase — request one before signing. A vendor that cannot produce this document has not deployed enough times to have learned from failure.

What gateway density does the proposal specify, and how does it vary by accuracy tier? A proposal that uses a single gateway density figure for the entire facility is not site-specific. The behavioral health unit and the main supply corridor have different accuracy requirements. Gateway density should reflect those differences.

How does the CMMS integration work at the event-trigger level? Ask the vendor to describe exactly which location events trigger which CMMS work order types. If they describe it generically (“it integrates with your CMMS”), they have not done a deep integration before. A vendor with CMMS integration experience can describe the event taxonomy in specific terms.

What does the post-go-live service tier cover, and what is excluded? Battery management alerts, tag replacement, firmware updates, and accuracy recertification are ongoing operational requirements. Confirm whether each is included in the base SLA or billable separately.

What is the path from a pilot to full deployment? A pilot covering one department or one floor is a legitimate starting point. Confirm that the pilot infrastructure — gateways, network configuration, software instance — can be extended to the full facility without replacing components. Pilots that require a forklift upgrade to scale are pilots designed to create a second sales cycle, not a path to enterprise deployment.

Explore Penguin’s healthcare RTLS solutions for a full view of how PenTrack, PenSafe, and PenNav address the complete spectrum of hospital location intelligence use cases.

For hospital IT directors evaluating RTLS in 2026, the financial case is settled. The $14 billion in annual waste documented by HIMSS, the $10 million documented savings at a major North Carolina health system, and the 30% reduction in clinician hunt time are not projections. They are outcomes from facilities that completed the implementation. The question is no longer whether to deploy RTLS. It is how to deploy it in a way that reaches go-live on schedule and delivers the accuracy benchmarks the ROI model assumes.

The answer to that question is a responsibility matrix, an infrastructure prerequisites checklist, and a vendor who can describe their CMMS integration at the event-trigger level — not just in a brochure, but in a pre-contract technical review. Facilities that do that work before signing reach go-live faster than facilities that leave it to the kickoff meeting.

The five-phase framework above is the starting point. The responsibility matrix is the tool. The infrastructure checklist is the gate. Any vendor that cannot walk you through all three before the contract is signed has not earned the contract.

The following questions represent the most common queries from hospital IT directors, clinical engineers, and procurement teams evaluating RTLS implementation for the first time or replacing a legacy system.

A full hospital RTLS deployment takes 8 to 24 weeks from kickoff to go-live. A single-department pilot runs 8 to 12 weeks. A full facility deployment at a 200-bed hospital runs 12 to 16 weeks when existing BLE-enabled Wi-Fi 6 infrastructure is in place. The same 200-bed hospital without BLE-capable access points runs 16 to 24 weeks, because infrastructure upgrades run in parallel with site survey work. Multi-building campus deployments at 500 beds or more follow a phased schedule — building by building — and the full rollout can extend to 30 weeks or longer depending on construction access and integration complexity.

At minimum, the facility needs 802.11ax (Wi-Fi 6) access points with the BLE radio enabled in firmware across all zones in scope. A dedicated IoT VLAN for RTLS gateways and tags must be configured and isolated from clinical systems. PoE ceiling drops are required at gateway mounting locations — or AC power with adapters where PoE is unavailable. Firewall rules must permit tag-to-gateway and gateway-to-server traffic on the ports the vendor specifies. A server or cloud instance must be provisioned for the RTLS software layer. All of these items must be validated in Phase 1 before gateway installation begins — not discovered during it.

Both — with defined boundaries. The vendor owns gateway placement design, tag programming, software configuration, training delivery, and go-live support. Hospital IT owns network readiness, IoT VLAN configuration, firewall rules, server provisioning, and EHR API access credentials. Clinical engineering owns the device inventory audit, CMMS maintenance rule configuration, tag-to-asset mapping validation, and post-go-live battery management. Facilities that assign named owners to each of these tasks before kickoff consistently reach go-live faster than facilities that leave ownership implicit.

Gateway density depends on the accuracy tier required and the construction characteristics of each space. Zone and room-level accuracy — sufficient for most asset tracking use cases — requires approximately one gateway per 800 to 1,000 square feet in standard drywall or light masonry construction. Sub-room accuracy for workflow automation or staff duress requires one gateway per 400 to 600 square feet. Behavioral health units, ICUs with thick concrete walls, and shielded procedure rooms all require higher density because construction attenuates BLE signal propagation. The Phase 1 site survey heat map produces the specific gateway count and placement design — a single-number-per-floor estimate in a vendor proposal is a red flag, not a planning document.

Yes. RTLS platforms integrate with EHR systems through HL7 messaging standards and, in modern deployments, through REST API connections. The EHR vendor’s integration team must provide API access credentials and sandbox environment access before the RTLS vendor can begin configuration. The specific workflows enabled by the integration — asset availability displayed in the EHR, patient location visible in clinical documentation — depend on what the EHR’s API exposes and what the facility’s clinical informatics team approves. Hospital IT is responsible for obtaining API access and managing the integration environment. The RTLS vendor configures the connection on their end.

A pilot covers a single department, floor, or use case — typically one to three months in duration — and is designed to validate accuracy, workflow integration, and staff adoption before committing to a full facility deployment. A full hospital deployment covers all zones in scope, all asset categories receiving tags, and all integration touchpoints. The critical evaluation criterion when choosing a pilot is scalability: the gateways, network configuration, and software instance used in the pilot should extend to the full facility without replacement. A pilot that requires new hardware or a different software tier to scale is not a pilot — it is a proof of concept that creates a second procurement cycle.

RTLS connects to a CMMS through the CMMS’s API layer. The RTLS platform is configured with event rules that define which location transitions — equipment entering a soiled utility room, returning to the biomed shop, exceeding a PM interval threshold — generate work orders in the CMMS automatically. Clinical engineering defines the maintenance rules: which equipment categories, which PM intervals, which priority levels. The vendor configures the event triggers. Once live, biomed engineers see maintenance-due alerts in the CMMS dashboard without physically searching for equipment first — because the RTLS already knows where the asset is and has pre-populated the work order location field.

Thick concrete walls, masonry construction, and environments with high RF interference — including seclusion rooms with shielded construction and procedure rooms with metal-shielded walls — attenuate BLE signal propagation and increase multipath effects: signals bouncing off surfaces arrive at the gateway from multiple directions simultaneously, making simple signal strength estimates unreliable. The solution is a combination of higher gateway density in those areas and an AI algorithm that analyzes the full picture of signals across all antennas simultaneously rather than relying on any single signal path. This multi-antenna analysis approach resolves location even where individual signal paths are unreliable — which is precisely why behavioral health units and ICUs require a modified site survey protocol in Phase 1.

Penguin Location Services delivers AI-powered location intelligence for hospitals across North America and the Middle East. Our PenTrack asset tracking platform uses BLE 5.1 and the MUSIC algorithm to achieve room-level and sub-room accuracy on standard off-the-shelf hardware — with a structured five-phase deployment model and a written responsibility matrix built into every engagement. To discuss a site assessment or pilot scope for your facility, visit penguinin.com/pentrack or explore our full range of healthcare RTLS solutions.