There will always be some form of change control as long as these documents are not in a "draft" state. If the document has a revision associated with it, any and all changes will go through change control, no matter how insignificant it may seem. This makes sense because every change needs to be assessed from every perspective. Every change has the ability to affect each and every department individually. For example, changing the text on the label on a product may have no effect on the manufacturing process itself, but it could severely affect quality and regulatory. Every change needs to be looked at and its impact needs to be assessed by every department.

However, company practices ultimately dictate exactly how robust change control needs to be depending on the type of error. For example a typo on a word ("nad" instead of "and") can be relatively harmless and the person initiating the change may not need the approval of every single department in the company to get it through change control. But changes that are made directly on the product are more than likely going to need the signatures of every department associated with that particular device.

When it comes to significant errors found in design input documents (DID) or design specification documents (DSD), several steps are often taken to rectify the error. First, the error must be identified. Then a change request (to fix the error) must be initiated, a document that describes the error at hand while also explaining why the change is needed and how the change would be implemented. Next, relevant stakeholders such as project managers and quality assurance (QA) personnel review and approve the request. Lastly, the change is officially implemented and an updated document is created that ensures that the change is documented accurately and meets the objective it was intended for. 

These steps ensure that a change is accurately identified and ensures that it is accurately rectifying the error identified. However, these steps are for errors that are more large scale, such as a change in material or such. Any minute errors seen in the documentation do not go through these extensive steps. 

This is sort of off topic of correcting specific documents such as DSD and DID but I wanted to mention the practices in Good Laboratory Practices (GLP) regarding data collection. In GLP, when errors occur during data collection there is a specific protocol for correction. Instead of eraring or replacing data sheets, the standard is to cross out the error and provide clarification alongside the correction. This method often seems redundant, yet it ensures the accuracy of presented data while maintaing integrity displaying all corrections made.

In the context of document control and management, when errors or changes are identified in documents like Device Master Record (DMR) or Device History Record (DHR), the typical practice is to initiate a change control process rather than a change request. The change control process involves a systematic approach to manage changes to documents, procedures, or other elements of a quality management system.

Here's a general overview of the process:

1. Identification of Change: When an error or a need for a change is identified in a document, it is documented, and the change is clearly defined.

2. Documentation: The details of the change, including the reason for the change and its potential impact, are documented.

3. Initiation of Change Control: A formal change control process is initiated. This process may involve issuing a Change Control form or document, depending on the organization's procedures.

4. Evaluation and Impact Assessment: The change is evaluated to determine its impact on the quality management system, regulatory compliance, and other relevant factors.

5. Approval: The proposed change is reviewed and approved by relevant stakeholders, which may include quality assurance, regulatory affairs, and other relevant departments.

6. Implementation: Once approved, the change is implemented in the affected documents or processes.

7. Verification: The implemented change is verified to ensure it was carried out correctly and has the desired effect.

8. Closure: The change control process is closed, and documentation is updated to reflect the approved changes.

By following a formal change control process, organizations ensure that changes are managed in a controlled and systematic manner, reducing the risk of introducing errors or issues during the change process. It provides a structured approach to maintaining document integrity and regulatory compliance.

@vthampi I would like to add to this by mentioning how even a small thing such as a misspelling, or even something as miniscule as missing an (s) at the end of a word will almost always be adjusted using some kind of change control. Where I work, there are some documents that aren't updated for years, then once a change occurs (either for adding an additional line in the SOP, or something to the appendix) it is interesting to check the redlines (changes from the previous revision to the newest revision) to see some things that may have been glanced over. Sometime it'll just be the renaming of the component (the main reason for a change control for example), and sometimes there will be two words in a 50 page SOP that didn't have a space between them, and that is all that is adjusted in addition to the original change. I don't know how it works at other companies, but I believe all departments that were required for signing off on a change notice previously or DID/DSD, will have to sign off again and ensure there is no skipping of signatures, regardless of how minor the error may be. If in a drafted form (revision 1 or Alpha) that hasn't been fully approved yet, I think it definitely makes sense to have frequent meetings discussing the state of the document and ensure not only grammar, but content is all accurate. From there, there is no need to do a formal change control until the document is officially released.

Yes, every little change needs to be documented. This might seem tedious, but it is very important for traceability. There are a lot of different systems used to accomplish this. Usually, you will need to have a number of people sign off on your changes as well. Before, the document is then routed. 

Issuing a Design Change Request is the normal remedial action when problems are found in design documents, such as the Design Input Document (DID) or the Design Specification Document (DSD). This procedure starts with locating the mistake and ends with creating a suggested modification. After that, the modification request is formally submitted for evaluation, and its effects on the product's performance, design, and compliance are carefully assessed. Once approved, the revisions are applied, documented, and included into the current documentation. For traceability purposes, all changes are kept track of in the Design History File (DHF). This process guarantees that any changes made to the design documentation are methodical, regulated, and compliant with legal requirements. This is especially important in sectors like medical devices where precision and compliance are paramount. On the other hand, some organizations may allow for non-critical errors to be correct with a small annotation, or for certain errors to be corrected with an addendum.

Initiating document releases and revisions are a crucial part of an effective quality management of any device. In fact, there is a cycle that every document goes through which includes its creation, review, release approval, distribute training, use, and if withdrawal occurs, it goes back to the first stage. To ensure that there are no errors within the document, review sessions should be made to ensure that it conforms to the requirements and any mistakes are caught early on. But this is not the case in industry so there needs to be changes made once the document is released so a change request is initiated. 

This is the job for quality engineers. They have to ensure that document is release process and change request is efficient and effective because if they are not it can lead to unnecessary waiting, lack of step in which the team does not wait and simply continues working, and most importantly the regulatory risks. Inefficient document releases and change requests can shut down your entire team so effective review and process should be established to make a good quality product. 

It can be easily argued that a change notice is required for every proposed change to any document. It is a good practice for several reasons. It ensures that everyone is dealing with changes in the same way, and allows for order and organization. These change notices usually require the approval of several people. Although it may be tedious and overbearing to keep track of each person's approval, this is an important step. For a minor change to a document, an approving person may discourage the change the notice and say it is not needed for this point in time. Not that the change is made anyways, but rather the change is not needed at all, for whatever reasons. This may be helpful because the whole process is avoided and attention is channeled into another task. Also, these approving people provide insight into other corrections that may be made. This acts as a preliminary document control, before the document reaches the "real" document control. Documents are used company wide, and it is important that changes are made and implemented for everyone. Any disconnect can cause one part of the company to operate one way, and another part another way. This is shows a lack of attention to detail and overall lack of quality. If the documents cannot be set straight, how about the processes that the documents dictate?