The traditional economics of the software industry can be very profitable. Once a company sells enough copies of its software to cover development costs, every additional unit sold after that generates pure profit. With this economic model, companies do not have to emphasize efficiency or innovation.
However, the economics of developing software change dramatically when the final product has to be integrated with customers' existing systems. Development costs become variable and unpredictable, with each sale requiring custom integration work, impacting expenses and overall profits.
When it comes to healthcare, organizations must be able to integrate multiple disparate systems. Almost all software sold to hospitals, clinics, labs or any other healthcare organizations requires integration with existing networks and applications in order to become a valuable addition to the organization's existing IT infrastructure.
The healthcare industry also has its own messaging standard: the Health Level Seven (HL7) messaging standard. HL7 was intended to standardize integration within the industry. However, organizations have interpreted and implemented the standard a variety of ways, resulting in a range of integration challenges.
While some cite the ambiguity and optionality of HL7 as the leading contributors to the inconsistency of implementations, many other factors come into play, such as:
• Misinterpretation of the standard;
• Disregard by large vendors regarding adhering to the standard;
• Multiple versions of the standard;
• Vendor errors during HL7 implementations; and
• Numerous ways to represent the same information.
For instance, data about whether a patient smokes can be classified several ways. While one system may classify a smoker as “heavy,” “medium” or “light,” another may record the average number of cigarettes smoked per month. These subtle differences require organizations to write and maintain custom “glue” code that is unique to every customer site.
Software providers working with healthcare organizations face additional challenges such as increased development costs. Many software companies are grappling with the economic challenge of reducing the time required to write and maintain site-specific code.
In this economic environment, many software vendors and healthcare organizations are investigating the merits of both sides of the well-known buy-vs.-build debate. While the majority of development teams are capable of constructing interfaces, very few are able to do so in a cost-effective manner.
There are several key considerations to review before you decide whether to custom build an interface or purchase one. They are:
The opportunity cost
Spending significant resources on the development of custom interfaces when there is software available is less valuable than devoting the same resources to projects that provide a competitive advantage to your business.
The true investment
The initial cost estimates of building integration software typically do not include long-term maintenance costs. However, healthcare integration is an on-going process rather than a one-time project. Most projections on the cost of maintaining and updating code are often unpredictable, resulting in the true investment amount being overlooked or underestimated.
Integration is not simple
Integration usually consists of connectivity, transport, routing and data manipulation. Each implementation will present unique issues, with each site requiring its own custom code, unique connections and destination types.
The pitfalls of proprietary
Healthcare integration is specialized, but that doesn't mean it needs to be proprietary. In addition to the expenses associated with writing and maintain site-specific custom code, proprietary systems can be vulnerable to outside attacks or corruption.
Features matter
Successful projects rely on integration platforms that provide flexibility. Monitoring and logging features are essential to the support, maintenance and reduction of downtime in any integration project. Features such as configurable notifications are vital to troubleshooting and minimizing support costs.
Think of the future
It is often all too easy to think in terms of single projects. If you look at a single integration project and determine that your development team can build the required interface, what happens when the next one comes along that is more complex, more sophisticated, needs more features and requires the flexibility to change? You will likely end up with unmanageable code and a poorly designed system that is ultimately more expensive and less feature rich than a third-party system.
Conclusion
As healthcare organizations continue to adopt electronic medical records and other technology, the ability to exchange information between disparate systems is critical. Integration is increasingly a pressing issue for hospitals and other healthcare providers that typically rely on multiple computer systems for a wealth of patient data.
Before creating a custom integration solution, healthcare organizations need to carefully examine the challenges and costs of creating such a system. The on-going costs, maintenance and overall complexity may end up making a custom solution more expensive in the long run.
About the author
Eliot Muir is CEO and founder of iNTERFACEWARE, a software provider committed to simplifying healthcare integration. For more information on iNTERFACEWARE: http://www.interfaceware.com.
