Clinical Management for Behavioral Health Services (CMBHS) Mental Health Implementation

Project Update Presented May 17, 2013

AGENDA

1. Introductions and review of our agenda items (Chris)

2. Review “Attestation” (Steve)

3. Update on provider testing progress (Chris)

4. Provider testing beyond July 3, 2013 (Chris)

5. Review revised migration strategy (Chris)

6. Review pros and cons of reloading the batch test environment (Chris)

7. Review batch reports (Chris)

8. Address issues raised at the Policy Work Group meeting on May 15, 2013 (Dana & Chris)

9. Review issues from Mike’s email (Dana & Chris)

2

Attestation

By my signature, I represent that my organization has successfully completed all applicable batch testing scenarios provided by the Department of State Health Services for the Child and Adolescent uniform assessment for mental health services as indicated on the attached CAUA Testing worksheet.

I acknowledge that the testing may not have included all possible data permutation and combinations. My organization bears responsibility for submitting properly formatted and accurate data into DSHS-specified information systems, consistent with applicable DSHS contract requirements.

3

Update on provider testing progress

4

Number of Providers setup to UAT

Number of Providers that have sent CANS data

Percentage of Providers that have sent CANS data

Number of Providers that have sent CANS Attestation

Percentage of Providers that have sent CANS Attestation

36 24 67% 9 25%

Number of Providers setup to UAT

Number of Providers that have sent ANSA data

Percentage of Providers that have sent ANSA data

Number of Providers that have sent ANSA Attestation

Percentage of Providers that have sent ANSA Attestation

36 0 0% 0 0%

#providers Sent Test File Completed AttestationAnasazi 21 10 5

47.62% 23.81%

CoCentrix 10 6 060.00% 0.00%

Iserv 6 6 5100.00% 83.33%

Unknown 2 2 1Total 39 24 11

61.54% 28.21%

Provider testing beyond July 3, 2013

• The LMHA’s and NorthSTAR SPN’s may continue testing in the existing CMBHS/CARE Data Exchange Test Environment from July 4, 2013 through August 9, 2013 with the understanding that DSHS and HHSC will not be available for support (phone calls, emails, FTP setup, etc.)

• DSHS will give the LMHA’s and NS SPNs a two day notice if they need to refresh the CMBHS/CARE Data Exchange Test Environment with production data between July 4, 2013 and August 9, 2013.

• The IMC will identify one LMHA that will be completed with their batch testing on or before July 3, 2013. DSHS and HHSC will use that LMHA to test synchronization of data between CMBHS and CARE.

• Value options will identify one NS SPN that will be completed with their batch testing on or before July 3, 2013. DSHS and HHSC will use that NS SPN to test synchronization of data between CMBHS and CARE.

• DSHS and HHSC will also use the LMHA’s and NS SPN’s that plan on entering assessment data online to test synchronization of data between CMBHS and CARE.

5

Migration strategy

Data will be migrated from CARE to CMBHS in two steps:

1. The Client Profile and Diagnosis data in CARE as of 08/30/2013 will be migrated into CMBHS by 09/02/2013.• The daily data synch process (including NorthSTAR) between CMBHS and CARE will

be initiated for Client Profile and Diagnosis at this time.

2. The RDM assessment data in CARE as of 09/06/2013 will be migrated into CMBHS by 09/09/2013.

6

Migration strategy

The RDM assessment function will be disabled in CARE after the final batch process runs at 6:00 pm on 09/06/2013.

• CARE system will block assessments dated 09/01/2013 and later for both batch and online.

• This date was chosen by the CMBHS Policy Work Group/Data Systems Work Group to allow providers time to submit their batches after the holidays and to correct batch errors.

• Providers will be able to enter or correct RDM assessment data in CARE until the function is disabled.

• There will be no opportunity to enter or correct RDM assessments in CARE after the function is disabled.

7

Migration strategy

8

Migration Timeline

9

30 31 1 2 3 4 5 6 7 8 9

F S S M T W T F S S M

CARE Batch Processing Starts at 6pmCARE Batch Processing Ends and CARE ODS Loaded by 8amCMBHS Migrates Organizations, Client Profile and Diagnosis Records from CAREODSNorthSTAR SPNs start batching Client Profile, Diagnosis, Financial Eligibility and FE Attachments to CMBHS CMBHS and CARE internal syncronization of onine changes startsCMBHS starts processing Client Profile and Diagnosis records batched to CARECARE Blocks RDM Assessment with Assessment Date > 8/31/2013

Providers batch and correct RDM Assessments with Assessment Date < 9/01/2013 in CARELast Batch of RDM records to CARE - note, will not be able to correct any errors in this batch CARE Batch Processing Starts at 6pm CARE Batch Processing Ends and CARE ODS Loaded by 8am

CMBHS Migrates Read Only RDM Assessments and Open Assessments/AuthorizationsLMHA's and NorthSTAR SPNs first batch of TRR Assessments to CMBHS

