4 min read

HL7 v2 Messaging

ArkCloud contains an HL7 v2 parser and message generator as a code library, which an administrator can call through the HL7 API. Nothing connects that library to an interface engine: there is no MLLP listener or sender and no configuration screen. No HL7 messages are exchanged today.

HL7 v2 interface (ADT, SIU, DFT feeds)Not available

There is no HL7 interface: no listener, no inbound feed and nothing sent. A message library exists that an administrator can use to check or build a single message.

What exists in the code

Parser (lib/hl7/parser.ts)

Splits a pipe-delimited HL7 v2 message into segments and fields, honouring the encoding characters in MSH-2, and extracts typed MSH, PID, PV1, IN1, DG1 and FT1 data. It accepts any message type, including ADT, DFT, SIU, ORM, ORU and BAR, and runs basic validation.

Generator (lib/hl7/generator.ts)

MessagePurpose
ADT^A01Admit / visit notification
ADT^A03Discharge / end visit
ADT^A08Update patient information
DFT^P03Post detail financial transaction
ACKAcknowledgement

HL7 API (app/api/hl7)

Wraps the parser and generator over HTTP: POST /api/hl7 with action=parse, validate or generate. It requires the manage_integrations permission, which organisation administrators hold; supervisors and agents are refused. It returns the result to the caller and sends nothing to any other system.

HL7 v2 file sandbox (Rehab outside records, off by default)

Where a deployment switches it on, staff can upload one HL7 v2 message saved as a file. ADT^A04 and ADT^A08 identify the patient and propose allergies and diagnoses; ORU^R01 keeps the report text and can propose an imaging finding. Everything becomes a proposal a clinician reviews. It is not an interface: there is no MLLP listener, no inbound endpoint, no ACK and no feed, and no partner has been tested against it. See Outside records.

Verification: the file sandbox is tested with synthetic messages only. The HL7 API and the generator are inspected only, and nothing has been exchanged with a real system.

Not built

An MLLP listener or sender, or any TCP interface; there is no inbound HL7 route (the HL7 API's own index says inbound is not available)
Any screen to configure an HL7 interface, endpoint or field mapping
Generating SIU (scheduling) or BAR (billing account) messages; SIU and BAR can only be parsed
Automatically creating or updating patients, visits or charges from received messages
Message queues, message logs or delivery monitoring

What it would take

This is a list of engineering gaps, not a delivery commitment. A working HL7 interface would need at least:

  • An MLLP listener (and sender, for outbound messages) with TLS or a VPN, run as a service.
  • Routing parsed messages into patient, visit, coverage and charge records for the right organisation.
  • Acknowledgement handling, message logging and an error queue.
  • An administrator screen to configure the interface.
  • Tests for the parser, the generator and the end-to-end flow.

Exchanging data today

Claims and remittance travel through your clearinghouse's SFTP mailbox.
Outside records - documents and exported record files - can be uploaded in ArkCloud Rehab for a clinician to review (see outside records). The S3, SFTP and manual-upload connections under Settings → Integrations → Connections can be set up and tested, but files arriving there are not imported.
Anything else is implementation work arranged with support.