Research shows that the more complete a patient’s record is, and the more data there are at the point of care, the better patient outcomes can be.55 More data lead to better-coordinated care and more informed decision-making. Data sharing among payers is one powerful way to facilitate this critically valuable flow of information through the health care ecosystem. As a result, in the CMS Interoperability and Patient Access final rule, we finalized a requirement for certain impacted payers to exchange, at a minimum, clinical information as defined in the USCDI version 1 (85 FR 25568 through 25569). We did not specify an API standard for data sharing in that final rule, however, understanding at the time that there may be a variety of transmission solutions that payers could employ to meet this requirement. We did encourage impacted payers to consider the use of a FHIR-based API in line with the larger goal of leveraging FHIR-based APIs to support a number of interoperability use cases for improving patient, provider, and payer access to health care data in order to reduce burden, increase efficiency, and ultimately facilitate better patient care. In addition, we also signaled our intent to consider a future requirement to use FHIR-based APIs for payer-to-payer data sharing, envisioning the increasing implementation of FHIR-based APIs within the industry.
55 55Office of the National Coordinator. (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from
55 See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
55 HL7 International. (n.d.). Da Vinci Payer Coverage Decision Exchange (PCDE) FHIR IG. Retrieved from
55 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
In the time since we proposed the initial payer-to-payer data exchange requirements in the CMS Interoperability and Patient Access rule, we have begun to leverage new tools, most notably the HL7 FHIR Bulk Data Access (Flat FHIR) specification, as discussed in more detail in section II.B. of this proposed rule. We believe the HL7 FHIR Bulk Data Access (Flat FHIR) specification, in particular, provides an opportunity to continue to build upon the requirement for payer-to-payer data sharing in a way that adds valuable efficiencies for payers, further simplifying administration and reducing burden. We believe that the suite of tools that the CMS Interoperability and Patient Access final rule (85 FR 25510) requires and that this proposed rule would require for payers would ultimately lead to payers having more complete information available to share with patients and providers. As a result, we are now proposing an enhanced set of payer-to-payer data-sharing requirements that would build on the policy finalized in the CMS Interoperability and Patient Access final rule (85 FR 25568 through 25569) by leveraging FHIR- based APIs to further support greater interoperability and information flow.
Payer-to-Payer Data Exchange on FHIR
There are three primary proposals we are making regarding the payer-to-payer data exchange in this proposed rule. First, we propose to extend the payer-to-payer data exchange to state Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b). We previously finalized in the CMS Interoperability and Patient Access final rule (85 FR 25568 through 25569) that MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs were required, at the patient’s request, to share a specified subset of clinical data with another payer of the patient’s choice.
Second, we propose to enhance this payer-to-payer data exchange triggered by a patient’s request beyond what was previously finalized (for MA organizations, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs) in the CMS Interoperability and Patient Access final rule. In the final rule, we required impacted payers to exchange, at the patient’s request, clinical data as defined in the USCDI, but we did not finalize in what electronic form or how these data would be transmitted. In this rule, we are proposing to require a FHIR- based API for this data exchange. In addition, we propose that this standards-based API must be conformant with specific IGs. We also propose that this Payer-to-Payer API, at the patient’s request, must make not just clinical data as defined in the USCDI available, but also claims and encounter data (not including cost information), and information about pending and active prior authorization decisions. We propose these enhancements to the required payer-to-payer exchanges for Medicaid managed care plans (other than NEMT PAHPs) at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.221(f)(2). We are also proposing to include these enhancements as part of extending the payer-to-payer data exchange requirements to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b). We believe these proposed enhancements would facilitate more efficient data sharing between payers. In addition, the proposed additions to the data the API must be able to share would be consistent with the proposals discussed in sections
II.A. and II.B. of this proposed rule, which would require these payers to share the same types of data with patients and providers via FHIR-based APIs. This would add efficiencies for payers and maximize the value of the work being done to implement APIs, overall reducing burden for all impacted payers.
Third, we propose a second payer-to-payer data exchange policy that would use this Payer-to-Payer API to facilitate data sharing between payers at enrollment. When a patient enrolls with a new payer or when a patient identifies concurrent coverage, we propose that the
patient would have an opportunity to opt-in to this data sharing. Unlike the payer-to-payer exchange finalized previously, where the patient must make a request to initiate the data sharing, under this proposal the patient would be presented with data sharing as an option at enrollment. As more than one patient could be moving from one payer to another at enrollment, this new Payer-to-Payer API proposal to share data at enrollment would include a requirement for impacted payers to facilitate data sharing both for individual patients and for more than one patient using the HL7 FHIR Bulk Data Access (Flat FHIR) specification, discussed previously in section II.B. of this proposed rule. We are proposing to codify the requirement for this Payer-to- Payer API, including use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification, at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP issuers on the FFEs.
Payer-to-Payer Data Sharing in Medicaid and CHIP
In the CMS Interoperability and Patient Access final rule, we did not include Medicaid and CHIP FFS programs in the payer-to-payer data exchange policies. In that rule, we also did not specify how these data must be exchanged. As discussed in sections II.B.6.d. and II.C.7., and again later in this section of this proposed rule, Medicaid and CHIP FFS programs can face unique circumstances that might make it more challenging for them to meet new requirements within the same timeframe as other payers. As a result, in our first phase of interoperability policy, we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs. Now that we are looking to transition the payer-to-payer data exchange to an API, and understanding the fact that this new API will be leveraging the same data and technical standards, and nearly all the same
implementation guides as the Patient Access API, we believe that asking these programs to now implement this payer-to-payer data exchange via a Payer-to-Payer API would not be as burdensome as it would have been had we required these FFS programs to implement a payer-to- payer data exchange that does not require an API in the CMS Interoperability and Patient Access final rule effective January 1, 2022. By the time these programs would need to start preparing to implement this new Payer-to-Payer API, they are expected to have implemented the Patient Access API, and they would thus be able to leverage the work done for that to make implementing this new API more manageable. As a result, we now propose to extend this requirement to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b), respectively.
In the case of Medicaid and CHIP FFS programs, the state agency is the “payer” that can share patient data with other payers. As we discuss in more detail in section II.D.4. of this proposed rule, use of the Payer-to-Payer API could improve operational efficiencies for the state, thereby reducing burden for the state, and leading to better coordinated patient care and improved health outcomes. We thus expect the proposed Payer-to-Payer API requirement to lead to more effective administration of the state plan, and to better enable Medicaid and CHIP programs to ensure care and services are provided in a manner that is consistent with their beneficiaries’ best interests. Ensuring that information can follow Medicaid and CHIP beneficiaries as they enter the programs could potentially lead to better care coordination for these patients, and better continuity of care. It could also reduce burden for patients and providers. Payers would have additional information to share via the Patient Access API and the Provider Access API. As a result, patients would have more readily available information to support informed decision making, and providers would have more information about the care
their patients are receiving. This could potentially lead to fewer duplicate tests or less time taken collecting and recollecting information about the patient during a visit. Any opportunity a state takes to evaluate the data from a patient’s previous payer could allow the state to avoid wasteful or unnecessary action that the previous payer may have already completed, such as an involved process or series of tests to support receipt of certain services. In this way, extending this Payer- to-Payer API to state Medicaid and CHIP programs could benefit them by helping them to operate more efficiently.
Also, as discussed in the CMS Interoperability and Patient Access final rule (85 FR 255664 through 25569), we believe there are numerous benefits for payers to be able to maintain a cumulative record of their current patients’ health information. If payers do so, they can make information available to patients and their providers and can help ensure that patient information follows patients as they move from provider to provider and payer to payer. We believe it is important to propose that Medicaid and CHIP FFS agencies facilitate this data access and sharing for their beneficiaries, so that the benefits of both the data sharing required in the final rule and the data sharing proposed in sections II.A. through the Patient Access API and II.B. through the Provider Access API of this proposed rule would extend to Medicaid and CHIP FFS beneficiaries in the same way across other impacted payers. In this way, as a patient moves in and out of Medicaid or CHIP FFS, they will not lose access to their health information – that information would continue to follow them to new payers and providers by virtue of payers being able to send and receive their data and make it available to the patient and providers through these APIs.
States operating Medicaid and CHIP programs may be able to access federal matching funds to support their implementation of this Payer-to-Payer API, because this API is expected to
lead to more efficient administration of the Medicaid and CHIP state plans and improved care coordination and health outcomes for Medicaid beneficiaries consistent with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more detail in section II.D.8.a. of this proposed rule.
Consistent with the discussion regarding funding and the Provider Access API proposal discussed in section II.B. of this proposed rule and the DRLS and API APIs in section II.C., we do not consider state expenditures for implementing this Payer-to-Payer API proposal to be attributable to any covered item or service within the definition of “medical assistance.” Thus, we would not match these expenditures at the state’s regular federal medical assistance percentage. However, federal Medicaid matching funds under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs, because use of the Payer-to-Payer API would help ensure that payers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately, and in the best interest of the patient.
States’ expenditures to implement these proposed requirements might also be eligible for enhanced 90 percent federal Medicaid matching funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent federal matching funds under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.
States request Medicaid matching funds under section 1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning Document (APD) process described in 45 CFR part 95, subpart F.
States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to ensure that any system for which they are receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and incorporates the ONC Health Information Technology standards adopted in accordance with 45 CFR part 170, Subpart B. The Payer-to- Payer API, and all APIs proposed in this rule, complement this requirement because these APIs further interoperability through the use of HL7 FHIR standards proposed for adoption by ONC for HHS use at 45 CFR 170.215.56 And, states are reminded that 42 CFR 433.112(b)(10) explicitly supports exposed APIs as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act.
Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of Medicaid technologies and systems as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. As noted in section II.B. of this proposed rule, CMS would interpret that sharing and re-use requirement also to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to connect to the APIs proposed in this rule can do so would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Payer-to-Payer API.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, limiting administrative costs to no more than 10 percent of CHIP payments to the state, would apply in developing the APIs proposed in this rule.
56 See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
Again, we note that the temporary federal medical assistance percentage (FMAP) increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.
In the CMS Interoperability and Patient Access final rule, the payer-to-payer data exchange is required for Medicaid managed care plans with an applicability date of January 1, 2022 and codified at 42 CFR 438.62(b)(1)(vi) and (vii). Because this rule proposes to require implementation and use of a Payer-to-Payer API for Medicaid FFS programs, and to be consistent with the other provisions of this rule, we propose to codify the requirement for states in connection with Medicaid FFS programs at 42 CFR 431.61(b), amend the requirement specific to Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii) to sunset the requirements at 438.61(b)(1)(vi) when the new requirements take effect with the rating period beginning on or after January 1, 2023, and revise 42 CFR 438.242(b)(7) to add a requirement for Medicaid managed care plans to comply with the requirement imposed on Medicaid FFS program using a cross reference to 42 CFR 431.61. Codifying the requirement for Medicaid managed care plans this way would ensure that the same standards for payer-to-payer data exchange apply across the Medicaid program, regardless of it is through the FFS or managed care delivery system.
Similarly, we are proposing revisions to the CHIP managed care regulations to require CHIP managed care entities to comply with the requirement for an API for payer-to-payer data exchanges that applies to CHIP FFS programs; the CHIP managed care entities would also have to comply by the rating period beginning on or after January 1, 2023. We propose to codify this policy for CHIP managed care entities at 42 CFR 457.1233(d)(4). Because CHIP managed care entities are required by current 42 CFR 457.1216 to comply with 42 CFR 438.62, our proposed
revisions to 42 CFR 438.62 (for Medicaid managed care plans) would also apply to CHIP managed care entities.
We request comment on these proposals.
Enhancing the Payer-to-Payer Data Exchange – Payer-to-Payer API
In the Interoperability and Patient Access final rule, we established a payer-to-payer data exchange that required certain impacted payers to share clinical data as defined in the USCDI version 1 data set with the approval and at the direction of a current or former enrollee. We did not require that this data exchange take place using an API, though we encouraged payers to look at an API solution. We are now proposing to enhance this payer-to-payer data exchange in two ways. First, we are proposing to require that this payer-to-payer data exchange take place via an API. Second, we propose to require impacted payers to make available, at a minimum, not only the USCDI version 1 data, but also claims and encounter data (not including cost information) that the payer maintains with a date of service on or after January 1, 2016, conformant with the same IGs proposed for these data types in sections II.A. and II.B. of this rule, as well as information about pending and active prior authorization decisions, beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023) via this standards-based Payer-to-Payer API. This Payer- to-Payer API is proposed to use the technical standards and the same base content and vocabulary standards used for the Patient Access API. These proposed requirements would be codified for Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b), Medicaid managed care plans other than NEMT PAHPs at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.221(f)(2). Ultimately, we believe sharing this information across payers can improve
operational efficiencies, reduce unnecessary care, reduce care costs, and improve patient outcomes.
Consistent with what was finalized in the CMS Interoperability and Patient Access final rule, impacted payers who receive these data would be required to incorporate the data into the payer’s records about the enrollee, making these data part of the data maintained by the receiving payer. We note that unless expressly stated as part of a specific proposal, CMS is not proposing to require the receiving payer to specifically review or act on the data received from other payers. As explained in the CMS Interoperability and Patient Access final rule for the Payer-to- Payer Data Exchange, payers could choose to indicate the part of a data exchange that was received from a previous payer so a future receiving payer, provider, or even patient, would know where to direct questions (such as how to address contradictory or inaccurate information); and we propose that the same principle would apply to this enhancement. As noted in the CMS Interoperability and Patient Access final rule (85 FR 25566), impacted payers would be under no obligation under this proposal to review, utilize, update, validate, or correct data received from another payer. However, if a payer should choose to review or otherwise use received data, the payer would not be prohibited from doing so under any of the policies in this proposed rule.
We believe a patient’s current payer is in an optimal position to maintain a cumulative record for the patient and facilitate that record following the patient through their health care journey. Whereas patients may see many providers, patients’ payers have a more holistic view of a patient’s care across providers over time. It is important to note that, under these proposals, impacted payers would not be required to exchange any cost information, such as enrollee cost- sharing and provider remittances. While there could be some value to patients accessing this cost information via the Patient Access API, sharing this cost information between payers would have
only limited beneficial impact on care coordination. We believe that sharing claims and encounter information without the cost details, however, could complement the clinical data as defined in the USCDI by providing more information to support care coordination and efficient operation, including, for example, information about the patient’s care history. As we discussed in the CMS Interoperability and Patient Access final rule, and in section II.B. of this proposed rule, claims and encounter data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the health care system (85 FR 25523).
In addition, we believe it would be highly valuable for payers to share pending and active prior authorization decisions generally, and particularly when a patient enrolls with a new payer. Currently, when a patient enrolls with a new payer, little to no information is sent from the previous payer to the new payer about the prior authorization decisions the previous payer made or was in the process of making relevant to the patient’s ongoing care. While some previous payers will make this information available to the new payer upon request, most new payers do not request such information. Instead, most payers with a newly enrolling patient require the treating provider to request a new prior authorization, even for items or services for which a patient has a valid and current prior authorization approval. The burden of repeating the prior authorization process with the new payer falls on the provider and patient, which often impedes continuity of care, impacting patient outcomes and complicating care coordination. In addition, it adds burden to payers who must expend time and effort to review a potentially unnecessary and duplicative prior authorization request. While we do not propose to require the new payer that would receive the prior authorization information and documentation under this proposal to specifically consult this information, at the very least this information would now form part of
the patient’s cumulative record and thus be available to be shared by the payer with the patient and the patient’s care team. Should a payer choose to consult this information, it could reduce payer, provider, and patient burden, and possibly cost, over time. If a new payer consulted this information, it could mean fewer prior authorization requests the provider needs to send and the payer needs to process. Patients would not have to wait for a new prior authorization for an item or service they have already demonstrated they need and would benefit from. This is especially true of patients with chronic conditions who are changing payers. As a result, sharing this information between payers could have a significant impact on payers, providers, and patients. Payers and providers could see reduced burden, and patients could experience better, continuous care.
We discuss prior authorization and our proposals regarding prior authorization processes in more depth in section II.C. of this proposed rule. As part of this Payer-to-Payer API proposal, we propose at 42 CFR 431.61(b) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(b) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.221(f)(2) for QHP issuers on the FFEs to require all impacted payers make available pending and active prior authorization decisions (and related clinical documentation and forms) via the Payer-to-Payer API using the HL7 FHIR Da Vinci Payer Coverage Decision Exchange (PCDE)57 IG proposed at 45 CFR 170.215(c)(4) and integrate this information into the patient’s record for review and consideration. For purposes of this proposal, “active prior authorization decisions” means prior authorizations that are currently open, and being used to facilitate current care, and are not expired or no longer valid. By “pending prior authorization decision,” we mean prior authorizations that are under review, either pending
57 HL7 International. (n.d.). Da Vinci Payer Coverage Decision Exchange (PCDE) FHIR IG. Retrieved from http://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
submission of documentation from the provider, or being evaluated by the payer’s medical review staff, or for another reason have not yet had a determination made. As discussed in section II.A.2. of this proposed rule, when we say “items and services,” for purposes of this rule, we are talking about items and services excluding prescription drugs and/or covered outpatient drugs. “Status” of the prior authorization means information about whether the prior authorization is approved, denied, or if more information is needed to complete the request. We are proposing that impacted payers, consistent with the proposals for the Patient Access API in section II.A. and the Provider Access API in section II.B. of this proposed rule, limit sharing to pending and active authorizations to reduce the volume of outdated or irrelevant information shared between payers. We propose that this documentation would include the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date.
We request comment on this proposal.
In addition to these proposals, we also seek comment for possible future rulemaking on the extent to which we should consider explicitly requiring payers to demonstrate that they have reviewed and considered these previous prior authorization decisions and associated clinical documentation from a patient’s previous payer before requiring patients to undergo a new prior authorization process. Such a requirement could minimize the possibility of duplicate testing for the purposes of reaffirming coverage or renewing a prior authorization for a covered benefit that is part of the patient’s current care plan. As discussed in section II.C., providers experience burden when navigating through each payer’s set of prior authorization policies or rules. It is a burden to payers to administer a prior authorization process. In addition, requiring a new prior authorization can also delay patient care. We also seek comment for possible future rulemaking
on whether to, in the alternative, require payers to honor a previous payer’s active prior authorization decisions at the time the enrollee moves from one payer to a new payer for some length of time, such as 30, 45, or 60 days, or if there are situations where this may not be possible or appropriate and why.
This Patient Access API requirement was finalized at 42 CFR 422.119(a) through (e) for MA organizations, 42 CFR 431.60(a) through (e) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care, 42 CFR 457.730(a) through (e) for CHIP FFS, 42 CFR 457.1233(d) for CHIP managed care, and at 45 CFR 156.221(a) through (e) for QHP issuers on the FFEs (85 FR 25558 through 25559). Further, we are proposing the same content and compliance with the same technical standards, the same documentation requirements, and the same discontinuation and denial of access requirements for the Patient Access API (discussed in section II.A. of this proposed rule) and the Provider Access API (discussed in section II.B. of this proposed rule) as we are proposing for this proposed Payer-to-Payer API. This degree of overlap and use of the same requirements should ease the burden for payers in developing and implementing these various APIs.
In addition, all of these APIs would need to be conformant with the same IGs proposed for claims and encounter data as well as the USCDI version 1 data as discussed in section II.A. for the Patient Access API and section II.B. of this proposed rule for the Provider Access API. The Patient Access API, in particular, provides the foundation necessary to share claims, encounter, and clinical data. Because the same data elements would be exchanged through all three APIs, payers would have already formatted these data elements and prepared their systems to share these standardized data via a FHIR-based API, doing much of the work needed to implement this Payer-to-Payer API. As a result, we believe payers would have devoted the
development resources needed to stand up a FHIR-based API infrastructure that could be adapted for expanded interoperability use cases after 2021, when they have implemented the Patient Access API.
However, we are proposing that the Payer-to-Payer API and the Patient Access and Provider Access APIs be conformant with different IGs for sharing prior authorization decisions. In sections II.A. and II.B. of this proposed rule, we propose that the Patient Access and Provider Access APIs would need to be conformant with the PDex IG when sharing prior authorization decisions with patients and providers, respectively. We propose to require the Payer-to-Payer API be conformant with the PCDE IG instead, when sharing this information, as this IG addresses data sharing between payers more specifically. PDex would be better suited for an exchange from a payer to patients and providers. Given the shared FHIR resources across the two IGs, we do not believe requiring the use of both IGs – one for each appropriate recipient of the data – adds significant burden to payers.
Payer-to-Payer API—Sharing Data at Enrollment
As finalized in the CMS Interoperability and Patient Access final rule, the payer-to-payer data exchange is initiated at the direction of the patient. We discussed proposed enhancements to this patient-directed data sharing in the previous section where we noted this data exchange would now require the use of an API and include additional data to be shared. In addition to this case-by-case, patient-directed data sharing, however, we also propose a second, new Payer-to- Payer API data sharing opportunity that would be offered to all patients receiving coverage from a payer impacted by this proposed rule as an option at the time of enrollment with a new payer, if both the current payer and new payer would be subject to the requirements in this proposal. We propose to codify this new Payer-to-Payer API requirement at 42 CFR 431.61(c) for Medicaid
FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP issuers on the FFEs. We are proposing that this exchange be offered to patients receiving coverage from payers impacted by this proposed rule as an option when they enroll with a new payer. The new payer, if an impacted payer under this proposed rule, could then request the data from the previous payer for patients who opt-in to this data sharing via the Payer-to-Payer API.
We are proposing the following if a patient enrolls during a specified annual open enrollment period, or, for a payer that does not have such an enrollment period, during the first calendar quarter of each year. If such a patient opts-in to having their new payer obtain the applicable data from their previous payer at this specified time, we are proposing to require that impacted new payers request such data from the previous payers via the Payer-to-Payer API using the HL7 FHIR Bulk Data Access (Flat FHIR) specification within one week of the end of the enrollment period or the first calendar quarter of each year. The previous payer, if an impacted payer, would be required to respond to this request within one business day of receiving the request.
We do recognize that not every impacted payer has a dedicated annual open enrollment period. For those payers, we are proposing that the opt-in Bulk data sharing occur at the end of the first calendar quarter of each year. We seek comment on whether this is the best time to require the data sharing for such payers. Based on our experience with Bulk data sharing discussed in section II.B.4. of this proposed rule, and based on discussions with payers and technology developers, we believe the efficiencies afforded by having at least one time per year where payers could facilitate this data sharing and employ the Bulk specification to leverage the opportunity to make data available for as many patients as possible at one time could be
potentially significant because such an asynchronous data sharing option could limit drain on system resources and promote a dedicated and efficient opportunity each year to ensure patients have their health information follow them as they move from payer to payer, permitting better care coordination and potentially better health outcomes. Therefore, we seek comment on how best to operationalize this across impacted payers. We also see comment on whether the timeframes for the new payer requesting these data – within one week of this enrollment or other defined period ending – and the old payer sending these data – within one business day of receiving the request – are the optimal timeframes and what other timeframes payers may want us to consider. Would payers be able to accommodate a shorter request timeframe – such as one to three business days after the end of the defined enrollment period? Or, do payers need more than one business day to respond to a request? If so, would payers want to have a one week turnaround for data requests? We do think it is important for patient data to move to the new payer as soon as possible to facilitate care coordination, and to ensure the patient’s data is available to their providers and to them, hence our current proposal. We also seek comment on whether we should consider any other factors regarding the process and timeline for this Payer- to-Payer API data sharing at enrollment.
Efficient data sharing between payers would ensure that information that could support payer operations and benefit patient care is available to a new payer at the very start of the patient’s care covered by a new payer. This could facilitate care coordination and continuity of care. This proposal would require the new payer to adopt a process to obtain the name of an enrollee’s previous payer, or concurrent payer if the enrollee has coverage through more than one payer, as part of the enrollment process. Subsequently, the new payer would be required to receive the enrollee’s clinical data as defined in the USCDI version 1 and adjudicated claims and
encounter data, as well as pending and active prior authorization decisions, from the previous or concurrent payer, if that payer maintains such data for the relevant enrollee.
Under this proposal, impacted payers would be required to maintain a process for capturing data about each patient’s previous payer and concurrent payer (if there is one) at enrollment to facilitate this payer-to-payer data sharing. While we wish to leave it to each impacted payer how they choose to implement capturing this information, we seek comment on potential solutions to support payers in obtaining this previous and concurrent payer information in an effort to provide all impacted payers with options to consider. As to concurrent payers, we anticipate that many payers already have a process in place to request and update information of this sort for coordination of benefits or to implement Medicare Secondary Payer requirements (if applicable), and we wish to allow payers to maintain their current processes if that is beneficial and feasible when incorporating the use of the Payer-to-Payer API into this process.
We are proposing at 42 CFR 431.61(c)(5) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(5) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(5) for QHP issuers on the FFEs, that payers put a process in place to allow enrollees to opt-in to this payer-to-payer data sharing at enrollment, similar to the opt-in proposal under the Provider Access APIs detailed in section II.B. of this proposed rule. If enrollees do not actively opt-in, impacted payers would not be required to share their data through the Payer-to-Payer API as described under this proposal. This means that only at the defined enrollment period, or at the end of the first calendar quarter for payers that do not have a defined enrollment period, are impacted payers required under this proposal to have a process in place to capture a patient’s preference to opt-in to this data sharing under this proposal. If a patient would like their data shared with another payer at another time throughout a
given year, the patient could request that data exchange under the enhanced payer-to-payer data exchange proposal discussed in section II.D.4. of this proposed rule.
We seek comment on these proposals.
Some individuals may have concurrent coverage with two or more of the payers impacted by this proposal. We also propose at 42 CFR 431.61(c)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(4) for QHP issuers on the FFEs that when an enrollee has concurrent coverage with two or more impacted payers, the impacted payers must make the patient’s data available to the concurrent payer quarterly, in addition to when the enrollee obtains new coverage from a payer subject to these proposed requirements. We propose to require payers to provide enrollees the opportunity to opt-in to initiate this quarterly data sharing. This data exchange among concurrent payers is expected to support better care coordination and more efficient operations. We also considered whether to propose more frequent exchange (weekly or monthly), and less frequent exchange (semi- annually or annually); however, we believe a quarterly data exchange would strike the right balance in providing accurate, timely data with minimal payer burden.
We request comment on this proposal, including the appropriate frequency for this payer- to-payer exchange for enrollees with concurrent coverage. We also seek comment on whether payers prefer the flexibility to define their own process for facilitating how patients opt-in to this quarterly data sharing and if there are additional considerations that we should take into account to facilitate data sharing using the Payer-to-Payer API between concurrent payers.
We appreciate that a patient may be moving to or from a payer, or have concurrent coverage with a payer not subject to the requirements in this proposed rule, such as when a
patient moves from a QHP on the FFE to an employer-based plan, as an employer-based plan is not impacted by this rulemaking. We encourage all payers to consider the value of implementing a Payer-to-Payer API so that all patients, providers, and payers in the U.S. health care system may ultimately experience the benefits of such data sharing. For instance, we are exploring best next steps for the Medicare FFS program to participate in a Payer-to-Payer API data exchange with all interested payers. That said, if an impacted payer learns that a previous or concurrent payer is not subject to this proposal, we encourage the new payer to evaluate if the other payer can accommodate an API data exchange and seek such exchange in accordance with applicable law. However, an impacted payer would not be required to try to send data to or receive data from a payer that is not required to exchange data through the Payer-to-Payer API under this proposal.
As discussed in section II.B. of this proposed rule, and as further illustrated in the discussion in this section of this proposed rule, it may be valuable for a payer to share data with another payer for more than one patient at a time. It is likely that if payers are sharing data at enrollment, impacted payers would have many patients’ data to share at one time. In such a situation, it can be burdensome to make an API call for each patient. This could require significant technological resources and time. To introduce additional efficiencies, we are proposing that this required Payer-to-Payer API must be able to share the specified data conformant with the HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR 170.215(a)(4) to facilitate sharing information relevant to one or more patients at one time. We are proposing to codify this specific requirement at 42 CFR 431.61(c)(1) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(1) for CHIP FFS, at 42
CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(1) for QHP issuers on the FFEs.
We request comment on this proposal.
As with the proposal for the Provider Access API, discussed in section II.B. of this proposed rule, we invite comment on the tradeoffs and benefits of having the Payer-to-Payer API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification. We believe both approaches would offer benefits to payers depending on the specifics of the situation in which they would need to share patient data. As we look to balance providing this flexibility with the burden of implementing and maintaining APIs, we invite public comment on the benefits of having the Payer-to-Payer API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification, which can be leveraged to request the data for a single patient or multiple patients.
Extensions and Exemptions for Medicaid and CHIP
If our proposals regarding the Payer-to-Payer API are finalized, we would encourage state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API as soon as possible understanding the many benefits of the API as discussed previously in this section.
However, we also recognize that state Medicaid or CHIP FFS agencies could face certain unique circumstances that would not apply to other impacted payers, as discussed in more detail later in this section. As a result, a few states might need to seek an extension of the compliance deadline or an exemption from these requirements. To address this concern, we are proposing a process through which states may seek an extension of and, in specific circumstances, an exemption from, the Payer-to-Payer API requirements if they are unable to implement these API requirements, consistent with the extension and exemption proposals for the Provider Access
API in section II.B., and the DRLS and PAS APIs in section II.C. of this proposed rule. Providing these flexibilities might allow these states to continue building technical capacity in support of overall interoperability goals consistent with their needs. Therefore, we propose the following.
Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1), respectively, we propose to provide states – for Medicaid FFS and CHIP FFS - the opportunity to request a one-time extension of up to one (1) year for the implementation of the Payer-to-Payer API specified at 42 CFR 431.61(b) and (c) and 42 CFR 457.731(b) and (c). Unique circumstances that might present a challenge to specific states to meet the proposed compliance date could include resource challenges, such as funding. Depending on when the final rule is published in relation to a state’s budget process and timeline, some states may not be able to secure the needed funds in time to both develop and execute implementation of the API requirements by the proposed compliance date. A one-year extension could help mitigate this issue. And, some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an open, competed procurement process, together with the time needed to onboard the contractor and develop the API, could require additional time as well. Finally, a state might need to hire new staff with the necessary skillset to implement this policy. Again, the time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult, because, generally speaking, public employee hiring processes include stricter
guidelines and longer time-to-hire periods than other sectors.58 In all such situations, a state might need more time than other impacted payers to implement the requirements.
If a state believes it can demonstrate the need for an extension, its request must be submitted and approved as a part of its annual Advance Planning Document (APD) for MMIS operations costs and must include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to states operating Medicaid or CHIP FFS programs, (2) a report on completed and ongoing implementation activities to evidence a good faith effort toward compliance, and (3) a comprehensive plan to meet implementation requirements no later than one year after the initial compliance date.
An extension would be granted if CMS determines based on the information provided in the APD that the request adequately establishes a need to delay implementation, a good faith effort to implement the proposed requirements as soon as possible, and a clear plan to implement no later than one year after the proposed compliance date. We would expect states to explain why the request for an extension results from circumstances that are unique to states operating Medicaid or CHIP FFS programs. We also solicit comment on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement sufficiently difficult for states and thus justify an extension. In particular, we seek comment on whether we should require or use additional information on which to base the determination or whether we should establish different standards in the regulation text for evaluating and granting the request.
58 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457. 731(e)(2), respectively, we propose two circumstances that would permit state requests for exemption; namely, (1) when at least 90 percent of all covered items and services are provided to Medicaid or CHIP beneficiaries through Medicaid or CHIP managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or (2) when at least 90 percent of the state’s Medicaid or CHIP beneficiaries are enrolled in Medicaid or CHIP managed care organizations as defined in 42 CFR
438.2 for Medicaid and 42 CFR 457.10 for CHIP. In both circumstances, the time and resources that the state would need to expend to implement the API requirements may outweigh the benefits of implementing and maintaining the API. As discussed in section II.B. of this proposed rule, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries as states, unlike other payers, do not maintain additional lines of business.
We acknowledge that the proposed exemption could mean that a few Medicaid or CHIP FFS systems would not receive the benefits of having this API available to facilitate health information exchange. To address this, we propose that states meeting the above thresholds would be expected to employ an alternative plan to enable the electronic exchange and accessibility of health information for those beneficiaries who are served under the FFS program.
A state meeting the above criteria would be permitted to submit a request for an exemption to the requirements for the Payer-to-Payer API once per calendar year for a one-year exemption. The state would be required to submit this annual request as part of a state’s annual APD for MMIS operations costs. The state would be required to include in its request
documentation that it meets the criteria for the exemption using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. We note we propose that this request be made annually as from year-to-year the nature of the FFS population could change and so it is important that the state provide the most current information for CMS’s consideration.
Exemptions would be granted for a one-year period if a state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established a plan to ensure that all impacted payers would have efficient electronic access to the same information through alternative means.
We request comment on the proposed extension and exemption.
For Medicaid and CHIP managed care, we are not proposing an extension process at this time because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements in 42 CFR part 438 and part 457 and also benefit from efficiencies resulting from their multiple lines of business impacted by these interoperability policies. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or are unachievable by the compliance date. We are soliciting comment on whether our belief concerning the scope of resources and ability of managed care parent organizations to achieve economies of scale is well-founded. Further, we seek comment on whether an extension process is warranted for certain managed care plans to provide additional time for the plan to comply with the
requirement at proposed 42 CFR 438.242(b)(7) (which cross references 42 CFR 438.61(b) and (c)) for Medicaid managed care plans and at proposed 42 CFR 457.1233(d)(4) (which cross references 42 CFR 457.731(b) and (c)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary for the reasons outlined here, we are open to considering one if necessary. If we adopt an extension process for these managed care plans and entities, what criteria would a managed care plan or entity have to meet to qualify for an extension? Should the process consider, for example, enrollment size, plan type, or some unique characteristic of certain plans that could hinder their achievement of the proposed requirements by the proposed compliance date? Also, we seek comment on whether, if we finalize such a process for Medicaid managed care plans or CHIP managed care entities, the state or CMS should manage the process and whether states could successfully adopt and implement the process on the timeline necessary to fulfill the goals and purposes of the process. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension request to include, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, the impact of non-compliance upon enrollees, the current or proposed means of providing electronic health information to providers, and a corrective action plan with a timeline to achieve compliance.
We do propose, however, to exclude non-emergency transportation (NEMT) PAHPs from the Payer-to-Payer API proposals. In this rule, we propose to require MCOs, PIHPs, and PAHPs other than NEMT PAHPs (as defined at 42 CFR 438.9(a)) to implement and maintain the Payer-to-Payer API. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs is not consistent with the proposed purposes of the Payer-to-Payer API
proposed at 42 CFR 431.61(b) and (c). Specifically, we do not believe that having all other Medicaid managed care plans, such as acute care or dental managed care plans, be required to request, receive, and incorporate into the plan’s records NEMT data from an enrollee’s prior or concurrent payer would help achieve the goals of the Payer-to-Payer API, namely to help avoid unnecessary care, ensure that providers are able to spend time with patients focusing on care versus collecting redundant information, or improve patient care through enhanced care coordination. Conversely, we do not believe having NEMT PAHPs be required to request, receive, and incorporate into its records enrollee data from other managed care plans contributes to achieving the goals of the Payer-to-Payer API given the unique nature and limited scope of the services they provide.
We note that the HIPAA Privacy Rule, at 45 CFR 164.502, permits a covered entity to use or disclose PHI for certain treatment, payment, or health care operations without individual authorization. As such, we believe a health plan that needs NEMT PAHP utilization for treatment, payment, or the applicable health care operations for a current enrollee, would generally be permitted to under the applicable HIPAA provisions.
As mentioned previously in this proposed rule, although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement a Payer-to-Payer API for the Medicare FFS program, if finalized. In this way, the Medicare FFS Payer-to-Payer API would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that Medicare FFS beneficiaries would also benefit from this data sharing.
Exception for QHP issuers
With regard to QHP issuers on the FFEs, similar to our exceptions process noted in the CMS Interoperability and Patient Access final rule for the Patient Access API (85 FR 25552
through 25553) and in section II.B.6.e. of this proposed rule for the Provider Access API, we are also proposing an exception for the Payer-to-Payer API at 45 CFR part 156.222(d). As such, if a plan applying for QHP certification to be offered through a FFE believes it cannot satisfy the Payer-to-Payer API requirements, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to payers, and solutions and a timeline to achieve compliance with the requirements of this section. Further, we propose that the FFE may grant an exception to these requirements if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates.
We request comment on this proposal.
Statutory Authorities for Payer Exchange Proposals
Medicaid and CHIP
For Medicaid managed care plans and Medicaid state agencies, we are proposing to require the implementation of a Payer-to-Payer API to exchange claims, encounter, clinical, and pending and active prior authorizations data between payers at a patient’s request or any time a patient changes payers using a FHIR-based API. Our proposals in this section fall generally under our authority in the following provisions of the statute:
Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan.
Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.
Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
We note statutory authority for proposals to require specific IGs for this and all APIs proposed in this rule is discussed in section II.A.3. of this proposed rule.
We believe these proposals related to the Payer-to-Payer API are authorized by these provisions of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, it is anticipated to help state Medicaid programs improve the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. Use of the Payer-to-Payer API could introduce efficiencies in providing Medicaid services, by reducing duplicate prior authorization requests, referrals, or tests. In addition, as is discussed in section II.B. of this proposed rule, with respect to the Provider Access API and the Bulk specification, this Payer-to-Payer API, by allowing payers to share health information for one or more patients at once, could increase efficiency and simplicity of administration. It could give payers access to all of their enrollees’ information with limited effort and enable the state to then make that information available to providers and to patients through the Provider Access and Patient Access APIs. And, it could reduce the amount of time needed to evaluate a patient’s current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. Use of the proposed Bulk specification allows state Medicaid programs to receive information on a full panel of patients at once, thus expediting the data collection process. Sharing patient information for a full panel of
patients at a specified time annually, such as at the end of the first calendar quarter, would help to ensure payers receive patient information in a timely manner when a beneficiary moves to a new payer, and therefore, could lead to more appropriate service utilization and higher beneficiary satisfaction by supporting efficient care coordination and continuity of care as beneficiaries move from payer to payer, which could lead to better health outcomes.
Second, the proposals are expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries’ best interests, consistent with section 1902(a)(8) and (a)(19) of the Act, for the following reasons. If states were to share information about Medicaid beneficiaries or former beneficiaries with other payers with whom these beneficiaries are enrolled, they could support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate a Medicaid beneficiary’s current care plan, their health risks, and their health conditions at the time that beneficiary enrolls with the Medicaid program. Exchanging this information between payers could also better support care continuity for Medicaid beneficiaries. As discussed in section II.D.4. of this proposed rule, if a state Medicaid program has access to a previous payer’s pending and active prior authorization decisions, the Medicaid program could choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might be of particular value in improving care continuity for beneficiaries who might churn into and out of Medicaid coverage, or have concurrent coverage in addition to Medicaid. The proposal could also improve the provision of Medicaid services, by potentially
helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers could be identified and provided case management services, as appropriate.
For Medicaid managed care plans, the proposed exchange of claims, encounter, USCDI, and some prior authorization data would greatly enhance an MCO’s, PIHP’s, or PAHP’s ability to fulfill its obligations under 42 CFR 438.208(b) which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and social support providers; make a best effort to conduct an initial screening of each enrollee's needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee's needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API proposed in this rule would give managed care plans the information needed to much more easily perform these required functions, thus enhancing the effectiveness of the care coordination and helping enrollees receive the most appropriate care in an effective and timely manner.
For CHIP, we are proposing these requirements under our authority in section 2101(a) of the Act, which states that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe the provisions in this proposed rule could strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates the use of electronic information exchange in the health care industry today and would facilitate a significant improvement in the delivery of quality health care to our beneficiaries.
As with the Medicaid FFS and Medicaid managed care programs, the proposals in this section of the proposed rule for CHIP FFS and CHIP managed care require the use of a Payer-to- Payer API to exchange claims, encounter, clinical and pending and active prior authorization data at a beneficiary’s request, or any time a beneficiary changes payers, using a FHIR-based API. The current payer could use data from the prior payer to more effectively or accurately respond to a request for a prior authorization, because under this proposal, a new payer would have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients could enable appropriate staff within the CHIP program to more effectively coordinate care and conduct the care management because they would have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, what vaccines they have had, or other possibly relevant encounters that could help payers manage their care. This proposal is consistent with the goal of providing more informed and effective care coordination, which could help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a).
QHP issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. Existing and emerging technologies provide a path to make information and resources for health and health care management universal, integrated, equitable, accessible to all, and personally relevant.
Requiring QHP issuers on the FFEs to build and maintain a Payer-to-Payer API would allow the seamless flow of claims and encounter data, the clinical data the payer maintains for a patient as defined in the USCDI version 1, as well as their pending and active prior authorization decisions, from payer to payer. We believe that ensuring a means for an enrollee’s new issuer to electronically obtain the enrollee’s claims, encounter, and clinical data, as well as prior authorization information with corresponding medical records, from the previous issuer will reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests.
We believe it is necessary that QHP issuers on FFEs have systems in place to send information important to care coordination with departing enrollees, and that QHP issuers also have systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate and consistent with the proposals in this section. Therefore, we believe certifying only health plans that make enrollees’ health information available to them and their providers, and as discussed in this section, other payers, in a convenient, timely, and portable way is in the interests of qualified individuals and qualified employers in the state in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.
We previously finalized the Payer-to-Payer Data Exchange in the CMS Interoperability and Patient Access final rule, where, with the approval and at the direction of an enrollee, one payer would have to send clinical data as defined in the USCDI version 1 to another payer named by the enrollee. We are now requiring this to be done via an API and adding claims and encounter data, as well as pending and active prior authorization decisions.
We also believe that requiring QHP issuers on the FFEs to use the Bulk Specification for the Payer-to-Payer API would improve the efficiency and simplicity of data transfers between issuers, by enabling the exchange of all data for all patients at once. We believe the opportunity to support an exchange of large volumes of patient data, rather than data for one patient at a time, may be cost effective for the issuers, and having patient care at the beginning of a new plan, could assist the new payer in identifying patients who need care management services, which could reduce the cost of care. Taking in volumes of data would also enable the QHPs to perform analysis on the types of new patients in their plan, if they choose to analyze data for existing patients as well.