This page is part of the FHIR Specification (v1.2.0: STU 3 Draft). 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:

• Secure Channel

  When transmitting PHI (Personally Identifiable Healthcare Information) or other confidential information over an unsecured channel, systems SHALL use TLS or other equivalent secure transport protocols (determined to be sufficient through risk analysis) to provide a secure channel

  • TLS implementations SHALL be at least as tight as NIST 800-52 Guideline, Configuration and Use of TLS (Requires a minimum of TLS 1.1 and move to TLS 1.2 starting in 2015)
  • TLS implementations SHALL use IHE ATNA guidelines for Node Authentication
• When communicating without PHI or over a secured channel, systems SHOULD use TLS as above to provide defense in-depth and ensure transaction integrity.
• Systems SHALL use either IHE's ATNA standard for audit logging or an equivalent using the AuditEvent resource
• When evaluating security of alternative channels, transport protocols, user authentication, etc., a risk analysis SHOULD be performed and documented using NIST 800-30 guidelines of their equivalent
• 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.

B.2.2 Security Workflow

When communicating RESTfully, AuditEvent and Provenance resources are typically submitted separately from the resource versions they're manipulating. This is for a couple of reasons:

• In a pure REST environment, resources are manipulated individually
• The server that stores the created/updated resource may not be the one that stores the audit or the provenance (making the use of transaction impossible

In environments where the submission of audit and/or provenance information must be performed as part of a single unit of work, this should be done using transaction. Provenance information can be retrieved along with a QuestionnaireResponse using the _revinclude query parameter.