Events

An event in RCM is one clinical encounter. The exact term varies by country:

Country	Local term	Examples
Brazil	atendimento	Internação, atendimento ambulatorial, atendimento de pronto-socorro
Colombia	episodio	Episodio de hospitalización, episodio ambulatorio
Other LATAM	atención	Same concepts, different label
Internationally	encounter / episode of care	—

This page uses "event" as the canonical English term used in the API (e.g. origin_event_id).

An event captures the clinical side of what happened:

• Which patient
• What kind of service (consultation, surgery, ER visit, diagnostic, etc.)
• When it happened
• Under which payer agreement it should be billed
• The diagnoses and procedures recorded by the provider

This is distinct from the account, which is the billing wrapper that may group one or more events from the same patient.

How events are created

You don't create events explicitly via a "create event" endpoint. Instead, RCM creates them implicitly when you send the first charge that references a new origin_event_id:

So in practice you only ever send charges — and RCM derives the event + account from the origin_event_id and the patient/agreement information embedded in the charge request.

What lives on an event

Field	Description
origin_event_id	Your HIS/PMS identifier for this encounter. Required, used as the deduplication key. Stable across re-submissions of charges.
service_type	One of CONSULTATION, HOSPITALIZATION, EMERGENCY, DIAGNOSTIC, etc. Determined by the service_type_code on the first charge.
patient_id, patient_name, patient_document_type, patient_document_number	Patient information at the time of service.
agreement_code	Which provider-payer contract applies to this encounter.
origin_event_creation_date_time	When the encounter happened in the HIS (not when RCM received the data).
cost_center_code, cost_center_name	Provider-internal accounting reference.
base_event	true for the primary encounter, false for related secondary events (see below).

Base events vs secondary events

Inside an account you can have:

• One base event — the main atendimento (e.g. the hospital admission).
• Zero or more secondary events — related encounters that should be billed together (e.g. an outpatient follow-up visit that's part of the same surgical package, an interconsultation requested during a stay).

Secondary events use parent_event_id on the charge request to link to the base event. RCM keeps them as separate Event records so the clinical history stays accurate, but groups them into the same Account for billing.

Updating event data

Event-level data is set on event creation, from the first charge that referenced its origin_event_id. Resending a charge with the same origin_event_id does not overwrite event-level fields — only charges and support files keep being added. To change event data after the fact, call one of these endpoints explicitly:

• PUT /v1/events/origin-events/{originEventId} — update the event header: patient data, description, agreement plan type, cost center, service type. This is the endpoint to use when the encounter data changes in your HIS. A header-only change applies synchronously (200); changing the service type is asynchronous (202 + Location), because the event's charges have to be reclassified — poll getPendingEventModificationById until it reaches a terminal status.
• PUT /v1/events/origin-events/{originEventId}/agreement-codes/{agreementCode}/cost-center — change only the cost center, scoped to one agreement. Applies synchronously.
• PUT /v3/accounts/origin-events/change-of-payer — change the agreement / payer for the whole event (and optionally a subset of its charges). Allowed only while no item has been invoiced.
• POST /v1/accounts/additional-data — attach a settlement protocol number to an event/account.
• POST /v1/accounts/additional-data/external-id — attach a guide (external_id) to a specific event by origin_event_id.

Looking up an event

The canonical lookup is by origin_event_id:

curl -X GET "https://sandbox.osigu.com/rcm/v1/accounts/base-accounts/origin-events/EVT-12345/deep-info" \
  -H "Authorization: Bearer $TOKEN"

Returns the full event + its account + linked charges + support files. See getDeepBaseAccountInfoByOriginId.

You can also list events indirectly through dispatch packages (groupings of events sent to a payer) — see Account dispatch lookups.

Related concepts

• Accounts — the billing wrapper that groups one or more events.
• Charges — the billable lines that attach to an event.
• Support files — documentation that justifies what happened on the event.