HealthLink

HealthLink and Refera solve different parts of the same journey.

• HealthLink transports correspondence securely to the intended practice.
• Your practice management system (PMS) imports it into the provider inbox, patient record or unmatched-correspondence queue.
• Refera gives reception one administrative workflow for what happens next: contact the patient, book, retry, record unable to contact, or record that the referral was declined.

Your PMS remains the clinical record. Refera does not replace clinical filing or change clinical content. Refera performs no clinical triage.

The preferred connection

Where the practice has a server or hosted PMS, the safest pattern is to preserve the existing HealthLink-to-PMS delivery exactly as it is and provide Refera with a separately supported copy at the practice-controlled receiving boundary.

HealthLink -> existing practice endpoint -> PMS inbox / patient record
                              |
                              `-> supported copy -> Refera admin workflow

The PMS remains the only application consuming its original import location and remains responsible for its normal acknowledgement. Refera reads only its own copy. It does not race the PMS for the same folder, move the PMS source file or acknowledge HealthLink.

The copy must come from a supported HealthLink, PMS or practice-environment mechanism. A second collector on the same EDI is not supported and is not how Refera works.

Cloud PMS environments

A cloud PMS may not expose a practice-controlled folder. Refera keeps the existing HealthLink path unchanged while the supported integration is confirmed.

Direct upload remains unavailable until its source-document controls pass. It is not presented as a substitute for the supported HealthLink-to-PMS path.

The preferred option is a sanctioned secondary feed that leaves the PMS as the primary destination. If none exists, Refera can ask HealthLink to assess a receiving-and-relay pattern. In that pattern every addressed message and supported attachment would pass onwards to the practice PMS. Clinical content would be preserved; transport-envelope or addressing changes would be limited to the agreed onward-delivery profile. Successful delivery would depend on the agreed downstream application acknowledgement.

That relay is not production-enabled today. It remains a proposal until HealthLink provides written direction through its partner assessment, including the applicable technical profile and conformance process. Test credentials and certificates, a supported PMS receiving-interface contract, interface-specific synthetic testing and a reviewed reversible cutover must also be in place. Refera has no live SMD transport enabled, does not claim HealthLink conformance and does not re-point live correspondence while any of those conditions remain open.

What the connector already proves

Using synthetic messages, Refera’s connector test suite proves:

• the original HL7 message is preserved;
• a read-only connection cannot send or acknowledge;
• an in-path design takes durable custody before attempting onward delivery;
• duplicates and recovered attempts reuse stable delivery identity;
• a positive application acknowledgement must correlate to the original message;
• negative, missing or contradictory acknowledgements remain visible for recovery;
• non-referral correspondence never becomes a referral work item.

These are engineering controls, not a substitute for HealthLink’s own conformance process.

One work queue, with an honest boundary

Refera aims to remove duplicated transport handling, not the PMS itself.

Reception works the referral’s administrative next step in Refera. The original correspondence, appointment and clinical record remain in the PMS. Until a supported PMS status integration exists, staff still complete the normal booking or filing action there.

A HealthLink acknowledgement is a technical delivery receipt; it is not clinical triage and it does not claim that practice staff reviewed the referral. If HealthLink supports a relay in writing under an agreed technical profile, the operator projection would suppress positive ACKs so routine success would not require staff to open HealthLink and clear a second list. AA closes or suppresses the transport item; AE, AR, no-ACK, timeout and replay remain visible exceptions. Duplicate/resend idempotency is proven against the message and acknowledgement identifiers before a retry can advance the same delivery.

Before Refera describes HealthLink as a live one-queue connection, HealthLink’s written partner assessment, the applicable conformance process and interface-specific synthetic testing must prove that behaviour end to end, followed by a reviewed reversible cutover. The PMS still receives the correspondence and remains the clinical record; Refera gives reception one place to own the subsequent patient-contact and booking work.

What happens during setup

1. Refera records the practice’s HealthLink use and PMS environment.
2. Existing HealthLink delivery stays unchanged.
3. Refera and the practice’s IT contact identify the supported copy or partner pathway.
4. The connection is exercised with patient-free synthetic messages.
5. Real capture remains off until the delivery, acknowledgement, exception and rollback checks pass.

Related

• Alongside your PMS
• Capability status
• Medical-Objects