Patient Access API
1. Question. Are impacted payers required to convert large unstructured documents like portable document formats (PDF) to Fast Healthcare Interoperability Resources (FHIR) to support the clinical data exchange requirements of the Patient Access API? In other words, are impacted payers required to convert documents to FHIR to identify clinical data elements that may or may not be present on a PDF or fax?
Response. Impacted payers (i.e., MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) are required to make claims, encounter and clinical data, including laboratory results1 available through the Patient Access API. CMS encourages impacted payers to make as much data available to patients as possible through the API to ensure patients have access to their data in a way that will be most valuable and meaningful to them. In the final rule, we said that the Patient Access API must meet the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule, the content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR § 423.160 and the United States Core Data for Interoperability (USCDI) version 1, also finalized by HHS (see citations below).2
Large documents, such as PDFs or a scan of a fax may or may not include data elements in the USCDI. CMS encourages payers to follow industry best practices to map data that a payer maintains as part of an enrollee's record as a discrete data element to USCDI data elements or a FHIR resource and make it available through the Patient Access API. However, CMS does not require payers to manually go through large files that cannot be parsed into data elements efficiently for the purposes of this API. The final rule did not require payers to include these large files as data available via the API.
2. Question. What is the requirement for impacted payers to maintain their data? Please clarify the intended meaning of the word “maintain.”
Response. The Interoperability and Patient Access final rule (CMS-9115-F) defines ‘‘maintain’’ to mean the impacted payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538). Payers are only required to make the data that they maintain in their systems available through the Patient Access API and for exchange with other payers. If a payer does not maintain clinical information for covered patients in its systems, the payer will not have to share clinical information through the Patient Access API or for exchange with other payers.3 As discussed in the final rule at 85 FR 25513, impacted payers must make available, through the Patient Access API, data they maintain with a date of service on or after 1 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242(b)(5); 42 CFR § 457.730; 42 CFR § 457.1233(d); and 45 CFR § 156.221. 42 CFR § 422.119(c)(3)(i); 42 CFR § 457.730(c)(3); 45 CFR § 156.221(c)(1); 45 CFR §§ 170.215; 45 CFR §§ 170.213 42 CFR §§ 422.119(h) and 438.242(b)(5); 45 CFR § 156.221(i)(1). January 1, 2016 forward for all current enrollees. Impacted payers must follow any other applicable federal or state laws regarding data retention requirements for records.
3. Question. Are impacted payers required to provide a single point of access for the member through the Patient Access API? May a payer require a patient to use multiple portals to access their data?
Response. In order to meet the requirements finalized for the Patient Access API, impacted payers are required to make all claims/encounter data, and clinical data they maintain available through a FHIR-based API.4 This FHIR-based API allows a third-party software application (“app”) of enrollees’ choosing to access the data easily. Payers can set up their APIs in a way that works best for their situations, but ultimately, the data must be available through an API that is conformant with the technical, content, and vocabulary standards adopted in the Interoperability and Patient Access final rule (CMS- 9115-F) and ONC 21st Century Cures Act final rule (45 CFR 170.213 and 170.215).
4. Question. CMS has suggested that industry consider using the CARIN for Blue Button Implementation Guide (IG) for the Patient Access API. The current version of the CARIN for Blue Button IG (STU 1 V1.0.0) 5 does not enable the inclusion of certain claims data (e.g. dental and vision claims). Will an impacted payer be considered compliant with the Patient Access API provision of the Interoperability and Patient Access final rule if it uses the suggested CARIN for BlueButton IG?
Response. Yes, from a technical perspective, if a payer uses the suggested IGs, and follows the IGs to specification to build their Patient Access API, the payer could be in compliance with the final rule (85 FR 25524). The Interoperability and Patient Access final rule requires that payers must make available adjudicated claims, encounters and clinical data that they maintain.6 The final rule does not preclude vision or dental claims. When an updated version of the suggested Implementation Guide for the Patient Access API (the CARIN for Blue Button IG) is available for use which enables inclusion of additional claim types, impacted payers may use the updated version.
4 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242.(b)(5); 42 CFR § 457.730; 42 CFR § 457.1233(d)(2); 45 CFR § 156.221.5 http://hl7.org/fhir/us/carin-bb/history.html 6 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242.(b)(5); 42 CFR §§ 457.730; 42 CFR § 457.1233(d)(2); 45 CFR § 156.221.
Payer-to-Payer Data Exchanges
5. Question. Does the final rule allow payers impacted by the payer-to-payer data exchange requirements to accept another payer’s requests for a payer-to-payer data exchange on behalf of a member? Can a health plan be considered the enrollee’s personal representative for the purpose of payer-to-payer data exchange?
Response. The requirement(s) for payer-to-payer exchange apply only to certain impacted payers: MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. There are currently scenarios where payers can exchange data without a request, such as for payment and health care operations,7 but the CMS Interoperability and Patient Access final rule (CMS-9115-F) imposes a requirement for certain impacted payers to send, at a current or former enrollee's request (or at the request of a personal representative), specific information they maintain with a date of service on or after January 1, 2016 to any other payer identified by the current enrollee or former enrollee.8 CMS noted in the final rule that when we discussed patients, we acknowledged a patient's personal representative.9 Per the Health Insurance Portability and Accountability Act (HIPAA) privacy regulations at 45 CFR § 164.502(g), a personal representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney). Policies in this final rule that require a patient's action could be addressed by a patient's personal representative. However, a health plan cannot be considered an enrollee’s personal representative.
Provider Directory API
6. Question. Are payers impacted by the Interoperability and Patient Access final rule (CMS- 9115-F) required to offer a public facing Provider Directory API? What information are they required to include through the Provider Directory API for in-network providers and contracted networks?
Response. MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies and CHIP managed care entities are required to offer a public facing
7 45 CFR § 164.512. 8 42 CFR § 422.119(f); 42 CFR § 422.119(h); 42 CFR § 438.62(b)(1)(vi); 42 CFR § 438.62(b)(1)(vii); 42 CFR § 457.1216; 45 § CFR 156.221(f); 45 CFR § 156.221(i). The requirement for payer-to-payer data exchanges in 42 CFR § 422.119(f), 42 CFR § 438.62(b)(1)(vi), and 45 § CFR 156.221(f) is conditioned on the approval and at the direction of a current or former enrollee or the enrollee’s personal representative. Similarly the regulations requiring that the Patient Access API be implemented and maintained explicitly address how the approval of the current patient (i.e., the beneficiary or enrollee) or the patient’s personal representative is required At 42 CFR §§ 422.119(a), 431.60(a), 457.730(a), and 45 CFR § 156.221(a). Provider Directory API which must include data on a payer’s network of contracted providers. Because QHP issuers on the FFEs at 45 CFR 156.221(i) were already required to make provider directory information available in a specified, machine-readable format, we did not require that QHP issuers would have to make provider directory information available through an API. Impacted payers, other than the QHP Issuers on the FFEs, must make certain information accessible through the Provider Directory API, including provider names, addresses, phone numbers, and specialties. Directory information must be available to current and prospective enrollees and the public within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information11. There are additional content requirements for the provider directory under the Medicaid and CHIP managed care program at 438.10(h)(1) and (2).
CMS does not specify how payers manage access to APIs for provider directories for providers managed through contracted networks. Therefore, payers may make appropriate business decisions for ensuring availability of the Provider Directory APIs, making them accessible, and providing information or links on the payer website to direct interested parties to those APIs.
The Provider Directory API must be publicly available and exclude 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 (see 85 FR 25543).
7. Question. What are the requirements for the Provider Directory API for Medicare Advantage organizations that offer Medicare Advantage Prescription Drug (MA-PD) plans, with respect to including the mix and number of pharmacies in their network?
Response. MA organizations that offer MA-PD plans must make available, at a minimum, pharmacy directory data and include the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”).12 In the Interoperability and Patient Access final rule (CMS-9115-F), CMS encouraged MA-PD plans to build a Provider Directory API that is conformant to the Health Level Seven International (HL7) PDex Plan-Net Implementation Guide (85 FR 25529).
10 42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3). 11 Id. 12 42 CFR § 422.119(b)(2).
8. Question. May a payer require the developer of a third-party application or the third-party application itself to register in order to use the Provider Directory API?
Response. No, a payer may not require the developer or the application that accesses the Provider Directory API (or its documentation) to register to use the Provider Directory API. The Provider Directory API endpoint must be made publicly accessible and payers subject to the Provider Directory API requirement must make that API publicly accessible. The API technical standards for the Provider Directory API exclude 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.13 In addition, payers must make sure that the API and its documentation are accessible via a public-facing digital endpoint on the payer's website.14 Specifically, the final rule requires payers make the Provider Directory API accessible via a public- facing digital endpoint on their website to ensure public discovery and access.15 Given this is generally publicly available information at this time, restrictions are not permitted. However, under the payer’s obligation to keep its systems secure under other rules, payers may put certain information behind an initial firewall in order to protect against a denial of service attack, much as they would currently protect data for any website. Otherwise this must be a truly public and unrestricted digital endpoint.
Compliance and Testing of the Required APIs
9. Question. Does CMS require certification to determine if a payer’s APIs comply with the
requirements of the Interoperability and Patient Access final rule?
Response. No, CMS does not require that payers certify their APIs as part of the requirements imposed on MA Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies, CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the FFEs. However, these impacted payers are required to conduct routine testing and monitoring, and update their systems as appropriate, to ensure the API functions properly, including conducting assessments to verify that the API is fully and successfully implementing privacy and security features such as those required to comply with HIPAA requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and 13 42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3) 14 42 CFR §42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3). 15 Id. other applicable laws protecting the privacy and security of individually identifiable data.
10. Question. Does CMS require that payers test their APIs? What testing tools should implementers use for the implementation guides suggested in the Interoperability and Patient Access final rule?
Response. The CMS Interoperability and Patient Access final rule requires impacted payers to conduct routine testing and monitoring of their APIs and to make updates as appropriate, to ensure the API functions properly.17
CMS recommends that impacted payers use the implementation guides and testing tools developed for use with FHIR APIs. The authoring organizations of the implementation guides, HL7 Da Vinci and the CARIN Alliance have chosen to use certain testing tools that are available on the HL7 Da Vinci Implementer website. For more information, visit that web page at: https://confluence.hl7.org/display/DVP/Da+Vinci+Implementer+Support
There are at least two different levels of testing that can be performed:
11. Question. How will CMS evaluate compliance with the provisions of the Interoperability and Patient Access final rule?
Response. Compliance with the provisions of the Interoperability and Patient Access final rule will be assessed in accordance with the oversight policies of each impacted program. The MA and Medicaid managed care programs each have programs in place to evaluate compliance of contracted entities. Issuers of QHPs on the FFEs will be evaluated through the annual QHP certification application process, and in the final rule we indicated that we would provide additional guidance to QHP issuers on how they would demonstrate compliance (85 FR 25553). Medicare Advantage plans will be evaluated using annual survey instruments. Similarly, the States will use their contract vehicle to complete assessments. Each program will provide information about evaluation mechanisms at a later date.
16 42 CFR §§ 422.119(c)(2); 422.120(a), 431.60(c)(2), 431.70(a); 438.242(b)(5) and (6), 457.730(c)(2), 457.760(a) and 457.1233(d); and 45 CFR § 156.221(c)(2).
12. Question. What resources are available for additional assistance with technical questions
related to the suggested implementation guides?
Response. CMS encouraged the use of certain HL7 FHIR Implementation Guides, and provided links to information and resources on our website. There are a number of implementer work groups in which impacted payers and their vendors may be interested in participating to support their project development and implementation plans. Technical questions may be addressed from these resources through the main HL7 Zulip chat stream (https://confluence.hl7.org/display/FHIR/Zulip+Streams) or to one of the HL7 Zulip chat links below based on the relevant IG.
• Plan Net/ Directory: https://chat.fhir.org/#narrow/stream/229922-
To obtain an account, visit the Zulip chat home page at: chat.fhir.org. For additional guidance, refer to the HL7 confluence site at: https://confluence.hl7.org/display/CAR/CMS+Patient+Access+API+%3A+Industry+Ques tions+and+CMS+Answers.
For testing questions and support: https://touchstone.aegis.net/touchstone/
Medical Loss Ratio (MLR) for Medicaid MCOs, MA Plans, and Issuers of QHPs on the Federally- Facilitated Exchanges
13. Question. Can implementation costs related to interoperability be classified as Quality Improvement Activity (QIA) expenses rather than administrative costs for purposes of MLR calculation?
Response. Yes, for QHP issuers on a Federally-Facilitated Exchange, if the criteria described in section 2718(a)(2) of the Public Health Service Act and its implementing regulations at 45 CFR part 158 are met, implementation costs related to interoperability may be classified as QIA expenses rather than administrative costs for purposes of MLR calculation. There are similar standards required for QIA treatment that are applicable to Medicaid Managed Care Plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8(e),18 CHIP managed care entities under 42 CFR 457.1203(f),19 MA organizations under 42 CFR 422.2430, and Part D sponsors under 42 CFR 423.2430.20 An entity’s MLR is generally calculated as the proportion of revenue spent on clinical services and QIA. There are specific criteria an expense must meet to qualify as a QIA expense, such as being designed to improve health quality and health outcomes through care coordination.
QHP issuers should work with their Plan Management contacts for additional information and to submit MLR reports. Medicaid managed care plans should work with their state partners to ensure expenses are accurately reflected in their MLR reports in accordance with their contractual requirements. Additional guidance regarding the MLR calculation and reporting requirements for MA organizations and Part D sponsors is available at: https://www.cms.gov/Medicare/Medicare-Advantage/Plan- Payment/MedicalLossRatio.html.
Missing Provider Digital Contact Information and Public Reporting
14. Question. Where will the list of providers who do not have digital contact information in
NPPES be posted?
Response. The list of providers who do not have digital contact information in NPPES will be available on data.cms.gov.
15. Question. How do I update digital contact information for multiple providers at the same time or in the same file as a bulk update in NPPES?
Response. CMS is developing an enhancement to the NPPES Electronic File Interchange (EFI) process that will allow for easier bulk updating of digital contact information in NPPES. As planned, this enhanced EFI process will allow only the digital contact information to be updated without impacting the rest of the provider’s record. CMS will not publicly report the list of providers who do not have digital contact information in NPPES until this enhanced bulk updating feature is available. Please watch the NPPES main page at https://nppes.cms.hhs.gov/ for more information on the enhancement and the reporting timeline. Expenditures for health care quality activities may be included in the MLR numerator if they are in at least one of three categories specified in 42 CFR § 438.8(e)(3), which includes expenditures that (i) meet the requirements of 45 CFR § 158.150(b) that are not excluded by 45 CFR § 158.150(c) or (ii) are related to Health Information Technology and meaningful use, meet the requirements placed on issuers found in 45 CFR § 158.151, and are not considered incurred claims, as defined in the regulation. CHIP managed care entities must calculate an MLR using the same standards as used for Medicaid managed care plans at 42 CFR § 438.8. The MA MLR regulations do not fully track or overlap the MLR requirements of the other programs for QIA so plans and organizations are strongly encouraged to review the MA regulation.
Admission, Discharge, and Transfer Patient Event Notification Conditions of Participation (CoP) (42 CFR 482.24(d), 482.61(f), and 485.638(d))
16. Question. What are the CoP requirements for the admission, discharge, and transfer (ADT) patient event notifications within the final rule?
Response. The patient event notification CoP requirement is limited to those hospitals, psychiatric hospitals, and critical access hospitals (CAH) that utilize electronic medical record systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2). However, conformance with this standard is only used to determine whether a facility will be evaluated under the CoP. Hospitals are not required to use a specific standard or technology to implement the electronic patient event notification required by the CoP. Hospitals subject to this rule may transmit patient event notifications using a range of approaches, including messages based on different versions of HL7 messaging standards, summary care records using the C-CDA standard, or making notification information available via a FHIR- based API (see 85 FR 25596 through 25597). CMS does note that a fax is not considered an electronic method of data exchange in this context. Please see page 25584 of the final rule for full details of the CoP.
The applicability date for the patient event notifications requirement is April 30, 2021. Compliance with this requirement will be assessed through established survey and certification procedures.
17. Question. Will CMS provide an extension for hospitals based on hardship for compliance with the patient event notification requirement?
Response. CMS will not provide hardship extensions for compliance with the patient event notification requirements for hospitals or CAHs. We note that the final rule was published on May 1, 2020.
18. Question. Can CMS elaborate on the intended goal of including the name of the treating practitioner in the minimum information that must be included in the notification pursuant to 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2)?
Response: The intended goal of including the name of the treating practitioner in the minimum information that must be included in an electronic notification is the facilitation of care coordination. We believe that including the name of the treating practitioner in the notification enables seamless, coordinated patient care. Existing patient event notification systems have demonstrated that a minimal set of information can achieve the desired effect of improving care coordination while imposing minimal burden on providers.
19. Question. What course of action should hospitals take if a patient has not yet been assigned to a treating physician at the time a patient event notification is required to be generated?
Response. In these instances (which we expect would only possibly occur upon initial registration in the emergency department [ED]), since the treating physician is not known at the time of issuance, hospitals would not need to include it in the notification.
20. Question. Is a patient event notification required when a patient is receiving services in the hospital’s emergency department and subsequently has their status changed to observation status?
Response. No. The preamble language in the final rule notes the following: “The revisions we are finalizing here would require a hospital’s system to send patient event notifications for patients who are registered in the ED, if applicable, and then also for patients admitted as inpatients, regardless if the patient was admitted from the ED, from an observation stay, or as a direct admission from home, from their practitioner’s office, or as a transfer from some other facility.” (85 FR 25592-93). Note that the hospital must send patient event notifications for patients registered in the ED, patients discharged from the ED, patients who are admitted, and patients who are discharged or transferred from the hospital’s inpatient services. Additionally, as noted in the preamble to the final rule, “However, while the requirements do not prohibit a hospital from electing to send a patient event notification when a patient is transferred to one inpatient services unit of the hospital to another, the requirements finalized in this rule are based on a change in the patient's status from outpatient to inpatient, and not necessarily on the physical location of the patient.” (85 FR 25593). To clarify, since a patient in the ED and a patient in observation are both considered to be outpatients (as they have not been admitted to the hospital as inpatients), there is no change in the patient’s status as an outpatient if the patient in the ED is then placed in observation. As per our discussion in the above example of an inpatient transferred from one inpatient services unit to another, the requirements here similarly do not prohibit a hospital from sending a patient event notification if a patient in the ED is subsequently placed in observation; however, such a notification is not required.
21. Question. How will CMS handle scenarios where a hospital can only record a patient’s primary care practitioner because their electronic health record (EHR) vendor has not provided a method to electronically capture any additional provider and/or group types?
Response. Under the requirements at 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5), a hospital (or CAH) that is compliant with the content exchange standard under 45 C.F.R. 170.205(d)(2) must demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes:
22. Question. Is there a timeframe that would qualify for compliance with the patient event notification requirements other than “immediate”? Is it acceptable to produce a single document daily for primary care practitioners that lists the admission, discharge, and transfer information from the previous day to limit the number of notifications that the physician receives and would provide a working report for the office staff so that they can schedule follow-up appointments as necessary?
Response. The Interoperability and Patient Access final rule requires at 42 CFR 482.24(d)(3) for hospitals, 482.61(f)(3) for psychiatric hospitals, and 485.638(d)(3) for CAHs, that if such hospital utilizes a compliant electronic medical records system or other electronic administrative system as discussed above, the system should send notifications directly, or through an intermediary that facilitates exchange of health information at the time of: (i) The patient's registration in the hospital's emergency department (if applicable) or (ii) The patient's admission to the hospital's inpatient services (if applicable). The final rule also requires at 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4), that if a hospital (or CAH) utilizes an electronic medical records system or other electronic administrative system, the system should send notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of: (i) The patient’s discharge or transfer from the hospital’s emergency department (if applicable) or (ii) The patient’s discharge or transfer from the hospital’s inpatient services (if applicable). We interpret “immediately” to be at the time of discharge or transfer and without any intentional delays. Further, at 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5), the rule requires that the hospital (or CAH) make a reasonable effort to ensure that the system sends the notifications to post-acute care services providers and suppliers, as well as to other practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes. The intent of this rule is to ensure that health information exchange is used to improve care coordination across settings, especially for patients at discharge, resulting in a reduction in readmissions, improved post-discharge transitions, and a reduction in the likelihood that a patient would face complications from inadequate follow-up care. As a result of this, and the cited regulatory provisions, hospitals are required to send the admission, discharge, and transfer notifications “at the time of” the patient’s admission or registration and “immediately prior to, or at the time of” the patient’s discharge or
transfer. Intentional delays in sending these notifications is not consistent with the regulatory requirement.
However, these requirements would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. Thus, in accordance with provider preferences, a hospital or intermediary would be permitted to group notifications for daily delivery if preferred.
23. Question. Are hospitals that have not fully adopted the use of an EHR system in all the healthcare services units, and are therefore utilizing a health record system that consists of paper records and electronic records, or hospitals that are currently migrating from one EHR system to another, required to comply with the patient event notification requirements?
Response. The applicability date for the patient event notifications, as required under the Interoperability and Patient Access final rule, is April 30, 2021. The provisions of this final rule require that a hospital, psychiatric hospital, or a CAH demonstrate compliance with all of the patient event notification requirements contained at 42 CFR 482.24(d), 482.61(f), and 485.638(d), respectively, only if it utilizes an electronic medical records system or other electronic administrative system that is conformant with the content exchange standard at 45 CFR 170.205(d)(2). If the hospital is not utilizing an electronic medical record system that is not yet conformant with the requirements in the final rule, CMS would not expect the hospital to meet the patient event notification requirements.
As we noted in the preamble to the final rule, we limited the applicability of this requirement to only those hospitals (and CAHs) that utilize electronic medical records systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals and CAHs have been eligible for past programs promoting adoption of EHR systems. Consistent with that is also our recognition, as expressed in the provisional clause regarding conformance with the content exchange standard, since not every hospital or CAH is at the exact same stage in its individual adoption and efficient use of EHR systems, the patient event notification requirements might not be applicable to such a hospital or CAH at this time.
24. Question. Patient privacy and consent—Are hospitals required to obtain patient consent to send a patient event notification? And will hospitals be able to honor a patient's request to opt-out of sharing information with providers in the form of a patient event notification and still be in compliance with the requirements if they do so? How should hospitals implement the required patient event notifications while still complying with other applicable state and federal laws and regulations around the transmission of sensitive data, particularly state laws and requirements on privacy and consent related to individuals treated in mental health facilities?
Response. Nothing in this rule should be construed to supersede a hospital’s compliance with HIPAA or other state or federal laws and regulations related to the privacy of patient information. We note that hospitals are not required to obtain patient consent for sending a patient event notification for treatment, care coordination, or quality improvement purposes as described in the final rule. However, we also recognize that it is important for hospitals to be able to honor patient preferences to not share their information. While the CoP would require hospitals to demonstrate that their systems can send patient event notifications, as we stated in the final rule, we do not intend to prevent a hospital from recording a patient's request to not share their information with another provider, and, where consistent with other laws, restrict the delivery of notifications as requested by the patient and consistent with the individual right to request restriction of uses and disclosures established in the HIPAA Privacy Rule. Similarly, if a hospital is working with an intermediary to deliver patient event notifications, the intermediary may record information about a patient's preferences for how they prefer their information is shared, and, where consistent with other laws, restrict the delivery of notifications accordingly. Regarding a patient's ability to request that his or her medical information (in the form of a patient event notification) not be shared with other providers and suppliers and/or practitioners, the requirements in the final rule explicitly state that a hospital (or CAH) must demonstrate that its notification system sends notifications, “to the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient's expressed privacy preferences.”
Nothing in these requirements should be construed as conflicting with a hospital’s ability to comply with laws and regulations restricting the sharing of sensitive information. While hospitals subject to the CoPs will need to demonstrate that their systems send notifications to appropriate recipients, hospitals would not be expected to share patient information through a notification unless they have obtained any consents necessary to comply with existing laws and regulations.
25. Question. How should hospitals address cases where they cannot confirm the identity of a provider, and/or where sending a patient event notification could risk improper disclosure of protected health information?
Response. Regarding improper disclosure of health information where a hospital cannot confirm the identity of a receiving provider, we note that under these requirements a hospital would not be under any obligation to send a patient event notification in such cases. Under our final rule, hospitals are required to make a “reasonable effort” to ensure their systems send notifications to the specified recipients. We believe this standard accounts for instances in which a hospital (or its intermediary) cannot identify an appropriate recipient for a patient event notification despite establishing processes for identifying recipients, and thus is unable to send a notification for a given patient.
26. Question. Can a hospital partner with an intermediary such as a health information exchange (HIE) to send notifications and delegate responsibility for identifying recipients to the intermediary?
Response. The final rule permits and encourages use of an intermediary such as an HIE that manages care relationships and routes notifications to the appropriate provider. The final rule discusses a variety of methods through which hospitals can identify recipients for patient notifications, including through partnering with intermediaries such as health information exchanges (84 FR 7652). We believe this is an important approach that hospitals are currently using to identify and route notifications to appropriate recipients, and that using an intermediary to complete these tasks may reduce operational burden for hospitals. Thus, hospitals are permitted to delegate responsibility for identifying recipients to an intermediary where applicable.
27. Question. Are hospitals, or an intermediary which a hospital is working with to deliver notifications, permitted to tailor the frequency or quantity of notifications in accordance with provider preferences?
Response. Yes, as noted in the final rule (85 FR 25598), under the requirement, hospital systems must send patient notifications in accordance with the requirements. However, this would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. For instance, if a specific provider prefers only to receive notifications upon discharge, nothing would prevent the hospital from limiting the notifications sent to that provider accordingly. Hospitals are encouraged to coordinate closely with receiving providers to ensure that the process is not burdensome and alerts are sent in a manner prioritizing the communication of clinically significant events and clinically significant data. Similarly, an intermediary may also support the hospital in developing a process that prioritizes communicating clinically significant events and data in a manner that does not disrupt the receiving providers’ workflows.
Proposed Rule on Interoperability and Improving Prior Authorization
28. Question. Can CMS provide a working link to the final rule, CMS-9123-F: Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients’ Electronic Access to Health Information?
Response. Per the memorandum from Ronald A. Klain, Assistant to the President and Chief of Staff, all regulations that have not been published in the Federal Register were withdrawn for review and approval by the Director of the Office of Management and Budget (OMB). CMS-9123-F was withdrawn consistent with this direction.
Copyright © 2021 HIKE HEALTH - All Rights Reserved.