Skip to content

Decision Proposal

Jump to bottom Edit New page
Alex Tatiyants edited this page Apr 18, 2018 · 16 revisions

This document describes a set of extensions to CDS Hooks, which enable complex interactions between the provider, the CDS Service, and the EMR. The following items are covered:

  1. User Decision Fulfillment
  2. System Only notifications
  3. Overrides

1. User Decision Fulfillment

In some situations, the CDS Service wants the provider to interact with its app before giving guidance (ex. to ask clarifying questions, present more options, etc). Furthermore, those interactions can result in provider decisions (ex. provider chooses to add an order). Therefore, CDS Service needs a way to communicate provider decisions back to the EMR and have those decisions be executed.

Related to this issue, CDS Service cannot tell the EMR that a valid action to a given suggestion card is launching a CDS app. This is especially true if launching the app is not the only choice (ex. "remove order" OR "provide more information"). This is because apps are currently linked to in the same way any reference links are, via an entry in the Links section.

Proposed solution

Diagram below describes the solution:

User Decision Fulfillment Flow

  1. After EMR notification, CDS Service responds with a link card.
  2. EMR launches the CDS App in a container and provides it a JavaScript object (CdsHooks). This object implements a special method done([actions]) which allows the CDS Service to ask the EMR to execute a set of actions (ex. “Remove order”).
  3. Once CDS App completes the interaction with the user, it calls CdsHooks.done([actions])
  4. EMR does whatever is necessary internally to fulfill those actions.
  5. EMR notifies CDS service via analytics endpoint that actions were executed. If CDS service does not receive a pingback, it will assume that actions were not executed.

In order to support an app launch as an action, a new type of action called launch-app is defined. If a link marked with this type is launched, the EMR will supply the CdsHooks object to the container for that link.

“card”: {
  “summary”: "Need more information to rate advanced imaging order",
  “suggestions”: [
    {
      “label”: "We need more information to rate your imaging order",
      “uuid”: "89shdfh92jrj2r23r",
      “actions”: [
        {
          “type”: "launch-app",
          “resource”: {
            “type”: "smart",
            “url”: "https://...",
            “appContext”: "my special app context"
          }
        }
      ]
    }
  ]
}

2. System-Only actions

Currently, there is no way for a CDS Service to signal to the EMR that a given action should be executed immediately, without having to prompt the provider.

Proposed solution

Allow CDS Service to return actions as a top level response. If actions are returned, the EMR should execute them without notifying the provider. Note that this solution uses the same approach as the one above (array of actions to be executed by the EMR), just in a different context:

System Only Notification Flow

  1. After EMR notification, CDS Service responds with actions array.
  2. EMR executes those actions without notifying the user.
  3. EMR notifies CDS service via analytics endpoint that actions were executed. If CDS service does not receive a pingback, it will assume that actions were not executed.

Potential Uses

For example, a Radiology appropriateness CDS Service may decide that a given imaging order is appropriate. It needs to mark the order as such, but does not need to interrupt the provider. It can return an action to update the order with necessary metadata and have the EMR execute the update automatically:

{
  "actions": [
    {
      "type": "update",
      "description": "Rate proposed imaging order as appropriate",
      "resource": {
        "resourceType": "ProcedureRequest",
        "identifier": [
          {
            "value": "C7ACB00D-C3B6-45E8-B469-CDCDABF905F6"
          }
        ],
        "extension": [
          {
            "url": "procedureRequest-authorizationId",
            "valueCode": "12310112310"
          },
          {
            "url": "procedureRequest-appropriatenessRating",
            "valueCode": "appropriate"
          }
        ]
      }
    }
  ]
}

Actions can also be returned concurrently with suggestion cards. Expanding on the example above, if a CDS Service wants to rate a currently proposed order as inappropriate AND propose two suggestions to the user (“switch order” and “remove order”), it would respond with the action to update the order + suggestion cards.

The EMR would execute the action immediately (thereby marking the currently proposed order as inappropriate) and present the suggestion cards to the user. If the user decides to ignore all cards, currently proposed order would remain marked as inappropriate. Alternatively, if the user decides to follow one of the suggestions, the proposed order would go away.

