# EDIFACT integration

Exchange EDIFACT with trading partners from plain Python, in any dialect they use.

With Zato, you exchange EDIFACT with trading partners from plain Python - the standard in which healthcare, logistics and customs systems have sent lab results, referrals, orders and reports for decades. The `parse_edifact` function converts an incoming interchange into typed Python objects, with an API modeled on [HL7 v2 parsing](https://zato.io/docs/dev/healthcare/hl7/v2/parsing/index.html). The same typed classes build and serialize the messages you send back.

## Reading a referral {#reading-a-referral}

The interchange below is a free-text referral from the Dutch healthcare dialect that ships with the platform - parse it and read the patient's details through typed, semantic names:

```python
# Zato
# Importing a dialect package registers its message classes.
import zato.edifact.nl

from zato.edifact import parse_edifact

raw = (
    "UNB+UNOA:1+41007001+41008002+230405:0912+7431'\n"
    "UNH+7431+MEDVRI:1'\n"
    "GGA+Praktijk Rozenburg+Administratie+Praktijk Rozenburg+Kerkstraat:14::Utrecht:3511AB+?+31611223344'\n"
    "DET+24:02:14+09:41'\n"
    "PID+1975:03:18+V+Dijk:van der:Peters:de::M.++BSN999990019'\n"
    "TXT:1+Beste collega'\n"
    "UNT+6+7431'\n"
    "UNZ+1+7431'"
)

interchange = parse_edifact(raw)
msg         = interchange.message

family_name = msg.pid.patient_name.married_name    # 'Dijk'
born_year   = msg.pid.date_of_birth.year           # '1975'
```

To learn everything `parse_edifact` handles, see [Message parsing](https://zato.io/docs/dev/healthcare/edifact/parsing/index.html), and for the full typed access model, see [Field access](https://zato.io/docs/dev/healthcare/edifact/field-access/index.html).

## How messages arrive {#how-messages-arrive}

Trading partners deliver interchanges through mailbox networks, file drops, HTTP endpoints and email, so there is no dedicated EDIFACT connection type. A REST channel, a SOAP channel, a file transfer channel or an IMAP connection receives the text and invokes your service with it. Inside the service, `self.request.edifact` is the interchange parsed into typed messages, and it is the same attribute whichever channel delivered the text. To learn the pattern for each carrier, see [transport patterns](https://zato.io/docs/dev/healthcare/edifact/transport/index.html).

## Dialects {#dialects}

A dialect is a set of plain Python classes - segments, composites and messages - and the engine resolves the right class for each incoming message at parse time. The Dutch healthcare profiles (MEDLAB, MEDVRI, MEDRAD, MEDSPE) ship with the platform as a complete worked example, and any dialect, from national healthcare profiles to UN/EDIFACT supply-chain messages, follows the same pattern. To define your own, see [Dialects and profiles](https://zato.io/docs/dev/healthcare/edifact/dialects/index.html).

## What the engine covers {#what-the-engine-covers}

The engine handles everything between the wire text and your typed objects:

- **Wire syntax** - UNA service string advice, custom separators and release-character escapes, in both the five- and six-character UNA forms.
- **Interchange envelopes** - UNB and UNZ as typed segments, functional groups (UNG/UNE), multi-message interchanges, and bare messages without any envelope.
- **Typed messages** - message classes declare their segments and groups declaratively, and every element and component is accessible by a semantic Python name.
- **Unknown types** - message types without a registered class parse into generic messages that keep everything navigable by position and serialize back byte for byte.
- **Round-trip fidelity** - serialization reproduces the parsed wire text, so a message can be received, inspected, selectively modified, and passed on without disturbing the rest of its content.

## See also {#see-also}

- [Message parsing](https://zato.io/docs/dev/healthcare/edifact/parsing/index.html) - Envelopes, separators, unknown types and byte-faithful serialization
- [Field access](https://zato.io/docs/dev/healthcare/edifact/field-access/index.html) - Reading and writing business data through semantic Python names
- [EDIFACT in healthcare tutorial](https://zato.io/tutorials/healthcare/edifact.html) - An incoming lab result and an outgoing letter to a GP, step by step

## Learn more {#learn-more}

- [Healthcare interface engine](https://zato.io/docs/dev/healthcare/) - Clinical messages, FHIR, conversion and operations
- [HL7 v2 parsing](https://zato.io/docs/dev/healthcare/hl7/v2/parsing/) - Messages as typed objects, with field access and validation
- [MLLP channels](https://zato.io/docs/dev/healthcare/hl7v2/mllp/) - Receiving and sending HL7 v2 over MLLP sockets
- [FHIR integrations](https://zato.io/docs/dev/healthcare/hl7/fhir/) - Read and write FHIR resources, with paths, bundles and extensions
- [HL7 v2 to FHIR](https://zato.io/docs/dev/healthcare/hl7/to-fhir/) - Converting v2 messages into FHIR bundles, codes and references included
- [Transformation](https://zato.io/docs/dev/healthcare/transformation/) - One message in, another standard out, in ordinary Python
- [Audit log](https://zato.io/docs/dev/healthcare/audit-log.html) - Every message with its acknowledgment, searchable by patient identifier
- [AI in clinical interfaces](https://zato.io/docs/dev/healthcare/ai/) - Services calling LLMs and AI agents calling clinical services as tools