launchContext.type issues

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Very High
    • Structured Data Capture (SDC) (FHIR)
    • current
    • FHIR Infrastructure
    • SDC Base Questionnaire
    • Hide
      • We will move the existing "Questionnaire Launch Context " binding to be on 'name', not 'type
      • We will make that binding 'extensible' rather than 'required'
      • We will define a new binding on the 'type' to be the list of resource types (there's a standard value set for that)
      • we will ensure that the 'value' element for each of the extension component elements is 1..1
      • We will rename the title for the extension to be "Launch Contexts" instead of "Context resources" (reflecting our rename of the extension id)
      • Will add an invariant that enforces what the allowed types are for the types specified in the value set:
        • patient: Patient
        • user: Patient, Practitioner, PractitionerRole, RelatedPerson (could be a subset of these)
        • encounter: Encounter
        • study: ResearchStudy
      • Will add usage notes to the extension indicating "If a name is specified other than one of those specified in the value set, systems will have to come to prior agreement and write code to support the additional name.  It will not be possible to dynamically automatically support new launch contexts without writing custom code."
      • Add an additional usage note: "'custom' names SHOULD have a prefix such that they won't collide with new standard context names introduced by future versions of SDC."
      Show
      We will move the existing " Questionnaire Launch Context  " binding to be on 'name', not 'type We will make that binding 'extensible' rather than 'required' We will define a new binding on the 'type' to be the list of resource types (there's a standard value set for that) we will ensure that the 'value' element for each of the extension component elements is 1..1 We will rename the title for the extension to be "Launch Contexts" instead of "Context resources" (reflecting our rename of the extension id) Will add an invariant that enforces what the allowed types are for the types specified in the value set: patient: Patient user: Patient, Practitioner, PractitionerRole, RelatedPerson (could be a subset of these) encounter: Encounter study: ResearchStudy Will add usage notes to the extension indicating "If a name is specified other than one of those specified in the value set, systems will have to come to prior agreement and write code to support the additional name.  It will not be possible to dynamically automatically support new launch contexts without writing custom code." Add an additional usage note: "'custom' names SHOULD have a prefix such that they won't collide with new standard context names introduced by future versions of SDC."
    • Paul Lynch/Joe Garcia: 5-0-0
    • Correction
    • Non-compatible

      See https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/Cardinality.20of.20launchContext.2Etype

      I think launchContext.type used to be 1..1, and then was changed in J#19500 to 1..*. Perhaps the thought was that "type" would be a list of resource types. In any case, that same issue also constrained "type" to be one of four values: patient, user, location, or encounter.

      Originally, I filed this issue to recommend changing the binding back to 1..1. However, after discussion in the above link, it seems like the best course of action would be to:

      1) Change the binding of the list for "type" to "Extensible", to allow for future development of SMART on FHIR and associated clients.
      2) Clarify that if there is more than one type provided, the types are connected via a logical "OR", not an "AND". In other words, the returned resource can be any one of the listed types.

            Assignee:
            joeegarcia
            Reporter:
            Paul Lynch
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: