10 Interface Engine Must Haves white paper

 OVERVIEW Requirements to determine the interface engine you select for the first time, or to replace an existing solution differ depending on the organization. For some, cost will play a more dominant position whereas for others, certain key features, or conforming to new requirements may be more critical. Most, however, want a high level of quality and value. Still more just don’t want to make the wrong choice and end up with a new solution that is neither future-­‐proof nor cost effective. This white paper explores the role of standards, platform selection, database support and a myriad of other considerations for selecting an interface engine that can meet your requirements today and for years to come. PURPOSE The purpose of this white paper is to help with the selection of an interface engine. It provides a checklist of requirements for the selection, or replacement of an interface engine. The 10 THINGS, examined below, are Must-­‐Haves today and need to be checked off in any evaluation of an interface engine. Available at: http://healthcare.pilotfishtechnology.com/pdfs/10-­‐Things-­‐Interface-­‐Engine-­‐Checklist.pdf 2 1. Does the interface engine use W3C standard technology? W3C standards define an Open Web Platform for application development. By selecting an interface engine that is based on W3C standard technology you can be assured that it is an open and widely supported standard. The independent World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web. This consortium is comprised of member organizations that maintain full-­‐time staff for the purpose of collaborating on the development of standards for the World Wide Web. If you select an interface engine based on W3C standards you won’t be locked into a technology or vendor that uses a proprietary language and/or scripting that does not have broad support. It ensures that you can leverage a vast library of web resources. It also ensures that you can draw from a very large resource pool of highly skilled developers worldwide to easily support your interface engine investment. 2. Is the interface engine Platform Agnostic? In order for software to be Platform Agnostic it needs to run equally well across more than one platform. Selecting an interface engine that is platform agnostic offers you tremendous flexibility. Just a few years ago, Apple was not considered a major player in Healthcare. Now with the Apple iPad, the launch of Apple’s HealthKit, and the large players that have already 3 announced support for the platform, Apple’s role in Healthcare is pretty much assured. A platform agnostic interface engine allows you to leverage the best technology at the time, whether based on cost or features. It can also eliminate the high license fees associated with certain platforms. 3. Is the interface engine Database Agnostic? Database agnostic describes the capacity of software to function with any vendor’s database management system (DBMS). This enables software or hardware to work with various systems and need not be customized for a single system. Simply put, it is an application that can talk to different databases without more than configuration changes. Selecting an interface engine that is database agnostic opens up your options. Again, as with being platform agnostic, you can choose the database that offers the best features and value at the time. This flexibility allows you to change the database vendor as your needs evolve. Often an organization will start small with a low cost alternative such as MySQL, and then as data volumes increase move to a more robust database like Oracle. A database agnostic solution allows the organization to make that move with minimal disruption. It also allows the possibility of not being subject to the high license fees of certain database vendors. The interface engine you select should support any modern database whether it is SQL Server, Oracle, DB2, MySQL, PostgreSQL, Access DB, H2, or any database based on open standards for the greatest flexibility. 4 4. Is the interface engine extensible? Technology is always changing, and new requirements are always being introduced. As an example, the Government’s task force JASON, in its A Robust Health Data Infrastructure report,
