DSTU2 STU 3 Candidate
This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is

This page is part of the FHIR Specification (v1.4.0: STU 3 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 . For a full list of available versions, see the Directory of published versions

B.2 General Security Considerations 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:

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 Authorization/Access Control
  • Audit Logging Audit Logging
  • Digital Signatures Digital Signatures
  • Security Labels 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

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

B.2 Transaction Integrity Transaction Integrity In some cases, the recipient of a completed

In some cases, the recipient of a completed QuestionnaireResponse may require that the response be accompanied by a may require that the response be accompanied by a Provenance or, more rarely an 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 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 or FHIR documents . However, within the scope of this implementation guide, this is accomplished in pseudo-RESTful fashion using the . 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 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 and AuditEvent.object.reference elements. elements.

B.2.1 Consent 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.

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 Security Workflow When communicating RESTfully,

When communicating RESTfully, AuditEvent and 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 resources are typically submitted separately from the resource versions they're manipulating. This is for a couple of reasons:

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. © HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:44+1100. Links: Search . Provenance information can be retrieved along with a QuestionnaireResponse using the _revinclude query parameter.