60 Days from Napkin

By Baselinemag Print this article Print

The health care industry has been slow to comply with new federal requirements for the electronic exchange of medical data. So how did one cooperative find a way to comply—four years ago?

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."

This article was originally published on 2002-02-04
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.