{
  "actions": [
    {
      "type": "update",
      "description": "Rate proposed imaging order as inappropriate",
      "resource": {
        "resourceType": "ProcedureRequest",
        "identifier": [
          {
            "value": "C7ACB00D-C3B6-45E8-B469-CDCDABF905F6"
          }
        ],
        "extension": [
          {
            "url": "procedureRequest-authorizationId",
            "valueCode": "12310112310"
          },
          {
            "url": "procedureRequest-appropriatenessRating",
            "valueCode": "inappropriate"
          }
        ]
      }
    }
  ],
  "cards": [
    {
      "summary": "CTPA is the primary recommendation for suspected pulmonary embolism, non-pregnant, PERC > 0, and RGS >= 11.",
      "indicator": "warning",
      "detail": "...",
      "source": {
        "label": "CMS Authorized CDSM",
        "url": "https://cdsm.com",
        "icon": "https://cdsm.com/img/icon-100px.png"
      },
      "suggestions": [
        {
          "label": "Switch Order",
          "uuid": "bbfd53d6-f8e2-4f52-b6d8-77cad72d6e99",
          "actions": [
            {
              "type": "create",
              "description": "CTA Chest",
              "resource": {
                "resourceType": "ProcedureRequest",
                "id": "cta-chest",
                "extension": [
                  {
                    "url": "procedureRequest-authorizationId",
                    "valueCode": "12310112310"
                  },
                  {
                    "url": "procedureRequest-appropriatenessRating",
                    "valueCode": "appropriate"
                  }
                ],
              }
            },
            {
              "type": "delete",
              "resource": {
                "resourceType": "ProcedureRequest"
              }
            }
          ]
        },
        {
         "label": "Remove Order",
          "uuid": "bbfd53d6-f8e2-4f52-b6d8-77cad72d6e99",
          "actions": [
            {
              "type": "delete",
              "resource": {
                "resourceType": "ProcedureRequest"
              }
            }
          ] 
        }
      ]
    }
  ]
}

3. Overrides

Currently, CDS Service cannot give the provider an option to override a recommendation, either from a list of options or with a free text comment.

Proposed Solution

Introduce a top level object in the card called override. This object would have an array of reason objects with a label and a uuid (to be used for analytics post-backs). Furthermore, the object would have a freeTextAllowed flag which would signal to the EMR that the user should be given the option of entering a comment as a valid override:

