CalMHSA’s Change Process

CalMHSA’s statewide electronic health record project was created to standardize clinical forms and practices across counties. CalMHSA works to address state initiatives for all involved counties, instead of each county having to react to these changes themselves. By pooling resources through CalMHSA, counties are able to access collective activism for meeting their needs and ensuring their voices are heard at the state level.

In the past, each county had to learn about new initiatives, analyze them, develop an implementation plan, work with their EHR vendor to get changes developed, and stand alone when faced with an audit. By joining the statewide EHR collective, counties are no longer on their own in addressing each state initiative.

CalMHSA monitors state initiatives, including new legislation, proposed billing changes, reporting requirements, and more. CalMHSA staff attend statewide meetings, monitor Behavioral Health Information Notices, and meet regularly with DHCS personnel to stay up-to-date on changes and requirements.

The length of time needed for each step below depends on the complexity of the initiative, resources available, and other issues that arise that take precedence, such as system outages or major bugs that severely impact crucial workflows.

CalMHSA’s Initial Review and Planning Process

When these initiatives present an impact to the EHR project, CalMHSA begins working on how to address them. The analysis and design process is comprised of many steps and requires time to ensure highest quality.


The first step is to analyze the requirements and determine the impact of the initiative. When an initiative is required by all counties, the impact is obviously much higher than when an initiative is voluntary. This means that CalMHSA will often reach out to counties to determine the impact of an initiative on their system of care.

Determining the requirements is often a larger, more drawn-out process. CalMHSA staff review these initiatives and consider their impact on current workflows, what data will need to be collected, what new documents need to be created or adopted, etc. Sometimes an initiative may look simple, but the changes required are actually complex and expansive. Other times, an initiative may look complicated, but with further analysis, we find that the information is already being collected and only minor changes are needed.

CalMHSA doesn’t just take the state requirements into account, but also considers the real-life workflows. For example, while the Mobile Crisis initiative required a Mobile Crisis Assessment, that assessment was meant to be done in the field. Being in the field means sometimes not having access to the internet. Trying to log into SmartCare on a laptop while a person is in crisis does not facilitate the best possible clinical care. CalMHSA, therefore, created a scanned document to ensure that those in the field on a crisis encounter would have a paper option they could simply scan in when the encounter was over.

This phase also sometimes includes having conversations with the State or attending State-run webinars. Oftentimes CalMHSA is receiving the information at the same time counties are. CalMHSA digests all the information and works to get a comprehensive understanding of the initiative and all its nuances. Increasingly, DHCS is meeting with CalMHSA to provide technical assistance to ensure all counties included in the EHR project implement the initiative smoothly.


The next step is to begin strategizing. This involves investigating what already exists that can be utilized and what needs to be created from the ground up. This step also includes exploring the entire workflow — not just a document or a screen, but how that document or screen will be utilized, and by whom. This includes considerations of CDAG implications, user role accessibility, and what other parts of SmartCare will be utilized or impacted. Sometimes this may also mean a discussion with legal experts to ensure all privacy regulations are followed.

This process is often iterative, meaning that a draft is created, reviewed by others, feedback is given, and a newer draft version is created. This process of starting with the basics and then refining as feedback is given allows us to meet multiple perspectives. By the time a draft strategy is presented to counties, it has already been vetted internally.

CalMHSA will still often present this strategy to counties for feedback. As the experts on the ground, we rely on county subject-matter experts (SMEs) who will be doing this work day-in and day-out, to provide us with real-life scenarios we may not have considered. This adds to the iterative process and an even more refined strategy can be created.

With all initiatives, some change is required, and that means that counties may need to change their processes and workflows to adapt to the new requirements. CalMHSA ultimately holds ownership of how an initiative is implemented in the statewide EHR and works to balance the feedback and needs of all involved counties.

Sometimes, this means the strategy must be rolled out in versions. Version one of the strategy may simply meet the basic requirements. This often occurs when a state initiative includes a short timeframe and a hard deadline. After getting something basic in the system to meet the minimal requirements, version two can add improvements to make the process easier, smoother, and faster for users. Part of strategizing is determining what can be done in the timeframe required and what can accomplished with future streamlining.


