Complete a claim after service is rendered
Once a service has been rendered, you file a claim — the record of what actually happened, which the sponsor uses to pay the provider. This guide covers the outpatient-care claim, which is the most common shape. The medical-procedure claim follows the same pattern but with a narrower scope (one procedure, one authorization).
Before starting, make sure you understand Claims — this guide shows how; the concept page explains why.
Prerequisites
- A completed pre-authorization (
authorization_id) for the service just rendered. You can also file a claim without an authorization for some countries — the sponsor's rules apply. - The provider products for the line items are already registered.
- Access to an OAuth token with
arc:writescope.
1. Create the claim shell
curl -X POST "https://sandbox.osigu.com/arc/v1/outpatient-care-claim" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"beneficiary_id": "bnf_01HW8GQ2KMNP3F4R5T6Y7U8I9O",
"sponsor_slug": "sponsor-sandbox",
"authorization_id": "auth_01HXA...",
"diagnosis_code": "R51",
"line_items": [
{ "product_code": "CONS-GEN", "product_type": "PROCEDURE", "quantity": 1 },
{ "product_code": "LAB-HEMO", "product_type": "LAB", "quantity": 1 }
]
}'
Response (201):
{
"claim_id": "clm_01HXBFP...",
"status": "OPEN",
"created_at": "2026-06-25T14:00:12Z"
}
The claim is now OPEN — you can still modify it, add attachments, or void.
2. Retrieve to inspect
curl "https://sandbox.osigu.com/arc/v1/outpatient-care-claim/clm_01HXBFP..." \
-H "Authorization: Bearer $TOKEN"
Verify each line item is what you meant. The response also lists any authorization files inherited from the pre-authorization step — those follow the claim automatically.
3. Attach any additional evidence (optional)
If the sponsor accepts post-service evidence — a signed patient discharge note, an itemised invoice — list attached files with getClaimAuthorizationFiles. Additional documents are usually uploaded via the settlement-batch flow (for Dominican Republic) or via the pre-authorization step (for real-time sponsors).
4. Complete the claim
Signal Osigu the claim is closed and ready to be included in the next settlement / real-time submission:
curl -X POST "https://sandbox.osigu.com/arc/v1/providers/$PROVIDER_SLUG/outpatient-care-claim/clm_01HXBFP.../complete" \
-H "Authorization: Bearer $TOKEN"
Response (200):
{
"claim_id": "clm_01HXBFP...",
"status": "COMPLETED",
"completed_at": "2026-06-25T14:10:44Z"
}
Once COMPLETED you can no longer edit line items. To fix a mistake, void and re-create.
5. Void if you need to unwind
Before the claim reaches SETTLED, you can cancel it:
curl -X POST "https://sandbox.osigu.com/arc/v1/outpatient-care-claim/clm_01HXBFP.../void" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"reason":"Wrong diagnosis code"}'
After it's in SETTLED, void isn't allowed — you'd have to work with sponsor operations to reverse.
Medical-procedure claim variant
Same pattern, different endpoint:
- Create →
POST /arc/v1/medical-procedure-claim - Retrieve →
GET /arc/v1/medical-procedure-claim/{id}
Single line item, always tied to an authorization. No complete call — it goes straight to COMPLETED on creation because there are no line items to add later.
Related
- Issue a pre-authorization — prerequisite.
- Submit a settlement batch — how completed claims move to
SETTLEDin the RD flow. - Concept: Claims.