Suppress multiple A08’s so just one passes

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Suppress multiple A08’s so just one passes

  • Creator
    Topic
  • #55242
    Kaley Grimes
    Participant

      I’m working on a project where the vendor can not receive multiple messages that are the same type. I have to send A08 messages for the only purpose of sending patient type change information for ED to Observation. When the Registration user completes this process in our ADT system, it sends three or four A08 messages.

      Ultimately, I would want to send one A08 message for the patient and kill the rest. Has anyone had to do anything like this?

    Viewing 6 reply threads
    • Author
      Replies
      • #84680
        Peter Heggie
        Participant

          This is difficult – usually the interface engine is only aware of the current message and cannot act depending on a previous message.

          Before suggesting other possibilities, I assume you have examined the three or four A08s and have not found any little item in them that is unique such that only one of them has or does not have that item? And there is no way to modify the HIS to put some little tag in one of those messages that you can use to trigger the CONTINUE logic and kill the rest?

          If those two options are not available, then you have to use something outside the message –

          Table/File indicator – store information in a file or table that says an A08 has been sent. Use visit/encounter number in the entry to identify the encounter. Check the file for each A08 (expensive) that goes through. If you find that encounter number, it must have gone through before, so KILL the message. If not, put an entry in there and CONTINUE the message.

          Cleaning this up later is a necessary chore. Maybe you can clean up the entry when you get an A03. Or you can use a database table to store this encounter A08 flag – but that uses more code to store the value.

          Maybe just creating a tiny file whose name is made up of the encounter number would be easier. Use the tcl File Exists command to see if the file exists – if not, CONTINUE the message and write the file (needs no content). If the file exists, KILL the message. That’s probably 4 or 5 lines of code. You still need to cleanup the files later. Maybe a nightly batch script that deletes files older than a day. Or an even easier solution is when you write a new file, instead of Opening the file, Writing one line and Closing the file, you could instead use the File Copy command, and copy some blank template file to this new file name, that’s just one command.

          You also have to decide where to put this logic – in the Inbound UPOC, in a pre-translate step or even in the destination thread Outbound UPOC. It depends on performance considerations.

          Peter Heggie

        • #84681
          Mark Thompson
          Participant

            We did this for a while until our ADT system got A31 messages under control.  Our approach used 2 parts:

            1, A fileset local thread writes each A31 message into a file – using the patient ID number as the filename.  Each additional message overwrites the previous message.  After a message burst we have the most recent content in the file.

            2. The same fileset local thread with a directory parse proc passes messages when their file is more than X seconds old.  You may need to adjust X to get the appropriate level of filtering.

            Caveats:

            – Unless you have generic Tcl procs for setting outbound filename and directory parse, there will be a moderate level of Tcl coding required.   Code for both items is discussed in other Clovertech postings.

            – Our AIX file system processing is relatively fast.  Performance will vary based on OS and hardware.

            - Mark Thompson
            HealthPartners

          • #84682
            Robert Kersemakers
            Participant

              Instead of a file, you can also use a global variable to store the patient id of visit number of the last received message. If the next message has the same patient id/visit number, then kill this new message; if not then replace the global variable with the information from the new message and let it continue.

              Just be aware that when stopping a process, this global variable will be cleared, so at that time you will need to write it to a local file. And at startup read the local file into the global variable again.

              Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

            • #84683
              Charlie Bursell
              Participant

                How would you do that Robert, write the global to a file if the interface stops? OK if a good controlled shutdown but you know that does not always happen.

                I would be more in favor of a simple sqlite or just plain file to always maintain whatever t is you use to ascertain sameness.

              • #84684
                Robert Kersemakers
                Participant

                  Hi Charlie,

                  You are right: if the process crashes, then you will lose your global. So saving it through sqlite or file is safer, although it takes a bit more time and i/o (negligible though). But must say that crashing processes shouldn’t happen that often (they really don’t, most are controlled restarts). And in this case, if a crash would occur and you lose the global you would only send out one extra A08 message that the receiving system can’t handle.

                  In all fairness: the initial question is very weird. The receiving system should be able to process all these A08 messages of the same patient. But we know our vendors…

                  Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

                • #84685
                  Jim Kosloskey
                  Participant

                    I wonder if the sending system isn’t sending one A08 for each change. Such that the last A08 does not really express the entirety of the changes.

                    In that case, I suspect the receiving system would want one A08 with the cumulative changes of all A08s.

                    Perhaps the analysis has already been done but I suspect there is more to measure here before the first cut is made.

                    I agree absolutely the receiving system should process as many A08s as arrive – that way cumulative or not it does not matter.

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

                  • #84686
                    Kevin Crist
                    Participant

                      I have seen a sending system send out multiple A08s on a change but the others would be different/old accounts. We had logic that if it had a discharge date and A08 then kill the message. Not sure if that is exactly your issue but just a thought.

                  Viewing 6 reply threads
                  • The forum ‘Cloverleaf’ is closed to new topics and replies.