Once a strategy is ready, CalMHSA must determine the development pathway. CalMHSA has an internal development team that can create certain types of items in SmartCare, but sometimes a strategy requires the vendor to develop, due to proprietary systems or complexity of the design. CalMHSA also must review what is already in the development queue to determine estimated timelines for new development items. This often includes a consultation with one or both development teams.

If this need is urgent, due to a deadline or a fatal design flaw in the current system, CalMHSA also must determine if a quick and but somewhat cumbersome fix is better than a slower but more streamlined fix. Each type of fix takes time, and CalMHSA measures these options carefully. This doesn’t mean the long-term fix is abandoned, but rather that we’ve decided to work with a short-term solution to buy us time.

While we’ve been discussing the progress of a single state initiative, keep in mind that there are often multiple initiatives occurring at the same time. This means part of planning includes prioritization. CalMHSA prioritizes based on level of need. CalMHSA prioritizes State initiatives with hard deadlines to ensure counties meet all State requirements. This means that other items may be deprioritized to ensure resources are available to meet the most acute needs first.

Request Development

The next step is to finalize the request for development. This means that CalMHSA has decided on a strategy and a development pathway and is committing to that pathway. CalMHSA submits a request with the chosen development team, providing as much information as possible to ensure the request is understood and assigning a priority level.

The Development Process

While there are two separate development teams (one CalMHSA and one Streamline), the general process is similar and is outlined below. The development process starts the same way the analysis process starts – with a request. At any point in the development process, a request may be put on hold. This may be due to a larger than expected level of effort estimated, changes in regulations or external requirements, or lowering their priority as more urgent requests arise. CalMHSA is constantly re-evaluating the current product roadmap and making adjustments as needed.

Please note that, for Streamline, each step may be handled by different teams that schedule in monthly intervals. This means that even if a step is complete, it may not move to the next until the follow month at the earliest.


The development team reviews requests that are in the queue. They do some initial analysis to determine the requirements for each project. This includes reviewing what they know about the system to determine if something like this already exists and can be used as a starting point, if any specialty skills are needed, and if the request is feasible as written based on the limitations of the software. If there are any concerns or additional clarity is needed, the development team consults the requestor.

As part of this step, Streamline creates a Requirements Document that summarizes the request. This can take anywhere from two to eight weeks. CalMHSA must approve the Requirements Document before the process can move forward, which can take up to two weeks. This step is iterative. Often CalMHSA will send the document back with questions or changes, with which Streamline then incorporates and remakes the document. This repeats until the Requirements Document has been approved by CalMHSA.

Level of Effort Analysis

Once the requirements are understood, the development team provides some high-level estimates of what type of resources and time will be needed to complete the request. This may also include some discussion around when these resources may become available.

As part of this step, Streamline requires that CalMHSA approve the high-level estimate before the process can move forward. It can take three to six weeks for Streamline to provide the estimate and another two to four weeks for CalMHSA to review.


The development team then begins working on a technical design. This expands off the requirements document and includes how exactly this request will be accomplished in SmartCare. Again, this process can be iterative, as developers may need clarification from the requestor when a hurdle arises. Often the strategy that CalMHSA produces includes a visual design of any documents or screens that are requested. This step fills in the technical details and setup of those visual designs.

Once again, as part of this step, Streamline creates a Design Document that summarizes the design. The design phase is often scheduled and does not automatically start after a level of effort estimate is approved. Streamline generally schedules in monthly intervals. Once started, the design is generally completed within two to four weeks.

Development Scheduled

CalMHSA works with the development teams to schedule development into a roadmap. This is a matter of resource management. Items that take fewer development hours may be able to be slotted in more quickly, but larger items need to be added to the schedule early. This development schedule must also have some built-in flexibility to address urgent tasks that need to be quickly addressed. There is generally a schedule for each development team. Streamline’s schedule is not limited to only CalMHSA tasks, as it includes all development Streamline is working on, including requests from other customers and their own product team.


Once started, development generally continues until the task is completed. This may be only a few weeks or occur over several months, depending on the complexity of the task. For extremely large projects that are slated for more than six months, Streamline will generally check in with CalMHSA to confirm they’re on target. Feedback given may require the developers to change their methodology, which may change the estimated completion date.

