Why Healthcare Needs an Agent-to-Agent Protocol

Healthcare's integration problem isn't technical debt - it's architectural. For 30 years, interoperability has meant translating between siloed systems: HL7v2 pipes, FHIR REST endpoints, point-to-point integrations that multiply as N² as each new system joins. Now add autonomous AI agents - triage systems, diagnostic engines, prescription validators, discharge planners - each capable of reasoning independently but unable to communicate with each other. The result is the same fragmentation that has plagued healthcare IT, but at machine speed.

The promise of clinical AI is not a single omniscient model. It is a fleet of specialised agents, each trained on a narrow domain, collaborating the way a multidisciplinary team does in a hospital ward. But collaboration requires communication. And the communication infrastructure that healthcare has relied on for decades - HL7v2 messages, FHIR resource bundles, SOAP-wrapped web services - was designed for a world where a human operator sits at every decision boundary.

That world is ending. What replaces it demands something the industry has never built: a protocol designed from the ground up for agent-to-agent communication in clinical environments.

The Problem with Healthcare APIs

Healthcare's existing integration standards - HL7v2, HL7v3, CDA, and FHIR - were designed to move clinical data between systems under human supervision. They solve an important problem: getting a lab result from the analyser to the clinician's screen, or transmitting an admission notification from the PAS to the bed management system. But they were never designed for autonomous orchestration.

Request-Response Is Not Enough

REST APIs operate on a synchronous request-response model. A client sends a request, the server returns a response. This works when a human is waiting for a lab result. It fails when an AI triage agent needs to simultaneously request imaging, coordinate pharmacy, allocate a bed, schedule a follow-up appointment, and verify insurance coverage - all within a single patient encounter, all with different latency profiles, all requiring different authorisation contexts.

The N-Squared Integration Problem

Every point-to-point integration creates a new maintenance surface. With 5 systems, you need 10 integration channels. With 25 autonomous agents, that number explodes to 300. Add versioning, consent boundaries, and jurisdictional compliance rules, and the combinatorial complexity becomes unmanageable. Traditional integration engines (Mirth Connect, Rhapsody, InterSystems HealthShare) reduce the wiring but do not eliminate the fundamental problem: each connection is bespoke, each message transformation is hand-coded, and each new participant increases the maintenance burden for everyone.

No Native Task Orchestration

FHIR has no concept of a delegated task that passes through multiple agent hands before returning a result. The Task resource exists, but it models human workflow - a clinician assigns a task to another clinician. It does not model an agent spawning sub-tasks, monitoring their progress via streaming updates, handling partial failures, or escalating to a human when confidence drops below threshold. The orchestration layer that clinical AI demands simply does not exist in any current healthcare standard.

No Built-in Consent or Audit

When Agent A asks Agent B for a patient's medication history, who authorised that request? Under which consent directive? For which purpose? FHIR's security model relies on OAuth 2.0 tokens and SMART scopes, but these were designed for human users logging into applications. They do not natively support agent-to-agent delegation chains, consent verification at every hop, or the cryptographic audit trails that regulators increasingly demand. The gap between what healthcare regulations require and what existing APIs provide widens with every new agent deployed.

What Makes A2A Different

The Agent-to-Agent (A2A) protocol, as implemented in our Nexus framework, is built on a set of design principles that directly address the limitations of existing healthcare integration standards. It is not a replacement for FHIR or HL7 - those standards continue to serve their purpose for data interchange. A2A operates at a different layer: the coordination of autonomous agents that may themselves produce or consume FHIR resources.

JSON-RPC 2.0 over HTTP

A2A uses JSON-RPC 2.0 as its wire format. This is a deliberate choice. JSON-RPC provides structured method invocation with typed parameters and error handling, without the overhead of REST's resource-oriented constraints. An agent doesn't GET a resource or POST to a collection - it invokes a method on a peer agent. The semantics are closer to a remote procedure call than a data query, because agent collaboration is fundamentally about delegating work, not fetching records.

Every A2A message is a JSON-RPC envelope: a method name, a parameter object, and a unique request identifier. Responses carry either a result or a structured error. This simplicity is intentional - the protocol should be trivial to implement in any language, on any platform, without requiring a FHIR server, an HL7 gateway, or a message broker.

Task Lifecycle: From Submitted to Completed

The core primitive in A2A is the task. When Agent A asks Agent B to do something - run a differential diagnosis, validate a prescription, check bed availability - it creates a task. That task moves through a defined lifecycle: submitted, working, completed, failed, or escalated. Each state transition generates an event. Agents can subscribe to these events and react accordingly.

The escalated state is particularly important for clinical safety. When an agent's confidence in its output drops below a configurable threshold, it does not silently return a low-confidence result. It escalates - pushing the task to a human-in-the-loop review queue with full context attached. The protocol enforces this pattern; it is not an optional add-on.

Agent Cards for Discovery

Every agent in an A2A network publishes an agent card - a machine-readable description of its capabilities, input/output schemas, supported methods, authentication requirements, and operational constraints. Agent cards are hosted at a well-known URL (/.well-known/agent.json) and are registered with a Global Agent Registry (GHARRA in our implementation). This allows agents to discover peers dynamically, negotiate capabilities at runtime, and form ad-hoc collaboration chains without pre-configured point-to-point wiring.

Server-Sent Events for Real-Time Progress

