CMS-10767.Supporting Statement Part A

Supporting Statement – Part A

Medicare/Medicaid; Interoperability and Patient Access Supporting Regulations

CMS-9115-F, OMB 0938-NEW

Background

The Centers for Medicare & Medicaid Services (CMS) is finalizing new requirements for a Patient Access Application Programming Interface (API) for Medicare Advantage (MA) organizations at 42 CFR 422.119, Medicaid Fee-for-Service (FFS) at 42 CFR 431.60, Children's Health Insurance Program (CHIP) FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42 CFR 457.1233(d), and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) at 45 CFR 156.221 to establish standards-based APIs that permit third-party applications (“apps”) to retrieve standardized data for adjudicated claims, encounters with capitated providers, provider remittances, enrollee cost-sharing, clinical information including reports of lab test results, pharmacy claims and formulary information (for MA-Prescription Drug Plans (MA-PDs)), and preferred drug lists, where applicable. We are finalizing a publicly available Provider Directory API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42 CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed care.

1. Need for the Information Collection

API Access Requirements

CMS is committed to fulfilling its role in promoting interoperability, putting patients first, and ensuring they have access to their health care data. The initial CMS Blue Button^® service was established in 2010 and allowed CMS beneficiaries, through MyMedicare.gov, to download their health care claims data in a PDF or text format. While the original Blue Button effort was a first step toward liberating CMS’ patient health information, CMS recognizes that significant opportunities remain to modernize access to patient information and the ability to share health information across the health ecosystem. CMS believes that moving to a system in which patients have access and use of their health information will empower them to make informed decisions about their health care.

CMS believes there are numerous benefits associated with individuals having simple and easy access to their health care data under a standard that is widely used. Whereas electronic health record (EHR) data are frequently locked in closed, disparate health systems, care and treatment information in the form of claims and encounter data is comprehensively combined in a patient’s claims and billing history. 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 than EHR data alone. As one example, inconsistent benefit utilization patterns in an individual’s claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance. Identifying and finding opportunities to address the individual’s non-adherence to a care plan are critical to keeping people with chronic conditions healthy and engaged so they can avoid hospitalizations. By authorizing their payer to make these data accessible via a third-party app via a standards-based API, individuals can further facilitate communication with their care teams and coordination of their care. Further, patients who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan.

1.1 Medicare Advantage API Requirements

In alignment with existing federal initiatives, we are finalizing new requirements for MA organizations at 42 CFR 422.119 to implement and maintain an API that is accessible to third-party applications and developers. The Patient Access API enables enrollees of MA plans and MA-PD plans to access their health data electronically through the use of common technologies and without special effort. We finalized that the information to be made available through the standards-based Patient Access API must include, at a minimum: data concerning adjudicated claims (including cost, specifically provider remittances and enrollee cost-sharing), which must be made available no later than one (1) business day after a claim is adjudicated; encounter data from capitated providers, which must be made available no later than one (1) business day after data concerning the encounter is received by the MA organization; and clinical data, in the form of the U.S. Core for Data Interoperability dataset (USCDI version 1) (if the MA organization maintains any such data), which must be made available no later than one (1) business day after the data are received by the MA organization. An MA organization that offers an MA-PD plan must make available data concerning adjudicated claims for covered Part D drugs, including remittances and enrollee cost-sharing, no later than one (1) business day after a claim is adjudicated; and formulary data including covered Part D drugs and any tiered formulary structure or utilization management procedure which pertains to those drugs.

Additionally, at 42 CFR 422.120 for MA organizations, we finalized requirements for the Provider Directory API. The MA organization must implement and maintain a publicly accessible, standards-based API that is conformant with the technical requirements at 42 CFR 422.119(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations. The API must provide a complete and accurate directory of the MA plan’s network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after the MA organizations receives provider directory information or updates to provider directory information; and, for an MA organization that offers an MA-PD plan, the MA-PD’s pharmacy directory, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”) updated no later than 30 calendar days after the MA organization receives pharmacy directory information or updates to pharmacy directory information. This information is the same information MA organizations are already required to disclose to their enrollees under 42 CFR 422.111(b)(3) and make available online under 42 CFR 422.111(h)(2)(ii).

We finalized these requirements under our authority in section 1856(b) and section 1857(e) of the Social Security Act (the Act). Sections 1856(b) and 1857(e) of the Act provides CMS with the authority to add standards and requirements for MA organizations that the Secretary finds necessary and appropriate and not inconsistent with Part C of the Medicare statute. In addition, section 1852(c) of the Act requires disclosure by MA organizations of specific information about the plan, covered benefits, and the network of providers; section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. The information required to be made available through the APIs in this final rule is within the scope of information that MA organizations must make available under sections 1852(c) and (h) of the Act and the implementing regulations at 42 CFR 422.111 and 422.118. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Additionally, as noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7629), we believe that to align the standards with 21st century demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. We further noted that the proposed requirements were intended to achieve this goal.

We also relied on section 1860D-12(b)(3) of the Act to add provisions specific to the Part D benefit offered by certain MA organizations; that provision incorporates the authority to add program requirements to the contracts from section 1857(e)(1) of the Act. For MA organizations that offer MA-PD plans, we finalized requirements at 42 CFR 422.119(b)(2) regarding electronic health information for Part D coverage. We explained that this policy was supported by the disclosure requirements imposed under section 1860D-4(a) of the Act, requiring Part D claims information, pharmacy directory information, and formulary information to be disclosed to enrollees. And, we note here that 42 CFR 423.136(d) requires Part D plans to ensure timely access by enrollees to the records and information that pertain to them. The APIs in this rule further implement and build on these authorities for ensuring that Part D enrollees have access to information.

1.2 Medicaid FFS and Managed Care, CHIP FFS and Managed Care API Requirements

In alignment with existing federal initiatives, we finalized a new requirement for Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, CHIP managed care entities at 42 CFR 457.1233(d), and Medicaid managed care plans at 42 CFR 438.242(b)(5) that requires states in Medicaid and CHIP FFS and Medicaid and CHIP managed care, including managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs), to implement and maintain an API which is accessible to third-party applications and developers. The Patient Access API enables beneficiaries to access their health data electronically through the use of common technologies and without special effort. We finalized the information to be made available through the standards-based Patient Access API must include, at a minimum: data concerning adjudicated claims (including cost, specifically provider remittances and beneficiary cost-sharing), which must be made available no later than one (1) business day after a claim is adjudicated; encounter data, which must be made available no later than one (1) business day after receiving the data from providers, clinical data, in the form of the USCDI version 1 (if the state maintains any such data) which must be made available no later than one (1) business day after the data are received by the state; and information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, which must be made available no later than one (1) business day after the effective date of any such information or updates to such information.

Additionally, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities, we finalized requirements for the Provider Directory API. These provisions require the implementation and maintenance of a publicly accessible, standards-based API that is conformant with the technical requirements at 42 CFR 431.60(c) for Medicaid, and 42 CFR 457.730(c) for CHIP, excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations. The API must provide a complete and accurate directory of the state’s provider directory information specified in section 1902(a)(83) of the Act, updated no later than 30 calendar days after the state receives provider directory information or updates to provider directory information. We believe that these policies are designed to empower patients by mandating that entities subject to the API policies take steps – by implementing the two required APIs – to enable beneficiaries to have access to their data in a usable digital format and have potentially easier means to share that data.

We finalized these new requirements under our authority in 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 plan, and section 1902(a)(19) of the Act, which requires that care and services be provided in a manner consistent with simplicity of administration and the best interests of the recipients. For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which sets forth 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. Together, as noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7630), we believe these policies will provide us with authority (in conjunction with our delegation of authority from the Secretary) to adopt requirements for Medicaid and CHIP that are necessary to ensure the provision of quality care in an efficient and cost-effective way, consistent with simplicity of administration and the best interest of the beneficiary.

Medicaid managed care, section 1932(a)(5) of the Act requires that states and managed care plans provide basic managed care information to enrollees on how to utilize a managed care program and to facilitate decision-making about plan choice, providers, and benefits. The intent of this statutory provision was to provide information from which enrollees could make decisions about their health care; the API finalized at 42 CFR 438.242(b)(6) supports that intent in a robust and modern way. We believe the health care information that will be available through the Provider Directory API enables beneficiaries to make more informed, proactive decisions. Additionally, since most of the information required by section 1932(a)(5) of the Act – particularly the beneficiary handbook, provider directory, and formulary – is currently provided electronically, the standardized data available through the APIs finalized in this rule could be easily integrated for use by the beneficiary. As digital health care evolves, data becomes an important resource that Medicaid managed care beneficiaries can use to improve their health outcomes.

