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

Declaratively handle behaviour for unknown extensions

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Very High Very High
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • CapabilityStatement (Conformance)
    • Hide

      This will be addressed by new designed CapabilityStatement using a code. 

      Show
      This will be addressed by new designed CapabilityStatement using a code. 
    • Grahame Grieve / Rick Geimer: 11-0-0
    • Enhancement
    • Non-compatible

    Description

      The STU3 version of CapabilityStatement included an element acceptUnkown
      This was removed from the R4 version (see FHIR-14647)

      I believe it is still a valid requirement to declare whether a server will accept unknown extensions, or not. Separating this out to be a more explicit element ( say *acceptUnknownExtensions *) as a boolean would simplify this.

      The definition within a "requirements" capabilityStatement would be clear.

      Definition within an instance would need to be declarative against stated behaviour. This would need to be decided upon, but broadly speaking would need to be one of

      • If an unknown extension is received and there is no support then return an error
      • if an unknown extension is received and there is no support then "drop" the extension

      This would not apply to "Modifier Extensions" which already have clear guidance within the standard.

      Attachments

        Activity

          People

            Unassigned Unassigned
            rkavanagh Richard Kavanagh
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: