Send a Question to the DCF Help Desk
General Questions
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 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: 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.
Appendix 5 Data Codes
Q: Table 16, Staff Identifier Education/Certification Level: Code 07 – MD/DO has the description, “Board Certified”. MANY MD/DOs are NOT Board Certified. If the description is accurate, then there should be another Code for MDs and the ilk that are not Board Certified.
A: The wording in FASAMS Appendix 5 is a verbatim transcription of the wording in SAMHIS DCF Pamphlet 155-2 Appendix 5, Table 17 for Staff ID Education Codes, which MEs and their network providers have used for years. Adding another code or changing the wording at this stage of DDI would be a non-critical change that could delay the project. Hence, any change to this field would be part of the change request for future enhancement
Q: EducationGradeLevel – code 35 – Special School. Could we receive some clarification please – how is ‘special school’ defined?
A: Code 35 – Special School - is used for children in a special education class that does not have an equivalent school grade level. It corresponds to TEDS code 74 for Self-contained special education.
Q: EducationGradeLevel – “The code indicating either the highest school grade completed for adults or children not attending school or the current school grade for school-age children (3-17 years old) attending school.” This needs some grammatical clarification. Is the intent to ask (1) the highest school grade completed for adults; or (2) children not attending school; or (3) the current school grade for school-age children (3-17 years old) attending school? I don’t really think that’s the intent. Rather, I think the intent is (1) the highest school grade completed for adults or children not attending school; or (2) the current school grade for school-age children (3-17 years old) attending school. So perhaps: “The code indicating either the highest school grade completed for adults or for children not attending school; or the current school grade for school-age children (3-17 years old) attending school.” (note the semi-colon prior to the last ‘or’ – err, maybe it should be a comma; was never an English major). Or, perhaps, “The code indicating the current school grade for school-age children (3-17 years old) attending school, and for all others the highest school grade completed.”
A: This field specifies (a) the highest school grade completed for adults or children not attending school or (b) current school grade for school-age children (3-17 years old) attending school.
Q: We need the crosswalk to the ASAM codes, which DCF wants for level 2, 3 , 4 etc.. I can’t find the ASAM Florida Supplement, which is a DCF development tool, anywhere on the DCF website. This tool has both ASAM level and DCF level on upper right corner of each page. So we need access to one or the other or both.
A: The ASAM Florida Supplement was discontinued when the older version (2nd edition) of the ASAM was updated in 2013. A crosswalk has been created for the SAMHIS codes.
| ASAM Code | ASAM Levels in FASAMS | ASAM Placements in SAMHIS |
|---|---|---|
| 1 | 0.5 Early Intervention | [14] Intervention |
| 2 | 1 Outpatient Services | [11] Outpatient |
| 3 | 2.1 Intensive Outpatient Services | [12] Day Treatment |
| 4 | 2.5 Partial Hospitalization Services | [12] Day Treatment |
| 5 | 3.1 Clinically Managed Low-Intensity Residential Services | [04] Residential Level 4 |
| 6 | 3.3 Clinically Managed Population Specific High-Intensity Residential Services Note: This level is not designated for adolescent populations. | [03] Residential Level 3 |
| 7 | 3.5 Adults - Clinically Managed High-Intensity Residential Services | [02] Residential Level 2 |
| 8 | 3.5 Adolescents - Medically Managed Medium-Intensity Residential Service | [02] Residential Level 2 |
| 9 | 3.7 Adults - Medically Monitored Intensive Inpatient Services | [01] Residential Level 1 |
| 10 | 3.7 Adolescents - Medically Monitored Intensive Inpatient Services | [01] Residential Level 1 |
| 11 | 4 Medically Managed Intensive Inpatient Services | [07] Residential Detox |
| 12 | OTP Opioid Treatment Program (Level 1). Note: OTP's not specified here for adolescent populations. | [17] Outpatient Methadone |
| 13 | 1 WM - Ambulatory Withdrawal Management without Extended On-Site Monitoring | [09] Outpatient Detox |
| 14 | 2 WM - Ambulatory Withdrawal Management with Extended On-Site Monitoring. | [09] Outpatient Detox |
| 15 | 3.2 WM - Clinically Managed Residential Withdrawal Management | [07] Residential Detox |
| 16 | 3.7 WM - Medically Monitored Inpatient Withdrawal Management | [07] Residential Detox |
| 17 | 4 WM - Medically Managed Intensive Inpatient Withdrawal Management | [07] Residential Detox |
Client Data Set
Updated 11/20/2018
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.
Q: How will FASAMS handle the merging of two clients?
A: Currently, FASAMS does not have a process that merges clients. If you have submitted data for the same client under different SourceRecordIdentifiers, you can correct this by deleting one client and associated records and updating the other client.
Q: There are numerous inconsistencies in the Client Data- Chapter 4. Items like e-mail address, client phone and address say “optional” in the description yet “required” in the Description/Validation Rules tables. When will this be corrected so that we know how to proceed with this information?
A: This is an optional sub-entity that doesn’t need to be included in the XML. If it is included in the XML, then the fields will be required. Clarification can be added to the chapters.
Q: In the client chapter, although some fields say required, they state they are optional within the text. IE. Client email address. Does this mean that we are required to send the clients email address only when the attribute is sent under the element?
A: That is correct. It Is only required if you add the attribute.
Historical
Updated 01/24/2019
Q: For the oldest admissions there are problems mapping old grade codes, 20-23, prior to the 2015 PAM update.
A: The current grade codes can be mapped to the furthest grade listed for each code in the 2015 PAM.
| PAM | FASAMS |
|---|---|
| [20] = No Schooling | 00 = No Years of Schooling |
| [21] = Nursery School to 4th Grade | 04 = Grade 4 |
| [22] = 5th to 6th Grade | 06 = Grade 6 |
| [23] = 7th to 8th Grade | 08 = Grade 8 |
As far as translating current PAM data to FASAMS to support those who were unable to upload FASAMS but could still upload PAM and for the creation of the historic data for upload, some of the areas where guidance would help:
Evaluations for Initial Admissions under MH. Values can be derived for most of SA because they have FASAMS, but MH only have level of functioning in current reporting, not level of care.
A: For Historical Data, the only evaluation for MH is the level of functioning based on FARS and CFARS score as specified in Chapter 5, pages 58 thru 61, and in Appendix 5, page 11). The only fields required for the Evaluation Entity will be the following: SourceRecordIdentifier, StaffIdentifier, EvaluationDate, TypeCode, ToolCode, ScoreNumber, ScoreCode, and ActualLevelCode.
Q: For the oldest admissions there are problems
00 as the Site ID – possible solution – select a current site where the client has been served.
A: The Submitting Entity would need to make sure that the provider site selected has the correct treatment setting for the corresponding covered services in the service event.
Q: Contracts that have expired – the original contracts contained an entirely different OCA structure, and a number of subsequent OCAs have expired. Further, a lot of the early contract data is paper based, not in a database for easy consumption. – possible solution would be to use the current contract number and relax any possible validation against the contract dates for the historic load.
A: It would not be recommended to use a current contract. However, a contract that has already expired prior to 7/1/2018, along with the business rules to be modified below maybe sufficient.
Q: How should Residence County 88 mapped in FASAMS?
A: Residence zip 88888 can map to 99999.
Q: How should Residence zip 88888 be mapped in FASAMS?
A: Residence county can map to the county of service.
Q: For those individuals with a service on or after July 1, 2018, are we just uploading the data relevant to that episode or is it all data for that client, regardless of how many different episodes?
A: Upload the data relevant to the episode that is open on or after July 1, 2018.
Q: As part of the data load from (1) are we supposed to create transfer admissions to the different treatment settings or will the validations be relaxed so that the services will be accepted as long as there is an initial admission without regard to the treatment setting?
A: Historical data transfer admissions do need to be created so that service events that are different from the original admission treatment setting from the can be accepted by FASAMS.
Service Event Data Set
Q: Does the ExpenditureOcaCode correspond to the current Modifier 4 value to indicate the OCA or is it the actual expenditure OCA once the ME has paid?
A: The ExpenditureOCACode will correspond to the actual expenditure OCA codes.
Q: Can you provide examples and further clarification around the use of the different modifier entities on the service event record?
A: Modifiers can be used on covered service codes, HCPCS codes and expenditure codes to further describe that code. For example, HCPCS modifier ‘HN’ (Bachelor’s degree level) can be used with HCPCS code ‘H0031’ (Mental health assessment, by non-physician). Modifiers used with covered services and expenditure codes will not be validated at this time. Any combination of codes and modifiers can be used. However, modifiers used with HCPCS codes will be validated. Only valid combinations will be allowed.
The modifiers that can be used with HCPCS codes will be provided in the next update to the Appendix 5 Data Code Values.
Q: Will services be validated against the Provider records based on the site ID, treatment setting, covered service?
A: No, the services will not be validated against the provider data at the time of import. It will be validated via a management report at a later time during the month. However, each covered service must be valid for the treatment setting, program area and event type.
Q: In Service Event- Chapter 6, what is the difference between the Episode Source Record Identifier and Admission Source Record Identifier (page 14)?
A: A client-specific service event (ServiceEvent) record is a child of an Admission record, and a grand-child of a provider treatment episode (ProviderTreatmentEpisode).
The admission SRI (AdmissionSourceRecordIdentifier)is used to link the client- specific service event (ServiceEvent) record back to the specific parent Admission record, and the episode SRI (EpisodeSourceRecordIdentifier) is used to link the client- specific service event (ServiceEvent) record back to the specific grand-parent ProviderTreatmentEpisode record.
Q: Can the ExpenditureOCACode differ from the reported ServiceEventExpenditureModifier? My interpretation is that the ServiceEventExpenditureModifier would be populated by the provider indicating the OCA from which they expect payment, whereas the ExpenditureOCACode would be populated by the ME reflecting the actual expenditure OCA that paid for the service (for example: a restricted OCA is exhausted so the service is paid out of an unrestricted OCA).
A: As discussed in the 8/23/2018 Strategic Meeting, the use of the Expenditure OCA was an oversight, and these should have been identified as (Budget) OCAs. The change to the modify the label of the ExpenditureOCACode in FASAMS will happen after the DDI phase.
Q: Would the ServiceEventCoveredServiceModifier be used for things like reporting the medication a client is receiving under the STR grant or that a client is in the care coordination program? If not this modifier, how are these types of things to be reported?
A: Yes. In regard to the STR grant the Appendix 5 Data Code Values Chapter has modifiers (S1-S5) that relate specifically to STR.
Q: According to Chapter 6, for client-specific events, with Collection Unit of Measure of “Direct Staff Minutes” and which involve more than one individual and/or more than one staff, the total number of minutes spent by the staff should be divided by the number of individuals involved to get the number of units per client per event. If we are calculating this correctly, for services provided with one staff person, like our PSR groups, the state would essentially pay for one member in attendance. This seems not only very difficult to do (because the system would have to calculate this based on members in attendance at varying times), but is contrary to how other funders pay for services such as these. Moreover, our groups are mixed (meaning that they have different funders- some are Medicaid, others SAMH). Can you please provide some clarification or direction about the unit requirement?
A: The unit of measure requirement for each covered service is defined in the Financial Rule 65E-14.021.
Your calculation is correct for reporting the total number of minutes for client-specific service event, which is measured in direct staff hour and involves more than one client and more than one staff. For example, an outpatient service provided by two staff to a group of five individuals for 60 minutes, would require the submission of five client-specific service events (one per client). The number of service units (ServiceUnitCount) reported in each individual service event record would be 24 minutes (60 minutes X 2 staff = 120 minutes /5 clients = 24 minutes per client).
In case where the group is mixed (e.g., 2 of the 5 service events are funded by Medicaid and 3 are funded by DCF, then only the 3 service events funded by DCF would be submitted in FASAMS.
As always, DCF welcomes the ME recommendations to improve the process for reporting direct staff hours for service events involving more than one individual and/or more than one staff.
Subcontract Data Set
Q: For the oldest admissions there are problems: Contracts that have expired – the original contracts contained an entirely different OCA structure, and a number of subsequent OCAs have expired. Further, a lot of the early contract data is paper based, not in a database for easy consumption. – possible solution would be to use the current contract number and relax any possible validation against the contract dates for the historic load.
A: It would not be recommended to use a current contract. However, a contract that has already expired prior to 7/1/2018, along with the business rules to be modified below maybe sufficient.
