Comment: In addition to the changes in the in the 11/29/24 memo, Updates and Timeline for the Contract Year 2026 Plan Benefit Package, and the 60-day comment period of CY2026 PBP & Formulary changes posted (CMS-R-262, OMB0938-0763) we ask CMS consider adjustments to the PBP supplemental benefit indicator of waving the required 3-day IP stay prior to a SNF stay. An issue was raised by OACT after the rebate reallocation submission indicating our PBP and BPT did not align in indicating SNF supplemental benefits. The SNF supplemental benefit provided by our plan allow less than the 3-dayIP stay prior to a SNF stay. This is indicated in the PBP Benefit Details section by checking a box in the SNF detail entry screens and entered the number of days. There is not an option to select allowing less than the 3-day IP stay in the ‘Benefit Offerings” section where non-Medicare services are selected. The non-Medicare SNF option allows the plan to select to coverage of additional days beyond Medicare. This is not the same allowing less than the 3-day IP stay for SNF services. Because the BPT indicated we had a SNF supplemental benefit but we did not have the SNF non-Medicare covered item checked under ‘Benefit Offerings’ if flagged as a disconnect for OACT. We worked with Sara Walters to confirm the disconnect in supplemental benefit entry for this SNF supplemental benefit and that our PBP entry and BPT was correct with OACT. To prevent this mis-match/issue from happening in CY2026 PBPs, we recommend CMS add the option to allow less than a 3-day IP stay prior to SNF services in the Benefit Details section or update the PBP to recognize this selection in the Benefit Details SNF entry screen is considered the supplemental benefit entry.
Response: CMS will consider this requested enhancement.
Comment: In the Contract Management module, organizations must click each contract separately to pull data reports. Within each contract, it is possible to choose "Select All" to include all plans within that contract, but for large organizations with dozens of contracts it is time consuming, administratively burdensome, and can lead to discrepancies in reporting if clicking errors are made during the report pulling/selection process. In the Contract Reports - Contract and Plan Summary Reports - Basic Plan Characteristics Report, UHC requests the capability to simultaneously select all contract/plan/segments that an individual has access to when pulling data reports.
Response: This comment is out of scope for this PRA package.
Comment: PBP data entry reporting may be pulled at the contract level/individual PBP level from the Plan Benefit Package -> Reports module. PBP Data Reports found in this module can be useful in aiding organizations with their audits of PBP data entry prior to the initial June bid submissions, Rebid Reallocation, and Desk Review submissions. The only option available today when pulling PBP Data Excel Reports for multiple plans is to pull one large Excel file. Because the data is not separated out by plan, it can be challenging for organizations to audit their plans at the individual plan level. UHC recommends that CMS provide an Excel file for each individual plan. This approach will help with the ease and accuracy of organizations’ review and confirmation of the individual plan data submissions. We also request that the report module create a zip file that includes multiple individual PBP specific Excel files.
Response: CMS will consider breaking out the plans at an individual level as a reporting feature enhancement. In the meantime, CMS is planning to release the plan version of the plan benefit extract data extract in May rather than post-contract approval.
Comment: In the Data Extract Facility module, organizations can download a Plan Information - Plan Version report that has the plan-level information that was entered into the Manage Plans subsection of the Bid Submission module. UHC recommends that CMS make this information available to download as a dataset during the PBP data entry window before bid submission versus after bid submission or after CMS approval to improve upon the accuracy and/or audit activities of the bid.
Response: This comment is out of scope for this PRA package.
Comment: In the Data Extract Facility module, CMS provides updates to the data for the Plan Service Area extract once a week and/or upon request. UHC requests that CMS consider giving plans real-time access to the data. Not having to submit a request to CMS to get the updated data will be more efficient for both CMS and plans and will avoid unnecessary delays in the review process.
Response: This comment is out of scope for this PRA package.
Comment: Currently, data entered in "Plan Setup" can only be viewed in the "Plan Information" extract. This extract can only be pulled after all plans have been submitted to CMS. Having access to real-time information before bid submission completion, would make it much easier for organizations to proactively verify "Plan Setup" information prior to bid submission. In order to verify plan setup information, before bids submission, UHC requests real-time reporting of data entered in Plan Setup.
Response: CMS will investigate ways in which we can make this data available earlier.
Comment: Prior to the final bid submissions, UHC conducts multiple quality checks using the reports pulled from the Bid Reports screen of HPMS. Most of the reports (such as Service Area Reports and Plan Benefits Reports) are only available for download at the individual plan level, but for organizations that conduct reviews at the portfolio level with all of their plans, this can make the process of pulling each report for a single plan time-consuming and inefficient. UHC requests the ability to download the reports for all / multiple plans in the form of a zip file. Within the zip file, we also recommend including the plan ID on each individual file name.
Response: To assist plans with the bid submission process, CMS is planning to release the plan version of the plan benefit extract data extract in May rather than post-contract approval.
Comment: With the current structure of the PDP Demo Election Report, organizations can only print the information at a PBP level to a pdf or take a screen shot, which limits the output to what is visible on the screen. UHC recommends that CMS add the functionality to allow organizations to export the PDP Demo Election information to an Excel file or pdf.
Response: This comment is out of scope for this PRA package.
Comment: The substantiation documentation upload process requires organizations to upload individual zip files to one plan at a time and each zip file can take up to 5 minutes to process per plan. Given the number of files that need to be uploaded during the short windows of time before the bid submission and resubmission deadlines, UHC requests that CMS consider a module that would expedite the substantiation documentation upload process. An example of an existing HPMS module that supports this capability is the PBP-BPT submission module. CMS could consider using the PBP-BTP submission model to develop a substantiation document upload module to allow organizations to simultaneously upload different zip files to multiple plans.
Response: This comment is out of scope for this PRA package.
Comment: During the bid submission process, health plans may upload hundreds of substantiation documents for each HPBP which can result in over 100,000 documents that need to be audited by the health plans to confirm the accuracy of the uploads. UHC requests the capability to export an Excel document showing the following: (1) all uploaded supporting documentation, (2) the plans to which they are attached, (3) and the HPMS user who uploaded the documents. We do extensive quality checks prior to bid submission of these documents and having the ability to check more than one plan’s uploads at one time will substantially improve the efficiency and accuracy of those checks.
Response: This comment is out of scope for this PRA package.
Comment: Currently, only the user that uploads the bid substantiation documents has the ability to delete them. There are circumstances that occur during upload, whereby substantiation documents are uploaded twice due to CMS system lags or user error. These duplicative substantiation uploads are identified during the health plans' QA process. After identifying the incorrectly uploaded documentation, it can be cumbersome to then identify the original uploader and have them reenter the site to delete the documentation. UHC proposes that CMS allow users the ability to delete substantiation documents that the user did not update themselves based on different levels of user access. There are circumstances that occur during upload, where substantiation documents are uploaded twice due to CMS system lags or user error. These duplicative substantiation uploads are identified during the health plans' QA process but can only be deleted by the user who originally uploaded the documentation. Allowing more than one user the ability to delete the duplicate documentation will help ensure the process is as seamless and efficient as possible. We also encourage CMS to consider allowing organizations to delete substantiation documents during rebate reallocation, instead submitting a list of documents to CMS to be deleted, similar to the process during the initial bid submission. This change would remove the administrative burden on CMS and drive greater efficiency and process consistency.
Response: This comment is out of scope for this PRA package.
Comment: As part of preparing Bid Pricing Tools (BPTs) for bid submission, they must be zipped into a single file that includes the .xlsx and .xml files associated with the BPT. Previously, BPT creation included a feature that zipped up the BPT .xlsx and .xml files so they were ready for uploading. For 2024 and 2025, that functionality was not available. UHC requests that CMS add back the feature that allowed plans to zip the BPT .xlsx and .xml files for uploading as this makes the uploading process faster for plans.
Response: This comment is out of scope for this PRA package.
Comment: Within the PBP-BPT Submission screen, the only way to check the date/time of plan submission is to hover over the "(i)"icon in the "Submit Plan" column for each plan individually. Currently, plans don't have the ability to extract submission timestamp information in report format. During bid submission we will sometimes submit a plan multiple times as we test the bid submission process or make updates to plans. Having access to reporting that indicates the date/time of submission would make it much easier to verify that the submitted PBP/BPTs align to the latest information. UHC requests the ability to extract submission timestamp information, currently shown in the "(i)", for all plans in a report format. We request a sortable column for “Submit Plan Date/Time”, similar to how the timestamps are displayed in the columns for “PBP Ready for Submission Date/Time” and “BPT Upload Date/Time.” Having access to reporting that indicates the date/time of submission will make it much easier to verify that the submitted PBP/BPTs align to the latest information.
Response: CMS will consider this enhancement.
Comment: PBP service area updates must currently be entered manually in the Set-Up Plans module. However, for benefit data entry, plans are able to utilize the API process which allows an organization to directly import data from an external source. We request the ability to send service area updates via API, versus data entry in the Set-Up Plans module. This would significantly reduce burden in the data entry process time and minimize data entry error risk.
Response: CMS will consider this enhancement.
Comment: When uploading a PBP via API, any validation error stops the entire upload and requires an organization to clear one error at a time. This set-up this slows the process and makes it difficult to triage issues with benefits that show up in multiple sections of the PBP. Therefore, when uploading an entire plan via the API UHC Requests the following: The API uploads all of the sub-sections that have no validation errors regardless of whether some sections do have validation errors.
The API upload results provide the validation errors for all subsections (e.g. Benefit Details, Benefit Offerings) that have an error.
The ability to upload only those select subsections of the PBP that need to be re-uploaded (e.g. Benefit Details, Benefit Offerings) instead of having to reupload all of the PBP subsections.
Response: CMS will consider this as a future enhancement.
Comment: Currently, to retrieve premium data from HPMS we have to: (1) download the report, (2) manipulate it, and then (3) reupload it to our own system. While maintaining the current "Review Plan Data Reports", we request the ability to send the premium data directly from HPMS to our system through the API.
Response: This comment is out of scope for this PRA package.
Comment: During the initial bid submissions, all of our plans exported successfully without any validation errors. When resubmitting the API for desk review updates, it became apparent that CMS had made changes to the API validation checks because the plans then presented unexpected validation errors. This seems to be a result of the fact that there is no process for CMS to notify health plans when there is a change to benefit validation checks in the API. UHC recommends CMS notify plans of any changes to benefit validation checks in the API as they are released, so that plans can proactively assess their impact to our JSON setup, rather than having to react to issues that are discovered the next time the gates open for resubmission.
Response: CMS will strive to notify plans when changes are made to the API validations.
Comment: The Out-of-Network (OON) Groups data in the PBP JSON does not indicate which OON Group's Number is assigned by benefit. Instead, it shows a string of numbers and letters that appear to be backend code versus the actual Group Number that shows in the PBP UI. UHC requests that the JSON show the OON Groups' Numbers by benefit as shown in the PBP UI. We use the JSONs to perform quality checks and providing this information would allow us to more efficiently and holistically verify that OON Groups' data is accurate.
Response: OON groups have been removed from the CY 2026 PBP.
Comment: For the PDP Demo Election, the status of a submission appears as a floating message box that lasts approximately 10 seconds after submitting and then vanishes. UHC recommends that CMS add a submission status field that does not disappear and shows (1) the time stamp for the last successful submission and (2) the user who submitted.
Response: CMS will investigate ways to enhance the PDP demo election data display.
Comment: When uploading a PBP via API, there are instance when the PBP "times out" and the upload does not complete. Other times, the API source indicates the process timed out, but in HPMS it shows that the process is complete. This results in an organization submitting a single PBP multiple times in order to ensure that it successfully processes. However, even taking that approach, it may show that the PBP failed when it actually processed successfully. This may be caused by the length of the HPMS processing time window being too short. If that is the case, we request that the processing time be extended to ensure successful completion of the process. We recognize that CMS communicated in December 2023, that there is a plan to allow this in CY2025. Please confirm that this will be addressed in CY2025.
Response: CMS will investigate ways to improve API processing and API processing times.
Comment: UHC uses the Sandbox environment to test the exports of our plans to HPMS. In preparation for the official bid submission of new plans, we would like the ability to be able to send those plans to HPMS in a test environment first to ensure the plans export without validation errors and the plan data sends as expected. Unfortunately, the current Sandbox environment does not allow us to create/add new plans to do this type of testing. Therefore, we request that CMS allow plans the ability to create/add new plans in the Sandbox environment, so we can test the API exporting of new plans before the official bid submission.
Response: CMS will be exploring this enhancement.
Comment: UHC asks that CMS consider the following additional changes to the PBP Modules:
We ask that the following functionalities be added to the 'Edit Plan Service Area' screen: (1) the ability to maximize the service area selection picklist windows and (2) the ability to sort the picklist alphabetically in addition to the current county code sort. Having this additional functionality will make it easier for plans to navigate, sort, and review the information to ensure accuracy.
In order to streamline the service area verification process, we request the capability to flip a county to "EGWP Only" within the SAR module, without removing all EGWP plans from the county. Having this functionality will make it more seamless for plans to make service area updates to plans.
We request the functionality to extract data across all contracts and plans for the "Plan Crosswalk" and "Verify Service Area" so that we can more efficiently and accurately conduct our reviews.
We request that the Medicare Plan Finder (MPF) and Medicare & You (M&Y) Handbook reviews be held a few weeks prior to rebate reallocation. The window for completion of the MPF and M&Y Handbook reviews and the rebates allocation is compressed and occurs simultaneously which can be challenging for the resources dedicated to the review of both of those activities. Changing the timeframe for review would give organizations more time and capacity necessary to better plan for the review of MPF and M&Y modules and it would also allow more time for the CMS team responsible for the modules to correct any issues reported by health plans during round one of the reviews.
UHC also appreciates the additional time CMS gave organizations to conduct the rebate reallocation review in 2024. The additional time allowed us to perform quality checks which in turn, help support stability and consistency in benefit design. We ask that CMS continue to give organizations at least 2-3 more business days to conduct this review due the growing number of plan counts and the increasingly complexity of the plan designs. When working in HPMS, we request the ability to have more than one browser window of HPMS open at any given time. Since PBP data entry, bid submission, and plan setup are all conducted in HPMS, users need the capability to open multiple windows of HPMS open simultaneously in order to enter data more efficiently.
Response:
CMS will consider this enhancement.
CMS will consider this enhancement.
Plan users can extract all service area data across all contracts in the Service Area Extract in the Data Extract Facility. CMS will investigate ways to make the plan crosswalk data available across contract numbers.
This comment is out of scope for this PRA package.
CMS does not permit the opening of multiple browser windows in an HPMS session, as it results in a security risk. We will research alternative approaches to make these data available in a single window.
Comment: During resubmission, the Benefit Details subsection reverts to "In Progress" status even when no changes have been made to the subsection and/or any API has been resent. There have also been instances when the Benefit Details subsection has reverted to "In Progress" several days after a resubmission. This change in status requires an organization to review all sections of the PBP on plans that haven’t had any in order to move the "In Progress" status back to "Completed." This additional review is a time-consuming process, particularly when organizations are trying to complete their updates during a short window of time. UHC asks that when CMS opens the gates for resubmission, subsections do not revert to an "In Progress" status unless the organization goes in and makes updates to those subsections, as appropriate, in response to CMS resubmission requests.
Response: CMS will review the bid statuses to determine if additional enhancements can be made.
Comment: In the 2025 PBP, the daily copays for prescriptions (Rx) are manually entered as part of the PBP setup. For the 2026 PBP, these values will be automatically calculated, and UHC seeks clarification on the following:
Question:
Will the daily copay values be rounded up, rounded down, or rounded to two decimals? UHC recommends CMS consider rounding down the daily copay values to mitigate the need for system changes.
Will plans be able to export these values, and if so, how? Having the ability to export the daily copay values helps plans efficiently validate what is loaded into their systems, and UHC recommends that CMS make these values are available in the PBP JSONs which organizations could then query to produce a table of values by plan.
Do plans need to check to see if the rounded daily copay times the number of days covered is less than the 1-month copay when adjudicating claims? With rounding or rounding up, it is possible that 29 times the daily value will be greater than the 1-month value. CMS’s guidance on this will help ensure consistent adjudication across carriers and allow organizations time in the event they need to make any changes to their systems.
Response:
I am sending this to EVEREST NOW.
Comment: The “PRA List of Changes” document provides a description of the proposed changes. However, the provided screenshots in the various “Appendix C” documents do not show the changes that are discussed in the “PRA List of Changes.” Humana requests that CMS provide updated screenshots of the changes so that plans can adequately begin prep work for the 2026 plan year.
Response: The screenshots identify where the updates will be made. Further detail comes further into the design and finalization of the requirements which often comes after we receive responses from our 60-day package. CMS also provides organizations the ability to visualize and test during the weeks leading up to the release of the module updates, thus providing organizations adequate time to begin their prep work for the upcoming plan year.
Question: For insulin products, we request clarification on whether plans can only list one of copay or coinsurance.
Response: Both a copay and a coinsurance must be entered in the Insulin data entry. This will be used to determine the cost sharing, which, beginning in CY 2026, is the lesser of a fixed copayment or a coinsurance percentage of the maximum fair price established under the Medicare Drug Price Negotiation Program, or the negotiated price under the prescription drug plan (PDP) or Medicare Advantage prescription drug (MA-PD) plan.
Question: Humana also requests additional clarification on whether plans have the flexibility to reduce one or both options. For example, can a plan list a cost sharing amount as “25% up to $25” or “15% up to $35” for insulin.
Response: Plans can reduce either the copay and/or the coinsurance as part of their Part D insulin data entry. As a reminder, the cost-sharing value cannot be greater than the initial coverage phase cost sharing for the given location/day supply.
Comment: CMS proposes the following change to the Medication Therapy Management Program Application submission: 2.b. Change "Individualized, written summary of CMR in CMS’ standardized format (includes beneficiary cover letter, recommended to-do list, and personal medication list)" to “Individualized, written summary of CMR in CMS’ standardized format (includes beneficiary cover letter, recommended to-do list, and medication action plan).”
Question: UHC requests CMS clarify whether the intent of the proposed change for the MTM Program Interventions Page is to align with change with the current CMR standardized format. If it is, UHC recommends the following change to align with the standardized format requirements: “Individualized, written summary of CMR in CMS’ standardized format (includes beneficiary cover letter, recommended to-do list and medication list).”
Response: This has been corrected in the list of changes document by replacing ‘medication list’ with ‘medication action plan’.
| File Type | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
| Author | KRISTY HOLTJE |
| File Modified | 0000-00-00 |
| File Created | 2025-05-19 |