Integration architecture first for health payers
If the landscape of a health payer’s IT system were compared to a city’s buildings and skyscrapers, then system integrations and the flow of data would be analogous to the infrastructure of roads, electrical grid, water system and sewage system of that city.
A city landscape is filled with buildings of all shapes and sizes – custom-developed solutions, packaged solutions and third-party service providers. Some of the buildings are being continually modified, while others are torn up and new buildings are erected. The only constant is the changing skyline.
The same is true with the landscape of a health payer’s IT system. As healthcare goes through transformations triggered by changing government regulations and the need to curtail rising healthcare costs, the only constant is the changing skyline.
Unlike actual cities, very little attention is given and investments are made in the infrastructure that supports the buildings in a health payer IT landscape. Systems and solutions can go up fast, but if the infrastructure is nonexistent, inadequate or inflexible, the bottleneck to change will be the time and cost spent in integrating the solution to the rest of the system landscape. For health payers, continuously investing to improve integration architecture and capabilities is the key to keeping up with the changing system landscape.
Practically speaking, investing in integration architecture is not easy to pull off. Although a lot of an IT division’s operational costs may be buried in supporting poor integration architecture, there is very little appetite for pure re-architecture or re-engineering projects, unless the need is dire to the point that the poor architecture is affecting business continuity.
The cost of incrementally improving integration architecture needs to be built into projects that impact system integrations. When a new building is being planned in a city, city planners consider the impacts of the new building on the infrastructure, like parking, roads, traffic flow and water, for example. Builders often are required to pay for infrastructure changes and improvements to accommodate the new buildings.
Similarly, whenever a new IT system is introduced or is planned to replace an existing system, health payers should consider the upstream and downstream integration costs and what might be improved in the overall integration architecture to capture the up and down flow of integration changes in the future. Improve the integration architecture as part of the implementation of the new system to encapsulate the system as much as possible within your IT landscape.
Done consistently and over enough time, integration architecture will organically and incrementally improve the IT landscape to allow for greater flexibility and to reduce time and costs in future system replacement projects.
While incremental investment in integration architecture is all well and good, don’t expect to hear support or praise from vendors who provide packaged solutions or third-party services. Vendors and third-party service providers have a natural incentive to lock clients into the solutions or services they provide. After all, tightly coupled system integrations to the vendor solution or third-party service help increase dependence on the vendor.
Often, health payers look to vendors for integration architecture advice with the assumption that the vendor knows best on how to integrate their solution. However, the incentives for the vendor to create lock-in and the incentive for health payer to create flexibility for change in their system landscape are misaligned.
With a little planning and a focus on payer-centric integration architecture, as opposed to solution-centric integration architecture, health payers can architect integration solutions that create flexibility for future system replacements and encapsulate the vendor solution within their system landscape to reduce lock-in and dependence.
As health payers start thinking and building payer-centric integration architecture, the system landscape’s critical assets will not only be the systems, but also the integrations that support them.
An health payer’s IT division will also need to transform to add strong, capable people in integration architecture and integration development. Traditional health payer IT division’s development resources will need to shift or rebalance from developers in legacy technologies and custom applications to integration architects and integration developers.
Just as city infrastructure is planned, built and enhanced over years, so is integration architecture. For health payers currently suffering from solution-centric, tightly coupled integration architecture, the right time to invest in improving the integration architecture is not in the distant future. Rather, it should be with every project that touches integrations.
Thinking about integration architecture first will pay off in the quest for a dynamic and flexible system landscape to keep up with ever-changing industry demands.