Slashdot Mirror

"HIPAA EDI" is ANSI ASC X12 (specifically committee "N") which is a collection of file formats for communicating business transactions (in this case, generally submitting charge or payment information among providers and insurers), and has very little to do with medical records.

HL7 has created the Consolidated Clinical Document Architecture which hopes and dreams to one day capture provider documentation in an electronic format. The government incentives mandate certain pieces of this document to be supported by certified software, with the pieces differing between the phase 1 (now "2011 Edition") and phase 2 ("2014 Edition") certifications.

These pieces are nowhere near enough to actually transmit something resembling a legal patient record.

Deep down, though, the problem with communication is that every provider has their own style, from the wet-behind-the-ear doc who writes out all their SOAP notes long form over two pages mentioning every little thing like they're still trying to impress their professor, to the 40 year old doc who has made up a single page template with 40 checkboxes for the most common exam findings, a few checkboxes for diagnosis, and a box to write a plan, to the 60 year old who writes "ros/pe:wnl,pt well,flu shot,rtc 1y" on the line below where the nurse wrote the vitals and calls it a day.

What all of the above doctors have in common is that they do NOT want to deal in "structured data". They do not want to deal with SNOMED (or ICD-10, or hell, most of them don't even use ICD-9 that's what they hire billers for). Nobody deals with LOINC (good luck finding out the process used for your urinalysis dipstick so you can code the results correctly. I've got two major national labs that use LOINC for their test results, zero local labs, and zero labs that use LOINC order codes at all. For vitals at least someone in the government bothered to arbitrarily pick codes for height, weight, blood pressure and a few others out of the list of different ways of measuring each of them).

Database differences between each installed system is the biggest hurdle to full data exchange

There are standardized codesets to handle these things, the problem being that most of them rate somewhere between shit and flaming piles of shit.

ICD-9: smoldering pile of shit for specifying a diagnosis, containing diseases, causes of diseases, and a general category for "why the hell are you here if you're not sick?" to cover all the checkups, immunizations and so on. Replaced by ICD-10 by most of the rest of the world over a decade ago, still in use in the US until 2013 assuming the whiners at the AMA don't get the transition put off.

ICD-10: neatly stacked pile of shit. At least it's organized.

SNOMED: former pile of shit smeared all over the floor, walls and everything else. Encompassing diseases and causes and so on, it goes on to include symptoms, descriptions, etc. It prides itself on being an "enumeration" which allows it to justify having no relation at all between codes without an enormous relational database that must be conferred with before drawing any conclusions, thus (as a completely contrived example) chest pains might be 12421421 while sharp chest pains could be 2512519 simply because they thought of other things to number in between.

RxNorm: a smoking pile of shit that is mostly hidden behind a curtain you have to pay really big bucks to peek behind. Like SNOMED it's an enumeration, but they didn't bother to enumerate anything less detailed than the actual prescribeable drug, so if you have some 80 year old guy who tells you he takes a big purple pill, a round pink pill, and a yellow diamond, even if you figure out what those drugs were, you can't enter them without knowing whether they're the 50mg version or the 500mg version. It has it's place (notably in e-prescribing) but outside of that little sphere it's in the way. The free version covers some generics.

NDC: A flaming pile of shit that crackles and pops and splatters flaming shit all over. The are few words to describe just how fucked up the national drug code is, and fewer still to describe how retarded ANSI/ASC is for the way they chose to deal with it on insurance claims. For starters, there isn't actually a central authority for it. The FDA issues "labeler" codes to companies (who package the drugs, not necessarily manufacture the drugs) who then assign a drug and a packaging code to each, and eventually maybe get around to reporting the results back up the chain. Second, these three parts of the code come in three flavors: 5-4-1, 4-4-2, and 5-3-2, each totalling 10 digits not counting the hyphens which are obviously significant. ASC X12 decided that the hyphens must be removed (apparently in EBCDIC the ascii code for hyphen translates to "stop processing and burn all punch cards"), and to make things even more confusing, the code should be padded to an 11th digit, it's location depending on which section was "short" thus 0442, 5401 or 5032. Of course, many of the labeler codes already start with zero so it's impossible to know whether a code starting with 00044 was labeler 0044 or 00044. But I'm digressing...

LOINC: ah, LOINC. Yet another "enumeration". This time of things that can be measured. Or documented. Or in a document. As I understand it, now they've got LOINC numbers for the headings in documents, so the line "PHYSICAL EXAM" on your chart can be 51522-4 or whatever. As an enumeration of lab tests, it scores flaming pile of shit because its license makes it really, really difficult to distribute mappings of other lab codes to LOINC codes, and every lab performs every test slightly differently so there are somewhere around 20-30 different LOINC codes for "red blood cell count" and you're not allowed to know which one is the one you've got the result for. Likewise, when reading codes from other sources, you have to know that the red blood cell count could be any of these different codes and the doctor doesn't care whether it was mechan

Knowing what to search for brings up these relevant links:
EDIFACT
X12
How Radio Frequency Identification Affects EDI
Integration for Logistics: RFID, EDI, XML, and Beyond

If you are using an off-the-shelf inventory/billing system they you should probably consider letting someone else handle the integration and format-translation.

I have implemented an EDI system from scratch at my previous company. It was based on EDIFACT and email, and had extensive tracking&tracing, status feedback, error handling. The major challenge in implementing and EDI system is the integration with your EDI partners. It took 3 months from start of testing to the first real EDI message getting through, and almost a year before the workflow was right. Another challenge is that touches on legal responsibility - who said what, why, when.

I believe that ROI was good. No more manually entering 5 batches of 100 items every day. And the deadlines were improved so the final information set could be imported half an hour before work was initiated.

As far as I know the system is still chugging along 5 years after I left the company.

Ok, this REALLY should have been one for google- even I admit that and I'm usually on the other side. Just how many hackers on slashdot do you think have even messed with EDI?

There are a few of us. Actually probably quite a lot of us.

Still, given IBM's movement to bladeservers,

Obviously you haven't, EDI is not about hardware. You should have googled too....

http://www.x12.org/ would be a good place to start.

Simply put, EDI is a set off transactions for communicating B2B. (Business to Business) Electronic orders, invoices, advanced ship notices (ASN), electronic Bills of Lading. They are flat text files with tokens (slashdotters will love that, it sounds like a config file).

Then of course there is XML EDI.

D'oh! I took the first google link, but I should have linked to the Official ASC X12 Site . Sorry.

UN/CEFACT works on standards for business documents. There's something called EDI (Electronic Document Interchange) which has 2 major forks - in North America a group called DISA has an X-12 committee to create and maintain the standards. Everywhere else in the world uses EDIFACT standards, which are made and maintained by UN/CEFACT.

So when you go to Wal-Mart or JC Penney or even Dell and buy something, the whole business process behind that revolves around electronic documents. An electronic Purchase Order is created by Company X, which sends it to it's supplier, Company Y. Company Y acknowledges it and eventually sends back Ship Notification and an Invoice electronically. Saving both companies money.

ebXML was a proposed format to replace a lot of the old standards by using their own flavor of XML and their own comms stuff.

Good suggestions, but not always doable in practice.

Open data standards for payroll and accounting data? I'm sure there are some... they're probably old as dirt and about as fun to utilize nowadays too (yes, I've just spent a couple weeks learning the horrors of X.12 in the shipping industry -- it's used all over but it's archaic, has over 3 decades of different revisions, and an utter PITA to actually use). You can roll your own format (we did... we're in a position to) and make it reasonably open (again, we did... at least to our customers), but the odds of getting someone else to write to your format is low, especially for things like payroll/accounting. You could also reverse engineer their data files (a coworker did so for a flat file database at a former company, producing a real time importer for Sybase/Oracle), but that takes some pretty serious skill and money.

Don't think that it's just MS producing "proprietary" data. Virtually everyone does. And it's not the big, obvious formats that are a problem -- those have enough people looking at them to crack the nut eventually -- it's the small, uncommon formats that will keep you locked in. And it's equally unlikely that you'll easily find replacements that are low cost and open format. Companies have an incentive to lock you in... the counterbalancing force to this is that in a competitive market place they also have incentive to read other people's formats, which will either lead to a common format or to everyone figuring out how to import everyone else's data.

In general, without government mandates, it tends toward the latter rather than the former.