This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

B.2 General Security Considerations

Some of the SDC transactions make use of patient-specific information. Even those that merely retrieve empty forms could be abused by malicious actors to corrupt the form - resulting in the potential subsequent exposure of patient data. For this reason, all SDC transactions must be appropriately secured with access limited to authorized individuals, data protected while in transit and appropriate audit measures taken.

Implementers should be aware of the security considerations associated with FHIR transactions, particularly those related to:

• Communications
• Authentication
• Authorization/Access Control
• Audit Logging
• Digital Signatures
• Security Labels

For the purposes of SDC, security conformance rules are as follows:

• Systems SHALL use TLS version 1.1 or higher for all transmissions containing patient-identifiable information and not taking place over a secure network connection. Such transmissions SHOULD use bi-directional certificate validation
  
• Systems SHOULD use TLS version 1.1 or higher when retrieving Questionnaires intended to capture patient-identifiable information to reduce the risk of form tampering.
(Using TLS even within a secured network environment is still encouraged to provide defense in depth.)
• Systems SHALL use OAuth or an equivalent mechanism to provide necessary authentication (user or system-level)
• Systems SHALL use either IHE's ATNA standard for audit logging or an equivalent using the AuditEvent resource
• Where workflow requires digital signatures on forms or on answer submissions, implementers SHALL make use of the Provenance resource to record such signatures.

B.2 Transaction Integrity

In some cases, the recipient of a completed QuestionnaireResponse may require that the response be accompanied by a Provenance or, more rarely an AuditEvent as part of a single unit of work. (Audit is typically managed by the server and client locally or by a shared service that does not store the clinical information.) This can be accomplished by mechanisms outside the scope of this implementation guide by using FHIR messages or FHIR documents. However, within the scope of this implementation guide, this is accomplished in pseudo-RESTful fashion using the Transaction mechanism. Regardless of means, the Provenance and/or AuditEvent event point to the QuestionnaireResponse by full version-specific URL using the Provenance.entity.reference and AuditEvent.object.reference elements.

B.2.1 Consent

The SDC workflow envisions the sharing of patient-identifiable healthcare information from SDC Form Filler systems to SDC Form Manager. It also envisions transmitting completed forms from SDC Form Filler to SDC Form Receiver systems. Where such exchanges take place across organizational or other custodial boundaries, patient consent may be required. Furthermore, use of C-CDA data for completing questionnaires for purposes unrelated to the initial population of the C-CDA may also require patient consent. It is the responsibility of the client systems to ensure that any necessary consent records exist and are reviewed prior to each exchange of patient-identifiable healthcare information. This verification should be logged in the same manner as other transactions, as discussed above under General Security Considerations.