The IT Commissioning Required Before a Healthcare Facility Opens

There is a moment on every healthcare construction project when the building is nearly done, the move-in date is weeks away, and someone from IT quietly asks, "Are we actually ready?” Not ready in the sense of having equipment ordered or cables pulled. Ready in the sense that every system has been tested, every integration has been validated, and every gap that will surface on day one has been identified and resolved. That question deserves a serious answer, and most organizations reach that point without a clear framework for what readiness actually looks like on the IT side.

IT commissioning is not a single event. It is a series of validation activities that unfold at different phases as the building comes together, and the organizations that do it well treat it that way from the start. It is something you plan for during construction documentation, build into contractor scopes, and manage through every phase that follows.

What IT Commissioning Actually Covers

The term "commissioning" is used loosely in healthcare construction. In the traditional facilities world, it refers to established definitions and standards that verify that mechanical, electrical, and plumbing systems perform as designed. IT commissioning follows a similar logic but applies it to infrastructure, devices, applications, and integrations. This creates a far more complex set of interdependencies.

IT “go live” occurs far in advance of first patient day. At a high level, IT commissioning should address infrastructure validation, device readiness, application and integration testing in partnership with the Transition and Activation team, an IT Command Center, and a formal project close. Each one can surface issues that become genuinely difficult to resolve once a facility is occupied.

Infrastructure Validation

Before devices are deployed and applications are tested, the underlying infrastructure needs to be

confirmed. This means verifying that structured cabling was installed per the approved design, that all cable runs were tested and meet the required performance standards, and that any field deviations were documented and formally accepted. It means confirming that network closets are built out correctly, that equipment is racked and powered appropriately, and that cooling and power redundancy are functioning as specified. Much of this needs to occur before the walls close, while physical access is still available.

Wireless infrastructure requires its own validation step. A post-installation wireless survey should confirm that access point placement, signal coverage, and channel configuration match what was modeled during design. Organizations deploying RTLS or Bluetooth Low Energy systems need those validated separately because Wi-Fi coverage and location accuracy are related but not the same.

We have seen projects where structured cabling passed certification testing, but the as-built documentation did not reflect field changes made during construction. That gap creates real problems when troubleshooting issues after go-live, because the documentation no longer matches what was actually installed.

Device Readiness

Device readiness is one of the most time-consuming and frequently underestimated parts of IT commissioning. Every device that will be used in the facility needs to be inventoried, imaged, configured, and tested before it is placed in a clinical space. That includes workstations, workstations on wheels, thin clients, printers (and don’t forget to assign someone to add the paper), label printers, scanners, bedside devices, and any clinical peripherals that connect to IT systems or the network IT manages.

For devices connected to clinical systems, testing should include end-to-end workflow validation, not just a ping test. A workstation that boots and connects to the network has not been commissioned. A workstation where a nurse has logged in, launched the EHR, documented a patient encounter, ordered a medication, and printed a label from the correct printer for that room has been commissioned.

IoT and clinical engineering devices require a coordinated approach between IT and clinical engineering. IP address management, network segmentation, and vendor activation all need to happen in the right sequence. That sequence is often not clearly defined unless someone is actively managing it across both teams.

Application and Integration Testing

Application readiness is where the greatest risk tends to concentrate, particularly for organizations managing a new build while also juggling ongoing operational changes to their application environment. Testing in the context of IT commissioning verifies whether applications and integrations work in this facility, on this network, on these devices, in these clinical workflows.

Integrations deserve particular attention. Patient monitoring systems feed data into the EHR, nurse call systems are connected to communication platforms, real-time location services feed into dashboards, and pharmacy systems communicate with automated dispensing cabinets. Each of those is a potential failure point. They need to be tested with real data flows in the actual environment, not just validated in a test environment that does not reflect field conditions.

One of the most overlooked parts of IT commissioning is the discipline around tracking what testing actually happened, what was found, and how it was resolved. This is a documented record that the organization can rely on after the project team is gone. Healthcare IT testing typically moves through several formal phases. Functional testing confirms that systems and integrations perform in accordance with their technical specifications. It is the baseline, and it should happen well before any clinical involvement. User acceptance testing (UAT) brings in the people who will actually use these systems and asks them to validate that the configuration meets their workflow needs. These are two different things, and organizations that conflate them tend to find out during opening week why that distinction matters.

