Care Recipient Sync

Learn about Maica's Care Recipient Sync logic.

Overview

The Care Recipient Sync process is a process that retrieves data from the Services Australia "Support at Home" API suite. This process uses the Care Recipient ID to pull funding and support-related data for a single Care Recipient and stores the data across various related objects, all associated with a parent Plan record.

Plan Record Validation

Prior to beginning the integration, Maica first needs to run some Validation to determine whether an active Support at Home Plan already exists for the Care Recipient. Maica will:

GET maica__Plan__c record WHERE

maica__Type__c = ‘Support At Home’

maica__Participant__r.maica__Care_Recipient_ID__c = {Request Care Recipient ID}

maica__End_Date__c > CurrentDate

• If found, this existing Plan will be used to relate all downstream data.

• If not found, a new Plan record of this type will be created.

CREATE maica__Plan__c record WHERE

maica__Type__c = ‘Support At Home’

maica__Participant__r.maica__Care_Recipient_ID__c = {Request Care Recipient ID}

maica__Claim_Period__c > ‘Quarterly’

The date range values can only be populated for a NEW Plan record after the Classifications have been retrieved. The Plan duration should be taken from the earliest Start Date of the child Classifications and the latest End Date of the child Classifications:

GET maica__Classification__c WHERE maica__Plan__c = {Created maica__Plan__c.Id} AND

maica__Plan__r.maica__Start_Date__c = {Retrieved Classifications Earliest Start Date}

maica__Plan__r.maica__End_Date__c = {Retrieved Classifications Latest End Date}

This ensures each Care Recipient maintains only one active Support at Home Plan at any time.

Once done, Maica can then process with the first callout as per the steps below:

Integration Process

Step 1: Care Recipient Summary API Callout

Purpose: Retrieve the core summary data for a care recipient, using their Care Recipient ID as the key input.

API Endpoint: Care Recipient Summary API

Input:

• CareRecipientID

Data Returned:

• Classifications → Stored in Classification__c

• Approved Services → Stored in Approved_Service__c

• Supplements → Stored in Supplement__c

Logic:

• Records are stored and linked to the identified (or newly created) Plan.

---

Step 2: Care Recipient Individual Contribution API Callout

Purpose: Retrieve the care recipient’s contribution data, indicating the portion of costs they are responsible for under their care plan.

API Endpoint: Care Recipient Individual Contribution API

Input:

• CareRecipientID

Data Returned:

• Array of contribution records → Stored in Individual_Contribution__c

Logic:

• Each record is linked to the Plan and represents a required participant contribution.

---

Step 3: Care Recipient Budgets API Callout

Purpose: Retrieve funding allocation data for the care recipient's plan, including budget breakdowns and specific entitlements.

API Endpoint: Care Recipient Budgets API

Input:

• CareRecipientID

Data Returned:

• Plan Budgets → Stored in Plan_Budget__c

• Entitlements → Child records of budgets → Stored in Entitlement__c

Logic:

• Budgets are linked to the Plan; entitlements are linked to their respective budgets.

• This structure reflects the total available funding for the care recipient.

By progressing through these three stages — summary data, individual contributions, and budgets — the Care Recipient Sync process creates a single, consistent record of all Support at Home information. All retrieved records are stored in their respective objects and related back to the Support at Home Plan & only one active Plan per Care Recipient is maintained.

For a visual representation of this process, please refer to the diagram below: