HL7 FHIR R4
FHIR R4 — a standards-based API onto the fertility record
FertiliCore exposes a FHIR R4 facade over the clinical record. It serves a real CapabilityStatement, answers RESTful reads and searches with searchset Bundles, and accepts Observation and Patient writes through the same validated ingestion path the other connectors use. Errors are returned as OperationOutcome.
- Real R4 CapabilityStatement at the metadata endpoint
- Reads served as searchset Bundles
- Observation and Patient write seam
- Standards-compliant OperationOutcome diagnostics
Why a FHIR endpoint matters now
FHIR has become the common language of healthcare interoperability. National exchanges, patient-facing applications, payer and provider APIs and modern EHRs all expect it, and procurement increasingly asks for it by name. Without a FHIR endpoint, every partner integration becomes a bespoke export: a file format negotiated once, maintained by hand, and broken the next time either side changes. A standards-based read and write API replaces that with something a partner's integration engineer can discover for themselves.
What the facade exposes
Rather than pipe-delimited messages, FHIR models data as resources addressed by URL. FertiliCore projects the clinical record as standard R4 resources and maps incoming resources back onto clinical data. The metadata endpoint returns a genuine CapabilityStatement describing what the server supports, which is the first thing any FHIR client calls. Reads are served either as a single resource by identifier or as a searchset Bundle from a search, and every error comes back as an OperationOutcome so clients get diagnostics they can parse.
- Patient, from the patient file and demographics
- Appointment, from the scheduler
- Observation, from laboratory results and measurements
- DiagnosticReport, from grouped results
- Specimen, covering oocyte, sperm, embryo and laboratory samples
Reads go through a projection layer, not the tables
The FHIR service does not query the clinical database. It fetches protocol-neutral projections from the clinical application's own read-back endpoints and maps those onto FHIR resources. That separation matters for two reasons: the facade stays decoupled from the clinical data model, so schema changes do not silently alter what a partner sees, and every read is subject to the clinical service's own authorisation. If no read source is configured, the facade says so plainly rather than returning partial data.
Writes take the same validated path as everything else
An incoming Observation, Patient or transaction Bundle entry is mapped to a clinical data transfer object and posted to the clinical ingestion API over authenticated service-to-service HTTP. The integration service never writes clinical tables directly, so an externally sourced record passes through the same validation and audit path as one typed in by a clinician. Writes are deliberately limited to the safe Observation and Patient seam rather than opening every resource type for update.
The shared backbone
The FHIR connector sits on the same backbone as the other four. Every resource served and every resource ingested is recorded with direction, type, external reference, payload and status, so a partner's complaint about a missing record can be answered from the log. An external-to-internal identifier crosswalk stops a repeated write from creating a duplicate patient. Everything is tenant-scoped, and the connector's own credentials are stored encrypted and never returned in plaintext by the administration API.
Scope, stated plainly
Integration projects fail on the assumption, not the protocol. Here is what this connector does and does not do today.
Supported today
- CapabilityStatement, resource read, search and searchset Bundle responses
- Live reads served from the clinical service's read-back projections
- Observation and Patient writes through the clinical ingestion API
- Transaction Bundle entries ingested entry by entry
- Mappers validated by round-trip through the Firely R4 parser
- Configurable client authentication and default search page size
- Message log, identifier crosswalk and tenant scoping on every call
Not yet covered
- True all-or-nothing transaction Bundle rollback is a documented seam; entries are ingested individually today
- Outbound push to a peer FHIR server is not built; the facade is a server, not a client, in production use
- Writes are limited to the Observation and Patient seam rather than the full resource catalogue
- The connector ships disabled with an empty endpoint and no client credentials, and no certification or conformance testing is claimed
Common questions
Who is allowed to call the FHIR endpoint?
That is a deployment decision your team makes. The connector supports no authentication, basic, API key or bearer client authentication, configured per site, and it ships disabled with no credentials seeded. Separately, the service authenticates itself to the clinical API with a service key and tenant header, so the read-back and ingestion endpoints are genuinely authenticated rather than merely permission-gated. All secrets are stored encrypted and never returned in plaintext.
Is it a FHIR server or a FHIR client?
A server. External systems read resources from it and write Observations and Patients to it. Outbound push to a partner's FHIR server is a documented seam that is not built, so if your architecture requires FertiliCore to POST resources to a national exchange on a schedule, that is work to scope rather than something to switch on. The connector's endpoint setting exists for that future peer-server case.
How do we find out what it supports without reading documentation?
Call the metadata endpoint. It returns a genuine R4 CapabilityStatement, which is FHIR's machine-readable self-description and the conventional first call from any client. It is also a useful capability and liveness probe for monitoring. Beyond that, every error response is an OperationOutcome, so a client can distinguish an unsupported search parameter from a genuine failure.
Are FHIR reads and writes auditable?
Yes. Resources served and resources ingested are recorded in the message log with direction, type, external reference, payload and status, filterable by connector and direction. Because writes go through the clinical application's ingestion API rather than direct table access, the resulting clinical record also carries the normal clinical audit trail showing what changed and when.
Do we have to use FHIR instead of HL7 v2?
No, and most hospital groups will use both. HL7 v2 over MLLP is what existing hospital information systems speak, and it remains the practical path for demographics and routine results. FHIR is the cleaner seam for modern partners, patient applications and exchanges that will not accept legacy messaging. The two connectors are independent and can be enabled separately.
Other connectors
See FertiliCore against your own workflow
A working walkthrough with one of our clinical engineers — patient file to live-birth outcome, plus the integration and deployment questions your IT team will ask. No obligation, and no sales script.