Skip to Content
FHIR

FHIR integration

Xenrad exposes a FHIR R4 JSON API for site-scoped clinical data. You authenticate with a site-scoped API key in the X-API-Key header. There is no separate FHIR user. The key is bound to a site and resolves to its owning user.

Standard and auth

The server speaks FHIR R4. The capability statement reports 4.0.1. Prefer application/fhir+json. Auth is always the site API key header. Create the key in Horizon first, store it once when it is revealed, then call the FHIR host your environment publishes.

Base URL — https://fhir.stg.xenrad.io/fhir (for example https://fhir.stg.xenrad.io/fhir/Patient). Capability metadata: GET https://fhir.stg.xenrad.io/fhir/metadata.

A normal call

Send the key and the FHIR content types:

X-API-Key: <api_key>
Accept: application/fhir+json
Content-Type: application/fhir+json

Search is GET /fhir/{ResourceType}?…. Read is GET /fhir/{ResourceType}/{id}. Create is POST /fhir/{ResourceType}. Update is PUT /fhir/{ResourceType}/{id}. The server resolves the key to a site and runs the request inside that boundary. DELETE is not supported for the clinical resources below.

What you can work with

Patient holds master demographics, identifiers, and contact points. Condition and AllergyIntolerance cover problem list and allergies. Observation and Procedure hold coded or textual clinical events. DiagnosticReport surfaces structured radiology or clinical reports that already exist inside Xenrad. DocumentReference holds document metadata and the content pointers your mapping supports.

If a resource type is not on that list, do not invent support from a generic FHIR tutorial. The capability statement is the source of truth for your environment.

Patient search understands identifier, name (case-insensitive substring), birthdate, and gender. With no query parameters you get all patients in the site attached to the key.

Condition and AllergyIntolerance take patient as Patient/{uuid}, plus clinical-status and code when you need them. Observation and Procedure take patient and code. DocumentReference takes patient and type. DiagnosticReport takes patient, and status=final maps to completed reports while other status values map toward drafts.

Search responses are FHIR Bundles with type: searchset.

Writing data

POST creates and the server assigns an id. PUT updates an existing id for that site. Patient writes commonly map name[0].text, identifier[0].value, telecom by system, address fields, gender, and birthDate. Other resources expect references like Patient/{id} in subject or patient fields. When the body is wrong, the server answers with OperationOutcome. Read diagnostics first.

Errors and a first smoke test

Failures use FHIR OperationOutcome JSON with issue entries. A good first smoke test is metadata, then a patient search by name:

curl -sS \
  -H "X-API-Key: $XENRAD_API_KEY" \
  -H "Accept: application/fhir+json" \
  "$FHIR_BASE/fhir/Patient?name=smith"

HL7 can feed the same patient store from v2 events. MPPS is a different host for procedure-step sessions. Imaging still arrives over DICOM, not FHIR.

API keysHL7