Testing with messages to/ from production systems

we do this quite a bit. For every site/thread we have in production we mirror in test but i’d say over half our interfaced applications don’t have a testing environment. This is becoming more and more frequent. probably cheaper, less servers. Some will use the test environment for testing the move that to live and have no test system at all after that while some require we send live data from the start. It used to annoy me but since here any joe shmo can go online, buy and application and we have to “install” and integrate it in i dont get much say so i just deal with it. I have never seen any issues from the times we have done it.

I have approached this by translating the patient data to file on one valid test patient.  It keeps from getting live patients in those systems that do have a test area and makes looking up results easier.

We have a couple of approaches we typically use.

The preferred method is to use our production SMAT archives and convert the desired amount of SMAT messages to new line terminated messages and resend that file through the desired test interface(s).

Most discussions will reveal that rarely is a real-time live production feed to test needed, but often people will say that up front so try and talk them down from that stance first.

If others remain insistent on a live real-time production feed to test, we use what we call our relay site.

The relay site is localhost TCP/IP listener that intercepts the desired production interface and forks 2 static raw routes (one static raw route to the prod listener that the intercepted interface sender was talking to which is often outbound to a foreign system, and one static raw route over to our desired test interface).

Our relay sites are used in many different ways but this particular example I think applies to your question.

Our relay sites are mostly used for parallel go lives when upgrading a vendor app on a new server that requires a parallel overlap for a while.

By using relay sites most of the configuration is in a dead site until activated and hardly any change to the live production site is necessary beyond setting the IP of the interface sender to be intercepted to localhost, which helps keep potential mess ups out of that site.

Hi Karl.

If we have been requested to do this, we set up a non-production Cloverleaf site to connect to the new application.  The production messages are sourced from daily cycled SMAT files and are either sent in batches (using the standard file load), or sent at an approriate time, based on the messages MSH timestamp.

This provides the production data 1 day late