CMBHS Migration Timeline

SeptemberAugust

\Pros and cons of reloading the batch test environment

Pros:Providers:

a. More adult and child clients with recent assessments to test with

b. Providers can synch their local test system with data for the same date CMBHS and CARE uses to migrate production data

c. Providers can retest the issues identified with the initial migration

d. Higher level of confidence that migration is solid

e. Another opportunity for the security administrator to practice setting up locations and users

CMBHS:a. New DBA will get a practice run of migrating data from CARE

b. Higher level of confidence that migration is solid

c. CMBHS Data Exchange Team will not have to intervene to correct migrated data

Cons:Providers:

a. The providers, locations and staffs have to be set up again.

b. All the test data so far is nuked

c. Script Failure

CMBHS:a. CMBHS IT cannot provide a date for refresh

•Recommend migrating production data after CARE batch processing on May 24, 2013

10

Review Batch Reports

Batch File Acknowledgement Detail Report

This report provides an audit trail of batch transactions sent. When CMBHS receives a batch file, it will acknowledge the receipt by sending this detail report. The report will list each transaction in the batch file that was Accepted, Suspended, Rejected, or placed in the Dependency Queue.

•Accepted Transactions include all transactions that were without errors as well as Incomplete Transactions that only had data errors in optional fields. These transactions do not require corrections.

•Suspended Transactions include all transactions that require Provider corrections in able for CMBHS to be able to process them. The Provider can correct these via the CMBHS Online Batch Error Correction Screen or by resubmitting a corrected transaction.

•Rejected Transactions include all transactions that are corrupt and cannot be loaded into CMBHS for correction. Rejection Errors occur if the file layout is corrupt, component code and/or local case id is missing or any error which would prevent CMBHS from being able to accurately post the transaction for a Provider.

•The Dependency Queue is a holding area for transactions that arrive out of sequence. For instance, if an Assessment arrives before the Diagnosis, the Assessment will be placed in the Dependency Queue. As soon as the Diagnosis arrives, CMBHS will immediately process the Assessment from the Dependency Queue.

11

Review Batch Reports

Batch File Acknowledgement Summary Report

This report provides an audit trail of batch transactions sent. When CMBHS receives a batch file, it will acknowledge the receipt by sending this summary report. The report will list transaction counts from transactions in the batch file that were Accepted, Suspended, Rejected, or placed in the Dependency Queue.

•Accepted Transactions include all transactions that were without errors as well as Incomplete Transactions that only had data errors in optional fields. These transactions do not require corrections.

•Suspended Transactions include all transactions that require Provider corrections in able for CMBHS to be able to process them. The Provider can correct these via the CMBHS Online Batch Error Correction Screen or by resubmitting a corrected transaction.

•Rejected Transactions include all transactions that are corrupt and cannot be loaded into CMBHS for correction. Rejection Errors occur if the file layout is corrupt, component code and/or local case id is missing or any error which would prevent CMBHS from being able to accurately post the transaction for a Provider.

•The Dependency Queue is a holding area for transactions that arrive out of sequence. For instance, if an Assessment arrives before the Diagnosis, the Assessment will be placed in the Dependency Queue. As soon as the Diagnosis arrives, CMBHS will immediately process the Assessment from the Dependency Queue.

12

Review Batch Reports

Daily Reconciliation Report

This report will send a daily snapshot of all transactions that were received via batch during the last 24 hour period. This report will include transaction data from all Batch Files.

•Batch Warnings

• Accepted but Incomplete Transactions that have Warnings

•Batch Errors

• Suspended Transactions

• Rejected Transactions

• Dependency Queue Transactions

•Batch Accepted Transactions

This is available in the standard HTML version and now also as a text delimited file format for those who need to automate internal processes with this data.

13

Review Batch Reports

Cumulative Batch Error Report

This report will display a snapshot of all transactions that remain in Suspense or the Dependency Queue.

• Batch Errors

• Suspended Transactions

• Dependency Queue Transactions

This is available in the standard HTML version and now also as a text delimited file format for those who need to automate internal processes with this data.

14

Issues Raised at May 15th Policy Work Group Meeting

• Separate folders for processing transactions ASAP and processing transactions after CARE processes

• When are the reports going to run without intervention from the CMBHS team?

• Requirements for a migration report

15

IMC Discussion Items

• Prior notification of Data refresh

• Mike Taylor to set an auto-forward rule that routes email from Chris with a key word in the subject line to full IMC.

• Selection of Data Entry Method (Manual vs. batch) + Switching / simultaneousNotification of delay in processing

• Warnings vs. Errors - blank non-required fields silent please.

• Notification of status change w/in CMBHS System (all types, incl. auto discharge)

• Stop doing auto-discharges in CMBHS

• Notify sender of file being dropped (not processed) due to file format error. e.g. letter case error (XmL), file just stops, sender has not idea.

• Develop some automated batch processing to expedite cycle time

16