XDS Affinity Domains and XCA Communities, a confusing combination?

Since the introduction of the IHE Cross-Community Access (XCA) Profile, confusion exists as to the difference between an (XCA) Community and an (XDS) Affinity Domain. That confusion, so I have noticed, has caused unnecessary complexity and misalignment in the domain of standards-based (clinical) information exchange. In this article, I'll explore several Affinity Domain and Community combinations.

First, let's go back to the origin of the IHE Cross-enterprise Document Sharing (XDS) profile to first understand what an Affinity Domain is. From there we'll introduce the XCA Community, and discuss how they relate.

IHE Cross-enterprise Document Sharing 

With the first introduction of XDS a "blueprint" for an exchange infrastructure was created through the definition of a set of actors that are linked through transactions. The actors, referring to roles and associated responsibilities a system can have in an exchange use case, distinguish between "source", "consumer", and some shared components like a "registry" and "repository". Sources provide documents to repositories. Repositories register documents with a registry. Consumer queries and retrieves documents. Quite simple and easy to understand. However, defining actors and transactions alone does not suffice in a real-world exchange infrastructure. Hence the concept of an Affinity Domain was born to denote everything that exchange network participants need to agree upon to make the exchange work. An Affinity Domain constitutes the agreement exchange participants commit to. Amongst others, it refers to the decisions made about how to identify patients across different information systems, the ground rules w.r.t. legal and regulatory issues, security measures, access control rules, patient consent, and so on, and so on.

Growing adoption

As the IHE XDS profile was adopted by Health Information Exchange (HIE) organizations around the globe, the deployment model that used a single, centralized XDS registry became popular and an HIE and an Affinity Domain were considered synonyms.
 
However, with the first deployments, it also became clear that every HIE network has a boundary. What defined the boundary though, was less clear. Regional HIE may have a geographical boundary, but the main sharing use case could define another. For example, a cardiology exchange network may have different "boundaries" than a radiology exchange network, each with its own sharing agreements. Add to that, that some HIE participants take part in more than one exchange use-case, and the concept of the Affinity Domain that at the start seemed easy became more difficult to understand.

Cross-community Access profile

Around this time the Cross-community Access (XCA) profile was introduced. Again, a straightforward profile that defines how one HIE network can set up an exchange with another HIE network without having to connect all participants in both networks with each other. IHE XCA introduced the concept of a gateway actor through which all cross-network communication is tunneled.

                                                                                                                                                            Simplified XCA diagram

The "cross gateway" transactions ITI-38 (Query) and ITI-39 (Retrieve) are almost identical to their XDS equivalents ITI-18 and ITI-43. The difference is that the response of ITI-38 includes a "homeCommunityId" that can be used to direct an ITI-39 transaction to the gateway of the community that "holds" the document. Consumers are expected to treat the homeCommunityId as an "opaque" parameter that they should modify or store. 

In addition, the XCA profile also defines that the "gateways" are to harmonize the differences in Affinity Domain definitions. An easy-to-understand example of the latter is the fact that two networks are unlikely to use the same patient identifier making it difficult to query another network for patient information. A more complex challenge is to harmonize access control rules, or user roles between different networks. Hence, the definition of a Community was created. A community is everything that is "hidden" behind an XCA gateway actor. Whether or not that "everything" actually is an XDS-based Affinity Domain is not relevant.

There are many examples of what a Community can represent. The European epSOS program introduced the concept of a National Contact Point (NCP) that mapped a community to a country or large region within a country. Some EHR vendors see themselves as a community that may span a single or a group of their customers. Vendors like Founda Health use it to represent a healthcare provider organization in their network. In the USA the TEFCA heavily relies on the concept of communities referred to as QHINs.

Community models

Even though the XCA profile does not mandate that a community needs to use XDS internally, it makes it easier if we make that assumption when combining them. Let's review a few "archetypes". 

Archetype #1: Community spans a single Affinity Domain

This archetype is the most straightforward combination of an Affinity Domain and a Community. The affinity domain mostly likely uses a single XDS registry used by all participants to register their documents with. The responsibilities of the gateway in this model are quite clear as it harmonizes the differences between the (internal) Affinity Domain, and external Communities (plural!) for outbound and inbound transactions. 

For outbound transactions, the (initiating) gateway is expected to address a remote (responding) gateway using patient identifiers issued by assigning authorities in the responding community. Hence, it needs to keep (or magically retrieve from somewhere) a mapping between a (remote) homeCommunityId and the assigning authorities being used. The gateway may use some form of a Master Patient Index to translate patient identifiers from one domain into another. 

For inbound transactions, the (responding) gateway is required to route requests to the registry, repositories, and (on-demand) document sources when needed.

An example of this archetype is the XDS Affinity Domain created through the DI Common Services program from Ontario Health (Canada). This domain maintains document registration from 4 different sources (Diagnostic Imaging Repositories) in the province. All document registrations use the provincial "patient identifier" maintained by the provincial Client Registry (Canadian for master patient index).

Archetype #2: Community spans multiple Affinity Domains

