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

$docref should accept multiple coding parameters instead of CodeableConcept for type parameter

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Applied (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • 5.0.1
    • Cross-Group Projects
    • US Core Fetch DocumentReference
    • Hide

      Agree this makes sense, will change CodeableConcept 0..1 to  0..* Coding

      and change guidance and examples

       

      This will be a breaking change to the operation.

      Show
      Agree this makes sense, will change CodeableConcept 0..1 to  0..* Coding and change guidance and examples   This will be a breaking change to the operation.
    • Eric Haas/Brett Marquard: 13-0-1
    • Enhancement
    • Non-compatible

    Description

      See https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.24docref.20operation.20Q

      It is currently unclear how DocumentReferences should be matched based on the type parameter. Does a matching instance need to contain all codings of the "type" parameter or just one? Should the .text element of the "type" parameter be considered for matching?

      The recommendation of the Zulip thread above would be to change the "type" parameter to 0..* Codings.

      Attachments

        Activity

          People

            Unassigned Unassigned
            alexanderzautke Alexander Zautke
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: