# Security Policies: Attribute Based Access Control

## Overview

Security policies in Welkin provide Attribute-Based Access Control (ABAC), enabling organizations to granularly control what data each user role can Create, Read, Update, and Delete (CRUD). Policies can be applied to all customizable objects, individual fields within Custom Data Types, and system objects like Patient Profiles, Forms, Calendar, Communication Center, Documents, Encounters, Data Exports, Insights, Programs, and Dictionaries.

Security policies ensure that sensitive health data is protected while allowing appropriate access for clinical and administrative workflows.

## Key Concepts

* **Security Policy** – A collection of access rules defining what users can do with specific data
* **Role** – A user category (Nurse, Care Manager, Patient, Supervisor, etc.) that determines access
* **CRUD Permissions** – Create, Read, Update, Delete access controls
* **Custom Data Type (CDT)** – User-defined data fields whose access is controlled
* **Field-Level Security** – Restricting access to individual fields within a CDT
* **Object-Level Security** – Restricting access to entire systems (forms, programs, documents)

## How Security Policies Control Access

### CRUD Operations Explained

Each role can be granted or denied permissions for four operations:

#### Create (C)

* **Permission:** User can create new records/entries for this data type
* **Examples:**
  * Create new medication record
  * Add new vital signs measurement
  * Initiate new assessment instance
* **Use case:** Only providers and nurses can create, not patients or clerical staff

#### Read (R)

* **Permission:** User can view/access this data
* **Examples:**
  * View patient's medications
  * See assessment responses
  * Access clinical notes
* **Use case:** Broadly granted to care team, restricted for patients (only their own data)

#### Update (U)

* **Permission:** User can modify existing data
* **Examples:**
  * Edit medication dosage
  * Update assessment responses (in some cases)
  * Correct vital signs
* **Use case:** Only original recorder or supervisor can update

#### Delete (D)

* **Permission:** User can remove data from system
* **Examples:**
  * Delete erroneous assessment response
  * Remove duplicate medication record
* **Use case:** Usually restricted to admins or supervisors

### Access Denied

If no permission is granted, user cannot:

* See the field/object in the UI
* Access the data via API
* Perform the denied operation even if it's visible

## Types of Objects Protected by Security Policies

### Custom Data Types (CDTs)

Individual fields within your custom data can be protected:

* **Medication CDT** – Who can see/edit medication name, dosage, frequency, prescriber?
* **Mental Health Assessment** – Who can see responses to sensitive questions?
* **Social History** – Who can view/edit substance use, housing, legal status?

### System Data Types (Built-in)

* **Patient Demographics** – Name, DOB, MRN, contact information
* **Insurance Information** – Insurance provider, member ID, coverage details
* **Care Coordination Data** – Program enrollment, care plan

### Forms & Assessments

* **Create** – Who can create assessment instances (start new assessments)
* **Read** – Who can view completed assessments
* **Update** – Who can modify responses (in some designs)
* **Delete** – Who can remove assessments

### Patient Profile Access

* **Patient Demographics** – Full name, DOB, address, phone
* **Medical History** – Past conditions, surgeries, allergies
* **Contact Information** – Who can update patient phone/email

### Documents

* **Create** – Who can upload documents
* **Read** – Who can view documents by type
* **Delete** – Who can remove documents

### Calendar & Appointments

* **Create** – Who can schedule appointments
* **Read** – Who can view calendar
* **Update** – Who can reschedule/modify
* **Delete** – Who can cancel appointments

### Communication Center

* **Read** – Who can view messages
* **Create** – Who can send messages
* **Update** – Who can edit unsent messages
* **Delete** – Who can remove messages

### Programs & Encounters

* **Read** – Who can view program/encounter details
* **Create** – Who can create program/encounter instances
* **Update** – Who can modify program/encounter
* **Delete** – Who can end programs

### Insights & Reports

* **Read** – Who can access data analytics and reports
* **Create** – Who can create custom reports

### Dictionaries

* **Read** – Who can view reference data
* **Update** – Who can modify dictionary entries

## Creating Security Policies

### In Designer (Policy Definition)

1. Log into Designer
2. Create a new Draft
3. Navigate to **Access Control** > **Security Policies**
4. Click **+ New** to create a new policy
5. Define:
   * **Policy Name** – Descriptive name (e.g., "Behavioral Health Providers")
   * **Description** – What this policy controls
6. For each CDT or object, specify roles and CRUD permissions:
   * Behavioral Health Assessment → Read: All roles, Create: Nurse/Provider only
   * Medication List → Read: All care team, Update: Provider only, Delete: Supervisor only
7. Save and publish the policy

### In Admin (Role Assignment)

1. Log into the Admin portal
2. Navigate to **Users** or **Roles**
3. Create or edit a role (e.g., "Clinical Nurse")
4. Assign the Security Policy to the role
5. Users with this role inherit all permissions defined in the policy

