AS4 ebHandler vs Light Client: Which Profile for Healthcare?

Healthcare IT teams should deploy the AS4 ebHandler profile when they need 24/7 availability, payloads above 20 MB, and full push/pull messaging - the typical fit for regional hospitals, national health authorities, and EUDAMED-style cross-border exchanges. The AS4 Light Client profile fits smaller clinics, pharmacies, and rural practices that have intermittent connectivity, no public IP, and routine workflows under the 20 MB cap. The decision comes down to three things: message size, network reliability, and available IT resources.

Healthcare IT teams choosing an AS4 deployment hit the same fork in the road: the AS4 ebHandler profile or the AS4 Light Client profile. Both secure patient records, clinical reports, and administrative documents to the same OASIS ebMS 3.0 baseline, but they’re built for very different organizations. Get the choice wrong and you’ll either over-engineer a rural clinic with DMZ infrastructure it doesn’t need, or under-provision a regional hospital that can’t move imaging files above 20 MB. This guide walks through how each profile works, where each fits, and how to decide for your network.

Why AS4 Matters for Healthcare Data Exchange

Protecting electronic health information is a legal and ethical mandate that drives the technical decisions of healthcare IT departments. AS4 addresses this requirement by applying strict security controls directly at the message level using the WS-Security 1.1 standard. This approach is fundamentally different from standard Transport Layer Security (TLS), which only encrypts data while it travels through an active network tunnel. Message-level security ensures that sensitive clinical payloads remain fully encrypted and signed even when stored temporarily on intermediary servers. In addition to WS-Security, the protocol mandates transport security using secure HTTPS connections. This dual-layered security architecture provides healthcare organizations with verifiable end-to-end protection for patient records across complex regional networks.

Read more: AS4 Protocol in Healthcare: Secure and Reliable Data

AS4 Conformance Profiles Explained

One of the defining characteristics of the AS4 specification is its use of conformance profiles, which define the capabilities required for different types of communication endpoints. This modularity ensures that the protocol can scale from high-end gateways in national data centers to light clients in local clinics.

Read more: How ebMS 3.0 delivers reliability and security

What Is the AS4 ebHandler Profile?

The ebHandler profile represents the most comprehensive conformance policy available within the AS4 specification. It is specifically designed to handle the demanding requirements of large-volume healthcare data exchanges. This profile provides full messaging client and server capabilities, which means a deployed system can both send and receive files. It supports both pushing and pulling of messages across continuous, uninterrupted connections. Large regional hospitals, national healthcare data centers, and cross-border digital health networks commonly choose the ebHandler profile.

Beyond basic message transfer, the ebHandler profile contains advanced operational features that guarantee the reliable exchange of critical information. It includes native support for reception awareness, automatic message retries, and duplicate detection to prevent data inconsistencies over unstable networks. The profile also offers robust error-handling capabilities, supporting synchronous and active error reporting back to the originating application. This ensures that IT teams are immediately notified if a transmission fails, allowing them to troubleshoot issues without losing vital patient data.

What Is the AS4 Light Client Profile?

In contrast to the heavy infrastructure of the ebHandler, the AS4 Light Client profile is an entry-level conformance policy. It is designed specifically for smaller medical practices, local pharmacies, and rural clinics that have limited IT resources. The Light Client profile functions strictly as a messaging client and does not require a local HTTP server. Instead of accepting incoming connections, a Light Client initiates a connection to a central gateway to push outbound data and pull inbound messages. This asymmetrical pull-based design allows clinics with intermittent internet connectivity to participate securely in regional health networks.

While the Light Client profile provides strong encryption, its authentication mechanisms are adapted for lightweight endpoints. The ebHandler profile uses digital certificates to sign outgoing clinical documents to establish their origin. However, Light Clients frequently use the WS-Security UsernameToken Profile to authorize their pull requests from the central server. This allows a clinic to authenticate securely using a simple username and digested password when pulling messages. However, a major technical limitation of the Light Client profile is its maximum message size. Transactions using a Light Client must not exceed a strict message size limit of 20 MB. Any clinical exchange that exceeds this threshold requires the use of the ebHandler profile instead.

AS4 ebHandler vs Light Client: Technical Comparison

The strict 20 MB size limit of the Light Client has significant practical implications for healthcare IT teams. For routine administrative workflows, such as submitting electronic prescriptions or retrieving digital lab results, a 20 MB cap is perfectly sufficient. However, modern clinical environments often generate massive datasets that easily exceed this technical threshold. High-resolution medical imaging scans, detailed cardiology reports, and bulk patient records can easily surpass 20 MB. For these data-intensive transactions, IT teams must implement the ebHandler profile, which has no defined maximum size limits. Choosing the wrong profile can lead to dropped messages and failed transmissions during critical patient transfers.

Network infrastructure and cybersecurity policies also play a major role in determining which AS4 profile a healthcare team selects. Operating an ebHandler profile requires establishing a secure public-facing endpoint, which typically demands a dedicated demilitarized zone network setup. This requires a dedicated technical team to configure firewalls, manage secure routing, and protect against external cyber threats. Conversely, the Light Client profile is highly attractive to smaller organizations because it runs entirely behind a private local area network. Since the Light Client initiates all outbound connections to pull messages, it requires no inbound firewall modifications. This eliminates the need for expensive security infrastructure and minimizes the attack surface of the local clinic.

