Care coordination through trusted exchange networks: How CMS is requiring payers to get online
May 15, 2019
This is the second part of a series about what the new CMS and ONC rules mean for the Health IT landscape and how Redox can help solve some of these problems.
The first post on the “Electronic Notification” provision can be found here.
This post deals with “Care Coordination Through Trusted Exchange Networks” in the CMS rules.
We are proposing to require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs (excluding SADP issuers) to participate in trust networks in order to improve interoperability in these programs.
This particular requirement gives me an opportunity to explain TEFCA, which is now in draft #2 and moving along. First I want to explain the acronyms in the quote and give relative sizes around them.
MA Plan– MA stands for Medicare Advantage. Essentially, instead of the government paying for your services, they pay the plan to pay for you. An example is Kaiser Permanente, their profit goes up if you stay healthy and use fewer services.
Medicaid Managed Care– Similar to the MA plans above, managed care plans pay a set fee to an organization to provide all the care a patient needs. Medicaid targets a different population. Here is a great overview.
CHIP Managed Care Entities– CHIP stands for Children’s health insurance program. Again, the rule covers managed care providers, much like above. There are differences in how states administer Medicaid and CHIP so they are functionally separate.
QHPs in the FFEs– Remember healthcare.gov? It still exists, and that what is called a federally facilitated exchange. QHPs are “qualified health plans”, essentially it means that you’re allowed to list on healthcare.gov. Here’s an overview of the states that apply and don’t apply.
SADP– Stand-alone dental plans, these are special.
In short, CMS has two levers to pull to get payers online and sharing data:
A number of different kinds of “Managed Care” models exist where the government pays a per-person fee to a plan and the plan agrees to provide a set of services. CMS can control which plans are allowed this potentially lucrative status.
CMS controls which plans are allowed to be listed on healthcare.gov
Many of these plans, however, are administered by larger organizations, who may choose to put all of their data onto networks, not just the patients required by CMS. As they outline in the rule:
While we cannot require widespread payer participation in trust networks, we are proposing here to use our program authority in the MA program, Medicaid Managed Care Program, CHIP Managed Care Program, and QHP Certification Program for the FFEs to increase participation in trust networks and to bring the benefits of such participation to those programs.
The rule does not go into too much detail about what a Trusted Exchange Network actually is, but requests comment on how TEFCA can be used to further the goal of the rule. TEFCA is essentially a plan for a “network of networks” whereby a central authority certifies networks and sets technical and legal “ground rules” for sharing data between unaffiliated groups. For example, the likes of Commonwell and Carequality, both of which Redox is also connected to, would be key providers of services under TEFCA. Regional HIEs and other geography-based exchanges will likely also fall under the rule, and Redox is connected to several.
The real challenge for the payers affected by the rule is going to be technical. The technical foundation for TEFCA is pinned by aging standards– notably IHE profiles XCPD, and XCA. Redox supports these in all directions, and naturally, we use them to connect to the Commonwell and Carequality networks, among others.
The real power of Redox is our ability to simplify the arcane and complex transactions into a usable API that a modern web developer can understand. The functionality in XCPD and XCA are exposed in Redox’s ClinicalSummary and PatientSearch data models. Redox supports dozens of other methods for getting data into the Redox platform and transforming it. For example, Redox could support a payer who only had CSV files that they send to Redox via SFTP. Our team of integration engineers would map all the appropriate fields to the Redox model and facilitate a connection to a trusted exchange network.
Payers can also query data from Redox using the same convenient APIs. As we continue to see FHIR® take a more prominent role in data exchange, Redox can provide FHIR® interfaces on top of legacy standards through R^FHIR.
Payers participating in trust networks have the potential to improve care and promote competition. CMS has a few levers to move over a handful of different types of plans, but an initial push may trigger network effects. Redox can help payer organizations connect to the rest of the healthcare ecosystem through our modern, developer friendly APIs and tools, as well as our support legacy integration options like SFTP, and emerging ones like FHIR®. We look forward to hearing about how this rule affects you and how we can help.
***
Want to learn more about how Redox can help Payers prepare for and meet these proposed requirements? Reach out today to speak with a member of our Solutions Team.