New API Requirement for Behavioral Health Services

application programming interface api n.w
1 / 18
Embed
Share

Learn about the new API requirement for Behavioral Health Plans to provide beneficiaries digital access to their clinical records, the impact of the change, and how providers must adjust their processes. Get insights into the background, beneficiaries' access rights, data restrictions, and compliance requirements.

  • API
  • Behavioral Health
  • Clinical Records
  • Compliance
  • Digital Access

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Application Programming Interface (API) Quality Assurance Team (QA) Alameda County Behavioral Health Services (ACBH) Presented by: Torfeh Rejali, Division Director, Quality Assurance Camille Peterson, Information Systems Analyst Sue Louie, Interim Information Systems Manager October 25, 2023

  2. The purpose of this training is to inform and educate providers on a new requirement by the Department of Health Care Services (DHCS). Learning objectives: o Understand the background of the new API requirement. Learning Objectives o Understand beneficiaries records access rights. o Understand why & how health information should be restricted. o Articulate rationale for reviewable & unreviewable circumstances for restricted records. o Understand requirements to modify and monitor agency maintained EHR systems in compliance with API. 2

  3. Application Programming Interface (API): An Introduction In December of 2022, DCHS issued BHIN 22-068 announcing the requirement for Behavioral Health Plans (e.g., ACBH) to implement and maintain secure, standards-based Patient Access and Provider Directory Application Programming Interfaces (APIs). To comply with the Centers for Medicare and Medicaid Services (CMS) Interoperability and Patient Access final rule, Health Plans must maintain and allow beneficiaries and their legal representatives to have digital access to available clinical records for service dates on or after January 1, 2016. This rule affirms beneficiaries as the owners of their health information with the right to direct its transmission to third-party applications. 3

  4. API: What is changing? Current Process Beneficiaries or their legal representatives submit forms to obtain copies of their records. Providers have time to review the notes in advance of the release. Using clinical judgment, providers can redact notes that might cause significant harm to the beneficiary or another person. Records are released after review by the provider. New Process With the API roll out, beneficiaries will have on-demand access to their digital health records. For CG users, beneficiaries will be provided a unique log-in to the API which can access their records without submitting a formal request. For CG users, notes that might cause significant harm to the beneficiary or another person can be restricted using new functionality available on 10/26/23. Important Note: This change impacts digital health records contained in EHRs; paper chart procedures will remain the same. 4

  5. API: What is the impact? This change enables beneficiaries/legal representatives to digitally access their clinical record, including the following available information: o Beneficiary demographics/information, billing and claims, clinical notes (procedure note, progress note, consultation note, history and physical, discharge summary, assessments, care plans, treatment goals, problems lists), labs and other clinical data. ACBH s EHR (Clinician s Gateway), will be enhanced with new options for clinicians to restrict access to specified clinical notes, if needed. New procedures have been developed for processing beneficiary/legal representative requests to dispute the restriction. Providers using their own EHR are required to integrate similar software enhancements as well as develop similar procedures to manage records requests. 5

  6. DHCS Required Timelines and Deliverables March 1, 2024: Evidence of implementation of Patient Access API requirements to include the following: API Policy and Procedure document (to be developed by ACBH) Publicly accessible link or web URL where the Patient Access API Documentation is located Link to the BHP s publicly accessible member educational resources Quarterly deliverables starting Q2 2025 (Data for 4/1/2025-6/30/2025 will be due on July 31, 2025): Utilization metrics for the Patient Access API: o Total API pass and error rates o Count of Unique API Consumers making API requests o Count of Third-party Applications registered with the API Note: API memo can be found here. 6

  7. ACBH Approach ACBH has established a phased approach for this implementation. The first phase, starting in October 2023, includes provider communication and training as well as launch of a new Potential Harm field in Clinician s Gateway. Additional information will be shared at each phase, up to the launch of the API Patient Access in 2025, when beneficiaries will be provided with information and log-ins to access their records digitally. 7

  8. Providers using their own EHR If your agency does not utilize Clinician s Gateway, you will need to familiarize yourself with the new requirements and implement API Patient Access and reporting capabilities by the due date. Specifically, please make note of the following ACBH and DHCS requirements related to this initiative: Develop functionality to allow digital access to health records dating back to January 2016 Develop a procedure for restricting notes when needed Develop a process for tracking unique beneficiary/legal representatives making API requests Develop a process for completing and tracking beneficiary/legal representative requests for review of a note restriction Track the following Patient Access API metrics for quarterly reporting to ACBH and/or DHCS starting Q2 2025: Total API pass and error rates Count of Unique API beneficiary/legal representatives making API requests Count of Third-Party Applications registered with the API Count of beneficiary/legal representatives requesting review of a note restriction and outcome of those inquiries 8

  9. API: Restricting access to records Restricting access to records should be rare. Records can only be restricted in certain circumstances. Some restriction reasons allow beneficiaries to request a review of the restriction by another clinical staff member who was not involved in the initial decision to restrict the note. Please rely on your clinical judgment and use intra-agency consultation to determine if notes should be restricted. 9

  10. API: Allowable reasons for restricting a note Reviewable Circumstances A licensed healthcare professional has determined, in the exercise of professional judgment, that the access requested is reasonably likely to endanger the life or physical safety of the patient or another person. The protected health information makes reference to another person (e.g., family) and a licensed healthcare professional has determined, in the exercise of professional judgment, that the access requested is reasonably likely to cause substantial harm to the other person. A licensed health care professional must deny a parent/guardian access to a minor s mental health records if the minor has been removed from the parent/guardian s physical custody, absent a specific court order granting such access. 10

  11. API: Allowable reasons for restricting a note Unreviewable Circumstances The requested information is part of psychotherapy notes. The requested information is compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding. Access to the record would jeopardize the health, safety, custody or rehabilitation of beneficiary, other inmates, or the safety of any officer, employee or other person at the correctional institution or the transporting service. Access is denied while beneficiaries protected health information is used for research involving treatment by a health care provider. The restriction is temporary and was agreed upon as stated in the consent to participate in the study. Access will be reinstated at the completion of the research. The protected health information was obtained by someone other than a health care provider under a promise of confidentiality and access would be reasonably likely to reveal the source of the information or to cause substantial harm to the individual or another person. 11

  12. API: Process Management in ACBHs EHR Effective October 2023, Clinician s Gateway (CG) will be enhanced to include a field titled Potential Harm that will allow the author of a note to block its release by identifying the specific reason for restriction from a drop-down menu. Clinical supervisors within agencies may request permission to alter the Potential Harm Flag if the author of the note is no longer with the agency and the note needs to be restricted or unrestricted. These requests will be managed by the ACBH Information Systems team. 12

  13. Clinicians Gateway: Potential Harm Flag Information likely to endanger life/physical safety of beneficiary. Information likely to endanger life/physical safety of another person. Information relates to a third party and likely to cause substantial harm to the person. Information received in confidence and disclosure likely to reveal source of information. The Potential Harm Flag menu includes the following options: 13

  14. Before a note is finalized: The Potential Harm Flag may be added while in Edit mode. A required text field will be available to add a justification for the Potential Harm Flag. Clinician s Gateway: Potential Harm Flag 14

  15. After a note is finalized: The Potential Harm Flag may be added on the View Note screen. A required text field will be available to add a justification for the Potential Harm Flag. Clinician s Gateway: Potential Harm Flag 15

  16. If a note is flagged, it will not be accessible to the beneficiary or their representative. It is not possible to redact sections of a note. The Potential Harm Flag will make the entire note inaccessible to the beneficiary/representative via the Patient Access API. Clinician s Gateway: Potential Harm Flag 16

  17. Q&A Q&A 17

  18. For questions about the presentation, contact QATA@acgov.org. 18

More Related Content