Affinity domains, actors, and the repository-registry split
XDS.b is the canonical IHE pattern for cross-enterprise document sharing. It assumes an affinity domain: a governed federation of organizations that agree on metadata rules, identity conventions, and security expectations.
Its most important architectural idea is the hard split between payload storage and discovery metadata. Repositories own document binaries. A central registry owns document metadata and query logic.
Read the picture left to right: a source publishes into the sharing domain, metadata becomes searchable through the registry, and only then does a consumer know which repository to call for the actual document bytes. That sequencing is the architectural reason XDS.b can scale across organizations without centralizing every payload in one application tier.
XDS.b actors inside an affinity domain
Loading diagram...
Primary XDS.b actors
| Actor | Owns | What it must do well |
|---|---|---|
| Document Source | Submission of document plus metadata | Build valid metadata and invoke the correct transaction |
| Document Repository | Binary document persistence | Durably store payloads and forward metadata correctly |
| Document Registry | Metadata index and query semantics | Validate metadata and answer discovery queries quickly |
| Document Consumer | Search and retrieval | Query the registry, then fetch from the right repository |
IHE XDS.b profile
Official XDS.b chapter covering affinity domains, actors, and responsibilities.
Open the XDS.b profileThe four XDS.b transactions architects remember first
The core XDS.b workflow is short but strict. A source submits a document set to a repository. The repository registers metadata with the registry. Consumers search the registry and then retrieve payloads directly from the owning repository.
Core XDS.b exchange sequence
Loading diagram...
The legacy transport reality
Most XDS.b deployments still mean SOAP envelopes plus MTOM/XOP for large binary documents. That transport assumption has major impact on API Gateway, proxy, and ingestion design on AWS.
Minimal Provide and Register request shape
A simplified XML example that shows the split between registry metadata and the document content reference.
XML structure with syntax highlighting
ITI-41 Provide and Register Document Set-b
Official transaction definition for document submission and MTOM-based packaging.
Read ITI-41ITI-18 Registry Stored Query
Official query transaction used by consumers to discover document metadata.
Read ITI-18ITI-43 Retrieve Document Set
Official retrieve transaction used after the consumer has discovered the repository location.
Read ITI-43The hardest part of XDS is community governance, not the SOAP envelope
An XDS affinity domain only works when participants agree on how metadata is used. The registry can validate syntax, but it cannot invent a coherent community metadata specification for patient identifiers, document classes, confidentiality, replacement semantics, and code-system usage.
What the affinity-domain governance layer controls
Loading diagram...
Governance decisions that determine whether queries stay useful
| Policy surface | Example decisions | Operational effect |
|---|---|---|
| Patient identity | Which assigning authorities are allowed and how patientId is formatted | Prevents searches from missing documents because the wrong patient domain was used |
| Document typing | Which classCode, typeCode, and formatCode value sets the community accepts | Makes FindDocuments queries precise instead of returning inconsistent mixtures of content |
| Privacy and sensitivity | How confidentiality codes, consent context, and masking rules are applied | Lets consumers discover only what policy allows them to see |
| Lifecycle and provenance | How replacement, append, transform, and author metadata are represented | Supports safe updates and human trust in the returned result set |
Why many XDS deployments disappoint users
If a community does not constrain metadata values and query behavior, the registry can still be technically correct while clinicians see noisy, incomplete, or misleading search results.
Document Sharing Metadata Handbook
Official IHE handbook on community metadata constraints, discoverability, and governance decisions for XDS, XCA, and MHD.
Read the metadata handbookebRIM gives the registry its data model
The registry side of XDS.b is based on ebXML Registry Information Model concepts. A document entry is represented as an ExtrinsicObject. Submission sets and folders are registry packages. Associations capture replacement, append, signature, and membership relationships.
Simplified ebRIM view for XDS.b
Loading diagram...
This model is the reason registry implementations often feel relational. Query semantics are driven by metadata joins, classifications, and association traversal rather than by simple key-value lookup.
ITI-42 Register Document Set-b
Official metadata registration transaction that writes validated ebRIM content into the registry.
Read ITI-42XCA federates communities instead of building one giant registry
XDS.b is the centralized sharing model inside one affinity domain. XCA is what you add when each community keeps its own registry, repository, policies, and patient identity management but still needs to query and retrieve across boundaries.
In practice, XCA is usually paired with XCPD or another identity-management approach because the initiating community often does not know the patient identifier used by the responding community. The initiating gateway performs the federation work and aggregates the answers for the local consumer.
Cross-community query and retrieve with XCPD and XCA
Loading diagram...
Single-community XDS.b versus federated XCA
| Concern | XDS.b inside one community | XCA across communities |
|---|---|---|
| Discovery location | One registry in the affinity domain | Multiple responding communities queried through gateways |
| Patient identity | Usually solved within the community already | Often needs XCPD, PIX, or another cross-community identity strategy |
| Routing | Repository uniqueId is often enough | homeCommunityId becomes part of query and retrieve routing |
Cross-Community Access (XCA)
Official IHE profile for querying and retrieving patient-relevant medical data held by other communities.
Read XCACross-Community Patient Discovery (XCPD)
Official IHE profile for locating communities that know a patient and translating patient identifiers across those communities.
Read XCPDKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.