Two tasks have been created from the current FHIR Ballot: 10354, and 10659. Both propose the same basic idea: to allow a reference to refer to an item by it’s logical identifier rather than a direct URL. This is a pretty significant change, so we’re calling for comments from the FHIR Implementer community.
The basic idea is pretty simple. A reference from one resource to another is a URL that identifies where the content of the resource can be found. For example, Observations nominate the patient that the observation is made on:
<Observation xmlns="http://hl7.org/fhir"> ... <subject> <reference value="http://acme.com/fhir/Patient/example"/> </subject> ... </Observation>
This means that the patient resource can be accessed at the given URL. A reference can also be relative, like this:
<Observation xmlns="http://hl7.org/fhir"> ... <subject> <reference value="Patient/example"/> </subject> ... </Observation>
This means that patient resource location is relative to the end-point at which the Observation was found. Both these approaches assume that the author of the resource knows exactly where the patient resource is found. In a purely RESTful environment, that’s a good safe assumption. But the FHIR community is encountering a number of situations where the address at which a resource is located is not know, even they key identifying information about the target is. In the case in point, this means that the application has a patient identifier, but it doesn’t know where the server for the patient is (or it doesn’t exist) and even if it does, the patient resource id the server uses it isn’t the same as the patient identifier, and there is no obvious conversion (in fact, it’s quite often that the patient identifier is not sufficiently reliable to use in the URL – they change…).
So the proposal is that FHIR should change so that this is valid:
<Observation xmlns="http://hl7.org/fhir"> ... <subject> <identifier> <system value="http://hl7.org/fhir/sid/us-ssn"/> <value value="5551234567"/> <identifier> </subject> ... </Observation>
This is a reference to a patient by their identifier. It’s the responsibility of the reader of the resource to decide how to resolve this reference to a resource (or some other kind of resource) – if they can. Or to decide what to do about it if there’s multiple candidate matches – which is also possible.
This is a fairly significant change. There’s already resources where this pattern is baked in by using a data type choice – see, for example, ExplanationOfBenefit:
Generalising this pattern so it applies anywhere there’s a reference – without having to be explicit in the design as above – is both good and bad, depending on who you are. Generally, it allows a resource writer to move work to the resource reader, but it also allows a resource writer to write resources it otherwise couldn’t?
We’re calling for comments on this issue from implementers, to help us decide. Please comment on the second task (10659)