"The IG creates implementation optionality for electronic medical record (EMR) and Health IT Vendors by allowing determination of when to contact a payer and level of information a payer would be permitted to receive.  This optionality will create custom integration requirements across the ecosystem." The determination of when to contact the payer is driven by the supported hooks.  We can explore mandating the support of specific hooks in future releases when there is more experience with them.  In terms of the information a payer receives in the hook, that's tightly defined.  In terms of the information a payer can retrieve, that's wide open, though a provider organization can choose to not return information they consider sensitive or don't have consent to share - recognizing that that might limit the decision support provided.  There won't be any custom integration requirements as the interfaces the providers are expected to expose are standardized by US core.  Payers can't demand any information that the US Core interfaces don't already require be exposed. However, we will tighten the conformance expectation for payers.  We will change: "CRD Services conforming to this implementation guide  SHALL  provide a service for at least one of the hook types listed below and  SHOULD  support all hooks that are relevant to the types of coverage provided by any payers associated with that service." to "CRD Services conforming to this implementation guide  SHALL  provide a service for all hooks required of CRD clients by this implementation guide unless they have determined that the hook will not be reasonably useful in determining coverage or documentation expectations for the types of coverage provided." We will also append to "CRD Clients conforming to this implementation guide  SHALL  support at least one of the hooks listed below and  SHOULD  support all that apply to the context of their system." the following: "Future releases of this specification may increase expectations to support additional hooks."   "The IG allows for de-identifiable responses from the EMR. De-identifiable coverage and patient resources would circumvent the underlying payer care coordination process" Support for de-identified CRD has been removed   "The IG assumes the request - response are 1:1; however, an order could contain multiple requests and it is possible not all requests would be covered or require authorization" There is no such presumption.  A single hook invocation can pass multiple orders.  And a hook response can include multiple cards.  Each card can tie itself to 0..* orders.  So it's quite possible to have cards indicating that some orders aren't covered, some require prior authorization (and possibly DTR launch), some orders have been pre-emptively authorized, and still other orders are fully covered without authorization being needed.