Meditech 6.X: Capturing Temperature Source in a Single Query Field  It was my first experience working with Meditech that made me really think outside of the box to see if we could get temperature source in its own query field. There was no way the clinical staff would accept Meditech’s recommendation. The following steps are one solution that I have deployed at several hospitals.
Click on "Download the Article" to continue......
0 Comments
 While the end product should always be insight, it is often more about the journey or process that makes you successful. Take a moment and do an inventory on yourself. Are you utilizing all 8 characteristics?
Let’s face it, we all want to work smarter not harder! When it comes to interface engines there are 7 things that will tell you quickly if you are working smarter versus harder. These 7 items can make a world of difference and yet, they are so simple that they are easily missed.
 Creating an Environment of Cross Training & Sharing
I was recently asked by a friend of mine who manages several interface engineers, “How do I create an environment of cross training and sharing of information? We are working in silos, and it has been costly to the organization.” When you only have one person working on interfaces this can still be an issue because most likely you have another individual who supports the interfaces when they are out. Most interface engineers that I have worked with are introverted geniuses. They can usually make interface engines do things that no one ever thinks of; however, many like to keep their “cards close to their chest”. In most cases, it is always best to relate a problem in ways that will benefit the individual. Here are some ways an open environment will benefit the individual:
If you are a manager, it is sometime difficult to make a culture shift in your group. In the short term, this requires people to slow down and re-think what they are doing. Again, it is human nature to become creature of habits. Breaking those habits is not always easy and there could be some complaining. However, keep constantly in front of your staff why we are doing this and it is to benefit them. Show month progress to be 100% complaint and celebrate when you do hit the 100% mark. Be strategic in your planning, it will benefit you, the department, the organization and your team! This can be a common occurrence if you have one or multiple HL7 programmers. If you have multiple HL7 programmers, this problem can be compounded exponentially if there isn't a process in place to address it. Look for common functionality that can be used across multiple interfaces, and then have a process in place where it can be develop once and then stored in a designated area that all programmers know about. A real life situation is filter transaction by location. Allow the script or program to pass the location(s) as a parameter so that it can be flexible across various interfaces. This type of structure will foster an environment of working smarter not harder!
I am going to answer this from the management prospective and the technician's prospective. The basic question you have to ask yourself is why? What is causing the back log? Here are some questions to ask yourself:
If you answer yes to any of these questions, then you probably don't have an issue with the correct number of FTE. All of these scenarios can be managed without adding FTEs. However, if the increase of interface request and the increase of support issues is going to be a new "normal", you should measure your FTEs against the new normal. If it is just a bubble, then you can add contract help to get your through. If you answer no to every question, then you need to assess your FTEs. Most likely, the volumes are not matching your resource hours. I want to address this from a technician view point. Are there any inefficiencies that are causing your staff to do redundant task? If you have multiple interface engines, you could be doing duplicate work if you have come up with an architect to migrate interfaces, scripts, or logic to multiple machines. Many technicians tend to just learn to live with it and don't think anything of it. However, the inefficiencies increase when the number of interface increase. What was once an hour here or there, can suddenly start taking 3-4 hours a week. A fresh set of eyes to look over your environment may be warranted. 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.
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
|
RSS Feed