Building a Global Agent Registry for Healthcare

The internet solved service discovery decades ago with DNS. You type a domain name, and a hierarchical system of registries resolves it to an IP address. Healthcare AI has no equivalent. When a triage agent in London needs to delegate a radiology interpretation to the most capable available agent - anywhere in the NHS, or across a federated European network - there is no lookup service. No trust chain. No way to verify capability, jurisdiction, or compliance status before opening a connection. GHARRA changes this.

GHARRA - the Global Healthcare Agent Registry and Routing Architecture - is the infrastructure layer we have been building at Symphonix-Health to answer a question that becomes more urgent with every new healthcare AI deployment: how do agents find each other?

This is not a theoretical problem. It is the bottleneck that will determine whether healthcare AI remains a collection of siloed point solutions, or becomes a composable, interoperable ecosystem capable of genuinely transforming patient outcomes at population scale.

The Discovery Problem

Consider the landscape today. A hospital deploys a triage agent. A pathology lab runs a diagnostic agent. A pharmacy network operates a medication-interaction agent. A national health authority maintains a population surveillance agent. Each of these agents was built by a different team, hosted on different infrastructure, authenticated through different mechanisms, and governed by different regulatory frameworks.

Now imagine you want them to work together on a single patient journey - say, a suspected sepsis case that requires immediate triage, rapid blood panel analysis, antibiotic interaction checking, and a notification to the regional public health authority. The current state of the art is bilateral integration: point-to-point API contracts negotiated between each pair of organisations. In a network of n agents, that is n(n-1)/2 integration agreements. For 50 agents, that is 1,225 bilateral contracts. For 500, it is 124,750.

This does not scale. It never has. The internet faced exactly this problem with hostnames in the 1980s, and the answer was a hierarchical, federated registry: DNS. Healthcare AI needs its own equivalent, built from the ground up for the unique constraints of clinical systems - jurisdictional sovereignty, regulatory compliance, cryptographic trust verification, and the absolute prohibition on exposing patient data through discovery infrastructure.

The Four Failures of Bilateral Integration

No dynamic capability matching. When a clinical agent needs a specific capability - say, FHIR R4 ClinicalImpression generation from a dermatology image - it has no way to query which agents in the network can provide that capability right now, with what latency, under what jurisdictional constraints, and at what trust level. Endpoints are hardcoded. Capabilities are documented in PDFs, if at all.

No cross-organisation trust verification. Even when two agents discover each other's existence, there is no standardised way to verify that the remote agent is who it claims to be, that it holds the certifications it advertises, or that those certifications are current. Trust is established through legal agreements and manual certificate exchange - processes that take weeks or months.

No jurisdictional routing. A clinical agent in Germany cannot programmatically determine which agents it is legally permitted to communicate with under GDPR, which require Standard Contractual Clauses, and which are in jurisdictions with adequacy decisions. This information lives in legal departments, not in machine-readable metadata.

No graceful degradation. When an agent goes offline, there is no automatic failover to an equivalent agent. There is no health scoring, no priority weighting, no capability-aware fallback routing. The integration simply fails, and a human must intervene.

How GHARRA Works

GHARRA is a three-tier federated registry that maps the organisational structure of global healthcare. Like DNS, it is hierarchical, delegated, and eventually consistent. Unlike DNS, it carries cryptographic trust material, regulatory attestations, and capability metadata alongside every record.

The Three Tiers

Root Registry - The global root, operated by Symphonix-Health from infrastructure in Ireland (EU jurisdiction, GDPR native). The root maintains the authoritative list of sovereign registries, their delegation records, and the global trust anchor chain. It does not store individual agent records. It stores pointers to the sovereign registries that do.

Sovereign Registries - National or regional registries operated by health authorities, standards bodies, or delegated operators. Examples: NHS Digital for GB, the ONC for US, gematik for DE, the Ministry of Health for KE. Each sovereign registry manages the agent records for its jurisdiction, enforces local regulatory requirements, and participates in the federated discovery protocol. Sovereign registries are authoritative for their namespace - gb.gharra.health, us.gharra.health, de.gharra.health.

