What architectural strategy should my hospital adopt?” How you answer this question when developing an information systems strategy will have significant implications on your hospital's operations in the 1990s — and into the 21st century.
Generally, three architectural models have emerged in the marketplace: single vendors, core systems and open systems. All have advantages, and each has a place in today's varied and volatile market. Making the choice involves careful consideration of important issues.
In the first approach, a single hospital information-system (HIS) vendor provides all strategic applications — and takes responsibility for integration.
The core-system approach relies on an HIS vendor delivering major modules, such as general accounting, order communications and patient accounting. These modules are interfaced to a limited number of departmental modules to comprise a total system. This choice also addresses specific departmental needs.
The open-systems model relies on multiple vendors to provide specific software functionality to individual departmental users. The standalone systems exchange information via industry-standard communications protocols through a system-wide networking scheme.
Evaluation points to consider when determining an appropriate HIS architectural strategy include:
Best-of-class vs. single-vendor applications: Large, complex institutions with specialized needs (and with pre-existing investments in standalone systems) often opt for an open-systems approach because of the ability to purchase applications considered best of class. By employing a network and a set of interfaces that all use the same communications protocol, they are able to pick and choose applications individually for each department, as well as utilize departmental systems already in place.
Degree-of-risk diversification: Hospitals choosing an open-architecture approach place a priority on diversifying risk among vendors. An HIS consisting of multiple systems could have a longer lifespan than an HIS by a single vendor; using a variety of vendors is a means of ensuring the entire system does not become obsolete because a single product is no longer available, or a particular vendor goes out of business.
Adding applications: Because some single vendors require applications be implemented in a specific sequence, the open-systems approach allows the hospital freedom to decide when to implement and incur costs for a given application. Conversely, the ease of implementing a tightly coupled application is considered a benefit by hospitals opting for the single-vendor approach.
Increased data redundancy: As multiple systems (each with a data dictionary) capture and share information, data redundancy becomes an issue. Extracting uniform, meaningful data from a system with multiple versions “owned” by different components may be difficult in an open-systems architecture. On the other hand, a global report-writing capability, utilizing consistent data from all departments throughout the hospital, remains an advantage of the single-vendor approach.
System complexity: How many hardware platforms and operating systems are there? How many different languages? What types of databases are used? How are releases from individual vendors implemented into the environment? How will regulatory changes be implemented across the enterprise? The degree of responsibility assumed by the hospital will be determined by the architectural model selected.
System integrity and performance: In a single-vendor environment, the vendor takes responsibility for integration and overall system performance. In the open-systems environment, each vendor's responsibility is limited to assuring that only their software applications perform and their interfaces comply with the protocol of choice. Therefore, the hospital takes on the responsibility associated with making the entire enterprise work. Smaller community hospitals with fewer resources need to ask: “Does the institution have the people, both in numbers and expertise, to manage the system, and do they understand the concepts, accountability and costs involved with network management?”
May 2010
