Combined resolution for FHIR-41761 and FHIR-42136   https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-procedure.html#mandatory-and-must-support-data-elements RE: Per discussions and clarifications to date, the USCDI Reason for Referral is meant to be applied to ServiceRequest which has its reasonCode and reasonReference already marked as USCDI, thus in scope for certification. There is no further language to indicate whether it is supposed to be a MAY, SHOULD or MustSupport, thus interpreted as a MustSupport. > All elements marked as USCDI are to be interpreted as Must Support by certifying systems. This is clearly documented here:  https://build.fhir.org/ig/HL7/US-Core/must-support.html#uscdi-requirements RE: This, in combination with providing an alternative method to having a more direct capability to provide the reason on a Procedure directly using .reasonCode or .reasonReference (see  https://jira.hl7.org/browse/FHIR-41761 ) should enable HIT being certified to provide the appropriate reasons for either the intent of the procedure (ServiceRequest) and/or the actual intent of the procedure (reasonCode or reasonPreference) and recognize that not all type of procedures represented in Procedure would have an ServiceRequest to link to. Decision:     Add Procedure.reasonCode and Procedure.reasonReference as  Additional USCDI Requirements  elements 0..* ReasonCode binding = US Core Condition Codes (extensible) - same as ServiceRequest.reasonCode ReasonReference reference profiles = Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) US Core Profiles Map to USCDI Requirement for  Reason for Referral Document in Profile Specific Implementation Guidance: "* The Reason or justification for a referral or consultation is communicated through: 1) the US Core ServiceRequest Profile   ServiceRequest.reason and ServiceRequest.reason elements.  The `Procedure.basedOn’ element links the Procedure to the US Core ServiceRequest Profile. ServiceRequest.reasonCode and {{ServiceRequest.reasonReference }} are marked as Additional USCDI Requirements , the certifying server system is not required to support both, but SHALL  support at least one of these elements. The certifying client application SHALL support both elements. 2) When a Procedures does not have ServiceRequest, the Procedure.reasonCode  or  Procedure.reasonReference . Although both Procedure.reasonCode and {{Procedure.reasonReference }} are marked as Additional USCDI Requirements , the certifying server system is not required to support both, but SHALL  support at least one of these elements. The certifying client application SHALL support both elements. Certifying Servers and Clients SHALL support both option 1) and 2) as Additional USCDI Requirements elements. RE: To remove ambiguity, we suggest that the language in the asterisk is changed [from "The Reason or justification for a referral or consultation is communicated through the US Core ServiceRequest Profile which can be linked to the Procedure through the {{Procedure.basedOn’ element."] to "*The Reason or justification for a referral or consultation is communicated through the US Core ServiceRequest Profile which MAY be linked to the Procedure through the }}Procedure.basedOn’ element." where the capitalization of MAY is intentional. Is not persuasive because  MAY  will lead to confusion with the definition of an  Additional USCDI Requirements Decision: See sub-bullet in above decision