Postel’s Law and FHIR Profiles

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.

About Mark Kramer

Mark Kramer is Chief Engineer for MITRE’s Health Innovation Center. Over 10 years ago, Mark's work on hData helped establish the principles for RESTful APIs in healthcare, now used in FHIR. Mark also originated Synthea, the widely-used synthetic health data simulator. Formerly an Associate Professor at MIT, Mark’s publications in the areas of healthcare, data analytics, machine learning, modeling and simulation have been cited over 8500 times.
This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Postel’s Law and FHIR Profiles

  1. Grahame Grieve says:

    Well……. we have a way for the server to indicate multiple sets of profiles, but not to differentiate between read and write. And while Postels principle suggests that a server could usefully differentiate between what it read and writes, I suspect that the other differences – the use case ones – are even larger. And that for many servers, writing is confined to some use cases.

    I think there’s definitely something to explore here.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s