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

We recently migrated with another organization.  We have multiple Interface Engines.  What should we do?

7/28/2014

0 Comments

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

As an application analyst, how can I test integration through the interface?

7/25/2014

0 Comments

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

I am constantly rewriting the same code for multiple interfaces.  How can I work more efficiently?

7/25/2014

0 Comments

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

No one pays attention to our interface engine, should we monitor it?

7/25/2014

0 Comments

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

I can never tell what interface is what in our engine, what can we do?

7/25/2014

0 Comments

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

Should we backup our Interface Engine?

7/25/2014

0 Comments

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