As part of the Affordable Care Act (ACA) healthcare payers in each state were required to integrate with a healthcare “exchange” if they wanted to offer products and participate in this new marketplace. These exchanges function like an online mall (similar to Amazon.com) for individuals to shop for, select, and purchase a healthcare insurance plan. Some states chose to create their own exchanges while others opted to use the federal exchange hosted by http://www.healthcare.gov/ (this is the website that was constantly in the news in the last couple of months of 2013). Not only did healthcare payers face tough challenges creating individual products that could be sold on these healthcare exchanges, payers also faced several technical challenges integrating with the healthcare exchanges. As the political discourse around the ACA evolved requirements for integrating with the exchange evolved requirements sometimes changed causing extreme disruption and misinformation.
One major technical challenge healthcare payers faced in this integration was the implementation of systems to accept individual enrollments for persons who did not previously have insurance and could not purchase insurance through their employers. The federal agency that manages the implementation of these systems is the Center for Medicare and Medicaid Services (CMS). Payers who offer plans on these exchanges are required to be able to accept an enrollment in the form of a 5010 X12 834 EDI transaction (this went live effective 10-1-2013). Throughout 2012 and 2013 CMS routinely updated and modified rules for processing these transactions through announcements to payers on conference calls, e-mails and updated companion documentation. In addition to 834 processing requirements, CMS requires a variety of acknowledgements and other outbound transactions. Payers offering plans on the exchange must be able to generate these transactions. Lastly, CMS also has periodically asked payers to process audit files to ensure that no enrollments were lost.
Microsoft’s BizTalk platform is a great solution for implementing this type of processing. BizTalk can receive data in almost any format, translate this data into something that can be used by the organization receiving the enrollment, perform validation and special processing, integrate with external (to BizTalk) systems that require the data, and create acknowledgements and other messages that can be routed to trading partners such as CMS. Below are examples of business requirements that may be discovered when a payer integrates with the Federal Exchange. Below each requirement is a brief description of how BizTalk can be leveraged to meet the requirement.
Requirement: Accept a 5010 X12 834 transaction
Solution: BizTalk ships with schemas and components to translate EDI transactions into a format that can be translated and used. This is helpful because these schemas accurately reflect the data types and the structure of the EDI files. The 834 transaction has around 1,000 elements and sub-elements that are arranged in a hierarchical structure. The elements and sub-elements belong to segments, which are arranged in loops. Building a structure to represent the 834 transaction from scratch would require defining the hierarchical structure, loops, segments, and elements. The out of the box schemas included with BizTalk saves firms the hassle of defining these transactions manually.
Requirement: Reuse processing logic for other kinds of enrollment transactions.
Solution: BizTalk allows developers to create a common format to represent business objects within their organization. Developers can then map different formats of these objects to the common format, allowing one set of rules to be applied. The common format is typically referred to as a canonical schema. This has an added bonus of achieving loose-coupling. Internal processes can change without affecting the contracts/message formats received from external systems. This also makes it easy to onboard new trading partners. Once a trading partner is connected to the system all that needs to be done is to map the data from that trading partner to the canonical schema.
Requirement: Integrate with the payer’s membership system to set up coverage for the enrollee, integrate with the finance system to setup payment information for the new enrollee, and integrate with the reporting system for business intelligence reasons.
Solution: BizTalk ships with a whole range of adapters that allow users to connect to a wide variety of systems to accomplish the exchange of messages. These adapters are not only adapters for exchanging messages over protocols like sftp, ws*, etc. BizTalk also comes with a wide range of “Line of Business Adapters” for connecting to systems like PeopleSoft,Tibco, SAP, and IBM iSeries. Not only does BizTalk ship with adapters for connecting to common systems, you can also create a custom adapter if the need arises.
This is not a complete list of high level requirements for a payer implementation of the ACA (it follows that this is also not a complete list of the ways BizTalk can enable organizations wishing to integrate with federal exchange). However, it does serve to highlight some of the issues facing payers who are considering this type of project as well as highlight how a proven solution like BizTalk can bridge significant challenges quickly and effectively.