Privacy and Security Tiger Team Meeting

Privacy and Security Tiger Team Meeting Discussion Materials for Today’s Topics: Stage 2 Patient Identification & Authentication User (provider) Authentication Privacy and Security for Stage 2 Meaningful Use April 1, 2011

Patient Accessidentity proofing and authentication

Patient Identification Principles • The Tiger Team supports entities making these determinations based on their own assessments of what is necessary to address the risks of inappropriate access. However, we recommend such assessments be guided by the following principles: • Providers must manage the risk of inappropriate access; however, they should not set the identification requirements in a way that discourages or inhibits patients from participating. • Providers should offer the option of “registering” for access during an office or facility visit – but they should also offer options in addition in person-identification. Permitting only in-person identification may make participation difficult for individuals who live in rural areas, or who lack reliable transportation or who face health, financial or other barriers to coming into the office or facility.

Patient Identification Principles (cont.) • One technique for remote identification is requiring the individual to provide information that is known to both parties. Providers using such a method should be careful to choose information beyond basic demographic information (such as address, date of birth, social security number) that might be known or knowable by an unauthorized person. • Providers should require more stringent proof of identity for access to patient identifiable data in the EHR. Information required to access other electronic services (such as signing up for an appointment or indicating interest in a portal or PHR that is merely designed to trigger follow-up) may not need stringent identity.

Patient Identification Principles (cont.) • Providers should also consider the populations they serve in setting identification requirements (for example, providers should consider primary languages spoken, likelihood of possessing photo or government-issued identification, etc.). • Providers should consider consulting their patients (such as if they have a patient advisory group) to get feedback on what will work best for them while also providing appropriate security (VA has done this with MyHealtheVet). • ONC [HHS?] should [work with NIST to?] provide guidance to providers on trusted identification methods. Such guidance should be updated to reflect federal government e-identification efforts (such as the National Strategy for Trusted Identity in Cyberspace).

Patient Authorization • Providers should require at least a user name and password to authenticate patients. • This single-factor authentication should be a minimum – providers may want to at least be able to offer their patients additional security (such as through additional authentication factors) or provide such additional security for particularly sensitive data. • In setting authentication requirements, providers should also be mindful of guidelines for identification and not set requirements so high that patients are discouraged from participating or cannot meaningfully participate (for example, by requiring complicated passwords).

Patient Authorization (cont.) • Certified EHRs should include a capability to detect and block programmatic attacks or attacks from a known but unauthorized person (such as auto log-off after a certain number of unsuccessful log-in attempts). Having this capability in the EHRs provides providers with options for deploying technology-supported password management programs • [same recommendation as for identity] ONC [HHS?] should [work with NIST to?] provide guidance to providers on trusted authentication methods. Such guidance should be updated to reflect federal government e-identification efforts (such as the National Strategy for Trusted Identity in Cyberspace).

User (provider) Authentication • Organizations that are seeking to exchange information as part of the NwHIN should be required to adopt baseline user authentication policies that require more than just user name and password for remote access. At least two factors should be required. Remote access is defined as access over a public network like the Internet. • The Team was not comfortable with requiring the application of the NIST or DEA requirements for all authentication because of the stringency of the second factor requirement. • The Tiger Team was particularly concerned about remote access (vs. access within the physical structure of an entity), but we had a difficult time initially setting parameters for what constitutes “remote” access. Does the definition above get it right? Do we need to specifically exempt access using a VPN? • Should the Standards Committee be asked to determine which are appropriate factors for two-factor authentication?

User Authentication (cont.) • These recommendations are intended to set a baseline for user authentication; organizations and entities can adopt more stringent requirements. • For more sensitive, higher risk transactions, an additional authentication of greater strength subsequent to an initial authentication may be required, as has already been recognized with the DEA policy covering prescribing controlled substances. Additional work may be needed by the Policy Committee and ONC to identify the potential use cases that might require authentication above the baseline requirement.

User Authentication (cont.) • NwHIN Policies should be re-assessed for consistency with other national identity efforts, technology developments, such as National Strategy for Trusted Identity in Cyberspace. • ONC should also work to develop and disseminate evidence about the effectiveness of various methods for authentication and reassess NwHIN policies accordingly. • For writing e-prescriptions for controlled substances, Certified EHRs should have capability for the two-factor authentication, at a minimum consistent with DEA rule.

Privacy & Security For Stage 2 Meaningful use

Policies to Facilitate Secure Exchange of ePHI • Eligible Providers and Eligible Hospitals should be required to obtain digital certificates per Tiger Team’s previous recommendations -The EHR certification process should include testing on the use of digital certificates for appropriate transactions. • Eligible Providers are required to comply with the DEA rule regarding e-prescribing of controlled substances. -For e-prescribing of controlled substances, stage two certification testing criteria for EHRs should include testing of compliance with the DEA authentication rule, which requires two-factor authentication.

Policies to Promote Accurate Patient Matching • Eligible Providers [and hospitals?] are require as part of Stage 1 of Meaningful Use to enter patient demographic data, and Stage 1 certified EHRs must enable a user to electronically record, modify, and retrieve patient demographic data. The following Tiger Team Recommendations relevant to accurate patient matching (and adopted by the Policy Committee) should apply to certification of EHRs for Stage 2: • HIT Standards Committee should identify standard formats for data fields that are commonly used for matching patients (for example, name, DOB, zip, address, and gender). • HIT Standards Committee should specify standards that describe how missing demographic should be represented during exchange.

