Electronic Control History Record (eCHR)
In highly regulated industries such as aerospace, defence, and medical device manufacturing, strict traceability and audit requirements demand exceptionally reliable record keeping demonstrating that products have been manufactured to high quality standards in accordance with their design.
In the medical device sector, one such requirement is to record device or batch history records in an Electronic Device History Record (DHR). These must clearly show that products are manufactured according to approved processes (as defined by the device master record – DMR), ensuring patient safety is never compromised.
Key regulations in the medical device sector include FDA 21 CFR Part 820 and ISO 13485, though other regulated industries follow similar standards. A common requirement across all of them is the ability to prove, through an immutable audit trail, that manufacturing has consistently met compliance standards.
Some records require a signature, and where the details are collected electronically, specific regulation defines the requirements for these signatures to be considered equivalent to a physical signature (FDA 21 CFR Part 11).
In 9.0, we introduced our Electronic Control History Record (eCHR) system which is designed to meet these regulatory demands. It lets you define exactly what information should be included in the controlled history records, provides an immutable audit trail for this data based on blockchain storage, and supports electronic signatures for approval of these records.
Manage Reset of Non-SSO User Password
User accounts are explicitly marked as to whether they use SSO or Eyelit identities. If you select SSO, you will be prompted to record a Principal Name which is the Azure identity. You will still have an Eyelit password for eSignatures.
If you select Manual Password, your Eyelit identity, then the same password is used to login and for eSignatures.
A further scenario is addressed where not all users are on SSO or have email addresses. In these cases, password management is complicated.
In 9.0, the User Access field was introduced to allow easy management of all user scenarios.
You can select:
SSO: The Principal Name is mandatory as it maps to the User principal identifier in Azure AD. You need to populate this field to automatically federate your account with Azure AD. This is usually the same as your email address but not always.
- If you select this option if the password is configured in MES this will only be used for eSignature functionality within the system. This password can now be changed or reset by the user by clicking the person icon and selecting:
Change eSign Password: Displays the Change Password pop-up.
Reset eSign Password: Triggers a reset email to be sent to the user.
Manual Password
User has an email: It is recommended that the Force Password Change On Login checkbox is ticked. This will trigger an email to be sent to the user to allow them to set their own password without the administrator having visibility of the password. If the administrator triggers a reset of password this will also send an email direct to the user.
User does not have an email: The email field is optional which caters for users who don’t have an email. A password will be automatically generated and displayed to the administrator to share with the user. This is also the case where an administrator resets the password for the user (see image below).
Default Work Centre
A device may be linked to multiple work centres. In previous versions, one work centre on a device could be configured as the default. At the same time, the sequence of work centres could be configured but always had the default work centre in the first position.
To simplify the sequence of work centres on a device, the default work centre functionality was removed in 9.0, and only the sequence of work centres is now a consideration. Whichever works centre is in first position in the sequence is always considered the default. Drag and drop are supported for ordering the sequence.
Document Manager
Documents may be configured with an External Reference. In previous versions, even though the reference could be provided, it was not displayed in the Document Management grid.
In 9.0, the External Ref Field is included in the grid on the Document Manager screen, which can be made visible if hidden. It displays the value entered during document creation. It can be used, for example, to match a version in the Document Manager to a version on an external document management system.
Public API
The APIs continue to be improved in 9.0.
API Versioning
Versioning of our APIs was introduced. This ensures backward compatibility and integration stability, allowing customers to adopt new features without impacting existing implementations.
Product Property Update
Ability to trigger integration from productprop.set transaction.
Materialitem/move
The public API endpoint for MaterialItem/Move lets you specify the material item ID, new location ID and comments.
Location
A new API endpoint called Location/List was added to list locations by the following filters:
Location SUID
Location Name
Warehouse
Site
Organisation
MaterialItem/PutOnHold
The endpoint allows the status update of a material item called MaterialItem/PutOnHold which allows you to pass in the following:
Material Item ID
Reason (mandatory)
Comments (optional)
Skill Upsert
Create or update a skill. Require the following fields to be input:
ID (mandatory for update)
Name (mandatory on insert)
Description
Skill Type (mandatory on insert)
Active (Mandatory on insert)
Remove skill from referenced products, activities and issue types
Time Limited (Mandatory on insert)
Time limit option (mandatory on insert when time limited field is yes)
Expiry Days
BoM Slot Candidate
Improvements were made to the BoM Slot Candidate in 9.0.
Improved Candidate Screens
The order of fields was rearranged to group elements logically and provided a better user experience.
BoM Slot Candidate Screen Improvements
Now, the Default Qty field is positioned below the Default Candidate field.
The unit of measure field was introduced and has been positioned below the Default Qty field.
Add/Edit Candidate Screen Improvements
The Child Qty field was moved below the Candidate field.
The Unit of Measure field was introduced and has been positioned below the Child Qty field.
Unit of Measurement (UOM)
The following improvements related to the UOM have been implemented in 9.0.
Workflow action: For every candidate linked to a BoM slot, it is now possible to configure the appropriate UOM for the candidate for that BoM rather than assuming the default UOM for the child product. For example, if you perform different transactions in different UOMs. Most common is if you were consuming it in grams, but you might receive it in kg. Then the stocking UOM used for receipts and warehouse transactions could differ from what appears in BoMs and use transactions.
- Completion % and validation of completion vs requirement including tolerance is calculated based on the quantity UOM.
Screens updated with UOM displayed: Build Screen, Remove Screen and Stock Items.
Creation of Product Specifications at Check Item Template Creation
When you create a check item template it is associated with one or more product types. A corresponding specification record is created for all products of the types specified.
If you populate the default specifications (target/upper/lower limits), these are also copied to all products within that type, i.e., this could involve the background creation of potentially hundreds of product specification records. This is not obvious.
Additionally, if a mistake is made here, it is hard to rectify (e.g., if a specification is populated that is only relevant for a small subset of products or there is a mistake in the default criteria).
Release 9.0 addresses these issues by:
Displaying the following warning on creation of a check item template: “Warning: creation of this check item template will automatically create a corresponding specification for all existing products of the types specified - the specifications for each product will match any default values entered below.”
Enforcing eSignature approval if an eSignature permission requirement is set against the check item template when the check item template is created. (Previously, the signature was only enforced on subsequent edits of a specification).