recently recommended the use of standardized data-­‐level APIs (Application Programming Interface) across the healthcare industry as a means to achieve greater interoperability. When you select an interface engine make sure it offers an API for users to extend existing components, or to write new ones using industry standard platforms and languages. You should also be sure that new Adaptors, Transports, Transformations, and other modules can be written in industry standard languages using a straightforward, simple approach. 5. Does the interface engine provide validation within the application? Validation is key to the workflow of interface development. Validation can help do away with the time consuming and error prone process of desk checking sample feeds. The interface engine should offer a robust data validation facility that can be used to describe arbitrarily complex validation rules. 5 Once the validation rules are established the engine should allow use of these rules in place of manual processes to facilitate implementation. When in production, the validation should also offer the opportunity to use the same set of validation rules to maintain data quality and catch errors closer to the source. It should also offer the ability to generate a report that is in an easily understood format. The interface engine should provide, at a minimum, Data Format conformance, Business Rules and Schematron Lookup validation against external sources and custom validators. 6. Can the interface engine support both legacy and new standards? Legacy standards still play a dominant role in healthcare. Take for example the HL7 standard which dates back to the late 1970s. HL7 v1 and v2 are essentially refinements of an even earlier University of California at San Francisco (UCSF) Medical Center protocol. HL7 was initially developed to transfer clinical and administrative data between Hospital information systems. In the U.S. it is still the de facto means of moving healthcare data today. As integration requirements have evolved over time, it is a standard that no longer meets the broader requirements of the healthcare industry. To meet these requirements, HL7 3.x, based on XML standards and others, has been developed. These newer standards are still not widely implemented due to the cost and time that would be required to supplant HL7 2.x. HL7.org recently introduced FHIR, (Fast Healthcare Interoperable Resource, pronounced Fire). FHIR combines the best features of HL7 v2, HL7 v3, and CDA, while leveraging the latest web service technologies. 6 As you can see, standards do not stand still. The interface engine you select should allow new standards and modifications of existing formats to be leveraged through simple configuration rather than relying on architectural changes. Updating standards should be as simple and direct as loading in newer versions of these standards. To meet these ever changing requirements, the interface engine you select should support any XML standard and have the capacity to be easily extended for new standards as they come into play. Many interface engines are built on old technology that is not easily adapted or suited for modern standards. The interface engine you select should be architected to support the old and the new. 7. Does the interface engine provide a robust tool for both simple and complex data transformations? Ask any experienced interface developer and they will tell you that data transformations are one of the most time consuming aspects of interface development. How easily the interface engine allows you to read in data and work with non-­‐standards compliant data and different standards and formats is critical in a comparison of interface engines and for determining productivity levels. Is documentation included inline, or do you need to spend time going out of the application? Many interface engines offer line drawing mapping tools that look fine in demonstrations, but fail miserably in real life interface development. Others use proprietary scripting which locks you into a vendor and may require specialized training. When you select an interface engine 7 make sure the mappings are based on W3C standards, widely adopted technology, and can handle any mapping no matter how complex. 8. Does the interface engine support broad based error handling? Interfaces are not perfect, they connect to external systems, and those systems may go down. To support this reality, the interface engine you select should be designed for pro-­‐active notification of errors and exceptions. Can it send email alerts with error details when an error occurs? Does it support the ability to call another interface in case of an error? Does it support integration with any application that supports the Simple Network Monitoring Protocol (SNMP), another industry standard? It should also offer customizable logging, so that your specific error reporting requirements can be met. 9. Does the interface engine offer inline testing within the application? Any developer knows that testing often takes the bulk of the time in interface development. Your interface engine should allow you to test an interface end-­‐to-­‐end within your application. This saves you time from having to go outside the application. Does it allow you to stop and 8 start your test at any stage of the interface pipeline? Does it provide detailed messages for why an interface has failed for easy analysis and remediation? Lastly, how easy is the testing process? The interface engine you select should offer an intuitive interface that is easy to use and learn for maximum productivity. 10. Is the interface engine designed for simplified ease of use and a short learning curve? Evaluate how easy the integration engine is to use. Does it offer flexible configuration for building interfaces without having to write code? Other considerations include the support integrated into the interface engine for collaboration between analysts and developers. Does it offer a process workflow or pipeline so that interfaces are all easy to follow and configured the same way? Or does it just give you a bucket of tools that you randomly work with? For the greatest flexibility does it offer both an easy-­‐to-­‐use graphical mapping view and a code view for advanced developers? Is the interface engine intuitive or does it have a steep learning curve? Does it utilize standard programming languages so once you learn the process workflow you are good to go? Or does proprietary scripting need to be learned? Look for a graphical, intuitive and simplified approach to interface configuration for the most value and greatest productivity gains. 9 CONCLUSION When you’re done looking at these 10 factors and why they are critical don’t forget to take into consideration the cost for test, development, as well as back-­‐up servers. Note that some vendors may charge additionally for these. Test, development, and back-­‐up servers are an integral part of the requirements for best business practices for interface development. Make sure that cost is included in your overall assessment. Extra license fees for these can add up quickly. If you use the above criteria as your guide for selecting an interface engine, you’ll be well on your way towards meeting today’s and tomorrow’s integration challenges. At PilotFish, we want you to succeed. Over ten years ago we brought our middleware and interface engine solutions to market. We helped invent the space. So rest assured we’ve learned a thing or two about interface engines. If at any time you have a question on what has been presented, or you have questions on what your requirements should be, please give us a call at 860 632-­‐9900 x511. If you’d like to learn about PilotFish’s integration solutions please visit our website at: http://healthcare.pilotfishtechnology.com/. 10