Saving IN1 from ADT and placing them into ORM msg

[Nora Katz]

I am working on an interface where the sending system is producing an ADT and ORM message, and the receiving system only wants the ORM message (with insurance information).

Upon receipt of ADT, I was planning to save off the IN1 segments in a SQlite database and when I get the ORM message, insert the IN1 segments into the ORM message.

Has anyone done this in the past?  Is this the best way of doing this?

Can I save the entire IN1 segment and insert it back into the message from an Xlate?  Or, do I need to save the individual fields of the IN1 segment in the SQlite database?

ADT and ORM messages should come close together, but ORM only contains a single test, so, I will be saving the IN1 segments from the ADT  messages for about 1 week and deletig them.

Any suggestions would be appreciated!

thanks

Topic

[David Harrison]

I have to use data caching for populating messages quite a lot. I build a database table with an auto increment field as the identifier and populate individual fields. I also have a date/time field and a single character field which is set to 1 when the data has been processed. You can use these fields when you want to clear data from the table.

The problem you may find if you store an HL7 segment in Sqlite is reserved characters like quotes etc. I have experimented with storing entire HL7 messages by first pulling out the unique identifiers (so you can retrieve the record you want) and converting the message to base 10 encoding.

This is a schema I have used to store fields from messages:

Code:

CREATE TABLE PAS_ARCHIVE (
 id INTEGER PRIMARY KEY,
 tpref VARCHAR,
 trans VARCHAR,
 caseno CHAR(2),
 intno VARCHAR,
 distno VARCHAR,
 surname VARCHAR,
 forename1 VARCHAR,
 forename2 VARCHAR,
 dob VARCHAR,
 sex CHAR(1),
 title VARCHAR,
 homephone VARCHAR,
 workphone VARCHAR,
 dod VARCHAR,
 addr1 VARCHAR,
 addr2 VARCHAR,
 addr3 VARCHAR,
 addr4 VARCHAR,
 postcode VARCHAR,
 dataddrmove VARCHAR,
 pmicomment VARCHAR,
 nhsno VARCHAR,
 userid VARCHAR,
 patsurnameretain CHAR(1),
 gpcodeint VARCHAR,
 dategptransfer VARCHAR,
 religcode VARCHAR,
 marstat VARCHAR,
 ethnic VARCHAR,
 nokname VARCHAR,
 relcode VARCHAR,
 nokaddr1 VARCHAR,
 nokaddr2 VARCHAR,
 nokaddr3 VARCHAR,
 nokaddr4 VARCHAR,
 nokpcode VARCHAR,
 nokhomephone VARCHAR,
 nokworkphone VARCHAR,
 pderror VARCHAR(3),
 pferror VARCHAR(3),
 sp1 VARCHAR,
 sp2 VARCHAR,
 sp3 VARCHAR,
 sp4 VARCHAR,
 processed INTEGER(1),
 datetime DATETIME);

[David Harrison]

Correction!

for base 10 read base64

[Nora Katz]

Thanks for the hints.

I had not thought of a single character field for after processing.

[Jeff Dinsmore]

I also assemble composites from multiple messages.

The approach I use instead of storing the messages in a database is to build a database to index SMAT files. The index includes a few pertinent pieces of data – MR, Account/encounter number, etc. for each message in select SMAT files.

This approach makes for a smaller database and quicker lookup. It requires code to read SMAT idx and msg files, but that’s not too complex.

When I need a bit of info for a message – let’s say some insurance info from past ADT for a current order message – I look up messages in this index, then read them directly from current/archive SMAT files to “enrich” the current message.

NOTE: I appropriated (stole) the “enrich” term from someone on this forum. Thanks to whoever you are – that’s is my description of choice for this technique.

This database and accompanying SMAT file utilities are also used for other purposes – such as finding/resending messages across multiple SMAT files.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Rehman Masood]

I have done something similar in which I saved off the test code on an orders interface and used it back on a result interface. It was pretty simple and straight forward. I saved everything in a sqlite database.

[Nora Katz]

Jeff,

I’ve not considered using the SMAT files to “enrich” a current message.

Is there more information on this topic?

Nora

[Jeff Dinsmore]

This is something I’ve built from scratch.

The major components are:

1) An indexer for select SMAT files

In your (Nora’s) case it would be your inbound ADT.

I index several different SMATs – a couple of different ADT feeds, a couple order feeds and Rad results – whatever messages I need to reference in other interfaces. I don’t do all SMAT files because I don’t need them – it would just be a waste of time, CPU and disk space.

For each indexed message, I’m storing minimal info – smat file, cloverleaf message ID, message offset in SMAT file, message length, MR, account number

The indexing info is stored in an SQLite database.

2) Code to find messages of interest from the database.

3) Code to read the individual “found” messages from their SMAT files.

4) Code to tear apart and reassemble HL7 messages so you can get to what you need and use it in another interface.

This is greatly simplified, but hopefully gives you an idea of what’s involved.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Author]

Replies