Why Your Technology Problems Start During Design Development (DD) And How to Prevent Them

The decisions locked in during DD determine whether your technology works on day one or becomes a costly retrofit.

The $2+ Million Sentence: "We'll figure out the technology later.”

That single sentence, spoken during Design Development, explains why hospitals discover at activation that:

• Smart room cameras can't see the patient bed

• Nurse documentation stations are three rooms away from where nurses actually work

• The wireless network can't penetrate the gorgeous glass-walled collaboration spaces

• Medical device Virtual Local Area Networks (VLANs) weren't planned, so nothing connects to the EHR

Here's the uncomfortable truth: most "technology problems" discovered at go-live were really design decisions made months or years earlier. By the time your drawings approach the completion of DD, the technology fate of your building is largely sealed.

Why DD Impacts Technology

Design Development is where three things converge:

1. Architectural decisions become permanent (wall locations, room sizes, adjacencies, materials)

2. MEP systems get locked in (power distribution, pathways, cooling, structural loads)

3. Cost models crystallize (changes after DD trigger premium pricing, rework, and schedule delays)

This convergence creates a reality that most teams don't fully appreciate. Technology isn't something you add to a building; it's something you must plan for alongside architectural and engineering decisions.

Consider what's already been decided by the end of DD:

• Whether your IT rooms have adequate cooling and power capacity

• If your risers can handle present and future low-voltage systems

