To Script or Not to Script – That is the Question!
MUSE Matters 2009 Fall Edition
Author: Brian Rogers, Product Manager, Summit Healthcare
Crawl before you can walk, walk before you can run! We all are very familiar with the concept! But how many individuals that you know leap into huge integration projects without knowing the why behind the how? If you don’t clearly understand the ‘why’ of a project, knowing the ‘what’, ‘when’ and ‘how’ is harder than you think! Deciding the best method for healthcare data exchange is no exception to this rule.
One of the most prevalent integration questions asked about is: “Should I use a scripting tool or an interface engine for my integration project”? The simple answer is you must fully understand why you need the interface in the first place, as well as when you need it and you must be familiar with the data you need to exchange (and how much volume is to be expected) prior to selecting the method of integration.
Is there a rule of thumb to go by as to when scripting is clearly the best method to use for my interface?
Generally, Scripting can be used to connect two disparate systems, typically using a spreadsheet or database as a medium. However scripted interfaces can also provide application connectivity where traditional HL7 interfaces are not an option (not available), or are considered too expensive. A scripted interface is also highly desirable when the interface must be in production under a tight deadline. This is because a scripted interface is quick to deploy and can achieve a near real-time data exchange as well as provide a means to map or cross-walk data between systems.
Clearly, scripting is the best interface method for the following interface projects. Scripting can be generally categorized in three flavors: Batch, Real-Time, and Interactive. Here are a few examples of each:
Batch
- Dictionary Building and Maintenance
- Batch Remittance Postings
- Automation of 3rd Shift Operations
- Excel or Database Uploads
Real-Time (or near Real-time)
- Scripted Interfaces (when time, money or customization is an issue)
- Blood Bank Interfaces
- Glucose Interfaces
- Streamlined Registration
- Remote office connectivity
Interactive
- Real-Time Desktop Integration
- Business Rule Enforcement
- Real-Time eligibility and insurance verification
- Barcodes
The benefits of using a scripted interface:
- Control
- Cost Effective
- Timeliness
- Highly Customizable
The drawbacks of using a scripted interface:
• This can sometimes be challenging with 3rd Party Vendors
In closing, sometimes the best solution at hand is to use a combination of scripting and HL7. This is another factor to assess as you gather your interface requirements for the project and one you should explore with your integration partner. This is especially true if you have a standard HL7 interface already in existence that you want to leverage (due to volume of data, etc), yet you need some level of customization for your interface project where scripting can be used in a cost-effective, yet reliable manner.
When is it best to use HL7 as the interface method?
It is best to use an interface engine that uses HL7 protocol for your interface method when you need to re-use existing interface feeds and reduce the number of point to point interfaces you need to manage. HL7 is also a good candidate if you have the project already budgeted, and if you have a standard HL7 interface already in existence. This interface method also assumes that you can exchange all of the desired fields you need as a part of the standard interface.
Choosing HL7 protocol as your interface method is a clear choice in most cases (outside of money, time or customization issues) when you need to feed ADT, Orders, Results, Charges or Reports to and from your HCIS and specialized third party application. Examples:
‘Feeder’ or ‘Eater’ Systems
- PACS (ADT, Orders, Reports)
- Laboratory (ADT, Orders, Results)
- Pharmacy (ADT, Orders, Charges)
- Radiology (ADT, Orders)
- OB/Fetal (ADT, Results)
- Clinics (ADT, Orders, Results)
- Glucose (ADT, Results)
- Portal (ADT, Results)
- Forms (ADT)
- Dictation (ADT, Transcription Reports)
- ER (ADT, Charges)
The benefits of using a standard HL7 interfaces:
- Usually well documented and easily implemented
- Real Time
- Easy to Monitor
- Usually Includes Logging and Tracking out of the box
- Easy Resubmission of Data
The drawbacks of using a standard HL7 interface:
- Expensive
- Lack of Data Available
- High Initial/Ongoing Cost
We have talked about HL7 and Non-HL7 scripted interfaces; how about other options that exist?
There are three other methods to explore as an option for your interface; however they all have clear benefits and drawbacks that you must think about carefully.
- API (Application Programming Interface)
- Custom Development
- Direct to Database using Reporting Tools
The API solution is great when you come across it, as it is usually very easy to use for programmers (if you have them on staff or engage their services). But by and large, many vendors do not have this option available, so you must choose between other integration methods. Also, cost of this solution will vary widely among vendors.
Custom Development is always the way to go if you have the time and money! The sky is the limit… You can engage with a responsible vendor or vendors to manage the entire project and tailor the interface to your needs. The downside here is cost, timeliness and lack of available resources to get the job done.
Direct Database extraction via reporting tools (such as NPR) is usually very cost effective and easy to extract the data itself if your staff has the knowledge on how to use the reporting tool. However the big drawback here is that typically, you only have read only access to the data itself, and knowledge of the reporting tool itself is usually sparse due to the attrition of staff.
In Conclusion:
We have reviewed a number of methods available to integrate your healthcare information. Keep in mind, one size does not fit all, and it is best to do a thorough review of your available options prior to choosing a method of integration. Generally, one of the driving factors to consider in any interface, fully or semi-automated, is the amount of daily volume that you would experience between systems. The vendor assessment of upfront and ongoing volume is a very important part of the due diligence found in an engagement’s qualification process, so be sure not to skip this step!
Finally, a few words of wisdom to impart; Set the standard high of what is required to successfully interface your hospital information system. It’s a good idea to have a bag of tricks at your disposal (proven, reliable integration applications) that cover HL7, Scripting, Flat Files and more
Read the entire digital MUSE Matters 2009 Fall edition
Call image Brian.jpg
Next to his picture write Brian Rogers, Product Manager, Summit Healthcare
About the Author:
Brian Rogers is a Product Manager for Summit Healthcare with experience in MEDITECH technology. He is experienced in designing, developing, and customizing System Integration Solutions via both HL7 Standard Interfaces and workflow user emulation. He has gained knowledge as an Interface Programmer in MEDITECH's C/S NMI group, as well as through $T Product Development for Picis, Inc.