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

Date math should be allowed with any definite-duration units

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • Clinical Quality Language (FHIR)
    • 1.5
    • Clinical Decision Support
    • Authors Guide
    • 5.4.4. Date and Time Arithmetic
    • Hide

      Comparison and calculation between calendar years and months is not supported to ensure that those durations aren't confused with the mathematical definite-duration UCUM units. However, to align with FHIRPath and existing reference implementation, we will relax for days, weeks, hours, and minutes. Apply definite-duration comparison and calculation at weeks and below (only months and years are not comparable)

      Show
      Comparison and calculation between calendar years and months is not supported to ensure that those durations aren't confused with the mathematical definite-duration UCUM units. However, to align with FHIRPath and existing reference implementation, we will relax for days, weeks, hours, and minutes. Apply definite-duration comparison and calculation at weeks and below (only months and years are not comparable)
    • Chris Moesel/Peter Muir: 19-0-0
    • Correction
    • Non-substantive

    Description

      The specification states

      Using a definite-quantity duration above seconds in a date/time arithmetic calculation will result in a run-time error.

      This seems to me like it would cause problems since many data models may have properties that are defined as quantities that only support UCUM units (or more specifically, don't explicitly support CQL units).  Enforcing the rule above could result in run-time errors for any mathematical calculations that use duration-based quantities from the data model.

      For example, FHIR MedicationRequest has a dispenseRequest property that contains an expectedSupplyDuration property which is a Duration.  By definition that duration must be defined using UCUM units (and will often be expressed in units greater than seconds).  So... any CQL logic that attempts to add dispenseRequest.expectedSupplyDuration to a dispense date (for example) will fail with an error based on the language in the spec above.  This doesn't seem like an acceptable outcome.  I think this limitation needs to be removed from the spec.

       

       

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: