That is a great question and your instincts about the email are probably right. I am assuming that you are sending a file with HL7 data. If this is the case, you have to be concerned with private health information or PHI. Email is not a secure method of sending data because you never know who is opening the email. As a former Director of Technology, I know that emails can be open from the server without the intended recipient having any knowledge of it. For real time interfaces, my recommendations for sending data is secure point-to-point VPN connections using encryption through the firewalls. I can't stress enough the use of the encryption. If you need to send batch files, I recommend sFTP servers where the data is uploaded. In order to download the file, a user id and password is needed. I also recommend that the files be removed from the server within 48 - 96 hours. Certain interface engines have the ability to transmit data through software modules to other interface engines. However, the module's communication protocols are still using the point-to-point VPN through the firewalls in the background.
0 Comments
First, let me clarify that I am only going to refer to interface engine related logs and not window's or server logs. Obviously, servers have a finite amount of space, so you need to use it wisely; otherwise, you run the risk of crashing the server. When I am setting up an engine, here is what I think works well.
For the inbound interfaces, I would recommend that you save only the pre-process transactions. If you need to trouble shoot or resend a message, you have a clean place to start. For the outbound interfaces, I recommend that you only save the post-process transactions. This will show you what went out the door. If there is an error that is happening, most engine give you a testing area to see your logic applied against the message. You can start with the inbound message and walk the transaction through the logic one step at a time. In regards to retention, my general rule of thumb is six months on the server. This can vary depending on daily amount of transactions being processed on a specific server. If you have SANS capabilities, I recommend that you keep a subsequent six months of transaction for lab transactions. It is not uncommon for a providers office to ask for a result from a year ago because the patient is now being seen for the yearly physical. This allows for the message to be resent without the lab having to un-finalize then re-finalize the message which is not favorable to TJC and CAP. This would depend on what medical devices and where. What we have seen at many hospitals that are interfacing patient monitors, ventilators, and IV Pumps, the first call goes to IS. In the off hours, the nursing supervisor calls the on call person. For vitals sign monitors, we have normally see that these are supported normal IS office hours. If the a set of vitals don't come thru, they are documented manually. Where this question gets complicated is in the critical care areas - ICU, ED and OR. There seems to be a trend in many hospitals where IS is extending their support 7 days a week and extending to two shifts. The push in CPOE, medical devices interfaces, and more patient documentation online has forced many IS departments to review their support policies. If you only have one interface engineer, we strongly recommend that you have a secondary support person who is knowledgeable in the interfaces is assist.
That is a great question, but not an easy one to answer. The first question is are they the same software vendor. If they are the same vendor, I would recommend that you develop an architecture that will help you support it more easily. For example, divide engine based upon location or by functionality. Location could be by hospital or clinic while functionality could be ADT/SCH versus ORU. This also gives you an opportunity to build redundancy in case one system goes down.
If they are not the same software vendor, I strongly encourage to pick one vendor and convert. There is tangible and intangible savings with going with one vendor. The tangible savings will be the annual support fees, cross over training for personnel. The intangible savings are on going support of two systems. Conversion will have a one time expense Great question! First, let me state that the interface engineer that you are working with should test the logic of their code. It should be their responsibility to ensure that the code is working as designed. Second, as an application analyst there are two things that you should test. The first is data validation within the receiving application. For example, ADT interfaces you will want to make sure that the demographic information is being placed in the correct fields within the receiving application i.e. first name, last name, DOB, gender, and etc. The second is what I call business logic. Test to make sure that you get the desired patient population. If you only want inpatients, test to make sure that outpatients do not come through. If data is being mapped, make sure that the new values are coming through. Next, verify that HL7 transaction are working accordingly in the receiving application. For example if a patient is discharged, verify that the application shows they are discharge.
The best testing document is your interface specifications. However, don't hesitation to test normal daily activities either. I am constantly rewriting the same code for multiple interfaces. How can I work more efficiently?7/25/2014 More interface engines allow you to write code and save it. This allows for you to do an external code within the interface engine. For example, Filter by Patient Location is a procedure that you would use multiple times across many interfaces. Write the procedure (or code) to pass in multiple locations and then pass back a pass/fail flag to the interface. The pass/fail flag would either suppress or continue to process the record.
I would also recommend that you have a naming convention in place so it is easily recognized by multiple people. There was a time in healthcare information technology that many software vendors would state, "Interfaces do not take any resources, so you can just add them." I wish I had a dollar every time I heard that! YES, you need to be monitoring your interface engine. Many things can go wrong with interfaces. There are hardware performance concerns that should be monitored. In regards to the interfaces, data can stop flowing so queues need to be monitored. Also, the end point applications can change without notice which can cause the engine to process data with results that are not desired.
I recommend to all of our clients to have at least one person who is trained and responsible for interfaces and interface engines. It does not have to be an employee, but can be outsourced if budget is a concerned. I also recommend that when an employee is utilized to have a back up person trained as well for vacations. I would strongly recommend that you have a naming convention for your interfaces. The two methods that work well are 1) name them by functionality i.e. ADT, ORM, ORU, etc. It would look something like this ADT_EPIC_OUT_TO_PACS, or 2) by systems i.e. PACS, EMR, etc. It would look something like this PACS_ ADT_EPIC_OUT or PACS_ORU_EPIC_IN.
I can already hear the next question. How do we get everyone to comply. For employees, I would tie compliance to the naming convention to their annual review. For contractors, I would add it to their contract. Any consulting firm will welcome written standards. The answer is YES!! You should at least backup the interface engine once a week. The best case scenario is a daily backup. I have been called into companies to restore their interface engine after a fatal hardware crash, and they had not down any backups. At this point, your only options is to begin rebuilding every interface from scratch.
|
Kevin L Frederick Founder & CEO Welcome to our blog! Our purpose at D288 IT Solutions is to support the advancement of healthcare IT. Our hope is to create an environment through sharing of topics aimed to help the healthcare IT professional in their careers. We hope you find the information useful and practical, so enjoy and check back often! TOPICS
All
Archives
October 2019
|