Nexra
Start in the sandbox
All connectors

FHIR R4 server

Healthcare systems

Move care records through FHIR R4 server with the right person checking each step.

21 ways to read, 10 ways to write, each write switched on by you.

Try this in the sandboxBring us a workflow

Quality checks

Built and tested with example responses.

  1. Ready to connect: doneEvery listed action is built in.
  2. 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.
FHIR R4 server with Nexra

Connected, approved, proven.

The things teams do most with FHIR R4 server, an example flow with a person in the loop, and what Nexra keeps as proof.

Top actions

  • Book an appointmentappointment.createApproval by rule
  • Record a visitencounter.createApproval by rule
  • List the kinds of records the server holdsserver_resource.listRead

Example flow

  1. FHIR R4 server · List the kinds of records the server holdsserver_resource.listDone
  2. FHIR R4 server · Book an appointmentappointment.createMaker-checker
  3. 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 FHIR R4 server.

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 FHIR R4 server
  • FHIR R4 server'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 a HL7 FHIR test account before you go live.

Try this in the sandboxBring us a workflow

For developers

Technical detail

Connect any FHIR R4 health record system: find patients, book appointments, record visits and observations, follow claims, and start flows when records change.

HL7 FHIR API docs
Source actions
21
Destination actions
10
Data types
13

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
  • Book an appointmentDestinationNot retried automaticallyApproval before production

    Book an appointment for a patient with a practitioner. Status is booked unless you choose proposed or pending.

  • Get a appointmentSource

    Read one appointment by its record ID, with minimum-necessary fields.

  • Find appointmentsSourceIncremental

    Search appointments with validated filters sent in the request body.

  • Reschedule or update an appointmentDestinationProvider duplicate protectionApproval before production

    Move an appointment, or mark it arrived, checked in, fulfilled or no-show. Cancelling stays with people in the record system.

claim2
  • Get a claimSource

    Read one claim by its record ID, with minimum-necessary fields.

  • Find claimsSourceIncremental

    Search claims with validated filters sent in the request body.

encounter4
  • Record a visitDestinationNot retried automaticallyApproval before production

    Record a visit (encounter) for a patient, for example a finished home visit with its start and end time.

  • Get a visitSource

    Read one visit by its record ID, with minimum-necessary fields.

  • Find visitsSourceIncremental

    Search visits with validated filters sent in the request body.

  • Update a visitDestinationProvider duplicate protectionApproval before production

    Change a visit's status or times, for example mark it finished.

invoice2
  • Get a invoiceSource

    Read one invoice by its record ID, with minimum-necessary fields.

  • Find invoicesSourceIncremental

    Search invoices with validated filters sent in the request body.

medication request3
  • Suggest a medication for clinician reviewDestinationNot retried automaticallyApproval before production

    Add a medication proposal or plan for a clinician to review and sign in the record system. Nexra never issues prescriptions.

  • Get a medication requestSource

    Read one medication request by its record ID, with minimum-necessary fields.

  • Find medication requestsSourceIncremental

    Search medication requests with validated filters sent in the request body.

observation3
  • Record an observationDestinationNot retried automaticallyApproval before production

    Record a measurement such as a blood pressure or weight reading, coded with LOINC where possible.

  • Get a observationSource

    Read one observation by its record ID, with minimum-necessary fields.

  • Find observationsSourceIncremental

    Search observations with validated filters sent in the request body.

patient by identifier1
  • Find patient by record numberSourceIncremental

    Find a patient by a business identifier such as a medical record number (system|value).

patient by phone1
  • Find patient by phoneSourceIncremental

    Find patients by phone number. The number is sent in the request body, and contact details are not returned.

patient4
  • Register a patientDestinationNot retried automaticallyApproval before production

    Add a patient record with name, date of birth, gender and optional contact details.

  • Get a patientSource

    Read one patient by its record ID, with minimum-necessary fields.

  • Find patientsSourceIncremental

    Search patients with validated filters sent in the request body.

  • Update patient detailsDestinationProvider duplicate protectionApproval before production

    Change a patient's name, date of birth, gender, contact details or active flag.

practitioner4
  • Add a practitionerDestinationNot retried automaticallyApproval before production

    Add a practitioner to the server's directory.

  • Get a practitionerSource

    Read one practitioner by its record ID, with minimum-necessary fields.

  • Find practitionersSourceIncremental

    Search practitioners with validated filters sent in the request body.

  • Update practitioner detailsDestinationProvider duplicate protectionApproval before production

    Change a practitioner's name, title, qualification or active flag.

server resource1
  • List the kinds of records the server holdsSource

    One entry per kind of record (Patient, Appointment and so on) with what the server lets apps do with it and which searches it supports.

server1
  • Check what the server offersSource

    Read the server's capability statement: FHIR version, which kinds of records it holds, whether it can notify Nexra of changes, and its sign-in addresses.

sign in details1
  • Check the server's sign-in detailsSource

    Read the server's SMART configuration: token and sign-in addresses, supported sign-in methods and SMART capabilities.

Access and limits

Authentication
Your registered app (SMART Backend Services or client credentials)
Plans and access
Any server that implements the FHIR R4 REST API. Hosted health record systems need an app you register with them (SMART Backend Services or client credentials). Your organisation registers its own app with the health record system and grants it only the scopes your flows need. A business associate or data processing agreement with that system is your organisation's responsibility.
Test environment
Test mode works with the public test server at https://hapi.fhir.org (server path /baseR4, sign-in: public test server) or your vendor's own sandbox with synthetic patients.
Rate limits
Each server sets its own limits. HTTP 429 and 503 use bounded retries and Retry-After.
Pagination
Searches send _count in the POST _search body and follow the Bundle's next link for further pages.
Provider events
FHIR R4 Subscriptions (rest-hook) notify a URL when matching records change. Flows can start the moment something happens: when an appointment is booked or changes; when a visit is recorded or changes; when a patient is registered or their details change; when an observation is recorded.

Before you build a flow

  • Minimum necessary: mappings leave out addresses, contact details, photos, notes and attachments; searches keep values out of the first request URL.
  • No deletes. Appointments are not cancelled and orders are not signed from Nexra; medication writes are draft proposals or plans only.
  • Updates use JSON Patch; servers without JSON Patch support refuse them (reads, bookings and new records still work).
  • Change notifications need the server to support FHIR R4 Subscriptions (rest-hook); otherwise use a scheduled check, which reads records changed since the last run.
  • Run evidence from this connector is hidden in the console by default and kept for a short time, and it is never sent to an AI model unless the workspace allows it.
  • Each request asks for the narrowest scope it needs, so the server issues several short-lived tokens; servers that ignore the requested scope use the scopes granted to your app.

Developer reference

  1. Create the HL7 FHIR credentials described above with the narrowest permissions your flows need.
  2. In Nexra, open Connect, then Connections, then New connection, choose FHIR R4 server, enter its settings and credentials, and tick only the write actions you need. Connection guide
  3. Test the connection, then use its actions as flow sources and destinations. Flow guide
HL7 FHIR docsAPI referenceHL7 FHIR docsAuthenticationHL7 FHIR docsWebhooks

Machine-readable detail: GET /api/public/connect/connectors/fhir-r4 and the Connections API.