Long-running clinical tasks - a radiology AI analysing a CT scan, a genomics agent processing a whole-exome sequence - cannot return results in a single HTTP response. A2A uses Server-Sent Events (SSE) to stream progress updates from the working agent back to the requesting agent. This allows the orchestrator to display progress, update dependent tasks, or abort early if the clinical context changes (e.g., the patient's condition deteriorates and the original request becomes irrelevant).

MQTT for Low-Bandwidth Environments

Not every clinical environment has reliable broadband. Rural clinics, mobile health units, disaster response teams, and community health worker networks in low- and middle-income countries operate on intermittent, low-bandwidth connections. A2A supports MQTT as an alternative transport - a lightweight publish-subscribe protocol designed for constrained networks. The same task lifecycle, the same agent card discovery, the same security model - but over a transport that works on a 2G connection with 200ms latency and 50% packet loss.

The Nexus Agent Fleet

The protocol is only as credible as the agents that use it. Nexus currently operates 25 clinical agents across four tiers, each tier representing a distinct domain of healthcare delivery. Every agent publishes a compliant agent card, participates in the task lifecycle, and passes through the 13-point route admission gate before communicating with any peer.

The 13-Point Route Admission Gate

Before any agent in the Nexus fleet can communicate with any other agent, the request must pass through a 13-point route admission gate managed by the Global Healthcare Agent Registry and Routing Authority (GHARRA). This is not a simple API key check - it is a multi-layered security evaluation that verifies identity, authorisation, trust, jurisdiction, and transport integrity in a single synchronous call.

The gate operates on a deny-by-default principle. If any single check fails, the request is rejected and the failure is logged with full cryptographic context for audit. There is no fallback, no soft-fail, no "allow and log" mode. The checks are:

1. Active Record - Confirms the requesting agent has an active, non-suspended registration in GHARRA. Revoked or expired agents are immediately rejected.
2. Namespace Validation - Verifies the agent's namespace (organisation + domain + agent-type) matches its registered identity. Prevents namespace spoofing.
3. Zone Delegation - Checks that the requesting agent is authorised to operate in the target agent's security zone. Cross-zone communication requires explicit delegation.
4. Trust Anchor Verification - Validates the certificate chain back to a recognised trust anchor. Self-signed certificates are never accepted in production.
5. JWKS Endpoint - Retrieves and validates the agent's JSON Web Key Set from its published JWKS endpoint. Keys must match the signing key used in the request token.
6. Thumbprint Match - Compares the certificate thumbprint in the request header against the thumbprint registered in GHARRA. Detects certificate substitution attacks.
7. Certificate-Bound Token - Verifies that the OAuth token is bound to the presenting certificate (RFC 8705). Prevents token theft and replay.
8. Policy Tag Evaluation - Evaluates the request against the target agent's published policy tags (e.g., data classification, purpose limitation, retention period).
9. Jurisdiction Check - Confirms that data transfer complies with the jurisdictional rules of both the source and destination agents. Prevents cross-border violations.
10. Federated Trust - For multi-registry environments, validates the federation trust chain between the source and destination registries.
11. Protocol Version - Confirms both agents support a compatible A2A protocol version. Version mismatches are rejected, not silently downgraded.
12. Feature Flags - Checks that any required feature flags (e.g., SSE support, MQTT transport, batch mode) are enabled on both agents.
13. Transport Endpoint - Validates the target agent's transport endpoint is reachable, TLS-secured, and responds with a valid agent card.

Each check executes in under 5ms. The full gate evaluation completes in under 50ms - fast enough to sit in the hot path of every agent-to-agent request without introducing perceptible latency. The gate is not a batch job or a periodic audit; it runs on every single interaction, every time.

Real-World Deployment

A protocol that works only in controlled lab environments is not a protocol - it is a proof of concept. Nexus A2A is deployed across five countries, each presenting distinct infrastructure, regulatory, and clinical challenges that stress-test every assumption in the protocol's design.

Each deployment validates different aspects of the protocol. A bandwidth-constrained East African deployment proves MQTT transport works at scale. The UK proves backward compatibility with legacy standards. Rwanda proves dynamic agent chains can coordinate maternal health pathways across facility tiers. Singapore proves fine-grained consent enforcement for IoT data streams. Australia proves federated registry operation across jurisdictional boundaries.

The common thread is that none of these deployments required protocol modifications. The A2A specification - task lifecycle, agent cards, route admission, transport abstraction - is the same everywhere. What changes is configuration: which transport, which consent rules, which trust anchors, which terminology mappings. The protocol is the constant; the environment is the variable.

What Comes Next

The transition from API-mediated integration to agent-native protocols is not optional. It is a consequence of the technology trajectory that healthcare is already on. As clinical AI matures - as diagnostic agents become more accurate than junior clinicians, as triage systems reduce emergency department wait times, as documentation agents eliminate hours of clerical burden - the bottleneck will shift from "Can the agent do its job?" to "Can the agent communicate with the agents around it?"

That is the question A2A answers. Not by replacing FHIR or HL7, but by providing the coordination layer that sits above them. FHIR moves data. HL7 sends messages. A2A orchestrates work. Each layer has its purpose, and each layer is necessary. What healthcare has been missing is the top layer - the one that lets agents be agents, not just API clients with better error handling.

We built Nexus A2A because we needed it. Our own clinical agents could not coordinate without it. Every workaround we tried - REST webhooks, message queues, custom orchestration services - created more problems than it solved. The protocol emerged from operational necessity, not theoretical ambition. And that, perhaps more than any technical feature, is why it works.