Post by Nikolaj on Jul 20, 2016 6:55:11 GMT
Hi All
In my experience, small and mid-sized companies have two main drivers to implement an EDMS. The first is a need to create electronic documents with eSigs and submission ready PDF's. The other is a requirement to electrify their quality system to obtain better compliance. 10 years ago the eCTD/submission argument was without a doubt the most prevailing. However, in the recent years this has shifted very much towards the Quality Systems. Of course these companies cannot (and should not) buy two separate systems for these purposes. Rather, the systems should be able to handle both. I would therefore argue that the Pocket EDMS should include requirements to accommodate quality documents. (Perhaps even quality processes like Change Control, Deviation, CAPA, etc.).
(On a side note, I always advise the companies to start out with the quality system documents. They are well structured, already controlled and affect everybody in the company. This will allow for a fairly "easy" implementation and at the same time familiarize the whole company with the joys of EDMS and make them ready for the next implementation sprint.)
Quality documents like policies, procedures, etc. have a training requirement and exist in both Approved and Effective/Released lifecycle states. While the Pocket EDMS URS does take these states into account, it does not cover the fact that these might exist simultaneously. Once version 1.0 of an SOP is Effective and in use, it might very well be in a revise process and updated. While the new version is still draft, the system should allow read-only users (document consumers) to see only the major versions. However, when version 2.0 becomes Approved, this needs to co-exist with the Effective/Released version 1.0. Document consumers now need to use version 1.0 Effective/Released in their daily work, while being trained on version 2.0 Approved. The problem of having two major versions of the same document needs to be handled by the system. This is what I like to refer to as the document duality.
Most commonly this is handled by having two separate document areas (repositories, folders, sites, etc.). One for the Author-type users (document contributors) where they can access the word, excel, etc. file types, and one for the document consumers where PDF renditions of the Effective/Released versions are. Depending on the technology, sometimes a third area for the documents currently being trained on.
What do you think?
- Am I mixing pears and apples?
- Is this covered somewhere else?
- Or do I have a point :-)
Best regards
Nikolaj
In my experience, small and mid-sized companies have two main drivers to implement an EDMS. The first is a need to create electronic documents with eSigs and submission ready PDF's. The other is a requirement to electrify their quality system to obtain better compliance. 10 years ago the eCTD/submission argument was without a doubt the most prevailing. However, in the recent years this has shifted very much towards the Quality Systems. Of course these companies cannot (and should not) buy two separate systems for these purposes. Rather, the systems should be able to handle both. I would therefore argue that the Pocket EDMS should include requirements to accommodate quality documents. (Perhaps even quality processes like Change Control, Deviation, CAPA, etc.).
(On a side note, I always advise the companies to start out with the quality system documents. They are well structured, already controlled and affect everybody in the company. This will allow for a fairly "easy" implementation and at the same time familiarize the whole company with the joys of EDMS and make them ready for the next implementation sprint.)
Quality documents like policies, procedures, etc. have a training requirement and exist in both Approved and Effective/Released lifecycle states. While the Pocket EDMS URS does take these states into account, it does not cover the fact that these might exist simultaneously. Once version 1.0 of an SOP is Effective and in use, it might very well be in a revise process and updated. While the new version is still draft, the system should allow read-only users (document consumers) to see only the major versions. However, when version 2.0 becomes Approved, this needs to co-exist with the Effective/Released version 1.0. Document consumers now need to use version 1.0 Effective/Released in their daily work, while being trained on version 2.0 Approved. The problem of having two major versions of the same document needs to be handled by the system. This is what I like to refer to as the document duality.
Most commonly this is handled by having two separate document areas (repositories, folders, sites, etc.). One for the Author-type users (document contributors) where they can access the word, excel, etc. file types, and one for the document consumers where PDF renditions of the Effective/Released versions are. Depending on the technology, sometimes a third area for the documents currently being trained on.
What do you think?
- Am I mixing pears and apples?
- Is this covered somewhere else?
- Or do I have a point :-)
Best regards
Nikolaj
