This is an option in the Administration > Data Import > “Generic Client Case Import”.
This import process performs the following tasks based on the data provided:
- Create Client record if it doesn’t already exist.
- Create Episode record within the program indicated by the “program_code” value.
- Assign the Episode to the Team indicated by the “assigned_team” value.
- Assign the Staff Member indicated by the “assigned_staff” value to the episode.
- Create a Note stating that the record was imported.
The import process first searches the database for a Client record with an identifier that matches the “client_key” value. If found the existing record is loaded and updated to match the values provided. Otherwise, a new record is created and populated with the values provided.
The import process then searches for an existing Episode (Case) record with an identifier that matches the “episode_key” value. If a match is not found, it then tries to match the “referral_key” value against the “ReferralId” field in the database. If found the existing record is loaded and updated to match the values provided. Otherwise, a new record is created and populated with the values provided.
The value “assigned_team” may be left blank but must contain a valid entry if populated. This will be used to connect the Episode (Case) record with its assigned Team.
Where lookup tables are used, the value being imported will be checked against both the ‘Code’ and the ‘Description’ in the lookup. This makes it easier to import without converting values.
The import process requires a set of values provided as an Excel spreadsheet or CSV file:
- Client Key (external system generated identifier, will be stored as client custom identifier named “ClientKey”, required)
- SLK (stored as a client identifier, optional – note that the SLK value is not validated)
- Date Of Birth (Format: “dd-MMM-yyyy”, optional)
- Est Date Of Birth (must match values in “EstimatedDateOfBirth” lookup table, optional)
- Client Gender (must match values in “Gender” lookup table, optional)
- Client ATSI Status (must match values in “IndigenousStatus” lookup table, optional)
- Country Of Birth (must match values in “Countries” lookup table, optional)
- Main Language At Home (must match values in “Languages” lookup table, optional)
- Client First Name (required)
- Client Surname (required)
- Client Phone (optional)
- Client Mobile (optional)
- Client Email (optional)
- Residential Address (optional)
- Postal Address (optional)
- Program Code (required – must match a configured generic program)
- Referral Key (Fixus Referral id eg ‘123456’, optional – if not provided then a unique random number is generated)
- Episode Key (Fixus GUID, optional)
- Referral Date (Format: “dd-MMM-yyyy”, optional – if not provide then the current date & time will be recorded)
- Start Date (Format: “dd-MMM-yyyy”, optional) – Episode Start Date
- End Date (Format: “dd-MMM-yyyy”, optional) – Episode End Date if any
- Episode Status (optional text, usually ‘Active’, ‘Closed’, ‘Pending’, ‘Cancelled’)
- Priority (must match values in “{Program Code}_Priority” lookup table, optional)
- Assigned Team (Fixus Agency Team Name, optional)
- Assigned Staff (Fixus Agency Team Member Name, optional)
The following optional fields are mainly used for DEX or Dynamic fields
- Client Role – Case dynamic field must match values in “{Program Code}_ClientRole” lookup table, optional, usually ‘Primary’, ‘Secondary’ etc
- Program Stream (label in Fixus is ‘Outlet Activity’ but field must be ‘ProgramStream or ‘program_stream’, and matches values in “Generic_{Program Code}_OutletActivity” lookup table, optional, depends on Program
- Referral Source Type – Case dynamic field (must match values in “Generic_{Program Code}_ReferralSourceType” lookup table, optional, usually ‘xxx’)
- Referral Purpose- (must match values in “Generic_{Program Code}_ReferralPurpose” lookup table, optional, usually ‘xxx’)
- Referrals To Other Service- (must match values in “Generic_{Program Code}_ReferralsToOtherService” lookup table, optional, usually ‘xxx’)
- Reason For Seeking Assistance Primary- reason value – optional (must match values in “Generic_{Program Code}_ReasonForSeekingAssistance” lookup table)
- Reason For Seeking Assistance Secondary- reason value – optional (must match values in “Generic_{Program Code}_ReasonForSeekingAssistance” lookup table)
- Disability Indicator Primary- reason value – optional (must match values in “Generic_{Program Code}_xxx” lookup table)
- Disability Indicator Secondary- reason value – optional
- Exit Reason- reason value – optional (must match values in “Generic_{Program Code}_ExitReason” lookup table)
Either an Episode Key or a Referral Id can exist. If both exist, the Episode Key will be used for the lookup. A list of errors will be shown prior to import.
The first row within the datafile must contain the following column header values:
- “client_key”
- “slk”
- “date_of_birth”
- “est_date_of_birth”
- “client_gender”
- “client_atsi_status”
- “country_of_birth”
- “main_lang_at_home”
- “client_firstname”
- “client_surname”
- “client_phone”
- “client_mobile”
- “client_email”
- “residential_address1”
- “residential_address2”
- “residential_city”
- “residential_state”
- “residential_postcode”
- “postal_address1”
- “postal_address2”
- “postal_city”
- “postal_state”
- “postal_postcode”
- “program_code”
- “referral_key”
- “episode_key”
- “referral_date”
- “start_date”
- “end_date”
- “episode_status”
- “priority”
- “assigned_team”
- “assigned_staff”
- and other DEX optional fields, listed above
Check the attachments to this article for a sample import file.
Validation
During Import, the data will be validated to check required/optional values, formatting (eg Dates) and any expected values. Errors will be listed showing the details of the error and the row within the source file that caused the error.
*Note: Only those records that display an error have been excluded. ALL OTHER ROWS HAVE BEEN SUCCESSFULLY IMPORTED. This is important, under certain configurations simply fixing the invalid row(s) then re-importing may re-import the successful records and cause multiple records.
To avoid the creation of multiple records when re-importing data, make sure to provide either an Episode Key or Referral Key values. These will then be used to lookup the existing record and update with the values provided. A note is created for each episode record each time the import is run.
Other Errors
Some types of error may be reported to internal Fixus systems – if errors persist and are not clear, please contact Fixus Support at [email protected]