Beyond those, many organizations conduct integrated testing, which validates that multiple systems work together under realistic conditions, and dress rehearsals or simulation events in the weeks leading up to move-in. Every one of these events should be tracked in a centralized log that captures what was tested, what version or build was in place, what issues were identified, how they were resolved, and who signed off. That record becomes the foundation for the Command Center operation and the transition to operations.

Defects found during functional testing that are resolved before UAT tell a very different story than defects that are still open at dress rehearsal. Organizations that maintain a living log throughout can see their readiness posture in real time rather than trying to reconstruct it when something goes wrong after opening day.

We recommend that integration testing include a formal sign-off between IT and the relevant clinical or operational stakeholders before first patient day. A unit leader who does not know that nurse call integration was tested and confirmed working has no way to distinguish a configuration problem from a process problem if something goes wrong in the first week.

The Transition and Activation Team Partnership

On most large healthcare construction projects, a Transition and Activation team or planner is engaged to prepare clinical staff for the move into the new facility. Their work centers on Day-in-the-Life or Dress Rehearsal simulations, in which clinical teams walk through scenarios of actual patient-care workflows in the new environment before the facility opens. These sessions are invaluable for surfacing issues that no amount of technical testing will catch, because they reflect how care is actually delivered rather than how a system was designed to work.

What often goes unsaid is how dependent those experiences are on IT, given the speed at which healthcare and technology have converged. The applications that clinicians use during these events are either managed by IT or by a vendor that IT manages. The scenarios being run require data to be set up, test patient environments to be configured, and systems to be in a testable state. A simulation session where the EHR is not accessible, the nurse call integration has not been activated, or the wireless network in a particular unit does not behave as expected is not a successful rehearsal.

We recommend that IT and the Transition and Activation team establish a formal working relationship early, well before simulation events are scheduled. That means agreeing on which systems need to be in which state for each event, defining IT's role during the sessions, and building IT testing milestones that support the Transition and Activation calendar rather than running in parallel with it. When those teams are aligned, simulation events become genuine readiness validation. When they are not, the rework is significant, and the timeline pressure is real. We have found the most successful simulations include dedicated IT resources with at-the-elbow support to quickly address any concerns or feedback.

Additionally, the test tracking log becomes a shared asset. The Transition and Activation team needs to know what has been tested and what has not (when technology is successfully managed, all systems should already be tested and available for simulation events). IT needs to know what scenarios are being run so they can confirm the right systems are ready with the agreed-upon scenarios. That kind of coordination does not happen by accident and must be part of the IT planning for a new build.

The IT Command Center

Opening day at a new healthcare facility is unlike any other day in a health system's calendar. Patients are moving, staff are navigating an unfamiliar environment, clinical workflows are being executed in a new building for the first time, and technology is relied on to support it all simultaneously. This is an exciting day for everyone.

We recommend that organizations proactively stand up a dedicated IT Command Center for the opening period. The Command Center is a structured operation with defined staffing, defined escalation paths, and defined processes for capturing, triaging, and resolving issues in real time. This is an operation in which visibility and coordination are intentionally managed.

The staffing plan matters enormously. The Command Center needs coverage across all critical systems; remember that this coverage is in addition to the IT department's daily demands. We recommend tracking planned support hours against actual support hours throughout the operation. A Command Center that burns out its staff in the first three days is poorly set up, and those signals show up in the data. Use the data to right-size support.

The Command Center should also track the number of issues logged, categorized by system or category, along with the time to close each one. The time from incident to closure is one of the most telling metrics for how well technology was prepared. Organizations that invest in thorough testing and robust technology planning consistently will see faster resolution times and lower overall incident volume.

One of the things we find most rewarding is watching clients close their Command Centers earlier than planned. It is not unusual for an organization to have budgeted two weeks of Command Center operations and find that by day ten, the incident volume has dropped to a level that operational support can absorb. That early close reflects the quality of the preparation that preceded it. The IT Command Center should not simply wind down when incident volume drops. It should close through a formal process and be communicated to all stakeholders to ensure clarity and clear escalation paths.

