Integration platform
Standards in, standards out.
A clinic is never one system. FertiliCore speaks the protocols your hospital, your PACS, your analysers and your registry already use — as five independent connectors on one shared, auditable backbone.
HL7 v2 messaging
HL7 v2.5.1
A bidirectional HL7 v2.5.1 interface with an MLLP listener and outbound client. Inbound ADT keeps demographics in step with the hospital information system; finalised laboratory results are dispatched outbound as ORU messages.
How it worksFHIR R4 API
HL7 FHIR R4
A FHIR Release 4 REST façade that exposes clinical data as standard resources, so modern EHRs, health-information exchanges and partner applications can read from FertiliCore without a bespoke interface.
How it worksDICOM & DICOMweb
DICOM / DICOMweb
A DICOM C-STORE service class provider and DICOMweb endpoints that receive ultrasound and imaging studies from scanners and PACS, and bind them to the patient file and treatment cycle they belong to.
How it worksAnalyzers & time-lapse incubators
ASTM / HL7 ORU
Laboratory device connectivity over ASTM and HL7 ORU, by TCP feed or watched folder, covering hormone and general chemistry analyzers alongside time-lapse embryo incubators.
How it worksNational ART registry
Registry submission
A submission connector for national assisted-reproduction registries, assembling the required cycle and outcome dataset from the clinical record and pushing it to the authority's endpoint on the mandated schedule.
How it worksOne backbone
Five connectors, one place to look when something goes wrong.
Each connector runs as its own service, so a misbehaving analyser feed cannot take the clinical application down with it. What they share is the part you need on the day an interface breaks: the log, the crosswalk and the queue.
Every message logged
Direction, type, external reference, payload, status, error and correlation id — for inbound and outbound alike.
Identifier crosswalk
A record of how each external identifier maps to an internal patient file, so a foreign record is never silently duplicated.
Reliable outbound queue
Claim-locked, retried on failure, reclaimed if stuck, and visible to operators with a manual retry.
Tenant-scoped throughout
Connector configuration, message log and crosswalk all sit behind the same row-level isolation as clinical data.
Nothing is on by default.
Installing FertiliCore changes nothing about what your network talks to. Every connector arrives disabled. Every endpoint and every credential arrives empty. There is a master switch above all five, and it is off. Until an administrator configures a transport and turns it on, the integration services sit idle and say so in the log.
Integration questions your IT team will ask
Does anything start talking to our systems the moment FertiliCore is installed?
No. Every connector ships disabled, with no endpoint and no credential configured, behind a master switch that is also off. Listeners bind no socket and watch no folder until an administrator configures and explicitly enables them. Nothing leaves your network by accident.
Where are integration credentials stored?
Connector settings live in the system settings store. Secrets — credentials, tokens, API keys — are encrypted at rest and are never returned in plaintext by the administration API; the interface shows them only as set or unset, and they can be overwritten but not read back.
What happens when the partner system is unavailable?
Outbound messages go through a reliable queue rather than a direct send. Entries are claimed with row-level locking so multiple instances never double-send, failures are retried, a stuck send is reclaimed automatically, and operators can watch and retry the queue from a dedicated screen.
Can we see exactly what was sent and received?
Yes. Every inbound and outbound message is recorded with its direction, type, external reference, full payload, processing status, any error and a correlation identifier. An external-to-internal identifier crosswalk records how each foreign record was matched to a patient file, so a mismatch can be traced rather than guessed at.
Do the integration services write to the clinical database directly?
No, and this is deliberate. Each connector calls the clinical application's own ingestion API rather than writing tables. An externally sourced record therefore passes through the same validation, the same permission checks and the same audit trail as one typed in by a clinician.
Send us your interface specification
Tell us which HIS, PACS, analysers and registry you run. We will come back with a written statement of what maps cleanly, what needs work, and what we cannot do.