Call to Interoperability Action: What Would Amazon Do?
In reviewing a schematic diagram of the integration points of the imaging information systems of Kaiser Northern California (Oakland), Richard (Skip) Kennedy, MS, bewails the current state of point-to-point integration in health care. Not only is this approach inefficient, time intensive, and wildly expensive, it’s not working very well.
On March 22, 2012, Kennedy presented “The Blind Men and the Elephant: A Parable of Imaging IT Interoperability” at a Long Beach, California, regional meeting of the Society for Imaging Informatics in Medicine. In the presentation, Kennedy (who is technical director of imaging informatics, Northern California, Kaiser Permanente) explains not only why health-care IT should evolve, but why it must.
Figure In this representation of most of the imaging and imaging-support systems at Kaiser Northern California, each line represents a system-integration point for which an interface had to be built.
[Click on image to see full size] Over the Wall The reason Kaiser (along with nearly every other health-care enterprise in the United States) has found itself in this predicament is that many systems originated as stand-alone systems serving individual purposes. “We bought a RIS; maybe we have a billing interface. In some cases, in the past, we even wrote out a billing file, and then we tossed it over the wall; that was the model,” he explains. While Kaiser has a single integration engine (or interface broker) that attains most integrations, each one is implemented, from system to system, as a unique, point-to-point HL7 2.2 or 2.3 interface. In general, these interfaces are unidirectional and can’t inform the system on the other side if there is a problem. “As a result, those of us who work in IT spend an enormous amount of time clearing up queues, error logs, exception files, and the like of things that went over the wall and didn’t stick,” he explains. “These are all legacies, essentially, of building something that’s not changed its fundamental structure in well over two decades. We haven’t had a fundamental difference in this mechanism for a long time,” Kennedy says. The Compromise The problem with this approach is that it entails compromises that limit information access in a complex environment with multiple information systems.Beyond three or four systems, hundreds of interfaces could be necessary to share specified information from one system with multiple other systems. The problem becomes multiplicative, in effect. Kennedy offers the example of making available up-to-date and consistent creatinine values in the RIS, which many organizations do not do because they would have to build a creatinine interface. For this reason, “The radiologists don’t have all of the information they need to do their work,” he notes. Another problem is the inability to leverage structured content—for example, in obstetric interpretations, Kennedy says. “There is nothing sillier than watching a radiologist dictate head circumference on an obstetric study,” he suggests. “It’s there in the data. We should have solved this problem five years ago, but in most cases, we haven’t—because we haven’t built the structured-content system. We need point-to-point interface systems to support it.” Reporting Dose Kennedy’s final example pertains to the conference theme: complying with California’s new dose-reporting requirements under the Medical Radiation Safety Act of 2010 (originally SB 1237). Beginning July 1, 2012, all of the state’s health-care providers will be required to record the radiation dose for each CT exam. Kennedy notes that just one presenting organization reported an effective solution that did not require the manual entry of the dose data.“Most of us are not ready to report—at least, not in a form that isn’t manual,” he observes. Kennedy points out that the dose-summary page that many CT systems produce does not contain the necessary data. “This is a picture of data, and it is not useful unless you can actually decompose it,” he explains. “The silliest thing in the world is taking data like these, making them into a picture, and doing optical character recognition to get them back. Nobody else in IT, outside our area, would ever tolerate such a practice.” In contrast, Kennedy shares a DICOM Structured Reporting (SR) Radiation Dose Report, which contains the volumetric CT dose index and the dose–length product required by the Medical Radiation Safety Act. This is part of Kennedy’s strategy to meet the new law’s requirements, but he is struggling to make all of his CT systems capable of producing the DICOM SR object in time to meet the deadline, and he plans to implement a temporary solution. The Gospel of SOA Fortunately, imaging informatics is moving away from point-to-point interfaces and toward service-oriented architecture (SOA), and this trend is getting a boost from the Health Information Technology for Economic and Clinical Health Act. Kennedy says, “We are beginning to inherit some very good tools from outside imaging.” We are moving toward the mashup, Kennedy says: Instead of an interface for the RIS and another for PACS, the mammography reporting system, and the billing system, users need one interface to access multiple information systems. “We are going into meaningful use much more in this way, going from having PACS, RIS, and the electronic medical record (EMR)—maybe with good integration, maybe not—to the new view, which is that this is all EMR-wrapped content,” Kennedy explains. He continues, “In other words, the EMR is the single portal for almost all of this information. There will be some specialty use, obviously, for PACS and RIS (within the department), but most of us will get this information through the EMR, and that seems to be the trend. We’ve gone from silos to something that looks a lot more like Amazon.” Kennedy adds that Amazon is one of a number of Web companies showing interesting parallels to imaging informatics. For instance—without leaving your context or having to sign in again—you can locate anything in an inventory of several million items (by keyword or category); download digital purchases such as books, software,movies, or music;compare prices; order with one click; get a report on everything you’ve ever bought on the site; track purchases; or cancel an order, all from any Web-enabled device (with no training session required). Amazon is built entirely on SOA. Kennedy explains,“It turns out that every time you go to Amazon, you are doing about 100 service calls.” He urges IT departments to start thinking like Amazon, which sells more software than books. “We are not just in the process of turning out CT scans,” Kennedy says. “We are moving information around in a way very similar to Amazon’s way. Every time you have a new medical imaging informatics problem, ask this question: What would Amazon do? How would I solve the problem if I were a developer at Amazon, or if I were a software engineer at Amazon?” For a long time, health care has been able to hide its inefficiencies, but those days are over now. “We are currently running the Red Queen’s race; that is, we have to run twice as fast to stay where we are,” Kennedy notes, “and we are losing the race.”Cheryl Proval is editor of Radinformatics.com and Radiology Business Journal.More About SOA
“We worked in an interfacing environment that’s dedicated to building very professional, very custom-crafted Rolls Royce Phantoms, and we’re living in a world now, in health care, that can only afford an Accord. We’re not going to be able to spend $300,000 for interfacing anymore.”
—Richard (Skip) Kennedy, MS
In preparation for his presentation, Kennedy tried to figure out how many man-hours went into the nearly 50 interfaces linking his information systems (see figure).He gave up; he did, however, report that each HL7 interface took an average of six to nine months to complete. “We spend an enormous amount of time building these interfaces, and the sad thing is, frankly, about 90% of the content between these interfaces is all replicated: This is the same information we are sending from system to system, and that’s how we always have done it,” he says. “I am going to make an argument that this is a bad way of doing it, and that we have better ways to do it.”
Figure In this representation of most of the imaging and imaging-support systems at Kaiser Northern California, each line represents a system-integration point for which an interface had to be built.
[Click on image to see full size] Over the Wall The reason Kaiser (along with nearly every other health-care enterprise in the United States) has found itself in this predicament is that many systems originated as stand-alone systems serving individual purposes. “We bought a RIS; maybe we have a billing interface. In some cases, in the past, we even wrote out a billing file, and then we tossed it over the wall; that was the model,” he explains. While Kaiser has a single integration engine (or interface broker) that attains most integrations, each one is implemented, from system to system, as a unique, point-to-point HL7 2.2 or 2.3 interface. In general, these interfaces are unidirectional and can’t inform the system on the other side if there is a problem. “As a result, those of us who work in IT spend an enormous amount of time clearing up queues, error logs, exception files, and the like of things that went over the wall and didn’t stick,” he explains. “These are all legacies, essentially, of building something that’s not changed its fundamental structure in well over two decades. We haven’t had a fundamental difference in this mechanism for a long time,” Kennedy says. The Compromise The problem with this approach is that it entails compromises that limit information access in a complex environment with multiple information systems.Beyond three or four systems, hundreds of interfaces could be necessary to share specified information from one system with multiple other systems. The problem becomes multiplicative, in effect. Kennedy offers the example of making available up-to-date and consistent creatinine values in the RIS, which many organizations do not do because they would have to build a creatinine interface. For this reason, “The radiologists don’t have all of the information they need to do their work,” he notes. Another problem is the inability to leverage structured content—for example, in obstetric interpretations, Kennedy says. “There is nothing sillier than watching a radiologist dictate head circumference on an obstetric study,” he suggests. “It’s there in the data. We should have solved this problem five years ago, but in most cases, we haven’t—because we haven’t built the structured-content system. We need point-to-point interface systems to support it.” Reporting Dose Kennedy’s final example pertains to the conference theme: complying with California’s new dose-reporting requirements under the Medical Radiation Safety Act of 2010 (originally SB 1237). Beginning July 1, 2012, all of the state’s health-care providers will be required to record the radiation dose for each CT exam. Kennedy notes that just one presenting organization reported an effective solution that did not require the manual entry of the dose data.“Most of us are not ready to report—at least, not in a form that isn’t manual,” he observes. Kennedy points out that the dose-summary page that many CT systems produce does not contain the necessary data. “This is a picture of data, and it is not useful unless you can actually decompose it,” he explains. “The silliest thing in the world is taking data like these, making them into a picture, and doing optical character recognition to get them back. Nobody else in IT, outside our area, would ever tolerate such a practice.” In contrast, Kennedy shares a DICOM Structured Reporting (SR) Radiation Dose Report, which contains the volumetric CT dose index and the dose–length product required by the Medical Radiation Safety Act. This is part of Kennedy’s strategy to meet the new law’s requirements, but he is struggling to make all of his CT systems capable of producing the DICOM SR object in time to meet the deadline, and he plans to implement a temporary solution. The Gospel of SOA Fortunately, imaging informatics is moving away from point-to-point interfaces and toward service-oriented architecture (SOA), and this trend is getting a boost from the Health Information Technology for Economic and Clinical Health Act. Kennedy says, “We are beginning to inherit some very good tools from outside imaging.” We are moving toward the mashup, Kennedy says: Instead of an interface for the RIS and another for PACS, the mammography reporting system, and the billing system, users need one interface to access multiple information systems. “We are going into meaningful use much more in this way, going from having PACS, RIS, and the electronic medical record (EMR)—maybe with good integration, maybe not—to the new view, which is that this is all EMR-wrapped content,” Kennedy explains. He continues, “In other words, the EMR is the single portal for almost all of this information. There will be some specialty use, obviously, for PACS and RIS (within the department), but most of us will get this information through the EMR, and that seems to be the trend. We’ve gone from silos to something that looks a lot more like Amazon.” Kennedy adds that Amazon is one of a number of Web companies showing interesting parallels to imaging informatics. For instance—without leaving your context or having to sign in again—you can locate anything in an inventory of several million items (by keyword or category); download digital purchases such as books, software,movies, or music;compare prices; order with one click; get a report on everything you’ve ever bought on the site; track purchases; or cancel an order, all from any Web-enabled device (with no training session required). Amazon is built entirely on SOA. Kennedy explains,“It turns out that every time you go to Amazon, you are doing about 100 service calls.” He urges IT departments to start thinking like Amazon, which sells more software than books. “We are not just in the process of turning out CT scans,” Kennedy says. “We are moving information around in a way very similar to Amazon’s way. Every time you have a new medical imaging informatics problem, ask this question: What would Amazon do? How would I solve the problem if I were a developer at Amazon, or if I were a software engineer at Amazon?” For a long time, health care has been able to hide its inefficiencies, but those days are over now. “We are currently running the Red Queen’s race; that is, we have to run twice as fast to stay where we are,” Kennedy notes, “and we are losing the race.”Cheryl Proval is editor of Radinformatics.com and Radiology Business Journal.More About SOA
- A conversation with Werner Vogels. ACM Queue. http://queue.acm.org/detail.cfm?id=1142065. Published May 1, 2006. Accessed April 8, 2012.
- The practical guide to SOA in healthcare: version 1.0. http://hssp.wikispaces.com/PracticalGuide. Accessed April 8, 2012.
- Healthcare Services Specification Project (HSSP).http://hssp.wikispaces.com/. Accessed April 8, 2012.
Cheryl Proval,
Vice President, Executive Editor, Radiology Business
Cheryl began her career in journalism when Wite-Out was a relatively new technology. During the past 16 years, she has covered radiology and followed developments in healthcare policy. She holds a BA in History from the University of Delaware and likes nothing better than a good story, well told.