Healthcare/EDIFACT
Standard

EDIFACT messaging in healthcare

Healthcare adopted EDIFACT for lab results, referrals, and specialist letters two decades before FHIR, and in several countries this traffic remains in production. Zato parses it into typed Python objects.

Typedsegments and messages
Anydialect or profile
100%round-trip fidelity
edifact_bridge.py
# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service
from zato.edifact import parse_edifact

# A dialect registers its classes on import -
# the Dutch profiles ship as a worked example
import zato.edifact.nl

class LabResults(Service):
    name = 'demo.edifact.lab-results'

    def handle(self) -> 'None':

        # An interchange from any carrier
        interchange = parse_edifact(self.request.raw_request)

        # Typed access to every element
        msg = interchange.message
        patient = msg.pid.patient_name.married_name

        self.logger.info('Results for %s', patient)

Where does EDIFACT remain in use in healthcare?

EDIFACT predates FHIR by two decades, and the infrastructure built on it is still in production across Europe. The pattern repeats country by country - a national or regional mailbox network connects general practitioners, laboratories, hospitals, and pharmacies, and the messages flowing through it are EDIFACT profiles defined by a national standards body.

CountryTrafficProfiles
NetherlandsLab results, radiology, specialist letters, free-format mail between practicesMEDLAB, MEDRAD, MEDSPE, MEDVRI and successors, exchanged over national mailbox networks
United KingdomPathology and screening reports to GP systemsMEDRPT and related NHS profiles
DenmarkMessaging between practice, hospital, municipality and labMedCom EDIFACT standards, migrating to FHIR programme by programme

These networks are store-and-forward - a lab drops a result into the recipient's mailbox and the network guarantees delivery. There is no live acknowledgment loop as with HL7 v2 over MLLP, which simplifies the transport side of EDIFACT integration, as transport patterns explains.

How does Zato parse EDIFACT?

One call - parse_edifact - handles the UNA service string advice, the UNB-UNZ envelope, and every message inside the interchange. Each message resolves to a typed Python class from its UNH identity, and message types without a registered class parse into generic, fully navigable objects instead of failing.

Dialects are plain Python. The platform ships the Dutch healthcare profiles as a complete example - typed segments, composites for names, addresses and dates, and the message structures - and your own dialects follow the same pattern, whichever country or sector they come from.

What does an EDIFACT service look like?

The service below receives a laboratory result and walks its repeating groups - each specimen with its determinations and their values. The message in this example is a Dutch MEDLAB, but the shape of the code is the same for any dialect - parse, navigate by name, act on the values.

lab_results.py
# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service
from zato.edifact import parse_edifact

# The example dialect - import your own instead
import zato.edifact.nl

class LabResults(Service):
    name = 'demo.edifact.lab-results'

    def handle(self) -> 'None':

        interchange = parse_edifact(self.request.raw_request)
        msg = interchange.message

        # The patient and the sending department
        patient = msg.pid.patient_name.married_name
        department = msg.department.department

        # Each specimen and its determinations
        for material in msg.materials:
            for bep in material.determinations:
                self.logger.info('%s: %s = %s %s',
                    patient,
                    bep.determination,
                    bep.result,
                    bep.unit)

From here the values go wherever the integration needs them - a database, a REST API, a FHIR server following the same bridging pattern as the HL7 v2 to FHIR mapping, or a JSON representation via to_json for any downstream consumer.

Frequently asked questions

EDI is the general concept of structured electronic data interchange, EDIFACT is the UN-standardized syntax for it - the segment-based text format with UNB envelopes. Healthcare EDIFACT profiles are national applications of that syntax.

No - EDIFACT is text and has no transport of its own. It travels over REST, SOAP, file transfer, SFTP or email connections, and services call parse_edifact on whatever the carrier delivers.

No - the Dutch profiles ship as a worked example of a dialect, and the engine is dialect-neutral. Any EDIFACT dialect is defined the same way, as typed Python classes registered by their UNH identity.

Yes - serialization reproduces the parsed wire text, including separators, escapes and empty elements, so store-and-forward and selective-modification flows do not disturb message content.

Ready to integrate EDIFACT traffic?

Get started with Zato and parse your first interchange in minutes.

Open source In Python