1. Prior to Go-Live, application analysts meet with the stakeholders and sponsors in each area that requires Epic access to understand workflows and system configuration needed to function effectively. The application analysts and teams concentrate on providing the access necessary to support the validated workflows. This is where the role of the Security Team is so important. While the application teams are busy granting access, the Security Team should be busy restricting access.
2. The model system must be scrutinized for security and access by the Security Team. Records that are delivered with the foundation system, or model system, grant more access than required by most organizations. The reason why most model records can be used without modification is due to the fact they usually “give away the store.” The security classes, roles, menus, activities, profiles, and other security-related records are developed by Epic as a “one-size fits most.” Depending on the policies and procedures of the organization, what is granted in model records may not be permitted or desired for your organization.
3. The policies and procedures of the organization – along with HIPAA, HITECH, and other regulatory mandates involving security and privacy – must be considered by the Security Team. Outside of being intimately familiar with HIPAA, HITECH and other regulatory mandates, the first thing the Security Team should concentrate on is understanding the policies and procedures of the organization. Armed with this knowledge, the Security Team can then review the validated workflows with a keen awareness of what the organization allows and what they do not. The Security Team can then address any “breaches” of policy or procedure early in the build stage. As the build matures and User Templates are being created, a methodology of build and review should be agreed upon by the application and security teams. The methodology should center around restricting access, not granting access.
4. The Security Team must determine a methodology to employ in order to restrict access appropriately. There are many methodologies one can employ but when deciding on a methodology to restrict access, the most important consideration is making sure the end result can be easily quantified and reportable. When audits occur, the Security Team should have a comprehensive way to report on who has access to what. This is not as easily achievable as one may think. As you may be aware, controlling access to activities in Hyperspace can be achieved either through removing the activity or menu record from the role associated with a user, or to remove the security point that grants the access in the first place. The key is that it is relatively easy to report on who has a certain security point assigned but not so easy to report on what records are used in a role or profile.
There are additional considerations when defining a methodology to restrict and report on access within Hyperspace. Some sensitive activities are not controlled by any security point. There are others that rely on a security point that controls more than just that one activity. If the security point is removed, it may remove not only the sensitive activity but other activities that may be required by the user. Restricting activities of this nature must be done through the modification of other records such as menus, roles, or profiles.
Whatever methodology is agreed upon, restricting access to activities in Hyperspace should always begin with removing the security point within the relevant security class. The methodology should be geared towards audit and reporting and not just restricting access. The Security Team should develop an “Audit Toolbox” full of reports, utilities and defined processes that address specific audit controls. Stay tuned for more access restriction and audit reporting best practices.
5. The Security Team must then determine a methodology to employ in order to grant access appropriately. There are certain security points that grant access to “sensitive” activities. I define sensitive activities as those that are regularly audited by external auditors and/or should only be granted to those that absolutely must have them to perform their job. Having view only access to billing information may not be a sensitive activity but being able to modify Professional or Hospital Billing information is. It is beneficial for the Security Team to use the Epic Security Point Dictionary on the UserWeb to identify all sensitive security points that grant access to sensitive activities in all applications.
6. The Security Team must work closely with the Reporting Workbench to understand – beyond workflow and end-user functionality required – who must access reports/data (especially via the Reporting Workbench). As part of the Security Team’s “audit toolbox” Reporting Workbench (RWB) reports should be developed to identify all security classes with sensitive security points. Columns of the report should include all Linked User Templates that the security class is assigned to. Another RWB report can show all users linked to those templates. Thus, when the question is asked who has access to modify billing information the Security Team can drill down to every individual that has access.Ultimately, operational and clinical leadership should decide on the access required for each role within the organization. It is then the Security Team’s responsibility to take that information and make it functional for end users by granting and, more importantly, restricting access.