Patient Cost Transparency FAQs

This use case is looking at the No Surprise Billing portion of the CAA and specifically focused on defining Standard FHIR APIs for the Good Faith Estimate and Advanced EOB as an initial Implementation Guide.

There is much discussion in the industry to leverage the X12 837D (predetermination) for the advanced EOB requirement, how does that fit with Da Vinci work? 

Much of the work we do in DV, we're looking to find gaps and places where FHIR can fill existing pain points and augment or improve existing standards.  I don't think there is a singular answer here, but imagine there is a need for existing X12 standards to be leveraged as the predominant tool for claims and price for payers today.

Da Vinci is working closely with X12 to ensure that stakeholders that need to support X12 back end systems will be supported with the data needed, but X12 transactions will not be required as part of implementing the FHIR IG. 

The FHIR bundle goes to the payer (or intermediary), who can decide how to process it (translate to X12, import into its system, etc.).  What the payer does inside its system is outside scope.

Dates based on original effective dates, note that enforcement may be different based on additional FAQs, always check CMS and the Federal Register for official dates. 

1/1/2022 - this is for Payers to provide a machine readable file and this Guide does not address that.

1/1/2023 and 1/1/2024 -  Cost Estimates for shoppable services. This is on the list for phase 2, but there may be interest from Da Vinci members to pursue this sooner.  

The CARIN BB IG was reviewed to inform the Advanced EOB definition. We recognize the value of leveraging this IG as it was implemented for many as part of Patient Access API so lowers the barrier to implementation.  We received feedback from the community and will explore this further with the community during ballot reconciliation after Jan 2022 Ballot given more detailed feedback. 

As a reminder, these IGs are both built on use cases and the use cases are very different, two different purposes from two different perspectives.

• CARIN BB, like the CMS Medicare Blue Button, was built for consumer-directed exchange to easily share paid claim information that can be stored across time, health plans and providers and shared with doctors, pharmacies, caregivers meeting the CMS Interoperability and Patient Access rules.
• PCT has been developed as a statement from the payer describing what costs it “may” cover for medical care or products and a patient’s responsibility or identify a provider as out-of-network and provide a way to locate an in-network provider. 

A few examples of the differences between the two:

• PCT is not built to gather a history of past claims to share with other providers. It is being developed to share a point-in-time perspective on how much a payer will pay and a subscriber/patient’s costs. Based on the information contained within the AEOB, a patient may choose different providers, services, or products.
• PCT is based on a Good Faith Estimate created PRIOR to any service or product being given or purchased for the patient. CARIN BB EOB mapping is based on claims that passed through all possible validation and adjudication edits, information was gathered after all services/devices were purchased for the patient, and all information was available.
• PCT AEOB contains the GFE as it was submitted, CARIN BB points to the claim identifier.
• PCT does not require the “Common Payer Consumer Data Set (CPCDS)

At this time, we see no current need for more EOB Resource profiles based on the existing requirements where extensions, code systems and value sets are identical, they should be consistent where possible. This type of ballot comment would be welcomed.

Medical Devices and Services is the focus.

It's worth noting that implementers have found value in reviewing the PCT IG for other related uses / "off-label" needs.  Please recognize that there is the NCPDP standard for pharmaceuticals and the PCT Profiles are constrained to code systems and value sets for medical items and services only. 

The PCT IG will not specifically address Prior Authorization. PCT is a separate and distinct process from Prior Authorization. 
Per the No Surprises Act (Section 111(a)(f)(1)(F)), the Advanced EOB must include a disclaimer indicating when coverage for items or services are subject to a "medical management technique" such as Prior Authorization, concurrent review, step-therapy, etc. No additional information specific to Prior Authorization is required or planned for inclusion.

Per discussion from community calls, some additional information:

• Provider could chose to send a PCT and a CRD/DTR/PAS request at the same time if needed, but they are independent.
• The Payer rules, medical documentation requirements, and review needed for a Prior Auth. are unique and different than what is needed for PCT.
• Also, not all services require Prior Auth. 

We could expand in a number of ways. This is a growing backlog of opportunities for standardization: PCT Phase 2 Planning

We plan to look deeper into this for phase 2. It sounds like tools today are challenged with this and may process one coverage,  then the other, with manual intervention to show the combined/cascaded estimate.

By design, requirements are based on existing claim’s structure and framework, but less information will be known so less will be required for advanced estimates.  

Ideally, a single provider (referred to as the "GFE Submitter" in some PCT materials; referred to as the "convening provider/facility" in Requirements Related to Surprise Billing; Part II (86 FR 55980)) collects information from all "co-providers/facilities" (or all other providers/facilities that will be engaged in the item/service) and submits a single collection of GFE information to a payer to facilitate the creation of an AEOB.

There is not yet specific regulation related to this IG. However, because CMS is not immediately requiring one such GFE collection for a related but different use case (a GFE from provider/facility to patient when a patient schedules a services with an out-of-network provider at an in-network facility as noted in Requirements Related to Surprise Billing; Part II), it is important this IG provides the tools to support a similar scenario for the use case indicated in Section 111 of the No Surprises Act covered by this IG (a GFE from a provider/facility to a payer leading to an AEOB to a patient). Having the ability for the IG to support one collection of information and/or separate GFEs that share a linking identifier ensures that the IG can support the use case in both possible situations.