Patient Matching (cont.) • The Tiger Team heard testimony that USPS normalization of addresses would be beneficial to the patient matching process, but the Tiger Team did not want to make a recommendation at that detailed a level. As a result, the HIT Standards Committee is requested to consider whether USPS address validation and normalization would be beneficial to improved matching accuracy and whether it should be added to the demographic standards. • Stage two certification criteria should include testing that (i) appropriate transactions are sent/received with the correct demographic data formats and (ii) data entry sequences exist to reject incorrectly entered values.

Policies to Promote EHR Security • In Stage 1 of Meaningful Use, Eligible Providers and Eligible Hospitals are required to conduct or review a security risk analysis in accordance with the HIPAA Security Rule and implement security updates as necessary and correct identified security deficiencies as part of the risk management process. • The Tiger Team recommends that this measure also be included in Stage 2 of Meaningful Use.

Policies to Promote EHR Security • To be determined: Should the Tiger Team add a recommending regarding implementation of EHR security functionalities (Stage 1) • Four options: • Require that providers “address” how they will implement these functionalities as part of meanignful use for Stage 2. • Rely on interpretation of HIPAA Security Rule regarding “addressable provisions” for users of certified EHRs • Require implementation of encryption at rest • Require implementation of a full complement of security functionalities (per Standards Privacy & Security workgroup recommendation)

Option 1 • Recommend that eligible providers and hospitals, as part of their security risk assessment for stage 2 of meaningful use, specifically address how they will implement the security functionalities in the certified EHRs. Providers can attest that they have done this as part of their risk assessment and may be required to produce documentation if audited (vs. having to affirmatively submit documentation

Option 2 • Rely on the Office of Civil Rights to interpret how the HIPAA Security Rule applies to users of certified EHRs. • Adam Green at HIMSS: an entity (either an eligible professional or hospital) that manages a certified EHR system that has built-in technical safeguards for the confidentiality, availability or integrity of EPHI will be expected under the HIPAA Security Rule to have those system safeguards (e.g., encryption) in operation.

Option 3 • Specifically require, as part of stage 2 of meaningful use, that eligible providers and hospitals specifically implement the requirement to encrypt data at rest.Providers and hospitals would be required to attest to this as part of Stage 2 of meaningful use

Option 4 – require implementation of security measures Policy Measure: Conduct or update a security risk assessment and implement security updates as necessary (1 of 3) Demonstration Measures: Conduct or update security and privacy risk assessment, and implement policy, procedures, and system configuration necessary to use the certified EHR meaningfully, including: Termination of system access of terminated workforce members Establishment and periodic review of accesses to assure that access is granted to those with permission, and that access is not granted to those who do not have permission Protection against, detection, and reporting of malicious software Monitoring of audit trail of system activities Password-management (if passwords are used for user authentication) 20

Option 4 (cont.) Policy Measure: Conduct or update a security risk assessment and implement security updates as necessary (2 of 3) Demonstration Measures: (risk management – continued) Screen-locking and session termination after pre-established periods of inactivity Secure hash function to protect the integrity of all PHI transmissions Encryption of all PHI transmissions, internal or external to the organization, where the possibility of their going over unsecured wireless or cellular networks cannot be ruled out Encryption of all PHI transmissions that leave the facility and travel in part over shared networks Encryption of all PHI stored on portable devices and removable media 21

Option 4 (cont.) Policy Measure: Conduct or update a security risk assessment and implement security updates as necessary (3 of 3) Demonstration Measures: Update and implement Contingency Plan (data backup plan, disaster recovery plan, emergency-mode operations plan, testing and revision procedures, applications and data criticality analysis) that incorporates use of the EHR product Identify and document data and capabilities that are minimally required in order to assure continuity of critical data services, and establish service-level-agreements (SLAs) consistent with these priorities 22

Additional EHR Security Functionalities • Malicious software detection • Screen locking and session termination after a period of inactivity • Audit trail processing • Password management support (for example, see patient authentication recommendations) • Secure hash function to protect transmissions within an entity? (current integrity standard protects only exchanges of information) • Others?

Policies for Patient Portals • Eligible Providers and Hospitals should deploy audit trails for access to a patient’s portal, and at least be able to provide these to patients upon request. Audit trail capability for the portal will need to be part of Stage 2 certification requirements. • Patient portals should include provisions for data provenance. • Portals should include mechanisms that prevent automated services from requiring individuals to provide user name and password in order to provide access

Patient Portals – Other policies (IE Workgroup?) • Patients must be able to download the information in human readable form. • Portal must include a printer-friendly format. • Portal must enable the data to be exported into commonly used software formats, such as spreadsheets, pdfs, or text files. Expectation is that migration to more standard formats can occur as they become available and more broadly implemented. • Providers and entities offering portals should provide basic education to patients about use of portal, risks and responsibilities (for Tiger Team to take up later – not as time-sensitive because not tied to technical functionality)

Privacy and Security Tiger Team Meeting