The eCHR profiles define what subset of production data is going to be included in the eCHR. It also defines the signature requirements, the languages that the final eCHR will be translated into, how splits are managed, and defines the content and format of the summary text displayed on the listing page.

In a production workflow you select which eCHR Profile will apply for that workflow. An item can only have one eCHR Profile.

When you create a job, it's created against a scheduled workflow and therefore the eCHR Profile that will be used. The profile determines what will be stored when making an item.

If you spawn a task from a parent workflow (i.e., go to a Start New Task workflow such as rework or a planned inspection workflow), the data from the spawned task will only be written to the eCHR for the item if it were set up to do so in the parent workflow. You can't have a separate eCHR profile for the spawned task.

If you transfer one item from one scheduled workflow to a different scheduled workflow, you can only do that if the second workflow is on the same eCHR profile assigned.

eCHR Profiles are versionable. Each version is assigned sections and each section contains configuration which determines what content is saved in the eCHR.

Major and Minor eCHR Profile Versions

eCHR Profiles are versionable to support change control.

eCHR Profiles have a major and minor version. Minor upversions can be used to minimise approval admin where a change can be applied to existing workflows without upversioning and approving the workflows that reference the eCHR Profile. For example, you might make a cosmetic change to the format of the line summary information without altering the underlying data. You would want this change to apply across all workflows that reference the eCHR Profile, without needing to create and approve a new version of each workflow.

Major versions can be used to enforce more substantial changes such as the data to be included in the eCHR and this would require a new workflow version to be approved to control and authorise the change.

eCHR Profile Structure

The image shows the structure of the eCHR Profile.

eCHR Profile: Name of the eCHR profile allowing easy linking to applicable products.

eCHR Profile Version: It is the definition and status of versions of the profile and top-level controls for associated eCHRs.

eCHR Section: Defines the top level structure of lines into an easily readable layout, for example, "Product Definition which contains documents and bill of materials information".

eCHR Subsection: Where needed a subsection can define a secondary grouping of data. For example, group check results by op number.

eCHR Line: Defines the exact data to be recorded and the display for that data, including what data is used in the summary and what is detailed info.

eCHR Profile Configuration

The eCHR Profile screen consists of:

eCHR Profile section

Profile header: Consists of the profile name and whether it is active.
Profile version: Contains the header details that's displayed in the Details column of the eCHR Listing page. It also defines the eSignature requirements, languages and how splits are to be managed.

The image shows how the profile header information is displayed in the eCHR Listing page.

eCHR Section

Section header: Contains the user-defined name for the sections that will be displayed as the section label in the Content page of the eCHR Listing. It also contains the configuration of the data for each of the sections you want to define.
Section Config: The line type configuration defines the data that will be included in the eCHR.

The image shows how this is displayed in the Content page that is accessed from the eCHR Listing page.

In addition to viewing the eCHR profile, sections and configurations in eCHR Listing and Contents pages, you can also download a report which will be printed in all the selected languages.

eCHR Profile

eCHR Profiles control the data that is collected and how it will be displayed.

Create an eCHR Profile

Navigate to the eCHR Profiles page.
Click the New Profile button.
Complete the New eCHR Profile input screen.

New/Edit eCHR Profile

Blue fields in the form are required and are flagged with an asterisk (*) in this document.

Name*: Provide a unique name for the profile.
Header Summary Syntax*: Defines the data that will be displayed in the Details column of the eCHR Listing. This section is pre-configured but is editable if you wish to add or remove data earmarked for the eCHR. If however, you need to do this, contact Eyelit for assistance.
Approve eCHR - eSign Profile*: Signature profile that you need to close the eCHR.
Reopen eCHR - eSign Profile*: Signature profile you need if you wanted to reopen a closed eCHR.
Delete eCHR - eSign Profile*: Signature profile you need to delete an eSign profile.
Printable Report Title*: The name of the printable report.
Languages: When you complete an eCHR, it generates reports in the languages specified here. Multiple languages are supported.
Force Split on Serial Number Change toggle: This system flag determines whether a new eCHR should be created when a batch is assigned a new serial number through an edit or a split. When a new serial number is introduced, the system can either:

