FHIR Issue: removing the element from all resources

Oct 3, 2012

From the beginning, every FHIR resource has included an element as the first element of the resource: ```` <[**Person**](null) xmlns="http://hl7.org/fhir"> <[**id**](null)> ````

The id is the logical id of the resource, which might be a unique number, a UUID, an OID, or something else involving up to 36 characters (letters, digits, “-“ and “.”). This was added because the Highrise API had an id in the same place. It’s the target of a logical id reference from somewhere else, encoded right in the resource for ease of use.

Only, it’s not so good for ease of use, which is an issue that emerged from the connectathon. There’s a few problems with putting the id inside the resource:

  • In a RESTful environment, the id of the resource is it’s location. The id is therefore duplicated between the content and the context
  • The resource itself doesn’t change if you move it (and there’s a wide variety of FHIR deployment approaches where moving resources is a very sensible thing to do), and making the content change is either tiresome or impossible if digital signatures are involved
  • When the resource is put in an atom feed, you also duplicate the id in the atom metadata
  • There’s no clearly stated context on the resource id, so you don’t know what the scope of it’s uniqueness is

We all found ourselves writing checking code that enforced that the id in the resource was the same as the context implied it to be, and otherwise ignoring it in our systems.

The only real use I’ve found for the id inside the resource is actually in publishing the FHIR spec itself, where all the examples include a logical id in the example resource which serves as the target for references in other example resources. For example, the patient example points to the person example by the ids (well, it was supposed to, and I thought it did, but I just discovered that the ids don’t match: the id of the person is 34234 while the id of the patient subject reference to person is 25bd34).

So generally, having the id in the resource turns out to be unuseful, and we propose to simply remove it, and make it a requirement that the identity of a resource, and the integrity of references to that resource must be maintained where ever FHIR is implemented. That’s already in place in the RESTful context, and in FHIR messaging/documents, so it is an additional constraint imposed on ad-hoc uses of resources in other contexts. For example, in the specification examples, we’ll simply indicate outside the resource example what the id of the resource is for the purposes of other example resources referring to the resource.

Discussion

This is a FHIR ballot issue. Comments on this blog post are discouraged – unless to point out outright errors in this analysis. Discussion will be taken up on the FHIR email list. A doodle poll will be held for the final vote – this will be announced on the FHIR email list.