The Referral Note template includes the following conformance statements:

5. SHOULD contain zero or more [0..*] participant (CONF:1198-31642) such that it
a. SHALL contain exactly one [1..1] @typeCode="IND" Indirect (CodeSystem: HL7ParticipationType urn:oid:2.16.840.1.113883.5.90) (CONF:1198-31924).
b. SHALL contain exactly one [1..1] associatedEntity (CONF:1198-31643).
i. This associatedEntity SHALL contain exactly one [1..1] @classCode, which SHALL be selected from ValueSet INDRoleclassCodes urn:oid:2.16.840.1.113883.11.20.9.33 DYNAMIC (CONF:1198-31925).
ii. This associatedEntity SHALL contain exactly one [1..1] associatedPerson (CONF:1198-31644).
1. This associatedPerson SHALL contain at least one [1..*] US Realm Patient Name (PTN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1) (CONF:1198-31645).

So, suppose you have the following participant:

<participant typeCode="IND">
    <time value="20200304" />
    <associatedEntity classCode="ECON">
        <id extension="99999" root="1.2.840.114350.1.13.239.2.7.2.827665" />
        <code nullFlavor="OTH">
            <originalText>Spouse</originalText>
        </code>
        <addr use="HP">
            <streetAddressLine>123 Contact St</streetAddressLine>
            <city>Beaverton</city>
            <state>OR</state>
            <postalCode>97867</postalCode>
            <country>USA</country>
        </addr>
        <telecom use="HP" value="tel:+1-555-555-5555" />
        <associatedPerson>
            <name>Eva Betterhalf</name>
        </associatedPerson>
    </associatedEntity>
</participant>

 Clearly this doesn't conform to the statements above (in particular, the associatedPerson/name isn't a structured US Realm Patient Name). But since this is a "such that it" conformance statement, it should still be totally allowed to have participants that don't follow it, like this one. However, if you put this participant in the header of a Referral Note, you can see the C-CDA schematron flag it as an error. (The ONC's doesn't, for what it's worth.)

This seems like an issue with the schematron that should be fixed. We should probably also look into US Realm Address validation since names and addresses are both validated in the schematron with a long list of XPath nodes where their rules should apply, but apparently it's turning up a false positive here.