What Every Interface Analyst wished Everyone Knew about Integration!

RSS Feed

I admit, I have been doing this for a long time.  I have enjoyed my career and I have encountered so many talented and incredible people along the way.  However, can I say that I have found that there is some misconception about integration.  This article is not meant to be divisive or “point the finger” at anyone, but to help bring about understanding about some of the misconceptions of integration.

• Integration is not just the responsibility of the Interface Analyst.  Each sending and receiving application is responsible for the entire stream of data.
  

• You can’t create data if it isn’t there.  I have seen this one a lot.  Can’t you just put the logic in the message?  If it is a literal value that is the same for every message, yes, I can.  However, if the values being added to the message are different AND there is no way to differentiate between the messages, I cannot.
  
• Don’t you just set it up and it just runs!!  Interfaces change!  Many times, during an application update the upstream or downstream applications change and the message changes.  Interfaces need constant review, update and maintenance.   Also, master files change constantly as well.  For example, the location master file changes.  Organizations add new locations and if you are filtering by location, your interface needs to now include it.
• I don’t understand why special characters are an issue.  This is most common when users have free text fields.  HL7 architect uses special characters to define the data elements of a field.  The most common characters are, but not limited to, |\~^&.  When a user adds the & or any of these characters, the engine doesn’t understand that it shouldn’t parse this character and often times the message errors out.  Can’t you just strip them out?  Well that depends.  If you know which fields, yes you can.  However, you can’t just stripe them out of the message because the message needs them to know where to parse out the field.
  
• Making the Interface Engine do what the application can’t.  An interface Engine is not an application, so when you try to have it do the logic of an application, you create a monster that is hard to maintain.  I have seen organizations try to create so much logic in an interface, that it is almost impossible to maintain it especially if you are downloading many master files in your engine to check against. 
  
• Master Files in your engine need to be updated frequently.  The most common is the provider file.  Your organization adds providers constantly, so you need to create a mechanism to update the tables in your engine.  Otherwise, they become outdate quickly.
  
• Sudden Growth and Expectations.   In the last five years, we have seen integration, interoperability and interface exponentially grow with RHIO/HIE’s, and order/result to provider offices.  What use to be a one-person job, is no longer.  Look at and review your resources.  It is most likely why your integration projects are falling behind or you keep losing people.