Security and Cryptographic Best Practices for AS4 in Healthcare

In healthcare IT, ensuring non-repudiation of receipt is essential for legal compliance and clinical dispute resolution. Both the ebHandler and Light Client profiles support synchronous signed receipts to provide cryptographic proof of message delivery. When an AS4 server receives a message, it verifies the digital signature, decrypts the payload, and returns a signed receipt containing cryptographic digests of the original file. This signed receipt proves that the clinical document was successfully received and validated by the target system. However, because the Light Client does not natively support advanced reception awareness or duplicate detection, IT teams must implement these features.

To maintain the integrity of patient data, healthcare AS4 deployments must follow modern cryptographic best practices. While traditional networks relied on older RSA algorithms, modern implementations are transitioning to Elliptic Curve Cryptography. Elliptic Curve Cryptography provides stronger security with smaller key sizes, which significantly reduces the computational overhead on clinical messaging servers. Additionally, IT teams must employ SHA-256 hashing to secure digital signatures against potential security vulnerabilities. Managing the lifecycle of these cryptographic certificates is a critical task for healthcare IT staff. Expired certificates can also disrupt the flow of patient data; therefore, automated certificate management tools are highly recommended to monitor expirations and renew keys without human intervention.

Further read: AS4 message packaging and security layers

Error Handling and Real-World Implementation

Real-world applications of these profiles highlight their specific roles in the global healthcare and administrative ecosystems. For instance, the eDelivery AS4 profile, used across European eHealth infrastructures, selects and extends the ebHandler profile to enable secure cross-border communication. This setup supports continuous, high-volume clinical document exchanges between national health authorities. On the other hand, the Light Client profile is widely used in B2G reporting, such as the Australian Taxation Office integration.

When implementing AS4 in a medical setting, clinical IT teams must establish clear protocols for handling transmission errors. If a message transmission fails, the receiving server sends an error signal instead of a signed receipt. Common AS4 error codes include authentication failures, signature validation errors, and decryption failures. For ebHandler deployments, these errors are automatically captured and routed to the central clinical application for rapid resolution. However, Light Client implementations require custom middleware to catch these errors and notify administrative staff. Understanding these error codes is vital for healthcare IT teams to ensure that patient records are not lost in transit.

Some common error codes.

• EBMS:1001: Failed Authentication
• EBMS:1002: Failed Decryption
• EBMS:1003: Signature Validation Failed

Read more: AS4 eDelivery use cases in public sector and healthcare

How to Choose the Right AS4 Profile for Your Healthcare Organization

Ultimately, the choice between the AS4 ebHandler and Light Client profiles depends on the specific operational scale of the healthcare provider. High-volume environments, such as major regional hospitals and national clinical registries, require the robust, always-on ebHandler profile to guarantee massive file transfers. Conversely, small local practices, rural clinics, and pharmacies can leverage the Light Client profile to join secure health networks without prohibitive cost. By selecting the profile that aligns with their transaction volume, technical expertise, and local network reliability, healthcare IT teams can optimize data workflows. This strategic technical alignment ensures that critical clinical information remains secure and accessible, directly improving the quality and safety of patient care.

Talk to an Expert

See AS4 Server handle both ebHandler and Light Client profiles for your setup. It comes with a 30-day free trial, no credit card required - book a walkthrough to get started.

Request a demo

Frequently Asked Questions

What is the difference between the AS4 ebHandler and Light Client profiles?

The ebHandler is a full client-and-server profile that supports push and pull messaging, payloads of any size, 24/7 availability, and built-in reception awareness, designed for hospitals and national health authorities. The Light Client is a client-only profile capped at 20 MB per message, designed for smaller clinics with intermittent connectivity. The Light Client cannot accept inbound connections and instead polls a central gateway.

What is the maximum message size for an AS4 Light Client?

The AS4 Light Client profile is capped at 20 MB per message under the OASIS specification. That covers most administrative workflows, electronic prescriptions, lab result retrieval, claim submissions, but is too small for high-resolution medical imaging, full patient record bundles, or detailed cardiology reports. Healthcare organizations exchanging files above 20 MB need the ebHandler profile, which has no protocol-defined size limit.

Can a small clinic use AS4 without a public-facing server?

Yes. The AS4 Light Client profile is designed precisely for that scenario. It runs entirely behind a private LAN and initiates all outbound connections to a central gateway, pushing messages out and polling to pull messages in. This means no inbound firewall rules, no DMZ, and no public IP required, which dramatically reduces both infrastructure cost and the local attack surface.

Does the AS4 Light Client profile support non-repudiation of receipt?

Yes, both profiles support signed receipts that provide cryptographic proof of delivery, which is the basis for non-repudiation under most healthcare compliance frameworks. The difference is operational: the ebHandler natively handles reception awareness, retries, and duplicate detection, while Light Client deployments must implement those features at the application layer through custom middleware.

Which AS4 profile does EUDAMED require?

EUDAMED machine-to-machine reporting runs over the EU eDelivery infrastructure, which uses an extended AS4 ebHandler profile. Medical device manufacturers and authorized representatives sending data to EUDAMED therefore need an ebHandler-capable AS4 server, a Light Client is not sufficient for direct EUDAMED submission, though it can serve internal subsidiaries that report through a central corporate ebHandler gateway.