Discussing Healthcare IT
At a Glance
Healthcare leaders can contribute to their organizations' discussions of healthcare IT by:
- Identifying desired components
- Determining objectives of IT applications
- Defining properties
- Defining and enforcing standards for IT systems
- Conducting an architectural review of new applications and technologies
- Investing in IT architecture
IT staff often use the word architecture in their speech and presentations. Client-server architecture. Web architecture. Database architecture.
Those who are listening may dismiss this term as another piece of jargon used by IT people that seems to obscure rather than illuminate the discussion. Yet while there are many IT terms that you can ignore, architecture is not one of them.
IT architecture is an important discussion point for healthcare management. IT architectural choices have the potential to significantly influence the efficiency, effectiveness, and agility of an organization's applications and infrastructure (e.g., networks, workstations, and databases).
Defining IT Architecture
Architecture serves the same role for information systems that blueprints serve for a house.
In building a house, the builder has objectives (e.g., a single-family dwelling) and desired properties (e.g., energy efficient or handicap accessible). The builder knows that the house must have certain basic components, such as a kitchen, a garage, and bathrooms.
The builder knows that the raw materials (bricks, pipes, and paneling) must be brought together in such a way that the resulting structure has the necessary components, meets objectives, and possesses desired properties. The blueprint serves as the builder's plan for this "bringing together."
In the same way, a healthcare organization's information systems must meet certain objectives, such as providing access to patient data across the enterprise and integrating clinical and financial data. All information systems have desired properties, such as efficiency and high reliability. Healthcare IT systems also must have certain components, such as e-mail, registration, and support for the clinical laboratories.
The organization's IT staff, along with its vendors, "bring together" servers, networks, applications, and databases in such a way that the resulting systems have the necessary components, meet objectives, and possess desired properties. IT architecture serves as the plan for this "coming together."
IT architecture consists of concepts, strategies, and principles that guide an organization's technology choices and the manner in which the organization implements and manages these choices. For example, an organization can decide that it will implement only industry standard technologies (e.g., workstations based on Intel processors). This decision reflects an organization's conclusion that such technologies will be less expensive to support and will enable the organization to have a wider range of choices in the market, giving the organization greater flexibility.
As another example, an organization can decide to obtain all of its applications from one vendor. This decision reflects a conclusion that this approach will result in a higher degree of integration and lower support costs than trying to interface the applications from many vendors.
Consequences of IT Architecture
The building of a house involves making trade-offs among cost, components, properties, and objectives. The addition of the third bathroom may be too expensive. The decision to build a single-family dwelling means that changing your mind and deciding to build a gas station may be impractical. Forgetting that one had planned to have children may mean that the decision to build a house with only one bedroom was ill-conceived.
Likewise, there is no free lunch with IT architecture. An architectural decision to implement applications from only one vendor can mean that individual applications are mediocre and that the travails of that vendor have a significant impact on the organization's ability to make progress. However, an architectural decision to allow multiple vendor applications, while providing a large amount of flexibility, means that the ability to integrate those applications will be constrained.
Major changes in IT architecture can be very expensive and time-consuming to effect. One does not go from a multiple vendor strategy to a single vendor strategy without digging deep into his or her wallet.
Just as a poor blueprint and ill-conceived objectives, incomplete properties, and failure to determine the necessary components will have a damaging impact on the utility of the house, poor architecture can haunt an organization's information systems. The resulting systems may be too costly to support, difficult to modify, unreliable, and unable to achieve the desired degree of integration
The Role of Healthcare Management in IT Architecture
How should management guide the discussion on IT architecture?
Of all of the senior leadership discussions of IT, discussing architecture is often the most difficult. Architecture discussions are critical, and they involve the expenditure of large amounts of money and organizational effort to implement. However, these discussions often necessarily involve reviews of complex tradeoffs and technology concepts such as service-oriented architecture, wireless protocols, and interface technologies. These terms usually cannot be avoided in a discussion of IT architecture. The effectiveness of any discussion that involves these terms is exceptionally dependent upon the communication skills of the CIO.
Despite the dense terminology, one does not need to be a computer scientist to effectively manage and contribute to this discussion. There are several tasks and steps that management can take.
Identify desired components. The determination of necessary components (e.g., registration, pharmacy, and nursing documentation applications) is an outcome of the activities that will lead to the development of the organization's IT strategy. This strategy identifies not only the components, but also their sequence of implementation and critical feature set.
Determine objectives. Objectives are capabilities that a large number of applications, if not all of them, must possess. Objectives can be determined by completing sentences such as, "We want our applications to be able to . . ." One could complete that sentence with phrases such as "be accessible from home," "have logic that guides clinical decision making," or "share a pool of consistently defined data." This determination of objectives should be an aspect of the development of the IT strategy.
Define properties. Properties refer to broad characteristics of the applications and infrastructure, e.g., reliability, agility, supportability, integrity, and potency. An organization that is heading into the implementation of more mission-critical systems, for example, must ensure a high degree of reliability. If the organization perceives that it is experiencing substantial growth, it will place a premium on those properties that support the efficient and rapid extension and growth of its systems.
Properties are defined by answering questions such as "What steps do we need to take to significantly improve the reliability of our systems?" or "If we significantly increase the number of physicians in our network, can we rapidly extend our network and applications to them?"
Define and enforce standards. Standards are an essential element of IT architecture. These standards cover areas such as workstations, networks, electronic mail, servers, and applications. Standards help improve the supportability of the infrastructure; one can focus support resources rather than dissipate them over a wide range of technologies. Standards can make the infrastructure more reliable; for example, computer system problems are harder to diagnose and fix in very heterogeneous computer environments. Standards also can ease the challenge of integrating systems. Some systems are designed to support integration with other systems, while others are not.
The task of defining which aspects of the infrastructure need standards, determining which standards to adopt, and developing the approach to enforcing standards involves complicated trade-offs. Standards reduce autonomy. Standards must be kept current. However, it is hard to imagine an infrastructure without standards. It would be hard to imagine the U.S. economy if each state could issue its own currency. It would be hard to imagine our use of modern appliances if each building had its own approach to delivering electricity.
Conduct an architectural review of new applications and technologies. This review should assess the degree to which new technologies or applications support the desired properties and objectives. For example, if the technology is immature, will it reduce the reliability of our applications? Or if the application uses database technology that is different from our other applications, will this place an undue burden on the organization's ability to integrate its systems?
Subjecting new applications and technologies to a review adds a step in the process of acquiring them. The review might conclude that the proposed application harms the infrastructure or is a mediocre solution. This conclusion might dismay the proponent of the new application.
However, architectural review is, in many ways, no different from the review that providers conduct of new medications and modalities before they adopt them. Both types of reviews are intended to ensure that we make thoughtful and holistic decisions.
Invest in architecture. Architecture requires investment. Improving security requires the acquisition of firewalls and virus detection software. Enhancing reliability may call for the development of fault tolerance. Providing mobile workers with access to data will necessitate the implementation of a wireless network. Increasing supportability will require the presence of network management tools.
This investment invariably is limited by the fiscal constraints that all organizations face, and investment decisions must be made thoughtfully. However, as with buildings, equipment, and people, ongoing investments in architecture are needed if an organization is to perform the work that we would like it to perform.
Laying the Foundation for IT Architecture Discussions
The discussion of IT architecture is often the most complex IT discussion that senior leadership will face. The conversation involves complicated concepts and big budgets. It can be very difficult to assign an ROI to these investments.
Nonetheless, the discussion must be held. Poorly conceived or neglected architecture can damage an organization's ability to achieve the desired value from its IT investments. Well-conceived architecture can significantly enhance the leverage of the organization's investments.
Thoughtful discussions of the desired components, objectives, and properties of IT systems provide necessary guidance in the definition of IT architecture. Developing standards, conducting architecture reviews, and making prudent investments will enable the organization to maintain and sustain its architecture.
John Glaser, PhD, FHIMSS, is vice president and CIO, Partners HealthCare, Boston (firstname.lastname@example.org).
Publication Date: Saturday, April 01, 2006