Monday, July 29, 2013

Direct Enrollment & the Federally Facilitated Marketplace: the Risks


At first blush, the Fully-Integrated model may seem like the best option because of the control it gives payers over their customers' shopping experience and their brand. But, it is technically complex to implement and poses quite a number of implementation risks. Here are just a few of the immediate risks that I can see to the approach, which leverages an evolving Direct Enrollment Application Programmatic Interface (API) that is still under development by the FFM. 

Seven Risks

1. Complexity of Integration: The integration pattern the FFM has defined is complex, requiring two web session transfers (first from the issuer site out to the FFM's and then from the FFM's back to the issuer) and two web services calls from the issuer to the FFM/Data Hub, the first to retrieve household and subsidy information for the applicant and the second to submit the enrollment once complete.

2. A New, Untested API: Real-time integration between two systems can be challenging in their own right, but in this case we are dealing with a brand new system being developed against an aggressive timeline and an integration pattern that has not been attempted before. The newness alone raises a considerable risk of bugs and errors in the web services and redirect.

3. The Test Pool Is Crowded: The biggest  challenge in system integration is generally the coordination, testing, and triaging of issues between the two supporting parties—that is, when an exception occur, tracking down which system is responsible and determining the root cause. In this instance, it's not two organizations alone attempting to implement an integration but potential a large number of parties attempting to integrate with the FFM all at the same time, which only raises the risk of delays in testing and working through issues

4. Multiple Browser Windows: The FFM's integration pattern calls for the FFM's web pages to open in a new browser window from the one used to navigate the issuer's site, which from a user experience perspective is less than ideal.

5. Impact on Issuer's Shopping Portal Flow: To implement the full direct enrollment pattern, an issuer would need to update their own shopping experience to take into account the APTC's and CSR's from the subsidies in the experience (for example, when displaying premiums to users) as well as handle the more complex enrollment scenarios of dual-taxpayer households. In other words, the development effort is not just in the bouncing out and bouncing back from the FFM site but in fact changes the overall shopping experience.

6. Brand & Customer Satisfaction: When a user's shopping experience begins on the payer's site but bounces out to the FFM, the user is quite likely to associate any problems or issues incurred on the FFM's site with the issuer itself, putting at risk the issuer's brand and customer satisfaction if there are problems on the FFM's end

7. Can I Come Back Later? The complexity of the integration is compounded by the functionality needed to handle a shopper who doesn't complete the process in a single web session. Because of the complexity of the information required for the APTC/CSR application process, it is quite likely that users will "save and come back later." The issuer's web site will need to be able to handle those situations and all the various user paths: e.g. What happens if they come back to the issuer's website when they are ready to continue? What if they return to the FFM's site?

Considerations

These are some significant risks, and each payer will have to decide for themselves if the rewards are worth the risk and expense of the fully-integrated model. Because Exchanges and QHPs are brand new, there is not solid track record or set of best practices to draw upon to understand consumer behavior when it comes to shopping for insurance with government subsidies.

In my view, brokers with automated sales systems have much more to gain from the integration than payers do, and it would be perfectly understandable for payers to decide that they'll let other organizations be the crash test dummies and work out all the kinks and implement their own integrations later if they prove valuable.

But, it may well be worth the risk for your organization to get out ahead of the pack. We'll look at some of those considerations next.

No comments: