Da Vinci - Documentation Templates and Rules
2.2.0 - STU 2.2

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.2.0 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 | Highlight text changes?

Guidance and conformance expectations around privacy and security are provided by all three specifications this implementation guide relies on. Implementers SHALL adhere to any security and privacy rules defined by:§sec-1

- FHIR Core: Security & Privacy Module, Security Principles and Implementer's Checklist
- HRex: Privacy & Security
- SMART on FHIR: SMART App Launch

### 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.§sec-2 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 does require prior authorization).§sec-3

Compliant Questionnaires SHALL NOT include hidden or read-only questions where the data is populated from the EHR.§sec-4 DTR Clients SHALL appropriately manage access to data that is sensitive per policy and regulatory requirements when responding to queries from a DTR app.§sec-5 Providers SHOULD ask the patient if they want to share the information with the payer prior to manually populating it in any QuestionnaireResponses.§sec-6

Any EHR with SMART on FHIR support SHOULD be prepared to deal with the implications of providing a client with the scopes they request.§sec-7 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.§sec-8 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 might not have access to certain data for retrieval because of security considerations.

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

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:§sec-10

- 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.

NOTE: | When Questionnaires provide external links through XHTML or `supportLink`, there may need to be up-front negotiation to add such links so they are considered 'safe'.