HL7

Health Level Seven

Definition

HL7 (Health Level Seven) is an international standard for healthcare information exchange, established by the HL7 international organization, corresponding to the seventh layer of the OSI model (application layer). HL7 defines the message formats and exchange rules between healthcare systems, applicable to data such as patient information, medical orders, test results, imaging reports, and medication records. HL7 v2 is the traditional message format (pipe-separated), HL7 v3 is in XML format, and HL7 FHIR is a new generation RESTful standard that has become mainstream.

Healthcare systems such as HIS, PACS, LIS, and EMR implement data exchange through HL7. IoT SIM cards provide secure connections for healthcare system interconnectivity, telemedicine, integrated healthcare networks, health apps, and ensure the compliance of HL7 message transmission (MLPS (Multi-Level Protection Scheme), HIPAA).

Technical Features

HL7 v2 message types include ADT (patient management), ORM (orders), ORU (observation results), etc. FHIR adopts a Resource model, supporting REST, batch, subscription, and other modes. HL7, in conjunction with the IHE (Integrating the Healthcare Enterprise) framework, can define a complete integration solution (e.g., XDS cross-institutional document sharing).

Use Cases

HL7 is applied to hospital HIS, PACS, LIS and other system interconnections, medical consortiums, regional medical information platforms, and medical insurance interfaces. Typical scenarios include: order placement, laboratory result feedback, imaging report sharing, patient information synchronization, electronic medical record sharing, etc. SimtoLink provides VPDN private network, dedicated APN, real-name verification, and smart healthcare solutions for medical data exchange scenarios.

Segmentation and Retry of Pipe-Delimited Messages

What a message means when it crosses cellular

An HL7 message on an IoT SIM means that, on a link between sites, on a mobile lab, or on an emergency backup, an agreed message carries a patient event, an order, or an observation result from one end to the other. On the SIM side the meaning is concrete. One message may be split into segments, and the segments have to be reassembled by the original message number. The character set and the separators must not be rewritten on a gateway or a module. A partial packet must not be taken by the receiver as a new order. The SIM does not understand the business meaning of an ADT or a lab result. It only has to deliver the bytes in order, to the right port, and allow a retry that keeps the same message number when it fails.

The newer resource interface is covered under FHIR, and privacy limits under HIPAA. Whichever envelope is used, cellular is only how the envelope is carried. The correct action after a failed delivery is to send the original envelope again, not to write a new order with similar content.

Conditions for turning on an inter-site link

Both ends have already agreed the message version, the character set, the port, and the acknowledgement method, and the SIM access point may visit only those ports. When mobile or disaster-recovery use treats cellular as backup, the failover is decided by the front-end processor, not by signal bars. On a weak network the front-end should be able to cache messages that already have numbers, and send the missing ones by number after recovery. Clocks need to be aligned, or an admission that happened first is ordered after a discharge that happened later.

Size the plan for the message peak. A lab rush and an imaging report are not the same volume. Night-time idle traffic does not say whether the day is covered. After a SIM number changes, the far-end allow-list and the source identity in the audit have to change with it, or messages are dropped quietly while the sender still shows them as written.

A partial packet parsed as a new order

A common failure treats connection close as the end of a message. A brief cellular break parses half a pipe-delimited text, missing fields are filled with defaults, and the system contains an order that was never placed. If the retry logic mints a new message-control number, the same lab result is stored twice. Another is a device in the middle that changes the character set from the agreed encoding to another. Drug names and personal names become garbled, and a manual check matches the wrong patient.

Watching only whether the port is open, and not the acknowledgement number, treats a mass of negative acknowledgements as a healthy link. Acceptance should use one message cut short on purpose and one repeat of the original message. The cut message must not be stored. The repeat may be kept only once, and the control number must stay the same.

A negative acknowledgement itself has to return to the send queue. It must not be hidden by a successful send on the SIM side. The front-end writes bytes into the module, and the module answers that the send is complete. That only means the bytes left the radio. It does not mean the other application accepted them. The application acknowledgement number is the condition for sending the next message. If fields are rewritten automatically after a negative acknowledgement — for example an empty bed number filled with a default bed — the receiver accepts a message whose content has changed, and the original error is covered. Character-set conversion should happen only at the one step both sides agreed. The module's SMS mode or log mode must not convert again, or a drug name is damaged on the second conversion while the SIM log shows another encoding. When a long message is segmented, any missing segment means the whole message is resent. Segments that have already arrived must not be stored early. If the port is taken by another service, a second connection should be refused, so messages from two instruments are not spliced together.

A repeating group inside a message, such as several items in one lab panel, succeeds as a group or fails as a group. Storing only the first few items makes the report look partly complete, and clinical staff may act on a broken result. The front-end should not submit to the application before the whole group has arrived. If a cellular break cuts the group in the middle, the unfinished group stays on the send queue and the whole group is sent again after recovery. Groups that already succeeded are skipped by message number. Do not, for speed, split a group into fragments that have no sample number.


Related Terms

Back to the IoT SIM Card Glossary