Organisational Registries - Individual healthcare organisations register their agents within their sovereign namespace. An NHS Trust might register agents under guy-st-thomas.gb.gharra.health. Mayo Clinic under mayo.us.gharra.health. The HSE under hse.ie.gharra.health. Organisational registries manage their own agent lifecycle - registration, capability updates, deprecation, decommissioning - within the policy constraints set by their sovereign.

Agent Capability Cards

Every agent registered in GHARRA publishes a capability card - a structured, machine-readable document that describes what the agent can do, how to reach it, and how to verify it. The card includes the agent's namespace and unique identifier, its supported protocols (A2A, MCP, FHIR, HL7v2), its capability tags (triage, radiology, pharmacy, genomics), its trust material (JWKS endpoint, mTLS certificate chain, DPoP configuration), its regulatory attestations (CE marking, FDA clearance, ISO 13485), its health status and performance metrics, and its jurisdictional compliance tags.

Capability cards are signed by the registering organisation and countersigned by the sovereign registry. This creates a verifiable chain: any agent in the network can validate that a capability card was issued by a legitimate organisation within a legitimate sovereign, and that the sovereign is recognised by the global root.

This is a critical architectural decision. GHARRA never sits in the data path. It never proxies agent-to-agent traffic. It never sees clinical payloads. It is a directory service that provides discovery results and cryptographic verification material. Once a calling agent has resolved its target and validated the trust chain, all subsequent communication happens directly between the two agents. This eliminates GHARRA as a single point of failure, removes it as a latency bottleneck, and - most importantly - ensures it never handles patient data.

Cryptographic Trust at Scale

Discovery without trust is dangerous. Knowing where an agent lives is useless if you cannot verify that it is genuinely operated by the organisation it claims, that it holds the certifications it advertises, and that its behaviour is auditable. GHARRA implements trust through four layered mechanisms, each building on the one below.

The 13-Point Route Admission Gate

Before GHARRA returns a discovery result - before it tells a calling agent where a target agent lives and how to verify it - the request passes through thirteen sequential admission checks. Every check must pass. A failure at any point terminates the resolution with a structured error indicating which gate failed and why. The thirteen gates are:

1. Active Record - The target agent's registration must be in an active state. Expired, suspended, or decommissioned records are excluded.
2. Namespace Validation - The target's fully qualified namespace must parse correctly and resolve within the registry hierarchy.
3. Zone Delegation - The sovereign registry responsible for the target's zone must have a valid, unexpired delegation from the root.
4. Trust Anchor Verification - The trust anchor chain from the target's organisational registry through its sovereign to the root must be cryptographically valid.
5. JWKS Availability - The target agent's JSON Web Key Set endpoint must be reachable and must return at least one valid signing key.
6. Thumbprint Matching - The key thumbprint in the target's capability card must match a key in the resolved JWKS.
7. Certificate-Bound Token Validation - If the caller presents a certificate-bound token, the certificate must match the token's cnf claim.
8. Policy Tag Evaluation - The target's policy tags must be compatible with the caller's requested interaction scope.
9. Jurisdiction Check - The caller's jurisdiction and the target's jurisdiction must have a permissible communication basis (adequacy decision, SCCs, or same-jurisdiction).
10. Federated Trust Level - The caller's computed trust level must meet or exceed the target's minimum required trust level.
11. Protocol Compatibility - At least one wire protocol must be supported by both the caller and the target.
12. Feature Flag Evaluation - Any feature flags required by the target must be enabled for the caller's organisation.
13. Transport Endpoint Liveness - The target's declared transport endpoint must respond to a health check within the configured timeout.

Cross-Border Discovery in Practice

