As discussed in our previous post, healthcare companies face many integration challenges: complex data standards like HIPAA and HL7, differences in applications across the healthcare industry, and increasing regulations about meaningful use and value-based care.
These challenges are compounded by legacy technologies. Many healthcare companies’ internal enterprise applications were set up years ago using various data formats that cannot directly interoperate with one another. One way to solve this problem was to turn to enterprise service buses (ESBs) to transform and normalize data across different applications for cross-company communications, and a popular system was Java Composite Application Platform Suite (JCAPS). JCAPS was an effective way to integrate existing systems using ESBs to standardize data– and critical for healthcare providers, it offered support for HL7 data standards. JCAPS also introduced business services which allowed IT architects to design service-oriented architectures (SOA) to try to make those separate systems more responsive.
However, Oracle is quietly deprecating JCAPS — the end of extended support is next January — and customers are being advised to migrate to a different Oracle suite. With a deadline looming in less than a year, IT leaders in the healthcare industry have to start looking for a new integration solution. Now is the time to start defining the requirements for the next generation of healthcare data interoperability solution.
Modern Approach to Integration with Red Hat Fuse
The Red Hat blog ran a post in September that identified three key pain points when designing an integration architecture:
- The flexibility of the resulting architecture
- The openness of the underlying standards
- Availability of related applications or services from a single vendor
Consideration #1: Modern Architecture
This resulting architecture is one of the better opportunities available to IT departments which need to migrate from JCAPS. JCAPS is an older product, from the early tech boom. Its architecture tends to reflect that older, legacy design: vertical, hierarchical, and rigid. ESBs integrated artifacts by pulling them into a centralized location, in a design known as a hub-and-spoke architecture. While relatively simple to implement and design, this structure scales poorly, is difficult to redesign as needs change, and difficult to integrate with more modern, dynamic structures like agile development models and cloud-based applications. It’s more like a monolithic architecture, so if one area needs to grow, the whole system has to scale; likewise, if the needs of one area change, the whole system has to go through a design change.
Red Hat Fuse is a lightweight integration platform. It’s modular, which means it can run as a collection of nodes with different defined levels of data transformation and workflow management. You can create a pattern-based architecture that adapts to the unique needs of different use cases in your organization. You only use the features and capabilities that are essential for your immediate requirement.
Consideration #2: Open Standards
Although JCAPS supports HL7 standards, its foundation is built on older technology platforms. JCAPS uses NetBeans as its GUI and GlassFish as its container. These older technologies can limit your ability to adapt a more modern architectural design and roll out new services.
Red Hat Fuse, among other technologies, includes Apache Camel which allows implementations based on patterns within the IT environment (called enterprise integration patterns). Apache Camel, combined with message and web services, also serves as the core integration technology for Red Hat Fuse. Red Hat Fuse supports over 150 connectors; it also has a rich API that allows developers to write their integration services quickly. Red Hat Fuse includes a variety of default connectors, including SaaS applications like Salesforce and SAP, industry standards like HL7, technology standards like JDBC, and cloud services like Amazon AWS. Red Hat Fuse also includes intuitive tooling for easier development.
Red Hat Fuse’s open-source heritage also helps companies avoid vendor lock-in. JCAPS’s proprietary license model restricts your IT department’s options. With end-of-support imminent, leaving JCAPS and migrating to another proprietary product would only create more restrictions for your organization. For many healthcare companies, this is the best opportunity to discover the freedom and flexibility that open source software provides.
Consideration #3: Related Middleware Functionality
The last major consideration is to identify what else needs to interact with your ESB platform. Particularly to promote a DevOps environment, your IT department has to be agile enough to move between environments and to iteratively release changes.
Red Hat Fuse-based integration applications can be packaged as modular containers, based on Docker, and can be deployed on Red Hat OpenShift PaaS[link] which provides the flexibility, agility and scalability for your application development and deployments. The modular and containerized capabilities provide a path towards microservices style architecture and rapid development.
The full JBoss middleware portfolio includes capabilities like business rules/decision management, data virtualization, distributed data grids, developer kits, and system management. The breadth of available supporting applications can make it easier to create a new environment after a migration, because the resources you need are there.