Service Upload Template
In the attached spreadsheet there are different worksheets. The “Details – UploadTemplate” provides the template/instructions and data validations that will be applied. Please note that the field-by-field instructions are provided in rows, but the actual result would have each field as a column in a spreadsheet. For example, in the instructions:
- The first field (row 3) indicates that the “Client ID” should be provided. This means that the Client ID would appear in Column A for a row/record to be imported.
- The second field (row 4) indicates that the “Clinician ID” should be provided. This means that the Clinician ID would appear in Column b for a row/record to be imported. Etc.
In the other worksheets in the excel file, there is information describing use cases and the Ux/Front-End features such as list pages that will be used to support the upload process.
Location
You can also watch this video: Location Video
Data Migration into SmartCare
The Program’s NPI, unless none are provided and the agency only uses the Agency level single NPI.
This field is required if the NPI for your claim for ServiceNPI should be based on program providing the service and/or your agency has more than one NPI. Otherwise, the NPI listed in the Agency table will be used.
When an 837 file is generated at this moment in time, SmartCare will export the 837 file directly to the users’ PC downloads folder. The user can then move it from their download folder on their PC to where they need to from there. We do have development where we have requested Streamline to configure a folder on the SFTP site for each county for 837 files and State Reporting and automatically send the files to the SFTP site for retrieval. We are waiting for this development to be released to automatically send the 837 and State Reporting files to the SFTP site and this is slated for May.
Balances will not be migrated; all old billing and payments (prior to 7/1/23) need to be completed from legacy system.
They may change a bit before 3/1/23;most likely would be state reporting stuff. We can set a date here if needed. The basic setup and client files shouldn’t be changing.
It is available now, needs to be enabled by user, can ask IT Team to reach out to county if more info needed.
They primarily used Crystal Reports—likely willing to share.
No, migration is only 1 time before go live, however, you could migrate just the client IDs and no program enrollments/episodes that you have before go live 2023.
Semantics — SL’s “migration process” versus our own ability to use stored procedures and other methods to get this over. John has a strategy for 2024 (beds, programs, etc.). This program has additional functionality/issues that it’s better to leave out for now.
For the most part, no, in the name of data consistency and streamlining processes. There are some exceptions (program types) that can bring back a request to CAB with the reason for a new global code.
No, we need the csv files to be completed according to the instructions so that we can upload to SL.
Often times a child template will point to something missing in the parent file (missing program, missing staff, missing client, etc.).
No, our team can help translate as needed.
Leave them blank. Do not enter a dummy value or other characters.
All PDF files will upload to a single directory in the county SFTP site. The file path will be the same, so just need the file name in the path field.
CalMHSA created the Data Migration Document; counties fill out their scope.
Blank is better than Null. Don’t use dummy dates. NPIs do need a start date so use 1-1-23 but otherwise blank.
Not after 7/1 for discrete data; PDFs, yes, but that’s it. Your last extraction will put you in the gap time between your legacy EHR and SmartCare. When you get your migration in your QA environment you need to test your data extensively prior to go live.
It depends. In general you give us your files and we batch for about a week before moving them to Streamline. Once the errors are corrected we’ll push to QA. We have an internal validation process and this may require iterations.
They have different degree type global codes that you will use in the staff file.
Students would not be showing up on your provider list but would still be able to bill. There are different classifications of student.
The staff role should be reception/front desk. That roles covers some billing like 270/271 as well.
Yes we did. Staff locations will be controlled at the program level.
If they have plans not covered in the pre- populated list, they will need to add them. If they bill their Medicare HMO plans the same, they can create a template for Medicare HMO and then connect all of their actual Medicare HMO plans to it. That way, if anything changes or they have a new plan, they can manage it under the template plan.
CalMHSA global codes will overwrite county global codes if they are the same number. Global codes addition will need to be discussed during migration. This is unlikely to occur due to the sequencing CalMHSA will use compared to the ones available to counties.