Quality Assurance Review

Once the initial development is complete, the development team conducts internal quality assurance testing. This ensures that the new code is working as intended and does not introduce bugs into the system. Any issues discovered will be addressed and retested. Only once internal quality assurance processes have been satisfied does the task move forward to the next step.

Request Deployment

The next step is to finalize the request for deployment. This means packaging all the newly developed items into a bundle so the entire request can be deployed at once.

Deployment Process

All deployments go through Streamline. Development items are not released piecemeal; rather, completed development bundles are grouped together to be added to a build. A build is basically a set of development projects that will be released at the same time. Streamline has multiple build paths, including their Core Build, often referred to as a Monthly Service Pack (MSP), the California State Build, a CalMHSA Build, and a Custom Build. Each of these builds are produced in their own timeframes. The MSPs are produced monthly, as the name implies. The MSPs are named for the month where development occurred, so the January MSP is a collection of development items that were developed in January. State builds tend to be smaller, and CalMHSA and custom builds even smaller.

Builds must be released in sequential order (i.e., the February MSP cannot be deployed before the January MSP is deployed).

Package for Deployment

As deployment requests are received, the deployment team packages them based on the build path. Core builds are packaged monthly and take at least two weeks to complete, usually being released by the 15th of the following month. Smaller builds may take one to four weeks to complete. Release notes are also generally created at this time but may take longer to complete than the packaging of the build itself. Builds often include brand new items, enhancements, and bug fixes. Some critical bug fixes may be deployed in a Hot Fix Build, which allows for quicker deployment.

Schedule Deployment to QA

Once a build is available to be deployed, CalMHSA must determine when to deploy it to QA. CalMHSA prefers to stay at least one month behind on core builds for initial bugs to be found and worked out by Streamline and their other customers. It’s also best practice to deploy only one core build at a time, so that build can be fully tested without confounding elements introduced by another build. This means a build is often not deployed until the previous build is fully vetted. Sometimes, crucial testing is being done in county QA environments and should not be disrupted with a new deployment. When a build is deployed to the QA environments, it is deployed to all QA environments, meaning every county’s QA environment gets this build. All this is considered when scheduling deployments.

User Acceptance Testing

Once deployed, CalMHSA begins testing the entire build. For small builds, testing can be completed in one to two weeks, whereas larger builds often take two to four weeks. When issues are found, CalMHSA submits tickets before approving the build to move to production environments.

For the core monthly builds, CalMHSA curates the build release notes to highlight all changes introduced by Streamline relevant to CalMHSA, many of which are development items not requested by CalMHSA. All relevant changes are tested before approving the build for deployment to production environments. For items not requested by CalMHSA, CalMHSA reviews the development item for potential implementation.

Some development items require setup and configuration. CalMHSA completes this setup in the CalMHSA QA so that synced county QA environments will have access to this setup. Currently, most county QA environments do not sync with CalMHSA QA but will in the future.

For bug fixes, CalMHSA will often ask the reporting county to test. Any configuration needed will be done by CalMHSA in that county’s QA system to support the county’s testing.

Schedule Deployment to Production

Once a build has been approved to move to a production environment, the build must be scheduled for deployment. This is very similar to scheduling deployment to QA environments and follows the same guidelines.

User Guides and Training

The deployment to QA is often the first time CalMHSA is seeing the development item in action. At this stage, CalMHSA staff work to create training materials using screenshots from the QA environment in preparation for deployment to production environments. Any relevant live training courses are created and scheduled.

If something is being developed in phases, CalMHSA may decide to wait until all phases are completed before implementing the initiative. This is especially true when the workflow steps are built separately and are tested separately. CalMHSA prefers to test the entire workflow before implementation to ensure a smooth process.


Once the build is deployed to production environments, CalMHSA re-tests to ensure development items are working as intended. CalMHSA tests using a pseudo-production environment that acts just like any other county affiliate system but lacks PHI.

Subsequent deployments are delayed at least one week to allow for bug discovery. Bugs are reported promptly, and hotfixes are deployed to resolve these. Each hotfix is first tested in QA before moving to Prod.

Updated 5/23/24