Skip to content

Decision Proposal

Jump to bottom Edit New page
Josh Mandel edited this page Oct 24, 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 with SMART Web Messaging enabled. The app can call SMART.messaging.send() using a message type of fhir.update, fhir.create, or fhir.delete to modify the orders in progress (either with individual calls per-action, or with a transaction bundle to ensure that multiple actions are performed as a block).
  3. Once CDS App completes the interaction with the user, it calls SMART.messaging.send() again with a message type of ui.done to return control to the EHR.
  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 launch the app in a container with SMART Web Messaging enabled.

“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 override object.
  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 the proposed order 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 the 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 the 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 the proposed order based on available data and determines that the order is appropriate. CDSM can also recommend a valid alternative.
  • Switch (add + remove) order
  • Update order (rated as appropriate)
 Yes
3 CDSM cannot rate the proposed order based on available data. More information is needed from the provider before the order can be rated. Launch App Yes
4 CDSM can rate proposed order based on available data and determines that order is appropriate. No alternatives exist. 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:
      • “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 SMART.messaging.send(), using a message type of fhir.update, fhir.create, or fhir.delete.
  8. EMR notifies CDSM via analytics callback.

Use Case 4: Order Appropriate, 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 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