Processing 997 Files. Using an Interface Engine for Process Improvement

I've recently been working on parsing X12 files. My former colleagues referred to these files as "EDI" files, which is kind of silly. There may have been only a single format for the electronic interchange of data once upon a time, but in 2011 there are lots of ways to exchange data.

I worked on x12 848 transaction set (Materials) messages about fifteen years ago. I was part of a team that developed an implementation guide for the exchange of Material Safety Data Sheets (MSDS) between Tier 1 Paint Suppliers and Auto Manufacturers.

This project is much simpler. We receive an x12 997 Acknowledgement file from one of our trading partners. We send charges to them and they submit those charges on our behalf. The 997 file tells us whether the claim has been accepted by the payer.

For as long as anyone can remember, our operators have been receiving these 997 files and then manually looking through them to determine if the claim was accepted.

This is what an inbound 997 file looks like:

ISA*00* *00* *ZZ*562402607 *ZZ*383386347 *100312*0639*U*00401*000002331*0*P*:~GS*FA*562402607*383386347*20100312*06394602*2331*X*004010X098A1~ST*997*2331001~AK1*HC*275615~AK2*837*999999~AK5*A~AK9*A*1*1*1~SE*6*2331001~GE*1*2331~IEA*1*000002331~

Yes, there are no carriage returns in the file. They are optional. The segment separator is the tilde ("~").

I had Rhapsody create a message definition for the 997 file and then built a route that picked the following fields from the file.

• AK2-1 Is the Transaction Set ID (In the example message, the AK2 segment is “AK2*837*999999”, which makes AK2-1 “837”). The ack is for an 837 file.
• AK2-2 is the Transaction Set Control ID (In the example message, the AK2 segment is “AK2*837*999999”, which makes AK2-2 “999999”). This is the ID of the transaction that is being ack’d.
• AK5-1 is the Transaction Set Ack Code (In the example message, the AK5 segment is “AK5*A”, which makes AK5-1 “A”). The transaction set is acknowledged.
• AK9-1 is the Functional Group Ack Code (In the example message, the AK9 segment is “AK9*A”, which makes AK9-1 “A”). The functional group is acknowledged.

I then had the route build an email message using javascript that I send out using the email communication point in Rhapsody.

The script looks at the ack codes and sets text so that I don't have to remember what "R" means. That code looks like this:

if (TSackCode == "A") {
TSackMessage = "Accepted";
}
if (TSackCode == "E") {
TSackMessage = "Accepted, but errors were noted";
}
if (TSackCode == "R") {
TSackMessage = "Rejected";
}

There is similar code for the Functional Group Ack Code.

The email that gets built looks like this:

subject: X12 997 File Received from xxx: Accepted

Rhapsody received 997 Functional Ack Message from xxx for 837 - 999999
Transaction Set Acknowledgement Code is A: Accepted
Functional Group Acknowledgment Code is A: Accepted

The operators will still have the file to look at, should they wish to. We can get the computer to parse the message and send the results in an email. This email should make their job just a little bit easier, and, after all, don't computers exist to make our lives easier?

Patient List Interface

Here is a cute, little interface project that I knocked out in a couple of days.

One of our business partners is sending us what they call "patient list" data. This is information on patient groupings. For example, a patient could be on the "Gastroenterology Consults" list. This is information that does not come across in the organizations ADT stream, and the likelihood of getting it added to that was pretty low. Instead, they send us a patient list file which would contain a record for each patient and the patient list that they are on. They generate this as a Comma Separated Value (CSV) file and would send that to us as a flat file. I built a route and a mapping in the engine to take the flat file, generate an HL7 A08 (patient udate) message for each patient and place the Patient List information into the PV2-23 field (ClinicOrganizationName). The route then places each ADT message into the ADT stream for the appropriate system.

The A08 updates the basic patient demographic information by only adding the patient list information to the PV2-23 field ClinicOrganizationName. They can then select all patients that are currently in the Neurology list, for example. The receiving system gets the Patient List information with no changes required.

We already had a mechanism in place to exchange flat files, so they added this file to the stream. On the receiving end I have a script that looks at each file, identifies which one it is and routes it for processing. I added the new file to the script and built a new route to process the patient list file.

I then had to build a data structure for the CSV, which was pretty straightforward. I then built a special ADT structure that contained multiple A08 messages, and then a Map (that is the Rhapsody term, in Cloverleaf, this would be a Translate) to map the data from the CSV file to the ADT Message. After this, I added a DeBatch filter to the route to split each of the A08s into a separate message.

I had not built this sort of interface before, so I learned a little bit doing it. The trickiest part was getting the file structure definitions set up correctly. The actual mapping took about an hour to build and test.