## Policy Configuration Examples

### Example 1: Clinical Provider Policy

```
Role: Provider
Can Create: All assessments, medications, care plans
Can Read: All patient data, all assessments, all medications
Can Update: All CDTs, all assessments, all care plans
Can Delete: Only their own draft notes
```

**Result:** Providers have broad access to create and manage clinical data.

### Example 2: Care Manager Policy

```
Role: Care Manager
Can Create: Tasks, care plan notes, program enrollment
Can Read: All patient demographics, assessments (read-only), programs
Can Update: Care plan, program progress notes
Can Delete: Their own draft tasks and notes
Cannot: Create medications, delete assessments, access sensitive behavioral health data
```

**Result:** Care managers can coordinate care but cannot modify clinical data.

### Example 3: Patient Portal Access

```
Role: Patient
Can Create: Patient-reported assessments (PROs)
Can Read: Only their own data, appointment summaries, after-visit summaries
Can Update: Their own demographics, contact information
Can Delete: Nothing
Cannot: View clinical notes, see test results, access other patient data
```

**Result:** Patients see only relevant information about their own care.

### Example 4: Sensitive Data Restriction

```
Behavioral Health Assessment CDT:
- Read: Behavioral Health Provider, Psychiatrist, Supervisor only
- Create: Behavioral Health Provider, Psychiatrist only
- Update: Original recorder or Supervisor only
- Delete: Supervisor only

Other roles: No access (field hidden from view)
```

**Result:** Sensitive psychiatric data protected; only specialists and supervisors see it.

### Example 5: Field-Level Security

```
CDT: Patient Demographics
- Name field: All roles can read
- DOB field: All roles can read
- SSN field: Only Admin and Supervisor can read
- Insurance Member ID: Admin, Billing, Provider can read; Billing can update
- Religious Preference: Patient and assigned care team can read
```

**Result:** Granular protection of sensitive PII and PHI by field.

## Implementation Workflow

### Step 1: Identify Your Roles

List all user types in your organization:

* Physicians
* Nurses
* Care Managers
* Social Workers
* Patients
* Administrative Staff
* Supervisors
* Administrators

### Step 2: Define Access Levels

For each role, determine what data they need:

* What must they read to do their job?
* What must they create/modify?
* What should be restricted?

### Step 3: Create Security Policies in Designer

1. Design comprehensive policies covering your role requirements
2. Map each CDT and system object to role permissions
3. Test policies in draft mode
4. Publish when complete

### Step 4: Assign Policies to Roles in Admin

1. Log into Admin portal
2. Go to role management
3. Select or create each role
4. Assign the corresponding security policy
5. Save configuration

### Step 5: Test Access

1. Create test user accounts for each role
2. Log in as each role
3. Verify:
   * Expected data is visible
   * Restricted data is hidden
   * CRUD operations work as expected
   * Forbidden operations are blocked

### Step 6: Train Team

1. Communicate security policy to care team
2. Explain why certain data is restricted
3. Provide guidance on handling restricted information
4. Establish secure handoff procedures for accessing protected data

## Best Practices

1. **Principle of Least Privilege** – Users get minimum access needed for their role
2. **Role-Based Design** – Create policies by role, not by individual user
3. **Regular Audits** – Review security policies quarterly
4. **Clear Documentation** – Document why each restriction exists
5. **Consistent Standards** – Apply same rules across similar data types
6. **Restrict Sensitive Data** – PHI, SUD information, mental health data require strong protection
7. **Logging** – Enable audit logs to track data access
8. **Test Thoroughly** – Test all role combinations before deployment
9. **Change Management** – Document policy changes and rationale
10. **User Communication** – Explain restrictions so team understands boundaries

## Compliance Considerations

Security policies help meet regulatory requirements:

* **HIPAA** – Restricts PHI access to authorized users
* **42 CFR Part 2** – Protects substance use disorder information
* **State Laws** – May restrict mental health record access
* **Consent-Based Access** – Can restrict data if patient hasn't consented
* **Audit Trail** – Policies enable tracking of who accessed what data

## Related Topics

* [Configuring Security Policies](https://welkin-health-1.gitbook.io/welkin-health-docs/designer/configuring-security-policies) – Security policy setup in Designer
* [Setup Security Policies](https://welkin-health-1.gitbook.io/welkin-health-docs/designer/setup-security-policies) – Implementation guide
* [Security Policy Detail](https://welkin-health-1.gitbook.io/welkin-health-docs/designer/security-policy-detail) – Detailed policy configuration
* [Roles](https://welkin-health-1.gitbook.io/welkin-health-docs/care/roles) – User roles in Care
* [Add New Users](/admin/users/add-new-users.md) – Creating users and assigning roles
* [Provide Access to Users](/admin/users/provide-access-to-users.md) – Managing user permissions


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.welkinhealth.com/admin/security/security-policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.