HL7 analyzer integration — profile-gated

Current status: RESEARCH / E0–E2. Cortex does not treat HL7 as one universal analyzer interface. A successful socket connection is not evidence that a result can be acknowledged, interpreted, matched, or delivered safely.

This page is an evidence-collection path, not an activation recipe. An exact Cortex profile is required before a clinic can enable an analyzer.

What must be known first

Collect the following from the device vendor or the authorised LIS/PIMS integrator for the exact model, firmware/software build, region, and licensed options:

• Which side opens the connection and whether the connector is serial, a TCP client, a TCP listener, a file exchange, or a vendor-managed hub.
• Framing, character set, delimiters, message version, sender/receiver identity, and the complete result message family.
• Positive and negative acknowledgement rules, timeout and retry behavior, duplicate control identifiers, and what the device expects after a decode or validation failure.
• Patient, order, accession, specimen, and observation coordinates; result lifecycle, correction flags, coded values, comments, and quality-control semantics.
• Whether orders or worklists are queried or pushed, the query message family, and how the response is correlated to a sample.
• TLS, network allow-list, credential, audit, and offline behavior.

Do not infer any of these values from another analyzer, a device family name, an online catalog, or a simulated fixture.

Safe evidence collection

1. Record the exact device tuple and the written interface contract. Keep the source date and a checksum in the profile evidence packet.
2. Use a synthetic or deidentified patient and a single authorised test order. Capture only the minimum diagnostic metadata needed to compare source and normalized values.
3. Ask the vendor/integrator to provide the expected acknowledgement and a malformed-message example. Test duplicate, reconnect, timeout, correction, multiple-order, and unmatched-result behavior.
4. Compare the device report, Cortex durable receipt/diagnostic record, API payload, and visible client value by value. A mismatch keeps the profile in research or unsupported status.
5. Keep raw diagnostic captures encrypted and access-controlled outside Git; delete them when the signed evidence packet is complete and no later than seven days. Commit only deidentified fixtures, hashes, and provenance.

Activation boundary

The profile must name the exact connector role, framing, message family, driver version, mapping version, and capability status. Results, worklists, quality-control flows, and imaging are separate capabilities: passing one does not certify the others.

Profiles below the interface-contract evidence level cannot be activated. Experimental profiles require an explicit opt-in by an existing clinic device manager and remain visibly experimental. Only bench- or field-verified exact profiles may be presented as supported.

Troubleshooting without guessing

• A refused connection is a transport-role or network configuration question; do not switch the device from client to listener (or the reverse) based on a generic guide.
• A received message that is not accepted should remain in the durable diagnostic/quarantine path. Do not ask the device to retry indefinitely or mark the result as delivered from a log line.
• A result that has no single clinic-owned order belongs in manual review. It must not create or attach a patient automatically.

For a certified exact tuple, use the profile-specific instructions supplied by Vetigen support. This page intentionally contains no universal port, version, message, acknowledgement, or firewall value.