Based on implementer feedback, many facade servers cannot faithfully populate the Meta.lastUpdated element but do want to provide timing information based on changes they track. For example, an EHR knows when an Observation.status has changed but may be using a local mapping table for codes in the Observation and not track that a display name has been updated.

In order to provide that information to clients, we propose adding a new extension called last-underlying-data-update:

• Name: last-underlying-data-update
• Cardinality: 0..1
• Context: Meta
• Type: instant
• Short: When the server last updated underlying data relating to this resource
• Definition: An instant that identifies when data on a server has been updated that may impact this FHIR resource.
• Comments: This extension is used in situations where a server cannot track every type of change to a resource but still wants to indicate the times when data for the resource is changed.  For example, many servers generate instance details by mapping sets of codes from an internal system when an instance is requested.  In the case that the mapping table is updated, there may be millions of records changed which is not currently feasible to track on each individual instance.  This extension allows servers to track when core or significant resource elements (e.g., status, etc.) are changed without needing to track the entire graph of possible changes.

Paired with the extension, we would like to add a new search parameter, _lastUnderlyingDataUpdate:

• Name: _lastUnderlyingDataUpdate
• Type: date
• Context: All resources
• Definition: Matching is performed against either the element Resource.meta.lastUpdated, the last-underlying-data-update extension, or an implementation's internal equivalent.

For additional context, please see the call notes for Detecting and Reporting Changes.