User Requirements
This page provides a listing of regulated requirements that were utilized to build the Tulip product.
The user requirements on this tab are organized into two categories: ALCOA and ERES and have the following fields:
ID: The ID provides a unique reference to the requirement. The format was changed to ABC-1234 in LTS7 to directly link the numbering from the tickets used internally for development. The prior ID was maintained as a cross reference since LTS7.
Requirement: A brief description that describes the user requirement.
Implemented By: The Product Spec(s) that provide the feature/functionality to support the user requirement. Features may be used individually or in combination with other features to achieve/meet the requirements.
As part of LTS11, Tulip has also decided to deprecate the usage of all user requirements, aside from the explicit regulatory requirements for electronic records and signatures associated with 21 CFR Part 11, Annex 11 and the commonly recognized requirements around ALCOA+. User requirements are not used internally for product development. Our Product Management team uses an internal process to triage many different feeders to define what Tulip will work on to evolve our product. Also, it is felt that user requirements should come from the users, our beloved customers as they define the scope of how Tulip will be used in their operations. We provide a set of features necessary to the target customers we desire to support. These product features are outlined in our Product Specifications pages.
GxP
ALCOA
| ID | Requirement | Implemented By |
|---|---|---|
| PLAT-8734 (852) | System must provide accurate time server synchronization and shall utilize the same time source. | |
| PLAT-8865 (800) | All records shall be Contemporaneous. Data captured should include the date and time of the activity/action. | |
| PLAT-8867 (801) | All records, including audit trail shall be Legible, ie. shall be human readable throughout the retention period. | |
| PLAT-8885 (813) | All data shall be Attributable; data must be identified to the person who did the data collection. Records shall include information about how the data was acquired, action/activity performed, where and and when. | |
| PLAT-8915 (804) | All records shall be Complete. Records shall include all data related to activity with no deletion or overwriting. | |
| PLAT-8916 (803) | All records shall be Accurate. there must be the ability to build accuracy checks into the design of the system or configure verification for manually entered data as necessary. | |
| PLAT-8920 (802) | All records shall be Original; all originally recorded data shall be maintained. | |
| PLAT-8946 (806) | All records shall be Enduring, ie. stored, managed, accessible and unalterable for the full retention period. | |
| PLAT-8948 (805) | All records shall be Consistent, ie capture and recorded in the same manner and in the correct sequence of the acitivities or action being recroded. |
ER ES
| ID | Requirement | Implemented By |
|---|---|---|
| PLAT-8807 (32) | All Users have to be uniquely identified. | |
| PLAT-8809 (29) | Access and use of system and its components shall be limited to authorized users. | |
| PLAT-8829 (26) | Ability to authenticate all defined users with a unique username and password using a single sign-on (eg. oAuth, LDAP, Active Directory, etc). | |
| PLAT-8859 (121) | Ability to define procedural sequences with relevant process information that can guide an operator through task execution. | |
| PLAT-8866 (33) | Display the current user logged in during any interaction with the system. | |
| PLAT-8869 (856) | Continuous signing sessions require two signature components for first signing but only one (secret) component for subsequent signings. | |
| PLAT-8871 (855) | For records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry. | |
| PLAT-8872 (830) | All data changes must be captured in audit trail. Audit trail can be turned off or on for GxP needs. This may only be performed by an administrator; it cannot be performed by a user executing an APP. | |
| PLAT-8874 (848) | The ability to discern invalid or altered records. Ability to annotate data is changed. For GMP or critical data changes annotation can be configured as required. | |
| PLAT-8883 (814) | Ability to view, display and and print accurate and complete records, including any attachments, electronic signatures and their associated audit trails. | |
| PLAT-8888 (811) | All records, electronic signatures, and audit trails must be human readable and protected to ensure they are readily retrievable throughout a pre-defined retention period. | |
| PLAT-8891 (816) | The manifestation of an electronic signature should contain the user's full name, date & time, meaning of signature human readable format; the record itself should contain these elements. | |
| PLAT-8893 (815) | Provide an unalterable and enduring link between records and their associated electronic signatures; they cannot be removed, changed, copied, transferred or deleted. | |
| PLAT-8899 (43) | All user maintenance activities shall be recorded. | |
| PLAT-8902 (817) | Ability to require multiple electronic signatures for a record. Ie co-signer, verifier, etc. | |
| PLAT-8904 (820) | Electronic signatures have to be secured and not allowed to be falsified. They can only be used by their genuine owners. | |
| PLAT-8905 (819) | All electronic signatures have authenticate the signatoree by two distinct elements (e.g. username and password; at least one being a private element), or a secure unambiguous biometrics system that cannot be used by anyone other than their genuine owner. | |
| PLAT-8906 (818) | If more than one signature is required the electronic signature shall capture the role of each signatoree. Eg. trainer, verifier, co-signer, etc. | |
| PLAT-8937 (808) | All records have to include the date, time, action or activity, user, and reason for change if applicable. | |
| PLAT-8939 (35) | Automatic logout user from system after a configurable amount of inactivity time. |