The Diagnosis Document and the Client Clinical Problems are different screens and serve different purposes in SmartCare. However, there is a lot of overlap. DHCS requires that any diagnoses that are part of an assessment must be added to the client’s problem list (BHIN 23-068). Many counties have asked for the ability to connect these two screens to minimize duplicate entry. There’s a configuration key allows that, with some very important caveats. See DisplayPullProblemListsButtonAndPushProblemListsCheckboxOnCoreDxDoc for details about the configuration key itself.
Every diagnosis document is tied to a specific program. This is because SmartCare uses this program to pull ICD-10 codes into the Billing Diagnosis tab for services associated with that program. If a program does not have a diagnosis document, then the Billing Diagnosis tab will not be populated. This means that often times multiple programs have almost identical diagnosis documents, since they’re all working on the same diagnoses with the client, but the system needs to be able to pull in the codes separate for each program. This is a SmartCare limitation.
Every problem on the Client Clinical Problems screen is also tied to a specific program. This is only for privacy purposes, and NOT for data purposes. When CalMHSA designed this problem list, we wanted to limit duplication of ICD-10 codes, but we needed to respect 42 CFR privacy rules. If a problem is associated with a program that the user does not have in their CDAG, then they won’t be able to see that problem. If the client signs an ASCMI that allows for sharing between CDAGs, and CDAG rules are dropped, all users will be able to see all problems. This also means that a user from Program B doesn’t have to add a problem that Program A has already added to the problem list. If there are updates, the user from Program B can simply update the client’s problem that already exists.
This configuration key does not work within CDAG, only within program.
This means that if a user from Program A has added a problem to the problem list, a user from Program B will NOT be able to pull this problem into a diagnosis document for Program B. The system will ONLY pull in problems that are associated with Program B.
This also means that if the user from Program B manually enters in diagnoses into their diagnosis document and then pushes these to the problem list, the system will create DUPLICATE problems. The system doesn’t check to see if that problem already exists for the client, it only checks to see if it exists for that client for that program. This push will lead to duplication of problems on the Client Clinical Problems list, which is antithetical to the design CalMHSA worked on, which emphasizes the treatment team approach while still respecting 42 CFR rules.
Please also keep in mind that the problem list shows all problems that you’re allowed to see, so there isn’t a way to limit the problem list to show only those problems associated with your program. If we requested that enhancement, then we would basically be duplicating the diagnosis document into the problem list rather than the problem list being a cooperative effort. It would mean that anytime a client was opened to a new program, the user would have to populate the problem list again, either manually and then pulling into the diagnosis document, or by creating the new diagnosis document and pushing to the problem list.
Please also keep in mind that pushing to the problem list from the diagnosis document uses the effective date of the diagnosis document as the start date. This also means that if you’re pulling in from the problem list to the diagnosis document and the diagnosis document effective date pre-dates any start dates of any problems, those problems will NOT be pulled in, as they occur “after” this diagnosis.