The Cove Business Standards Discussion Forums
UL - Underwriters Laboratories - Health Sciences

Monitor the Elsmar Forum
Sponsor Links

Courtesy Quick Links

Links Elsmar Cove visitors will find useful in the quest for knowledge and support:

Jennifer Kirley's
Conway Business Services

International Quality Services

Marcelo Antunes'
SQR Consulting, and
Medical Devices Expert Forum

Bob Doering
Bob Doering's Blogs and,
Correct SPC - Precision Machining

Ajit Basrur
Claritas Consulting, LLC

International Standards Bodies - World Wide Standards Bodies

AIAG - Automotive Industry Action Group

ASQ - American Society for Quality

International Organization for Standardization - ISO Standards and Information

NIST's Engineering Statistics Handbook

IRCA - International Register of Certified Auditors

SAE - Society of Automotive Engineers

Quality Digest

IEST - Institute of Environmental Sciences and Technology

Single Post View
Old 16th May 2017, 06:40 AM

Total Posts: 39
Re: Integrity - The meaning of the word INTEGRITY in ISO 13485 Control of Records

In Reply to Parent Post by ehrbs27 View Post

I mean, do not divide as you like. for example, if you have a record "a/b/c/d/", then you should not divide it by "a", "b", "c" or "d"
I'd say you can still divide it to a, b, c and d parts, as long as removal of any one of the parts is prevented or noticeable.

For example, a summary record of e (all of the above) on a, b ,c and d means you can no longer delete and c and never know it existed.
Another way would be to reference for example this as being part 2 of 5. This would be similar to page numbers which can also denote wholeness or integrity of a document.

Taking it to the next level would involve test-suite setups, where later sections do not replace the previous one in an identifiable (e.g. part 2 under rev 1 to a different part 2 under revision 2) but take a unique place in an expansive set.
This is the core principle behind the often little understood practice of decadal (groups of ten) increments in manual maintenance of for example requirements documentation. This practice allow additions to the requirements set later on to still follow some imposed logical structure (for a little while). Else it could seem that a requirement has either transformed (replacement damages long-term integrity of directly referencing the requirement without the higher-level document identifier) or having a catch-all 'these all came later' numbered set of additional requirements at the end making reading and execution of protocols more difficult.

Sponsored Links

The time now is 04:23 AM. All times are GMT -4.
Your time zone can be changed in your UserCP --> Options.

Misc. Internal Links

NOTE: This forum uses "Cookies"