The Fixus MDS Aggregator is a purpose-built module designed to support lead agencies in the collection, validation, and aggregation of Minimum Data Set compliant data from external service providers. It streamlines the process of receiving data from distributed systems, ensuring consistency, accuracy, and compliance with reporting requirements.

Distributed Episode Workflow

The distributed episode workflow ensures that Fixus manages incoming referrals and allocates them to external agencies, which handle episodes using their own software. These agencies then report their data back to Fixus, where it is aggregated for centralised reporting.

• The Lead Agency creates a reporting period in the MDS Aggregator.
• The Lead Agency manages staff records in the Fixus system ensuring that it has a practitioner record with a matching Practitioner Key for each reporting practitioner.
• Referrals are received into Fixus (this can occur via direct entry into Central Intake, Snapforms, API integration or the H2H gateway).
• The referral is converted to an episode and is allocated to an External Agency.
• The External Agency receives the episode including the Client Key and Episode Key. They manage the episode in their own software, creating service contact and assessment records.
• The External Agency generates a compliant MDS extract from their own software and uploads this to the Fixus MDS Aggregator.
• The Fixus MDS Aggregator matches the incoming records using the shared Client Key and Episode Key and updates its dataset using the supplied data.
• At the end of the reporting period the Lead Agency generates a combined MDS report and uploads this to the MDS portal.

The Validation Process

This section examines uploaded data files to ensure they meet the minimum data set standard by verifying the file format, required content, and size, while logging any discrepancies.

• Payload Check:
  • The service first checks if it received any data.
  • If no data is received, it logs an error and stops processing.
• Submission Upload Record:
  • It looks up the record associated with the data upload using the provided ID.
  • If the record isn’t found, it logs an error and stops processing.
  • It also notes who uploaded the file and when (using Australian Eastern Standard Time).
• Document Verification:
  • The service ensures that at least one document (file) is included in the data.
  • It retrieves the file details (like name and size) to check they exist.
• File Type and Size Check:
  • The file must be either a ZIP or an Excel (.xlsx) file.
  • The file size must be less than 512 MB.
  • If these conditions aren’t met, it logs an error and stops processing.
• Loading the File:
  • The service loads the file data into memory for further checks.
• Format-Specific Validation:
  • For ZIP files:
    • It confirms the ZIP file is valid.
    • It checks that all required CSV files are included inside the ZIP.
  • For Excel files:
    • It confirms the Excel file is valid.
    • It checks that all required tabs (sheets) are present.
• Data Reading and Logging:
  • The service uses specific validators to read data from the file.
  • Each validator checks its part of the file and adds notes to a log.
• Record Processing:
  • Each validator then processes the records to ensure they meet the necessary standards.
  • The processing time for these checks is recorded and logged.
• Final Steps and Error Handling:
  • Once all checks are complete, the service logs the total processing time.
  • If any unexpected errors occur during this process, they are caught, logged, and reported.
  • Finally, the updated data (including any errors or logs) is returned.

Validation Order

Validation processors are executed in the following order:

• Clients
• Practitioners
• Intake
• Intake Episode
• IarDst
• Episodes
• Service Contact Practitioners
• Service Contacts
• Collection Occasion
• Assessments

Data Processing Order

Data processors are executed in the following order:

• Clients
• Practitioners
• Intake
• Intake Episode
• IarDst
• Episodes
• Service Contact Practitioners
• Service Contacts
• Collection Occasion
• Assessments

Practitioners

Managing practitioners is an important part of the workflow process described above.

Practitioner records must exists and contain matching Practitioner Key and Organisation Path values before a data import can be completed successfully.

Assessments

• The Assessor and AssessorId values are not provided – there is no way to know from the MDS data file.
• CollectionOccasionTags, K5Tags, K10pTags and SdqTags are being stored as column values – these values are not used or displayed by Fixus.
• Assessment Scores provided are stored as provided – we are not checking the calculation.

Configuration

Agencies

When configuring an agency:

• The agency must have the MDS Aggregator module enabled.
• The agency must have a single team with the PMHC program type enabled*
• The agency must have a valid “Provider Organisation Key“ configured that will match the OrganisationPath stored in provided import files. This can be either a partial key or the full key.

*It’s important to note that ONLY agencies with a single team enabled for PMHC are currently supported.

Practitioners

• A Staff Member record must be created for each practitioner.
• A Practitioner Key that matches the external reporting system must be set for each staff member record.