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

General Security Considerations

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
• In situations where signatures are necessary, systems SHOULD make use of the signature extension as used in the SDC behavior profile.

Transaction Integrity

In some cases, the recipient of a completed QuestionnaireResponse may require that the response be accompanied by additional information about the creation of the QuestionnaireResponse such as:

• What tooling was used to render the form?
• If someone transcribed the information from paper or another representation, and if so who?
• If certain answers were populated from existing data, what those other data sources?
• Whether completion of the form was overseen by anyone, and if so who?
• etc.

In FHIR, such information is represented using a Provenance or, more rarely an AuditEvent. (Audit is typically managed by the server and client locally or by a shared service that does not store the clinical information.) However, because this information is intrinsically tied to the QuestionnaireResponse instance, it needs to be conveyed alongside that instance as a single unit of work. 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, communicating both records together is accomplished in one of two ways:

• The Provenance associated with a resource may be transmitted along with the resource in a POST or a PUT using the X-Provenance as described in the core specification here.
• The QuestionnaireResponse and its associated Provenance (or more rarely AuditEvent) may both be sent in a single RESTful Transaction Bundle, where there is either an entry POSTing both records, or one entry PUTting an update of the QuestionnaireResponse and a second POSTing the Provenance/AuditEvent corresponding to the metadata for that update. In either case, the Provenance or AuditEvent will point to the version-specific identifier of the QuestionnaireResponse, using either Provenance.entity.reference or AuditEvent.object.reference

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, the use of data for completing questionnaires for purposes unrelated to the initial gathering data 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.

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.

Population

When populating a form from existing data, there is no expectation for consent to pass data to the form or for the form to query information where the user filling out the form would normally have access to such data. (The population mechanism merely saves the effort of looking it up manually and copying it across.) However, population does raise two important privacy/security considerations:

• Form Fillers SHALL always give users a chance to review all answers prior to submission and allow the user to know where the data is being submitted
• Systems need to be very cautious about submitting forms that contain 'hidden' questions that can be auto-populated because they can allow disclosure of information without human review. These can be innoccuous (e.g. what version of the software was the data loaded from) but could also be used in an attack to extract data surreptitiously. Manual review by a technical expert (prior to approval of use of the Questionnaire) of Questionnaire versions that contain hidden auto-populated questions may be needed. Similarly, a manual review of submission destinations might also be appropriate if they are not already 'trusted' destinations.

Compartments

QuestionnaireResponses associated with an individual will generally have a subject that will establish the 'compartment' the data belongs to and control who has access to that QuestionnaireResponse and what consents or business rules, if any, apply when evaluating requests for access to that record. For example, if QuestionnaireResponse.subject is set to a specific patient, then that record will be 'protected' by all of the rules that apply to accessing that particular patient's data. However, QuestionnaireResponse.subject is optional, and there are some situations where a QuestionnaireResponse will contain information that is patient or provider-identifiable and even sensitive, but will not yet have a QuestionnaireResponse.subject. For example, some workflows might involve filling out a Questionnaire where the Form Filler isn't aware of the subject record to link to. Alternatively, a QuestionnaireResponse might be used to capture initial registration information before the appropriate Patient or Practitioner instance has even been created.

Because of this, systems must be extremely careful around allowing access to QuestionnaireResponses with no specified subject. Some might be completely fine to share and access widely, while others might contain extremely sensitive information. It might be necessary to make use of security tags or other mechanisms to assert and manage the sensitivity of such records.