Maintain a single eCHR for all related items.
Create a new eCHR for the newly identified item, allowing for independent traceability.

For more information, refer to the Splitting a Batch section below.

Edit an eCHR Profile

When you edit an eCHR Profile, you can only change the name. The rest of the configuration that was set up in the new eCHR Profile is contained in the eCHR Profile version. The versions are also editable.

Edit an eCHR Profile Version

When you create the eCHR profile, the first version is automatically generated. When you edit the profile version, you can change everything that was configured in the New eCHR Profile (above) with the exception of the name.

Change Status

eCHR Profiles may have one of the following statuses: Draft, Pending Approval, Approved, Obsolete. To update a status, select the eCHR Profile version and click the Change Status button.

Manage Transaction Controls

This controls what you can and cannot do on items with an eCHR depending on the status of the eCHR. You may want to block actions from being allowed on an item or allow those actions but not write them to the item's eCHR, depending on the eCHR status. For example, by default, an item with an eCHR in Pending Approval status may not be used in a parent assembly, however, in some circumstances it may be desirable to permit this.

A number of transactions are prohibited by default for items with eCHR in Pending Approval status. This can however, be overridden by the Manage Transaction Controls settings for certain controls.

To configure the Manage Transaction Controls:

Navigate to the eCHR Profiles screen, select a profile version.
Click the Manage Transaction Controls button.
Select Blocked or Ignore for an item with an eCHR that is Open or in Pending Approval status, for each of the controls in the left hand column.
- Blocked: The control will not be allowed for an item with an eCHR in that status if it impacts the content of the eCHR, i.e., the eCHR is set up to record that information. You would need to re-open the eCHR or create a repair job to continue.
- Ignore: The control has no impact on an item with an eCHR in that status.

Examples

The examples describes how two of the controls can be configured.

Consumption / removal of eCHR item to a parent item

We want to consume a child item into a parent item before its eCHR has been approved. There scenarios are:

Open (Blocked), Pending Approval (Blocked): No consumption of the item is allowed whilst its eCHR is in one of these statuses, if that impacts the eCHR contents.
Open (Ignore), Pending Approval (Blocked): If the eCHR is open, you can consume a child item into parent item and it will not affect the eCHR. You cannot do so if the eCHR is in the Pending Approval status without it needing to be re-opened.
Open (Ignore), Pending Approval (Ignore): You can consume the child item and it will be ignored for an eCHR that's in Open or Pending Approval status.

Scrap available qty of Item

We scrap an item or part of an item in WIP before its eCHR has been approved. It may have been damaged in the warehouse. There are two scenarios that could apply:

We do not want to record the scrap in the eCHR as it has no bearing on how the item was manufactured. In that scenario, you can select Ignore for the Scrap available qty of item control for the eCHR in Pending Approval status. The eCHR can proceed to approval stage without any change.
We want to record the scrap in the eCHR. In this scenario, you will select Blocked for the Scrap available qty of item control for the eCHR in Pending Approval status. In this scenario you will have to re-open the eCHR to record the scrap.

eCHR Section

After defining the eCHR profile, you can define what data will be collected. The data gets put into sections and, within a section, you have section configs. The configs define what sort of data is going to be collected.

Having collected all this data, there are three places you can view that data:

eCHR headers in the listing page.
Line summary and line details.
HTML report.

Sections are displayed in the listing's Content section.

New eCHR Section

To create an eCHR section:

Select the version of the eCHR profile and click the New Section button.
Provide a name and set the Active field to Yes or No. If you select No, content will not be saved for this section.

New eCHR Section Config

Select the section you created and click the New eCHR Section Config button.
Complete the New eCHR Section Config input screen.

Blue fields in the form are required and are flagged with an asterisk (*) in this document.

eCHR Line Type*: Defines what type of data is collected. Options:
- Action Completion
- As Built
- BoM Definition
- Build Record
- Check Result Set
- Document
  - Checklist Document
  - Checklist Step Document
  - Issue Document
  - Item Document
  - Job Document
  - Operation Document
  - Product Document
  - Recipe Document
