FASAMS Frequently Asked Questions
Send a question to the DCF Help Desk
General Questions
Q: What is the Go Live date for FASAMS?
The FASAMS system is expected to go live by 12/31/2018. The first data sets using the new XML schemas would be sent in January 2019.
Q: What is FASAMS?
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.”
Q: Will I use FASAMS for TANF?
No. At this time, TANF data will continue to be submitted to the SAMHIS system.
Q: Will I use FASAMS for SANDR?
No. At this time, SANDR data will continue to be submitted to the SAMHIS system.
Q: Will I still able to view/download my data from FASAMS like I could from SAMHIS?
Yes. Your FASAMS login will allow you to access all of your data within the system for viewing and extract.
Q: Will a flat file format of the new / revised data layout be provided to supplement and map to the new XML data set?
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.
Q: How will FASAMS report errors on large data volumes?
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.
Q: Will the actual FASAMS data validation rules be provided to the ME’s in order to incorporate those into their data upload validation routines for provider data? Past SAMHIS issues have been a result of incomplete understanding and consequent mismatch in validation processes at the ME and DCF levels due to rule interpretation from the Pamphlet.
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.
Q: We noted some inconsistencies between field names and chapter definitions which will potentially create confusion.
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
Q: Regarding the Source record identifiers, what happens if a provider changes its system and its primary keys are reset it. How does that providers reference records already submitted in FASAMS if the ID's are not available anymore?
This is a special situation that would need to be worked out between the submitting entity and DCF.
Q: How FASAMS will validate for duplicate records when 2 or more records have the same content but different SourceRecordIdentifiers?
This is a basic feature of any Data System in order assure consistency and integrity of the data. Also, many providers have contracts with their EHR vendors that will only implement what DCF documentation specifies. Therefore, if even the Managing Entities would implement these types of validations, some providers would not be able to replicate them due to not being published in DCF’s documentation.
FASAMS does not contain any special logic to validate for duplicate records at this time. Any records with different SourceRecordIdentifiers are assumed to be different records.
Q: I’m unsure as to how our EHR can create all of these different identifiers
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.
Q: The memo from John Bryant dated August 28 said under bullet 1. Project Documentation that Entity Relationship Diagrams would be available by Friday, August 31. I have not seen the ERDs, either on the website or via email, and wanted to check on the timeline for their availability?
ERD Documents below:
- READ ME FIRST: How to Download a Zip File
- Entity Relationship Diagram (ERD), Updated 8/23/2019
Q: During the upcoming test window (Stage 1 & 2) is it acceptable to test with live data or should only dummy data be submitted?
Live data is acceptable.
Q: What would happen if a file included an invalid tag (for example: an element that was once in the chapter but has since been deprecated)? Would the record be rejected or would the system ignore the tag?
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.
Please see an example from the Treatment Episode Chapter.
