Get the data

Once a patient connects, Medblocks pulls their records from the facility or payer they approved in the background. This page is how those records reach the systems your team actually works in.

There is one path today, and one coming. Today you configure an export and Medblocks pushes records to a destination you own. The direct FHIR read API, where your backend reads a connected patient’s records straight from the SDK, is coming next. The rest of this page covers both honestly so you can build on what ships now.

Export to your systems

Set up an export and Medblocks delivers the records for you. After a patient’s connection goes active and a pull settles, Medblocks sends the new and changed records to a destination you configure in the dashboard. You write no delivery code, and you do not poll or pull file by file. The records arrive where you already query them.

You pick the destination type that matches where your team works.

• A FHIR server, when another system should receive FHIR R4 resources.
• Object storage, when a warehouse or lakehouse ingests files. Medblocks writes the records as NDJSON or zipped NDJSON to S3, GCS, or Azure Blob.

You add a destination, Medblocks runs a first backfill, and every later pull sends only what changed since the last run. Each destination runs on its own, so one failing does not block another. You set this up once in the dashboard, not per patient and not in code.

Data out walks through configuring delivery, the destination choices, and how exports fit with events and API reads.

Direct FHIR reads (coming soon)

Exports push records to a destination on Medblocks’ schedule. The direct read API will let your backend pull a connected patient’s records on demand instead, reading them straight through the SDK or API once a connection is active.

It will be FHIR-native, including the $everything operation. $everything is the FHIR operation that returns a patient’s full record as a single bundle, so one call gives you their complete connected history rather than a resource at a time. That suits a few cases exports do not cover as cleanly.

• Pull a connected patient’s current records into your own backend, on demand.
• Run an on-demand refresh right after a patient finishes a patient session.
• Build workflows that need FHIR resources in the moment, rather than files delivered later.

The shape will follow the path you already build. Create the patient, start a patient session, let the patient approve access, wait for the connection to go active (see After connection), then read. When it ships it will appear in the SDK and the API reference. Until then, exports cover the same ground for getting records out.

See also