 Every project begins with great excitement. The organization has finally committed the resources to accomplish a large scale project. The kick off meeting begins and people begin to travel for training. The project begins to take off. Life is sailing along, and you get to 90 days prior to your go live. How do you know if you are really ready for implementation?
Click on "Download the Article" to continue......
0 Comments
 At the beginning of every project, you must take a group of diverse individuals and begin to mold them into a cohesive team. You want to build synergy within the team. But how do you take dozens of people, sometimes hundreds, and get them working together toward a unified goal. The answer is rather simple and you probably learned it in fourth grade math……..lowest common denominator!
In any project, you want to educate on the most common factors that are mutual to all teams in the project. This will help define the culture, behavior and goals of any project. Click on "Download the Article" to continue......  Recently, one of our clients upgraded to Meditech 6.07 PP12 and we discovered that Meditech has now added Event Types in the Outbound ADT Interface. For anyone who has worked with Meditech interfaces, you know this is a welcomed feature. As we worked with Meditech, we were able to ascertain a list of Event Types that they have included in the interface. These values will populate EVN.4.
The following is a list of Meditech values that can appear in EVN.4: "EDACCT#" - "EDIT ACCOUNT #" "EDUNIT#" - "EDIT UNIT #" "EDSTATUS" - "EDIT PRE/SCH STATUS" Click Download the Article to continue.....................  I have to admit it. Project Management is one of my passions. I love the many facets of the role. It is exciting to see project teams come together and a project start to take life, but there are also many challenges and hurdles to overcome. When I get the opportunity, I like to speak from the perspective of lessons learned. I know that I will always be able to improve upon my skills, but it has also given me the ability to see a common thread through all the projects I have led. There are 8 common challenges that any project may face.
 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.
|
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