A Planning Guide for Healthcare Consultants, Architects, and Project Teams
The honest answer is: earlier than it usually happens.
RTLS tends to enter hospital construction conversations late. The clinical technology plan gets established, the wireless network gets designed, low-voltage infrastructure gets specified, and construction moves forward. Then, as opening day approaches, someone asks how the facility will handle asset tracking, or staff safety, or patient flow — and the team discovers they’re now working around decisions that were already made.
It doesn’t have to go that way. For consultants involved in new hospital projects, the opportunity is to bring RTLS into the conversation while the project still has room to move — before infrastructure is locked in, before vendors are selected, and ideally before the design is finalized. That window is shorter than most people expect and harder to reopen once it closes.
This guide is written for the people in that room: healthcare consultants, clinical technology planners, and project teams who want to know how to handle RTLS in a new construction project, and when to raise it.
Why RTLS Belongs in the Design Conversation
A modern hospital is a deeply interconnected technology environment. Wireless infrastructure, nurse call, security systems, EHR platforms, medical devices, and building management systems all have to coexist and, in many cases, exchange data. RTLS touches a surprising number of those systems.
Depending on the use cases, RTLS may involve IT, facilities, clinical operations, security, biomedical engineering, supply chain, and the construction team simultaneously. That makes it more than a software purchase — it is part of the technology architecture of the building itself. Decisions about wireless infrastructure density, conduit routing, power availability at ceiling locations, and room boundary definitions all affect how well RTLS performs after opening.
When those decisions are made without RTLS in mind, the project doesn’t necessarily fail — but it often creates constraints that are expensive to work around later. The earlier RTLS is introduced into the planning conversation, the more flexibility the project team has to accommodate it without disrupting what’s already been decided.
The most useful framing for consultants is not: “Does this hospital want RTLS?” It is: “What will become harder or more expensive if we don’t plan for location intelligence now?” That question tends to produce a more honest answer — and a more productive conversation.
Start With Workflows, Not Technology
The right starting point is operational. What decisions will depend on knowing where people, patients, or assets are in real time? That question leads somewhere much more useful, because the answer shapes every downstream decision about infrastructure, accuracy requirements, and integration.
Consider how differently the requirements look across a few common use cases. A hospital tracking mobile medical equipment primarily needs reliable room- or zone-level visibility — knowing which floor and which department is usually enough to support the workflow. A staff safety program needs to identify the location of a duress event precisely enough to direct the nearest responder quickly. Patient flow visibility requires tracking movement between departments, waiting areas, and treatment spaces across the care journey. Each of those is a different operational problem, and they don’t all produce the same infrastructure requirements.
For each planned use case, the planning team should be able to define what problem is being solved, who will use the information, what level of accuracy is actually required, how frequently location needs to update, what systems need to receive the data, and whether the use case is needed at opening or planned for a later phase. That clarity is what gives the project a defensible basis for infrastructure decisions — and prevents the common outcome of building for a technology specification that was never connected to a real workflow.
Infrastructure: Coverage Is Not the Same as Location Performance
This is the point that gets missed most often in new hospital projects, and it has the most expensive consequences when it is.
A wireless network designed for clinical mobility and device connectivity is not automatically designed for RTLS. The access point placement strategies, density standards, and coverage objectives that work well for Wi-Fi are different from what reliable location determination requires. An environment can have excellent wireless connectivity while still failing to consistently identify which room a tag is in.
RTLS location accuracy depends on a tag being visible to multiple access points or gateways simultaneously — typically three or more for reliable room-level determination. That requires a different density and placement approach than coverage-driven design. The planning team needs to ask not just where wireless coverage exists, but where the project needs reliable location information and what the infrastructure requirements are to produce it there.
This matters especially in the parts of a hospital where RTLS performance will be most operationally significant: emergency departments, behavioral health units, procedure rooms, high-density equipment storage areas, and other clinical spaces where the physical environment creates RF challenges. Getting infrastructure placement right in those areas during construction is significantly easier than correcting it afterward.
For new construction, the project may leverage the planned wireless infrastructure, augment it with dedicated BLE gateways, or use a combination of both. AiRISTA’s Sofia™ platform supports integration with enterprise wireless environments including Cisco Spaces and HPE Aruba Networking, which is relevant for health systems that have already standardized on a particular infrastructure partner.
Build for Expansion, Not Just Opening Day
New hospitals rarely stay static. Equipment inventories grow. Departments change. Clinical programs are added. Safety requirements evolve. A technology initiative that wasn’t part of the original scope becomes a priority two years after opening.
None of that is unusual — it’s the normal lifecycle of a healthcare facility. But it creates a planning challenge that is worth addressing directly rather than deferring: the infrastructure decisions made during construction will either support that expansion or constrain it.
A practical way to approach this is to think in three categories. First, the applications that need to be operational at opening.
Second, the use cases the hospital expects to add within the first few years. Third, the capabilities the organization might eventually want to introduce as technology and priorities evolve. The goal isn’t to predict every future application — it’s to make infrastructure decisions that preserve options rather than closing them off.
Overbuilding for hypothetical requirements is a real risk, and it’s one worth avoiding. But underbuilding and discovering three years post-opening that a staff safety deployment requires significant infrastructure work is also avoidable — if the right questions are asked during design.
Fit Into the Health System’s Existing Technology Ecosystem
A new hospital that is part of an existing health system rarely gets to start from scratch on technology. It needs to fit into an established ecosystem: a standardized wireless infrastructure partner, existing RTLS or location-enabled systems, EHR platforms, CMMS, security, and building management. Interoperability and architectural consistency matter from day one.
For consultants, this means understanding what the health system has already standardized on before the new facility’s technology plan is written. What wireless infrastructure does the organization use? What existing RTLS deployments need to be supported or connected? Which enterprise systems will need to receive location data? What networking and security requirements apply across the system?
The objective isn’t to recreate the existing environment exactly in the new building. It is to ensure the new facility can operate as part of the broader organization — rather than as an isolated technology island that requires its own management and support model.
Plan, Don’t Retrofit
The planning question is: which systems will need location data, who owns each integration, what network and security requirements exist, what data needs to be exchanged, and what events should trigger automated workflows?
Integrations Are Easier to Plan Than to Retrofit
RTLS delivers its greatest operational value when location information reaches the systems and people who can act on it. Depending on the use case, that means EHR platforms, CMMS, nurse call, physical security systems, workflow and automation tools, or analytics platforms.
The planning question is which systems will need location data, who owns each integration, what network and security requirements exist, what data needs to be exchanged, and what events should trigger automated workflows. Those questions are not difficult to answer during design. They become significantly more difficult and more expensive to answer after the facility has opened and the systems are already live.
A hospital that opens with RTLS infrastructure in place but integrations still being negotiated is not unusual. It is also a preventable situation — one that delays the operational value the RTLS investment was meant to deliver.
Where AiRISTA Fits Into the Planning Process
For AiRISTA, the most useful time to engage on a new hospital project is before the major technology decisions are locked in. That does not mean selecting an RTLS vendor at the beginning of construction. It means giving the project team access to RTLS expertise while there is still time to shape the strategy.
AiRISTA works with healthcare consultants and project teams to define the location-enabled use cases that make sense for the facility, translate workflow requirements into accuracy and infrastructure requirements, review planned wireless environments against RTLS performance needs, evaluate fit with the health system’s existing technology ecosystem, and develop a scalable deployment roadmap that accounts for future use case expansion.
That kind of early engagement is different from a vendor sales conversation. The outcome is a clearer picture of what RTLS requires in this specific facility — not a product pitch. Vendors can be evaluated and selected later, with the benefit of a well-defined set of requirements. Review AiRISTA’s RTLS Planning Checklist for New Hospital Projects.
The Window Is Shorter Than It Looks
Hospital construction projects move fast once they get going, and the moments when RTLS can be meaningfully incorporated into the design get fewer and further between as the project progresses. The conversations that happen during schematic design are easy. The same conversations during construction documents are harder. The conversations that happen after a building is occupied can be very expensive.
For consultants helping a health system plan a new facility, bringing RTLS into scope early is not about locking in a vendor or committing to a budget. It is about making sure the project asks the right questions while there is still room to act on the answers.
AiRISTA can support that process before vendor selection, before infrastructure is finalized, and before the opportunity to shape the outcome has passed. If you are involved in a new hospital project and want to talk through the RTLS planning questions, we are happy to be a resource.
About The Author
