We pick up where we left off.
The system can now handle tokens and all the problems that come with them.
The first thing we want to replace is the label printing system.
In fact at the moment we have installed n different software around the production and beyond, Nicelabel....easylabel etc...etc..
Of course with different versions that are sometimes not compatible with each other.
You should know that in the pharmaceutical/biomedical industry, labels are an integral part of the product itself. This is why labels are subject to strict version control.
At the moment, each PC in the production used to print, points to a network folder containing the latest version of the label layout, obviously for the same item we can have multiple labels, as the one we are going to apply to the product will be the first, the one on the box that contains the product will be the second, if was planned to pack n boxes in a larger one, there will be the third.
I problemi più comuni che incontriamo sono i seguenti
1-Utilizzo di una versione non aggiornata (diversi operatori memorizzano il layout dell'etichetta a livello locale, perdendo gli aggiornamenti rilasciati dal reparto qualità).
2-Mislabelling: l'operatore spesso dimentica di applicare un'etichetta.
3-Etichette con codici a barre illeggibili.
Prima di proseguire, è bene sottolineare che il file contenente il layout dell'etichetta presenta dei campi contenenti i dati veri e propri, che puntano tramite ODBC alle tabelle di un ERP dBase (i cosiddetti campi variabili). Questo permette al sistema di ottenere tutti gli altri dati dall'ERP attraverso il batch inserito dall'operatore al momento della preparazione della stampa.
Another peculiarity of the highly regulated environment in which we find ourselves is that in the case of rework of a batch, it must be relabelled with the label version released on the date of that batch, so that operators are forced to save the replaced layouts in dedicated local folders. In this way, during a rework, looking on the DHR to be relabelled will yield the version of the label to be used, saved locally.
So now we start to develop software that will be named after the procedure that manages the release of labels, the famous DBMD. Which will be nothing more than a function of our SYSTEM.
The first thing we had to do was to find graphics libraries that could work in a web environment. Once a field was inserted, we needed to be able to move it to the desired position. But before we could start inserting labels, we had to insert the link "label_field_name" ==> "table_db" ==> "table_field" into the appropriate tables, because there are obviously dozens of fields.
Obviously, all these records must be signed by the person who inserts them. The fields containing the coordinates must also be signed in order to correctly position both the text boxes containing the field description and the field containing the value dynamically retrieved from the ERP.
We are now in a position to be ready for the input of over 3,000 labels.
While our colleagues continue to prepare all the new label layouts, we can continue to build the part of the programme through which, by entering the number of the work order, the function of our system will be able to generate a PDF with all the variable data, inserting them in a special table, By entering the number of the work order, the function of our system will be able to generate a PDF with all the variable data, insert it in a special table with the signature of the person who has requested the printout and, always using the same function, we will be able to select the printer and print the PDF using a ZPL command, so that we can also manage the number of copies, information that will always be entered in the database with the relative electronic signatures processed through the distributed tokens.
As you will have understood, DBMDD is made up of two well-defined parts: an administration part, which is used by those who have to prepare the label layout and the link between the ERP and the defined variable fields, and a user part, which is used by the production department when there is a need. In the latter case, after entering the job number, the system allows the user to select the type of label (product, box, master box) and the number of labels to be sent for printing. It also displays the number of labels that may already have been printed. Procedure in accordance with GMP requirements
Again, in order to comply with FDA regulations, the system guarantees access only to authorised persons, authorisations which, like all other information, are recorded in the system and signed in accordance with PART11 CFR21.
As we said at the beginning, in the event of rework, the system must guarantee the printing of the label used during the first "packing". When you request the printing of a label by entering it in the work order, the system checks whether it has already been printed and, if so, it calls up the layout in the version that was released in production on day n.
Well, I would say that I have given you a good idea of what the system can do so far..... In the next few days I will try to explain all the others... they are many, but no less interesting.
Below the links to the first and second parts:
댓글