The real test of a federated registry is not whether it works within a single organisation or a single country. It is whether it works across borders - where jurisdictions differ, regulations conflict, and trust must be established between parties that have never previously interacted. GHARRA's cross-border discovery protocol uses a three-phase pattern we call Prune-Scatter-Gather.

Phase 1: Prune

When a calling agent issues a discovery query - "find me an agent capable of FHIR R4 dermatology classification in a GDPR-adequate jurisdiction" - the first step is to eliminate sovereign registries that cannot possibly contain a match. Each sovereign registry publishes a Bloom filter summarising its registered capability tags. The root registry maintains these Bloom filters and uses them to prune the candidate set before any network requests are issued. In practice, this eliminates 90-95% of sovereigns from consideration, reducing a global query to a handful of targeted lookups.

Phase 2: Scatter

The pruned candidate set receives parallel queries. Each sovereign registry evaluates the query against its local agent records, applying its own policy constraints, and returns a ranked result set. These queries are issued concurrently, with configurable timeouts and fallback behaviour. If a sovereign registry fails to respond within the timeout, its results are excluded and a degradation marker is attached to the response, informing the caller that the result set may be incomplete.

Phase 3: Gather

Results from all responding sovereign registries are merge-sorted by a composite score incorporating priority (explicit operator-assigned ranking), weight (load-balancing distribution), and health score (recent uptime, latency percentiles, error rates). The merged result set is paginated using federated cursor pagination - cursors that encode the position within each sovereign's result set - so that callers can efficiently page through large cross-border result sets without repeated full queries.

The Capability Routing Index

To accelerate repeated queries, GHARRA maintains a Capability Routing Index (CRI) - a distributed, eventually-consistent index that maps capability tags to sovereign registries. The CRI is built from the Bloom filters and augmented with frequency counts and freshness timestamps. When a calling agent queries for a common capability like "fhir-r4-patient-summary," the CRI can resolve the query directly from cached metadata without issuing any scatter queries to sovereigns. CRI entries have a configurable TTL and are invalidated when sovereign registries publish updated Bloom filters.

From Registry to Revenue

GHARRA is open-source infrastructure, but infrastructure requires sustainable funding. The commercialisation model mirrors the structure of the registry itself: tiered, transparent, and aligned with the value delivered.

Organisations pay to register and maintain their agents in the registry. Registration includes capability card hosting, attestation verification, trust anchor management, and SLA-backed uptime guarantees. Pricing scales with the number of registered agents and the frequency of capability card updates.

Workspaces provide isolated environments for development, staging, and production agent management. Organisations can maintain separate workspaces for testing federated discovery without affecting their production registrations.

Agent chains - complex multi-agent workflows that involve discovery, verification, and routing across multiple registries - are metered on a credit-based billing model. Each discovery resolution consumes credits proportional to the number of sovereigns queried and the complexity of the policy evaluation. Credits are purchased in advance or billed monthly.

Subscription tiers provide predictable pricing for organisations with stable, high-volume discovery needs. Tiers include bundled credits, priority support, dedicated sovereign registry instances, and custom policy rule development.

The principle is straightforward: the registry is free to query for basic lookups. Advanced features - cross-border federation, real-time health scoring, attestation verification, custom policy rules - are commercial services that fund the continued development and operation of the global infrastructure.

We built GHARRA because we could not find it. Every agent we deployed at Symphonix-Health - every triage agent, every clinical decision support agent, every population health monitor - needed to discover and verify other agents. And every time, the answer was the same: hardcode the endpoint, manually exchange certificates, hope the compliance team had signed off. That is not infrastructure. That is improvisation.

GHARRA replaces improvisation with architecture. A hierarchical, federated, cryptographically verifiable registry that lets healthcare AI agents find each other the way web services have found each other for thirty years - through a shared, trusted directory. The DNS for healthcare AI. Open-source, PHI-free, built for a world where clinical agents are not isolated tools but participants in a global, interoperable healthcare network.

The registry is live. The protocol is documented. The code is open. Build with us.