Interoperability Can Enable Healthcare Agility

As healthcare systems become larger, the need to manage change grows exponentially more complex. One hospital executive explained that the average time for a procedure to become standard practice is 17 years. And as the scale of regional healthcare operations increase, the advantage for an agile healthcare system could be worth millions of dollars.

However, there are situations that cannot be so controlled by forcing everything through a single solution. Patients can be unconscious and unable to explain the true nature of their illness. Patients can have no previous medical records at that facility. It is technically possible today for a physician with no previous connection to a patient to examine the various different tests results (imaging graphs and diagrams, lab reports, etc.), but only as long as the results were gathered from within the unified hospital systems. However, when patients use multiple competing medical units for their care (as in most cases), the ability of an examining doctor to have access to the information gathered by other medical units can be very limited.

For example, outside imaging units resist submitting tests results to the regional hospitals, fearing that they might lose out on billing opportunities for their work. Hospital executives complain that competing medical system manufacturers do not want to enable the results of their equipment to be interpreted by systems from other manufacturers, preferring the hospital to purchase a single solution product suite.

Monolithic Solutions: The monolithic solution has economy-of-scale advantages that can be leveraged across the organization, and it helps to simplify communication – everyone knows the language, procedures, etc. Some organizations go through tremendous effort and expense to incorporate every need into their monolithic solution.

But can a single solution truly solve every process problem? A single accommodating – albeit complex – application that solves central process control issues will likely stifle best-of-breed solutions out on the edge. These non-mainstream units may have needs that are quite different from the system-wide solution.

Point-to-point solutions: We used to believe that in order to ensure exactly the right information was transferred between systems, one must either replicate the entire database, or tightly couple the underlying databases. Replicating the entire database can be a serious violation of security policy for many organizations. And to tightly couple applications can take weeks of very detailed programming on both systems – not exactly agile. I know one hospital CIO who laments today that it takes more than six weeks to make any changes to interfaces in her environment, due primarily to the amount of testing necessary. Without looking at specifics, I would guess that she has a lot of tightly coupled databases.

The complexity of point-to-point integration simply does not scale upwards as operations grow. An average-sized hospital will have hundreds of different interfaces. Most industry standards change every few years, applications change versions every six months and organizations grow and contract continuously. Managing hundreds of point-to-point interfaces with that amount of forced changes – some duplicates, some slight customizations, some radically different – across applications that are in a constant state of flux - quickly becomes an impossibly complex problem when operations grow to thousands of interfaces.

A managed integration layer enables agility: Middleware software that “manages” the thousands of interfaces, such as those in a sophisticated healthcare system, makes change manageable. Essentially, the interfaces between applications become abstracted as autonomous objects that can be updated, changed, reused, replicated or deleted as needed, without causing massive cascading rework to every application in the system. Commercially available software products that provide this capability are grouped as enterprise service bus (ESB) technology. In a modern (XML-based) ESB, business rules and schema translations are handled with easily changed data document templates, rather than directly modifying the difficult-to-change databases and applications.

• data access and security policies (managing single sign-on access across and through multiple and federated-external sources - thus protecting the intellectual property (IP) of each member of the integrated healthcare community. Controls can be set so that external members can only access pre-established levels of information – or not.)
• data transformations from proprietary formats to industry standards (allowing each source and application to interact in the manner and format that works best for each)
• data cleansing routines to eliminate response redundancy or other conflicts when results from multiple databases are aggregated
• query routines that handle enhanced processing of responses (such as what to do with results that return at different time intervals)
• query routines enabling complex analysis (such as conducting research using a knowledge modeling ontology)