End-user device encryption

Clarifications:

• To meet the criterion, only one paragraph (d)(7)(i) or (ii) needs to be met. Both do not need to be demonstrated.
• Use of technology is considered to be stopped when a user closes or exits the technology application and a user would need to re-execute the technology application to again engage in use. Testing and certification will focus on normal terminations. [see also 77 FR 54237]
• Locally stored electronic health information is intended to mean the storage actions that technology is programmed to take (e.g., creation of temp files, cookies, or other types of cache approaches) and not an individual or isolated user action to save or export a file to their personal electronic storage media. [see also 77 FR 54238]
• This criterion focuses on, and only applies with respect to, the storage capabilities that are designed for use with developer provided or supported technologies for desktop, laptop, or mobile technologies. [see also 77 FR 54238]
• The functionality included in this certification criterion does not focus on server-side or data center hosted technology. Rather, this criterion focuses on data locally stored on end-user devices after the use of the technology is stopped. [see also 77 FR 54238]
• Information that has been sent to a print queue or downloaded by the user (e.g., download a PDF report) is no longer considered managed by the technology. [see also 77 FR 54238]
• This certification criterion does not supersede or affect the HIPAA Security Rule’s requirements or associated flexibilities. HHS has issued guidance around encryption as a possible risk management strategy to address storage of electronic protected health information. HHS has also issued guidance on how to render unsecured protected health information unusable, unreadable, or indecipherable to unauthorized individuals. We recommend developers refer to this guidance in developing their products. [see also 77 FR 54239]

Technical outcome – Technology designed to locally store electronic health information on end-user devices must encrypt such information after use of technology on those devices stops in accordance with any encryption algorithm in Annex A of FIPS 140-2.

Clarifications:

• ONC encourages developers to use encryption algorithms, such as Advanced Encryption Standard (AES), that are included in Annex A of FIPS 140-2. [see also 77 FR 54239]

Technical outcome – The technology must be set by default to perform the capability in provision (d)(7)(i)(A) and the ability to change the configuration must be restricted to a limited set of identified users unless the configuration cannot be disabled by any user.

Clarifications:

• If the developer designs technology that requires or utilizes locally stored electronic health information, it is the developer’s responsibility to ensure that such information is set to be encrypted by default in order to meet this criterion. This could be accomplished through different technical mechanisms including techniques to “sandbox” and limit the extent to which data can be accessed and used to only be within a secure session. [see also 77 FR 54238]

Technical outcome – The technology prevents electronic health information from being locally stored on end-user devices after the technology on those devices stops.

Clarifications:

• The language for this portion of criterion acknowledges that despite a health IT developer's best effort to design health IT in such a way that electronic health information never remains, ONC understands that such absolutes cannot always be guaranteed (especially when a health IT developer is unable to modify the functionality a particular web browser or operating system employs). [see also 77 FR 54238]
• A health IT developer would not have to demonstrate that its technology can encrypt electronic health information locally stored on end-user devices if the EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of health IT on those devices stops. [see also 77 FR 54238]
• ONC interprets “prevent” to include, for example, situations where health IT is designed to and would normally disallow electronic health information to be locally stored on end-user devices after use of health IT on those devices stops, but is run in a browser that does not respect “no-cache” headers. In this circumstance, and if shown under normal circumstances (e.g., running in a browser that does respect “no-cache” headers), the EHR technology could meet paragraph (d)(7)(ii) of this certification criterion. [see also 77 FR 54238]
• Health IT developer attestation or documentation could be used to meet the requirements of this criterion.