Language-First Interoperability in Action: A Closer Look into AI-Driven Referral Eligibility

How a multi-agent, protocol-driven architecture brings the Language-First Interoperability (LFI) vision to life in healthcare referral automation

Mark Kramer’s [Language-First Interoperability](http://1. https://medium.com/@kramermark/language-first-interoperability-f650abfb7353)[[1](https://medium.com/@kramermark/language-first-interoperability-f650abfb7353)] concept paints a picture of systems that can talk to each other, think together, and grow smarter using shared language-based protocols and models. Our AI Health Referral Eligibility proof-of-concept puts these ideas to work with a real-world problem of improving healthcare referral management — a process with documented systemic challenges. From 1999 to 2009, the probability that an ambulatory visit to a physician resulted in a referral increased from 4.83% to 9.29%, with the absolute number of visits resulting in a physician referral increasing 159% nationally over this time, from 40.6 million to 105 million[2]. An effective referral system requires care coordination — communication, feedback, and monitoring — to prevent medical errors[3,4]. This is often missing from current healthcare delivery models.

In this article, I will expand on the LFI principles, diving into how we actually built this thing, exploring the multi-agent architecture, protocol-driven design, and validation mechanisms that make it all work. It’s a solid example of what LFI can do when applied to healthcare challenges.

System Demonstration: A Complete Referral Workflow

Let’s examine the system through a complete referral scenario.

Health Referral Eligibility UI — Referral Form

The user interface presents a referral form completed by a primary care physician — this could function as a standalone portal or as a module within an existing EHR system.

The initial form captures patient demographics, referring provider information, specialty requested, urgency level, and reason for referral. Notably, while comprehensive patient information appears in the interface, only minimal data (patient demographics, specialty, and referral reason) is transmitted to the referral triaging agent initially.

This design choice demonstrates LFI’s dynamic context sharing principle — rather than requiring all information upfront, the system enables agents to negotiate and determine what additional data is needed to complete the transaction. This differs significantly from traditional implementations where all requirements must be known before initiating the referral request.

Agent Coordination in Practice

The system’s Agent Flow visualization reveals the structured, multi-agent workflow processing.

Agent Flow — Conversational view

Agent Flow — Protocol Detail

The process begins when ORCHESTRATOR-1 initiates a referral request to the Referral AI Agent (RAA-1) for a gastroenterology consultation.

Detailed Flow:

1. RAA-1 processes patient data and responds with extracted patient information for Ruby Wright, indicating readiness for policy evaluation

2. Orchestrator requests policy evaluation from Request Triaging Agent (RTA-1), which analyzes referral criteria and responds with required data elements: demographics, medications, active problems, and recent lab results

3. Orchestrator requests clinical data from Clinical Data Retriever Agent (CDRA-1), which retrieves required information and generates a referral letter

4. Workflow concludes with orchestrator confirming referral acceptance, indicating complete data collection and referral letter generation

This systematic approach ensures comprehensive referral evaluation through coordinated agent interactions, resulting in an accepted gastroenterology referral with complete clinical documentation. The process demonstrates automated complex healthcare referral decision-making while maintaining thorough documentation and clinical guideline adherence.

Message Flow Analysis

The complete message log shows the precise JSON-RPC interactions:

· 2025–07–24T16:23:17.930708: ORCHESTRATOR-1 → RAA-1: INITIATE_REFERRAL

· 2025–07–24T16:23:17.930712: RAA-1 → ORCHESTRATOR-1: PROVIDE_PATIENT_DATA

· 2025–07–24T16:23:17.930712: ORCHESTRATOR-1 → RTA-1: REQUEST_POLICY

· 2025–07–24T16:23:41.367893: RTA-1 → ORCHESTRATOR-1: PROVIDE_POLICY

· 2025–07–24T16:23:41.368174: ORCHESTRATOR-1 → CDRA-1: REQUEST_DATA

· 2025–07–24T16:23:41.371205: CDRA-1 → ORCHESTRATOR-1: PROVIDE_DATA

· 2025–07–24T16:23:41.371208: ORCHESTRATOR-1 → SYSTEM: CONFIRM_ACCEPTANCE

Each message includes complete context, timestamps, and agent identification, providing full audit traceability for compliance and debugging purposes.

The system demonstrates several key LFI principles in practice:

Explicit Protocols Enable Predictable Integration Making every agent interaction explicit, structured, and validated transforms integration from unpredictable custom development into systematic, safe operations.

AI Agent Cards Function as Enforceable Contracts Machine-readable agent cards ensure capabilities, requirements, and SLAs remain current and enforceable rather than becoming outdated documentation.

Discoverability Enables Composable Architecture Model Context Protocol (MCP) configuration and model cards enable capability discovery and composition without brittle, hardcoded integrations.

Security and Compliance by Design Authentication, authorization, and auditability integrate into the system foundation rather than being added as afterthoughts.

Observability and Monitoring as Core Features Health checks, structured logs, and real-time status updates make the system transparent and manageable at scale.

A Closer Look at the Protocol-Driven, Language-First Design

The Healthcare Referral Eligibility System uses a microservices architecture with a central Orchestrator Service coordinating three specialized AI agents — Referral AI Agent, Request Triaging Agent, Clinical Data Retriever Agent. The system processes healthcare referrals through a sequential workflow where each agent handles specific responsibilities: patient data processing, policy compliance evaluation, and clinical documentation gathering. All inter-agent communication is done via JSON-RPC 2.0 protocol. Every message is structured, signed, and validated according to standardized schemas.is secured with JWT authentication and message signing, while agents access external systems including Electronic Health Records and Clinical Policy Databases.

Health Referral Eligibility Architecture

Agent-to-Agent Protocol Implementation

Our application uses Google’s Agent2Agent (A2A) protocol[5] for inter-agent communication. It follows HTTP-based JSON-RPC 2.0 with strict request/response patterns. Each message structure includes:

· Header: Sender/recipient IDs, timestamps, and message type

· Body: Intent, context, and content payload

· Security: JWT signature for authentication and integrity

Following this protocol ensures every agent interaction is explicit, machine-readable, human-readable, and verifiable. For example, a referral initiation message follows this structure consistently across all agents, eliminating the ambiguity that typically plagues healthcare system integrations.

Agent Cards: Machine-Readable Capability Contracts

Each agent is defined by a JSON-based agent card that documents its complete operational profile. These aren’t static documentation files — they’re loaded at runtime and used to validate every message and workflow step. The key components of the model card include:

· Identity: Name, unique agent ID, version, organization, and functional description

· Capabilities: Each capability (e.g., INITIATE_REFERRAL, COORDINATE_WORKFLOW) includes detailed input/output schemas

· Interfaces: Supported message types, required fields, and SLA targets organized by urgency level

· Dependencies: Required services (policy server, EHR server), other agents, and infrastructure components

· Security and Compliance: Authentication methods, authorization levels, encryption requirements, and audit specifications

The Referral AI Agent’s agent card, for instance, specifies that it processes INITIATE_REFERRAL messages, expects specific input fields (patient ID, specialty, urgency), and guarantees response within defined SLA parameters. Agent card validation occurs at runtime through utility classes that ensure only compatible messages are exchanged and all required fields are present.

Agent cards may reference one or more underlying LLM model cards, and adding layers of implementation-specific information. This creates a documentation stack where you can trace from the agent’s behavior back through its configuration to the foundational model’s capabilities and limitations. All of the agents in our referral eligibility application use OpenAI GPT-4o.

MCP Configuration: Standardized Infrastructure Discovery

The MCP configuration system is based on Anthropic’s MCP specification[5], and aligns provides centralized management for all agent and server endpoints, authentication tokens, capabilities, and health monitoring. The configuration supports environment-variable awareness for seamless deployment across development, staging, and production environments.

MCP Configuration Elements:

· Server Configurations: Each MCP server (policy, EHR, document, FHIR) includes host, port, protocol, timeout, and retry specifications

· Authentication: Bearer tokens with refresh endpoints and renewal intervals

· Capabilities: Runtime-discoverable tools and resources available on each server

· Health Checks and Monitoring: Automated health monitoring endpoints and check intervals

· Global Settings: Message broker configuration (RabbitMQ), security settings (TLS/JWT), logging levels, and environment specifications

This configuration loads and validates at startup, enabling agents to dynamically discover and connect to required services. This supports LFI’s principle of making system capabilities discoverable and composable rather than hardcoded.

Message Validation and Workflow Enforcement

The system enforces comprehensive validation of all messages and configurations. Model card loaders and MCP configuration utilities ensure message compatibility, field completeness, and SLA compliance.

Validation Workflow:

1. Referral triage agent receives JSON-RPC request

2. JWT verification for authenticity and claims validation

3. Message type and field validation against agent’s model card

4. If valid: agent processes request and responds within SLA

5. If invalid: standardized JSON-RPC error response with specific code and message

This validation approach reduces integration friction and enables safe, scalable system evolution — core tenets of the LFI approach.

Security, Compliance, and Observability

LFI’s emphasis on trust and auditability manifests through several technical mechanisms:

· JWT-based authentication: Every request includes signature verification

· Digital signatures: Message integrity validation at each processing step

· Structured logging: All agent interactions logged with context (request IDs, agent IDs, conversation IDs)

· Audit trails: Complete action traceability supporting HIPAA and FHIR compliance requirements

· Health monitoring: Built-in endpoints and metrics for agent and service health assessment

Sequence and Communication Flows

The referral workflow demonstrates the orchestrated coordination between agents through the central Orchestrator service:

1. Referral Initiation User submits referral via web interface. Orchestrator generates conversation ID, stores referral state, and sends receive_message JSON-RPC request to Referral AI Agent (RAA-1).

2. Policy Evaluation RAA-1 extracts and validates patient data. Orchestrator sends request_policy JSON-RPC request to Request Triaging Agent (RTA-1), which applies clinical guidelines and determines required data elements.

3. Data Retrieval Orchestrator sends request_data JSON-RPC request to Clinical Data Retriever Agent (CDRA-1), which gathers and organizes necessary clinical data and generates referral letter.

4. Status Updates Orchestrator updates referral state and provides real-time status and agent flow visualization through web interface.

All communication maintains synchronous, request/response patterns with standardized error handling using JSON-RPC error codes for authentication failures, method not found conditions, and processing errors.

Paving A Language-First Path

The AI Health Referral Eligibility proof of concept demonstrates that LFI represents a practical, implementable approach to healthcare system interoperability. By establishing language and protocol as the foundation for system communication, the architecture becomes more than easier to integrate and extend — it becomes more secure, auditable, and adaptable to evolving healthcare requirements.

This approach suggests a path forward for healthcare automation where systems understand, validate, and evolve together through shared language protocols.

References

1. https://medium.com/@kramermark/language-first-interoperability-f650abfb7353

2. https://bmchealthservres.biomedcentral.com/articles/10.1186/s12913-021-06140-w

3. https://www.cdc.gov/pcd/issues/2021/20_0569.htm

4. https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/1108675

5. https://github.com/a2aproject/A2A

6. https://docs.anthropic.com/en/docs/mcp

May Terry is a Principal Healthcare Informaticist at the MITRE Corporation. She is a data and semantic modeler for several healthcare projects in cancer, post-acute care, and clinical genomics as well as a technical co-lead for the HL7 AI Transparency on FHIR project.

Dr. Mark A. Kramer is Distinguished Chief Engineer at MITRE Corporation, where he leads efforts in healthcare interoperability and standards development. He has been instrumental in developing mCODE, Synthea, and FHIR Shorthand.

©2025 The MITRE Corporation. All rights reserved. Approved for public release. Distribution unlimited 25–01406–8.