The most prevalent question posted to any Epic Security Team is: “Who has access to what in Hyperspace?” Whether it be asked by the organization’s leadership or an external entity, it behooves the Security Team to be prepared for this question at all times. The Security Team should be the last line of defense as it relates to granting access in Epic. Although the Security Team shouldn’t be the primary decision-maker regarding access, the team should enforce decisions made by others. In order to determine who has access to what and then configure and assign that access, the following steps must be taken.
Meet with All Epic Hyperspace Stakeholders
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.
Evaluate Security and Access for Compatibility with Policies and Procedures
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 their “giving 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.
Incorporate Organization Policies and Regulatory Mandates
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.
Create a Methodology for Restricting Access within Hyperspace
The Security Team must determine a methodology to restrict access appropriately. There are many methodologies one can employ. That said, when deciding on a methodology, the most important consideration is ensuring the end result can be quantified. 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.
Consider Restricting Access in Hyperspace
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 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 chosen, restricting access to Hyperspace should 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.
Create a Methodology for Access
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. Sensitive activities are 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. However, being able to modify Professional or Hospital Billing information is. It’s 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.
Collaborate between the Security Team and Reporting Workbench
The Security Team must work closely with the Reporting Workbench to understand–beyond workflow and end-user functionality required–who must access reports/data. As part of the Security Team’s “audit toolbox” Reporting Workbench, 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 asked who has access to modify billing information the Security Team can view every individual that has access.
Final Thoughts on Security and Access in Epic’s Hyperspace
Ultimately, operational and clinical leadership should decide on the access required for each role within the organization. Thus, it’s the Security Team’s responsibility to make that information for end users by granting and restricting access. Speak with an Expert
