Impact Insights

Building an Electronically Integrated Hospital from Scratch

Martin Kappeyne

Today’s hospitals ideally contain highly integrated systems for operating the hospital and for collecting and providing clinical information to healthcare providers. Historically, hospitals have implemented computer systems in an organic way that may not have followed an overarching strategy. Lessons from starting a new hospital from scratch can provide an example of how a strategy can create a roadmap for existing hospitals to achieve the highest levels of HIMSS integration.

In 2007, federal and state agencies found that a hospital in California was unable to meet minimal standards for patient care which resulted in its closing. The hospital provided medical services to about 1 million poor and underserved people, and the burden fell on faith-based, county and nonprofit hospitals in the general area. It was quickly determined that a replacement hospital was needed, especially for an emergency room. In 2009, the county pledged funds for the construction of a new hospital that would be operated as an independent nonprofit.

Work to put together the new hospital as a 501c3 nonprofit organization started in late 2011. In mid-2012, I joined the IT team as the application architect. At this point, the new hospital was comprised of a board and several contractors charged with construction and building out the IT infrastructure and integrated electronic medical record (EMR) system. The goal was to open the hospital during summer 2015.

It was quickly decided to implement one of the most popular EMR systems. This one decision simplified the overall process for selecting clinical software to integrate with the EMR and aligned with the three overarching principles that were developed at the start of this effort:

  • Achieve the highest level of integration possible in order to increase data quality and cut down on the amount of discrete data that needed to be transcribed.
  • Limit the number of vendors needed, which in turn simplified the interface build and streamlined problem resolution.
  • Use remote hosting for the main software applications to cut down on the management and support of data systems.

The main components of the hospital software and related interfaces were the EMR, financial management, interface management and human capital management pieces.

Due to lead times for building systems, many selection decisions were made before a CIO and departmental directors were hired. To accelerate the build of the systems, four people were tasked with managing the configuration of all the main components. To ensure the incoming directors could make their marks on the workflows and preferences, most systems were installed as generically as possible. After consultation with other operational contacts, the lab (including blood bank) and pharmacy equipment were ordered and installed before the respective directors and staff were hired. Again, we worked to consolidate vendors whenever needed functionality could be obtained from the same vendor in areas like pharmacy, lab, physiometric monitoring, OR and patient rooms. This also helped reduce the number of interfaces required when vendors provided a single interface bridge to their family of products.

This sequence of events allowed ancillary devices to be fully integrated with the EMR, which ensured that a maximum amount of discrete data could pass back and forth between the respective systems. The radiology and cardiology PACS went to bid only to vendors that could support both products and would work with the hospital to ensure that the majority of costs only came due once the hospital was operational and had a revenue stream. The selected vendor also had the ability to provide a vendor-neutral archive; however, it was determined to delay this to a future phase.

The majority of interfaces were real time and based on HL7 version 2 and the lab utilized ASC X12 protocols. Financial systems still largely relied on batch file delivery to a drop point, mainly because of the selected contractor’s interface requirements. To further reduce staffing needs, the EMR and financial systems were remotely hosted. However, all interfaces were processed through our local interface servers and required the “hairpinning” of virtual private networks (VPNs) to ensure speed and security while data was relayed from one remote data center to another. This configuration allowed hospital leadership to have full insight into the data streams and also assisted us during the setting up of the interfaces with the various vendors.

The hospital opened for operation in 2015, was certified as a HIMSS Stage 6 hospital in 2016 and then was recognized as a HIMSS stage 7 hospital in April 2018.

Lessons learned from this event show that with a foundational strategy a hospital can be integrated quickly and successfully. Naturally, an existing operational hospital will take longer to implement but they will benefit immensely from building the system from the bottom up, starting with the major operational components and then selecting and integrating the specialty systems.

Leave a Reply

Your email address will not be published. Required fields are marked *

*