MedUnite's Protocol: Less Is More For Easy Data Access

When it comes to health insurance, the words "quick and easy" don't exactly leap to mind. But that's how Jo Baxter, an office manager for San Diego Sports Medicine and Family Health Center, describes MedUnite.net. The site relies on XML and Soap technology to provide one-stop access to data from hundreds of payers, including the seven largest insurance companies and Medicare and Medicaid.

MedUnite links about 130,000 offices run by people such as Baxter, whose staff in the past was supposed to call each patient's insurance company to verify coverage. Because the office sees as many as 100 patients a day, that didn't always happen. "Less is best--less places to go, less places to call, less information to remember," Baxter says. Even the few EDI links the clinic could use to check eligibility didn't help much because they took several minutes per inquiry.

MedUnite was founded in 2000 by seven major health insurers--Aetna, Anthem, Cigna, HealthNet, Oxford Health, PacifiCare, and WellPoint. The goal is to make health-care transactions as easy as, say, using an ATM, says Sheila Schweitzer, MedUnite's chief operating officer.

When a health-care provider checking a patient's eligibility clicks on a MedUnite member and provides information such as name and ID number, the patient information is compared with the payer requirements to make sure it matches the payer's data format (e.g., the number of digits in the ID number). The data is then used to construct an XML version of an eligibility request, which is validated against the transaction specifications of the Health Insurance Portability and Accountability Act, the federal law that sets health-care transaction rules. It's then routed to the appropriate insurance payer; if necessary, the transaction may be converted into a format other than XML for communication with the payer's system.

	Integration can still require some custom programming, MedUnite's Schweitzer says.

When a new payer signs up, MedUnite can offer the electronic services within two weeks, Schweitzer says, because it doesn't have to build a new transaction system to interact with the new company's legacy system.

But don't fire half your programmers based on MedUnite's experience. Web services don't erase integration issues. While they let MedUnite reuse existing messaging methods, integration can still require some level of custom interface programming, Schweitzer says. The key advantage is that it rarely requires changes to a company's core code.

The savings can be substantial. MedUnite lets ConnectiCare, a health-maintenance organization in Connecticut, replace a customer phone call that costs $5 with a MedUnite Web inquiry costing 44 cents, says Dan Galdenzi, ConnectiCare's director of E-services. The system helps smaller health insurers be more competitive, he says, because they can offer electronic services for a per-transaction fee without maintaining a costly Web site. Physician offices pay a one-time $150 registration fee.

MedUnite doesn't yet use the UDDI registry or WSDL Web-services standards, though Schweitzer sees their promise. The biggest roadblock to rapid integration of disparate systems is the gathering of information about the interfaces, she says. UDDI would let developers easily discover, reference, and integrate MedUnite's XML Web services into their applications, but not until it's built into most insurers' systems.

MedUnite's next goal is to help insurers do more complicated financial transactions, such as electronic payments and claim status checks. ConnectiCare's Galdenzi says physicians sometimes end up making a phone call for complicated transactions that involve connecting with multiple systems. If it can continue to evolve using Web services, MedUnite should be able to let physicians help themselves.