- Generic eCHR data WF action
- Issue
- Operation Quantity Completion
- Scrap WIP
- Tool Use
Sql Statement*: Default value based on line type selected. Each eCHR Line Type above will populate a default SQL statement that defines the data to be collected. Eyelit MES can help customise a SQL statement if you need data other than what's in the default included in the eCHR.
Required SQL Parameters: Default value based on line type selected. Pre-populates and is displayed when selecting an eCHR Line and shows the parameter the SQL statement is based on.
Sql Output*: Default value based on line type selected. Determine if the output of the SQL is a flat structure (table) or an hierarchical structure (tree view or JSON).
Details Panel Menu Item: Default value based on line type selected. Defines the screen used when we view the data. The default can be customised.

Details in Printable Report: Default value based on line type selected. The query that defines the data that goes into the printable report. This is usually left blank for the Document Line Type.

Line Summary Content: Default value based on line type selected. Allows you to customise what's displayed on each line.

Insert eSign Profile: Signature required for a new record. Not required for the As Built line type.
Update eSign Profile: Signature required for an updated record. Not required for the As Built line type.
Delete eSign Profile: Signature required for a deleted record. Not required for the As Built line type.
Sub Section Content: Defines how the document is divided into sub sections.
Line Type-specific
- Checklist Type: Select a Checklist Type. Only displays for the Checklist Result Set line type.
- Checklist: Select a Checklist. Only displays for the Checklist Result Set line type.
- Document Type: Only required for the Checklist Document, Checklist Step Document, Issue Document, Item Document, Job Document, Operation Document, Product Document, and Recipe Document line types.
- Reference Key: Only displays for the Generic eCHR data WF action line type.
- Issue Type: Select an Issue Type. Only displays for the Issue line type.
- Tool Type: Select a Tool Type. Only displays for the Tool Use line type.
- Tool Group: Select a Tool Group. Only displays for the Tool Use line type.

Splitting a Batch: Traceability and eCHR Implications

When manufacturing a batch, for example, of 100 units, there are scenarios where it becomes necessary to split that batch. This process can be handled in different ways depending on how traceability and record-keeping are to be maintained. There are three options.

1. Splitting Without Changing the Serial Number

If a batch is split but both resulting parts retain the same visual serial number, they are indistinguishable in terms of traceability. In such cases, a single eCHR must be maintained to represent the entire batch. This unified record ensures that all traceability data continues to apply to both parts of the split batch, as they are not differentiated by identity.

A practical example involves splitting a batch post-manufacture for storage in different locations. For instance, part of a batch may be stored in Location A and the rest in Location B. These would be treated as separate material items in the system due to their differing storage locations, but they would share the same manufacturing history. This scenario typically occurs after manufacturing is complete and does not necessitate a new eCHR.

2. Splitting With a New Identity

Alternatively, a batch can be split and assigned a new identity—for example, splitting batch “A” into “A” and “A1.” In this case, the new sub-batch (A1) can be given its own eCHR. The system allows for the history of the original batch to be copied up to the point of the split. From that point onward, the two batches (A and A1) can diverge, each maintaining its own independent traceability record.

For example, you found a non-conformance with a result that a subset of the batch has to take a different path for rework. They will have different histories so you'll need to split them and give them different identities.

3. Maintaining a Single eCHR Across Multiple Items

Even when a batch is split into multiple sub-batches (e.g., A1, A2, A3), it is possible to maintain a single eCHR if desired. This means all traceability data continues to be recorded in the original document, which now applies to multiple items. This approach simplifies documentation but may limit the granularity of traceability.

For example, you have a manufacturing process where you are making a single batch and start producing things as a batch but at the end of the process you serialise the items but you've got a single history record for the batch so although the items have individual identities, all the items have the same eCHR.

Note that if you serialise early in the process, you would opt for separate eCHRs for each serialised item.

eCHR Profiles