Health Care's Napkin Network

By Baselinemag  |  Posted 2002-02-04

PDF Download John Halamka and John Glaser stood overlooking New Orleans' legendary Bourbon Street from the balcony of the Royal Sonesta Hotel. Below, knots of revelers were getting an early start on Mardi Gras, set to begin the next morning. It was a strange venue for the group assembled on the balcony that night. These chief information officers from major Massachusetts health care companies had gathered in New Orleans for a symposium on the security of electronic patient records and medical information systems.

Cost out a data exchange network (Excel)
A time line for implementation (Microsoft Project 98 file).
PDF download of both
Although security was the official topic, an ominous cloud hung over their heads. Two years earlier, President Bill Clinton had signed into law the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Part of that law established the requirement that health care enterprises that did any business with federal health care agencies, such as Medicare, had to adopt and implement by fall 2002 a common format for electronic transactions. Congress had selected the American National Standards Institute's x.12 standard (ANSI x.12) as the appropriate format for managing electronic records. The law also mandated that these networks—since they would carry sensitive data about patients, their sicknesses and their treatments—be secure.

It was against this backdrop that health care CIOs and CTOs from across New England sipped their drinks and chatted over the Mardi Gras noise above Bourbon Street that night in 1998.

Suddenly, for the first time, the health care industry faced a drop-dead deadline to solve two challenges that had bedeviled it for the past decade:

  • How to adopt and switch over to a single standard for exchanging medical data electronically, and

  • How to keep transmission of that data between vendors, payers, providers and government agencies safe from prying eyes, while still keeping it affordable and accessible for those with the right to have it.

    Many of the companies in New Orleans that night had toyed with developing their own software for complying with HIPAA. Others were hoping software vendors would come up with a solution in time. But for all, the HIPAA deadline was a sword hanging over their heads. And the penalties for failing to comply ranged from hefty monetary fines to jail time.

    This group of pragmatic technology executives, which came to call itself the Bourbon Street Coalition, wasn't about to wait for years to go by before finding a way to comply. It was ready to find a solution, immediately.

    Even as health care payment organizations such as Blue Cross and Blue Shield would seek to push the need for compliance beyond 2002, Halamka, Glaser and cohorts would find a way to be up and running by the end of 1998—almost four years ahead of time. This is the story of the secure patient information network sketched out on a napkin at Mardi Gras 1998—and why this group of health care executives could find a system that worked without major pain or investment, while other institutions pleaded for more time.

    Had Come">

    An Idea Whose Time Had Come

    The industry's foot-dragging can be hard to grasp when the benefits of electronic networks to hospitals and other institutions can be so tangible.

    For years, the health care industry had calculated that transaction networks were the best way to trim spiraling administrative costs. For instance, of the $1 trillion spent on health care in the United States in 2000, more than $250 billion was chalked up to administrative overhead, rather than patient care.

    Early attempts in the 1990s to create health care networks often failed because of the difficulty of creating and maintaining central databases from which a wide range of hospitals and insurers could retrieve and exchange information. Later attempts at deploying computer systems also worked against compliance with HIPAA. That was because many health care companies had relatively fresh investments in proprietary hardware and software. To create new systems for exchanging data could mean big write-offs on existing systems—and significant expense, to boot.

    In 2001, almost a half-decade after HIPAA became law, medical insurers such as Blue Cross and Blue Shield (BCBS) were still arguing to the U.S. Department of Health and Human Services for more time, and were granted a 12-month extension for full compliance, to October 2003. Blue Shield companies that collectively provide health care coverage for more than 81.5 million—one in four—Americans, applauded the extension.

    "The one-year extension passed by the House and Senate," said BCBS CEO Scott Sereta, "will better enable the health care community to build, test and successfully implement the new transactions and code sets required by HIPAA." Among Blue Cross' ( concerns: That patients could object that the consent they give to sharing of their records does not cover the broad exchanges of data that are likely to occur electronically.

    Even the extra time may not translate into compliance. A 2001 survey of the health care industry by consultancy Gartner Inc. found that fully 85% of hospitals and other health care providers had yet to complete assessments of whether they could even conduct basic electronic transactions with other institutions. In that survey, Gartner health care industry analyst Matt Duncan says he expects 70% of insurers who pay for health care will not be fully compliant with HIPAA standards on how transactions should be conducted—even by the end of Q3 2003. Conformance, he says, is often considered a "nuisance."

    "It's (seen as) government sticking its nose in where it doesn't belong," Duncan said in October.

    There's also the fear that medical networks, if they used a common format for exchanging data, could pose a security risk. Glaser says that what companies feared most was flunking what he calls the Boston Globe test. "No one wanted to wake up one morning and read on the front page of the Boston Globe that some hacker had broken into the patient-records database," Glaser says.

    The logistics of safely exchanging such sensitive personal data in a common format seemed to all involved to be expensive, risky and organizationally overwhelming. Consequently, progress had been slow, halting, decentralized and largely ineffective.

    "It came down to a matter of 'Okay, but you go first,' " says Glaser, the CIO of Partners HealthCare, a major Massachusetts health care provider.

    Leaning over the balcony at the revelers below, Halamka and Glaser began to talk.

    A few months earlier, Glaser had hired an El Segundo, Calif., consulting firm, Computer Sciences Corp. (CSC), to develop a fast and inexpensive way for Partners to automate its patient information and ramp up for HIPAA.

    CSC partner Greg DeBor was there that evening, and joined the two men on the balcony. He told Halamka that CSC had been working on some promising middleware using Internet transmission protocols, but which worked over private networks. He believed these protocols, even if they originated on public networks, could act as a common bridge or gateway between Partners' legacy systems and health insurance payers … or multiple hospital systems.

    "We started to think, instead of trying to comply separately, why not do it together?" said Halamka.

    Halamka and Glaser represented two of the Boston area's largest and most complex health care providers. And, each man brought to the table extensive credentials. Halamka, 39, was CIO of CareGroup, which operates six hospitals: Beth Israel Deaconess Medical Center, Mount Auburn Hospital, New England Baptist Hospital, Deaconess-Waltham Hospital, Deaconess-Glover Hospital and Deaconess-Nashoba Hospital. Halamka is also associate dean of the Harvard Medical School.

    Partners HealthCare, where Glaser works, operates Massachusetts General and several other hospitals in the same area. He holds a Ph.D. in health care information systems and was the founding chairman of the College of Healthcare Information Management Executives.

    Both men sought an efficient and affordable way to comply with HIPAA while at the same time fully automating the increasingly complicated and expensive relationship between providers and insurers, who were also represented on the balcony that night.

    DeBor, Halamka and Glaser invited the other CIOs and CTOs sipping their drinks that night to a sit-down. They sketched out a plan on napkins.

    Pen stroke by pen stroke, the sketch of a rudimentary network took form. What emerged was the picture of a relatively simple and secure "peer to peer" computer network, just like those that would soon be used to exchange music files over the Internet.

    Under the plan, members would be able to maintain all of their existing systems, software and workflows. Members wouldn't spend a fortune on new software.

    Companies would continue to maintain patient records on their own individual databases, avoiding the creation of a central storage spot that could invite scrutiny or hostile attacks from outsiders. Since the peer-to-peer network would operate over leased lines only, it avoided the main risk of the Internet: public communications lines.

    The so-called Bourbon Street Coalition would return to Boston with what it felt was an achievable plan to form a medical records network built upon the x.12 standard. That standard specified the information that needed to be exchanged to complete transactions between providers and payer and, as a fringe benefit, would also bring each member into compliance with HIPAA mandates.

    The system would be tested first by five companies: three health care providers—CareGroup HealthCare System, Partners HealthCare System and LifeSpan—and two payers, Harvard Pilgrim HealthCare and the Tufts Health Plan. The official name for the consortium would be the New England Healthcare EDI Network (NEHEN).

    to Network">

    60 Days from Napkin to Network

    When the Mardi Gras meeting of the coalition broke up, the key players each had their napkin-diagrams tucked into their shirt pockets. The next day they headed back to New England and began the work of implementing the vision.

    Coordinating the efforts would be Halamka, Glaser and CSC's DeBor. Five distinct entities—each with its own workflows, hardware and software, each with offices, clinics and/or hospitals scattered across hundreds of square miles and different hardware and software—would have to be knitted into a reliable and secure peered network.

    DeBor and CSC would act as the project's facilitator, handholder, arbiter and traffic cop.

    "The hardest part was coordinating the adoption and implementation process between the first five companies and keeping them each up to speed," says DeBor. "Some were further along than others. Partners had a bit of a head start on this so the other trading partners had to catch up."

    Once CSC had mapped an implementation path for each player, the company moved directly to perfecting the middleware it had originally begun developing for Partners. Now it had to serve the full range of providers and payers that would rely on it to pass data securely and reliably among them.

    "Our approach was to design the middleware from the lowest common denominator of the technology," DeBor says. "It had been made clear by everyone around the table that night that none of them wanted to make million-dollar investments to test a concept. And none of them wanted anyone dictating to them any particular sets of tools or software packages to make all this happen. Everyone had a common interest in a lightweight middleware layer. And that's what we designed for the NEHEN gateway."

    This meant using Internet communication protocols—the Transmission Control Protocol and the Internet Protocol, a.k.a. TCP/IP—even though the communications would be on private lines.

    Once the middleware layer was tested and in place, each member faced the biggest task—getting the required data out of their proprietary formats.

    CSC helped each hospital group identify the individual data sets to be implemented, as well as the data sets it had to retrieve from its systems, and then figure out how to translate that data from its nonstandard formats into the ANSI x.12 standard that the NEHEN middleware would recognize, DeBor says.

    Extracting the data "is where it got complicated," DeBor says. "What happens here depends entirely on what proprietary software the member uses. But when we got started, the version of a popular patient information management program, IDX, was an older version than the one that would be required by HIPAA. It spit out the data in ANSI x.12 format, but in an older version than the one we needed at the time. The extraction process was done, but [some members] still had to do a light translation process in order to convert the old ANSI format into the new one."

    For others, such as Beth Israel Deaconess, the data had to be extracted from their existing databases one field at a time and translated into the ANSI x.12 format.

    Proprietary vendor systems other than IDX's—such as one from Siemens Medical Systems—required an add-on module or service subscription for EDI. "The IDX approach was a no-brainer. Some of the other ones are less straightforward," DeBor says.

    Once the data got extracted, the provider still had to translate and transmit it. "Again the provider was faced with a 'build or buy' option," DeBor says.

    An elegant solution: interface engines that would broker the data as it moved from one computer to another. Popular tools for this included SeeBeyond's e*Gate, QuoVadx's Cloverleaf and Sterling Commerce's Gentra, DeBor recalls. But these packages were not cheap, costing $150,000 or more.

    Another option for the interface engine was a "translator" that could handle the mapping and remapping of the data from one format to another. Possible translators included TSI's Mercator and Orion's Symphonia.

    "The other interfacing option was the 'roll your own' approach," DeBor says, "either with internally developed application programming" or using a more generalized application integration tool like IBM's MQSeries.

    Once the extraction and translation was complete, the data package moved to the NEHEN middleware with sender and receiver tags attached.

    "When you send a letter through the U.S. Post Office they don't care what you stuff inside the envelope but they do want some basic information on the outside," DeBor says. "That's the best way to think of NEHEN middleware. It does not care what you stuff in the data envelope, it just wants you to tag it with the required recipient and sender tags."

    Costs Come Tumbling Down

    Besides acting as a post office, the NEHEN middleware also took on some processing abilities as the needs of certain members became clearer. "Some early processing is done right within the gateway," says DeBor.

    Requests for information are not sent to all members of the network. Instead, the middleware first inspects the request tags and determines what peer device is most likely to have the information. It then sends on the query to only those devices. As each device provides its information, the middleware aggregates it and, when complete, sends it back to the requester.

    Most important, the middleware sent back results. When the network went live 60 days following the Bourbon Street meeting, it began producing tangible savings immediately, reducing the cost of each exchange of data.

    Halamka says that at CareGroup the cost of each eligibility check was trimmed from $4.74 per inquiry to just 15 cents. And at Partners, Glaser says costs went from $2.64 to 10 cents per eligibility check.

    DeBor credits the success—human and technological—with the fact that the Bourbon Street Coalition set down clear markers and stuck to its founding principles. "Keep it simple," DeBor says. "That was the prime directive from the start. Keep the cost of entry low. And be minimally intrusive to the member's established operations."

    The success experienced by the first five NEHEN members was rapid and convincing. By October 1998, six months after the New Orleans meeting, the system was already handling 50,000 eligibility transactions a day, notes Halamka.

    Before NEHEN, the call centers of health care payers took an average of 15 minutes per request, as they checked their own records to verify that a patient was indeed insured by them. Health care providers often skipped the verification process and instead just sent the bill to the patient's insurance company. This resulted in a high volume of denied and contested claims, increasing administrative costs for both providers and payers.

    All of that changed when the NEHEN network went live. Suddenly, verifying the treatment eligibility of a patient was reduced to keying identification information into the NEHEN network and pressing Enter. Approval or denial came within as little as two seconds.

    In October 1998, monthly transaction volume for eligibility checks across the NEHEN network was just under 12,000. A year later, it was more than 71,000. And, by the end of 2000, it had jumped to more than 12,000 a day.

    The rollout was not without its problems. But they were less technical than organizational, DeBor contends.

    The companies involved were used to functioning unilaterally and did not take easily to suddenly having to worry about their NEHEN partners' operations as well as their own. "We would have situations such as an emergency room trying to verify a patient at 2 a.m., only to discover that the insurer's system would not respond because that was when they had always scheduled their backups," DeBor says.

    Another problem surfaced when some companies decided to send requests in batches rather than one by one. "The system worked fine for individual files, but some users preferred to send their requests in batches," DeBor says. "Some of the recipients' systems were not ready for that. So the requesters would be standing around waiting for the response, assuming it would come quickly, only to find out that the sender's system was not set up to process batch requests." An update to the middleware, coming soon, will provide for batch processing.

    Keeping the providers and payers on the same deployment timeline also proved problematic. "Payers wanted to deploy different features on their own timeline," says DeBor. "But, of course, the providers wanted the payers all up and running at the same time so they had continuity across all payer systems."

    Insurers also saw savings, thanks largely to fewer denials of services already rendered. Before joining NEHEN, Harvard Pilgrim reported more than $1 million a year in losses due to the intake, treatment or contested claims of nonqualifying members. One year after implementing NEHEN's online verification system, the same line in the company balance sheet showed a $1 million savings in verification-related expenses, according to Halamka.

    The benefits that accrued to the founding partners were so profound that NEHEN's ranks began to swell, as payers and providers lined up for membership. By the beginning of 2001, insurer members of NEHEN covered more than 60% of the insured in Massachusetts and provider members controlled more than 80% of the hospital beds in the state.

    Why NEHEN Succeeded

    Halamka, Glaser and DeBor each credit NEHEN's immediate and ongoing success to learning from past mistakes and sticking to the Bourbon Street Coalition's core criteria:

    The Data Stays Home: All proprietary data remains on each member's own system. One lesson taught by early efforts at creating networks of hospitals exchanging information was that health care providers do not like seeing their proprietary data leaving their premises. They like it even less when they have to put their data into some sort of common storage.

    Earlier networks' "requirement that members part with their data and send it to a central database outside their control just ran against human nature," Halamka says.

    One Size Fits All: A single, standard format was adopted for preparing and exchanging data, creating a common TCP/ IP gateway that works for everyone regardless of their legacy systems or company size. Once the extraction and translation layers were in place, connecting each member to the peer network was entirely handled by the NEHEN middleware.

    "Suddenly all of us had a single implementation guide," Halamka says. "It was completely standardized. This meant that since the system worked for Harvard Pilgrim it would work for any health insurance company that joined NEHEN. And since it worked for CareGroup and Partners, it would work for every health care provider. This proved amazingly powerful. We were suddenly able to share our intellectual property without having to do any serious retooling or changing our basic business processes."

    Gated Community: By using leased lines and frame relays, this peer-to-peer network was designed to be accessible to members only, eliminating risks of having a break-in similar to the University of Washington's (see p. 32), and thereby also avoiding that dreaded "Boston Globe moment." By keeping the entire NEHEN network off public lines, there were no public points of entry a hacker could exploit—at least for data traveling between NEHEN members. Only a knowledgeable insider could potentially be a risk. And even then, the security of each member's proprietary databases was still its own individual responsibility.

    "There is no central repository, no central database," Halamka says. "Every member's proprietary data still sits on their proprietary legacy systems where it always has. So it's impossible to hack the NEHEN system because there is nothing there to hack."

    Secret Handshakes: Even though the data may move unencrypted between gateways, because the lines are private, the data generally is encrypted when it moves inside a network. So, even in the unlikely case a hacker figured out a way to get in, all he'd get is nothing but gibberish for his efforts. But, before a "cracker" could even get that far, he would have to find the right relay or fiber and physically tap into it—a very unlikely prospect.

    "While we use TCP/IP and other standard Internet technologies, none of NEHEN's data ever crosses the public Internet," Halamka says. "If someone wanted to tap into our data streams they would have to find the hardwire or cable to do it—an unlikely possibility. Even then, the data is securely encrypted."

    Low Hanging Fruit First: The first step in NEHEN's implementation targeted the area where the biggest benefits could be proven fast—the eligibility process. It was the easiest to implement and showed immediate positive reinforcement for all involved. This is where CareGroup cut its costs from $4.74 per inquiry to just 15 cents.

    "Everyone sitting around the table could see there were potential gains for them—and I am talking nontrivial gains,'' says Partners' Glaser. "Second, for me to realize my gains I needed Tufts, I needed Harvard Pilgrim, I needed CareGroup and so on. I couldn't get those gains working unilaterally. So, we all understood that we had to work together to see our individual gains."

    On the Cheap: Implementation costs were low because members did not have to chuck their legacy systems or retrain their workforce in new workflows or procedures. NEHEN simply melded into their existing systems. Large enterprises that had their own technology staffs simply needed to develop extraction and translation layers to bridge between their legacy databases and the NEHEN middleware. Small companies could skip or delay that step by adopting NEHEN Lite, a Web-based interface. They could then move toward a fully integrated solution later if they desired.

    "We did not require the participants to throw out their legacy systems," says Glaser, "did not require the participants to divert major capital to fund the thing, and we did not require members to comply with an arbitrary feature-adoption timeline. Instead, they could move as fast or slow as they wanted and we would simply wrap ourselves around the member's own technology choices and directions.''

    NEHEN's success has made it a role model for other communities struggling to catch up. One of those communities is Buffalo, N.Y., says Bob Hoover, CIO of a regional health maintenance organization called Independent Health. "We're trying to build just that kind of network here in Buffalo right now," Hoover says. "We were able to look to [NEHEN] and say, hey, here is a group of companies that compete fiercely on a daily basis but were able to get past that to bring value to themselves and their community."

    Hoover says that at the time NEHEN began there was no model. "They were starting from zero," he says. "They did not try to go so far or get too complicated. They looked at available technology and made use of it. Sure, maybe using XML would now be more elegant. But back then, they used what was there to satisfy the needs of these different groups. They kept the costs low and the system simple to use and implement. I give them a hell of a lot of credit. They were real trailblazers."

    Side Benefits

    Besides seemingly solving the security issues of health care networks, Halamka also found a way for hospitals to live with one of the hottest of hot-button privacy issues—the so-called "Unique Patient Identifier," or UPI.

    An obscure section of the HIPAA law mandated the assignment of a unique identifying number for every patient served by a HIPAA-compliant medical entity. But several conservative members of Congress believed that a single number that tracked nearly every American's medical hitory, cradle to grave, had a distinctly Orwellian scent about it.

    But Halamka saw a UPI as a key element in providing comprehensive health care for CareGroup's patients. "A UPI is a good idea because it allows us to do a virtual consolidation of medical records that may be spread all over a system," Halamka says. "So, I spent over $1 million at CareGroup to develop our own patient identifier for every CareGroup patient."

    The software developed by Halamka and his programmers at CareGroup enables any doctor, clinic or hospital within the CareGroup family to locate the patient's medical file with as little information as their name. "So, if one of our patients has a heart attack at a shopping mall 25 miles from the hospital that normally serves him, our system can find his file," Halamka says.

    Halamka says if a patient gets care anywhere within the CareGroup system, the system clusters all those medical records under a single UPI—even though each hospital may still use its own proprietary numbering system.

    Sharing patient data can also prove a health benefit to all patients. To prove the point, Halamka used the NEHEN network to establish an early warning system within days of the news that someone had sent anthrax-tainted letters through the postal system.

    "I contacted the members and said, 'Look, since we have this infrastructure in place, how about branching beyond claims and eligibility and referrals?' " Halamka recalls. "How about we use our standards and infrastructure to exchange and aggregate health surveillance data on bioterrorism?"

    Every day, each hospital would transmit a ZIP code-based count of emergency room visits. This would provide a daily snapshot so that if suddenly there were a 20% spike in emergency room visits in Watertown, Mass., an alarm would go off.

    It took one week to build and deploy such a "regional bioterrorism surveillance network" because of the napkin network's infrastructure, already in place and in use.

    Stephen P. Pizzo has written for Forbes SAP, The New York Times, The Washington Post and Mother Jones. He is the author of Inside Job: The Looting of America's Savings and Loans (McGraw-Hill, 1989).