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

Add _lastUpdated search parameter for all resources

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Core (FHIR)
    • 7.0.0-ballot
    • Cross-Group Projects
    • Search Parameters and Operations
    • 6.2.2
    • Hide

      Background

      The  2024 Argonaut Project: Detecting and Reporting Changes held a series of calls with implementers to address the issues surrounding this tracker and related trackers to FHIR core. 

      Decision

      Based on the call series, add the following guidance to US Core: (see Mockup)

      1. Add Meta.lastUpdated element as Must Support 0..1 for:

      • US Core Laboratory Result Observation Profile
      • US Core DiagnosticReport Profile for Laboratory Results Reporting
      • US Core Condition Problems and Health Concerns Profile
      • US Core Encounter Profile

      2. Add_lastUpdated search parameter combinations as a recommended (SHOULD) Server RESTful FHIR interactions for US Core resource types listed above as follows:

      • Observation: patient + category + _lastUpdated
      • DiagnosticReport: patient + category + _lastUpdated
      • Condition: patient + category +_lastUpdated
      • Encounter: patient + _lastUpdated

      3. Add The Searching using lastUpdated section provides general guidance on representing when the Profile content changed using with Meta.lastUpdated and using the _lastUpdated search parameter

      Questions regarding additional last updated guidance in US Core?

      •   Keep guidance from earlier resolution removing the aggrieved parts (see mocked up section Here)?
        •  add servers SHOULD support some level of lastUpdated queries (i.e., 
          servers can populate this field with a best effort and (SHALL) document what they support  CapabilityStatement.rest.resource.searchParam.documentation ?
        • separate note to client bullet :  and false negatives/positives are possible)
      • Add SHOULD guidance to each of above profiles (see mock )? 
        • STU Note to turn these into SHALL next year (see project text)? update from "Note: Based upon additional testing we intend to to upgrade this Meta.lastUpdated guidance (SHOULD) to requirements (SHALL) in the next version of US Core)"
      •  Additional delete guidance ?
        • project recommendations: 
          • Deleting resources can cause issues with clients looking for updates (i.e., orphaned records continue to exist)
          • Today, a best practice recommendation is to change the resource's status element to entered-in-error and redact all PHI from the resource representation, rather than causing the resource to disappear from the API.
        • updated current US Core guidance from 

      4. Update examples

      5. Update CapabilityStatement

      • _lastUpdated combos for above type

       

      Show
      Background The   2024 Argonaut Project: Detecting and Reporting Changes held a series of calls with implementers to address the issues surrounding this tracker and related trackers to FHIR core.  Decision Based on the call series, add the following guidance to US Core: (see Mockup ) 1. Add Meta.lastUpdated element as Must Support 0..1 for: US Core Laboratory Result Observation Profile US Core DiagnosticReport Profile for Laboratory Results Reporting US Core Condition Problems and Health Concerns Profile US Core Encounter Profile 2. Add_lastUpdated search parameter combinations as a recommended (SHOULD) Server RESTful FHIR interactions for US Core resource types listed above as follows: Observation: patient + category + _lastUpdated DiagnosticReport: patient + category + _lastUpdated Condition: patient + category +_lastUpdated Encounter: patient + _lastUpdated 3. Add The Searching using lastUpdated section provides general guidance on representing when the Profile content changed using with Meta.lastUpdated  and using the  _lastUpdated search parameter Questions regarding additional last updated guidance in US Core?   Keep guidance from earlier resolution removing the aggrieved parts (see mocked up section Here )?  add servers SHOULD support some level of lastUpdated queries (i.e.,   servers can populate this field with a best effort and ( SHALL ) document what they support   CapabilityStatement.rest.resource.searchParam.documentation ? separate note to client bullet :   and false negatives/positives are possible) Add SHOULD guidance to each of above profiles (see mock )?  STU Note to turn these into SHALL next year (see project text)? update from "Note: Based upon additional testing we intend to to upgrade this Meta.lastUpdated  guidance ( SHOULD ) to requirements ( SHALL ) in the next version of US Core)"  Additional delete guidance ? project recommendations:  Deleting resources can cause issues with clients looking for updates (i.e., orphaned records continue to exist) Today, a best practice recommendation is to change the resource's  status  element to  entered-in-error  and redact all PHI from the resource representation, rather than causing the resource to disappear from the API. updated current US Core guidance from  entered-in-error deleted   to this mocked up section on deleled 4. Update examples 5. Update CapabilityStatement _lastUpdated combos for above type  
    • Isaac Vetter/Brett Marquard: 22-0-0
    • Enhancement
    • Compatible, substantive

    Description

      The `_lastUpdated` search parameter, applicable to all resource types (see http://hl7.org/fhir/r4b/search.html#lastUpdated) is useful to download only resources that have changed or are new since a given date. It can also be used in reverse, finding resources older and not changed since a given date.

      In our experience, this parameter has been implemented by many vendors, however it's absent from all of US Core. It would be good to include the `_lastUpdated` search parameter in section 6, "Search Parameters and Operations", and suggest it SHOULD or even SHALL be supported for all resource types. Issuing the query parameter should select any resource that has changed or has been added since or before the given date or date-time.

      It might be worthwhile to bring this change back to US Core 6.1 given it's already been implemented widely.

      Attachments

        Activity

          People

            Unassigned Unassigned
            pascal Pascal Pfiffner
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: