Integration is the key to successful information technology (IT) systems in today's health care facilities. From digital imaging and electronic medical records (EMRs) to building operations and services, integration makes a hospital's technology systems work for staff and patients.

From concept to design, systems analysis, implementation and commissioning, the road to technology integration is paved with building team collaboration and strategic planning during the pre-design, design and post-design phases. Working as a team, the hospital and its IT staff, mechanical-electrical-plumbing (MEP) engineer and technology consultants as well as the architect and contractor can make systems integration, and then convergence, a reality.

Pre-design phase

Prior to commencing design, a hospital seeking integration prepares an integration mission statement. This will answer such questions as: What is the motivation behind the integration? Will it enhance the business by increasing revenue, attracting more patients and drawing in more specialists?

Because of the higher first cost to integrate systems, a commitment from the top is essential to success. The integration mission statement must clearly define a vision as well as some uses and design concepts, while evaluating the effect of these concepts on the hospital's daily operations.

It is critical that the appropriate stakeholders and decision-makers are involved in this process. For example, during a major Chicago health care redevelopment program, outside experts met with C-level executives, directors and hospital managerial staff for a collective, day-long meeting. During this meeting, the team reviewed the organization's mission statement and determined how integrating technology can provide benefits. In this case, a core objective of the hospital was to ensure that patients return to the hospital for all their health care needs. Therefore, focusing on the patient experience became key when writing the integration mission statement.

The mission statement's vision will determine how technologies, along with integration, will enhance the day-to-day operations of the facility by listing what services the hospital would like to offer, while the uses will stand as examples of how this newly applied technology actually will play out in the field.

For example, a vision to employ a wireless communication system might stem from a mobile nurse's need to be available for a patient who frequently calls. Another vision might include specifying a videoconference and shared systems technology in the operating suite so a local surgeon can consult with a distant specialist who can access a patient's records remotely and participate in the live procedure.

Once uses have been determined, the design concepts and actual technology needed to support these uses can be documented. Here, the first map of technology integration will be outlined. Which equipment is employed and how will these technologies be tied together to create the desired result? Code issues and hospital requirements will be addressed as well.

Next is to evaluate the effect of these design concepts on daily hospital operations, examining each concept technically, operationally and for its return on investment. Regarding the wireless communication system, for instance: How can it be employed to transmit clearly? Will enhanced antenna systems be needed? Will the medical staff be the only ones using the system or will maintenance personnel communicate on it as well? A cost-benefit analysis needs to accompany the discussion of these technologies at this juncture, prior to their design and implementation.

Finally, reviewing the evaluation with the client team will involve educating the hospital owners and IT staff on the equipment available as well as their future technology options based on the project's schedule. Typically this pre-design phase occurs two to five years prior to hospital construction, allowing for maximum systems integration as a result of early building-team collaboration and, therefore, resulting in a more cost-effective bottom line.

Design phase

This collaboration will continue during the design phase as technology consultants work with the hospital's design team to map out the infrastructure necessary to support these integrated solutions — organically growing the design and its concepts while remaining mindful of the anticipated costs and available budget.

Coordinating systems requirements with all building team members during the design phase will align the technologies and their defined services, taking the first step toward integration and convergence. For example, one new technology may require a set amount of network storage, but working with the other team members reveals a number of additional network storage needs as well. Now the need for storage has doubled and the technology originally discussed won't scale that large.

Flushing out these needs during the initial period of design will lead to the creation of realistic strategies and goals and an understanding of the effects of each technology on the IT infrastructure and its networks, software, servers, support and maintenance.

When working with one suburban Chicago regional hospital with a strong and knowledgeable IT staff, a consultant and hospital IT team recently drove the process and developed integration requirements based on input from the hospital's clinical staff.

User-group meetings were held to address clinical operations, financial goals and all aspects of the patient experience. Through this interaction, it was determined that the organization's philosophy was to ensure that any technologies implemented were "future-proofed" as much as possible. In addition, it was determined the focus of the new technology should be enhancing the caregiver's ability versus providing patients with direct technology interaction.

Next, the schematic design period will further develop the alignment of technology requirements and details. It's important to find the right way to connect each technology to the network and to each other by beginning to understand adjacencies and defining interaction between the systems. During this time, design intent also will be defined while the cost expectations for new technologies will be weighed against their return on investment, proving on paper that the pre-design concepts and their high level of integration will work.

As part of schematic design, a code review should be performed. Typically, this effort is documented in a code analysis that details all IT systems and their relationship with local code requirements as well as state and federal regulatory constraints. For example, a code analysis recently conducted at a large metropolitan hospital revealed that its blood bank monitoring system needed to fulfill code and regulatory requirements. Therefore, the network supporting the blood bank monitoring needed high availability. While traditional data network design typically doesn't consider code and regulatory requirements, code analysis activity here would ensure that these requirements were addressed. During schematic design of the data network, consultants went back to validate that the network design could support such demands.

Following schematic design, the design development period will allow the team to address details like code and equipment requirements, number of fiber strands and physical room layouts, defining the interrelationship between them all.

When working on a Veterans Administration ambulatory care and lab facility, the infrastructure design team met with medical experts to discuss layouts and requirements for technology functions in use-specific rooms. The team documented requirements in customized data sheets that specified technology requirements into zones.

In the case of the operating room, anesthesiologists required Internet access, an interface with the EMR system and direct connectivity with a custom anesthesia database. Surgeons required access to the picture archiving and communications system, EMR, a high-bandwidth upload and download connection for long-distance learning, and an audiovisual system that included multiple high-definition visual displays, communications devices and personalized background music. Here, effective communication during the design development phase helped meet the hospital's IT infrastructure integration needs.

