Consider Relaxing Reference.Identiifer Cardinality from 0..1 to 0..*

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • R4
    • FHIR Infrastructure
    • References
    • 2.3.0
    • Hide

      Our rules for normative elements mean that we can't change max cardinality.  We will define a standard extension called 'additionalIdentifiers' for Reference and will update the usage notes for Reference.identifier to point to the extension.

      Show
      Our rules for normative elements mean that we can't change max cardinality.  We will define a standard extension called 'additionalIdentifiers' for Reference and will update the usage notes for Reference.identifier to point to the extension.
    • Enhancement
    • Non-substantive

      For FHIR servers using logical references, the existing 0..1 Reference.identifier cardinality forces the server to pick a single business identifier to send when it might know of multiple identifiers. In these scenarios, the server is forced to pick a "primary" identifier to send (and hope that clients are using the same "primary" identifier), rather than sending all known identifiers (allowing clients to determine which identifier(s) they care about).

       

      For example:

      • I'm trying to send a logical reference to encounters in DocumentReference.context.encounter.
      • Due to not having a FHIR Encounter resource to represent the physical visit, I'm using logical references rather than a literal reference to a FHIR encounter resource.
      • I have multiple encounter business identifiers available (EHR generated visit ID + lab system issued visit ID).
      • I can only send one identifier today due to the cardinality constraint, but I don't know which one clients would like (are they using the EHR visit ID or the LIS visit ID).
      • If Reference.identiifer was 0..*, I can send both identifiers and let clients decide which identifier type to use.

      (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Reference.2EIdentifier.20Cardinality)

            Assignee:
            Unassigned
            Reporter:
            Weiyu Zhang
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: