Health Management Technology

Today’s healthcare IT organizations are challenged to manage a growing portfolio of system solutions. The cost of acquiring, integrating and maintaining these systems is rising, while the demands of system users are increasing. Organizations must address evolving clinical requirements as well as continue to support revenue cycle and administration business functions. Health Management Technology In addition to internal data integration needs, demands are increasing for interoperability with other organizations to regionally support care delivery.

Service-oriented architecture (SOA) offers system design and management principles that support re-use and sharing of system resources across the healthcare organization. SOA does not require the re-engineering of existing systems. With SOA, existing processing can be combined with new capabilities to build a library of services that are used as a part of, or to compose, solutions. Using shared services that are aligned with business processes, SOA strengthens interoperability while reducing the need to synchronize data between isolated systems. Services may be made available, no matter their location, to create solutions that reach beyond the desktop, the department and the healthcare organization.

Systems Reused and Shared as Services

A healthcare organization that depends upon a single system across the entire enterprise to support departmental and care delivery needs often already has a solution that shares and reuses system resources. More typical is an organization that depends upon one or more enterprisewide systems, supports department-specific needs with additional systems, has locations that use their own instances of systems, and interoperates using a complex network of data interfaces.

Health Management Technology

An organization that has a large portfolio of systems will more readily see the benefits of a SOA. The use of SOA supports the enablement of system assets with access across the organization, providing opportunities for sharing system capabilities that are currently isolated. With sharing, current unfulfilled processing requirements may be met without purchasing additional systems, and opportunities may become available for standardizing processing and data management. This means existing system capabilities increase in value as they are packaged and shared as services.

Figure 1 presents examples of healthcare system functions and related applications. Though this table does not contain a complete list of functions or systems, it shows the redundancy of system functions in a typical healthcare environment.

SOA defines a service as an independent unit of work that is self-contained and has well defined and understood capabilities. A unit of work may be an entire process, a function supporting a process, or a step of a business process. With SOA, services directly support business processes as they are “discovered” and orchestrated as a system solution.

The greatest opportunities for applying SOA to increase re-use and standardization are provided by those functions that are used across systems, departments and organizations. If system functions are redundant across systems, then the corresponding business processes are most likely related and may indicate the need for process sharing as services. In Figure 1, functions with substantial redundancy are: Register patient; Admit, discharge and transfer patient; Document problem and diagnosis; Capture and document charges; and, Create clinical note.

Each system function may be separated into tasks to further increase re-use opportunities for services. For example, the function “register patient” may be separated into the functions “find and view patient record;” “create and update patient record;” “verify insurance eligibility;” “document history” (new or update); and, other business activities completed during the registration process. This granularity allows other services and applications to use parts of the “register patient” function. The function “find and view patient record” may be used by most of the organization, whereas, the function “create and update patient record” may be used only by the admission and front desk staff.

In some cases, the capabilities provided on another system may be superior to the capabilities currently being used in a process. For example, another system may use a “verify insurance eligibility” function that provides more capabilities than the corresponding function residing in the system on which the “register patient” function is processed. SOA provides an environment in which functions can be standardized and used across systems and processes. Figure 2 presents a conceptual view of the “register patient” set of services.

As SOA is further adopted by the healthcare industry, collections of services as well as specific services will be available for purchase or by subscription. Since the location of system providing services is transparent, it is even possible that services may be hosted outside of the organization. For example, a Diagnostic Related Group coding service may be available for integration into an organization’s solution. The service may be located at an outside agency, supporting use by a variety of healthcare organizations. With SOA, it is possible to have single instances of healthcare code sets, referenced using services, which are always up-to-date for the entire organization’s solutions.

True Interoperability

In most healthcare organizations, a nurse uses multiple systems and devices while providing patient care. She may switch between a patient management application to check demographics and admission information, one or more electronic medical record applications to view clinical notes on prior and current problems, a charge collection application to ensure correct billing, and multiple ancillary systems to request an order. If she does not have access to a system that supports contacting a patient’s physician or reviewing another organization’s clinical records, she may need to complete these functions by phone or fax.

These systems and activities support activities required to complete the overall care delivery process. In this example, however, the nurse—not the system—orchestrates the various systems to support her work. The nurse is providing the interoperability.

Until now, healthcare organizations have supported interoperability by synchronizing data between various systems. Patient information is managed in most every healthcare system, which can number above 100 in some organizations. These system databases are kept synchronized using data interfaces and, for less critical systems, duplicate data entry.

Initially, data interfaces between systems were point-to-point, with each system having its own message format. As the number of systems increased, standard interface formats, such as Health Level 7 (HL7), and central data interface engines have been adopted by larger healthcare organizations. In addition, Internet-based communication has allowed organizations to exchange data with external organizations, such as payers. Figure 3 presents a common healthcare data integration architecture. This environment includes various types of servers, older point-to-point interfaces, and many interfaces processed through a data interface engine.

As data is synchronized between systems and system databases within and outside the organization, this data interface approach falls short of supporting true interoperability. Data processing and communication between processes involves multiple systems and redundant processing. To support the overall workflow, users must switch between several applications to complete a process. Systems also often must be revisited to manually fine-tune data that is redundant between systems.

With SOA, services are developed using existing system capabilities, as shown in Figure 4. Redundant processing is organized and represented as a single service or set of services. Each service is made available to the entire organization through a standard interface. All departments that maintain or access the same information use the same service, making any data and processing redundancies transparent to users. Applications supporting a specific workflow reference one or more services and each service communicates with the systems to which it is related. Users no longer need to switch between systems to complete a workflow and data is naturally synchronized across processes and supporting systems. Orchestrated services aligned with user workflows enable true interoperability among the healthcare organization’s processes and people.

To support compliance with the Health Insurance Portability and Accountability Act, organizations are increasing standard data communication with payers. In addition, integration with other healthcare organizations is frequently required to support clinical workflow and Regional Healthcare Information Organization (RHIO) participation. An organization may integrate external services into its SOA solution to provide complete process interoperability. For example, when a patient is registered within an organization, the service may use an external service, provided by the RHIO, to register the patient for the entire region. Not only is the patient’s registration information synchronized, this external communication is placed into the related workflow with little user impact, creating interoperability outside organization system boundaries.

Conclusion

SOA is the next step of system evolution. It builds upon previous architecture approaches while not requiring complete re-engineering. SOA better addresses agility and effective re-use across and outside the organization, while providing true interoperability.

Most healthcare organizations have a large portfolio of systems with much redundant processing and data. SOA allows system capabilities to be selected and packaged as services that are better focused and available across the entire organization. Organizations can shift their efforts from maintaining a complex data interface strategy to creating service-oriented applications that support interoperability while more closely aligning with healthcare processes.

Michael W. Bridges
Sr. healthcare enterprise architect with Intel Corporation.
Contact him at michael.w.bridges@intel.com.