Convert an HL7 v2 message into a FHIR R4 Bundle (JSON) - locally in the browser, with no upload; the patient data never leaves your device.
Running locally on your device ...
0%
Your files never left your device
No. Everything runs in your browser - your file never leaves your device. How this is verifiable
HL7 v2.x has been the most widespread interchange format in clinical IT for decades: segment-based and pipe-delimited, with segments like MSH (message header), EVN (event), PID (patient), PV1 (encounter), OBR (request) and OBX (observation) and the delimiters ^~\&. The modern successor HL7 FHIR R4 models the same information as clearly named resources (Patient, Encounter, Observation) and delivers them as JSON or XML - far easier for web APIs and modern systems.
Drop your HL7 v2 file; the tool reads the segments and builds a FHIR R4 Bundle (collection). A curated core is mapped: MSH becomes a MessageHeader, PID a Patient resource (identifier, name, gender, birth date, address), PV1 an Encounter (class, visit number, location), OBX an Observation (code, value, unit) and OBR a ServiceRequest. You can drop several files at once, each becomes its own Bundle.
Everything runs entirely locally in the browser (pure JavaScript, no server, no foreign library from a foreign CDN) - the message with its patient data never leaves your device. Honest framing: this is a structural conversion of a common segment core, not a complete HL7-to-FHIR mapping (Z-segments and many detail fields are not covered) and not a clinical tool. Verify the result against the profiles and requirements of your target system.
| Input formats | HL7, TXT |
|---|---|
| Output format | JSON |
| Batch processing | Yes |
| Processing | Locally in your browser (JavaScript) |
| File upload | None |
Limitations: Converts an HL7 v2 message (e.g. HL7 v2.5, segment-based, pipe-delimited) into an HL7 FHIR R4 Bundle (collection, JSON): MSH -> MessageHeader, PID -> Patient (identifier, name, gender, birth date, address), PV1 -> Encounter (class, visit number, location), OBX -> Observation (code, value, unit), OBR -> ServiceRequest. It is a curated segment core: Z-segments, repetitions beyond the first and many optional detail fields are intentionally not represented, so the mapping is not lossless. It is a structural format conversion for data exchange and not a clinical tool; verify the Bundle against the profiles (e.g. required fields, terminologies) of your target system.
No. Reading the HL7 v2 message and building the FHIR Bundle run entirely locally in the browser (pure JavaScript, no server); the data never leaves your device.
MSH, PID, PV1, OBX and OBR are mapped to MessageHeader, Patient, Encounter, Observation and ServiceRequest. EVN and vendor-specific Z-segments are not covered.
HL7 FHIR R4 as a Bundle of type collection with one resource per mapped segment - as JSON.
No. A curated segment core is mapped; Z-segments, further repetitions and many optional fields are left out. Verify the Bundle against the profiles of your target system.
Yes. Drop several HL7 v2 files at once; each becomes its own FHIR R4 Bundle.