It is important to be aware that there is a degree of setting-up required to obtain the very best results out of iPassport QMS. Care taken at this stage amply repays the effort expended with ease of use afterwards. A variety of critical decisions need to be made at the outset. These are listed below. We suggest that this document is read in its entirety before diving in to set up the account.
Some information is repeated to highlight the concepts and offer them from a different perspective. Instructions and further comment are supplied in the user guide, Organisational Units, User Groups, Roles And Permissions Within iPassport.
It is recommended that the following order is observed when setting up iPassport QMS:
Above the normal permission system in iPassport, there is a special status called, Site Admin. Users with this status have access to all areas of the system and are effectively granted all permissions. This is useful at the beginning, to allow setting up certain areas without getting locked out for lack of permissions. It’s also very useful for at least one person to have this status going forward if, for example, another user is absent and has left information locked down, which needs to be accessed.
Initially, the Site Admin creates user accounts and manages the system’s settings. These responsibilities can then be assigned to other administrative staff but the Site Admin person will always be able to override changes or limitations imposed by any administrators.
It is recommended that there is at least one Site Admin in every account and thought should be given to a second person having these rights to provide for a temporary absence of the primary Site Admin. The first Site Admin must be added externally so once one has been chosen, please contact the iPassport support team to do this. Afterwards, any Site Admin can grant the special status to other users.
There is a setting for a user timeout in iPassport QMS which will automatically log a user out of the account after a defined period of inactivity. This period can be adjusted in the System Preferences > Miscellaneous Settings area and it applies to all users of the account. The default is 15 minutes of inactivity. If the timeout period is very long and users get into the bad habit of closing their browser tab without logging out of iPassport, they will reduce the number of licences available for other users to log in.
An Organisational Unit (OU) is a means of grouping records together; it can be thought of as a secure folder. All controlled documents have to be placed inside an OU and access to them depends on the permissions an individual has within that OU. Users that don’t have any permissions within an OU won’t even see it in the system. OUs are frequently associated with departments but they are also used to either share common documents across several departments or conversely, to hide records so that only a few users can view them. There is no limit to the number of OUs that can be added to the system and they are not hierarchical in nature; an OU does not inherit any information from another OU.
As an example, a laboratory might have separate OUs named after the ‘Biochemistry’, ‘Haematology’, ‘Cytology’ departments, an OU for ‘All Common Policies’ and an OU for ‘Admin Sensitive Documents’.
Important things to note:
Once an OU has been created, only the administrators will be able to access it until a User Group is created and associated with it.
A user group can include unlimited users and there can be as many user groups as required. They allow organising staff into identifiable ’teams’ with all members of each group having the same roles (permissions). Any number of disparate user groups can be linked to the same OU, so that staff members can perform their functions within iPassport. Examples of user groups can be ‘Document Viewers’, ‘Document Editors’, ‘Competency Examiners’ or ‘Administration’.
Despite it being possible to link a user group to multiple OUs, it is recommended that user groups are linked to only one OU whenever possible. It makes it easier to manage permissions downstream as the organisation evolves and its people or their functions change.
Following the example above, a laboratory could have user groups like:
Based on this information and before setting up the system, it’s important to decide how all documents will be classified and what OUs are required for them. The objective is to group them in such a way that, if a user is intended to access one document in a given OU, it’s appropriate for that user to have equal access to all the other documents of that type in the same OU.
The next step is to create a list of user groups that will cover all the necessary functions to access and manage the information in every OU. Since there can be as many user groups as required and a person can belong to multiple user groups, it’s always good practice to try to limit each user group to one OU as shown in the example above, even if the people and roles (of a given user group) are the same to start with.
User groups should be designed to reflect the functions of the organisational structure since all the users of a given group will have the same permissions. The next section about roles elaborates on this concept.
Roles are sets of permissions, drawn from a comprehensive pool that covers all the activities within iPassport. There is no limitation to the number of roles or possible combinations of permissions within them. There is a collection of predefined (system) roles included in iPassport so that there is no need to create new ones initially but the flexibility is there to copy and refine existing ones.
Without roles, a user group will have no access to any OU it is already linked to. A role (or series of roles) is assigned to a User Group for a particular OU. Therefore, a user can have different roles within different OUs by being member of multiple user groups. Similarly, additional user groups can be used to prevent all members of a team from having unintended permissions. For example, all the members of a team would be part of a user group that can view the SOPs relevant to that section but only the team leader would be made member of a user group that authorises leave for that team. Roles that could be used in this example would be, SOP Viewer and Personnel Management Editor.
Important things to note:
Once organisational units and roles are defined, users can be added to the system and assigned to User Groups.
These are the general properties of a user record:
Please note: When a user is created in the account, they must be assigned a Home (Default) OU. This doesn’t grant any access to the OU. Its purpose is to be able to limit access to the user’s personal records (e.g., skills, leave), so that only key users in that OU can view them. In short, the Home OU is about who can see a user’s records rather than what the user can see.
As well as having OUs to organise documents, there are two other labels to be aware of.
Within iPassport, a document Type refers to whether the document is an SOP, Policy, a ‘regular’ Document, COSHH, External Document, Health & Safety or a Job Description. This has to be assigned at the time of creating the controlled document within iPassport because their formats and related information vary. The structure of permissions allows granting access to the different types of documents independently, so a user might have permission to view SOPs in a given OU but not view the Job Descriptions in that same OU. There are dedicated search filters for the type of document which in conjunction with OU search filters, allow isolating all the documents of one type in one OU.
In addition, a Category can be assigned to a document to further classify it. Categories are not exclusive to a type of document or its OU. They can be thought of as tags and they can be helpful to group controlled documents in different ways. Once a category is created, it is available for use with any document in any OU but only one category can be assigned to any controlled document. For example, a number of different types of relevant documents in different OUs, can be grouped under the category, “Reagents”. With the use of the dedicated search filter, all types of documents under this category can be brought up (say, reagent handling SOPs, reagent storage Policies, COSHH documents, etc) from different OUs (say, reagents used in Pathology, Microbiology, etc.).
It’s not recommended to try and do too much at once; it works best to concentrate on specific areas of iPassport QMS during the first three months. With all the best intentions, it is not possible to use all of the modules at once. Once knowledge and skills start building up, the rest of the system should come easily.
If standards are required to be loaded into an account, it’s important that the holder of the account first gains permission from the standards body. The system offers a Standards Importer feature that allows users to load them independently. In many cases, Genial will be able to upload a copy of the standards to an account but a copy of the confirmation (proof of purchase) is required prior to undertaking the import. Multiple standards can be loaded in each OU and since there is no limitation in number, it’s possible to load the same standards in multiple OUs so that they are available for different departments.
The logical order of steps involved in planning the setup of an iPassport account is:
The use of a training account is strongly recommend; these are provided free of charge by Genial to allow practicing without the worry of making any mistakes. All of this can be daunting, therefore Genial support staff members are on hand throughout the implementation period and beyond, to answer any questions that may arise.
The minimum system requirements* to run iPassport QMS are, a computer with an internet connection and one of the following supported internet browsers:
We recommend running the latest stable release of any of the above web browsers.
*Subject to change without notification.