HL7 v2 — keep the hospital record and the IVF record in step

The problem HL7 v2 solves

A fertility centre almost never runs in isolation. It sits inside a hospital group, or alongside one, and the patient's demographics and routine bloods are owned by a system the clinic does not control. Without an interface, someone re-keys a name, a national identifier and a set of hormone values from one screen into another, several times a day. That is slow, and transcription is where patient identity errors and misfiled results are born.

• Registrations and demographic changes arrive automatically
• Hormone and serology results arrive as structured values
• Results finalised in the clinic go back to the hospital record

What the connector actually does

HL7 v2 is the pipe-delimited messaging standard that runs between almost every hospital information system, laboratory system and EHR, carried over MLLP on TCP. FertiliCore parses and builds v2.5.1 messages with a typed model and a round-trip tested parser. Inbound ADT messages become patient demographics, inbound ORU messages become laboratory results, and both paths converge on the same mapping pipeline whether the message arrives on the MLLP socket or is posted over HTTP by an interface engine.

Outbound results are event-driven, not polled

When a result is finalised in FertiliCore, the clinical application publishes an event. The HL7 connector consumes it, builds an ORU^R01 and places it on a reliable outbound queue. A worker drains that queue, sends the message MLLP-framed, reads the acknowledgement and retries on failure with a bounded attempt count. Nothing polls a table on a timer, and nothing is lost if the hospital's receiver is briefly unavailable — the message waits in the queue and stays visible to an operator.

The shared backbone behind every connector

All five FertiliCore connectors sit on one backbone. Every inbound and outbound message is recorded with its direction, message type, external reference, raw payload, status and correlation identifier, so an interface problem can be diagnosed from the message itself rather than from a log file. An external-to-internal identifier crosswalk maps the hospital's MRN to the internal patient file, which is what prevents a repeated ADT from creating a second patient. The outbound queue guarantees at-least-once delivery with retry, claim-locking so multiple workers never double-send, and an operator screen for watching and retrying failures. All of it is tenant-scoped.

• Message log with payload, status, error and correlation id
• Identifier crosswalk so re-sends update rather than duplicate
• Outbound queue with retry and operator-visible failures
• Connector credentials stored encrypted, never returned in plaintext

It never writes clinical tables directly

The HL7 service does not hold a connection to the clinical database. It calls the clinical application's own ingestion API over authenticated service-to-service HTTP, which means an externally sourced patient or result passes through exactly the same validation, permission and audit path as one typed in by a clinician. If the ingestion API rejects a message, the connector records a failure with the reason rather than writing a half-formed record. It also means the connector can be deployed, restarted or turned off without any effect on the clinical data model.