log_type and build an Olira-shaped payload yourself. With an absorber, you hand over data in its native format and it produces the right events for you.
Absorbers sit in front of the same ingestion pipeline as regular logs: whatever they emit is validated against the event catalog, written as logs, and compiled into patient state like any other submission.
One input may produce zero events (unsupported or unmappable content), one event, or several. A FHIR CarePlan, for example, can yield both clinical_plan_item and treatment_phase.
FHIR absorber
The FHIR absorber accepts FHIR R4 resources and is the mapper behind every FHIR entry point on the platform:- EMR integrations: Epic and Cerner integrations stream resources through it automatically.
- SDK and REST:
log_fhir()(POST /v1/fhir/resource) submits a single resource from your codebase. - Console upload: FHIR files uploaded through the Console.
- Historical ingestion: FHIR-formatted backfill jobs.
Observation, Condition, MedicationRequest, DiagnosticReport, DocumentReference, and CarePlan. Observation resources are routed by category and LOINC code to the appropriate event type (vitals, labs, genomics, functional class, and so on).
The full resourceType → event type matrix, per-resource examples, and error cases live in the log_fhir reference.
Single resources vs bundles
Reference resolution depends on the entry point:- Bundles (integrations, historical ingestion): linked resources are resolved together. Panel
DiagnosticReportresults reference theirObservationentries, vital-signs Observations at the same timestamp merge into onevitals_measurement, and medication resources see their siblingMedicationentries. - Single resources (
log_fhir): each call is processed alone; cross-resource references are not resolved. Use historical ingestion or an EMR integration for multi-resource imports.

