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.
|001||How 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.
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.
|003||If 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.
|004||Is 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.|
|005||This 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.|
|006||Where 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.
A few examples of the differences between the two:
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.
|007||Is this inclusive of Medical, Dental, Vision, and Pharmacy?|
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.
|008||Will 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 discussion from community calls, some additional information:
|009||What 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
|010||Will 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.
|011||Is 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.
|012||Why 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.