We also believe that as technology has advanced, we have encouraged states, health plans, and providers to adopt various forms of technology to improve the accurate and timely exchange of standardized health care information. As noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7630) the policy will move Medicaid and CHIP programs in the direction of enabling better information access by Medicaid beneficiaries and CHIP enrollees, which would make them active partners in their health care by providing a way for them to easily monitor and share their data. By requiring that certain information be available in and through standardized formats and technologies, we noted that the policy moved these programs toward interoperability, which is key for data sharing and access, and ultimately, improved health outcomes. We also note that states would be expected to implement the CHIP provisions using CHIP administrative funding, which is limited under sections 2105(a)(1)(D)(v) and 2105(c)(2)(A) of the Act to 10 percent of a state’s total annual CHIP expenditures.

1.3 Qualified Health Plans (QHP) API Requirements

In alignment with existing federal initiatives, we are finalizing a requirement for a new QHP certification standard at 45 CFR 156.221 to implement and maintain an API that is accessible to third-party applications and developers. The Patient Access API enables enrollees of QHPs offered on FFEs, excluding issuers only offering standalone dental plans (SADPs) and issuers only offering Federally-facilitated Small Business Health Options Program (FF-SHOP) plans, to access their health data electronically through the use of common technologies and without special effort. We finalized the information to be made available through the standards-based Patient Access API must include, at a minimum: data concerning adjudicated claims (including cost, specifically provider remittances and enrollee cost-sharing), which must be made available no later than one (1) business day after a claim is adjudicated; encounter data from capitated providers, which must be made available no later than one (1) business day after data concerning the encounter is received by the QHP issuer; and clinical data, in the form of the USCDI version 1 (if the QHP issuer maintains any such data), which must be made available no later than one (1) business day after data is received by the issuer.

We finalized this new requirement under our authority in section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act), which affords the Exchanges the discretion to certify QHPs that are in the best interests of qualified individuals and qualified employers. Specifically, section 1311(e) of the Affordable Care Act authorizes Exchanges to certify QHPs that meet the QHP certification standards established by the Secretary, and if the Exchange determines that making available such health plan through such Exchange is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates.

2. Use of the Information

Patient Access and Provider Directory APIs

2.1. Medicare Advantage Organizations

CMS finalized new requirements for MA organizations to implement and maintain standards-based Patient Access and Provider Directory APIs, which are accessible to third-party applications and developers, as detailed above. The APIs are required to meet the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule at 45 CFR 170.215 to ensure that MA enrollees’ electronic access to their health data and plan information is not obstructed by or confined to certain propriety systems, and that MA enrollees can access and use their information. Furthermore, the APIs are required to permit third-party applications to retrieve health data with the approval and at the direction of the individual enrollee.

2.2. Medicaid FFS and Managed Care, CHIP FFS and Managed Care

CMS finalized new requirements for states in Medicaid and CHIP FFS and Medicaid and CHIP managed care– including MCOs, PIHPs, and PAHPs – to implement standards-based Patient Access and Provider Directory APIs, which are accessible to third-party applications and developers, as detailed above. The APIs are required to meet the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule at 45 CFR 170.215 to ensure that beneficiaries’ electronic access to their health data and plan information is not obstructed or confined to certain proprietary systems, and that beneficiaries can access and use their information. Furthermore, the APIs are required to permit third-party application to retrieve health data with the approval and at the direction of the individual beneficiary.

2.3. Qualified Health Plans

CMS finalized a new QHP certification standard that would require issuers of QHPs on the FFEs, excluding issuers offering only SADPs and FF-SHOP plans, to implement a standards-based Patient Access API, which is accessible to third-party applications and developers, as detailed above. The API is required to meet the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule at 45 CFR 170.215 to ensure that enrollees’ electronic access to their health data is not obstructed or confined to certain proprietary systems, and that enrollees can access and use their information. Furthermore, the API is required to permit third-party application to retrieve health data with the approval and at the direction of the individual enrollee.

3. Improved Information Technology:

Patient Access and Provider Directory APIs

CMS finalized new requirements for MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the individual market FFEs to implement and maintain standards-based APIs, which are accessible to third-party applications and developers. These APIs enable patients to access and use their health information, and they allow data to be exchanged between different systems securely. This enables a payer to exchange data with a third-party app so patients can get access to their health information and use it in a way that makes most sense to them. These APIs help break down the silos that prevent health information from moving with the patient throughout their health care journey. This secure flow of information can aid care coordination, improve health outcomes, and reduce burden and cost.

4. Non-duplication

The information obtained through this collection is unique and is not already available for use or adaptation from another cleared source.

5. Burden on Small Businesses

For this final rule, we analyzed whether the provisions of the final rule would have a significant impact on a substantial number of small entities. Small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The API requirements in this final rule affect: 1) QHP issuers on the FFEs; 2) MA organizations, including those that are also Part D sponsors of MA-PD plans; and 3) Medicaid MCOs with a minimum threshold for small business size of $41.5 million (https://www.sba.gov/federal-contracting/contracting-guide/size-standards). While a significant number (more than five (5) percent) of not-for-profit organizations and small businesses are affected by this final rule, the impact is not significant. To assess impact, we used data which shows that the total (not discounted) net effect of this final rule over 10 years is $714 million.

There are a variety of ways to assess whether MA organizations meet the $41.5 million threshold for small businesses. The assessment can be done by examining net worth, net income, cash flow from operations, and projected claims as indicated in their bids. Using projected monetary requirements and projected enrollment for 2018 from submitted bids, approximately 30 percent of the MA organizations fell below the $41.5 million threshold for small businesses. Additionally, an analysis of 2016 data (the most recent year for which we have actual data on MA organization net worth) shows that approximately 30 percent of all MA organizations fall below the minimum threshold for small businesses.

We next assessed impact on Medicaid managed care plans. The total projected capitation payment and premiums for 2019 is projected to be $337.6 billion.¹ Hence, the total cost of this final rule over 10 years, $714 million, is significantly below the three (3) to five (5) percent threshold for significant impact to Medicaid managed care plans. Additionally, because Medicaid managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the API provisions of this final rule will be included in their capitation rates and may be reasonable, appropriate, and attainable costs whether or not they are a small business.

Finally, we assessed impact on QHP issuers on the FFEs. Based on data in the public CMS Medical Loss Ratio (MLR) files, commercial health insurance issuers had premium revenue of $77 billion for individual market plan coverage in 2016. Therefore, the aggregate raw cost of this final rule over 10 years, $762 million (low estimate) and $1.3 billion (high estimate), is significantly below the three (3) to five (5) percent threshold for significant impact to commercial plans. We believe that although a significant number of small plans under each program are affected by this rule, on average, this impact is not significant. Additionally, for QHP issuers on the FFEs, we note that for those small entities that find the cost of the provisions of this final rule burdensome, an exceptions process has been defined in the final rule. Specifically, we note that we may provide an exceptions process through which the FFEs may certify health plans that do not provide patient access through a standards-based API, but otherwise meet the requirements for QHP certification. This process could apply to small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards-based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to consumers, and not certifying the issuer’s QHP or QHPs would result in consumers having few or no plan options in certain areas.

6. Less Frequent Collection

Patient Access and Provider Directory APIs

These API requirements enable patients to access and use their health information. Patients who have immediate electronic access to their health information are empowered to make more informed decisions about their care. Health Level 7^® (HL7) Fast Healthcare Interoperability Resources^® (FHIR)-based APIs have the ability to make data available without the need to link multiple systems and thus provide a patient a single-point of access to their data. Having APIs that can be accessed by third-party apps permits the patient to choose how they want to access their data, and promotes innovation in industry to find ways to best help patients interact with their data in a way that is most meaningful and helpful to them. By utilizing an API approach, any system can make data securely available and those data can be used by any other system that is following the same approach to mapping and exchanging data without a need to otherwise link the systems or ensure any system-level compatibility.

7. Paperwork Reduction Act Guidelines

There are no special circumstances. More specifically, this information collection does not do any of the following:

-Require respondents to report information to the agency more often than quarterly;

-Require respondents to prepare a written response to a collection of information in fewer than 30 days after receipt of it;

-Require respondents to submit more than an original and two copies of any document;

-Require respondents to retain records, other than health, medical, government contract, grant-in-aid, or tax records for more than three years;

-Connect to a statistical survey that is not designed to produce valid and reliable results that can be generalized to the universe of study;

-Require the use of a statistical data classification that has not been reviewed and approved by OMB;

-Include a pledge of confidentiality that is not supported by authority established in statue or regulation that is not supported by disclosure and data security policies that are consistent with the pledge, or which unnecessarily impedes sharing of data with other agencies for compatible confidential use; or

-Require respondents to submit proprietary trade secret, or other confidential information unless the agency can demonstrate that it has instituted procedures to protect die information's confidentiality to the extent permitted by law.

8. Consultation and Public Comments

The Notice of Proposed Rule Making published on March 4, 2019 (84 FR 7610; RIN 0938-AT79) and served as the 60-day Federal Register notice. PRA-related public comments were received. A summary of the comments and our response has been added to this package.

9. Payments/Gifts to Respondents

There is no payment/gift to respondents.

10. Confidentiality

All information collected under this initiative will be maintained in strict accordance with statutes and regulations governing confidentiality requirements. In addition, the tools used for transmission of data are considered confidential forms of communication and are Health Insurance Portability and Accountability Act of 1996 (HIPAA) compliant.

11. Sensitive Questions

There are no sensitive questions associated with this collection. Specifically, the collection does not solicit questions of a sensitive nature, such as sexual behavior and attitudes, religious beliefs, and other matters that are commonly considered private.

12. Burden Estimates

12.1 Wages

To derive average costs, we used data from the U.S. Bureau of Labor Statistics’ May 2018 National Occupational Employment and Wage Estimates (https://www.bls.gov/oes/current/oes_nat.htm). Table 1 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage.

TABLE 1: Occupation Titles and Wage Rates

Occupation Title	Occupation Code	Mean Hourly Wage ($/hr)	Fringe Benefit ($/hr)	Adjusted Hourly Wage ($/hr)
Administrators and Network Architects	15-1140	$45.09	$45.09	$90.18
Security Engineer	17-2199	$47.80	$47.80	$95.60
Computer and Information Analysts	15-1120	$45.67	$45.67	$91.34
General Operations Manager	11-1021	$59.56	$59.56	$119.12
Operations Research Analysts	15-2031	$42.48	$42.48	$84.96
Software Developers, Applications	15-1132	$51.96	$51.96	$103.92
Computer and Information Systems Managers	11-3021	$73.49	$73.49	$146.98
Designers	27-1020	$24.05	$24.05	$48.10
Technical Writer	27-3042	$36.30	$36.30	$72.60
Computer Systems Analysts	15-1121	$45.01	$45.01	$90.02
Network and Computer Systems Administrators	15-1142	$41.86	$41.86	$83.72
Medical Records and Health Information Technician	29-2071	$21.16	$21.16	$42.32
Medical and Health Service Managers	11-9111	$54.68	$54.68	$109.36

We are adjusting our employee hourly wage estimates by a factor of 100 percent. This is necessarily a rough adjustment, both because fringe benefits and overhead costs vary significantly from employer to employer, and because methods of estimating these costs vary widely from study to study. Nonetheless, there is no practical alternative and we believe that doubling the hourly wage to estimate total cost is a reasonably accurate estimation method.

12.2 Burden Estimates

To promote our commitment to interoperability, we are finalizing new requirements for a Patient Access API for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221, to establish standards-based APIs that permit third-party applications to retrieve data for adjudicated claims (including cost, specifically provider remittances and patient cost-sharing), encounter data from capitated providers, clinical data in the form of the USCDI version 1, and pharmacy claims and formulary data for MA-PDs, as well as preferred drug lists, where applicable. We are finalizing a publicly available Provider Directory API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42 CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed care.

These standards-based APIs permit third-party applications to retrieve these specified data. To implement the new requirements for APIs, we estimate that payers and states will conduct three major work phases: initial design; development and testing; and long-term support and maintenance. In the initial design phase, we believe tasks will include: determining available resources (personnel, hardware, cloud space, etc.); assessing whether to use in-house resources to facilitate an API connection or contract the work to a third party; convening a team to scope, build, test, and maintain the API; performing a data availability scan to determine any gaps between internal data models and the data required for the necessary HL7 FHIR implementations; and, mitigating any gaps discovered in the available data.

During the development and testing phase, we believe payers and states will need to conduct the following: map existing data to HL7 FHIR standards, which will constitute the bulk of the work required for implementation; allocate hardware for the necessary environments (development, testing, and production); build a new FHIR server or leverage existing FHIR servers; determine the frequency and method by which internal data are populated on the FHIR server; build connections between the databases and the FHIR server; perform capability and security testing; and vet third-party applications, which includes potentially asking third-party application developers to attest to certain privacy provisions.

After the completion of API development, and as part of the third phase, payers will need to conduct the following throughout each year: allocate resources to maintain the FHIR server, which includes the cost of maintaining the necessary patient data; and perform capability and security testing.

The burden estimate related to the new requirements for APIs reflects the time and effort needed to collect the information described above and disclose this information. In the proposed rule, we estimated an initial one-time cost associated with implementing the API requirements of $789,356 per organization (84 FR 7659). However, in response to public comment, we are providing updated cost estimates for implementing and maintaining the Patient Access and Provider Directory APIs, moving from a single point estimate to a range—including a low, primary, and high estimate—to better take into account the many factors that impact the cost of implementation.

For a low estimate: We presume that it will take administrators and network architects 1,440 hours (at $90.18 an hour), security engineers 960 hours (at $95.60 an hour), computer and information analysts 480 hours (at $91.34 an hour), operations research analysts 960 hours (at $84.96 an hour), software developers 960 hours (at $103.92 an hour), computer and information systems managers 720 hours (at $146.98 an hour), general and operations managers 720 hours (at $119.12 an hour), designers 960 hours (at $48.10 an hour), technical writers 240 hours (at $72.60 an hour), and computer systems analysts 960 hours (at $90.02 an hour). We estimate a one-time burden assessment of 8,400 (1,440 + 960 + 480 + 960 + 960 + 720 + 720 + 960 + 240 + 960) hours per organization or state and a total of 2,898,000 (8,400 hours per organization x 345 organizations) hours across all organizations or states. The one-time cost to implement API requirements is $788,414 per organization or state per implementation and $272,002,968 across all organizations or states to complete the task described above.

For a primary estimate: We presume that it will take administrators and network architects 2,880 hours (at $90.18 an hour), security engineers 1,920 hours (at $95.60 an hour), computer and information analysts 960 hours (at $91.34 an hour), operations research analysts 920 hours (at $84.96 an hour), software developers 1,920 hours (at $103.92 an hour), computer and information systems managers 1,440 hours (at $146.98 an hour), general and operations managers 1,440 hours (at $119.12 an hour), designers 1,920 hours (at $48.10 an hour), technical writers 480 hours (at $72.60 an hour), and computer systems analysts 1,920 hours (at $90.02 an hour). We estimate a one-time burden assessment of 16,800 (2,880 + 1,920 + 960 + 1,920 + 1,920 + 1,440 + 1,440 + 1,920 + 480 + 1,920) hours per organization or state and a total of 5,796,000 (16,800 hours per organization x 345 organizations) hours across all organizations or states. The one-time cost to implement API requirements is $1,576,829 per organization or state per implementation and $544,005,936 across all organizations or states to complete the task described above.

For a high estimate: We presume that it will take administrators and network architects 4,320 hours (at $90.18 an hour), security engineers 2,880 hours (at $95.60 an hour), computer and information analysts 1,440 hours (at $91.34 an hour), operations research analysts 2,880 hours (at $84.96 an hour), software developers 2,880 hours (at $103.92 an hour), computer and information systems managers 2,160 hours (at $146.98 an hour), general and operations managers 2,160 hours (at $119.12 an hour), designers 2,880 hours (at $48.10 an hour), technical writers 720 hours (at $72.60 an hour), and computer systems analysts 2,880 hours (at $90.02 an hour). We estimate a one-time burden assessment of 25,200 (4,320 + 2,880 + 1,440 + 2,880 + 2,880 + 2,160 + 2,160 + 2,880 + 720 + 2,880) hours per organization or state and a total of 8,694,000 (25,200 hours per organization x 345 organizations) hours across all organizations or states. The one-time cost to implement API requirements is $2,365,243 per organization or state per implementation and $816,008,904 across all organizations or states to complete the task described above.

Once the APIs are established, we believe that there is an annual cost for performing necessary capability and security testing, as well as performing necessary maintenance and upgrades. We presume that it will take administrators and network architects 180 hours (at $90.18 an hour), network and computer systems administrators 420 hours (at $83.72 an hour), security engineers 240 hours (at $95.60 an hour), computer and information analysts 60 hours (at $91.34 an hour), operations research analysts 120 hours (at $84.96 an hour), software developers 240 hours (at $103.92 an hour), computer and information systems managers 90 hours (at $146.98 an hour), general and operations managers 90 hours (at $119.12 an hour), designers 120 hours (at $48.10 an hour), technical writers 30 hours (at $72.60 an hour), and computer systems analysts 120 hours (at $90.02 an hour). We estimate the total annual burden to be 1,710 (180 + 420 + 240 + 60 + 120 + 240 + 90 + 90 + 120 + 30 + 120) hours per organization or state, and 589,950 (1,710 hours per organization x 345 organizations) hours across all organizations and states. Thus, we estimate the total annual cost to maintain the API requirements is $157,657 per organization or state and $54,391,527 across all organizations and states.

SummFary of One-time Burden Estimates

Estimate	Regulation Section(s)	OMB Control No.	Number of Respondents	Number of Responses	Burden per Response (hours)	Total Annual Burden (hours)	Hourly Labor Cost of Reporting ($)	Total Labor Cost of Reporting ($)	Total Capital/ Maintenance Costs ($)	Total Cost ($)
Low	§422.119, §422.120, §431.60, §431.70, §438.242(b)(5) and (6), §457.730, §457.760, §457.1233(d)(2) and (3) and §156.221	0938-New	345	345	8,400	2,898,000	Varies	272,002,968	0	272,002,968
Preliminary	§422.119, §422.120, §431.60, §431.70, §438.242(b)(5) and (6), §457.730, §457.760, §457.1233(d)(2) and (3) and §156.221	0938-New	345	345	16,800	5,796,000	Varies	544,005,936	0	544,005,936
High	§422.119, §422.120, §431.60, §431.70, §438.242(b)(5) and (6), §457.730, §457.760, §457.1233(d)(2) and (3) and §156.221	0938-New	345	345	25,200	8,694,000	Varies	816,008,904	0	816,008,904
	Total		345	345	NA	NA	Varies	NA		NA

Summary of Annual Burden Estimates

Regulation Section(s)	OMB Control No.	Number of Respondents	Number of Responses	Burden per Response (hours)	Total Annual Burden (hours)	Hourly Labor Cost of Reporting ($)	Total Labor Cost of Reporting ($)	Total Capital/ Maintenance Costs ($)	Total Cost ($)
§422.119, §422.120, §431.60, §431.70, §438.242(b)(5) and (6), §457.730, §457.760, §457.1233(d)(2) and (3) and §156.221	0938-New	345	345	1,710	589,950	Varies	54,391,527	0	54,391,527
Total		345	345	1,710	589,950	Varies	54,391,527		54,391,527

13. Respondent Costs Other Than Burden Hour Costs

There are no annualized costs to respondents other than the labor burden costs addressed in Section 12 of this document to complete this collection.

14. Cost to the Federal Government

To determine the cost to the federal government we allocate the total cost of the implementation across the various plan types. Cost estimates have been aggregated at the parent organization level because we believe that an organization that offers individual market plans, Medicare Advantage, Medicaid, and CHIP products would create one system that would be used by all “plans” it offers. We note that due to the implementation of APIs across multiple business lines, there is no straightforward method to immediately estimate parent organization expenditures on how much of the cost is born by each program. In the proposed rule (84 FR 7662 through 7664) and the final rule, we provided a detailed discussion of how we allocated the percentage of total costs to comply with the API provisions across the various plans that offered products in the QHPs on the FFEs, Medicaid and CHIP, and MA. Detailed in that discussion, we allocated a percentage of the proportion of premiums to achieve an approximation of the proportion of the total cost that should be allocated across the various plan types, as follows:

TABLE 2. Proportion of Premiums (in billions) for Medicaid and CHIP, Medicare Advantage, and Individual Market Plans

Year2	Medicaid and CHIP	Medicare Advantage	Individual Market Plans	Totals
2016 Premium (billions)	113	157	77	347
2016 Percentage (used in this RIA in all estimates) of total costs by program	32.56%	45.24%	22.19%	100.00%

Since cost allocation at the parent organization level and the allocations of each parent organization may differ by program (Medicaid, CHIP, Medicare Advantage, and individual market plans) and is an internal business decision, we cannot directly assess per-payer costs. However, using the values in Table 2 we can assess the proportions of cost by program. We can then multiply these proportions by the total costs to obtain the total cost by year of implementing and maintaining the APIs, to offer estimates of API costs by year and program (Table 3).

TABLE 3. API Costs (in millions) by Year and Program

Year	Full Implementation and Maintenance Costs (millions) for API provisions	Medicaid and CHIP (32.56%)	Medicare Advantage (45.24%)	Individual Market Plans (22.19%)
2020 (Low estimate)	272.0	88.6	123.1	60.4
2020 (Primary estimate)	544.0	177.2	246.1	120.7
2020 (High Estimate)	816.0	265.7	369.2	181.1
2021	54.4	17.7	24.6	12.1
2022	54.4	17.7	24.6	12.1
2023	54.4	17.7	24.6	12.1
2024	54.4	17.7	24.6	12.1
2025	54.4	17.7	24.6	12.1
2026	54.4	17.7	24.6	12.1
2027	54.4	17.7	24.6	12.1
2028	54.4	17.7	24.6	12.1
2029	54.4	17.7	24.6	12.1
Total (Low Estimate)	761.5	248.0	344.6	169.0
Total (Primary Estimate)	1033.5	336.6	467.6	229.3
Total (High Estimate)	1305.5	425.1	590.7	289.7

In the final rule we detail the various reimbursement mechanisms available to the different programs from the federal government. We next subtract the costs that will be paid by the federal government, which include premium tax credit (PTC) payments as well as federal matching in Medicaid and Medicare Advantage. For PTC payments and MA, we have assumed federal payment in 2021.

The following percentages were applied to Table 3 API Costs (in millions) by Year and Program to obtain Table 4 Costs (in millions) Incurred by Federal Government Program and Year: 0 percent for individual market plans; 34 percent for MA plans; and (0.48 x 0.90)+(0.52 x 0.5844) (first year) and (0.48 x 0.75)+(0.52 x 0.5844) (later years) for Medicaid.³ These proportions represent different reimbursement rates between FFS and managed care. Additionally, we estimate that impact to PTCs in the FFE states will be approximately $6 million per year starting in 2021, which is about 0.02 percent of the total 2021 expected PTC payment in FFE states. Therefore, the costs to the federal government are detailed below.

TABLE 4. Costs (in millions) Incurred by Federal Government Program and Year

Year	For Medicaid and CHIP	For Medicare Advantage	For Individual Market Plans	Totals
2020 (Low estimate)	65.2	0.0	0.0	NA
2020 (Primary estimate)	130.4	0.0	0.0	NA
2020 (High Estimate)	195.5	0.0	0.0	NA
2021 (Low estimate)	11.8	50.2	6.1	NA
2021 (Primary Estimate)	11.8	92.1	6.1	NA
2022 (High Estimate)	11.8	133.9	6.1	NA
2022	11.8	8.4	6.2	NA
2023	11.8	8.4	6.2	NA
2024	11.8	8.4	6.3	NA
2025	11.8	8.4	6.3	NA
2026	11.8	8.4	6.3	NA
2027	11.8	8.4	6.3	NA
2028	11.8	8.4	6.3	NA
2029	11.8	8.4	6.4	NA
Total (Low Estimate)	171.0	117.1	56.4	344.5
Total (Primary Estimate)	236.2	159.0	56.4	451.6
Total (High Estimate)	301.4	200.8	56.4	558.6

15. Reasons for Change in Burden

This is a new collection with a new associated burden.

16. Publication of Results

The results of this information collection will not be published.

17. Expiration Date:

These ICRs do not lend themselves to an expiration date, as there are no forms.

18. Certification Statement:

There are no exceptions to the certification statement.

1 See “Capitation payments & premiums” in Table 17 of Appendix D in, Office of the Actuary (Centers for Medicare and Medicaid Services). (2016). 2016 Actuarial Report on the Financial Outlook for Medicaid. Retrieved from https://www.medicaid.gov/medicaid/finance/downloads/medicaid-actuarial-report-2016.pdf.

2 As discussed in the final rule, 2017 and 2018 premiums demonstrate that the proportion of premiums by payer is consistent with 2016 numbers. The final rule uses 2016 premium proportions to estimate cost to the federal government by year and program.

3 Based on current enrollment in Medicaid FFS and Medicaid managed care, we have allocated 48 percent of the costs to FFS, which are reimbursed by the federal government at 90 percent for the first year and 75 percent for additional years, as these are the match rate for the sums expended during such quarter as are attributable to the design, development, or installation of mechanized claims processing and information retrieval systems. We have allocated the remaining 52 percent of the costs at a general FMAP of 58.44 percent for managed care, which is the federal match rate for capitation payments.

8