FASAMS stands for Financial and Services Accountability Management System. The FASAMS system will allow managing entities, state mental health treatment facilities and other organizations who have contracts with DCF to submit data on persons served in substance abuse and mental health programs. Data submissions will be sent to FASAMS rather than the existing SAMHIS system. At its core, FASAMS is a data warehouse which enables reporting and analysis of financial, services and performance outcome information. It will enable FASAMS users to answer the question of “who received what services, from whom, at what cost and for what outcomes.”
No. At this time, SANDR data will continue to be submitted to the SAMHIS system.
Yes. Your FASAMS login will allow you to access all of your data within the system for viewing and extract.
No, a separate flat file layout will not be provided. Each new data set contains a section which maps the XML data set to fields used in the previous flat files, where applicable.
The submitting entity will receive an email notification of errors produced as a result of a file being processed. By logging into the FASAMS portal, you will be able to view the details of each error. Technical assistance will also be provided by the vendor to resolve data submission concerns.
All data validation rules are being incorporated into the new chapters. The data system will align with the chapters to ensure there are no inconsistencies between the documented functionality of the system and the actual code.
For example:
Chapter 3: TypeCode = the code indicating the type of provider site license identifier
Chapter 4: TypeCode = the code indicating the type of identifier
Chapter 5: TypeCode = the code indicating the type of discharge
Chapter 4: SourceRecordIdentifier = provider’s internal system identifier for the client
Chapter 5: SourceRecordIdentifier = provider’s internal system identifier for the site treatment episode record; the provider’s internal system identifier for the admission; the provider’s internal system identifier for the performance outcome measure; the provider’s internal system identifier for the discharge– these all refer back to the site treatment episode…
Chapter 5: Client SourceRecordIdentifier = provider’s internal system identifier for the client (Chpt. 4)
TypeCode is the generic name being used to identify various codes in the data sets. The specific code is identified in the description. SourceRecordIdentifier is the generic name being used to identify the provider’s internal system number on various types of records. The specific record is identified in the description
This is a special situation that would need to be worked out between the submitting entity and DCF.
I know I asked before but this is so confusing to me - in Chapter 5 there are several different Source Record Identifiers- it seems as there is one for the Treatment Episode, one for the Admission, one for the Performance Outcome Measure, one for the Evaluation, and one for the Diagnosis. Then of course there are different ones for Discharge and Immediate Discharge. Is there any way to consolidate this huge number of identifiers? With everyone working from electronic files, it seems like it is so many identifiers for one dataset.
As stated FASAMS FAQ page, SourceRecordIdentifier (SRI) is the generic name being used to identify the provider’s internal system number on various types of records. The specific record is identified in the description.
In each of the chapters, there are alternate suggestions on how to create unique SRI other than using an auto generated number or a global unique identifier (GUID).
In the event that one sub-entity of a dataset needs to be updated or deleted, the entire record doesn’t have to be submitted. Only the SRI of the sub-entity can be used to identify the sub-entity record that needs to be updated or deleted.
All chapters are currently in the requested Lock Down state until after the FASAMS Go-Live. DCF welcomes the ME recommendations for SRI consolidation as part of future FASAMS enhancement.
ERD Documents below:
- READ ME FIRST: How to Download a Zip File
Live data is acceptable.
If it is a required field, the record would be rejected. Each field or code that has been added/removed have a comment to inform Submitting Entity"s when that change will be testable.