Cross-Community Access (XCA)

XCA enables a Health Information Exchange (HIE) to broadcast a clinical query to multiple remote communities simultaneously. Rather than centralizing data, it uses a federated architecture where each community maintains sovereignty over its own records. The initiating gateway sends a Cross-Gateway Query transaction (ITI-38) to discover available documents, followed by a Cross-Gateway Retrieve transaction (ITI-39) to fetch the selected documents. This peer-to-peer design eliminates the need for a national patient index.

The XCA profile defines two primary system actors:

• Initiating Gateway: The system that originates the query on behalf of a local clinician, broadcasting requests to known remote gateways.
• Responding Gateway: The system that receives the query, searches its local document registry, and returns metadata about matching patient documents. Behind the Responding Gateway, a Document Registry actor stores metadata (author, type, date) while a Document Repository actor stores the actual clinical content. This separation allows for efficient metadata-level discovery before committing to large file transfers.

XCA relies on Patient Identifier Cross-Referencing (PIX) or Patient Demographics Query (PDQ) profiles to resolve patient identity across communities. When a query arrives, the Responding Gateway must map the initiator's patient identifier to a local identifier using a pre-established cross-reference. This demographic matching—often using probabilistic algorithms on name, date of birth, and gender—is critical to ensure that documents from the correct patient are returned without a universal master patient index.

XCA queries and responses use the Cross-Enterprise Document Sharing (XDS) metadata model, specifically the ebXML Registry Information Model (ebRIM). Each document is described by a rich set of metadata attributes:

• DocumentEntry.classCode: The type of document (e.g., Discharge Summary)
• DocumentEntry.formatCode: The technical format (e.g., C-CDA, PDF)
• DocumentEntry.confidentialityCode: The sensitivity level for privacy masking This standardized metadata envelope ensures that a querying clinician can evaluate the relevance of a document before initiating a bandwidth-intensive retrieval.

Each community in an XCA network is uniquely identified by a Home Community ID, typically formatted as an OID (Object Identifier) or a URN. This identifier is embedded in every document's globally unique identifier, allowing the Initiating Gateway to route a retrieve request back to the specific Responding Gateway that holds the document. This routing mechanism is stateless; the Initiating Gateway does not need to maintain a persistent connection, making the architecture resilient to intermittent network failures.

XCA transactions are built on SOAP-based web services and support both synchronous and asynchronous message exchange patterns. For large documents or slow-responding communities, the profile specifies an Asynchronous Web Services Exchange option. The Responding Gateway can immediately return an acknowledgment and later push the results to a designated endpoint. This prevents gateway timeouts during complex cross-community retrievals and supports high-latency, rural healthcare networks.

The organizational or technological entity that implements XCA to mobilize clinical data. An HIE acts as a gateway, using XCA's federated query mechanism to locate patient records across connected communities. Key operational models include:

• Centralized: Single repository with a master patient index
• Federated: Peer-to-peer queries via XCA, leaving data at the source
• Hybrid: Combining both architectures for regional coverage

The foundational IHE profile upon which XCA builds. XDS.b defines a document registry and repository model for sharing clinical documents within a single Affinity Domain (a community using a common set of policies). XCA extends this by enabling cross-community queries, allowing an XDS.b community to reach into another remote XDS.b community's registry to locate and retrieve patient documents.

The standardized XML document format that XCA typically retrieves. C-CDA defines the structure and semantics for common clinical document types:

• Continuity of Care Document (CCD): A summary of a patient's current health status
• Discharge Summary: Hospital course and follow-up instructions
• Progress Note: Encounter-specific clinical observations XCA queries return these structured documents, enabling semantic interoperability between communities.

The patient identity backbone required for XCA to function. An Enterprise Master Patient Index (EMPI) cross-references patient identifiers across multiple source systems within a community. When an XCA query arrives, the local MPI resolves the patient's identity using probabilistic matching algorithms that weigh demographic fields (name, DOB, gender) to link records despite inconsistencies, ensuring the correct documents are returned.

A complementary push-based protocol to XCA's pull-based query model. While XCA fetches documents on demand, Direct uses S/MIME-encrypted SMTP to push clinical information directly to a known, trusted recipient's inbox. Both are often deployed together in HIE architectures: Direct for point-to-point transitions of care, and XCA for broad, federated query across unknown communities.