Registry submission
ART registry reporting — validated before it leaves the building
FertiliCore builds national and international ART registry submissions directly from treatment cycle and outcome data. Datasets for the Turkish Ministry of Health, ESHRE EIM and SART CORS layouts are validated before they are queued, delivered through a retrying outbound queue, and tracked to a final status.
- Turkish Ministry of Health, ESHRE EIM and SART CORS layouts
- Validation runs before anything is queued
- Reliable queue with retry and per-submission status
- Reporting reminders raised on your schedule
Registry reporting is a legal obligation and a manual mess
A licensed fertility centre generally has to report its outcomes to a national ART registry, and many also report to an international one for benchmarking. In most clinics this is an annual scramble: someone exports cycles to a spreadsheet, reconciles them against the registry's field definitions by hand, discovers the mismatches only when the submission is rejected, and repeats. The data was in the system all along; the process around it was the problem.
Datasets built from the cycle record itself
FertiliCore builds each registry's dataset from treatment cycle and outcome data using a dedicated export builder per format, so the field layout each registry expects is produced by code rather than assembled by hand. An operator picks a reporting period and a format and triggers the build; nothing is scraped from a report or re-typed. Because the builders read the same cycle records the clinic works in daily, improving the completeness of the submission is the same work as keeping the clinical record complete.
- Turkish Ministry of Health national cycle dataset
- ESHRE EIM European registry layout
- SART CORS United States clinic outcome layout
Validation happens before queueing, not after rejection
The submission workflow is build, then validate, then queue. Schema and field validation runs first, so a malformed dataset never reaches the registry endpoint and never consumes a submission attempt. That inverts the usual sequence, in which the registry's own rejection message is the first indication that something is wrong. Failures surface as a validation result the operator can act on immediately, while the reporting deadline is still comfortably distant.
Delivery is queued, retried and tracked
A validated submission is placed on the same reliable outbound queue the other connectors use. A worker drains it and posts to the configured registry endpoint, marking the submission sent or failed with a bounded retry. Deliveries are claim-locked so multiple workers never double-submit, and a row stranded by a crashed worker is returned to the queue automatically. An operator screen shows each submission's period, format, attempt count, status and last error, and a submission that has exhausted its automatic retries can be retried by hand once the cause is fixed.
Reminders, audit trail and the shared backbone
A reminder can be raised through the notification engine on the reporting cadence you configure, so an annual obligation does not depend on someone remembering it. Every submission attempt is recorded with direction, type, external reference, payload and status, giving a defensible audit trail of what was sent to which registry and when. The connector is tenant-scoped, its credentials are stored encrypted and never returned in plaintext, and it reads clinical data through the clinical application's own API rather than querying tables directly.
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
- Export builders for the Turkish Ministry of Health, ESHRE EIM and SART CORS layouts
- Schema and field validation before a submission is queued
- Reliable outbound queue with bounded retry and claim-locking
- Per-submission status tracking with attempt count and last error
- Operator screen for validating, submitting and reviewing by period and format
- Reporting reminders raised through the notification engine
- Full audit trail of every submission attempt, tenant-scoped
Not yet covered
- The live submission push stays in dry run until an endpoint and credentials are configured; nothing is seeded and no credentials are fabricated
- Submissions are operator-triggered or scheduled batches, not an unprompted real-time feed
- Registry field definitions change; a layout revision by a registry is a maintenance item, not something the connector absorbs automatically
- No registry accreditation, certification or conformance testing is claimed
Common questions
What stops a bad dataset reaching the registry?
Validation runs before queueing rather than after submission. The dataset is built from cycle data, checked against the format's schema and field rules, and only then placed on the outbound queue. A dataset that fails validation is never queued, so it cannot consume a submission attempt or generate a rejection from the registry. The operator sees the validation result and can correct the underlying records.
What happens if the registry endpoint is unavailable?
The submission waits. Deliveries sit on a transactional queue and a worker retries a failing push with a bounded attempt count; once automatic retries are spent the row becomes terminal and is flagged with its last error. An operator screen lists queued submissions by status with the payload and attempt count, and a failed submission can be retried by hand after the cause is addressed. Disabling the connector pauses delivery without discarding queued rows.
Can we report to more than one registry?
Yes. The three formats are independent builders selected per submission, so a centre reporting nationally and to ESHRE generates a submission per format for the same period. Each submission is queued, tracked and audited separately. The connector's endpoint and credentials are configured per site according to your reporting agreement.
Where do the registry credentials live?
In encrypted settings, written through the administration API and never returned in plaintext — the interface shows them only as set or unset with overwrite-only editing. Nothing is seeded: the connector ships disabled with an empty endpoint and no credentials, and the push worker stays in dry run until both are supplied. That means installing FertiliCore cannot cause an unintended submission.
Is there a record of what we submitted?
Yes, and it is the point of doing this through a connector rather than a spreadsheet. Every submission attempt is recorded with its direction, format, external reference, the payload that was sent, the status and any error, filterable to the registry connector and outbound direction. If a registry later queries a figure, you can show exactly what left the building and when.
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.