Message Does Not Begin With an MSH Segment
The first segment of an HL7v2 message must be MSH (Message Header). The validator could not find an MSH at the start, so it cannot determine the encoding characters, version, or message type.
HL7v2 · Error
The error
Message does not begin with an MSH segmentWhy it happens
A leading blank line, a stray BOM or whitespace, a file header, or an MLLP wrapper (the 0x0B / 0x1C framing bytes) left in front of the message. Sometimes the message was split mid-stream and the MSH ended up in a previous chunk.
How to fix it
Trim everything before the literal characters "MSH". Strip MLLP framing bytes and any byte-order mark. Make sure the very first three characters of the payload are M, S, H, immediately followed by the field separator (usually |).
Example
The snippet below triggers the error:
PID|1||12345^^^HOSP^MR||DOE^JOHN||19800101|M
MSH|^~\&|SENDAPP|SENDFAC|RCVAPP|RCVFAC|20240115||ADT^A01|MSG001|P|2.5The corrected version:
MSH|^~\&|SENDAPP|SENDFAC|RCVAPP|RCVFAC|20240115||ADT^A01|MSG001|P|2.5
PID|1||12345^^^HOSP^MR||DOE^JOHN||19800101|MFrequently asked questions
Why does my message fail even though MSH is present further down?
MSH must be the first segment. HL7v2 derives its delimiters from MSH-1 and MSH-2, so a parser cannot read any segment that appears before MSH. Move MSH to the top.
Could MLLP framing cause this?
Yes. MLLP wraps each message with a start block (0x0B) and end block (0x1C 0x0D). If those bytes are not stripped before parsing, the message appears to start with a control character instead of MSH.