We left off with the observation that THE PROJECT was anything but simple. We are now faced with a system that can handle the tokens that we are going to have to issue to our colleagues in order to apply electronic signatures to various documents.
I am going to digress a little. When I talk about electronic signatures, many of you will immediately think of the electronic signature system issued by various public bodies, such as chambers of commerce or companies authorised to issue time stamps. What we need is not to guarantee the date and time of a given signature to a public body, but to a certifying body which is "content" to have a system capable of creating records on a certified date, even "only" from a company server, as long as the latter has also been validated according to what is required by the FDA.
As we have said, we now have a system capable of managing I tokens to be used for signature applications. This is made possible because the system developed is composed of:
- A system that issues the token by associating it with an AD user.
- Associates the AD user with an identification document
- Manages the replacement of a lost or failed token
- When a user leaves the organisation, manages the retention of the token.
Obviously, the system described above will be part of the validation of what we call THE PROJECT, the real name of which is e-DHR, which stands for Electronic Device History Record. This is a kind of "registration book" that tracks each and every batch of material produced and issued by Quality after it has been deemed compliant for sale.
At this point, in order to validate the system, we have to make sure that if a record is changed, it is highlighted by an "audit trail" reporting system. So how does it all work?
All the data is stored in a relational database in which we find n tables. Each table contains at least 3 fields. These fields are two ID fields, one auto-incremental and two integer fields, one of which will contain the ID of the modified record in the event of a modification. The last integer field will contain the MD5 generated by passing as arguments all the fields considered sensi in addition of course to the ID.
Obviously not satisfied with how complicated the system has become, wanting to follow Our commandments, we need to develop a system capable of signing and then replacing the largest number of documents/files, so we decided to build a system of tables, also validated, where it is specified for each table what are the fields to be included within the MD5 field, which will contain the value calculated by passing to the function the fields specified in the appropriate configuration tables.
I think that even for this post has given you several pieces of information, far from easy to digest. Know that THE PROJECT has not yet begun.
We are only at the beginning....
Opmerkingen