D288 IT Solutions
  • Home
  • About Us
    • Our Mission
    • Our Values
    • Our Story
    • Our Founder
    • Our Clients
    • Our News
  • Our Services
    • Infrastructure Services
    • Integration Services >
      • HL7 Consulting Services
      • HL7 Outsourcing
      • Epic Bridges
      • Meditech NMI
      • RHIO/HIE Integration
      • HL7 Project Management
    • Transitional Leadership
  • Careers
    • Our Work Culture
    • Our Benefits
  • Customer Care
    • Submit a Ticket
    • Feedback
    • Blog
    • Resources & Downloads
  • Contact Us

Interfacing Patient and Vital Signs Monitors

6/22/2016

0 Comments

 

Meditech 6.X: Capturing Temperature Source in a Single Query Field

Picture
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......

Download Article
0 Comments

8 Characteristics of a Successful Project Manager

5/20/2015

0 Comments

 
Picture
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? 

Download Full Article
0 Comments

Are you Interface Engineers working smarter or harder?

4/28/2015

0 Comments

 
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. 

  • Naming conventions of interfaces

  • Standardize programming structure of your engine

  • Required documentation of programming and modifications

  • Testing environments

  • Testing requirements

  • Synchronization between the test engines and productions

    • This can go either way.  Most likely you have test to production covered.  However, admit it, you made a change quickly in production.  Did it get put into the test engine?

  • Change control

If these things are not in place, most likely, you are working harder not smarter.  These items can make a difference in the number of hours spent on projects and support tasks.  Take a look at your environment and see how you are doing!

0 Comments

Creating an Environment of Cross Training & Sharing

2/11/2015

0 Comments

 
Picture
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:

  • When each individual is out, it will help the team cover for them.  This means less calls to them on their days off.

  • We need to work smarter not harder.  If we are sharing ideas and solutions, we all benefit. 

  • We must have consensus on the common factors and each individual is executing them across the board.  It should not be a free for all and everyone doing his/her own thing.  This will decrease the analysis time when something goes wrong because everyone is on the same page.

    • Naming conventions

    • Common store procedure are used by everyone.  E.g. filter patient by outpatient location by passing department codes as parameters.  There is no need for multiple procedure to do this. 

    • Time Out/Alerts Management.  Who gets notified when an interface gets hung up?

    • Etc.

  • Don’t become so rigid or controlling of the environment that easy fixes become hours’ worth of work. 

  • In weekly meetings, each team member reports on what they are working on and its progress.  No one has to second guess what the other team member are working on.  If a team member is stuck on a project, others can help.

It is human nature to adhere to what we know.  When an engineer learns a system, it is only natural that they develop all the interfaces for that system.  There are times that this approach does make sense especially if it is a new system being implemented.  However, I would like to challenge you on this.  The downside to this is that only one person learns it.  Try to break up the assignments across your engineers.  This will create an environment of cross training and sharing of information once they can break through the silo barriers.  It will force them to work together as a team.

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!


0 Comments

How to avoid developing common code again and again

10/9/2014

0 Comments

 
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!
0 Comments

It seems like my interface projects are stacking up.  How do I know if I have the right number of FTEs?

9/9/2014

0 Comments

 

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:

  • Have you received an unusual number of requests to add  interfaces?
  • Has there been an increase in absenteeism or leave of absences?
  • Have the support issue increase where staff can not get to development?
  • Are your current projects wrapping up as expected?
  • Is your staff being asked to do task outside their normal duties?

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.

0 Comments

Why does it take so long to develop interfaces but actual time work is so much shorter?

8/26/2014

0 Comments

 
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

I was asked to send data via email, but don't think that is wise.  Is there a better way of sending data?

8/18/2014

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.

0 Comments

What log files should we be keeping on our interface engine and for how long?

8/5/2014

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. 
0 Comments

How do we support real time medical devices?

8/1/2014

0 Comments

 
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.
0 Comments
<<Previous
    Picture








    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!

    View my profile on LinkedIn

    RSS Feed


    TOPICS

    All
    Managing HL7
    Project Management

    Archives

    October 2019
    June 2019
    February 2019
    September 2018
    July 2018
    October 2017
    June 2016
    May 2016
    March 2016
    June 2015
    May 2015
    April 2015
    February 2015
    October 2014
    September 2014
    August 2014
    July 2014

Connect With Us:

Phone: (315) 870-5533
Toll Free: (877) 585-3975

D288 IT Solutions, LLC
13212 S 66th East Pl
​Bixby, OK 74008
Phone: (315) 870-5533
Toll Free:  (877) 585-3975
© 2022 D288 IT Solutions, LLC. All Rights Reserved.
  • Home
  • About Us
    • Our Mission
    • Our Values
    • Our Story
    • Our Founder
    • Our Clients
    • Our News
  • Our Services
    • Infrastructure Services
    • Integration Services >
      • HL7 Consulting Services
      • HL7 Outsourcing
      • Epic Bridges
      • Meditech NMI
      • RHIO/HIE Integration
      • HL7 Project Management
    • Transitional Leadership
  • Careers
    • Our Work Culture
    • Our Benefits
  • Customer Care
    • Submit a Ticket
    • Feedback
    • Blog
    • Resources & Downloads
  • Contact Us