Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-36627

Order Sign should be be the preferred hook trigger (not Order Select)

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CRD (FHIR)
    • 1.1.0-ballot [deprecated]
    • Financial Mgmt
    • STU
    • Supported Hooks
    • 4.2.2.4 and 4.2.2.5
    • Hide

      Proposal is to replace this language:
      "This is probably the most important of the hooks for CRD and will be the most widely used as it is fired while orders are being created and decisions are being made about what medications, devices, services, etc. are going to be provided. This hook may be fired multiple times as additional information is gathered. Services SHALL NOT return warnings indicating that insufficient information is available to determine coverage when returning coverage requirement cards. It is to be expected that not all information will be available initially. If the user decides that the order is ‘complete’ when not enough information is available, that will be caught by the order-sign hook.

      While it might be possible to not support this hook and only use the order-sign hook, this hook has the benefit that it allows altering the provider’s behavior before they’ve gone too far. It’s much less aggravation for the provider if they’re prompted to change an ordered drug when they’ve just picked the drug and haven’t filled in all the dosage instructions than when everything is complete and they’re just about to sign."

      with

      "Support for this hook is optional, as not all information will necessarily be available when this hook is invoked.  Therefore, the [Order Sign] and [Order Dispatch] hooks are more critical to implement because they fire when information is required to be more complete and also represent the 'end' of the user engagement in their respective processes.  That said, the "Order Select" hook is still quite useful.

      First, because it fires earlier in the user's system interactions, it provides an opportunity for CRD services to initiate back-end queries that might take time to complete so that relevant information is already retrieved and cached before Order Sign is reached.  This increases performance and makes it easier for CRD services to respond in the required timeframe.

      Second, where a CRD service is able to provide guidance to providers earlier in the process (e.g. upon selection of a service but before entering detailed instructions), it can help to make the provider experience more efficient.  (If a provider knows up-front that a service won't be paid for but an alternative would be, they may be happier if they can save the time on entering full details before finding this out.)  Not all providers or EHRs will necessarily want to receive 'proactive' decision support during the order entry process.  EHRs can be configured as to what types of cards they're interested in receiving back for this hook, including no cards at all if the hook is being invoked solely for performance/caching reasons."

      Show
      Proposal is to replace this language: "This is probably the most important of the hooks for CRD and will be the most widely used as it is fired while orders are being created and decisions are being made about what medications, devices, services, etc. are going to be provided. This hook may be fired multiple times as additional information is gathered. Services  SHALL NOT  return warnings indicating that insufficient information is available to determine coverage when returning coverage requirement cards. It is to be expected that not all information will be available initially. If the user decides that the order is ‘complete’ when not enough information is available, that will be caught by the  order-sign  hook. While it might be possible to not support this hook and only use the order-sign hook, this hook has the benefit that it allows altering the provider’s behavior before they’ve gone too far. It’s much less aggravation for the provider if they’re prompted to change an ordered drug when they’ve just picked the drug and haven’t filled in all the dosage instructions than when everything is complete and they’re just about to sign." with "Support for this hook is optional, as not all information will necessarily be available when this hook is invoked.  Therefore, the  [Order Sign]  and  [Order Dispatch]  hooks are more critical to implement because they fire when information is required to be more complete and also represent the 'end' of the user engagement in their respective processes.  That said, the "Order Select" hook is still quite useful. First, because it fires earlier in the user's system interactions, it provides an opportunity for CRD services to initiate back-end queries that might take time to complete so that relevant information is already retrieved and cached before Order Sign is reached.  This increases performance and makes it easier for CRD services to respond in the required timeframe. Second, where a CRD service is able to provide guidance to providers earlier in the process (e.g. upon selection of a service but before entering detailed instructions), it can help to make the provider experience more efficient.  (If a provider knows up-front that a service won't be paid for but an alternative would be, they may be happier if they can save the time on entering full details before finding this out.)  Not all providers or EHRs will necessarily want to receive 'proactive' decision support during the order entry process.  EHRs can be configured as to what types of cards they're interested in receiving back for this hook, including no cards at all if the hook is being invoked solely for performance/caching reasons."
    • Bob Dieterle / Mark Scrimshire : 4-0-1
    • Correction
    • Non-substantive
    • Yes

    Description

      The sections on Order Sign and Order Select need to be reframed. Based on previous discussions with the Burden Reduction WG, Order Sign is the more commonly used hook (see notes https://confluence.hl7.org/pages/viewpage.action?pageId=90901642) so the way this section is written is misleading. Further, from a provider perspective, we are concerned with potential noise with information being inserted into workflow through Order Select; moreover, Order Select doesn't notify you if something is missing, because user might not have finished entering all the information yet; lastly, Order Select raises the concern that payers may attempt to direct care when the provider is ultimately the best patient representative for clinical decision making.

      As the guide so states itself – CRD shouldn't be warning about missing info with order-select because the order is complete, and info in the order (directions, frequency, quantity, etc) may determine PA requirements. This is why it makes more sense for Order Sign to be the preferred "firing" stage. What is the rationale of firing at Order-Select if the app can't provide correct coverage info since the info is incomplete?

      Suggesting multiple revisions in this section, including, making Order Sign a Must Support and Order Select a MAY Support.

      Note: Below is current content and suggestions for reframing in bolded/starred.

      order-select
      This hook is described in the CDS Hook specification here. This version of the CRD implementation guide refers to version 1.0 of the hook.
      This will probably be the most important and widely used hook for CRD based on WG discussions and notes, this is not an accurate statement, revise as it will be fired as orders are created for medications, devices, services, etc. within the CRD Client. The hook could fire multiple times as additional information is gathered and entered. Services SHALL NOT return warnings indicating that insufficient information is available to determine coverage when returning coverage requirement cards. It is to be expected that not all information will be available initially. If the user decides that an order is 'complete' when not enough information is available, that will be caught by the order-sign hook.
      While it might be possible to not support this hook and only use the order-sign hook, recommend stating, implementer MAY support this hook but MUST support Order Sign hook the benefit of supporting order-select is that information may be provided to alter a provider's behavior before they've gone very far in the authoring process. It will be less aggravating for the provider to be prompted to change a medical equipment order when they've just picked the device and haven't filled in all the usage instructions than when everything is complete and they're just about to sign. this last sentence is not accurate and appropriate for a spec and should be deleted
      This hook allows multiple resource types to be present. Resources provided could all be the same type or be a mixture of types. Coverage requirements SHOULD be limited only to those resources that are included in the selections context, though the content of other resources SHOULD also be considered before making recommendations about what additional actions are necessary. (I.e. don't recommend an action if there's already a draft order to perform that action.)
      order-sign
      This hook is described in the CDS Hook specification here. This version of the CRD implementation guide refers to version 1.0 of the hook.
      This hook serves a very similar purpose to order-select. The main difference is that all the listed draft orders are considered 'complete'. this needs to be fleshed out with more specifics on the difference, also seems misleading to say 'considered complete' There should be a mention that the order was submitted which is s big deal *That means that it's appropriate to provide warnings if there is insufficient information to determine coverage requirements. As well, all draftOrders are appropriate to comment on when using order-sign as the selections field in order-select is absent. *unclear on what this last sentence means, suggest revising

      Attachments

        Activity

          People

            Unassigned Unassigned
            celine_lefebvre Celine Lefebvre
            Celine Lefebvre
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: