Fixing the HIPAA Compliant “834” Insurance Transaction Format Still Work In Progress for Healthcare.Gov With Contrac
Posted Nov 05 2013 3:57am
Actually the Washington Post had a real detailed write up on how this works so here’s the link instead of me repeating it here as they did a good job. If you have never heard of this before, it’s the data format that sends your information to insurers when one signs up on an insurance exchange and this has not been working. Part of the problem is that CMS wanted to use their own format instead of using industry standards that the rest of the insurance industry uses…strike one. This format has been around for years, so nothing new.
CMS actually back on 2012 put out a pdf on the formats and technologies that QSSI would use for the hub. It’s pretty interesting to see a huge group of technologies here. QSSI is using the same technologies to store the data (actually it is in memory data and it is held in a data base) that was used for their data crunching to find fraud in claim payments. Link below has more details. This may have been changed since it’s release in 2012.
Below is a screenshot that tells you what data source is queries and the services that the QSSI Federal Hub will supply. It is using a data base from MarkLogic, and again as you are told it’s not used to supply data to other sources but uses “in memory” functionality to receive and and send the information out in an XML format, that is what MarkLogic data base and search uses.
In the last couple of days, HHS actually had a real “security breach” here with one man getting another’s man’s data online which means the match was not correct and and again we are matching data. If the information comes back with a wrong match well there you are. The MarkLogic data base uses an XML schema so I am thinking this is where CMS maybe thought they could use their 834 format as the matching process is a little different and maybe they thought they could code it the way they wanted in text field instead of a formatted currency field. If you have ever worked with data bases, then you know what I am talking about. Here’s the breach story below and ironic that it happens to the agency that puts the “breach” rules out for everyone to follow and abide by:)
I did wonder why the Oracle state turnkey platform was not used for state exchanges and why CMS didn’t recommend either that one or one from Microsoft for the state exchange part of the solutions? I know there are about million ways to configure a project this big but when time is of the essence I wondered here if there was a lot code writing going on when some of the integrated Oracle products that have already been integrated could have been used?
Oracle products use Java as well and there are more common libraries than those of XML, but not to say that MarkLogic XML is not good but when you have an “App heavy” configuration it’s best to kind of look at where code has already been written to save time and less time writing XML schemas.
“The foundation of the HIX platform includes Fusion Middleware, particularly the Oracle SOA Suite. Fusion is a leading application infrastructure platform.
Siebel customer relationship applications provide states with the infrastructure to operate multichannel customer service and include analytics tools for evaluating calls. Siebel also handles case management for the exchange.”
I like open source software but the hub has and XML format connecting to Red Hat over at the other end and Oracle has Red Hat that is already tweaked and they offer support. So again when you look at the link above on the CMS image for the Data Hub, and add in some state exchanges using the Oracle turnkey which are already set up for the 834 transactions…well…see where I am asking here..if it were engineered with technologies already coded to integrate, perhaps we would be having fewer issues. Again speaking from the outside we have Red Hat Apps to create or modify from libraries. You don’t get the support from Red Hat as you do with Oracle Linux.
You can read all over the web with enterprise engineers that it is stable and the support is worth it. In addition, the JBoss Middleware from Red Hat is in the schematic and that is again where you have Oracle Fusion middle ware, again already integrated. This is not a commercial for Oracle, but darn when you have short time limits to put a project like this together and have it work, is there time to be writing a lot of apps from the ground up? On the other side Oracle ID and Access was one of the items used.
So back to normal talk here, the 834 integration was already built into Oracle exchange platform and had integration for Medicaid as well…and most of the big insurers use Oracle and the 834 format. Perhaps Congressman Issa will get us an answer on all the technologies used here. With as complex as everything is today, you really want to not too far out on the creative limb and use products and code that you know are going to work.
So now QSSI is running the whole show and still needs to get their 834 XML schema fixed so the application data goes correctly to the insurance companies. I feel sorry for them over at CMS on how this all worked out with them being saddled with it and they are not tech folks and their jobs don’t center around data and IT. So now to get the 834’s working I am guessing we are doing some XML schema coding to get this to work. I do wonder if it is set in stone to use the CMS formatting or will they cave in and use standards, probably which ever requires the least amount of coding and runs the most efficient.
It’s been on the web too that MarkLogic could be a target for Oracle to buy someday. The CEO was at Oracle Open World and gave a nice long interview and even himself talked about their product versus Oracle (and that’s where he spent 15 years before coming to work for MarkLogic less than 2 years ago) and said their product needed the right mix and you need to really look at how app heavy the entire product was with Oracle versus other technologies to make the best choice. BD
Fixing errors related to messages using a key electronic data interchange standard is at the top of a “punch list” of problems that the CMS continues to work out with HealthCare.gov, Obama administration officials said Friday. Transmissions between the troubled federal exchange and health plans in the Accredited Standards Committee X12 834 standard for health plan enrollment are critical because they inform insurers which people chose their plans, delineate any payment splits between the enrollee and federal subsidy payments under the Patient Protection and Affordable Care Act, and contain sensitive personal information like Social Security numbers.