The UHG Profiling team has significant concerns that only CDS Hooks can be used. 

Proposed change: 

CRD server SHALL support an alternative way to perform coverage requirements discovery by CRD Clients and CRD Servers that allow use of standard FHIR Operations. CRD Servers MAY choose to support both synchronous or asynchronous operations. Use of CDS hooks as currently defined in the Da Vinci CRD specification may also be used.

We are open to idea of allowing an operation defintiion as an option for the next version of the Da Vinci CRD ID.

Summary of why this change is proposed: 

  Why should CRD IG support a FHIR Operation as an alternate approach?

• Can meet the same needs with an operation definition or CDS hooks. 
• FHIR Operations are widely supported.
• FHIR Operations can be resued by CRD Servers to support CDS hook implementations
• Reduced cost, scope, and complexity as compared to CDS hooks approach

  Why shouldn’t CRD IG require CDS Hooks?

• Requires industry adoption of technology not backed by ONC regulation.
• CMS unlikely to require use of IG that specifies technical requirements that are not required by ONC. 
• CDS cards are not well suited to support native EHR workflows interactions.
• CDS hook requirements are complex and not well understood by implementer community.

Specific issues with CDS hooks required as only mechanism to comply with Da Vinci CRD are:

-ONC has not adopted CDS Hooks in regulation which means that certified EMR’s do not have to implement and may not implement in a consistent manner.  It is also unlikely that CMS will require an IG before CDS Hooks are incorporated into EMR certification by the ONC

- we believe that many of the needs CRD supports such as finding out if Prior Authorization is needed will continue to be a back office function and adding it to Point of Care will only increase the provider burden.  Because of this, we would also like to see CRD add an option that uses a FHIR Operation instead of a CDS Hook. 

- CRD server created cards and utalized within CRD client smart apps allow for payers to introduce workflow variability into provider workflows. Providers and back-office staff prefer native workflow support within the EHRs that are agnostic of the payer systems being interacted with.

- For regulatory work related to our prior authorization business, CRD is a mandatory first step, specially with the wider Project Promise related guideline soon to be enforced. And as part of that, there are multiple checks that need to be made which we believe cannot be realistically achieved with CDS Hooks as the only choice.

- There has yet to be compelling rational shared demonstrating that CDS hooks provides functionality that cannot also be supported through a FHIR operation. Thus making it unclear why use of CDS hooks SHALL be the only allowed mechanism to be compliant with Da Vinci CRD.

- User research done by operations finds that information supplied to an EHR user is not used to support care delivery decisions is instead used to help help drive workflow. CDS hooks seems better suited toward supporting care delivery decision making rather than driving workflows.