See proposed changes to text below The data accessed by this implementation guide includes: (Use CONFORMANCE Verbs) Measures are generally publicly available information that is http://hl7.org/fhir/R4/security.html#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 percieved 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 http://hl7.org/fhir/R4/security.html#Patient Sensitive. Value Sets which are generally publicly available information that is http://hl7.org/fhir/R4/security.html#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 publicating 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 the 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. Add to Security and Privacy Risks Add text for PHI Risk 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. (cite: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Handbook_De-Identification_Rev1.1_2014-06-06.pdf#page=9 ) Direct identification of a patient to an attacker with access to commonly available data sources. (ibid) The data accessed by this implementation guide includes: (Use CONFORMANCE Verbs) Measures are generally publicly available information that is http://hl7.org/fhir/R4/security.html#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 percieved 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 http://hl7.org/fhir/R4/security.html#Patient Sensitive. Value Sets which are generally publicly available information that is http://hl7.org/fhir/R4/security.html#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 publicating 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 the 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. Add to Security and Privacy Risks Add text for PHI Risk 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. (cite: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Handbook_De-Identification_Rev1.1_2014-06-06.pdf#page=9 ) Direct identification of a patient to an attacker with access to commonly available data sources. (ibid)