Overview
The ASCMI, or “Authorization to Share Confidential Member Information”, acts as a multi-provider authorization to release information document. This form was developed by the California Department of Health Care Services (DHCS) to improve the coordination between agencies and providers that work with the same Medi-Cal member. This form is part of a larger initiative where DHCS can manage these releases so providers working with a beneficiary can search to see if an ASCMI is on file for the beneficiary, and if so, what type of information the beneficiary agrees with providers sharing amongst themselves. More information can be found on DHCS’s website: https://www.dhcs.ca.gov/CalAIM/Pages/ASCMI-CalAIM.aspx.
This website is also where you can find the ASCMI forms. There are three different documents:
- ASCMI AB-133: Only valid for Medi-Cal beneficiaries
- ASCMI Non-AB 133: Valid for all Californians, regardless of insurance coverage
- ASCMI Revocation Form: Used to revoke the existing ASCMI and change all sharing agreements to “do not share.”
The ASCMI AB-133 and ASCMI Non-AB 133 meet all requirements to act as an authorization to release information, otherwise known as a Release of Information (ROI), for both HIPAA and 42 CFR Part 2. Medi-Cal beneficiaries should complete the ASCMI, even if they choose not to share any information. That way, a new provider can find this record on DHCS’s database and see that an ASCMI is on file and know the beneficiary’s choice for disclosures.
ASCMI v. Coordinated Care Consent
The Coordinated Care Consent (CCC) was a document created by CalMHSA to mirror the draft ASCMI that DHCS was developing. The CCC acted as a type of beta-version of the ASCMI and was used in SmartCare from 2023 through 2026. Once the DHCS ASCMI form was finalized, CalMHSA began work on implementing the ASCMI in SmartCare to replace the Coordinated Care Consent.
Both documents serve a similar function, though the CCC is limited to only providers who had access to that specific SmartCare environment. The ASCMI goes beyond that, and includes providers who do not have access to SmartCare. The ASCMI will also have more impact to interoperability initiatives, as this will dictate what can be shared between EHRs.
Once the ASCMI is fully implemented, the Coordinated Care Consent will be deactivated. Historical documents will still be available, and active Coordinated Care Consents will still govern in-SmartCare sharing until a new ASCMI is created for that client.
Implementation Plan
CalMHSA has been meeting with DHCS and CalMHSA’s legal team at Manatt to determine how to best implement this initiative. It was decided that CalMHSA will implement the ASCMI Non-AB 133 version, as this can be used for any Californian and will minimize confusion regarding which form to use.
The first phase of this project will be to create the ASCMI Non-AB 133 document in SmartCare. This phase includes triggering CDAG functionality based on whether the client agrees to share SUD information or not (if client consents to SUD sharing, CDAG rules will be deactivated for that client). This document will replace the Coordinated Care Consent, which will be deactivated when the ASCMI is activated in SmartCare. The go-live date for this phase is TBD.
Subsequent phases will address different aspects of improving the ASCMI. Currently identified phases include, in no particular order:
- Multi-Language Support
- Revocation
- Interoperability
- Consent Management Platform (CMP)
- Improving Consent Functionality
Multi-Language Support
DHCS has provided the ASCMI documents in multiple languages. CalMHSA is working with Streamline to address this need, with the aim to select the language on the ASCMI document itself, rather than creating multiple ASCMI documents. Spanish will be the first language addressed, though more plan to be added as Streamline functionality improves the ability to utilize non-Roman characters in SmartCare.
Before this phase is implemented, CalMHSA recommends that counties use the DHCS PDF forms in the appropriate language with the client. The PDF can then be uploaded to SmartCare and associated with the SmartCare version of the ASCMI. Counties should still enter the client’s responses in SmartCare, as this will be important for CDAG and interoperability functionality. See How to Attach a Signed Paper Document to the Digital SmartCare Document for details on this process.
Revocation
CalMHSA will create the ASCMI Revocation Form in SmartCare. This will function much like the other “Revoke ROI” and “Revoke Consent” documents core to SmartCare. Part of this phase will include ensuring that it’s clear to end users when an ASCMI has been revoked or superseded by another ASCMI.
Before this phase is implemented, CalMHSA recommends that counties simply create a new ASCMI whenever the client wants to revoke their existing ASCMI. Each subsequent ASCMI will supersede the previous ASCMI, so if the newest ASCMI indicates the client has declined to share any types of data, that is the same as using the revocation form.
Interoperability
CalMHSA continues to work on tagging documents to limit sharing of 42 CFR Part 2 information outside of SmartCare. While CDAG works well within SmartCare, most other EHRs do not have a comparable system. This has been an ongoing effort that will continue with this ASCMI project.
Consent Management Platform (CMP)
DHCS is working on developing a database where ASCMI information can be stored, a consent management platform, or CMP. CalMHSA will work with DHCS to ensure SmartCare can connect to this platform so users can both submit ASCMI information to the CMP and retrieve information from the CMP. This phase is reliant on DHCS’s development timeline.
Before this phase is implemented, the ASCMI data can still be collected. If, for example, a client completes an ASCMI in SmartCare in March 2026, then when this phase is eventually implemented, SmartCare can upload that March 2026 ASCMI into the CMP. This will help pre-populate DHCS’s database, meaning when other care partners query the CMP on a client, they may find an ASCMI on file and begin to exchange information with BHPs immediately.
Improving Consent Functionality
CalMHSA is working with Streamline to address some issues counties have encountered with different legal documents in SmartCare. Examples include, but are not limited to:
- Not being able to back-date a client’s signature when denoting they’ve signed on paper or verbally agreed
- Making it clearer to end users whether a consent has been revoked, ended, or superseded
- Making it clearer to end users whether a consent is valid or not (e.g. signed by the client and/or guardian)
- Ensuring historical data, such as original expiration date, is maintained, even when a revocation changes the expiration date
- Reverting to older, still valid consents when the most recent consent is errored or deleted
CalMHSA is wanting to apply these fixes to all consent and ROI document types in SmartCare, which includes the ASCMI. This may be a longer-term goal, depending on the level of effort needed.
Before this phase is implemented, CalMHSA recommends that end users be trained how to clearly identify whether a consent is valid and be diligent when sharing information based on an ROI.
Related Articles
Training
CalMHSA is hosting two trainings regarding the ASCMI. One will be led by the law firm Manatt, and is focused on questions about the ASCMI itself. The second training will be led by CalMHSA staff and is focused on SmartCare implementation of the ASCMI.
- Event 1: Ask Me About ASCMI – Understanding Legal Requirements for BHPs
- Description: During this webinar, a legal expert from Manatt will walk through the state’s ASCMI Form, explaining its purpose, legal requirements, and real-world implications. We will discuss key implications for care coordination and information sharing and address questions submitted by counties.
- Event 2: Ask Me About ASCMI Part II – SmartCare Workflows
- Description:Intended as follow-up to our first ASCMI session, this training will walk through the ASCMI form in SmartCare, including step-by-step guidance on completion, workflow recommendations, and implementation considerations.
This session is intended for staff responsible for system configuration, quality oversight, training, and project implementation related to ASCMI.
- Description:Intended as follow-up to our first ASCMI session, this training will walk through the ASCMI form in SmartCare, including step-by-step guidance on completion, workflow recommendations, and implementation considerations.
- Click here to access the ASCMI Form Webinars
Translating ASCMI into SmartCare
As part of this project, CalMHSA has attempted to maintain the ASCMI format and language impeccably. Due to some system implementation requirements, there are a few changes that should be mentioned.
Organization Name
Throughout the ASCMI form, there are fields for the Organization Name of the Care Partner. This field can be found in the middle of sentences on pages 1 and 3 of the PDF. Since these should all be the same Organization Name, and to address limitations of having text fields in the middle of sentences, CalMHSA has created an Organization Name field at the very top of the SmartCare ASCMI document. This field will auto populate the County Name (Agency Name) from the Agency Table of SmartCare.
To address concerns that ASCMIs completed on paper may not use the exact naming convention, or even use the exact agency, as what is in the Agency Table, this field is editable. This will allow users to mirror what was entered on the paper/PDF form exactly in SmartCare. For example, an ASCMI done on paper by a contracted community-based organization (CBO) may enter their CBH name in this field. SmartCare will allow a user to enter that CBO name in the Organization Name field.
Client Information
This section will auto populate data from the Client Information screen. However, most fields are editable. This is to more easily allow a user to mirror what’s on the paper version, if the client has signed a paper copy. This will also allow a user to enter the client’s accurate information without slowing down the ASCMI process to make updates to the Client Information screen.
The Medi-Cal Client Index Number is included, as discussions with DHCS indicate that they plan to update the ASCMI Non-AB 133 form to include this data point.
The address fields are separated into Street, City, State, and Zip Code fields, as this is how addresses are generally stored in EHRs. The PDF concatenates these into a single line to match the DHCS PDF version.
Care Partner Information
This section will auto populate some data, including the Organization Name and the author’s name as the Care Partner Name.
There has been some debate about whether to enter the person’s information or the organization’s (e.g. NPI, phone number). CalMHSA recommends the organization’s information. There is currently not definitive guidance from DHCS on what should be entered here, and either seems to be acceptable.
Since most users won’t actually know the NPI or TIN of either the author or the organization, CalMHSA has added some helpful tool tips in SmartCare. Hovering over the NPI Information or TIN Information help icons will provide the user with the NPI/TIN of the document author, the program associated with the document, and the county (from the agency table). If the program NPI/TIN is not available, the user should save the document and re-hover.
Other fields, such as address and phone number, must be completed manually at this time.
Permission to Contact Via Text or Phone Call
For this question, Streamline ran into some limitations of formatting. For this reason, options here look different than they do on the DHCS version. The values are all the same, but please note this when doing data entry of an ASCMI that was completed on paper/PDF.
Signature Block
The Signature Block isn’t needed on the data entry screen, as the signature occurs by clicking the “Sign” button. The signature block may therefore look slightly different on the SmartCare version than on the DHCS PDF, but the data points (name, signature, and date of signature) will all still be present.
Footnotes
Footnotes don’t work well on a data entry screen, as the screen is just a single entity rather than separate pages. This is also difficult to do on the PDF in SmartCare. To address this issue, footnotes are added to the end of the sections in the data entry screen, and to the last page of the PDF.
General Format
Streamline couldn’t match all the exact formatting and colors of the DHCS form, but tried to make it match as much as possible. The PDF will render in 14-point font to meet ROI requirements. The header and footer of the SmartCare version matches the DHCS version with the exception of the addition of some client identifiers. This was something discussed with DHCS, who recommended this addition to ensure pages are not separated from each other.
Related Screens and Setup
Documents and Screens:
ASCMI Non-AB 133 (documentcodeid = 60409; screenid = 62996)
User roles that have read-write access:
- CalMHSA Sys Admin
- County Affiliate Sys Admin
- LPHA-Clinician
- Non-LPHA
- Medical Records/Quality Assurance
- Reception/Front Desk
- Pharmacist
- Patient Portal User
- Parent/Guardian Patient Portal User
- Contractor, No Rates
- Contractor, Full Permissions
User roles that have read-only access:
- Auditor/Read-Only
- Billing
User roles that have permission to delete this document:
- CalMHSA Sys Admin
- County Affiliate Sys Admin
Configuration Keys and Recodes:
Recode Category “DocumentsToBeConsideredForCDAGRuleBasedOnConsentFlag” – set to include both Coordinated Care Consent (Integer Code Id = 60133) and ASCMI (Integer Code Id = 60422)
Recode Category “XASCMIMailingAddressType” should be set to Mailing Address (Integer Code Id = 11134348)
Note: read-write access includes permissions for “Document Codes (Edit)”, “Document Codes (View)”, “Screens”, and “Screen (New Mode): Delete” whereas read-only access includes permissions for “Document Codes (View)” and “Screens” only.