> For the complete documentation index, see [llms.txt](https://knowledge.maica.com.au/maica-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledge.maica.com.au/maica-knowledge-base/maica-administration-guide/residential-aged-care/integration-architecture-and-event-lifecycle/inbound-data-apis.md).

# Inbound Data APIs

Alongside the event APIs that send data to Services Australia, the residential aged care integration includes a set of *inbound* APIs that read data back from Services Australia into Maica. These reads keep a resident's funding picture, balances and confirmed subsidy data current, and they feed the monthly claim and reporting processes.

This article explains what each inbound read provides, where the data lands in Maica, and when it runs. It is written for administrators who need to understand the data flow behind the resident record and the monthly claim.

{% hint style="info" %}
For the authentication and gateway headers shared by every Services Australia call, see [PRODA authentication and setup](/maica-knowledge-base/maica-administration-guide/residential-aged-care/integration-architecture-and-event-lifecycle/proda-authentication-and-setup.md). For the overall data flow and event status model, see [Integration architecture and event lifecycle](file:///). For how the claim and payment reads are orchestrated together into the monthly sync, see [Claims, Payment and Reconciliation Integration](/maica-knowledge-base/maica-administration-guide/residential-aged-care/integration-architecture-and-event-lifecycle/claims-payment-and-reconciliation-integration.md).
{% endhint %}

## How inbound reads work

Inbound APIs are read-only. Maica sends a `GET` request to Services Australia, receives the current data, and writes it onto the relevant Maica records. Nothing is changed at Services Australia by an inbound read.

Three characteristics are common to all inbound reads:

* **They are keyed to a known identity.** Most reads are scoped to a single resident (by their Services Australia care recipient identifier) or to a single service. The resident's identity is established at entry, so inbound reads generally depend on an accepted entry event already existing.
* **They are mapped onto existing Maica records.** Inbound data updates the resident's **Funding** record, **Funding Item** records, the **Claim Batch**, and related classification records, rather than creating standalone copies.
* **They record when they last ran.** The reads that run on a schedule or on demand stamp a last-synchronised date and time so you can see how current the data is.

{% hint style="info" %}
The Care Recipient Details read is the backbone of the resident-level inbound data and has its own dedicated workflow. See [Care recipient details sync](/maica-knowledge-base/maica-administration-guide/residential-aged-care/integration-architecture-and-event-lifecycle/care-recipient-details-sync.md) for how the manual, scheduled and bulk refreshes work.
{% endhint %}

## Resident-level reads

These reads return data about an individual resident and are scoped by the resident's Services Australia care recipient identifier.

### Care Recipient Fee Summary

The Fee Summary read returns the government-published fees and contributions that apply to a resident for a given fee type. It is the reference point for the means-tested amounts that Services Australia has determined for that resident.

{% hint style="warning" %}
By design, the means-tested amounts used in resident billing are entered into Maica manually from the resident's fee advice letter (the SA457), not applied automatically from this read. The Fee Summary read provides the government reference figures; the rates that drive billing are set on the resident's fee arrangement. See [Configuring resident fees](https://app.gitbook.com/s/hehRshYIRk6XUlay9L3b/residential-aged-care/the-manage-racs-agreement-component/configuring-resident-fees-tab) in the User Guide.
{% endhint %}

### Medicare Details

The Medicare Details read returns a resident's Medicare information confirmed by Services Australia.

| Field           | Description                                                       |
| --------------- | ----------------------------------------------------------------- |
| Medicare number | The resident's Medicare card number as held by Services Australia |
| Date of birth   | The resident's date of birth, used to confirm identity matches    |
| Gender          | The resident's recorded gender                                    |
| Expiry date     | The expiry date of the resident's Medicare card                   |

The returned values are written onto the resident's **Funding** record. This read is read-only and is used to confirm and keep the resident's identity details aligned with the Services Australia record.

### Leave and respite balances

Two related reads return the resident's remaining entitlement days:

* **Leave balances** return the remaining social leave and transition (hospital) leave days for the resident.
* **Respite balances** return the remaining residential respite days for the resident.

These reads are typically run before recording a leave or respite period, so that the available balance can be checked before an event is submitted.

{% hint style="info" %}
For how leave and respite are recorded and how the balances are used day to day, see [Managing temporary leave](https://app.gitbook.com/s/hehRshYIRk6XUlay9L3b/residential-aged-care/managing-temporary-leave) and [Managing residential respite care](https://app.gitbook.com/s/hehRshYIRk6XUlay9L3b/residential-aged-care/managing-residential-respite-care) in the User Guide.
{% endhint %}

## Claim and payment reads

These reads return service-level financial data and underpin the monthly claim and the reconciliation and reporting processes.

### Claims

The Claims read is the central financial reconciliation interface. Services Australia calculates the monthly residential care subsidy automatically from the events and classifications submitted during the month, so the provider does not build a claim line by line. Maica reads the calculated position back.

Maica retrieves the full claim for a service and claim month, including the service classifications, the per-resident funding detail, and the registered nurse eligibility data. This is how the confirmed subsidy position is brought into Maica.

When a claim reaches an approved state, the confirmed data is written across several records:

| Record                           | What the claim populates                                                                                                   |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Claim Batch**                  | Confirmed claim status, the Services Australia operational bed count, registered nurse eligibility, and the last sync time |
| **Funding Item**                 | One per resident per claim month, including the supported resident status                                                  |
| **Claim Service Classification** | The service-level classifications confirmed for the month                                                                  |
| **AN-ACC Classification**        | The resident-level AN-ACC classifications confirmed for payment                                                            |

{% hint style="info" %}
The Claims read runs as one step of the monthly Claims Sync, which orchestrates the claim, payment and reconciliation reads together. For the full sequence, see [Claims, Payment and Reconciliation Integration](/maica-knowledge-base/maica-administration-guide/residential-aged-care/integration-architecture-and-event-lifecycle/claims-payment-and-reconciliation-integration.md). For the resident-facing view of claiming, see [The Monthly Claim Batch and Claims Sync](https://app.gitbook.com/s/hehRshYIRk6XUlay9L3b/residential-aged-care/the-monthly-claim-batch-and-claims-sync).
{% endhint %}

{% hint style="warning" %}
The claim month progresses through Services Australia's own approval stages (submitted, being calculated, approved, completed). In the deployed build Maica brings that position in by **reading** the claim through Claims Sync; the claim status on the Claim Batch reflects where Services Australia has the claim. Claim finalisation is a Services Australia-side concept; there is no separate Maica finalise action wired to the Claim Batch in this build.
{% endhint %}

{% hint style="warning" %}
Registered nurse eligibility is returned inside the Claims response and written to the Claim Batch. This is distinct from the separate 24/7 registered nurse coverage check that providers run for their own GPMS reporting (see [24/7 RN coverage check configuration](broken://pages/ead48f8bde308d1a0a4d4727a92d50e6e546c432)), and from the standalone [24/7 RN supplement monthly summary](broken://pages/68b3733591ad1a589341d9270a94f5a048f74871) that Maica reads back separately.
{% endhint %}

### Payment statements

Two reads provide the read-only financial settlement view once Services Australia has paid:

* The **service payment summary** lists the payments made to a service, with their payment identifiers and totals.
* The **payment statement** returns the detail behind an individual payment.

These reads are used to reconcile what Services Australia actually paid against the invoices and claim data held in Maica. The payment statement response also carries resident-level balance figures (remaining respite and social leave) that are sourced from this read rather than from the claim.

{% hint style="info" %}
For how the payment settlement data is matched back to invoices, see [Reconciling payments](https://app.gitbook.com/s/hehRshYIRk6XUlay9L3b/residential-aged-care/reconciling-payments) in the User Guide and [Statement reconciliation service](broken://pages/fe8b02118c9fcf07c851a31f24b20b3e1a7155eb).
{% endhint %}

## Service-level summary reads

The integration also reads data scoped to the whole service rather than an individual resident.

### 24/7 RN Supplement Summary

Maica reads the monthly 24/7 registered nurse supplement summary for the service and stores it against the **Location**, as an entitlement-month summary with claim-month breakdown detail. This read runs as part of the monthly Claims Sync and is scoped by the service's NAPS ID. It applies to residential aged care claims with a Permanent or Respite funding type.

{% hint style="info" %}
For the summary and breakdown records, how they are keyed, and where they surface, see [The 24/7 RN Supplement Monthly Summary](broken://pages/68b3733591ad1a589341d9270a94f5a048f74871).
{% endhint %}

### Service summary and occupancy (design)

The integration design also describes two further service-level reads: a **service summary** (service identifiers, AN-ACC classifications, bed capacity, accreditation, respite allocation, and care minute and 24/7 RN eligibility) and a **service occupancy summary** (daily occupancy confirmed by Services Australia). These are intended to feed the Quarterly Financial Report.

## Where the data is used

Inbound data supports the resident record and the downstream processes:

* **The resident record** reflects current Medicare details, leave and respite balances, and confirmed funding.
* **The monthly claim** is reconciled against the confirmed subsidy and the actual payments.
* **Reporting** draws on the confirmed claim and service data for the Quarterly Financial Report and registered nurse reporting.