• Where outlets and data drops need to exist (and where they don't)

• Whether radio frequency (RF) environments will support wireless devices

• If security camera sightlines will actually cover what you need to see

Here's the problem: These design decisions get made by architects and engineers, but only if they understand the technology requirements early enough to incorporate them. Miss that window, and no amount of "best-in-class" software or devices will rescue the performance.

The Technology-Architecture Collision Points

Some technologies are especially vulnerable to design decisions. Here's where buildings make or break performance:

• Wireless Systems (Wi-Fi, BLE, RTLS, Telemetry)

  • What DD locks in: Wall composition, glazing type, ceiling plenum design, device density assumptions, interference sources, corridor widths, shielded spaces.

  • Why it breaks: Under-designed radio environments create poor clinical mobility, unreliable smart beds and IoT sensors, and inaccurate RTLS for equipment tracking, staff duress, and infant protection.

  • What the owner needs to bring to the table: Device counts and types, coverage requirements, RSSI targets, IT security standards for wireless, and expected clinical workflows that depend on mobility. The design team needs this information before layouts are finalized.

• Smart Rooms & Patient Engagement

  • What DD locks in: Camera sightlines, mounting surfaces, acoustic treatments, power/data at headwalls, privacy considerations, door swing, and corridor views.

  • Why it breaks: The best telehealth platform in the world fails if the camera can't frame the patient, audio echoes off hard surfaces, or the monitor washes out from uncontrolled glare.

  • What the owner needs to bring to the table: Specific device models, mounting requirements, sightline needs, and power/data specifications for each room type. The design team needs these requirements to coordinate millwork, headwalls, and finish selections.

• Documentation Zones

  • What DD locks in: Where staff can physically access computers, counter depths, monitor mounting, quiet zones for voice documentation, mobile device parking/charging.

  • Why it breaks: If staff must walk three rooms away to document, they'll delay documentation or improvise workarounds.

  • What the owner needs to bring to the table: "Day-in-the-life" workflow validation with staff to identify where documentation actually occurs. Your design team needs to understand these patterns to position power, data, and workstation locations appropriately, which they cannot infer.

• Autonomous Mobile Robots (AMRs)

  • What DD locks in: Corridor widths, turning radii, elevator cab dimensions, door clearances, floor surface specifications, charging station locations, power requirements for docking/charging stations.

  • Why it breaks: Robots like Aethon TUG, Relay, and other AMRs often cannot navigate corridors designed to the minimum code width, cannot fit in standard elevator cabs, and have nowhere to charge if power was not planned at docking locations.

  • What the owner needs to bring to the table: Specific robot models with dimensional and maneuverability requirements (turning radius, height, width), operational routes and frequency, planned charging station locations and power specifications, elevator coordination needs (cab size, controls integration, call interface), and network connectivity requirements for fleet management. Architects need this information to validate corridor and door clearances; MEP engineers need it for power and charging infrastructure; and elevator consultants need it to confirm cab design and operational integration.

A Case Study: Smart Room Readiness

Let's examine what "figuring out technology later" looks like in practice.

• The scenario: A health system plans to deploy cameras, digital door signs, and smart patient whiteboards in all inpatient and ED rooms. The decision is made during DD but critical details arrive too late.

  • What typically goes wrong:

    • Insufficient data drops: Engineers provide standard drops because they were never told cameras require PoE++, door signs need PoE+, and whiteboards require both network and power.

    • Outlet scarcity: Millwork changes move outlets, leaving devices starved for power or dependent on visible power strips (a compliance and safety issue) because fixed mounting locations were not provided early.

    • No cable management: Shallow wall cavities or incompatible surfaces force last-minute bracket improvisation and exposed cabling.

    • Wrong network segments: Devices end up on incorrect VLANs, isolated from required services, creating unreliable behavior because the owner's IT standards weren't communicated to the technology design team.

  • The cost of "later": Change orders to add drops, reroute conduit, modify millwork, and troubleshoot network issues. Multiply by the number of impacted rooms, and the result is a significantly higher budget and a delayed schedule.

• What the owner should communicate during DD:

  • Device inventory: Every patient room and unit type with specific device models and quantities.

  • Mounting coordinates: Height, lateral offsets, sightlines (for cameras) specific enough for designers to coordinate with millwork and headwalls.

  • Power/data specifications: Outlet types, isolated ground requirements, PoE class, port counts per location.

  • Network requirements: VLAN assignments, security zones, bandwidth needs.

  • Growth capacity: How many spare conduits, drops, and cable pathways to accommodate future expansion.

  • Infection prevention standards: Surface materials, sealed penetrations, and IP ratings.

• The result: When the building opens, the smart room stack works day one with clean installs, stable performance, and no activation scrambles.

  • How it empowers your design team:

    • Instead of vague "provide technology" notes, designers receive specific, actionable requirements like:

      • "Each med-surg room requires (3) hospital-grade duplex outlets and (4) PoE++ drops per attached device schedule"

      • "IDF rooms minimum 150 SF with 5-ton cooling and dedicated UPS"

      • "Wireless design target: -65 dBm or better, 5 GHz, channel plan per IT Security standards"

    • These translate into estimable scope, coordinated drawings, and clear accountability.

• The owner's responsibility: Give your design team the information they need to incorporate technology requirements into their work, not as an afterthought, but as an integral part of the architectural and engineering solution. Your IT standards should address many items, such as:

  • Future growth capacity for pathways and risers

  • Actual PoE power budgets by device type

  • IT room requirements (size, cooling, power, UPS)

  • Interface inventory for modalities, smart devices, and building systems

  • Network segmentation and security requirements

  • Technology refresh expectations for multi-year construction

The Bottom Line

"Tech later" doesn't work because technology requirements must inform architectural and engineering decisions and those decisions lock in during DD.

Your architects and engineers are excellent at what they do. But they can't design for technology requirements they don't have.

The organizations that succeed:

1. Gather technology requirements early

2. Document those requirements clearly

3. Communicate them to the design team early enough to be incorporated, not retrofitted

The result: fewer late-stage changes, no scope gaps, systems that work on day one, and clinical teams with the tools they need where their work actually happens.

Equinox HIT is Your HIT Construction Partner

As a Technology Owner’s Representative, we ensure your technology requirements make it to the design team at the right time. We don’t design buildings. We ensure your designers have the information they need to design buildings that work with your technology. We work alongside architects, engineers, and construction partners to ensure technology receives the same rigor and attention as structure, MEP, and finishes.

Ready to ensure your next project's technology requirements reach your design team at the right time?

Contact us to schedule a consultation.

This article was developed by the Equinox HIT Team with editorial assistance from AI tools and re-reviewed by the Equinox HIT Team for accuracy and alignment with our standards.