DASH CalAIM Authorization & Billing

Project Description
Project Features
Project Process
Project Design and User Experience
Data Concerns
Key Performance Indicators (KPIs) to Benchmark
Workflow
Figure 1: Workflow – DASH 2.0
Innovative Technologies or Processes
DASH 2.0 Data and process Improvements
Client Profile
Technology Stack & Development Approach
Platform
Data Processing
API Integration
System Screenshots
Figure 2: Client Profile
Figure 3: Generate Authorizations
Figure 4: List Authorizations with Status
Figure 5: Authorization Request Management
Figure 6: Authorization Request – Select All to Submit
Figure 7: Authorization Request – Download Request Submissions
Figure 8: Authorization Request- Import Authorization Data
Figure 9 – Authorization Request Dashboard
Figure 10 – Authorization Request Dashboard with Stats

Project Description

California’s Department of Healthcare Services (DHCS), through its California Advancing and Innovating Medi-Cal (CalAIM) model, is implementing delivery system, program, and payment reforms across the Medi-Cal Program. CalAIM establishes the framework to address social determinants of health and improve health equity statewide.

A key feature of the CalAIM model is the introduction of a menu of Community Support Services in managed care. Community Support Services are services or settings that managed care plans (MCPs) may offer in place of services or settings covered under the California Medicaid State Plan and that are medically appropriate, cost-effective alternatives to a State Plan covered service.

To accommodate this CalAIM initiative, Alameda County Health Care Agency (ACH) via Housing and Homelessness Services (HnH), have charged the County’s Information Technology Department (ITD) with designing and developing a system that augments the authorization and billing processes for several programs administered within ACH.

This system has come to be known as Database Access for SHIE and HMIS (or DASH).

(SHIE is the Alameda County Social Health Information Exchange and HMIS stands for Homeless Management Information System).

For Phase 1 of this project, the Information Technology Department implemented a custom application built on the Salesforce Platform that automated the CalAIM billing for the four programs that were enrolled. This included designing a series of data ingestions from a variety of disparate data sources, bringing the data together, and implementing complex business logic to determine how to and who to bill for the services, and finally delivering the invoice files to the contracted Health Plan Providers.

For Phase 2 of this project, the Information Technology Department has implemented an Authorization Module, which will allow Housing and Homelessness Services to perform all their client authorizations within DASH. Previously, this data existed in a variety of spreadsheets, maintained separately, including from the Health Plan Providers. Prior to this phase, the billing process was not aware of the authorization status of any clients with the Health Plan Providers, which is a requirement prior to billing for services, so this would lead to erroneous claims and subsequent rejections. Since deployment of Phase 2 and the merging of billing and authorizations, billing claims are now held back until a valid authorization is detected.

With the implementation of Phase 2, DASH has now become the system of record for billing and authorizations.

Some of the key features that DASH provides that were not available prior are:

User-friendly modern web Interface
SSO Integration with Alameda County’s Azure AD
100% Accessible
Mobile Friendly
Easy access to all historic data in a single location
One location to view all client information
Dashboarding and Reporting Capabilities

Project Features

Accessibility (ADA Compliance)
Single Sign On (SSO)
User-Based Experience (Personalization)
Third Party API Integration

Project Process

For the initial Phase 1 implementation of DASH, the primary objective was to automate the billing process. This was in part to remove the laborious manual procedures that were in place, improve accuracy and efficiency, but also to provide a single system that could be used to report on this data. Previously, when the billing/invoice files were sent, there was no historical record, other than the files themselves. This made reporting extremely difficult, manual and time intensive. As part of the implementation, while the primary objective was to generate the billing files, it was also important that the system be able to handle any future requirements, including mandated reporting.

That a large portion of the required reporting was able to be generated out of DASH after Phase 1, was testament to this.

Since this CalAIM requirement was a very new initiative, and the requirements were not known up-front, ITD used an agile, iterative approach to development. In this way, clients were involved very early on in the design process. ITD very quickly provided prototypes for the clients to view for approval, and once approved select users were given access to a development environment with representative sample data. This allowed users to provide feedback very early on in the design process.

After going live with Phase 1, the existing manual process continued generating billing output for some time afterwards, which allowed the staff to verify that the output from DASH was what they were expecting. Not long after Phase 1 deployment, the manual process was decommissioned, and has not been used since.

Project Design and User Experience

DASH was built on the Salesforce Platform, which ITD and ACH use extensively as development platforms. ITD has built numerous applications on the platform for ACH, all maintaining a familiar look and feel for the users of the systems.

ITD uses standard platform functionality wherever possible, adhering to ADA Accessibility and core UI/UX standards. When required to develop custom user interfaces on the platform, ITD maintains the UI/UX standards with the use of the Salesforce Lightning Design System (SLDS) and integrates via the Lightning Component Library wherever possible.

A core part of the implementation is for ITD to provide training to both staff and administrators so that they are comfortable in the system, whether they are new to the platform or not.

Data Concerns

The data necessary for DASH to function exists in a variety of external systems and databases.

