The AMDIS Connection: The Risk Equation for EMR Integration
The health IT pendulum swings back and forth. We started with mainframe-based dumb terminals and centralized Big Iron systems with monolithic architectures and no electronic data sharing.
Then came disparate, highly portable systems with some—but not enough—sharing of information. If you don't have a unified environment in place, it can be problematic to adopt a single-vendor EMR system. And if a one-stop EMR doesn't meet your needs, then what?
In the mainframe era, one-stop shopping (for the clinical part of the patient record, at least) was the way to go. You had your terminals feeding data into the mainframe, and there they stayed. This was also an era when lab systems weren't integrated, and commercial systems were monolithic.
However, as medicine became more specialized in the 1970s and '80s, so did EMRs. There was a need for different workflows to be served. Meanwhile, the transition from mainframes to green terminals to PCs was under way. I recall John Glaser, on a visit to Michigan, being met with a high degree of skepticism when he said he was pretty sure he could network together a bunch of PCs to deliver all the elements of an EMR over a local area network. As he and others with the same idea started building networked systems, the idea of EMR flexibility started to creep into hospitals' consciousness.
As popular awareness grew, the changes in health IT seemed to parallel the home device revolution, including the notion of more modularized services. Initially, these systems went where the money was—cardiology, for example—and were tightly targeted on specialized groups.
The demise of monolithic systems was slow, however—the last ones have been taken offline within the past five years—as was the evolution from one-vendor solutions to multiple systems under one roof. But the scenario of many people contributing to development led to a transformation over the last 15 years. Modern systems allow us to buy piece-parts: This is one reason HIMSS 2011 was the size of a small city. There has been some consolidation around large brands, but we still have a lot of legacy systems. Many facilities, especially smaller ones, do not have the finances to rip these out and start over with a single-vendor system.
We need to pay careful attention to the actual state of integration in the industry. Clearly, the emphasis now is on large multinational companies that do it all. However, despite what they claim, most companies still have significant gaps in their integration capabilities, while most hospitals, even the smallest ones, have some heterogeneity. Interface engines haven't solved the problems, especially for organizations with hundreds of locations, all of which impacts on the risk equation of best-of-breed versus a total suite from one vendor.
The problem is in the displays. Sometimes the data structure is the issue. You can capture points as separate data on a single display, but if you look at isolated data, you don't get the comprehensive view. In a display theater, lab data come across as a blob, and you have to parse them, or they're lost in a world of partial integration. Standards are now more robust and have more clinical richness, but nomenclature is still an issue. Mapping terms across multiple systems is necessary, regardless of whether a facility has one EMR or multiple EMRs in place.
The idea of one-stop shopping belies the point that greater adoption of EMRs in general will lead to a lot of disruptive feedback. The convergence of automation with practice will alter meaningful use ends; there will be further modification of data structures of commercial systems. There is no perfect solution with single source. IT needs to remain alert to appropriate standardization versus inappropriate, and having physicians engaged with acquisition and evolution is imperative because of the necessity of proper configuration.
Then came disparate, highly portable systems with some—but not enough—sharing of information. If you don't have a unified environment in place, it can be problematic to adopt a single-vendor EMR system. And if a one-stop EMR doesn't meet your needs, then what?
In the mainframe era, one-stop shopping (for the clinical part of the patient record, at least) was the way to go. You had your terminals feeding data into the mainframe, and there they stayed. This was also an era when lab systems weren't integrated, and commercial systems were monolithic.
However, as medicine became more specialized in the 1970s and '80s, so did EMRs. There was a need for different workflows to be served. Meanwhile, the transition from mainframes to green terminals to PCs was under way. I recall John Glaser, on a visit to Michigan, being met with a high degree of skepticism when he said he was pretty sure he could network together a bunch of PCs to deliver all the elements of an EMR over a local area network. As he and others with the same idea started building networked systems, the idea of EMR flexibility started to creep into hospitals' consciousness.
As popular awareness grew, the changes in health IT seemed to parallel the home device revolution, including the notion of more modularized services. Initially, these systems went where the money was—cardiology, for example—and were tightly targeted on specialized groups.
The demise of monolithic systems was slow, however—the last ones have been taken offline within the past five years—as was the evolution from one-vendor solutions to multiple systems under one roof. But the scenario of many people contributing to development led to a transformation over the last 15 years. Modern systems allow us to buy piece-parts: This is one reason HIMSS 2011 was the size of a small city. There has been some consolidation around large brands, but we still have a lot of legacy systems. Many facilities, especially smaller ones, do not have the finances to rip these out and start over with a single-vendor system.
We need to pay careful attention to the actual state of integration in the industry. Clearly, the emphasis now is on large multinational companies that do it all. However, despite what they claim, most companies still have significant gaps in their integration capabilities, while most hospitals, even the smallest ones, have some heterogeneity. Interface engines haven't solved the problems, especially for organizations with hundreds of locations, all of which impacts on the risk equation of best-of-breed versus a total suite from one vendor.
The problem is in the displays. Sometimes the data structure is the issue. You can capture points as separate data on a single display, but if you look at isolated data, you don't get the comprehensive view. In a display theater, lab data come across as a blob, and you have to parse them, or they're lost in a world of partial integration. Standards are now more robust and have more clinical richness, but nomenclature is still an issue. Mapping terms across multiple systems is necessary, regardless of whether a facility has one EMR or multiple EMRs in place.
The idea of one-stop shopping belies the point that greater adoption of EMRs in general will lead to a lot of disruptive feedback. The convergence of automation with practice will alter meaningful use ends; there will be further modification of data structures of commercial systems. There is no perfect solution with single source. IT needs to remain alert to appropriate standardization versus inappropriate, and having physicians engaged with acquisition and evolution is imperative because of the necessity of proper configuration.