1. Will change "Servers SHALL provide their card responses within 5 seconds, 95% of the time" to "This specification sets a target duration in which CRD Services are expected to return their CDS Hooks response after being invoked.  CRD services SHALL return responses for all supported hooks and SHALL respond within the required duration 90% of the time.  (I.e. all [primary] hooks and any [supporting] hooks where they opt to support the hook.)  For most hooks, this target time is 5 seconds.  It extends to 10 seconds for [Appointment Book] and for [Order Dispatch] and [Orderset Revision] hooks that are sent at least 24 hours after the last hook invocation for the same order(s) because there is no opportunity to cache data in those cases." 2. Will change "5 second window" to "time window". 3. Will add a new paragraph saying "CRD services are encouraged to leverage hooks fired earlier in the workflow (even if they do not provide decision support in response to those hooks) as an opportunity to begin 'caching' relevant information for use when providing responses to later hooks.  For example, when an Encounter Start hook fires, the CRD service can retrieve and 'cache' the patient's current coverage information and details about their specific plans, limits, etc.  When an Order Select fires, the service can cache information about coverage and authorization rules associated with the ordered service.  Potentially relevant information such as past labs, prior therapies, relevant diagnoses, etc. can also be retrieved from the EHR.  As a result, when an Order Sign or Order Dispatch hook fires, the CRD service should have almost all information needed to render an immediate decision, allowing response times to be met much more easily. A determination that additional information is needed (e.g. via DTR) is considered to be a valid response.   [add language here from FHIR-36511] If a CRD service exceeds the allocated time window for a hook (i.e. for those circumstances that fall outside the 90% expectation), CRD clients SHOULD establish a time-out process that ensures users are not blocked from proceeding with their business flow.  Where a CRD client opts to not block users from proceeding for responses that come back in a period of time shorter than the target time window in this guide (i.e. 5/10 seconds), the client must ensure that users are made aware of the information when it is available.  For responses that come back in a time period that exceeds this duration, CRD clients MAY ignore the resulting cards and/or system actions." 4. Will add a section at the start of the hooks page called "Hook categories" that says: The hooks supported by this guide can be categorized into two types: 'primary' hooks and 'supporting' hooks. The 'primary' hooks are [Appointment Book] , [Orders Sign] , [Order Dispatch] , and [Order Set Revision] .  CRD Servers SHALL, at minimum, return a [Coverage Information] system action for these hooks, even if the response indicates that further information is needed or that the level of detail provided is insufficient to determine coverage. The 'secondary' hooks are [Orders Select] , [Encounter Start] , and [Encounter Discharge] .  These hooks MAY return cards or system actions, but are not expected to, and CRD clients are free to ignore any cards or actions returned.  (CRD clients SHOULD use the configuration options to instruct CRD servers to not even try to return cards if they do not intend to display/process them.)  If Coverage Information is returned for these hooks, it SHALL NOT include messages indicating a need for [clinical] or [administrative] information, as such information is expected to be made available later in the process and therefore such guidance is not useful. Will update the remaining hooks to say "CRD clients and servers SHALL, at minimum, support returning and processing the [Coverage Information] system action for all invocations of this hook." 5. Will add a note to the Appointment Book, Encounter Start, Order Sign and Order Dispatch hooks "CRD Servers MAY use this hook as a basis for associating a patient with a particular practitioner from a payer attribution perspective." 6. Will add a 'summary diagram' highlighting all of the hooks, showing when responses are required vs. optional (and which types are which), what contributes to caching and attribution.  (Slight modifications from the diagram previously distributed)