Defacto Health has been reviewing health insurers’ Provider Directory APIs in terms of availability, issues, and use cases for almost a year now. This post is a continuation, and we are focusing on the importance of health plan information within the APIs. While many exchanges between patients and providers about insurance stop short at “Do you take Blue Cross?” or “Do you have Aetna?” (such as our Dirty Dancing GIF above), simply accepting one of hundreds of an insurers’ plans tells you little about whether a provider is in-network for the health plan with which a you are enrolled.
Carrier and Plan-Product Information in Real World Patient Use Cases
Take a look at the example below from a popular online appointment scheduling web site. If you want to filter on available doctors by insurances they accept (i.e., what you have), you need to specify both the carrier as well as the plan, both of which have pretty lengthy vertical scrolls (i.e., there are so many carriers and plans to search).
Regulatory Requirement and Compliance for Publishing Plan-Level Information
The CMS Final Rule on Patient Access and Interoperability describes use cases that require plan-level information such as in-network provider search to “help consumers identify a provider when they enroll in an insurance plan” or plan shopping “allowing patients to understand and compare plan information in a way that can best serve their individual needs.” One of the big problems that the No Surprises Act seeks to solve is out-of-network surprise billing. Having information on whether providers accept a specific plan, in all contexts (web directory search or via API), is therefore critical to improving the patient experience with regard to healthcare provider and health plan selection.
Most carriers are exposing health plan-level information within their Provider Directory APIs via the Insurance Plan resource described in the Da Vinci Plan-Net Implementation Guide. However, there are 7 carriers within the top 50 that have not yet published Insurance Plan information, making it difficult for their APIs to support the aforementioned use cases. Half of these carriers acknowledged the issue and are talking with their vendors to make this information available. It is a good sign that the majority of carriers are complying, and there are efforts being made to resolve issues when identified.
Health Plan Identifiers
Beyond health plan names and practitioner associations, it is important to be able to explicitly identify health plans across the many that look and sound the same within a carrier’s portfolio (e.g., UnitedHealthcare Dual Complete ONE (HMO D-SNP) and UnitedHealthcare Dual Complete ONE Plus (HMO D-SNP) are two different plans) . CMS issues identifiers for Medicare Advantage plans (Plan Benefit Package or PBP IDs), Exchange plans (HIOS IDs), and states issue Medicaid MCO IDs to uniquely identify a plan offered by a carrier. Within carriers’ commercial lines of business, however, a patchwork of internal identifiers, clearinghouse identifiers, plan names, and group IDs are used to identify health plans.
The Health Insurance Portability and Accountability Act (HIPAA) of 1996, beyond its well-known Privacy Rule, also required that HHS adopt a national health plan identifier. In case you missed it, NPPES stands for the National Plan and Provider Enumeration System (NPPES) and NPPES and the NPI number find their origins in HIPAA as well. What happened? Long story short, a Final Rule came out in 2012, industry convened to comment, and in 2014, HHS announced it would exercise discretion in enforcing the HPID rule. Which brings us to where we are today, with very long health plan selection dropdowns and a hodge-podge of plan identifiers issued by different bodies.
Universal Health Plan Identification
What would be possible with a universal health plan ID? Consumers’ Checkbook explored a similar, but related concept of a universal network ID that could be placed on a member’s insurance card with an accompanying QR code. Establishing such an identifier could allow consumers to better compare health plans, search for healthcare providers, and understand out-of-pocket costs on third-party sites with the confidence that they are doing so in the context of their plan and network. The identifier could work like Universal Product Codes (UPC) function in retail. UPCs support the supply chain, help consumers and regulators understand the landscape of products, and help consumers with product comparisons and shopping. To avoid the ‘yet another identifier’ phenomenon, existing identifiers need to be mapped to the universal identifier to help industry to migrate to an ideal future state. If such an ID were embedded in payer APIs and transparency files, the CMS-mandated APIs could fulfill their mandated purpose of making plan data available in ‘different contexts’.
Practical Next Steps: Publish Plan-Level Information and Use IDs that Currently Exist
No such universal ID is currently required, so what’s possible now?. Carriers should not only publish Health Plan names in their Provider Directory APIs, but also PBP IDs, HIOS IDs, and Medicaid MCO IDs to ensure that their members have the best information about their networks at their fingertips. Wider usage of existing identifiers lays the groundwork for a universal identifier across all carriers and lines of business that will enable a range of new patient access use cases.