Call for comments: Logical references

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:

refid

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)

18 Comments

  1. This makes sense: it would allow a FHIR resource to reference that is not stored as a resource. :

  2. Lloyd McKenzie says:

    This pattern is low value (and undesirable) when dealing with RESTful interfaces. However, it’s super common in the messaging and documents worlds where there may not be any FHIR servers around exposing some (or even any) of the records that are being shared.

    The use-case exists and it’s going to be met within FHIR. The only question is whether we recognize it as an official part of the standard and how hard we make it. (It can be done now, awkwardly using contained resources or more easily using extensions.)

    So in the end, systems can’t avoid having to deal with this. I don’t believe it’s appropriate to make something that’s essential to messaging and documents painful because it’s not good practice in REST. If we want to guide behavior in REST, we should do that using IGs, test tools, validation, etc.

  3. Thomas Lukasik says:

    +1 (What @Lloyd said..)

  4. Lars Kristian Roland says:

    Would you be able to have both a reference to a resource-id (“/Patient/”) and an identifier, in the same resource? Or either a ref or an identifier?

  5. Kathy Walsh says:

    This section sounds dangerous. “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…).”

    • Grahame Grieve says:

      yes. that’s right. Identifier practices are often dangerous in the real world. Of course, we deplore that, but we also have to be realistic (or alternatively, we could consider that such practices are safe, as long as we don’t assume that the identifiers have the kind of meaning you need for interoperable identifiers)

  6. Kevin Mayfield says:

    What is the reasoning behind using identifiers? Couldn’t we use an attribute to show the reference is logical. It would cause less change to existing code (that use logical references)

  7. Kevin Mayfield says:

    My post was truncated.

    In the UK-England our hospital systems should have only one patient that has a NHSNumber. None of the hospitals use this as an Id but we all would refer to it in provider to provider exchanges.

    Reference value = http: / / fhir.nhs.net / Id / nhs-number /9000000084

    type = logical

  8. Lars Kristian Roland says:

    In principle, how would logical references be different from using a contained Patient-object with an identifier (for example) and refering to this? Is there an implicit check on the web server that the reference links to a real patient or some other behaviour attached to using a reference to identifier directly?

    • Grahame Grieve says:

      Good question. We discussed this at length. Contained resources are created for use where you have information about a resource, but no identity. Here you have the inverse case – an identity but no information. And it turns out that there are cases where this isn’t a great fit. For instance, you don’t have the minimum mandatory information for any resource – and, well, you wouldn’t, because you don’t have any information.

      • Lars Kristian Roland says:

        But if you have the identity, then the two ways of doing it would be very similar? Except you don’t need to change FHIR to achieve having a contained Patient-resource with only the identity?

        • Lloyd McKenzie says:

          A contained resource and an identifier actually mean something different. A contained resource is a business object, albeit with limited information. On the other hand, a reference with just an identifier is a “pointer” to a business object (which isn’t expected to be resolvable, at least not in the typical RESTful sense).

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: