Medplum
Move care records through Medplum with the right person checking each step.
20 ways to read, 6 ways to write, each write switched on by you.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with Medplum, an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Propose appointment
appointment.createApproval by rule - Create draft communication
communication.createApproval by rule - Get appointment
appointment.getRead
Example flow
- Medplum · Get appointment
appointment.getDone - Medplum · Propose appointment
appointment.createMaker-checker - Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches Medplum.
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to Medplum
- Medplum's reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect your own account when you are ready to go live.
For developers
Technical detail
Medplum FHIR R4 patients, practitioners, encounters, observations, conditions, medications, appointments and tasks, with safe task and draft writes.
Medplum API docs- Source actions
- 20
- Destination actions
- 6
- Data types
- 10
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
appointment4
- Propose appointmentDestinationNot retried automaticallyApproval before production
Create an Appointment with status proposed. It is not booked; participants are added as needs-action.
- Get appointmentSource
Read one FHIR Appointment by resource ID with minimum-necessary fields.
- Search appointment recordsSourceIncremental
Search FHIR Appointment resources with validated parameters sent in the request body.
- Edit appointment proposalDestinationProvider duplicate protectionApproval before production
Edit an Appointment that is still proposed. The patch fails if it has been booked or cancelled.
communication4
- Create draft communicationDestinationNot retried automaticallyApproval before production
Create a Communication with status preparation (a draft). Nexra does not send it.
- Get communicationSource
Read one FHIR Communication by resource ID with minimum-necessary fields.
- Search communication recordsSourceIncremental
Search FHIR Communication resources with validated parameters sent in the request body.
- Edit draft communicationDestinationProvider duplicate protectionApproval before production
Edit a Communication that is still a draft (status preparation). The patch fails if it is no longer a draft.
condition2
- Get conditionSource
Read one FHIR Condition by resource ID with minimum-necessary fields.
- Search condition recordsSourceIncremental
Search FHIR Condition resources with validated parameters sent in the request body.
encounter2
- Get encounterSource
Read one FHIR Encounter by resource ID with minimum-necessary fields.
- Search encounter recordsSourceIncremental
Search FHIR Encounter resources with validated parameters sent in the request body.
medication request2
- Get medication requestSource
Read one FHIR MedicationRequest by resource ID with minimum-necessary fields.
- Search medication request recordsSourceIncremental
Search FHIR MedicationRequest resources with validated parameters sent in the request body.
observation2
- Get observationSource
Read one FHIR Observation by resource ID with minimum-necessary fields.
- Search observation recordsSourceIncremental
Search FHIR Observation resources with validated parameters sent in the request body.
organization2
- Get configured organisationSource
Read the configured Organization (or another organisation by ID) within the token's Medplum project and access policy.
- Search organisation recordsSourceIncremental
Search FHIR Organization resources with validated parameters sent in the request body.
patient2
- Get patientSource
Read one FHIR Patient by resource ID with minimum-necessary fields.
- Search patient recordsSourceIncremental
Search FHIR Patient resources with validated parameters sent in the request body.
practitioner2
- Get practitionerSource
Read one FHIR Practitioner by resource ID with minimum-necessary fields.
- Search practitioner recordsSourceIncremental
Search FHIR Practitioner resources with validated parameters sent in the request body.
task4
- Create taskDestinationNot retried automaticallyApproval before production
Create a FHIR Task for care coordination or back-office work.
- Get taskSource
Read one FHIR Task by resource ID with minimum-necessary fields.
- Search task recordsSourceIncremental
Search FHIR Task resources with validated parameters sent in the request body.
- Update taskDestinationProvider duplicate protectionApproval before production
Change supplied Task fields with JSON Patch; omitted fields are left unchanged.
Access and limits
- Authentication
- Medplum access token (Bearer)
- Plans and access
- Medplum project with a ClientApplication or user access token governed by an AccessPolicy. Grant the smallest AccessPolicy that covers the resources the flow needs (minimum necessary). A Business Associate Agreement with Medplum is the customer's responsibility for PHI.
- Test environment
- Use a non-production Medplum project with synthetic patients.
- Rate limits
- Medplum limits requests per IP per minute (6,000 free, 60,000 paid) and weights FHIR interactions (read 1, search 20, write 100 points). HTTP 429 uses bounded retries and Retry-After.
- Pagination
- Search uses _count and _offset in the POST _search body (offset capped at 10,000); continues while Bundle.link has next.
- Provider events
- Medplum Subscriptions (rest-hook) deliver resource changes. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.
Before you build a flow
- Minimum necessary: mappings omit telecom, addresses, photos, notes on clinical resources and attachments. Search by email or phone is not offered.
- No deletes, cancellations or $expunge. Appointment $book, $cancel and $reschedule, MedicationRequest writes, Patient writes and clinical resource writes are intentionally excluded.
- Appointment writes only create or edit status=proposed appointments; Communication writes only create or edit status=preparation drafts. Edits apply a JSON Patch test on status, so a booked appointment or sent message is never changed.
- Task updates cannot set cancelled, rejected, failed or entered-in-error.
- Access tokens are not refreshed automatically; replace the stored token when it expires (Medplum tokens default to one hour) or use a long-lived ClientApplication token.
- Medplum Bots or Subscriptions in the customer's project may act on Nexra writes; review project automation before enabling writes.
Developer reference
- Create the Medplum credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose Medplum, enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/medplum and the Connections API.