Security Policies

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 – Security policy setup in Designer

• Setup Security Policies – Implementation guide

• Security Policy Detail – Detailed policy configuration

• Roles – User roles in Care

• Add New Users – Creating users and assigning roles

• Provide Access to Users – Managing user permissions