Meta.lastUpdated has this definition:

For façade servers, which don't store resources, this definition is a little tricky.  Especially if there isn't some room for "hand waving".

Some examples of why this definition is problematic:

• Facade servers generate resources on-the-fly in response to requests, so the strict interpretation of this definition means that lastUpdated is just always "now" (when the API request was processed.  This is of course not useful (or the intent).
• Facade servers will usually have an internal "record" rather than a "resource".  For example, an EHR may have a Patient "record that has hundreds or thousands of elements in the schema, some of which map to the Patient resource, but others that map to other resources like Coverage, CareTeam, etc.  Servers may know when the "record" changed, but that is not the same as when the resource is updated. 
• Facade servers may use static terminology mappings for some record types.  When those terminology mappings are updated, that could cause the rendered resources to change.  For example, if you have the wrong CPT code mapped to a procedure, and an IT admin fixes that mapping, then all Procedure resources would reflect that change, but the internal Procedure record would not have an updated timestamp.

US Core is considering how to roll out _lastUpdated support in FHIR-43659, but as part of that we realized that the core spec definition is just problematic in general for façade servers in ways that can lead to both false positives and false negatives in any practical implementations of _lastUpdated.

Request:  either consider updating the definition of lastUpdated to indicate that false positives and false negatives are allowed and possibly expected, especially for façade servers.  Alternatively, create a new parameter that has that flexibility which facade servers could choose to support instead of _lastUpdated.