Extra Horizon
GitHub
  • Extra Horizon Documentation
  • Getting Started
    • Start familiarizing yourself
  • Tutorials
    • Medical Device Tutorial
      • Preparation
      • Build your first prototype
        • Define a data model
        • Configure your workflows
          • Workflow 1: Analyze a measurement
          • Workflow 2: Create & store a PDF report
          • Workflow 3: Send an e-mail
        • Define your permissions
          • Update your schema with user permissions
          • Update your schema with group permissions
        • Build the Front-End
          • Set up oAuth in your backend
          • Demo login page
      • Summary & Wrap up
    • Polysomnography (PSG) Tutorial
    • Retool - Building dashboards Tutorial
  • FAQ
    • General
  • Services
    • Identity and Access Management
      • User service
        • Users
        • Groups
        • Global roles
        • Configuration
      • Auth Service
        • Applications
        • OAuth2
        • OAuth1
        • MFA
        • OpenID Connect
          • Google Cloud
          • Azure ADFS
    • Data Management
      • File Service
      • Data Service
        • Schemas
        • Documents
        • FAQ Data Service
    • Automation
      • Task Service
        • Functions
        • Tasks
        • API Functions
        • Examples
          • Hello world (JS)
          • Hello world (Py)
          • Hello world (Docker)
        • FAQ
      • Dispatchers Service
      • Event Service
        • System Events
    • Communication
      • Notification Service
        • Notifications
        • Settings
      • Mail Service
    • Other
      • Localization Service
        • Language Codes
      • Template Service
        • Localizations
      • Payments Service
        • Subscriptions
        • Stripe
        • iOS App Store
      • Configurations Service
  • API Reference
    • OpenAPI Specifications
    • 📦Changelog
      • Per-service Changelog
    • Postman Reference Collection
  • Tools
    • SDK
    • CLI
    • Control Center
  • Additional Resources
    • Resource Query Language (RQL)
    • Handling Errors
    • GitHub
    • API interaction (Python)
    • Migration guide: Enabling verification request limiting
  • ExH Platform
    • 🙋Support
    • ⏱️Usage and Performance
    • 🔓Security
    • 🗺️Regions
    • ⚖️Cloud Subscription Agreement
    • 🇺🇸CFR 21 Part 11
Powered by GitBook
On this page

Was this helpful?

  1. Services
  2. Identity and Access Management

User service

PreviousIdentity and Access ManagementNextUsers

Last updated 1 year ago

Was this helpful?

The user service handles user management and offers role-based access control. By default, a new user has no permissions. Depending on the type of application you want to build you can create roles on a system and group-level and assign permissions to them.

In addition to role base access controls this service also provides registration and password management functionality.

User management

The structure of the user service, as is depicted in the graph below, relies on three core concepts; Users, roles, and groups. These concepts are explained in greater detail in the paragraphs below.

Users

The Extra Horizon user service provides standard user management features. For example; It can be used to register or remove users, update passwords and other user-related operations. This service is used to manage users, which include patients as well as staff members.

Roles

A user's role determines what actions a user is or is not allowed to perform, based on the permissions associated with that role. Roles that are granted to a user directly are called global roles. Global Roles determine the privileges a user has with respect to the EXHZ services; such as the services a user has access to, whether or not a user can view a resource, if the user can edit that resource, etc.

Groups

A group is a collection of users, which typically encompasses a company or a medical practice. They are used to connect patients and medical services, as well as for staff management.

A user can be connected to a group either as a patient or as a staff member. Since patients and staff members are both users, the distinction that separates them is their relationship with regards to a group.

The relationship between a user and a group is referred to as an enlistment. Patients are connected to a group through a patient enlistment, and staff members through a staff enlistment. Evidently, numerous users can be enlisted to a single group; Likewise, a single user can be enlisted to multiple groups.

Patient enlistment

When a patient is enlisted to a group, they entrust the group with their information in exchange for medical services. For this reason, patients are typically regarded as the end users of an application.

Staff enlistment

Staff enlistments are used to register a staff member to a group. Depending on their privilege, staff members can have varying degrees of access to a group's data, or control over said data. With these privileges, a staff member utilizes the information provided by patients for medical services or research purposes. Staff privileges are granted to group members through group roles.

Group roles

Group roles are similar to global roles, with the notable difference that they relate to a group instead of the EXHZ services. Group roles determine the privilege levels of a staff member within a group, and are not granted to a user directly but through a staff enlistment with that group.

For example, a medical practice could have three different group roles: lab researcher, physician, and practice owner. In this example, a lab researcher could be able to append the lab results of a sample to a patient's file, but not create or edit that file in any other way. Physicians could then consult these lab results to make their diagnose and prescribe a treatment to the patient. Finally, the practice owner has administrative control; which means they have control over their staff members or could register new patients to the practice. It is possible for a user to have more than one role within a group, which means the practice owner could be a physician too in this example.