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.

One way to look at this issue is through how the PDCA cycle separates planning from execution. In the accompanying slides it states that the design inputs are the high level customer requirements for a product, while specifications are the measurable details such as dimension values and tolerances. Keeping these in separate documents reinforces the boundary between “what is needed” and “how it will be built.” When that boundary is clear, teams can evaluate user and market needs before locking themselves into engineering solutions.

Another important factor is how verification is structured. The lecture slides explains that verification is based on checking that each design input has a corresponding output. This process depends on being able to clearly trace requirements to specifications. When inputs and outputs are separated, reviewers can follow that trail more easily during audits or internal reviews. If everything were written together, it would be difficult to tell after a few iterations which statements in a document were requirements, and which were design responses to the requirements.

The slides also state that each design control element is generally documented separately, although some companies combine elements. This suggests that the FDA is more concerned with how the document is organized and what it contains than what it looks like. Conversely, if it is appropriate to maintain traceability, version control and review checkpoints, then a combination of a DID and a DSD may be preferable, though more effort may be involved in managing a single document.

A useful analogy is building a house. First, the homeowner explains what they want: number of rooms, layout, and budget. Then, engineers and architects turn those ideas into detailed blueprints with exact measurements and materials. If both steps were done in one document from the start, every change in preference would force major redesigns. Separating them makes the process more controlled and less costly.

This leaves open the question of whether, for small medical device teams with limited resources, a carefully structured hybrid document improve efficiency, or would it increase the risk of losing traceability during verification and validation?

I also have wondered why the design inputs and specifications are split into two documents. The Design Input Document falls under the planning phase of the PDCA cycle and focuses on user needs and intended use while the Design Specification Document begins to fall within the executing or “Do” phase and translates those user needs into measurable outputs. I believe the efficacy PDCA cycle would suffer if these two documents were combined because this may make the distinction between user needs (inputs) and design outputs unclear. Also, I think it’s important to separate the DID and DSD because they are typically compiled by different departments within a company. Marketing develops the DID with input from the project team, customers, and stakeholders while engineering or research takes the DID and defines a detailed specification for each design input. Another thing to note is there is a required document a design history file must have that already shows correlating design inputs and specifications. This document is called a design traceability matrix and maps the relationships between user needs, design outputs, risk management, and verification/validation testing. It ensures that each step of the design control process is traceable and that each design input was successfully met.

I think the main reason DID and DSD are kept separate is clarity and traceability. The DID defines what the device must do based on user, clinical, and regulatory needs. The DSD defines how the design meets those needs in technical, measurable terms. This separation helps avoid design solutions influencing or biasing the original requirements. This separation strengthens the process from a PDCA view. If an issue arises, teams can clearly and easily determine whether the problem came from a flawed requirement (DID) or an inadequate specification (DSD) which then makes corrective actions more effective.

Regarding FDA expectations, the FDA does not require specific document titles, but it does expect a clear distinction between design inputs and design outputs with traceability between them. Based on research, a combined document could be acceptable if this separation is maintained but in practice, separate documents are easier to audit and manage.

The DID focuses on what the product needs to achieve, capturing user needs, regulatory requirements. In contrast, the DSD explains how those needs will be met by translating inputs into measurable and detailed specifications. In my opinion, Keeping these documents separate helps prevent early design bias and allows teams to review inputs independently before locking in technical solutions. If both documents were combined, changes in design specifications could unintentionally alter original inputs, making traceability more difficult. This separation also supports risk management, since inputs can be evaluated and approved before detailed design decisions are finalized. Combining them into one document might reduce documentation volume, but it could weaken the structured feedback loops of the PDCA cycle.