Situational Awareness for Novel Epidemic Response
1.0.0 - STU Release

This page is part of the Situational Awareness for Novel Epidemic Response (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Security Considerations

The data accessed by this implementation guide includes:

  • Measures are generally publicly available information that is Anonymous Read sensitive. There may be cases where use or testing of a given measure may be Business Sensitive.

  • Measure Reports that are generally not sensitive to individual patients or workers. The reported metrics may be perceived as sensitive to the organization publishing them. For this reason the project assesses the Security and Privacy Considerations as Business Sensitive under normal situations, however it may require higher levels of sensitivity where limited data sets exist. For example, when reporting data from a small facility in an area with a very limited population.

  • Evaluated and Supplemental Data which includes patient identifiable information (when the supplemental data option is used). This data is Patient Sensitive.

  • Value Sets which are generally publicly available information that is Anonymous Read sensitive. There may be cases where use or testing of a given value set may be Business Sensitive.

In some cases the use of this data may require user authentication for purposes unrelated to the sensitivity of the data.

Given this assessment, the main Security Considerations are focused on:

  • Assuring the data published is authentic to the organization publishing the data. That is that a consumer of the API can be given assurances that they are connecting to the authentic service endpoint they intended to connect to. This functionally is provided by common use of TLS with server sided authentication, commonly used in HTTPS.

  • Taking care to validate that the server certificate validated and authenticated by TLS/HTTPS is the server intended to connect to. This is important management of client side certificate trust store.

  • Assuring the data communicated is not modified in transit. The consumer of the API can be given assurances that they are retrieving exactly the data that is published. This functionality is provided by common use of TLS with integrity cyphers such as SHA256.

  • Encrypting the data. When evaluated or supplemental data is not used, the Confidentiality of the communicated data is not critical, but having it encrypted may prevent unidentified risks. Given that common use of TLS includes common use of encryption cyphers such as AES256, encryption is strongly recommended for consistency sake.

  • The service may choose to request a security token be obtained to provide identity of the client. When a client token is provided the server will have more rich information to make an access control decision or record in an audit log.

  • The client and server should record an Audit Log event such as FHIR AuditEvent. See Audit Records in the Profiles and Extensions section of this guide for profiles created in this guide for the HL7 FHIR AuditEvent resource.

Purpose Of Use restrictions

Given that the use-case for this implementation guide is to support Public Health reporting, the use of client context PurposeOfUse of PUBHLTH is recommended. The communication of PurposeOfUse is not defined in SMART-on-FHIR, so other methods might need to be used. IHE IUA profile provides a OAuth attribute to carry this.

The use of data returned by this API should be limited to the Public Health use-case. Re-purposing the data for other uses, such as re-identification, should be considered a violation of the API intention.

The setting of the PurposeOfUse to PUBHLTH may be addressed through policy agreements and thus not communicated in the API communications.

Local Access Control

The maintenance of the data on the client or server is not specified in this implementation guide. Security considerations must be applied in systems design to assure that the data is appropriately protected from inappropriate use and modification. For example only authorized services and individuals should be allowed to update the metrics that would be served by the API defined here.

Security and Privacy Risks

This section includes an enumeration of some of the risks identified for the use-cases covered and justifying the security and privacy mitigations indicated above.

  • Risk to re-identification when the Location (region reporting on) is small enough to identify too few individuals (e.g. k-anonymity); for example, where a region is so small that the community can re-identify a death because it is the only death in that region with the other indirect identifiers (gender, etc.)
  • Risk to reputation of a healthcare facility that is serving a community with increased negative incidents
  • Risk to community reputation – if a community is harder hit, it may be perceived negatively on that community. People in that community may be targeted by scams and bullied (cyberbullying).

In addition to the mitigations above, careful definition of regions that would be reported upon should assure that the region is large enough so as to lower the risk of re-identification. Where reporting regions are too small, aggregation into larger regions may be necessary.

Where evaluated or supplemental data is used, the following risks must also be recognized:

  • Direct identification of a patient within a facility, or indirect identification outside the facility.
  • Direct identification of a patient to an attacker with access to commonly available data sources.

Combined reports within one dataset increase the risk of re-identification through the correlation of indirect identifiers within the dataset. Independent reports can mitigate this reverse correlation used for re-identification.

References