Section 4.2 begins with a complex SHALL: "When transmitting identity attributes to third parties..." that needs to be clarified as follows:

• For the listed cases, we need to reference the mechanisms to indicate the level of identity assurance, if there are any, or note their absence. It may be that the point here is to write this with an eye towards the future (as it's on the STU2 radar), but given there are currently no normative capabilities (OIDC has amr and acr but no standard vocabulary), an implementer may find this hard to follow.
• For the sub-case "and a level of identity assurance is indicated", it is essentially saying "tell the truth - don't claim verification you didn't perform". Is this not typically addressed by policy for all data exchanged by systems? Also, it's not testable, as only the levels would be shared, not evidence the human process was followed.
• For the sub-case "or be consistent with other evidence used in that identity verification process completed by that party", this seems to allow an assurance level to be asserted where it was not verified at that level.
• For the sub-case "When transmitting identity attributes", beyond the three listed cases (the "such as" makes this an open-ended requirement), how is this enumerated/testable/enforced? Does this apply to every exchange of PII, for example, returning a Patient resource?
• Is the rest of the paragraph subject to the prior condition "When transmitting identity attributes to third parties..."? Is the rest of section 4.2?
• For the requirement "If a level of assurance is not explicitly asserted, the combination of identity attributes submitted SHOULD be consistent with, and sufficient to on their own resolve to the identity of a unique person in the real world", is the intent to discourage exchange of incomplete patient demographics like just first and last name?