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

per-1 invariant limits representation of real-world periods

    XMLWordPrintableJSON

Details

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

      Will add to the FHIR FHIRPath page a definition of the lowBoundary and highBoundary functions as applicable to any continuous variable (time, dateTime, instant, date, decimal, integer, Quantity).  Will note that these functions will eventually be migrated to the core FHIRPath spec.

      Will update the invariant to use these new functions.  Specifically:

      start.empty() or end.empty() or (start.lowBoundary() <= end.highBoundary())

       

      Will also define a FHIRPath function of Quantity.comparible(Quantity) that returns true if the two Quantities are comparable.  Comparable means that both have values and that the code & system for the units are the same (irrespective of system) or both have code + system, system is recognized by the FHIRPath implementation and the codes are comparable within that code system.  E.g. days and hours or inches and cm.

      Will mark this one for migration to FHIRPath too and submit a change request to do so.

       

      Will also change for Range

      low.value.empty() or high.value.empty() or (low <= high)

      to 

      low.empty() or high.empty() or low.lowBoundary().comparable(high.highBoundary()).not() or (low.lowBoundary() <= high.highBoundary())

      Grahame to check whether lowBoundary and highBoundary are necessary here.

      Show
      Will add to the FHIR FHIRPath page a definition of the lowBoundary and highBoundary functions as applicable to any continuous variable (time, dateTime, instant, date, decimal, integer, Quantity).  Will note that these functions will eventually be migrated to the core FHIRPath spec. Will update the invariant to use these new functions.  Specifically: start.empty() or end.empty() or (start.lowBoundary() <= end.highBoundary())   Will also define a FHIRPath function of Quantity.comparible(Quantity) that returns true if the two Quantities are comparable.  Comparable means that both have values and that the code & system for the units are the same (irrespective of system) or both have code + system, system is recognized by the FHIRPath implementation and the codes are comparable within that code system.  E.g. days and hours or inches and cm. Will mark this one for migration to FHIRPath too and submit a change request to do so.   Will also change for Range low.value.empty() or high.value.empty() or (low <= high) to  low.empty() or high.empty() or low.lowBoundary().comparable(high.highBoundary()).not() or (low.lowBoundary() <= high.highBoundary()) Grahame to check whether lowBoundary and highBoundary are necessary here.
    • Grahame Grieve/Ron Shapiro: 3-0-0
    • Correction
    • Non-substantive
    • R5

    Description

      The Period data type has this invariant:

      per-1 If present, start SHALL have a lower or equal value than endstart.hasValue().not() or end.hasValue().not() or (start <= end)

       

      On the surface, this seems fine, however, the way FHIRPath <= works, the start and end timestamps have to have the same precision for the start<=end comparison to resolve.  Detailed discussion of that occurred here in this chat.fhir topic

       

      We have real-world data (in this case, Encounter data) that has these start/end timestamps:

       
          "period": 

      {         "start": "2023-06-21",         "end": "2023-06-21T06:20:00Z"     }

      ,
       
       
      This is legacy data, and we simply don't know the timestamp of the start date.
       
      Right now, we are unable to represent these Encounters as valid FHIR resources.  
       
      I think there are a few options: # Update Encounter to use something other than the Period data type for representing the Encounter period.  This seems weird - Period seems like the correct data type.

      1. Update FHIRPath to change how date comparison happens.  I'm not familiar enough with the reasons behind why FHIRPath does what it does to know if this is a good option or not.
      2. Update the per-1 invariant to handle the comparison of timestamps with differing precisions differently.
      3. Provide narrative guidance on what systems should do when they have data that does not comply with the invariant.  Should we truncate down to the lowest precision?  This seems bad as we'd be losing possibly useful information.  Should we add precision, for example by defaulting midnight in the case where we don't have a timestamp?

       

       

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: