That is a really great question. If you have never developed an interface, it can be frustrating when it takes so long. Most of the time, it is "Hurry Up and Wait!!" Usually, there are a number of people who are responsible for a portion of the interface setup. If it is a brand new vendor interface, most likely, the VPN needs to be set up. This takes both an internal network engineer as well as the vendor's network engineer. There is the development of the interface on the sending system, the interface engine, and the receiving system. Quite often, it is waiting for the next resource to free up. Once the interface is developed, there is the testing and waiting for resources to test the sending system and the receiving system. There can be times that the development can be more involved based upon what is being sent and what is expected to be received. Based upon my experience, that is only about 1/3 of the interfaces I have developed.
0 Comments
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.
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.
|
![]() 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
|