Skip to end of metadata
Go to start of metadata

As Da Vinci works to define our Implementation Guide to advance interoperability with FHIR APIs for Cost Transparency, we have received a number of questions that the core team has done our best to answer below. 

IDQuestionResponse
001How does this work align with the Consolidated Appropriations Act (CAA, HR 133 Bill)? 

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.

002

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.

003If this guide is implemented, will it meet the requirements for the Transparency in Coverage Rule?

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.  

004Is this a patient-facing or provider facing API? We're hoping it will be usable for both patients and providers and will leverage what is already in place for Patient Access API and the coming Provider Access API. TBD at this time. 
005This seems very focused on fee-for-service, but how would it apply for value based care arrangements?Value-based contracts are all different but patient cost responsibility still ultimately depends on claims.  Factors for patient responsibility vary by the same factors (e.g.s facility, service location, provider network) which can be leveraged to make care more affordable for the patient.
006Where does the CARIN Blue Button IG for providing EOBs fit in? Can we use that to meet the CAA requirements?

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.

007Is this inclusive of Medical, Dental, Vision, and Pharmacy?

Medical Devices and Services is the focus.

008Will Patient Cost Transparency IG address Prior Authorization requirements and include that closely related process?

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. 
009What else is beyond the scope of Phase 1, but could possibly be considered for Version 2 of the IG? 

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

010Will the IG address dual eligibles or patients with multiple coverages? 

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.

011Is the GFE requirements the same as claim requirements?

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.  

012Why does the PCT IG support options for multiple providers/facilities to submit separate GFEs as well as a combined GFE to a payer?

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.

  • No labels