Epic Security Build: Role-Based Access, Security Templates, and HIPAA Compliance in Configuration
Epic security build is where HIPAA compliance becomes a configuration decision – and where most implementation teams accumulate technical debt that surfaces during audits. Security templates that are copied instead of designed, access rights granted for go-live convenience that never get tightened, and audit log monitoring that is set up but never reviewed are the three patterns that create the most compliance risk. This article covers how Epic’s role-based access control model works, how to design security templates that satisfy both operational needs and HIPAA minimum necessary requirements, and how the access control decisions you make during build become the audit artifacts you defend during an OCR investigation.
- Epic’s Security Model: How Role-Based Access Control Works
- Security Templates: Design Principles and Build Approach
- SubTemplates: Modular Access and Department-Specific Extensions
- HIPAA Minimum Necessary in Epic Security Configuration
- Access Categories: What Each Controls and How to Configure It
- How Access Decisions Become Audit Artifacts
- Break-Glass Access: Emergency Override Configuration
- User Provisioning and Deprovisioning: The Lifecycle Problem
- Common Epic Security Build Failures and How to Prevent Them
- Downloads
Epic’s Security Model: How Role-Based Access Control Works
Epic uses role-based access control (RBAC) implemented through security templates. Every user in Epic is assigned one or more security templates. The template defines what the user can see, what actions they can take, what records they can access, and what they can document. Access is additive – a user’s effective permissions are the union of all templates assigned to them. There is no deny-specific mechanism in the traditional sense: if any assigned template grants access, the user has that access.
This additive model has an important implication for security design. You cannot restrict access by assigning a second template. If a user has Template A that grants access to psychiatric records and you assign Template B that does not mention psychiatric records, the user still has access from Template A. Removing access requires modifying or removing the template that grants it. This is the most common misconception among analysts new to Epic security build – and the source of many unintended access grants that persist through go-live.
Epic’s security framework has four primary components that work together: security templates (the role definition), security classes (the data classification that determines what is protected), user records (which assign templates to individuals), and the audit log (which records what every user does). Understanding how these four interact is the prerequisite for designing a security build that holds up under both clinical operations and HIPAA scrutiny. The full Epic implementation context where security decisions are applied is covered in the Epic EHR Learning Hub.
Security Templates: Design Principles and Build Approach
A security template is an Epic record that defines a collection of access rights. Epic ships hundreds of sample security templates organized by role – RN Template, MD Template, Registration Template, Billing Template, and so on. These samples are starting points. They are not production-ready configurations. Organizations that deploy Epic’s sample templates without review and customization are deploying access rights calibrated for a generic user population, not for their specific workflows, patient population, or HIPAA risk profile.
Template Design Principles
Effective Epic security templates are designed around job function, not job title. A “Nurse” template is too broad. A health system employs ICU nurses, ED nurses, clinic nurses, home health nurses, and agency nurses – each with different workflow requirements and different appropriate access scope. A security template designed around job title produces a compromise that gives everyone too much (to cover the broadest need) or forces constant exception management (to handle the narrowest).
Design templates around the specific clinical or operational workflow the role performs. An ICU RN needs access to critical care flowsheets, ventilator documentation, vasopressor orders, and the ICU patient list. An ED RN needs access to the ED tracking board, triage documentation, and rapid assessment workflows. These are different templates – not the same template with different department filters. The HIPAA minimum necessary standard requires that access be limited to the information needed to perform the specific job function. A single “Nurse” template that grants all nursing workflows to all nurses fails this standard.
The Template Proliferation Problem
The opposite failure mode is template proliferation – creating a unique template for every access exception request. A health system that starts with 30 templates and ends with 300 templates within two years of go-live has a governance problem, not a security problem. Hundreds of templates cannot be audited, maintained, or consistently applied. When a regulatory change requires updating a permission across all nurse templates, a team with 12 nurse templates can make 12 changes. A team with 87 nurse variants has a significant compliance maintenance burden.
The correct design approach uses a base template plus SubTemplates model. Base templates define the core access for a broad role category. SubTemplates add specific capabilities for departments, specialties, or workflow extensions. A user who needs both the base RN workflow and the ICU-specific workflow gets the RN base template plus the ICU SubTemplate. This keeps the total template count manageable while accommodating legitimate workflow variation. The clinical documentation workflows that drive access requirements are described in the EpicCare Inpatient ClinDoc guide.
Eighteen months after Epic go-live at a 400-bed medical center, the security team conducted an audit in preparation for a Joint Commission survey. They found 247 active security templates. The organization had started with 38 templates at go-live. The additional 209 had been created by IT analysts responding to individual access requests from department managers – each request handled as a one-off by creating a copy of an existing template and modifying it. Many of the 247 templates were nearly identical to existing templates with minor variations. Forty-one templates had been assigned to only one or two users. The audit also found that 23 templates had not been reviewed since go-live and contained access rights that violated the organization’s then-current minimum necessary policy. The remediation required a 4-month security rebuild project, a template consolidation to 52 templates, and a mandatory change control process for any new template creation. The Joint Commission surveyor cited the absence of a template governance process as a finding.
SubTemplates: Modular Access and Department-Specific Extensions
SubTemplates in Epic are secondary security records that add specific access rights to a user who already has a base template. They function as access extensions. A base RN template defines what all nurses can do. An ICU SubTemplate adds ICU-specific flowsheet access, vasopressor documentation, and sedation scoring. A float pool SubTemplate adds the ability to see patients across multiple departments without a fixed unit assignment. SubTemplates are added to a user’s record in addition to their base template.
SubTemplates solve the modular access problem without requiring a unique base template for every combination. Instead of 12 nurse template variants (ICU RN, ED RN, Med-Surg RN, Float RN, Oncology RN, NICU RN…), you have one RN base template and six SubTemplates. A NICU nurse gets the base RN template plus the NICU SubTemplate. A float pool ICU nurse gets the base RN template plus both the ICU SubTemplate and the float pool SubTemplate. The combination is managed at the user level, not by creating new templates.
SubTemplates carry the same audit and governance requirements as base templates. A SubTemplate that grants access to psychiatric records, substance use disorder documentation, or HIV status (each of which has heightened HIPAA protection under 42 CFR Part 2 or state law) must be reviewed with the same rigor as any other access grant. The special category nature of the data does not change based on whether the access came from a base template or a SubTemplate.
HIPAA Minimum Necessary in Epic Security Configuration
HIPAA’s minimum necessary standard (45 CFR §164.502(b)) requires that covered entities limit the protected health information they use, disclose, or request to the minimum necessary to accomplish the intended purpose. In Epic security build, this translates to: every access right in every security template must be justifiable by the job function of the role the template serves. Access that cannot be justified by the role’s clinical or operational need should not be in the template.
The minimum necessary analysis for Epic security build is not performed once at go-live. It must be a living process. Job functions evolve. Workflows change. New modules get implemented. What was minimum necessary in year one may be excessive by year three if a workflow was automated or a department reorganized. An annual security template review that evaluates each template against current job function descriptions is the control that satisfies OCR’s expectation of “reasonable policies and procedures” for minimum necessary access.
Sensitive Record Classes and Enhanced Protection
Epic supports enhanced access restrictions for sensitive record types beyond the base HIPAA minimum necessary standard. Sensitive record classes include: psychiatric/behavioral health records (protected under many state laws and HIPAA), substance use disorder treatment records (protected under 42 CFR Part 2), HIV/AIDS records (protected under state law in many jurisdictions), genetic information (protected under GINA), and records flagged by patients for enhanced privacy (VIP and confidential patient records).
Epic’s sensitivity settings allow these record types to be hidden from users who do not have specific access rights for sensitive records. A general nursing template may grant access to the standard nursing flowsheets, but a separate “Behavioral Health Access” flag in the security template is required to view behavioral health documentation. If a user without behavioral health access opens a chart that contains behavioral health records, those records are masked or hidden – the user sees only the non-sensitive portions of the chart. Configuring sensitivity settings correctly requires both the security analyst and the privacy officer to agree on which record types trigger enhanced protection and which user roles have legitimate access to each type.
| Record Type | Regulatory Basis | Epic Protection Mechanism | Roles Typically Granted Access | Audit Requirement |
|---|---|---|---|---|
| Behavioral health / psychiatric | HIPAA + state law | Sensitivity flag; restricted security class | BH staff, treating providers, care coordinators with BH patients | Every access logged; break-glass if out-of-dept |
| Substance use disorder (SUD) | 42 CFR Part 2 | 42 CFR Part 2 module; separate consent required | SUD treatment providers; patient consent required for disclosure | Consent tracked; disclosure log required |
| HIV/AIDS | State law (varies) | Sensitivity flag; diagnosis masking | Treating provider, ID department, lab (results only) | Elevated audit monitoring per state requirement |
| VIP / confidential patient | HIPAA; organizational policy | VIP flag; access restricted to treating team | Directly assigned treating providers and care team only | All access logged; privacy officer notified of any non-treating access |
| Genetic information | GINA; HIPAA | Sensitivity flag; restricted to ordering provider | Ordering provider; genetics counselor; lab | Standard HIPAA audit; genetic data cannot be used for employment decisions |
Access Categories: What Each Controls and How to Configure It
Epic security templates organize access rights into categories. Understanding what each category controls is the prerequisite for designing templates that match job functions without over-granting. The major categories that security analysts configure are: activities (what the user can do), patient list access (which patients appear on the user’s list), report access (which Reporting Workbench reports the user can run), data access (which fields and columns are visible), and application access (which Epic modules and tools the user can open).
Activity Security: The Most Granular Level
Activity security controls what a user can do within an application – place an order, sign a note, verify a medication, void a charge, add a diagnosis. Each clinical action in Epic is associated with one or more security activities. The template specifies which activities the user has permission to perform. A nurse template grants the activity “Sign Nursing Note” but not “Sign Physician Order.” A pharmacist template grants “Verify Medication Order” but not “Place Medication Order.” The granularity of activity security allows very precise control over what each role can do in the clinical workflow.
The challenge with activity security is that Epic has thousands of activities across its modules. A new security analyst reviewing a template for the first time sees a list of hundreds of activity checkboxes with abbreviated names that are not always self-explanatory. Without a written job function analysis that maps each required workflow step to the corresponding Epic activity, the template review process becomes a guessing exercise. The HIPAA minimum necessary analysis must be done at the activity level, not just at the role level.
Patient List Access and Department Scope
Patient list access determines which patients a user can see in their Epic patient lists and, by extension, which patient records they can open. Department scope controls which departments a user’s patient list covers. An ICU nurse should see the ICU patient list but not the ED tracking board or the ambulatory schedule. A hospitalist should see the inpatient list for their assigned service but not the ED patients not yet admitted.
Restricting patient list access does not restrict a user from accessing any chart – it only restricts which patients appear on their default list. A nurse who is scoped to the ICU patient list can still perform a chart search and open any patient’s record if they know the patient’s name or MRN. The access log captures this search-and-open behavior. This is expected in a clinical environment where care coordination sometimes requires access to patients outside a user’s primary department, but it must be monitored. The access log for search-and-open events outside a user’s primary department is the primary data source for identifying potential inappropriate access.
How Access Control Decisions Become Audit Artifacts
Every access control decision made during Epic security build becomes a permanent part of the organization’s HIPAA compliance record. The security template that grants a user access to psychiatric records is documentation of an organizational access control decision. The audit log that records every chart access is the audit trail that proves – or disproves – that those access control decisions were appropriate.
Under HIPAA’s Security Rule (45 CFR §164.312(b)), covered entities must implement audit controls that record and examine activity in information systems that contain or use electronic protected health information. Epic’s audit log satisfies this requirement – but only if the organization actually reviews it. An audit log that is collected and never reviewed does not demonstrate compliance with the Security Rule’s audit control standard. OCR investigators ask for evidence of audit log review during breach investigations and compliance audits. “We collect the logs” is not sufficient. “We review logs weekly for anomalous access patterns and investigate flagged events within 72 hours” demonstrates a functioning audit control program.
What the Epic Audit Log Captures
Epic’s audit log captures: which user accessed which patient record, when, from which workstation, which specific data elements were viewed (in detailed audit mode), which actions were taken (orders placed, notes signed, medications administered), which records were printed or exported, and any break-glass emergency access events. The audit log also captures security configuration changes – when a template was modified, who modified it, and what changed. This configuration audit trail is the evidence that security decisions were made intentionally and documented.
The audit log is stored in Epic’s operational database and extracted to Clarity for reporting. Audit log reporting through Epic’s Reporting Workbench or Clarity SQL allows privacy officers to run queries for specific access patterns – all accesses to a VIP patient’s chart, all accesses to psychiatric records by users outside the behavioral health department, all chart accesses by a specific user in a defined time period. The FHIR API access logging that supplements Epic’s internal audit log is described in the Epic FHIR and Interoperability guide.
A community hospital received an OCR complaint from a patient who believed their records had been accessed inappropriately after a contentious family dispute. The hospital’s privacy officer pulled the Epic audit log for that patient’s chart for the preceding 90 days. The log showed 47 chart access events. Of these, 38 were by treating clinical staff with appropriate access – documented in the chart with clinical notes. Nine accesses were by clinical staff in a different department who had no treating relationship with the patient. Three of those nine were by employees who were family friends of the patient’s ex-spouse. The privacy officer was able to determine the inappropriate access within 48 hours of the complaint, solely from the Epic audit log. The breach investigation, patient notification, and OCR response were all supported by the audit log data. Without the audit log, the investigation would have been inconclusive. The hospital’s legal team noted that the existence of a functioning audit log review program – which had caught two similar incidents in the prior year and resulted in sanctions – was a mitigating factor in the OCR resolution.
Break-Glass Access: Emergency Override Configuration
Break-glass (also called emergency override) is the mechanism that allows a user to access a record they would not normally be permitted to view when a clinical emergency requires it. A nurse covering an adjacent unit during a code may need to access a patient’s chart even though that patient is outside their normal department scope. Break-glass allows the override while creating an audit trail that documents the override reason.
Properly configured break-glass in Epic requires three elements: a visible override prompt that requires the user to provide a reason before accessing the restricted record, immediate notification to the privacy officer or security team that a break-glass event occurred, and an audit log entry that captures the user, the patient, the time, and the stated reason. The override prompt cannot be skipped. The notification cannot be delayed beyond the event. These are not optional – they are the controls that make emergency access permissible under HIPAA rather than a breach.
Break-glass is not a solution to a poorly designed security template. If users are routinely invoking break-glass to access records they need for their normal clinical work, the template does not match the workflow. An ED nurse who triggers break-glass three times per shift to access consultation records is not using emergency override as intended – the template needs to be redesigned to include the appropriate consultation access. Audit log monitoring should flag any user who invokes break-glass more than twice in a week for privacy officer review. The go-live support framework for monitoring access issues in the early post-go-live period is described in the Epic EHR Go-Live Support guide.
User Provisioning and Deprovisioning: The Lifecycle Problem
The security template is only as effective as the provisioning process that assigns it correctly and the deprovisioning process that removes it promptly. Both are pervasive failure points in Epic implementations. Provisioning failures create users with incorrect access from their first day. Deprovisioning failures leave former employees with active Epic accounts for weeks or months after their last day.
Provisioning: Matching Template to Job Function
The provisioning process must include a mapping step that translates the new employee’s job title and department to the correct security template. This mapping should exist as a documented table – not as tacit knowledge held by one IT analyst. Without a documented mapping, each access request is evaluated ad hoc, producing inconsistent template assignments for users with the same job function in different departments.
The provisioning request process must also include a clinical supervisor approval step. The supervisor of the new employee confirms that the requested access level is appropriate for the employee’s specific role. This approval creates a documented accountability chain – the supervisor who approved the access is part of the audit record if that access is later found to be inappropriate. Without supervisor approval, the IT team is making clinical access decisions that are outside their expertise.
Deprovisioning: The 24-Hour Rule
Epic accounts for terminated employees must be disabled within 24 hours of the employee’s last day. This is the deprovisioning standard that OCR expects and that most health system HR policies require – but it is routinely violated because the notification chain from HR to IT to Epic security team involves multiple handoffs. Each handoff is an opportunity for the notification to be delayed or lost.
The most reliable deprovisioning controls are automated: an HR system termination event triggers an automatic account suspension in Epic through an HRIS-to-Epic integration. Organizations without this automation must have a manual process with a defined SLA and an escalation path when the SLA is missed. A weekly audit comparing active Epic accounts to current HR employee records is the minimum manual control. A terminated employee whose Epic account remains active for more than 30 days is a HIPAA Security Rule violation regardless of whether they actually access the system.
| Lifecycle Stage | Required Process | Documentation Artifact | SLA | Audit Evidence |
|---|---|---|---|---|
| New hire provisioning | Map job function to template; supervisor approval; IT creates account | Access request form with supervisor signature | Before first shift | Approved request form; Epic user creation log |
| Role change / transfer | Remove old template; assign new template; supervisor approval for new role | Change request with both old and new supervisor approval | Before start of new role | Change request; Epic template modification log |
| Leave of absence | Suspend account for leave > 30 days; reactivate only after return-to-work confirmation | Leave notification from HR; reactivation request | Suspend within 5 business days of leave start | HR notification; Epic account suspension log |
| Termination | Disable Epic account; remove all template assignments; document reason | HR termination notification; account disable confirmation | Within 24 hours of last day | HR notification timestamp; Epic disable timestamp – gap must be under 24 hours |
| Annual access review | Supervisor reviews and re-certifies each employee’s template assignment | Signed re-certification form per employee | Annually; within 12 months of last review | Signed re-certification forms retained for 6 years per HIPAA |
Common Epic Security Build Failures and How to Prevent Them
| Failure Pattern | How It Happens | HIPAA Risk | Prevention |
|---|---|---|---|
| Deploying Epic sample templates unreviewed | Time pressure at go-live; analyst assumes Epic defaults are correct | High – sample templates grant broad access not calibrated to org’s workflow | Require privacy officer review of every template before production. No template goes live without sign-off. |
| Copying an existing template for a new role | Fastest way to create a new template; analyst adds what’s needed but doesn’t remove what isn’t | High – inherited access from source template may exceed minimum necessary for new role | Start from the minimum access template, not a copy of an existing role. Add access; never subtract from a copy. |
| Granting “go-live” access that never gets revoked | IT grants broad access for go-live troubleshooting; project closes; access stays | High – IT staff with full clinical access post-go-live with no clinical need | Document every temporary go-live access grant with an expiration date. Run a post-go-live access cleanup within 30 days. |
| No audit log monitoring program | Audit log configured and then ignored; no defined review process or owner | High – HIPAA Security Rule violation; log exists but is not reviewed | Assign a named privacy officer as audit log review owner. Document review frequency and escalation path before go-live. |
| Missing deprovisioning process | HR and IT notify each other informally; no defined SLA or escalation | High – former employees retain Epic access; potential for retaliatory or accidental access | Automate via HR-to-Epic integration. If manual, weekly audit of active accounts vs current HR records with 24-hour remediation SLA. |
| Template changes without change control | Analyst modifies a template to fix an access issue without documenting the change | Medium – undocumented access changes cannot be audited or reversed cleanly | Every security template change requires a change request, approval, and documentation of what changed and why. |
The testing framework that validates security configurations before go-live is the same framework that applies to clinical workflow testing. Every security template must be tested with a user account that has only that template assigned, confirming that the user can perform all required clinical actions and cannot perform restricted actions. The BAT methodology for this type of access validation testing is described in the BAT vs UAT guide.
Get privacy officer sign-off on every security template before it goes to production – not as a rubber stamp, but as a documented minimum necessary review that confirms each template’s access rights match the job function description on file with HR. This review creates three things simultaneously: a governance artifact that demonstrates compliance intent, a check on analyst assumptions about what access each role needs, and an accountability record that names the person who approved the access. Organizations that do this before go-live have a documented defense when OCR asks how access control decisions were made. Organizations that skip it are defending ad hoc decisions made under schedule pressure.
Authoritative References
- HHS OCR – HIPAA Security Rule Guidance: Audit Controls, Access Controls, and Workforce Security Standards
- HHS OCR – HIPAA Minimum Necessary Standard: Guidance for Access Control Configuration and PHI Disclosure Limitations