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

CodeableReference data type not necessary

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • Modeling & Methodology
    • Datatypes
    • Hide

      There are two reasons for the introduction of this datatype:

      • allowing 0..* - you can't do 0..* with a choice, so this resulted in many places where we had 0..* Xcode and 0..* Xreference elements.  The new datatype allows for those to be collapsed in to one element
      • Indicating that the code and the reference were the same thing when both were provided.

      We believe that these reasons justify the creation of the new datatype and its use in resources where needed.

      Show
      There are two reasons for the introduction of this datatype: allowing 0..* - you can't do 0..* with a choice, so this resulted in many places where we had 0..* Xcode and 0..* Xreference elements.  The new datatype allows for those to be collapsed in to one element Indicating that the code and the reference were the same thing when both were provided. We believe that these reasons justify the creation of the new datatype and its use in resources where needed.
    • Lloyd McKenzie / Ron Shapiro: 3-0-1

      We don't think the CodeableReference data type is necessary.  It introduces a change that is not backwards compatible.  We don't see the problem with the existing approach using the '[x]' syntax to represent a choice of data types.  Also, we think it may be problematic from a validation perspective to require a CodeableReference data type for an element when both elements of that data type (concept and reference) are optional.  

            Unassigned Unassigned
            hstrasbe Howard Strasberg
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: