Skip to content

Label Verification and Reconciliation#

Overview#

The Label Reconciliation feature aims to improve the handling the verification/validation on every printed label. It is expected that labels are attached to final good products or scrapped.

Concept#

Every printed label needs to be verified and accounted for (either attached in a final goods Material or scrapped).

Label Verification can be made in one or more steps, and a final reconciliation shall be performed at a pre-defined step.

Concept

Verification can include#

  • Capturing/attaching images of printed product labels.
  • Storing the Counts for Good, Scrapped, verified labels.
  • First + Last label checks.

Reconciliation#

  • Tracking the counts of how many labels were printed vs how many verified, scrapped or left over.
  • Trigger protocols or prevent trackout if not all labels are accounted for the reconciliation process

Setting up a Label Reconciliation Scenario#

Printable Documents#

Set up the printable documents that shall be evaluated in the Reconciliation process. This feature requires the usage of MES Printable Documents, with printing triggered by the MES. The actual printing can be directly to a printer or integrated with a 3rd party printing system (e.g. Nice Label or Bartender).

In case the printable document layout includes more than one label (e.g. a sheet of 10 labels), the correspondent Attribute MedDevLabelsPerDocument defined in the Printable Document entity should be set accordingly.

Data Collections#

It's necessary to configure the Data Collection(s) used in the Verification / Reconciliation Steps.

To trigger the logic, the Data Collection must be of type "Label Reconciliation" (configured through /MedDev/LabelReconciliation/DataCollectionType/).

The Verification / Reconciliation Data Collections shall hold a set of parameters, such as First/Last Label, Good Labels, Scrapped Labels and others, depending on what is intended to verify at a given step.

A set of predefined parameters are already created in the System:

  • MedDevGoodLabels - Good Labels Parameter for Verification process
  • MedDevTotalGoodLabels - Total Good Labels Parameter for Reconciliation process
  • MedDevScrappedLabels - Scrapped Labels Parameter for Verification process
  • MedDevTotalScrappedLabels - Total Scrapped Labels Parameter for Reconciliation process
  • MedDevFirstLabelCheck - First Label check Parameter for Verification process
  • MedDevLastLabelCheck - Last Label check Parameter for Verification process
  • MedDevRemainingLabels - Remaining Labels Parameter for Verification/Reconciliation process
  • MedDevMissingLabels - Calculated Parameter with the Missing Labels validation on Label Reconciliation
  • MedDevFirstLastDiff - Calculated Parameter with the Difference between first and last labels validation on Label Reconciliation
  • MedDevFirstLabelCounts - First Label Counts Parameter for Reconciliation process
  • MedDevLastLabelCounts - Last Label Counts Parameter for Reconciliation process

Warning

The Data Collection Parameter Sample names configuration must match the Printable Document names, e.g. to record the number of scrapped labels of each label document.

Note: When defining Data Collection Parameters to be used, it's necessary to be aware different parameters can account differently to the final reconciliation values.

  • Parameters like Total Good Labels, Total Scrapped Labels, Firt/Last Label Counts, etc, have an Absolute update mode, meaning that any update to these parameters will overwrite the previous count. These should be used in cases where the full amount of labels is verified (e.g. check all labels as good or scrap in a step).

  • Other parameters like Scrapped Labels, First/Last Label Check, etc, are Incremental, and will be added at each verification step until the final reconciliation is reached.

If needed, different user-defined parameters or update modes can be used for verification/validation purposes, by configuring them in the MedDevLabelVerificationParameters table (see Administration section).

To define corrective actions in case of missing labels, Data Collection Limit Sets and Protocols should be configured, typically in the MedDevMissingLabels and MedDevFirstLastDiff parameters. With these Rules approach it's possible to trigger the required quality protocols with regards to Missing Labels (which ideally should be 0) and inconsistent First/Last Label check (which should have same the number).

reconciliation_missing_labels_preview Alternatively, the Data Collection attribute MedDevPreventTrackOutOnLabelCountMismatch can be set to trigger an error in case of a mismatch during label reconciliation, instead of triggering a Protocol.

At Trackout moment there is a warning that will be shown if the First Label and Last Label Verifications Counts are 0, the Data Collection attribute MedDevShowFirstLastLabelsVerificationWarning can be set to show this warning message in case of having First and Last Label verification counts both equal to 0 at label reconciliation. This Warning message does not prevent the Material to be tracked in, is just to highlight the missing validation process.

The Data Collection can also include additional parameters for other purposes, or the verification parameters can be added to existing Data Collections to extend existing processes, as long as the Data Collection Type matches the Label Reconciliation config.

The Verification / Reconciliation Data Collection can optionally be placed in Checklists to guide users into the Reconciliation process. To record/capture pictures of the actual verified labels, checklist parameters of type File can be used.

The Data Collections/Checklists can be associated to a Step operation via the Material Data Collection context, or executed directly via Perform/Post Data Collection, as long as a Material is included as context.

Even though the logic supports having separate verification and reconciliation steps, there is no problem in having a single verification and reconciliation data collection and step at the end of the flow.

Execution Behavior#

During execution, when a Printable Document is printed for a Material, a MedDevMaterialPrintableDocument relation is created between the Material and the Printable Document, keeping the number of document/label copies printed (multiplied by the MedDevLabelsPerDocument).

When verification Data Collections/Checklist are triggered, the user must input the configured data collection parameters for the step (e.g. scrapped labels + first & last label checks). Upon Data Collection Instance closure, the parameter values are persisted in the MedDevMaterialPrintableDocument relation, either incrementing or replacing the existing values depending on the parameter update mode.These parameter values are populated to the Data Collection Instance from the MedDevMaterialPrintableDocument relation.

At the reconciliation Data Collection Step, the final values on the relation can be pre-filled in the data collection for final verification and sign off. If missing or unverified labels are detected, these will be recorded in the Material history and Exception protocols can be triggered.

DC parameters to collect

In order to have the values pre-populated from the relation to the DC the operation and DC Operation Type to be used should be Track-In and LongRunningAfterTrackIn.

Operation Data Collection Type IsAvailable
TrackIn LongRunningAfterTrackIn Yes
TrackIn Immediate No
TrackIn LongRunning No
TrackOut any No
Other any No

Example Scenario Data#

This section include example Master Data files with separate Verification and a Reconciliation Data Collections and checklists, and more detailed instructions on how to quickly setup a label reconciliation scenario.

  1. Label Printable Documents

    In the example that follows this user guide, it's assumed that there will be 3 labels to verify/reconcile.

    • MedDevLabel1
    • MedDevLabel2
    • MedDevLabel3

    The Labels can be imported using this MedDevLabelsExample file. (To download this file select "save link as..." )

    These Printable documents are just simple examples that hold the name of the Material and the number of copies. They are provided on this guide to understand the relation between the label (printable document) and the Verification/Reconciliation process.

  2. Verification / Reconciliation Data Collection and Checklists

    It's possible to use the example available below with Data Collection/Checklist to perform verifications and reconciliations:

    In this Master Data file it's possible to find an example of two Verification and one Reconciliation Checklist and the correspondent Data Collections. Note: in the second Master Data file (002-reconciliation_dc_rule.xlsx) it is created an example to attach Rules in the Reconciliation Data Collection.

    The Checklists from the examples are provided using three Checklist items:

    1. File Attachment - To collect Label samples (capture images) as proof of verification
    2. Label Verification / Reconciliation - To collect the counts for Reconciliation process
    3. Signature - To allow QA roles to approve the collected counts

    Exception Protocols are not included in the example Master Data, if intended they should be configured as Warning/Error Violation Protocol in the Reconciliation Data Collection Parameters MedDevMissingLabels and MedDevFirstLastDiff. Alternatively, the Data Collection attribute MedDevPreventTrackOutOnLabelCountMismatch can be set to trigger an error instead of triggering a Protocol.

  3. Material Checklist and Data Collection Contexts

    The MaterialChecklistContext and MaterialDataCollectionContext should be updated to assign the Steps where the Validation/Reconciliation Checklist and Data Collection needs to be triggered.
    If required, the Data Collection Limit Set should also be filled in, in order to record non-compliances and trigger exception protocols.

    Relation Values Data Collection - Print labels for a material to create the MedDevPrintableDocument relation alt text - Have a reconciliation DC configured in a step - Dispatch and Track In the Material ,then open the DataCollection instance through Post Data alt text - The values are being populated to the DataCollection instance from the MedDevPrintableDocument relation. alt text

Administration#

Config#

Enable Feature through /MedDev/LabelReconciliation/EnableLabelReconciliation config entry.

This configuration shall allow the creation of custom Relation between Material and Printable Documents used in the reconciliation process (MedDevMaterialPrintableDocument).

Reconciliation Data Collection's Type name shall be configured through /MedDev/LabelReconciliation/DataCollectionType/ config entry.

This determines which Data Collection Typed will trigger the Verification/Reconciliation logic to be performed, enabling the feature.

MedDevMaterialPrintableDocument Relation#

MedDevMaterialPrintableDocument is a Relation Entity Type between the Material and Printable Document, and it keeps track of the count of all the labels printed and verified for each printable document, to be later used during reconciliation. Even though the relation is editable, in normal situations, the values should only be updated indirectly via Data Collections or document printing. Access to Material relation changes can be restricted by the Material.Edit security feature.

MedDevLabelVerificationParameters Generic Table#

A Generic Table was created to map how the Data Collection parameters interact with the MedDevMaterialPrintableDocument Relation properties. It contains the following columns:

  • Parameter - Corresponds to the parameter created.
  • Verification Property - It's the MedDevMaterialPrintableDocument Entity Type Relation's Property name that shall hold the value received in the Parameter.
  • Update Mode - is the type of calculation performed when updating the Entity Type Relation's Property.
  • PreFillParameterValue - is used to pre-fill the data collection's Parameter with the existent value when the Data collection GUI is opened.

The available Update Modes are:

  • Absolute - the value read from DC shall overwrite the total Property
  • Increment - the value read from DC shall be incremented to total Property
  • Decrement - the value read from DC shall be decremented from total Property
  • NoCalculation - no calculation shall be made

Some configurations examples:

  1. Two parameters pointing to the same Total Property

    two_parameters_good

    In the image above there are two parameters pointing to the same Property in the relation entity MedDevMaterialPrintableDocument.

    • GoodLabels => TotalGoodLabels
    • TotalGoodLabels => TotalGoodLabels

    In this example the GoodLabels Parameter is using the Increment Update Mode, this means that when used in a "Label Reconciliation" Data Collection type (ex: at Verification phase) it will increment the provided value to the existent TotalGoodLabel existing value - for use cases where verification is done gradually across several steps.

    On the other hand, the TotalGoodLabels is configured to use Absolute and Prefill, this means that when this Parameter is used in a Reconciliation Data Collection it shall place the value existent and the collected values (if updated) shall update the absolute values on the Relations Entity Property - for use cases of all labels verification or final reconciliation confirmation.

  2. Two parameters pointing to the same Total Property on the Same Data Collection

    It's possible to have more than one Parameter updating a Property from the Relation Entity MedDevMaterialPrintableDocument. For example It's possible to have different types of Good Label being verified. (ex: Labels that were pre-printed and labels that were printed on-demand.

    • GoodLabelsPrePrinted => TotalGoodLabels
    • GoodLabelsOnDemand => TotalGoodLabels

    The same approach can be used for different types of scrapped labels where, by having different Parameters representing different types of scrapped labels. parameter_scrappedtype

    These different Parameters can contribute to feed the Relation Property TotalScrapedLabels from Entity MedDevMaterialPrintableDocument

  3. One parameters used in the verification and reconciliation

    one_parameter_remaining When needed, it's possible to have a single Parameter being used in both Validation And Reconciliation Data Collections. For example the Remaining Labels Parameter, it might be configured with Absolute Update Mode and Prefill. On Each Data Collection the absolute value shall be placed (prefilled) and the users shall update it to the new Remaining Quantity obtained from the reading. The new value shall update the Remaining Labels Property with the new value added.