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

Consider new datatype for instantiatesCanonical/instantiatesUri

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • Clinical Decision Support
    • CarePlan
      Communication
      Contract
      DeviceRequest (was DeviceUseRequest)
      FamilyMemberHistory
      GenomicStudy
      NutritionOrder (was NutritionRequest)
      Procedure
      RequestOrchestration (was RequestGroup)
      ServiceRequest (Diagnostic/Procedure/ReferralRequest)
      Task
      Transport
    • Hide

      All of the 'instantiates' elements should go away as we're now using extensions (four different ones) to meet the use-case previously met by these elements.

      Bryn believes there are other places where this same pattern exists. He will submit a new tracker item for consideration in R6 that enumerates the places where a choice of repeating canonical|uri either exists or should exist where a new data type would be useful.

      Show
      All of the 'instantiates' elements should go away as we're now using extensions (four different ones) to meet the use-case previously met by these elements. Bryn believes there are other places where this same pattern exists. He will submit a new tracker item for consideration in R6 that enumerates the places where a choice of repeating canonical|uri either exists or should exist where a new data type would be useful.
    • Bryn Rhodes/Rick Geimer: 16-0-3

    Description

      There are a number of resources which contain the following two elements:

      • instantiatesCanonical
      • instantiatesUri

      This occurs 16 times (across 14 resources).  Since this seems to be a well-established pattern, and since these elements are similar in purpose, it might be beneficial to formalize this construct.

      Unfortunately, instantiates[x] cannot be used because the cardinality is 0..* on many of these (and perhaps some instances should use both kinds).

      This is why we should consider creating a new datatype to represent this pairing, similar to CodeableReference.

      One question that arises is if it ever make sense to have both a canonical and uri representation paired (indicating different representations of the same thing)?

      • If yes (pairing a canonical and uri could make sense), then this is much like CodeableReference - so there is precedent to introduce a type like this.
      • If no (it should always be a canonical or a uri), then the datatype would either have two elements w/ an invariant OR would have a single target[x] element (canonical | uri). Introducing such a thing likely requires more thought.

      If this has been discussed in the past, I apologize for bringing it up again!  But if not, it is probably worthy of some discussion.

      Here is a listing of where we find this pattern in the FHIR R5 Ballot spec:

      0..* CarePlan.instantiatesCanonical
      0..* CarePlan.instantiatesUri
      0..* CarePlan.activity.plannedActivityDetail.instantiatesCanonical
      0..* CarePlan.activity.plannedActivityDetail.instantiatesUri
      0..* Communication.instantiatesCanonical
      0..* Communication.instantiatesUri
      0..1 Contract.instantiatesCanonical
      0..1 Contract.instantiatesUri
      0..* DeviceRequest.instantiatesCanonical
      0..* DeviceRequest.instantiatesUri
      0..* FamilyMemberHistory.instantiatesCanonical
      0..* FamilyMemberHistory.instantiatesUri
      0..1 GenomicStudy.instantiatesCanonical
      0..1 GenomicStudy.instantiatesUri
      0..1 GenomicStudy.analysis.instantiatesCanonical
      0..1 GenomicStudy.analysis.instantiatesUri
      0..* NutritionIntake.instantiatesCanonical
      0..* NutritionIntake.instantiatesUri
      0..* NutritionOrder.instantiatesCanonical
      0..* NutritionOrder.instantiatesUri
      0..* Procedure.instantiatesCanonical
      0..* Procedure.instantiatesUri
      0..* RequestGroup.instantiatesCanonical
      0..* RequestGroup.instantiatesUri
      0..* RequestOrchestration.instantiatesCanonical
      0..* RequestOrchestration.instantiatesUri
      0..* ServiceRequest.instantiatesCanonical
      0..* ServiceRequest.instantiatesUri
      0..1 Task.instantiatesCanonical
      0..1 Task.instantiatesUri
      0..1 Transport.instantiatesCanonical
      0..1 Transport.instantiatesUri

      Attachments

        Activity

          People

            Unassigned Unassigned
            cmoesel Chris Moesel
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: