Objective
Conduct or review a security risk analysis and implement security measures as necessary and bridge identified security gaps as part of its risk management process.
Description
This section will describe and direct the system administrator to the features within Patient Records that will assist an eligible provider in meeting this objective.
Performance metric
None. This is a Yes/No attestation.
Each provider must attest that he/she conducted a security risk analysis, correctly identified security gaps as part of the risk management process, and successfully implemented measures to bridge these gaps as necessary to minimize the risks and keep all manner of data as safe as reasonably possible. McKesson recommends that all eligible providers (EPs) conduct a thorough security risk analysis at least once every quarter.
Exclusions
None.
Notes
There are a lot of features in the application that aid in keeping sensitive information secure. In addition to the features available in the EHR itself, EPs must have other general measures in place that may include, but are not limited to the following.
• Standard network security protocols on servers, databases, and workstations.
• Use proper firewalls and anti-viral/anti-malware software, which are updated frequently.
• Signed HIPAA agreements on file for all employees.
• Enforce strict policies and procedures for keeping all Personal Health Information (PHI) and Personal Identifiable Information (PII) secure.
• Use secure VPN connections when accessing EHR from off-site locations and mobile devices.
• Require personnel to change system passwords regularly.
• Ensure that staff members do not share login credentials with others.
• Frequent ongoing education of staff regarding the dangers to the practice/organization due to security breaches and the process they are expected to follow before and after an incident.
Notes Chapter 9 - Core Objective 9 - Security & Risk Analysis
• Conduct regular security checks (walk-through) at all locations and for all personnel to identify gaps.
• All personnel should have unique login IDs and passwords to access their workstations/
laptops/mobile devices.
• When using terminal services, Citrix systems, or RDP to access the EHR application,
operators are trained to use the Ctrl+Alt+Del feature to lock their workstations when they are away.
• McKesson recommends that system administrators enable the Auto-Log Off features on workstations after a certain period of inactivity.
NOTE: These are suggestions only and are not meant to be a complete list of all items to be covered. Use your best judgment to determine all of the requirements for your practice(s) and provider(s).
Chapter 9 - Core Objective 9 - Security & Risk Analysis Security measures recommendations in the EHR application
Security measures recommendations in the EHR application
Access control/authentication in Practice Partner
• Ensure that all users have unique operator IDs and passwords.
• Ensure that all users have been assigned appropriate role-based access levels.
• Ensure that all providers and non-provider operators with signature privileges only for prescriptions have been assigned unique PINs.
The configuration and setup required for these measures have not changed since previous versions of the product. For more information, see the Operator and Operator Maintenance, Access Levels, and Providers topics in the online help.
Figure 42. Operator Maintenance Edit screen
Chart access control and emergency access Chapter 9 - Core Objective 9 - Security & Risk Analysis
Chart access control and emergency access
1. Access to individual patient’s chart can be controlled using the Limit access to only these users and Block these users from access options on the Chart Access tab on the Patient screen.
Figure 43. Patient Edit screen
2. Emergency access to such restricted charts may be granted if warranted using the Break the Glass-Chart Access and Break the Glass-Complete access levels.
Chapter 9 - Core Objective 9 - Security & Risk Analysis Auto-park and log-off features
information. This should be used solely for the purposes of providing appropriate patient care (for example, in situations when the people with access to the chart are unavailable).
Chart tabs that normally are restricted from viewing based on access levels still will be restricted.
- Complete Chart Access: The access level for Break the Glass-Chart allows a user to access a patient’s chart temporarily, if he/she normally is restricted to view all chart information. This should be used solely for the purposes of providing appropriate patient care (for example, in situations when the people with access to the chart are unavailable).
Chart tabs that normally are restricted from viewing based on access levels will display in View Only mode.
With these features enabled, users will be prompted to enter a Reason for Access field and then click the Proceed button to access a restricted patient’s chart. Once a reason is provided, an operator can view this patient’s information with the same access level restrictions for the individual. This can be tracked via an Operator Audit trail.
Figure 45. Break-the-Glass Security screen
Once the operator has completed his/her task in the restricted chart and closed it, the operator is restored to his/her original access levels. The restricted chart once again will be restricted.
The operator will not have privileges to view any other restricted charts. Each time the operator wants to access a restricted chart, he/she must “break the glass” and provide a reason for access.
Auto-park and log-off features
McKesson recommends that all operators be trained to use the Park feature in the application to lock their workstations when they step away.
The system also can be set up to automatically “park” or “lock” the workstations after a certain period of inactivity. This setup is done on the Access 1 tab on the Electronic Security screen for PRUtils.
Operator Audit Trail report Chapter 9 - Core Objective 9 - Security & Risk Analysis
The setup and configuration for the Auto-Park feature in PRUtils has not changed since previous versions of the product. For more information, see the PRUtils topic in the online help.
Figure 46. Electronic Security screen
Operator Audit Trail report
This report lists all operator-recorded events in the EHR. This includes the adding, editing, deleting, and viewing of records.
This report also tracks and records the signing of patient notes and labs. Prescription printing, faxing, and transmitting also is recorded.
The audit trails can be enabled for as many items as desired on the Audit Trail tab of the
Electronic Security screen for PRUtils. McKesson recommends that the audit trails be enabled for all of the items listed on the screen.
Chapter 9 - Core Objective 9 - Security & Risk Analysis Operator Audit Trail report
The steps to enable the audit trail feature in PRUtils has not changed since previous versions of the product. For more information, see the PRUtils topic in the online help.
Figure 47. Electronic Security screen
Run an Operator Audit Trail report regularly. McKesson recommends that random audits be conducted by clinic managers and system administrators frequently to ensure that all standard policies and procedures are being followed consistently.
Operator Audit Trail report Chapter 9 - Core Objective 9 - Security & Risk Analysis
The steps to run the different audit trails in the EHR have not changed since previous versions fo the product. For more information, see the Operator Audit Trail Report topic in the online help.
Figure 48. Reports menu
Chapter 9 - Core Objective 9 - Security & Risk Analysis System security events
NOTE: To comply with CMS regulations, PHI (for example, patient name, date of birth, SSN) have been removed from the audit reports. The patient ID is displayed along with the date and time of occurrence of each event listed, as well as the operator ID of the user who performed the actions.
For more information, see the Operator Audit Trail Report topic in the online help.
System security events
System alerts may be enabled so that a specified operator (for example, a system administrator) is notified when a significant auditable event occurs. This allows the system administrator to be alerted immediately to an event that might indicate a security issue for your organization, and for the system administrator to be able to respond promptly.
The setup for this is done by entering the operator ID of the designated person on the Automatic Notification tab on the Electronic Security screen for PRUtils.
The steps to enable the audit trail feature in PRUtils has not changed since previous versions fo the product. For more information, see the PRUtils topic in the online help.
If a security event occurs, the operator assigned to receive the alert receives a “System security event notification” in his/her operator message inbox in the EHR. The message includes the following information:
• event type • date/time
• operator’s name and ID • workstation ID
• user’s Windows log on • patient name and ID • reason given for access
Notes Chapter 9 - Core Objective 9 - Security & Risk Analysis
• operator’s name and ID.
Figure 50. Electronic Security screen
Notes
McKesson recommends that EPs save copies of their Security & Risk Analysis reports as supporting documentation for this objective and to be produced in cases of an audit by CMS.
For reference, see the tipsheet at the following location:
http://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/
SecurityRiskAssessment_FactSheet_Updated20131122.pdf