Da Vinci - Documentation Templates and Rules
2.1.0-preview - STU 2 United States of America flag

Da Vinci - Documentation Templates and Rules, published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 2.1.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-dtr/ and changes regularly. See the Directory of published versions

Privacy, Security, and Safety

Page standards status: Trial-use

Guidance and conformance expectations around privacy and security are provided by all three specifications this IG relies on. Implementers SHALL be familiar with and adhere primarily to any security and privacy rules defined by Da Vinci HRex Privacy and Security. Implementers SHALL also adhere to the security guidelines defined in:

DTR-specific considerations

Any DTR SMART on FHIR application will have access to the scope of data authorized by the organization as appropriate for use by the app, accessible to the user, and potentially as authorized by the user. This scope granted MAY provide the SMART on FHIR application access to more data than is needed for the specific situation. For example, if Observation.read capabilities are needed, the app will have access to all observations for that patient. For compliance with HIPAA Minimum Necessary, the CQL included in payer-defined Questionnaires SHALL limit requests for information from the EHR’s API to only items that are relevant to the documentation requirements for which DTR was launched (e.g., documentation requirements for a service that requires prior authorization).

Compliant Questionnaires SHALL NOT include hidden or read-only questions where the data is populated from the EHR. If information is privacy restricted, the information SHOULD be treated by the EHR FHIR API as if it does not exist when executing queries in payer-defined CQL. Providers SHOULD ask the patient if they want to share the information with the payer prior to manually populating it in any QuestionnaireResponses.

Any EHR with SMART on FHIR support SHOULD be prepared to deal with the implications of providing a client with the scopes they request. For example, EHRs SHALL limit FHIR search capabilities for clients, requiring a patient ID in any search query to ensure the client can only access resources related to that patient.It is important for implementers to be aware that data is going to be auto-populated that could be considered sensitive - so there will likely be a need for a human to review and confirm that the information is appropriate to be shared (and be able to remove it without risk of it being put back if they wish). Also, the app MAY not have access to certain data for retrieval because of security considerations.

Payer systems SHALL use information received during execution of DTR $questionnaire-package solely for the purpose of satisfying the operation invoked, for audit, and to satisfy metric reporting needs.

If a payer uses adaptive forms to gather information, the payer SHALL NOT persist or use the information shared as part of the $next-question operation for any purpose other than:

  • Responding to the operation
  • Retention of the fully completed QuestionnaireResponse to support a coverage determination made as part of the Questionnaire completion process
  • Internal audit and metric calculation