Frequently Asked Questions

General Questions

Q: What is the Go Live date for FASAMS?

A: 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?

A: 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?

A:   No. At this time, TANF data will continue to be submitted to the SAMHIS system.

Q: Will I use FASAMS for SANDR?

A:  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?

A: 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? 

A: 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?

A: 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.

A: 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)

A: 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?

A: This is a special situation that would need to be worked out between the submitting entity and DCF.

Provider Data Set

Q: If a portion, or the entire, Provider Data Set is deleted and then resubmitted will the deleted data be re-activated or does the undo-delete method need to be used?

A: If you delete data and then resubmit the data, new records will be added.  The data you deleted will remain marked as deleted.  Alternatively, you could use the undo-delete method if none of the data has changed to reactivate data (previously marked as deleted) instead of resubmitting it.

Q: Will each ME need to register a provider administrative site?

A: No.  An administrative site is not required for an ME.

Q:  Will all provider sites need to be registered, regardless of whether or not services are funded at the site?

A: No.  A provider record must be sent only for sites that provide services under contract with the managing entity, direct contract with the Department or of the state treatment facility.

Client Data Set

Q:  Is the SourceRecordIdentifier a service provider client identifier? Not all providers have internal client identifiers that could serve this purpose.

A:  Yes.  The source record identifier is meant to be your internal system ID.  This could be your unique record number, or some combination of fields that uniquely identifies that record in your system.

Q: How will deletions of the client data set ensure that demographics and child records will not be deleted for other regions if there is no contract number identified in the client data set?

A: The provider FEI number is a key field in the Client data set, along with the SourceRecordIdentifier. Both of these fields would need to be provided in order to delete client data associated with that provider.

Treatment Episode Data Set

Q: For some of the child nodes there seems to be no indication of a date the information was recorded nor a maximum number of occurrences.

For example, if multiple records for stable housing were submitted under the same performance measure outcome node how would we be able to identify which record for stable housing is newer?

A: Each database table records the date a record is created and last updated. All of the subsections under the performance outcome measure, except for SubstanceUseDisorders only expect and will ultimately allow 1 occurrence.

Q: What provider site ID would be used for in-home on-site service episodes utilize?

A: Use the provider site associated with the staff member who provided the in-home service.

Q: Will the DLA-20 be added to the outcome measures in the Treatment Episode dataset?

A: Yes. We will be adding the DLA-20 and possibly other evaluation tools.