Solution Provider Edition: 5 Must-Haves in an Interface Engine
Don’t let your interface engine fail you!
As a solution provider – time is money. Implementation and production delays can make the difference between a profit and loss. The faster you can get your product or service integrated with customer systems and/or generate transaction fees, the better your bottom line. So how does the engine you use (or are evaluating) do on speed and ease of configuration?
We were at HIMSS 2015 in April and the heat is on solution providers to be positioned for new demands on data exchange and integration from their clients. Karen DeSalvo, M.D., M.P.H., M.Sc., the National Coordinator for Health Information Technology, emphatically projected the need to standardize standards, including APIs, and implementation standards. Accelerating maturation of FHIR, recently introduced by the HL7.org, was a huge concern. Breaking digital health news about mHealth, mergers and acquisitions, plus announcements from payers, providers, pharma companies and government agencies could make your head spin.
Check out your interface engine for its capacity to deal with challenges now and to come.
Homegrown systems often don’t have the features and capabilities to deal with real world use cases efficiently. They can tie you up with maintenance and keeping them up-to-date. Older engines may not allow you to leverage Web Services or XML standards. They also may not be extensible to support new technology. Open Source solutions may burden your staff with writing custom components and take them away from their core focus – your products and services. Open Source solutions may also not meet your performance requirements as you scale up. The fact is that you may have outgrown the capabilities of your Open Source solutions.
Here are 5 Must-Haves to Evaluate in an Interface Engine Today
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.
When you select an interface engine based on W3C standards, it ensures three extremely beneficial business benefits:
- You won’t be locked into a technology or vendor that uses a proprietary language and/or scripting that does not have broad support.
- You can leverage a vast library of web resources.
- You will be able to draw from a very large resource pool of highly skilled developers worldwide to easily support your interface engine investment.
Is the interface engine Platform Agnostic?
In order for software to be Platform Agnostic, it needs to run equally well across much more than one platform. Selecting an interface engine that is platform agnostic offers you tremendous flexibility. For example, the progress of mHealth and Apple and Android smart device adoption rate are hailed for their capacity to influence personal and population health. Apple’s HealthKit has moved from introduction to important programs and alliances. Healthcare providers are using mobile and wireless-enabled devices across the entire care continuum and settings, from homes to hospitals.
Cost-efficient flexibility and responsiveness are more dependent on being Platform Agnostic than ever. 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.
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 eliminates the need to be customized for a single system. Simply put, it is an application that can talk to different databases with nothing 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.
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 – 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.
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 (pronounced Fire), Fast Healthcare Interoperable Resource. FHIR combines the best features of HL7 v2, HL7 v3, and CDA, while leveraging the latest web service technologies. Backed by the Argonaut Project to accelerate its adoption, FHIR is a modern standard where users can leverage Web Standards such JSON, HTTP, etc. and REST-ful architecture.
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.
Leveraging your integration engine for profit and success
For solution providers, it’s all about speeding up deliverables and implementations, generating fees sooner, improving customer service, and increasing overall revenues. It may be time to address limiting costs associated with old-school infrastructure and make changes, as you will need to do more. Clients want to be assured that your product and services can interface smoothly with their systems – now, and as they change. You can’t really do that without these 5 Must-Haves, just to start.