One of the most significant claims made by FHIR is out-of-the-box interoperability (see the one page glossy summary on FHIR). This is only true for a weak definition of interoperability. Any well-formed FHIR resource can be parsed by any compliant FHIR application, but this doesn’t mean the receiver can understand and employ that information computationally. For that to happen, the exchanging parties need to agree in advance on terminology, extensions, cardinality restrictions, and more.

That’s the purpose of FHIR profiles. Without profiles, when a FHIR application exports a resource, there is a good chance the receiving FHIR application will find it clinically unusable. Profiling is a process that creates a new definition by adding constraints to an existing definition (called the parent or base). The base can be any instance of a StructureDefinition, either a core resource definition or another profile. The resulting derived definition is often referred to as a “profile,” but to be exact, a profile just another instance of the StructureDefinition class.

Note: In this discussion, I will try to avoid the word “resource” because it is often unclear if “resource” refers to a definition (“the Patient Resource”) or an instance (“a Patient resource”). I use “instance” to refer to a specific occurrence of the resource, and “class” to refer to a type definition (an instance of the class StructureDefinition).

To create an interoperable exchange, each interacting FHIR application should state its capabilities in terms of producing and consuming data. The profiles acceptable for producing (exporting information) and consuming (importing information) are not necessarily the same. An application that performs some internal normalization might accept a broader range of terminologies than it would export, for example. Let’s call these sets {P} and {C}, respectively, for produce and consume profiles. An application can perform validation on instances it receives using its {C} profile set to confirm that the instance can, in fact, be successfully imported. Anything failing the validation could be rejected, or perhaps, processed in a different manner than conforming instances.

It would be naive to think that all FHIR applications will adopt the same profiles, even within a single realm, or for a single use case. The question then arises, what instances can be exchanged when different applications support different profiles? You can think about this problem in terms of Venn diagrams, where each circle in the Venn diagram represents the set of instances capable of conforming to a given profile (see illustration below). Several different patterns are possible:

• Containment is where one profile is more restrictive than the other profile, so all instances conforming to the first profile also conform the second. An example is when cardinality is restricted, e.g., from [0..1] in the parent to [1..1] in the child. Profile inheritance is a special case of containment, where one profile is based on (derived from) the other profile, in a child-parent relationship. Any instance conforming to the child profile automatically conforms to the parent profile or base resource definition. While inheritance assures containment, two unrelated, independently-developed profiles also can have a containment relationship.
• Incompatibility is when one profile has a constraint that directly conflicts with a constraint in the other profile. An example would be if one profile requires ICD-10 and the other requires SNOMED-CT. Other cases of incompatibility  involve non-overlapping cardinalities (e.g. [0..0] versus [1..1]), required bindings to value sets with no common elements, conflicting fixed-value restrictions, non-overlapping min/max ranges, or restriction of “[x]” attributes to a subset of data types. Incompatibility may also be occur if one or both profiles close (disallow) additional extensions. Profiles derived from different core resource definitions are automatically incompatible.
• Overlap occurs when there are instances that can conform to either or both profiles. An example of overlap is when one profile requires ICD-10 or SNOMED-CT, and the other requires SNOMED-CT or CPT to describe a procedure. Another example is when one profile has cardinality [0..1] and the other has [1..*], and an instance with exactly one element will conform to both profiles. We call an instance that falls into the overlap between two or more profiles multiconformant.

It is possible to describe multiconformance in terms of a new profile that captures only the overlap region of two profiles (the American football, vesica piscis shape). This profile can be created by applying combining the logical constraints imposed by each profile, an operation I call restrictive combination. Restrictive combination is neither a union nor an intersection, so I give it a unique symbol, ω (lower case omega). In the restrictive combination operation, cardinality, value set elements, and min/max constraints are combined via intersection. For example, if one profile constrains to [0..1] and the other constrains to [1..*], then the restrictive combination has a [1..1] constraint. If one profile has a required binding, and the other a preferred binding, the restrictive combination selects the more restrictive, required binding. Any required extensions in either source profile are required in the resulting profile. I will not give a formal definition of ω operation here, but the idea should be clear.

Given two profiles d1 and d2, the intersection in the Venn diagram is described by the profile derived by restrictive combination, d12 = d1 ω d2. If d1 and d2 are incompatible, as described above, then the restrictive combination is infeasible, and d12 does not exist, i.e., d1 ω d2 = ∅.

Now, given four sets of profiles, {P1} and {C1} from system 1, and {P2} and {C2} from system 2, one would naturally like to know what information can be exchanged in each direction. More explicitly, if {X12} represents the set of restrictively-combined profiles describing information that can be sent from system 1 to system 2, and {X21} represents the analogous set of profiles describing information that can be sent from system 2 to system 1, the challenge is to derive {X12} and {X21} from the original set of four profiles.

The instances that can be sent from system 1 to system 2 must be multiconformant with a profile p1 ∈ {P1} and a profile c2 ∈ {C2}. Conversely, instances that can be sent from system 2 to system 1 must be multiconformant with a profile p2 ∈ {P2} and a profile c1 ∈ {C1}. Formally, if Ω (capital omega) represents the restrictive combination operation applied to all possible pairings (the cross product) from the source sets, then:

{X12} = {P1} Ω {C2}

{X21} = {C1} Ω {P2}

The instances that can be exchanged bilaterally are those that satisfy the restrictive combination in both directions, resulting in the fully-interoperable profile set {X}:

{X} = {X12} Ω {X21}

In summary, when you consider interoperability of two systems that support different sets of FHIR profiles, you need to consider analyze pairwise combinations of profiles, and restrictively combine (ω) them to determine the set of interoperable profiles.

Last year, my MITRE colleagues and I developed a set of tools to analyze, compare, merge, and document profiles, but these tools never fully addressed the question of the interoperability of two sets of profiles. So while I have the theoretical answer to the question posed earlier: what instances can be exchanged when different applications support different profiles, I can’t yet offer a tool that creates the exchange profiles.