Background: Because EHR vendors could not reach a consensus on a single profile structure to meet a USCDI ( and CCDS before that) requirement, we have defined instances in this Guide where there is a choice of supporting one or another profile element.  This pattern began in Argonaut DSTU2 with the representation of medication and continues through the current ballot.  In Version 4.0.0 we introduced a Conformance page to document the expectations for mandatory and must support elements in the US Core Profiles and defined this "Choice of Profile Elements" pattern  ( see: http://build.fhir.org/ig/HL7/US-Core/conformance-expectations.html#must-support---choice-of-profile-elements). As Described in FHIR-34553 , an invariant can require an element to be present (conditionally mandatory) but an invariant can not require an element to be must support (conditionally must support).  There are no examples of this in US Core or any other IGs based upon our review.  Therefore this would be a novel  ( and complex ) conformance structure. Because there is no consensus among EHR vendors on how to represent  Condition Date of Diagnosis  to meet the USCDI V2 requirement, and there no way to express a conditionally must support via an invariant, the Choice of Profile Elements" pattern is used here to represent it as follows (note there is separate tracker to clarify this text): There is no single element in Condition that represents the date of diagnosis. It may be the  assertedDate Extension ,  Condition.onsetDate , or  Condition.recordedDate . Although all three are marked as must support, the server is not required to support all [three] . A server  SHALL  support  Condition.recordedDate . A server  SHALL  support at least one of  assertedDate Extension  and  Condition.onsetDate . A server may support both, which means they support all 3 [elements] . The client application  SHALL  support all three elements. Reasoning: Based on the background given above, we disagree with the commenter's assertions that an invariant would satisfy the requirements and that the existing pattern is unusual or novel for US Core.  Proposed Changes: There is no action needed by US Core on this issue.