FHIR Chat · Reference Displays across Multiple Resources · implementers

Stream: implementers

Topic: Reference Displays across Multiple Resources


view this post on Zulip Weiyu Zhang (Mar 11 2021 at 00:16):

Hi all, I'm looking at some of our references to Practitioner, and wanted to get your thoughts on if reference.display can (or should) differ for the same literal reference based on context.

For DocRef.author, we currently send a literal reference + a display (for systems that don't need the literal reference):

  "author": [
    {
      "reference": "Practitioner/exvj0qm8HL0mczaMbkp1UfC-IFikz4CuJFjuDhBZvLn03",
      "display": "Provider, Sample RN"
    }
  ],

However, a Practitioner's display name may change over time - Provider, Sample RN today may become Provider, Sample NP tomorrow. We can document the Practitioner's name history in Practitioner itself, but we're not sure what we should do for these display references. Would it be better to:

1) Use the Practitioner's name as of the time of the request? (i.e. display will be Provider, Sample NP for all notes, regardless of name at time of note writing; all literal references would point to the same Practitioner resource)

2) Use the Practitioner's name as of when the DocRef was last edited? (i.e. display will be Provider, Sample NP for some notes and Provider, Sample NP for other notes, but both literal references would point to the same Practitioner resource)

Thanks!

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 01:02):

I don't think there's a right or wrong answer here. I think of Reference.display as being the same as the human-readable text part of a hyperlink. Multiple pages might link to the same URL and have different display texts. The page linked to might change over time in ways that make the hyperlink text of an old reference less-accurate/appropriate. Keep in mind that if you're changing anything about a resource (including Reference.display values) for a resource, that should trigger a new meta.lastUpdated and meta.version.

view this post on Zulip Vassil Peytchev (Mar 11 2021 at 14:53):

For the case of DocumentReference.author, however, I think 2 seems to be a better solution.

view this post on Zulip Weiyu Zhang (Mar 12 2021 at 00:13):

Got it, thanks for the feedback @Lloyd McKenzie and @Vassil Peytchev ! We'll keep the lastUpdated part in mind.


Last updated: Apr 12 2022 at 19:14 UTC