Operational Handoff

Operational handoff is the step that most IT commissioning processes treat as implied when it should be explicit. It covers the documentation, training, and support transitions that determine whether the facility can be operated and maintained after the project team is no longer on the ground.

On the documentation side, this means confirmed as-built records for cabling and network infrastructure; finalized floor plans showing technology device locations; IP address assignments and network topology documentation; and vendor support contacts and escalation paths. Records that are incomplete or inaccurate on the first patient day create a deficit that compounds over time. On the support side, it means confirming that IT service desk staff have been trained in the new environment, that on-call procedures are in place, and that vendor support contracts are active and accessible.

The Formal Project Close

We recommend a structured closeout that documents findings across all systems: building, medical, and technology. It should also include applications and integrations, organized by category. The goal is to show where the organization started and where it ended at the transition to operations. That includes decisions made along the way, lessons learned, open items that still need to be addressed after Command Center close, and systems in which the construction project introduced new considerations the organization had not previously managed.

The close document should also include detailed budget information. Construction projects surface technology needs that do not always make it into the original capital plan, and the close is the right moment to capture those items in a form that can inform the next budget cycle and departmental prioritization conversations. Some organizations leave this step out entirely, and the cost is not always visible immediately. It shows up eighteen months later, when a budget conversation occurs without context for what was deferred, or when a vendor contract is renewed, and no one can recall what was decided during construction and why.

Beyond the immediate post-opening period, the formal close should include any technology roadmap changes that reflect where the organization is headed and are informed by decisions made during the project. Healthcare construction does not happen in a vacuum. The choices made about infrastructure, platforms, and integrations during a new build have implications for the broader enterprise. Updating the technology roadmap at close captures that context while it is still fresh and gives IT leadership a structured view of the opportunities the project created.

Another thing that is often missed during a project close is celebration. Large construction projects affect every team in the IT department, often increasing demands and stress over extended periods of time. Remember to set aside time during close with all the IT department teams to celebrate their individual contributions and collective effort that made the build a reality. Reflection and recognition create a pause and make the celebration more meaningful.

When to Start and Who Should Own It

The most common mistake we see is treating IT commissioning as a construction closeout activity. By the time a building is in final punch-list mode, the window to address significant infrastructure gaps has largely closed. Physical access becomes restricted, contractors are demobilized, and remediation work in an occupied or near-occupied clinical space carries infection control and operational implications that make it far more expensive and disruptive than it would have been earlier.

IT commissioning planning should begin during the construction documentation phase, when the technology design is being finalized, and subcontractors are being procured. An IT commissioning plan developed at that stage can be built into subcontractor scopes of work, included in submittal requirements, and aligned with formal inspections at key construction milestones.

Ownership is a real question on many projects. The general contractor owns the overall construction commissioning process. Low-voltage contractors are responsible for the quality of installation. Technology design consultants create the technology designs. The IT department is ultimately accountable for the technology environment, but its capacity to execute commissioning activities alongside ongoing operational responsibilities is often constrained. That gap is where things fall through.

Equinox HIT Is Your HIT Construction Partner

At Equinox HIT, we build IT commissioning into our project management framework from the start. That means developing a plan tied to construction milestones, maintaining the test tracking log throughout, coordinating with the Transition and Activation team, planning the Command Center, and closing the project with the documentation the organization needs to move forward.

Opening day in a new healthcare facility carries enough inherent complexity without discovering that critical integration was never tested or that the wireless network does not perform as expected in a high-density patient care area. The organizations that avoid those moments do so because someone was managing the IT commissioning process with the same discipline applied to every other phase of the project.

As your Technology Owner's Representative, we become an extension of your IT team for the life of the project. We direct the work, manage the vendors, and serve as the single point of contact for every technology decision from preconstruction through transition to operations. Through our data-driven platform, Solstice KEY®, we provide both teams with the workflows and visibility needed to stay aligned and keep the project on track.

If your organization is planning a new build or major expansion, we're here to help. 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.