Overrides Flow

  1. After EMR notification, CDS Service responds with a card that contains an `overrject.
  2. EMR presents the card to the user with both actions and overrides. Note that there may be multiple overrides + free text comment.
  3. User selects an override reason.
  4. EMR notifies CDS service via analytics endpoint that an override reason was given by the user or POSTs back free text comment.
"card": {
  "override": {
	"freeTextAllowed": true,
	"reasons": [
  		{"label": "Wrong / disagree", "uuid": "cebfbce4-41d1-11e8-842f-0ed5f89f718b"}
  		{"label": "Not applicable", "uuid": "d797b0b0-41d1-11e8-842f-0ed5f89f718b"}
	]
  },
  suggestions: [...]
}

Use Case: Radiology Appropriateness

CDS Hooks extensions proposed above can be leveraged to implement a comprehensive Radiology Appropriateness solution.

As part of Protecting Access to Medicare Act (PAMA), Center for Medicare and Medicaid Services (CMS) will require all advanced imaging orders to be rated for appropriateness by a certified CDS Mechanism (CDSM) before submitting for payment to Medicare. Guidelines used for this purpose are known as Appropriateness Use Criteria (AUCs) and are provided by a CMS-approved organization called Provider Led Entity (PLE).

A PAMA compliant solution has to support the following requirements:

  • Imaging orders must be rated before the order is signed
  • CDSM recommendations cannot be ignored by the provider
  • CDSM can recommend both removal and switching of orders (from inappropriate to appropriate)
  • Provider must be able to override the recommendation in emergency scenarios or when the clinical scenario for the proposed imaging order is not covered by the AUCs implemented by the CDSM
  • CDSM must annotate order as a result with CDS Session Id, Appropriateness Score, and other details (ex. reason for exam)

PAMA Use Cases

# Description Action(s) Requires user interaction
1 CDSM can rate proposed order based on available data and determines that the order is inappropriate. No alternatives are available.
  • Remove order
  • Update order (rated as inappropriate)
 Yes
2a CDSM can rate proposed order based on available data and determines that the order is inappropriate. CDSM can also recommend a valid alternative.
  • Remove order
  • Switch (add + remove) order
  • Update order (rated as inappropriate)
 Yes
2b CDSM can rate proposed order based on available data and determines that the order is appropriate. CDSM can also recommend a valid alternative.
  • Remove order
  • Switch (add + remove) order
  • Update order (rated as appropriate)
 Yes
3 CDSM cannot rate proposed order based on available data. More information is needed from the provider before rating can be done Launch App Yes
4 CDSM can rate proposed order based on available data and determines that order is appropriate. Update order (rated as appropriate) No

Use Case 1: Order Inappropriate, No Alternatives

  1. Provider signs imaging order
  2. EMR triggers “sign-order” hook and invokes CDSM
    • Request context contains the proposed order
  3. CDSM responds with the following:
    • Actions
      • “update” action containing the resource for the proposed order with the following details:
        • CDS Session Id (via “procedureRequest-authorizationId” extension)
        • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as inappropriate.
    • Suggestions
      • “Remove Order” with the following:
        • “delete” action for the proposed order
      • Overrides for “emergency scenario” and free text response
  4. Provider accepts suggestion or overrides
  5. EMR notifies CDSM via analytics callback

Use Case 2a: Order Inappropriate, Alternative Available

  1. Provider signs imaging order
  2. EMR triggers “sign-order” hook and invokes CDSM
    • Request context contains the proposed order
  3. CDSM responds with the following
    • Actions:
      • “update” action containing the resource for the proposed order with the following details:
        • CDS Session Id (via “procedureRequest-authorizationId” extension)
        • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as inappropriate.
    • Suggestions:
      • “Remove Order” with the following:
        • “delete” action for the proposed order
      • “Switch Order” with the following:
        • “delete” action for the proposed order
        • “create” action containing a resource for a new order with the following details:
          • CDS Session Id (via “procedureRequest-authorizationId” extension)
          • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as appropriate.
          • Other relevant information (ex. “procedureRequest.note“ containing the reason for exam)
      • Overrides for “emergency scenario” and free text response
  4. EMR executes the “update” action
  5. Provider accepts suggestion or overrides
  6. EMR notifies CDSM via analytics callback

Use Case 2b: Order Appropriate, Alternative Available

  1. Provider signs imaging order
  2. EMR triggers “sign-order” hook and invokes CDSM
    • Request context contains the proposed order
  3. CDSM responds with the following
    • Actions:
      • “update” action containing the resource for the proposed order with the following details:
        • CDS Session Id (via “procedureRequest-authorizationId” extension)
        • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as appropriate.
    • Suggestions:
      • “Remove Order” with the following:
        • “delete” action for the proposed order
      • “Switch Order” with the following:
        • “delete” action for the proposed order
        • “create” action containing a resource for a new order with the following details:
          • CDS Session Id (via “procedureRequest-authorizationId” extension)
          • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as appropriate.
          • Other relevant information (ex. “procedureRequest.note“ containing the reason for exam)
      • Overrides for “emergency scenario” and free text response
  4. EMR executes the “update” action
  5. Provider accepts suggestion or overrides
  6. EMR notifies CDSM via analytics callback

Use Case 3: Order Cannot Be Rated, More Info Required From Provider

  1. Provider signs imaging order
  2. EMR triggers “sign-order” hook and invokes CDSM
    • Request context contains the proposed order
  3. CDSM responds with suggestion card containing:
    • “launch-app” action
  4. EMR or provider launches CDSM app
  5. Provider is asked additional questions
  6. CDSM app presents a recommendation to the provider. Depending on the recommendation, provider may select one or more actions.
  7. CDSM app communicates provider decisions to EMR via CdsHooks.done([actions]) callback.
  8. EMR notifies CDSM via analytics callback.

Use Case 4: Order Appropriate

  1. Provider signs imaging order.
  2. EMR triggers “sign-order” hook and invokes CDSM
    • Request context contains the proposed order
  3. CDSM responds with card containing:
    • “update” action containing the resource for the proposed order with the following details:
      • CDS Session Id (via “procedureRequest-authorizationId” extension)
      • Appropriateness Rating (via “procedureRequest-appropriatenessRating” extension). The value will indicate that the order is rated as appropriate.
  4. EMR executes the “update” action.
  5. EMR notifies CDSM via analytics callback.
Add a custom footer

Proposed Hooks

Clone this wiki locally