Last time, I mentioned the possibility of having different sets of profiles for producing and consuming resources. Since then, I have gotten questions about why a FHIR server might want to have two sets of profiles, and how these profiles relate to FHIR’s API. Although having separate sets of produce and consume profiles is not currently a feature of FHIR, having two sets of profiles would allow FHIR to follow a principle of interoperability called Postel’s Law.

Postel’s Law, also called the Robustness Principle, says “an implementation should be conservative in its sending behavior, and liberal in its receiving behavior“. Postel was trying to prevent networks from being brittle by encouraging information receivers to be tolerant of variation and even minor errors, but highly predictable (and correct) when sending information. Postel’s law results in the network being more robust to poorly-behaved nodes.

From last time, the profile set {P} describes how the server shapes resources when it sends resources in an outbound direction, e.g., in response to a read, search, or query. The profile set {C}, on the other hand, deals with what the server is willing to accept, either via create or update operations.

In terms of Postel’s law, {C} should be more permissive than {P}. In terms defined in my last post to this blog, {P} is contained by {C}. That is, all instances conforming to {P} should also conform to {C}, but there may be instances conforming to {C} that do not conform to {P}.  The produce profile may require, for example, that the server must always send RxNorm medication codes. The corresponding consume profile, however, may state that the same server can accept medication codes from either SNOMED or RxNorm.

Postel’s law has detractors who claim that it allows, or even condones, sloppiness. While this might be true, in the context of FHIR, Postel’s law allows more organizations (maybe those incapable of terminology translation) to participate in information exchange. Another case is where there is a regulatory “least-common-denominator,” such as DAF (Data Access Framework) in the US, that dictates {C}, but a subgroup of servers agree to implement more specific (but still DAF-compliant) profiles. For example, a DAF profile might specify “preferred” bindings, but certain servers might mutually agree that the same bindings are “required.” Or, a subgroup of servers may agree to limit themselves to CIMI lab profiles, which are not (currently) required by DAF.

In the current implementation of FHIR, there is just one declaration of profiles, not two.  A server could still implement Postel’s law without declaring separate produce and consume profiles, but there is a clear downside to making that behavior implicit rather than explicit. If the server declares the permissive consume profiles {C}, it may not appear interoperable with servers that have adopted more restrictive rules. If it declares the restrictive profiles {P}, then it would appear to not interoperate with servers implementing the baseline (permissive) set of profiles. For complete clarity, there should be a way in FHIR to declare both sets of profiles.

Next time, I will look at some of the issues involved with validation of information exchanges using profiles.