Clovertech

Saving IN1 from ADT and placing them into ORM msg

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Saving IN1 from ADT and placing them into ORM msg

  • Creator
    Topic
  • July 13, 2012 at 10:57 pm #53198
    Nora Katz
    Participant

      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

    • Creator
      Topic
    Viewing 6 reply threads
    • Author
      Replies
      • July 16, 2012 at 7:56 am #76885
        David Harrison
        Participant

          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);

        • July 16, 2012 at 8:23 am #76886
          David Harrison
          Participant

            Correction!

            for base 10 read base64

          • July 16, 2012 at 9:29 pm #76887
            Nora Katz
            Participant

              Thanks for the hints.

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

            • July 17, 2012 at 2:23 pm #76888
              Jeff Dinsmore
              Participant

                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

              • July 18, 2012 at 5:16 pm #76889
                Rehman Masood
                Participant

                  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.

                • July 18, 2012 at 9:27 pm #76890
                  Nora Katz
                  Participant

                    Jeff,

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

                    Is there more information on this topic?

                    Nora

                  • July 19, 2012 at 10:57 pm #76891
                    Jeff Dinsmore
                    Participant

                      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
                  Viewing 6 reply threads
                  • The forum ‘Cloverleaf’ is closed to new topics and replies.