Archetype #2 is a variation on #1 and is typically a result of the absence of a (global) master patient identifier that is used across all Affinity Domains. For outbound transactions, the gateway's responsibilities remain the same. For inbound transactions, routing gets a little more complex as the gateway must decide which of the Affinity Domains it covers inbound requests are to be routed to. Take as an example an inbound query (ITI-38) transaction. This request includes a patient identifier used by one or more of the covered Affinity Domains. The responding gateway decides when and how to route these requests to the registries within the Affinity Domains.

Archetype #3: Community spans multiple Communities

This model introduces the next level of complexity as many variations within the communities are possible that all must be harmonized through a single gateway. If you would think in hierarchies the top-level community is considered to be the parent of several child communities (that also may be parents themselves). This model results from the US TEFCA initiative and is based on the CareQuality and eHealth Exchange networks that both have detailed how to use XCA-based transactions in their networks. However, in addition to the XCA profile, these networks also leverage the IHE Cross-Community Patient Discovery (XCPD) profile to locate the communities that hold documents from patients known to the initiating community without the need for a "master" record locator service.  

This model is also used in The Netherlands to bridge between the XDS networks that both Founda Health and Enovation manage on behalf of their customers. Each vendor’s network is considered to be a Community of Communities, and their gateways acting as proxies take care of routing inbound requests to internal communities using business logic that is derived from sharing agreements that these customers in the different networks have with each other. A great enabler in this Dutch case is that all Communities share a common national patient identifier making it quite easy to identify patients in remote communities. The existence of the national patient identifier enables health information exchange without the need for a "Record Locator Service".  

Archetype #4: Community spans a single Affinity Domain and includes another Community

This model is a variation of #1 and #3. At first, this may seem like a strange combination. However, when you consider that more and more clinical applications have discovered the XCA profile as a way to expose clinical information they manage it is not that unlikely. Take as an example an Epic CareEverywhere or Cerner HIE solution. In both cases, these EHRs use XCA (and also other IHE XC* profiles) to query/retrieve documents from, or to be queried by other communities. This model is a great way to create a single point of entry for a Community regardless of the complexity inside. Unfortunately, there is a caveat. When an embedded Community and the embedded Affinity Domain follow different and conflicting affinity domain agreements it gets "hairy".    

For example, when the embedded Community F responds with document references from sources that are not part of the parent Community G it is a child of it becomes confusing for the (initiating) gateway that queries Community F. It brings the parent community gateway into a conflict as it may return documents in its responses that are not part of the community it is responsible for. To solve this conflict the embedded (child) community should follow the Affinity Domain agreement that it is part of, and limit its response to sources that are considered part of the parent’s Affinity Domain. Whether or not this can be enforced on the embedded community depends on the flexibility of the vendor's gateway of these embedded communities. An example where this is an issue is the XCA Gateway of the Dutch EHR vendor Chipsoft.

Another issue may be circular or duplicate document references resulting from the fact that the Affinity Domain inside Community G, and the embedded Community F return the same documents. It is the responsibility of the parent gateway to solve such conflicts. Unfortunately, not all XCA gateways are aware of this responsibility. 

Real-world Lessons Learned

Mixing communities and affinity domains can easily become a complex endeavor as the behavior of the different gateways is not always predictable as a result of different vendor implementations.
 
At Founda our experience has brought us to the decision to drastically simplify the relationship between a community, an affinity domain, and a document author institution (a.k.a. provider organization). Our default setup assumes a 1-on-1 relation between all of these:

One Community = One Affinity Domain = One Author Institution.

In the “real world” this mostly means that each hospital is an affinity domain and a community at the same time, and both adhere to the same sharing agreement. A practical result of the above is that the gateway configuration becomes extremely efficient. When acting as an initiating gateway it needs to be able to contact remote responding gateways. When acting as a responding gateway it only has to deal with the complexity of one author institution.

This model still allows for embedding communities inside the community representing the provider organization. Differences in behavior between the affinity domain and embedded communities are addressed within the scope of one provider organization. 

The Community G Gateway in our setup is responsible for routing all document queries, and the document retrieves it receives from the external initiating gateway to both the registry of the XDS Affinity Domain, and to the gateway of the embedded community. 

An essential element in this model is that the provider organization's patient identifier domain is "promoted" to be the master patient identifier also for the embedded communities. For requests initiated by the gateway, it has the responsibility to link these with patient identifiers used by a remote community. The IHE XCPD and PIX profiles guide how to do so. In case a true global patient identifier exists such as National Patient Identifier (Dutch BSN, English NHS number, etc.) this is relatively easy. Vice versa the gateway can also link a national patient identifier to a local patient identifier when acting as a responding gateway, or use XCPD/PIX profiles to interact with a master patient index system.

Summary

The Cross Community Access Profile was introduced to federate query and retrieve transactions across two or more health information exchange infrastructures. The XCA profile left it open whether or not a community is represented by an XDS Affinity Domain to leave room for vendor-specific (design) decisions. This makes the XCA profile quite powerful, but it also introduces the risk of additional complexities that only surface at implementation time. At Founda Health we have experienced many different XCA models used by our customers globally. As a result, our XCA Gateway offers flexibility and can be configured to support any of the "archetypes" discussed in this article. 

To implement scalable and sustainable community configurations we favor a deployment where each healthcare provider that represents (and legally owns) a set of unique document sources is represented by one XCA community and one affinity domain referred to as archetype #4. The Dutch National XDSCloud service Founda Health offers is based on this archetype.