Da Vinci - Coverage Requirements Discovery
2.2.1 - STU 2.2 United States of America flag

This page is part of the Da Vinci Coverage Requirements Discovery (CRD) FHIR IG (v2.2.1: STU 2.2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Privacy, Safety, and Security

Page standards status: Trial-use

Guidance and conformance expectations around privacy and security are provided by all three specifications this implementation guide relies on.

§sec-1

Implementers SHALL adhere to any security and privacy rules defined by:

In addition to these, this implementation guide imposes the following additional rules:

  • As per the CDS Hooks specification, communications between CRD clients and CRD servers SHALL use TLS.§sec-2 Mutual TLS is not required by this specification but is permitted. CRD servers and CRD clients SHOULD enforce a minimum version and other TLS configuration requirements based on HRex rules for PHI exchange.§sec-3
    • This specification does not provide guidance on certificate management between systems, though it has been proposed that Direct certificates could be used for this purpose.
  • CRD clients that support the Launch SMART Application Response Type SHALL support running applications that adhere to the SMART on FHIR confidential app profile.§sec-4
  • CRD servers SHALL use information received solely for coverage determination and decision support purposes.§sec-5 Servers SHALL NOT retain data received over the CRD interfaces for any purpose other than audit or providing context for form completion using DTR.§sec-6
  • CRD clients are the final arbiters of what data can or cannot be shared with CRD servers. It is up to clients to ensure they support their obligations as health data custodians, including legal, policy, and patient consent-based restrictions. Withholding information might limit the completeness or accuracy of coverage requirements discovery advice retrieved using the interfaces within this guide. The inability of a CRD server to provide full advice does not relieve providers of their responsibility to ensure that payer coverage requirements are met.
  • CRD clients SHALL ensure that the resource identifiers exposed over the CRD interface are distinct from and have no determinable relationship with any business identifiers associated with those records.§sec-7 For example, the Patient.id element cannot be the same as or contain in some fashion a patient's social security number or medical record number.
  • Access to patient information to meet decision support requirements is subject to regulations such as HIPAA "minimum necessary" and CRD client organizations SHOULD audit access to check for reasonableness and appropriateness.§sec-8
§sec-9 * Access tokens provided as part of CRD calls **SHOULD NOT** be forwarded to systems that are not managed by the same organization or have business associate agreements that allow centralized audit of access. Possible alternatives to token-sharing include: * Routing all requests for information through the initial endpoint system * Making use of RFC 8693 to allow the creation of 'delegate' tokens for downstream systems"

There is not a lot of experience around delegated access with CDS Hooks and the timing requirements make it even more challenging. Implementers should expect additional negotiations to happen around how this will function. Future versions of this specification might provide additional guidance or constraints.