Finally, during the creation of construction documents, the team will realize the final details of each system, focusing on interface points between them. The technology team actually will follow two design schedules: the typical architecture and engineering (A/E) schedule, which focuses on the major items of infrastructure, space and MEP support systems as well as the technology systems design schedule, which typically lags the A/E schedule by months or even years.

This is because technology systems typically have new versions introduced by manufacturers every six months or so, while the design and construction of a facility typically takes three years or more. As a result, the technology team will implement a final check of technology active systems approximately six to 12 months prior to the purchase of these systems to ensure that the latest software and firmware revisions have been included.

This technology review consists of a detailed evaluation of all proposed equipment. Since literal devices and their manufacturers are known at this time, it is possible to work directly with the integrators and manufacturers to align delivery dates with the manufacturer's planned product revisions. In one hospital, this review uncovered that the planned network electronics were at the end of their life and the manufacturer was releasing a new product line. This new equipment was larger in size and required that racks in the communications closets be upgraded from a two-post to a four-post version. As illustrated by this example, the technology review and equipment refresh was crucial to implementing a truly high-performance, integrated infrastructure that effectively will support today's hospitals.


LEFT The alignment of technology requirements reveals the most appropriate way to connect each individual system to the network and to each other. RIGHT Hospital designs require a final check of the equipment slated for specification to ensure that state-of-the-art technology goals are met.

Post-design phase

Commissioning and functional testing must be phased and staggered from the beginning to the end of construction. These tests will validate the uses created in the pre-design phase and ensure that the devices, software and the systems integration are working as intended.

These tests are intended to validate planned functionality and uncover any deficiencies in the IT systems and their supporting building infrastructure.

For instance, at one health care facility, functional testing uncovered a timing conflict between the network electronics and the building's power. When building power was disconnected, the generator performed as designed but the automatic transfer-switch sequence was not aligned with the need for the core network switches to power up before the distribution-level network switches. Uncovering this deficiency prior to building operation allowed the engineers to optimize the system in time for move-in.

The more systems that are integrated and then converged, the more complex and comprehensive the commissioning and functional testing can become.

Typically, the technology integrators will train hospital staff on its systems during this phase as well. These tests are not only the hospital's final look at its systems and integration prior to full operation, but also serve as the first validation of the system's return on investment and the principal verification for convergence.

Operational efficiency gains and satisfaction are measurable as the hospital has arrived at integration, looking toward its final destination: convergence.

Daniel Michaud, LEED AP, is vice president of technology consulting, and Antonio Wright, RCDD, NICET, CVND, is senior associate, at Environmental Systems Design Inc., Chicago. They are and


Sidebar - Common convergence potholes

On the road to systems integration and, eventually, convergence in today's health care facilities, there are many potholes health facility professionals must avoid.They include the following:

Cost vs. return on investment. The cost of putting in a system that can support future technology can be great. Selling these initial high costs to top management is a challenge, but the return on investment speaks for itself. Facility professionals should speak in business terms by breaking down the systems into their bottom-line efficiency gains and patient satisfaction benefits.

Anticipation of technological developments. Hospital designs begin years before the structure actually is built, and by the time construction begins technology often has changed. In these cases, infrastructure plans may need to be refreshed or in some cases, redesigned. Creating modular networks and supporting infrastructure while building timely check points into the process will carry flexibility through construction.

Code and regulatory requirements. Regulatory requirements and integration and convergence don't go together intuitively, but must work side by side. Technology can allow networks to be separate physically, but to operate on virtual local area networks, making both convergence and compliance possible. City codes and regional and national standards are important to interpret early in the design development. Facility professionals should find out what the authorities will and will not accept and get it in writing before the design is finalized.

Construction standards across disciplines. When integrating systems, division of labor among building team members can be challenging. The Construction Specification Institute's Master Specification Division 25, Integrated Automation, was created to define the scope of the technology integrator and general contractor. While not commonly used yet, this standard details interface points and responsibilities for each team member. If Division 25 is not being used, a responsibilities matrix for all team members should be prepared.

Field integration. The design of mechanical-electrical-plumbing and information technology systems integration is one thing, but real-life integration may be another. Facility professionals should be prepared to deal with such unanticipated field issues as undocumented software revisions or a system that operates differently from the way the manufacturer originally promised.


Sidebar - The degrees of integration

The following Five Degrees of Integration™, developed by the authors' firm, follow the progression of technology infrastructure, from completely disparate systems to full convergence. To illustrate each degree, the evolution of picture archiving and communication systems (PACS) and electronic medical records (EMRs) are used as an example throughout.

Degree 0 — None. Systems and pathways are completely disparate, never intending to work together. For example, PACS images may be maintained on local isolated servers while patient-information documents are secured in separate file storage rooms.

Degree 1 — Collocation. Systems share physical space and pathways, but are not connected or integrated in any way. PACS servers are located in data centers due to federal mandates for patient privacy, while patient information is transferred to electronic data (the beginning of EMR). The information is stored on separate servers located in the same data centers.

Degree 2 — Collaboration. Systems share the same media (i.e., copper and fiber cabling) and reside in the same physical space, sharing the same pathways and environmental resources. PACS and EMR would transmit data to the servers and users via common media.

Degree 3 — Interface. Multiple, disparate systems connected via relays, contacts and other simple input and output devices to initiate a response in one or more of the systems. Here, PACS and EMR data can be reviewed simultaneously on a single visual display, but through different connections.

Degree 4 — Integration. The connection between disparate systems into one common network, typically Ethernet, that allows them to pass data to each other. PACS and EMR can be reviewed together on a personal computer.

Degree 5 — Convergence. The alignment of traditionally disparate systems that utilize common databases and allow entirely new uses for translating data into actionable information. For example, PACS and EMR share data at the software/database level, providing caregivers and patients more access to information.