Strange billing file format

[George Kulz]

Hi all.

I have a vendor who is going to give me HL7 billing records in DFT format, HL7 ver. 2.2.  They’re going to dump out all the HL7 records at midnight let’s say. I’m throwing all of the HL7 records into a file. So, after the vendor is finished sending all the billing information to Cloverleaf, I should wind up with a file that looks something like this:

MSH

PID

FT1

FT1

FT1

MSH

PID

FT1

FT1

MSH

PID

FT1

etc.

What I want to do is to be able to read that entire file in with another Cloverleaf thread, flatten it out, and put the resulting flat file into another file.

Is there any way I can get Cloverleaf to read in all those HL7 records as one large HL7 record with multiple MSH segments in it? Or should I be approaching this a different way?

Thanks in advance for your help.

George Kulz

Senior Java Programmer

Information Services

Memorial Hospital of Rhode Island

Topic

[Jim Kosloskey]

George,

I am not sure I would try to make one huge message of all of those messages.

What does the receiving system really want?

I suspect it is a fixed length or delimited (like CSV) file with one record per HL/7 original message.

Do they really want one huge file?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[George Kulz]

Hi Jim

Eventually, our billing system needs to receive a flat file that looks kind of like this:

H

Record #1 (includes account number, quantity, unit price, etc.)

Record #2

Record #3

T 20110609

Unfortunately, from the vendor sending the billing file, all the charges are split up by patient, with one HL7 record for each patient. I need to get all of that into the above format.

-George

[Jim Kosloskey]

George,

OK the sending system sends one message per patient or multiple charges for a patient in one message?

If multiple charges per patient per message are all of the charges for one patinet in one message or can there be multiple messages for one patient each having multiple charges?

The receiving system – does it want one header through trailer set per patient or can the header through trailer set mirror the MSH set inbound.

The outbound definition is there a terminator at the end of each record (header, detail, trailer)?

I believe you can define the outbound as an HRL and depending on the answers to the above questions associate that with the inbound message set without resorting to anything too tricky.

If you would like to discuss this in more detail off line – feel free to email me.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[George Kulz]

Hi Jim

I managed to solve most of my problem.

What I’ve done is parsed each message into one or more lines using an FRL. So basically, at the end of the day, I have a bunch of lines in a file, each one being a separate charge.

What I need to do now is at the end of the day, somehow take that entire file, stick a header and trailer on it, and then put it somewhere to be picked up by another application. I also need to wipe out the file to prepare for the next day’s charges.

First, is there a way to define an HRL that’s simply a series of FRLs? That would be the template for the input file to the process that puts a header and trailer on. Then the output file template would be an HRL with a header FRL, a bunch of body FRLs, and a trailer FRL, which I’ve done before. Then I somehow need to delete or move the input file so that the next time a charge comes in, it’ll create a brand new file, which I’m not sure how to accomplish either. Do you have any suggestions on that part?

Thanks for your response earlier. I apologize for not getting back to you sooner, but the way things are around here, I’m always off on another project just when I start making headway on the one I’m working on. I’m finally back to this billing file problem now.

-George

[Jim Kosloskey]

George,

The FileSet protocols (local or FTP depending on the situation) would probably be what to use (that will pick up the file and delete it after reading all the records).

The key is the header and trailer:

Are these just static records – that is the data content always stays the same – or are these dynamic – meaning something like the header needs today’s date/time and the trailer needs record counts?

In either case, the Fileset protocols are not good about natively telling you the process has started or ended (what is needed to know when to cut the header and trailer).

However, you could have a header and a trailer template file in the directory where the data file is to exist. Make the names so that the header would naturally sort first then the data file then the trailer last and use a dirparse Tcl proc to assure they are listed in order. The Fileset protocol will then read those files in that order.

Set the permissions on the header and trailer file such that they cannot be deleted easily (so carbon based entities don’t delete them by mistake). Use a fileset delete Tcl proc to cause Cloverleaf not to delete the header and trailer files (the data file will be deleted).

The header and trailer probably do not fit the format of the detail so a single Xlate will probably not work. However with filtering you can probably have the header, detail, and trailer go through different Xlates to the same destination and because of their arrival order inbound they will end up in the proper order outbound.

If the header, detail, and trailer formats do accomodate one definition then a lot of the work could be done inside one Xlate I suspect.

Depending on the answer above to static versus dynamic data content of header and trailer more Tcl may be needed in combination with the Xlates.

Just some ideas…

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Levy Lazarre]

George,

Quote:

What I need to do now is at the end of the day, somehow take that entire file, stick a header and trailer on it, and then put it somewhere to be picked up by another application. I also need to wipe out the file to prepare for the next day’s charges.

This is the kind of task a UPoC thread allows you to easily perform.

You need the “time” mode of a UPoC thread to perform your actions at the end of the day. So you configure your thread with UPoC Options –> Read TPS -> Use Advanced Scheduling, which will allow you to

1. Indicate the time when the action should be executed, for example 11:55 pm.

2. Indicate the Tcl script to be executed.

In this TPS, you just code all the things you are trying to do, including adding the header, trailer, and moving the file to destination. Since you are building a dynamic header and trailer, you will have to open the charge file, parse it, and pull the necessary fields to run the totals (quantity and charges). The number of records is simply the number of lines in your charge file. You write all of this (header, charge lines, trailer) to a new file and copy that new file to its final destination. You also dispose of your old charge file as desired (move it to an archive directory). If you move it, then you don’t have to worry about wiping it out since the append process will create a fresh file.

I am not sure what kind of outbound thread you are currently using to create your charge file, but you could actually do this whole thing in the same UPoC thread, using the run mode (UPoC Options –> Write TPS) to append messages to the file after they have been Xlated. So basically, you configure the outbound UPoC thread to do both read and write. In the write mode, it creates your charge file by appending messages coming from the Xlate. In the read mode, it reads the completed file, creates the header and trailer, and ships the modified file to destination.

I hope this helps.

[Author]

Replies