In healthcare, it’s a common occurrence to find your organization having to make an investment, unplanned in many cases, in order to comply with a new regulatory requirement due to Health Reform. When faced with a new compliance need, I have heard many wistfully ponder the question of ROI, yet are already resigned to another initiative to add to an already burdened organization. What I then help folks understand is that you can get a ROI on this “required” investment, but it won’t be easy and it’s not obvious. The answer comes from stepping back from the specific requirement, reviewing how the impacted part of the business runs today, analyzing the changes needed and examining how the requirement could be a catalyst for something bigger. Most of the time, the focus is on the individual activities and tasks performed today and how they need to be tweaked, new steps shoe-horned in, an extra report run, etc. Our typical response mode is to focus on the micro and don’t rock the boat. By stepping back and examining the greater context or macro view of business activities and processes which will be impacted by the regulatory change, the organization can do two things. One, comply and two, by expanding the focus, and yes, investing more, effect a longer term change that improves service levels (customer satisfaction) and reduces the cost to serve, effectively generating a return to offset that dreaded investment.
To help illustrate this, let’s focus on an effort underway by the Payer community to prepare for the forthcoming Healthcare Reform Health Insurance Exchanges (HIXs). A primary engagement point between the payers and the HIXs deals with eligibility and premium information. For any payer, a common daily activity is the receipt and handling of eligibility data from their many clients, particularly employer health plans. While the 834 does exist for this very purpose, the complexity of the transaction, 
along with the various sources, such as HRIS solutions, HR staff, 3rd parties, etc. have led to a myriad of formats and mechanisms to facilitate this exchange. Typically, these many feeds will either go directly into the underlying claims systems that support the membership in question or through a conversion process that spits out a proprietary eligibility load file or an 834. This conversion process is somewhat of a one off with each client/feed, becoming a separate job that must be run, trouble-shooted and maintained. Many are reacting to the HIX challenge by just setting up new jobs, thankful that the HIXs will be using 834s and trying to figure out the use of the 820 for the premium.
So what’s the broader or macro view and opportunity here? In most cases, the payers are using a complex and expensive set of services set up years ago that focus on only EDI transactions. Again, the opportunity that has presented itself is one of being able to step back, look at the broader context and, albeit a greater investment, drive change in how the organizations handle transactions in general. As many payers wrestle with the need for greater access to, and accuracy of data, they are looking at establishing Data Governance, Master Data Management, ETL platforms, Data Repositories, Data Warehouses and delivery mechanisms. An enabler to the aforementioned is the deployment of a data and transaction backbone, an Enterprise Service Bus (ESB). And here’s the link: ESBs can not only support the organizations data consumption, but it can handle the operational transactions, both internal and external. Furthermore, abstraction can be fully supported, meaning that a standard is developed for introducing eligibility data into the transactional platforms that consume it. The ESB would accommodate the knowledge needed to interpret the inbound side of the 834 or 820, transforming it per established business rules and pushing it on its way to one or more destinations. The beauty of such a setup is that it can be done incrementally. In other words, you don’t need to change everything out at once. The new and the old can co-exist, while migration occurs. The organizations commitment up-front is to establish the new foundation and implement first those changes driven by the regulatory requirement. An added benefit is that you tend to end up with a single interface into the transactional platforms for each core transaction and/or set of master data. So, when it comes time to upgrading the underlying platforms, you have a minimal number of interfaces to worry about.
Given the multitude of offerings in the market today, any payer organization can do the above. By multitude, I mean solutions for any budget and varying complexities of environments, along with many of the traditional technology stacks, such as IBM, Microsoft and Oracle. So, if you’re willing to step back and look at the broader opportunity, a change driven by regulatory requirement can be leveraged in a way that benefits the company, the customers and, over time, provide the return you seek.
