FHIR R4 server (staff sign-in)
Move care records through FHIR R4 server (staff sign-in) with the right person checking each step.
21 ways to read, 10 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 FHIR R4 server (staff sign-in), an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Book an appointment
appointment.createApproval by rule - Record a visit
encounter.createApproval by rule - List the kinds of records the server holds
server_resource.listRead
Example flow
- FHIR R4 server (staff sign-in) · List the kinds of records the server holds
server_resource.listDone - FHIR R4 server (staff sign-in) · Book an 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 FHIR R4 server (staff sign-in).
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 (staff sign-in)
- FHIR R4 server (staff sign-in)'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.
For developers
Technical detail
Connect a FHIR R4 health record system by having a staff member sign in (SMART standalone launch), for systems that do not offer system-to-system access.
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
- Staff sign-in with your registered app (SMART standalone launch)
- Plans and access
- Servers that support SMART App Launch (standalone launch) for a confidential app you register. Access follows the signed-in staff member's permissions and the scope set chosen at sign-in. Your organisation registers the app and is responsible for its agreements with the health record system.
- Test environment
- Use your vendor's SMART sandbox with synthetic patients in Test mode, then sign in again for Live.
- 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.
- Access ends if the staff member's account is disabled or the server stops renewing the sign-in; sign in again to reconnect.
Developer reference
- Create the HL7 FHIR credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose FHIR R4 server (staff sign-in), 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/fhir-r4-staff-sign-in and the Connections API.