FREE Health Data Management e-newsletter 
Systems Integration: The Electronic Records Linchpin
Health Data Management Magazine, May 2005
Just like a linchpin is used to hold together a complex set of parts, systems integration technology bands together the clinical applications needed to create an electronic medical record. The technology enables CIOs to facilitate data sharing among information systems or present disparate data in a common application.
Advertisement
Deceptively simple
What clinicians see when they access electronic records is a deceptively simple view of an information technology infrastructure. Data is neatly arrayed in columns and tables, and a few mouse clicks can set off an amazing chain of events-lab tests are ordered; radiology images pop up on screen; prescriptions are checked and sent to the pharmacy in a matter of seconds.
Typically, though, electronic records users don't know the effort required to get all the information from disparate systems in one place at the same time.
For example, do clinicians using the electronic records system at Montefiore Medical Center know that their single view of clinical and demographic data requires more than 400 interfaces to operate? Or that each time they click "send," bits and pieces of data are being parsed to numerous information systems through the delivery system's interface engine?
On a mission
"We used to joke that our bathrooms would be paperless before our nursing units. But when we decided to implement an electronic record, we really went on a mission with our information systems," says Jack Wolf, Montefiore's CIO. The Bronx, N.Y.-based, two-hospital delivery system uses Carecast electronic records software from Burlington, Vt.-based IDX Systems Corp. and an interface engine from Software Technologies Inc., Monrovia, Calif. "If you really want to create a seamless electronic record, there is an enormous amount of work to be done before that's even remotely possible."
Behind every successful electronic records implementation is a backstory of systems integration-a tale full of inspiring highs and depressing lows, heroes and villains, treasure in the form of clinical data and sometimes vendor paychecks.
If the industry is serious about widespread adoption of electronic records, this is a story that will be told again and again. CIOs and I.T. experts agree that integration technology-coupled with increased and uniform use of messaging standards-has made systems integration a more manageable task.
Still, there are many hurdles-some technological, others conceptual-before integration delivers the type of seamless electronic medical records systems proponents envision as being standard technology.
The rise of electronic medical records systems is causing is a shift in the industry's approach to systems integration, says Wes Rishel, vice president and research area director at Stamford, Conn.-based Gartner Inc. Rishel also serves on the board of directors at Ann Arbor, Mich.-based Health Level Seven, which develops the health care industry's de facto electronic data interchange messaging standards.
Many health care organizations still treat systems integration as an afterthought to be addressed using ad hoc techniques late in the stages of implementing or upgrading an application, according to Rishel. Gartner refers to this approach as "pick up sticks" integration. Like the child's game, each integration project is designed to cause the least disturbance to the pile of applications, interfaces and existing business processes.
"The most common approach even today is using proprietary-and sometimes obscure-communication protocols to move data from one system to a file server and then into another system," Rishel says. "That might work fine when passing info back and forth between information systems, but now there is a person viewing that data who needs to look at information from multiple systems in one window, and also needs to perform transactions based on that data.
"That requires systems integration based on workflows and business processes. Instead of point-to-point connections, organizations need to use integration strategies that provide the flexibility to integrate data in a user interface."
Service architecture
Some organizations are starting to tackle systems integration using a concept called "service oriented architecture." Service oriented architectures are designed to couple together interacting software agents, or business components. They utilize a set of simple interfaces that can be re-used across different computing platforms and messaging standards.
The engineering discipline breaks up application business logic into a set of granular "services"-chunks of programming that provide business functionality-that may be used by different applications.
CIOs and other I.T. executives are finding that "pick up sticks," by comparison, does not provide the flexibility required to support electronic records systems, especially in light of the push to create interoperable electronic records. The problem is that one size does not fit all when it comes to systems integration, says Darren Dworkin, chief technology officer at Boston Medical Center.
The typical clinical messaging strategy has been to enable little systems to feed information into big systems, such as clinical data repositories or hospital information systems. But that strategy doesn't work well in an environment designed to support physician workflow, Dworkin contends.
"There was a time when we thought the best strategy was to interface all our systems and present all the data we had to physicians-but physicians pushed back," Dworkin says. "What they really need is `simplified' data they can process quickly."
So Boston Medical Center, like an increasing number of provider organizations, is implementing a Web-based physician portal instead of a "full-blown" electronic record. The portal provides summary data to physicians at the point of care while still enabling access to back-end systems.
To do so, the delivery system is using an integration platform from Cambridge, Mass.-based InterSystems Corp. to quickly integrate information and business components of disparate information systems.
The Ensemble product provides more than 250 pre-built "adapters," or programming blueprints, for interfacing commonly used information systems. The integration platform also includes "data transformation" services that help Boston Medical I.T. staffers technologically bridge differences in data schemas in disparate applications.
The platform has enabled the medical center to link information from various systems into a physician "to do" list that is available via the online portal. Caregivers can get summary information from the portal, as well as more detailed information-including radiology images-by using tools from the "native" back-end applications.
Having pre-built blueprints is crucial to Boston Medical Center because the delivery system follows the best-of-breed technology strategy, Dworkin says. The strategy allows the organization to pick what it believes to be the best information systems in each of the various clinical areas. However, this approach makes it more difficult to quickly integrate disparate systems, he says.
A need for speed
"One of the reasons we need an integration platform is the amount of time-and money-it takes to get vendors to the table and create interfaces among their information systems," Dworkin says. "We need to provide functionality quickly-our physicians don't want to wait six months while we figure out how to transfer data from a data field in one system to a field in another. Vendors are using more open architectures and making integration easier. But it's still not easy, and it's not fast."
The speed-or lack thereof-of systems integration has become an important factor in the development of electronic medical records systems, says Marty Botticelli, executive director for information systems at New England Baptist Hospital, Boston.
New England Baptist provides "different levels" of an electronic records system to various departments at its facilities. It also has installed an order entry system to enable clinicians to enter, edit or cancel drug and treatment orders, as well as review orders from separate departments. The order entry software is from New England Baptist's hospital information system vendor, Medical Information Technology Inc., Westwood, Mass.
In the past, getting information for mapping data from one information system to another has been a major integration hurdle for the delivery system, Botticelli says.
"Everyone who has done traditional interface and integration work has done the same thing with vendors over and over-sitting down and mapping out fields on a one-to-one basis, devising a method to interface, and then relying on the vendors' programmers to make it work," he says. "Then you sit back and watch the project keep missing its deadlines. But with an electronic record, there's limited time to get this information to clinicians-you can't redesign a workflow process and then wait a few months before implementation."
To speed the integration process, New England Baptist is using the Boston Workstation from Boston Software Systems.
The workstation creates interface "scripts" that enable programmers to quickly link specific data fields between applications. It identifies the structural details of an application and enables a programmer to build commands to make software components from one system interact with those from another.
Writing the script
The delivery system recently used the tool to integrate disparate scheduling applications with its hospital information system. The integration enables the information from the scheduling system to move to the Meditech system and from there to ancillary systems such as laboratory or radiology.
"The big advantage is that we've drastically cut down the amount of time it takes to standardize data elements and get information flowing from one system to another," Botticelli says. "We still use a traditional interface engine to send some data to and from our hospital information system. But the workstation gives us the flexibility to link systems, or specific fields in systems, very quickly without having to spend months trying to get vendors to work together."
Health care I.T. vendors, however, aren't solely to blame for the slow pace of the transition from point-to-point interfaces to service oriented architectures, says John Quinn, vice president and chief technology officer for the health care practice at Capgemini Health, a division of New York-based consulting firm Capgemini.
Many provider organizations get weak in the knees when facing the prospect of reworking their system interfaces to support clinical process automation, says Quinn, who also chairs HL7's technical steering committee.
"Everyone by this point has purchased an integration broker, and now that they have working interfaces, they don't want to touch anything-they've learned that it hurts to touch, and it costs a lot of money," he says.
Still, the reluctance on the part of vendors and providers to truly tackle systems integration is decreasing, Quinn says, because of the pressure to start moving structured data from one facility to the next, as well as among different types of electronic records systems.
"Many organizations have adapted HL7 and other messaging formats to fit their internal integration needs," he says. "But they are starting to come around to the idea that they have to start adhering to messaging standards-and start using standard nomenclatures such as SNOMED and LOINC-if they are truly going to integrate information systems to enable electronic medical records to be interoperable."
But requiring strict adherence to industry standards requires a "traffic cop" to ensure all the players in data transmission are playing by the rules. In time, that role may be filled by the federal government or entities managing the operation of regional health information networks, popularly known as RHIOs. In the meantime, some companies, in the interest of systems integration, are filling that void.
Cincinnati-based HealthBridge, for example, operates a health care network that acts as a third-party conduit between hospitals and providers in the greater Cincinnati region in Ohio, Kentucky and Indiana. The company provides remote access to 28 hospital clinical applications and delivers more than 940,000 clinical results per month to 2,900 physicians.
The HealthBridge network uses clinical messaging software from Tampa, Fla.-based Axolotl Corp. to deliver results. It also has embarked on systems integration initiatives with a number of small group practices to link practice-based electronic records systems with information systems from local hospitals.
Feeding time
The hospitals send data feeds from their information systems to the Axolotl messaging software. From there, the information is sent via file transfer protocol into the electronic medical records systems of group practices that have established interfaces with the HealthBridge network. And when patients receive care from specialists and other physicians, the practices' electronic medical records are updated with data from a community data repository.
Healthbridge has created interfaces among electronic records software from 16 different vendors, says Bob Steffel, CEO.
Not every practice has implemented an electronic records system; many physicians who use HealthBridge's services prefer to access results from Web-based message portals.
HealthBridge was able to interface the disparate systems by getting hospitals to transmit data in standard formats using HL7 and the Logical Observation Identifier Name Codes, or LOINC, which standardize the exchange of clinical laboratory results.
"Standardizing our message formats wasn't easy," Steffel says. "Hospitals have their own internal versions of HL7, and the electronic records vendors weren't too thrilled to help us create interfaces, since that's often a lucrative side business for them."
Vendors and hospitals, though, have since warmed to the idea of using standard messaging formats, Steffel adds.
The hospitals found that the initial disruption caused by using a "community" HL7 standard enabled them to interact with more physician practices without trying to design interfaces to each groups' information systems. And the vendors that have interfaced with Axolotl have found that the HealthBridge integration is a strong selling point for their software.
"We have seen a surge in physician interest in electronic records software over the past year," Steffel says. "I'd like to think that some of that interest is based on the fact that they now can integrate with the hospital networks and get all the data they need to support their workflow."
Sidebar
Putting integration into context
Many organizations feel they've crossed the finish line when they integrate back-end applications to create an electronic medical records system. But even at that point, a little something extra often is needed to make the whole package more palatable to caregivers.
NYU Medical Center, New York-which comprises Tisch Hospital, Rusk Institute of Rehabilitation Medicine and New York University School of Medicine-has spent the past few years integrating and interfacing systems to start feeding two electronic records systems and a self-developed clinical data repository.
NYU is deploying the Sunrise Clinical Manager XA electronic records system from Boca Raton, Fla.-based Eclipsys Corp. for its inpatient facilities. In addition, its affiliated group practices are using an ambulatory records system from Milwaukee, Wis.-based GE Healthcare Inc.
To top it all off, NYU Medical Center is using technology from Andover, Mass.-based Sentillion Corp. to streamline the use of electronic records by physicians. The reason? Even with an electronic records system, clinical data is still "all over the place" and needs to be put in some semblance of order before physicians can use it, says Pravene Nath, M.D., NYU's assistant director of clinical informatics.
To bring order to its clinical data, NYU Medical Center installed Sentillion's clinical context management and single-sign-on software. The applications use the Clinical Context Management Specification, developed by Ann Arbor, Mich.-based Health Level Seven Inc. The standard enables a user to log in to multiple systems-based on the "context" of their needs-using a single user name and password.
For example, a physician may want to view the clinical information of a particular patient. When the physician selects that patient in one application, the Sentillion software recognizes the context of the information request and opens other applications that contain information on that patient.
The information is not actually pulled from other applications, Nath explains. Instead, physicians are looking at the patient information in the back-end system. If they want more information, they can use tools from the back-end system. In addition, tabs on the screen enable users to toggle between the inpatient and outpatient records systems while maintaining the context of the information.
Sidebar
Conducting the orchestra
The health care industry is just beginning to change their systems integration strategies to incorporate the concept of service oriented architecture. And it won't be long before the concept leads to new methods to "orchestrate" business processes via integration, according to integration technology vendors and industry experts.
Service oriented architectures are designed to couple together interacting software agents, or business components. They utilize a set of simple interfaces that can be re-used across different computing platforms and messaging standards.
While the concept may sound abstract, it is widely used in other industries and making inroads in health care, says Jim Demetriades, founder and CEO of SeeBeyond Technology Corp., Monrovia, Calif. Morever, its impact on the industry could be significant. "Service oriented architecture is the next broad technology shift, and it will be more revolutionary than the shift from a mainframe to a client-server environment," Demetriades predicts.
Part of this burgeoning shift to service oriented architectures is the realization by health care organizations that systems integration is, at heart, designed to coordinate data in a way that supports clinical workflow and business processes, says Wes Rishel, vice president and research area director at Stamford, Conn.-based Gartner Inc.
"Provider organizations have to integrate information systems with the idea that each product adds up to more than the sum of its parts," Rishel says. "A lot of integration work being done at large facilities is focused on developing portals that fan out across many applications. That is a distinct difference from the typical interface engine approach to systems integration. Portals are the first step in developing a true integration platform and service oriented architecture."
Another reason for the shift is the realization that applications and data will need to be shared with other provider and payer organizations, Demetriades says.
"We used to think of software packages as programs, but they're really a bundle of services that can be interoperable and interchangeable. An organization can take all the unique technology they've designed and reuse it not only within their facilities but with their business partners."
The process for admitting patients to a hospital, for instance, varies widely across the industry. A service oriented architecture enables a facility to design a "best practices" admission process and share the resulting application with other facilities.
Blueprints
"Because the software services can be reused in other computing environments, one hospital could send a blueprint of the process-interfacing with a payer's claim at this point, checking an information system at another point-to another hospital," Demetriades explains.
However, the move toward service oriented architectures likely won't lead to a spending boom by health care organizations, says Trevor Matz, managing director at InterSystems Corp., Cambridge, Mass. Advances in systems integration technology are spurring providers and payers to try to get more out of their existing information systems instead of buying or creating new software, he adds.
"There is so much valuable information being passed around that's not getting used. So organizations are trying to get more bang for their buck, or more `bend' out of their back-end systems," Matz says. "I.T. staffs are trying to find ways to tap into the real-time information that's being transmitted by their systems to transform that data into business intelligence."
Sidebar
Mobility matters, but how much?
Wireless networks and mobile software now factor into many information technology initiatives, including systems integration. But some organizations are unsure how large a role the technologies will play in their march toward an electronic medical records system.
Northeast Medical Center Hospital, Humble, Texas, is rolling out a suite of mobile applications from Brighton, Mass.-based PatientKeeper Inc. The applications enable physicians to use PDAs or smart phones to access lab and test results and other rounding information. The mobile software is interfaced with Northeast Medical's hospital information system.
Interfacing the mobile applications with the hospital system has been relatively easy, says Carla Maslakowski, CIO, compared with the struggles the hospital has had to integrate back-end information systems. "The PatientKeeper staff came in and helped us set up an interface very quickly, a task that in my experience with other vendors would have taken months," she says.
The hospital information system feeds data to the mobile software via a one-way interface that uses messaging standards from Ann Arbor, Mich.-based Health Level Seven Inc. But Northeast Medical plans to create a bi-directional interface once it has the mobile applications up and running enterprisewide.
Maslakowski, however, says that task will be tougher than it should be.
"The mobile platform has a very open architecture and is easy to work with, but I'm not sure how helpful our HIS vendor is going to be when it comes to increased integration," she says. "It is coming out with its own electronic medical records software and is worried that PatientKeeper is going to move in on that territory."
Northeast Medical is "on a journey" toward an electronic record, Maslakowski adds. "We're about a third of the way there. The mobile applications are part of the foundation we're trying to build."
But mobile platforms aren't necessarily the solution to systems integration headaches, says James Christie, CIO at Alexian Brothers Hospital Network, Elk Grove Village, Ill. The hospital has implemented mobile patient management applications from MercuryMD Corp., Research Triangle Park, N.C.
"Mobile platforms are a strategic opportunity to provide physicians with easier data access. But you have to go through the steps of systems integration before you can really take advantage of a mobile platform. Such mobility is a building block to an electronic medical records system."
For Alexian Brothers, the mobile software and platform are part of a larger effort to consolidate systems and build its infrastructure on a single application architecture. "We want to build an electronic record based on software that uses open standards and architecture, and mobile applications fit that requirement."
Sidebar
Shakespeare had it right
Editor's Note: "What's in a name? That which we call a rose, by any other name would smell as sweet." Put another way: "You say po-tay-to, I say pa-tah-to." Either way, we're talking about the very same thing.
And this is why in Health Data Management and sister publication Mobile Health Data we only use the term "electronic medical records system," which we sometimes shorten to "electronic records."
The health care I.T. industry uses various terms to label this comprehensive collection of clinical information systems. Such terms include computer-based patient records system, computerized medical records, electronic health records system, longitudinal patient records software and so on.
One of the fundamentals of being a journalist is to communicate clearly. And this is why we only use the term electronic medical records system. "Electronic" is a word the general public clearly understands to signify the use of computers to automate processes or information. "Medical records" is the longstanding industry term for referring to the cumulative materials that make up a patient's health care history. And "system," as defined by trusty ol' Merriam-Webster, is "a group of devices or artificial objects or an organization forming a network especially for distributing something or serving a common purpose."
Hence, electronic medical records system.
During the past 11 years, myriad providers, vendors, association executives and consultants have explained to me (sometimes in painful detail) why they employ the term they use for this technology-and why they feel the term we use in HDM is "wrong." Frankly, I have yet to hear a persuasive argument for making any distinction among the varied terms.
We find "electronic medical records system" to be a clear, accurate and easy-to-understand phrase that effectively describes the collection of information systems that together make up an electronic record. We also find using multiple terms to describe the same thing can be confusing, which is counterproductive to communicating clearly.
As journalism icon Dan Rather once said, "If it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck."
- Bill Siwicki, Editorial Director