HMIS: The primary data source for the Service Providers entering Community Service Data is HMIS. Program Enrollment Data is also stored here.
Managed Care Plan Enrollment: MCP Enrollment Information (who is enrolled in which health plan) is stored in the SHIE.
Authorization Data: Authorization information is maintained by the MCP’s and by ACH staff.
Prior Authorization: Clients must be authorized with the MCPs prior to billing for services. The county is penalized for sending erroneous claims, so services are “held” until the authorizations are verified offline. In order to fix this process, DASH needs to have a full picture of client authorizations and become the system of record.
Authorization Request Automation: The determination of when to generate an authorization request was manual, through Excel spreadsheets, with mostly undefined business logic. DASH should be able to determine when an Authorization Request can be created, and when it cannot (defer to staff).
Authorization Request Submissions: DASH should be able to generate the Authorization Request Submission File in the format expected by the MCPs.
Authorization Request Determinations: The determinations (Approved, Denied) are supplied to ACH via a spreadsheet. A facility should be included to easily load these determinations into DASH and merge with the existing data.
Generate Authorization Submission Files for the Alliance: The excel files that are required by the Alliance for Authorization Requests are now generated out of DASH. Previously these had to be manually constructed.

For DASH 1.0, the HMIS and MCP Enrollment data was provided to DASH by ACH via flat file delivery on SFTP, extracted by Python Scripts.

For DASH 2.0, we wanted to remove the flat file process, and instead store the data required by DASH in a central repository.

While not visible to the ACH staff, we considered this a significant improvement that was delivered by DASH 2.0

Key performance indicators (KPIs) to benchmark

For DASH Phase 1, the primary performance indicators were 1) the number of services that were able to be submitted 2) the dollar amount for services that were successfully submitted and reimbursed 2) the number or services that were rejected.

Since the Phase 1 DASH implementation, more than 56,000 services have been submitted for reimbursement to the Health Care Providers. Prior to DASH, there were a little over 29,000 services submitted for reimbursement.

Since the Phase 1 DASH implementation, nearly $2,800,000 has been successfully reimbursed from Health Care Providers, versus just over $1,000,000 prior to DASH.

Since the DASH rollout, a new service provider has been added to the providers that are services by the billing portion of DASH. With minimal configuration, this new service provider was able to be onboarded and ACH are now able to bill the Health Care Providers on this provider’s behalf.

Key accomplishments in Phase 1 included:

Custom Salesforce Application Development: A tailored application was built on the Salesforce platform to manage billing operations.
Data Ingestion and Integration: The system processed data from multiple sources, applying complex business logic to determine billable services and recipients.
Invoice Automation: DASH automatically generated and delivered invoice files to contracted Health Plan Providers.
Enhanced Reporting Capabilities: Historical data was centralized, enabling streamlined reporting and analytics.

Since implementation, Phase 1 has yielded substantial improvements:

Over 56,000 services submitted for reimbursement, compared to 29,000 pre-DASH.
Nearly $2.8 million reimbursed, up from $1 million before DASH.
Onboarding of new service providers with minimal configuration.

For DASH Phase 2, the primary performance indicator will be to reduce the increase the number of claims that can be reimbursed, while reducing the number of claims that are rejected due to missing authorization.

It is too early in Phase 2 implementation to report on these metrics, but indications are that having all the data available in a single system is uncovering data discrepancies that would otherwise have gone unnoticed.

Phase 2 introduced a dedicated Authorization Module to centralize and automate client authorization processes. Prior to this, authorization data was dispersed across multiple spreadsheets and lacked integration with billing operations, leading to erroneous claims and frequent rejections.

Key achievements in Phase 2 include:

Consolidation of Client Authorization Data: DASH now serves as the system of record for both billing and authorizations.
Validation of Billing Claims Against Authorizations: Claims are now held back until a valid authorization is detected, reducing rejections.
Enhanced Data Visibility: The new system provides a single, comprehensive view of client information.

Workflow

Figure 1: Workflow – DASH 2.0

Figure-1: Workflow DASH 2.0

Innovative Technologies or Processes

The core application was built on the Salesforce Platform, utilizing low-code development technologies together with custom development on Apex and Lightning Web Components.

The system is reliant on external data to generate billing files and verify authorizations. This data was processed and transformed using a variety of technologies, such as Python, Java, SSIS and other tooling.

The data was ingested into Salesforce using REST APIs.

DASH 2.0 Data and process Improvements

DASH 2.0 included significant improvements in data management over the previous 1.0 release.

Authorizations: All historic authorization data loads were loaded into DASH as part of the 2.0 release. There is also now a weekly load of the authorization determination file from Alameda Alliance.
Program Enrollments: Program enrollment data is now loaded nightly from SHIE (via HMIS).
Automated Authorization Request Generation: DASH can now determine if a new authorization request can be automatically generated
Ability to manually generate Authorization Requests: DASH can manually create authorization requests when needed.
Ability to load Authorization Request Determinations from Auth Status File: The Alliance delivers an Auth Status File periodically to update the status of the submitted Authorization Requests. A component was added to allow this file to be loaded into DASH.
Provide analytics to track where manual intervention is required: DASH has several dashboards where staff can monitor authorizations and client status.

Client Profile

The Client Profile in DASH now contains a much more complete picture of the client.

Program Enrollments: This is a component containing two tabs; one with active program enrollments, and another with all historic program enrollments.
Authorizations: This is a related list showing the authorization history for this client.
Outreach Attempts: List of Outreach Attempts are those that were billed are now on the profile.
Technology

Technology Stack & Development Approach

DASH leverages a combination of low-code and custom development technologies:

Platform: Salesforce (Lightning Web Components, Apex)
Data Processing: Python, Java, SSIS
API Integration: REST APIs for seamless data ingestion

Development was conducted using an agile, iterative approach, ensuring continuous stakeholder involvement and rapid feedback cycles. Early user testing and parallel manual processing allowed validation before full system deployment.