The following elements have cardinality 1..1 in QI Core, constraining the US Core cardinality from 0..1 - note that MedicationStatement is not derived from US Core but the respective element is the same as referenced in MedicationRequest and should be handled the same:

• Procedure.recorded
  • This element was added to address procedures performed elsewhere documented in the record whether historical or recent. The assumption is that Procedure.performed[x] will not be available and the base FHIR resource (FHIR R5) includes Procedure.recorded; thus it is the direction proposed for FHIR.  However, the element is only necessary for a measure seeking to include a recorded time and clinical software can provide ability to enter a procedure with a date (I.e., Procedure.performed[x] even if not performed by the organization documenting.  
• MedicationRequest.authoredOn
  • MedicationRequest.authoredOn represents the time the prescription/request happened. That is different from the time the patient should take the medication (MedicationRequest.medication[x]).  While MedicationRequest use includes determination of an active Medication List and timing the request occurred, the authoredOn value seems to be a reasonable element to meet measure intent as distinct from when the medication should be taken by the patient and the element is used in Cumulative Medication Duration.  However, the element is only necessary for a measure seeking the time the order is placed since status=active can indicate the medication belongs on the Medication List. 
• Immunization.recorded

• • QI-Core 6.0 Immunization.recorded element allows reference to immunizations recorded from information elsewhere. However, it seems that existing workflow from interoperability with immunization registries should allow documentation of immunization.occurrence timing in most cases. Immunization.occurrence[x] has the same cardinality 1..1 as US Core.  For cases in which the individual entering the data into the record, the date would still be entered consistently with Immunization.occurrence.
• MedicationStatement.dateAsserted
  • Cardinality of MedicationStatement.dateAsserted is 1..1 and effective[x] is 0..1 (effective is time when medication was/is/should be taken.  Currently, no eCQMs use MedicationStatement but the date asserted indicates when someone updated the statement.  Technically, if a measure was to require MedicationStatement information the date asserted should be pretty essential to the measure meaning, i.e., at what point was this medication list accurate? Still, the element should be required (cardinality 1..1) if used in measure logic.
• ServiceRequest.authoredOn
  • US Core cardinality is 0..1. However, in measures existence of an order/plan for a procedure indicates the request is “active” (or other status) but not when the request occurred. In most measures, the request/order must occur within a specific timeframe compared to another measure element to be valid.  ServiceRequest.occurrence[x] indicates when the service should occur – not when the request was made. The timing of when the service request happened is important to measures. However, given the direction to drive QI-Core content from measure or CDS intent, it seems cardinality of 0..1 should be sufficient.

For all of these elements, change cardinality to 0..1.