Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-24888

Operation to find all references to a resource

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Very High Very High
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • operations
    • Hide

      We will define support for _revinclude=*

      We will document that this means "all _revincludes supported by the server", which will typically only be references that are indexed.  We don't believe enforcing referential integrity across non-indexed references is reasonable or necessary.

      While we're at it, we'll also define _include=* with the same expectation of only getting back those resources the server supports for _include with the specified base resource.

      Will indicate that '*' should be declared in CapabilityStatement the same as any other include or revinclude.

      Show
      We will define support for _revinclude=* We will document that this means "all _revincludes supported by the server", which will typically only be references that are indexed.  We don't believe enforcing referential integrity across non-indexed references is reasonable or necessary. While we're at it, we'll also define _include=* with the same expectation of only getting back those resources the server supports for _include with the specified base resource. Will indicate that '*' should be declared in CapabilityStatement the same as any other include or revinclude.
    • Rick Geimer/Eric Haas: 20-0-0
    • Enhancement
    • Compatible, substantive
    • R5

    Description

      _include and _revinclude implies that you know what resource types (and their search parameters) might be referencing a given resource.
      I would like a way to blindly search for any resource and/or resource type that references a given resource. For example:

      https://hapi.fhir.org/baseR4/$reference-search?target=Patient/pat1

      In this case, the server could respond with everything that references Patient/pat1, which may be one or many different resource types.

      It would be even better if the response could enumerate where the reference lies within each of the resources that reference Patient/pat1.

      If an application allows the user to delete resources on the FHIR server, the application should be able to find everything that references the resource the user wants to delete so that it can prompt the user and say "the following resources reference the resource you're wanting to delete: A, B, C. Are you sure you want to continue." With the information from the $reference-search operation (such as the location of the references within each of the resources that reference it), the application could then delete the references prior to deleting the resource, with the ultimate goal of ensuring referential integrity.

      Attachments

        1. operationdefinition-references.xml
          3 kB

        Activity

          People

            ginocanessa Gino Canessa
            seanmcilvenna Sean McIlvenna
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: