url references should be fixed up just like Resource references in transactions

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • REST (http)
    • Hide

      Make explicit that when processing Bundles, elements with an explicit type of uri, url or Reference can potentially be replaced if they're referencing something in the Bundle, but not elements with a type of canonical.

      Show
      Make explicit that when processing Bundles, elements with an explicit type of uri, url or Reference can potentially be replaced if they're referencing something in the Bundle, but not elements with a type of canonical.
    • Grahame Grieve/Ewout Kramer: 5-0-0
    • Enhancement
    • Non-substantive
    • STU3

      See FHIR Connectathon 16 thread

      https://chat.fhir.org/#narrow/stream/implementers/topic/XDS.2FMHD.20.2B.20Transaction.20Semantics

      on the FHIR spec at

      http://build.fhir.org/http.html#2.21.0.17.2

      current text says:

      A transaction may include references from one resource to another in the bundle, including circular references where resources refer to each other. If the server assigns a new id to any resource in the bundle as part of the processing rules above, it SHALL also update any references to that resource in the same bundle as they are processed. References to resources that are not part of the bundle are left untouched. Version-specific references should remain as version-specific references after the references have been updated. Servers SHALL replace all matching links in the bundle, whether they are found in the resource ids, resource references, url elements, or <a href="" & <img src="" in the narrative.

      I propose that this same processing rules be clearly applied to URL datatype, not just Reference.

      For example the IHE MHD profile needs this.

            Assignee:
            Unassigned
            Reporter:
            John Moehrke
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: