Data extract to DFT with 1 message per patient with multiple FT1s

[Yutaka]

We are receiving a data extract from our Epic instance with patient information and separate FT1s on each line.  The vendor is asking for DFT messages with 1 message per patient with multiple FT1s.  How can I do this translation?  I think I need to ask for the data extract in a different format, but not sure what I’m asking for.

Attachments:

You must be logged in to view attached files.

Topic

[Paul Bishop]

In the current format, I don’t see a way of doing this in a translate.  A tcl script would be able to handle this with no issues as long as the extract file is sorted in the correct order to begin with.  The logic would be along the lines of read a record, check the current patient against the previous record’s patient and if it is the same, add another FT1, and if it is different, write out the previous patient and start creating a new message with the current patient.

Epic also has an Outgoing Financial Transaction interface which is configurable for the FT1 segments being one per message or multiple per message.

Paul Bishop
Carle Foundation Hospital
Urbana, IL

[Ted Viens]

You should be able to do this with a simple translation.    In your translation iterate over the FT1 segment.  Within that iterate copy MSH, PID, PV1, current FT1 segment, etc.  You will need to update MSH.10 with a counter so that it is unique.  After each FT1 do a SEND to send the message outbound.  This will force the send of a message for each FT1.  At the bottom of the translate use a SUPPRESS.  That will kill the original message since you have already sent the content of the original inbound message using the SEND command.

 

Below is an example.  I do this very thing with a DFT.

 

Attachments:

You must be logged in to view attached files.

[Jim Kosloskey]

Ted,

I think Yutaka is receiving a non-HL/7 message so what you describe probably won’t work for him.

I might suggest in your case you use a CONTINUE rather than a SEND to cut the messages. The CONTINUE will progress each message to the next stage in the engine post Xlate, the SEND will place each message at the OB Thread Protocol bypassing post Xlate processing.

While the SEND will have the same result for you now, if in the future something needs to be done post Xlate, it will be bypassed which could lead to some head scratching until you recall using SEND rather than CONTINUE.

I recommend using SEND as an exception for when one knows absolutely NO post Xlate processing will be required.

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

[Ted Viens]

This is an example

Attachments:

You must be logged in to view attached files.

[Charlie Bursell]

I agree with Paul.  The format seems to be a series of flat records.  The question I have is it always received as a file and not separate records?  Will ALL of the data for a specific patient be in a file?

Assuming All of a patients data is in the file it would be fairly simple to build a DFT with a single FTI for each record.

If patient data could be in multiple files it may be a bit more complex.

 

[Author]

Replies