Based on the expansion of the use-case to include provider-initiated member match, rather than just payer member match, the 'new Coverage' will have to be optional.  In addition, we will do the following: We will add a usage note explaining that the term "oldCoverage" actually refers to the "coverageToMatch" and the "newCoverage" actually refers to the "coverageToLink" and that we're retaining the original names to avoid issues for systems bound by regulation, but that the names might change in a future release. We will add a business rule that says "for now", that if a member match comes in with a "newCoverage", it SHALL be echoed back by the server.  However, will add a note that this requirement is likely to be removed in future versions We will add an implementation note indicating that payers SHOULD NOT depend on the presence of newCoverage in the operation response to tie request and response instances together in their system, but should instead use standard FHIR mechanisms (and include an explanation of how to do that for both synchronous and asynchronous systems) Will add a note that when invoking the operation, newCoverage is "mustSupport" and SHALL be sent by payers to allow the original payer to establish a linking in their system between old and new member and leverage this linkage information when determining authorization to share information in subsequent queries or other operations. Will also add an example for provider-to-payer member match.