Much of the focus on the problems with HealthCare.gov
, the troubled federal website for enrolling in coverage under the healthcare reform law
, has been on the front end of the system as it crashes or stalls on consumers.
But there is a problem on the back end: a lack of agreed upon implementation specifications on an electronic data interchange standard. It's a familiar problem to those who deal with information exchange in the healthcare industry, but one that may have tripped up the Obama administration and contractors building the system. And it could continue to cause headaches long after the administration fixes the more visible kinks.
One key standard at issue is used to electronically enroll new members in health plans. It's called the ASC X12 834 benefit enrollment and maintenance transaction, which was developed by the Accredited Standards Committee, a not-for-profit standards development organization. ASC X12 is accredited by the American National Standards Institute, coordinator of the U.S. standardization system.
The standard also is used to communicate who pays how much between the buyer, the exchanges, the health plans and the federal government, for example, when a consumer using the exchange
qualifies for advance federal tax credits to subsidize the premiums.
More than a dozen ASC X12 standards, including 834, were anointed by the federal government for use in healthcare transactions in the Health Insurance Portability and Accountability Act of 1996
. So, it stood to reason that when the architects of HealthCare.gov decided what standard they would use, they chose 834.
And it works.
Kentucky's state-run exchange kynect, for example, has enrolled more than 12,000 health insurance buyers since its launch Oct. 1. It uses 834s to communicate with its health plans in the state and HHS.
“We'll do an enrollment transaction with the insurance company,” said Chris Clark technology program manager for kynect. “And once we're enrolled, we send that enrollment transaction to HHS.” The communication lets HHS know how much the enrollee will be paying out of pocket and how much of a subsidy HHS needs to pay the health plans out of the Patient Protection and Affordable Care Act
tax credit, Clark said. But Clark said communication beforehand with payers was crucial to the early success of the exchange.
With the federal government tasked with setting up exchanges in 36 states, problems with scaling up the program extended beyond hardware and software. They include collaborating with people and insurance plans across the country on data interchange standards and implementation specifications.
But the 834 transaction itself “was considered to be the transaction from employers to health plans,” said Stanley Nachimson, principal of Nachimson Advisors, a health IT consultancy. Because employers were not covered entities under HIPAA they were not required to use the standard—and many don't. The requirement was only on the health plan if an employer used it.
As a result, health plans, “although they were supposed to have the capability to process the 834s, they may not have been up to speed,” Nachimson said.
In health IT, standards are an important first step, but it is the implementation specifications that determine whether electronic messages are conveyed clearly, are garbled or fail.
That has been a problem with the federal exchange, said John Kelly, principal business adviser at Edifecs, Bellevue, Wash., a claims-management services provider. It has resulted in a lack of readiness and agility to handle variability in 834 enrollment transactions on some plans.
Specifications for the 834s in health information exchanges were released in March, but a final version “hadn't been rolled out until August, and there hadn't been the facility to test any of those transactions until just weeks before deadline,” Kelly said.
Still, Kelly said, several of Edifecs' health plan customers are live with the federal exchange. “We are seeing transactions are coming out of the federal exchanges, the state exchanges, some better than others.”
“The 834 is a transaction that has not been broadly implemented across the board since the advent of HIPPA because many of the larger accounts, the employer accounts, are self-insured and not under HIPAA,” Kelly said. “People haven't really looked at the 834 as a mandate.”
Consequently, a lot of the plans haven't built up the robust capability around 834 as they have under the “harder mandates” for HIPAA transactions, Kelly said.
Edifecs and companies like it mediate between the various transactions, including those using the 834 standards, and modify them to conform with the insurance industry's back-end systems.
But the exchanges were focused more on the front end of the systems, Kelly said. The assumption the exchanges made was that the payers can use the 834 because it is a HIPAA-mandated standard, he said. “The folks designing the exchanges were probably making the same assumption anyone would make, 'Oh, the 834s are the HIPAA transactions, we'll use those.'”
Meanwhile, many plans are still doing the bulk of their enrollment transactions on paper. Large employers use a proprietary standard, not 834, he said.
“Standards are only as good as agreements (to use them),” Kelly said. “There are no operating rules on the 834.”Follow Joseph Conn on Twitter: @MHJConn