Below are the reasons or purpose not to combine two documents ( DID and DSD ) to make a single document. 

1)Progressive Detailing: The DID serves as a high-level foundation, capturing user needs, regulatory requirements, and functional expectations. The DSD refines these inputs into technical specifications. Keeping them separate allows flexibility in refining inputs before committing to detailed specifications.

2)Iterative Development in the PDCA Cycle: The Plan-Do-Check-Act (PDCA) cycle benefits from iteration. By having a separate DID, teams can ensure they fully understand user needs before diving into technical specifications. If both were combined, updating the document mid-cycle might introduce confusion and inefficiencies.

3)Stakeholder Involvement: The DID often involves broader stakeholder input (marketing, regulatory, clinical teams), while the DSD is more engineering-focused. A single document might dilute focus or make it harder to keep track of relevant changes.

Yes the efficacy of the PDCA cycle would  suffer if the DID and DSD is combined.

The PDCA cycle relies on continuous refinement and improvement. If inputs and specifications are combined too early, it may lead to premature design commitments, reducing the ability to adapt as new information arises. Additionally, changes in inputs might require constant revision of specifications, making version control and traceability more complex.

The FDA has no strict rules as to keep them separate. 

The FDA’s Design Control Guidance (21 CFR 820.30) does not explicitly mandate separate DID and DSD documents, but it does emphasize traceability between design inputs and outputs.

• Combining them could create a documentation burden, requiring more justification and potential scrutiny from regulatory bodies.
• A combined document may make it harder to balance stakeholder input with technical feasibility.
• Changes to inputs may require immediate updates to specifications, increasing document maintenance effort.
• If a single document can demonstrate clear traceability, logical progression from inputs to specifications, and maintain design control rigor, it might be feasible.

Ref: https://c3mdc.com/blog/all-about-user-needs-design-input-requirements-getting-your-product-where-you-want-it/
https://www.greenlight.guru/blog/decoding-design-inputs-and-design-outputs#:~:text=Design%20input%20is%20the%20starting,most%20important%20design%20control%20activity.

Great points! I also think that a hybrid approach could be a strong alternative that could maintain the clarity of separate documents while still improving efficiency. Instead of two entirely different documents, companies could use a linked document system where the DID serves as the top-level summary and the DSD serves as an evolving appendix. Following this structure would allow for traceability without any redundancy and ensure that updates to design inputs are directly linked to evolving specifications without the need for excessive documentation maintenance. 

While the FDA does not mandate separate documents, it does put a strong emphasis on design traceability. A well-structured hybrid document could meet regulatory requirements if it clearly distinguishes between high-level design inputs and detailed specs while ensuring controlled updates. 

Keeping the Design Input Document (DID) and Design Specification Document (DSD) separate helps ensure a smooth development process by allowing flexibility and better organization. The DID acts as a foundation, outlining what the product needs to achieve, such as a medical device that must withstand repeated sterilization. The DSD, on the other hand, translates these needs into precise engineering details, like specifying that the device casing should be made of a material that can endure 50 autoclave cycles without degradation. If both documents were combined, any changes in user needs could require immediate updates to technical specifications, making the process more complex and harder to manage.

Another reason for keeping them separate is to involve the right stakeholders at the right time. Marketing and regulatory teams may contribute to the DID by defining requirements like usability and compliance, while engineers and designers focus on translating those into exact specifications in the DSD. For example, if a new safety requirement arises, it can be assessed at the DID level first before making technical modifications in the DSD. This separation prevents premature design decisions and allows for structured updates, ensuring that the development process remains flexible and traceable

The Design Input Document (DID) outlines the user needs, regulatory requirements, and functional expectations for a medical device. It serves as the foundation for the design process, ensuring that all critical aspects such as safety, usability, and performance are considered. The Design Specification Document (DSD) translates these inputs into detailed technical requirements, including materials, dimensions, software specifications, and testing criteria. While the DID focuses on "what" the device should achieve, the DSD defines "how" it will be implemented. Maintaining clear traceability between these documents ensures compliance with regulatory standards like FDA and ISO 13485. Together, the DID and DSD play a crucial role in guiding the development, verification, and validation of a safe and effective medical device.

The Design Input Document (DID) and Design Specification Document (DSD) are both very important elements of the PDCA (Plan-Do-Check-Act) cycle, but it has an underlying reason for maintaining them separately. The DID records the general requirements and expectations of the product, so that the requirements of all the stakeholders, together with the relevant regulatory standards, are covered. The DSD, on the other hand, takes these inputs and makes them technical specifications, providing detailed steps for development.

Merging these two documents together seems an efficient means of finishing it, but it actually muddles issues. A single document becomes too bulky and unmanageable, so it becomes harder to distinguish what the product has to achieve from how it gets produced. Also, the PDCA cycle is predicated upon being able to change one's mind—by keeping these documents separate, it allows one to iterate over the specifications if need be, without repeatedly editing the original requirements.

From an FDA compliance perspective, structuring documents are necessary toward complying with Design Control regulations (21 CFR 820.30), whereby traceability has to be transparent from inputs through outputs. Redesigning the process would require proof that an aggregation of documents adds to compliance, an improbability.