Design Output

We have covered Design Input in the last article and have established that Design Input consists of the requirements how the medical device should be. Its antagonist is Design Output, it describes how your medical device actually turned out to be. This is best described by the FDA definition in section 820.3 (g):?

?Design Output means the results of a design effort at each design phase and at the end of the total design effort. The finished Design Output is the basis for the device master record. The total finished Design Output consists of the device, its packaging and labelling, and the Device Master Record.“?

In essence everything, that is part of the design and development process and is relevant for the medical device, is part of the Design Output. To make this vast and ambiguous definition more tangible I will break it down in several subsections and examples for each category.

Dissecting the FDA definition of Design Output we end up with three very distinct types of documentation:?

1. Design Decisions?- Encompasses the research and decision-making aspect of the design process.?
2. Product & Production specification?- Anything defining the final device, how it will look, feel and function as well how the device is produced is part of this category.?
3. Integration & Test?- This category is all about proving that the design meets its requirements.?

Note that design planning activities do not fall under the Design Output definition and will be covered by a dedicated article.?

Utilising the V-model we can visualise in which phases the various different types of Design Output are created:

Each type of Design Output has, due to its nature, its own position along the V-Model:?

1. Design Decisions?

The essence of design is decision making. It starts right at the beginning with the project brief. What to include and what not is essential for the design. Going down the V-model decisions are everywhere, needs have to be decomposed, elaborated and defined. This includes trading of requirements against each other, as needs are not always compatible.?

In my opinion the quote is best understood as: There are no perfect solutions. Consequently, all solutions are trade-offs and our job as engineer is finding the best trade-off for all stakeholders. Getting the right balance is a crucial, but very complicated matter and should not be taken lightly.??

You are probably wondering ?If this is Design Output, where is the difference to Design Input?“. Well the Design Output in one stage is often part of the Design Input in subsequent stages. The relationship is best described by the image below:

The requirements are refined from sub-system requirements to component requirements. Both requirement sets are Design Input, but for different levels. The design output is how this refinement happens. This includes all the research and decision making.?

To provide a bit more clarity what the Design Output of this stage could look like I want to provide a few examples:?

• Research - like new technology scouting and trialling, IP-Freedom-to-Operate. Please do not confuse this with fundamental research or technology development! This is normally carried out unrelated to development projects and therefore is outside the scope of Design Controls.?
• Analysis documents - like Risk Analysis, Cybersecurity Analysis Fundamental to the decision making process is understanding the trade-offs. Risk document are an important key. If you really have to lower the severity of one risk this always involves a design change or excludes certain design solution from the available options.?

Analysis documents can also be investigation reports to determine how an alternative component impacts the system in case of an obsolescence or the need for a second source.

• System documents - like System Architecture, (sub-)system specifications, block diagrams, flowcharts. These decisions provide structure to the device and break it down to functional units. They also function as interface definitions for communication between development teams.??
• Decision matrices and processes – like decision tables. Whenever there is an important decision to take it has to be documented what the criteria and processes are that led to the final outcome. Different weightings for needs lead to different trade-offs.

2. Product & Production Specifications?

During the implementation phase the details of the device and how it shall be produced are fleshed out. This means creating specifications on which components have to be used, who can supply them, what they have to conform to, how they are assembled and so on. This phase stretches consumes to most time and effort. The decisions taken earlier on now need to be implemented and as always the devil is in the detail, so be prepared for some upsets along the road.

For a better structure the documents created during this phase can be subdivided in two distinct groups:

2.1 Product Specifications?

These documents define WHAT the component or assembly is. This can be achieved by either specifying which requirements the component has to fulfil (requirements controlled) or defining the supplier with order number (source controlled). As you can imagine in reality there is sometimes an overlap between these two.?

• Drawings (mechanical / electrical) - drawings define how the final part has to look like. It is a pure requirements control document, containing inspection dimensions and material specifications.?
• Component specifications - are generally used for third party components, either of the shelf or customized and should only list the requirements the product has to fulfil. Please don’t add purchasing information in this document.?
• Purchasing specifications - would only contain order relevant information e.g. manufacturer, order code etc. The advantage is changes to supplier information could have a lean and dedicated process instead of undergoing the full change procedure. This would only need to happen if the component specification itself needs to be modified.?
• Packaging and labelling specifications – labelling is a tricky and important aspect for medical devices and not only includes the packaging labelling but the Instructions for Use (IFU), website information, posters, advertising material, video material, an so on. As this information has to be technical accurate (otherwise you are in deep trouble if a patient gets hurt or ambiguous information is part of your advertising material) these documents are created in an interdisciplinary team consisting of R&D, RA, Legal, QA etc.?Packaging defines in which products the medical device can be transported and needs to be verified as part of the design output. There are various international standard like ISO 15378 that have to be met.

2.2. Production Specifications?

Compared to product specifications that define WHAT the part or assembly is production specifications define HOW the manufacturing process has to be carried out. I have to note that the FDA guideline uses a slightly different definition: “production specifications are documents used to procure components, fabricate, test, inspect, install, maintain, and service the device”. In my opinion splitting the categories provides a better understanding of what the documents intend to do.?

Nevertheless production specifications still cover a wide range of documents:?

• Operating procedures – These encompass every document directly used to manufacture, assembly or inspect parts and assemblies. This category also includes automated processes like CNC programs, PCB AOI tests or incoming inspection procedures.
• Process specifications - to ensure the manufacturing methods always produces parts with a consistent quality the settings of the process itself need to be defined. This can be environmental conditions like temperature and humidity ranges, but also additives (like cooling agents) used as well as machine parameters like pressure and hold time for injection moulding or temperature, cycle time for soldering processes.?
• Product acceptance specification - While the inspection criteria for a part or assembly are initially defined in drawings or part specifications it is important to make this information usable for production. The initial inspection criteria need to be combined with a sampling scheme and tied to a production process. The tests themself will be integrated in the operating procedures and can be carried out manually or automated by machines.?
• Installation and servicing procedures – depending on the medical device, installation can become a huge aspect of the manufacturing of a medical device, just think of the massive MRI or CT machines. The first time they are finally assembled and tested is at the customer's site. To ensure everything is set up correctly installation procedures are required often containing final checks the product runs as expected. Taking the long service life of MRI or CT machines into account, servicing is also an integral part in ensuring its safe and accurate functioning. Again, we are talking about procedures and test to document the due diligence of our company.?
• Packaging and labelling procedures – These documents quite simply tell staff how to apply the required labels (where and how) and how to carry out the packaging.

3. Integration & Test

While Verification & Validation is considered separate from Design Output a certain overlap exists. We have already seen with the Design Decisions that the boundaries between categories can blur.

Verification is all about demonstrating that the design meets the requirements and the official tests are carried out when there is a high confidence that the design is mature enough. It is quite risky to only test at the end of development activities, only to find out that some fundamental assumptions are wrong. Therefore testing should happen as early as possible, mostly with with prototypes and the results should be a constant feedback loop to the design team. This enables the engineers to find problems early on and influence the final design while it is still fluid.

As with the verification activities the prototype tests start on the implementation level and the systems under test get more and more complex with each level that is ?cleared“.

While at the first glance user interaction test seems like an exception that would start higher up in the V-model, they too have to build up the prototypes from the bottom up and the features will be integrated step by step into the final device. Especially early on a lot of modules and subsystems will create their prototypes in parallel, that over the design process need to be merged, user interfaces are no different.

Keeping the test results for the prototypes as part of the Design Output is important for me due to a range of reasons:

1. No confusion about the purpose of the tests. While verification has the intention to demonstrate conformance with requirements, prototype tests drive design decisions.
2. Prototype tests will and should not conform to the much tighter requirements for verification / validation activities. At this phase of the design process this would mean a huge administrative burden that hinders fast iterations. To be fair over the project these tests will get more sophisticated and resemble more and more verification tests.
3. Keeping the dataset close to the prototype, as the iterations should be as fast as possible, enables the traceability. Especially if questions arise in the future.
4. These test results should never remain mere data. They should be reviewed, analysed and used to find design solutions. Ideally in on prototype or integration test report that is discussed or created during a technical Design Review.

Further information about verification and validation can be found in the dedicated article.

Methods

As always, it is important to me to have a look at the various methods available to generate Design Output. As the spectrum of the Design Output is so broad, I had to subdivide this chapter in three sections, Idea Creation, Decision and Prototyping.?

Idea Creation?

The first section is about how to come up with new concepts and ideas. In the end we want to find solutions to the problems and needs our users have. It is important to adapt the methods to the environment (customers, team members, timeline etc.):?

• Brainstorming - this method was already used to determine user needs, now the focus is on the creation of concepts. The ideas can then be collected consolidated and rated. Central element is again the “No critique” principle while storming for ideas, encouraging everyone to come forward without judgement.?
• Bodystorming - The idea of this method is that the designers experience the environment in which the user would utilize the product and act out how it might function. This provides a better understanding of the users environment, the challenges and potential advantages. This can be done alone or with a group (potentially also users). Ideally new concepts are created on the spot that the designers can then implement and test as a prototype.?
• Co-Creation - This concept is based on the idea of introducing customer participation in the design process. It takes a step further than Bodystorming in the sense that the designers collaborate with the users or the users start to be designers. A good example for the latter is open source software. Normally users are not so much integrated, but are part of the development team by providing feedback and ideas from the get-go.?
• Analogies - The concept of this method is transferring the meaning of one subject onto another. The idea is by projecting the idea onto another element the problem can be solved with already existing solutions. The best example is bionics, where biological methods or systems are mimicked by technological solutions. The most prominent and widely used example is Velcro, that was developed on the hooks of buds. When it comes to mechanics FESTO has some great examples, my personal favourite is the handling assistant based on the functioning of an Elephant trunk.?
• Gamification - As you can probably imagine this method tries to change the viewpoint of the developers and coins the problem in form of a game. The two principles that help the most in the problem solving setting are competition and fun. Both have an intrinsic reward structure. The first can be some spurt of Hackathon or design challenge in which several teams compete against each other with limited resources.?The second can utilize elements like Lego to introduce the game like character to design. By utilizing systems that are ingrained in the emotional memory of the designers as ”game” and ”fun” these emotions are projected onto the design problem itself.?
• Idea Clustering - In order?to find new solutions the existing ideas are categories and “blank” fields are identified and the idea creation can focus on these areas to come up with unconventional solutions.

Decisions?

Now that we have created loads of good ideas we need to decide which ones we take foreword and create prototypes with and which we discard or leave for later.

• 2x2 Matrix - The idea of this graphical representation is to show the relationship between two factors. Most commonly used is impact vs. effort but also other aspects like performance vs. cost can be of interest. You will end up with all of your solutions distributed along the graph and you can use this visualization to guide your the decisions what to prioritize.?
• Design Structure / Impact Matrix?-?Complex systems are often hard to handle and the interactions are complex and hard to keep track of. The impact matrix visualizes the relationships between the components. Each of the axis lists the systems components and each cell contains information about their interaction (no interaction, unidirectional, bidirectional). Each component then receives a score how many other parts it is interacting with, and therefore how crucial it is to the design. If the system is very large this needs to be handled on sub-system level, with each of the sub-systems again having their own matrix.?
• Weight Decision Matrix -?The best way to make a decision transparent is by defining how valuable each criteria is. This is done by assigning a weight and then rating, e.g. on a scale of?1-5, each solution against all the criteria. The score for each criteria by its weight. Depending if a linear or non-linear scale are used for the weights some criteria become much more important than others. In the end there should always be a plausibility check to test for “bad” weigh distribution.?

Prototyping?

The first step in prototyping is to decide what you want to achieve. The idea behind a prototype is to give the user a feel for the finished device without actually developing or building the product. Therefore, the system has to be reduced in its complexity:?

• Proof-of-principle prototype - only the core functionality of the product is implemented and is often used in the early stages of development to determine feasibility of an idea.?
• Visual prototype – gives an impression of size, appearance and texture, but not the functionality or performance, of the intended design. This can consist from cardboard structures to provide size references and colour / texture samples to prototypes with final surface finish.?
• Functional prototype - while only surfaces and appearances were relevant for the visual prototype, the opposite is true for functional prototypes. The most basic version of functional prototypes are block models to demonstrate functionality without any consideration of the appearance. On the other hand functional prototypes can also be realized with different technologies, with the aim of testing e.g. user interaction.??
• Working prototype - is nearly the opposite of a proof of principle prototype. Late in the development is includes all or nearly all of the functionality of the final product and is often used for verification or test preparation.??

In reality the prototypes will not fall into clear categories, but will be a combination. If management wants to see the state of the project the prototype will be the latest stage and somewhere between a n Proof-of-principle and working prototype. User testing will also need visual and functional prototypes, depending on the situation and these might even be used in the same machine.

I’m a huge fan of creating prototypes as soon as possible. They are an amazing way of validating requirements, trialling concepts, communicating the state of design and much more.??

Depending on the discipline and production methods the prototyping techniques that can be used vary a lot. In the following I want to provide a few suggestions:?

Proof-of-principle prototype?

When creating proof-of-principle prototypes the idea is to create the core functionality with the minimal effort possible to test if the concept is feasible and provides value to the user.??

Luckily out of the box solutions in the shape of development boards exist. Development Kits like Arduino boards or a RasberryPi provide an amazing set and library of functionalities. They are to expensive for mass production, but ideal for small scale development. Combined with breadboards and further electronic components, extending the capabilities even further, they provide the much needed flexibility and adaptability.?

For software the Wizard of Oz technique is an excellent method to establish user needs and test interaction principles. The user interacts with a crude interface, but the functionality of it is actually provided by the ”wizard” and is only implemented if deemed desirable after the test.?

Examples methods are:?

• Development Kits / Shields?
• Breadboard / Stripboard / Perfboard?
• Wizard of Oz technique?

Visual prototype??

The simplest way of creating prototypes is just grab a bit of paper, sticking tape and glue and get going. You can colour it to represent features or interfaces. If the prototypes have to bigger / sturdier cardboard or plywood is an excellent option. Again colouring can provide additional information.?

If more details are required simulation or virtual models e.g. CAD models are good tools to communicate information. Via the model size, geometry, colour, texture and much can be discussed and agreed. For larger system it is advised to create architecture documents to create structure and then create concepts for the modules instead of trying the whole problem at once.?

Wireframes are a 2D sketch / outline of a user interface. As it is early in the process it is often scratched on paper and quite basic and not styling is applied. Again the idea is to get more information about the way users would interact with the system and will provide further input for the design process.?

System architectures or frameworks could be considered visual prototypes. They convey design information to other stakeholders and the proposal can be discussed before trialling it.?

Methods mentioned:?

• Paper / Cardboard / Plywood??
• Simulation / Virtual methods (e.g. CAD Models)??
• Wireframing??
• System Architecture / Framework?

?Functional prototype??

Compared to visual or proof-of-principle prototypes functional prototypes?require more detail on the technical aspects. To create more complex mechanical features 3D printing methods or CNC machining can be utilised. Be sure to always consider the limitations of the various techniques in mind. If you want to create gears go for milling as 3D print will probably break. On the other hand if complex surface geometry is required 3D print is ideal. For both you can easily find service suppliers online.?

The same goes for custom PCBs, online services make possible what you cannot do on your own. After tackling the technical questions with breadboards and developer kits it’s now time to take the next step towards the final design. Selecting the right components and creating functional elements is a crucial step. The current version will not encompass all functions and will improve with each iteration.?

At this stage it is important not to over-complicate matters and it might be advisable to test every feature on its own. This could even mean splitting up parts that contain several elements. As the design develops these features are step-by-step integrated to the final version of the part. But for now it is more important to carry out as many design iterations as possible, to weed out bad features, even if that means the test results are not representative of the final design.?

Software / firmware has an especially tricky role to play. As the prototypes get created they are not yet with the final components / design in mind. This means the software / firmware is also not scalable and might need to be recreated with each iteration. It is important to find the tricky balance between re-usability, effort and functionality of the prototype.??

Examples:?

• CNC?
• 3D Print?
• Custom PCBs?
• Throw away prototyping (SW)?

?Working prototype?

Well last we reach the working prototype. As we are getting closer to the final design the production methods converge too. You will still find custom PCBs, CNC machining etc. but they will be more refined and detailed. Features that were before split in several components are now combined and tested as a whole.?

More complex production methods with longer lead times can now be explored to get a more realistic prototype design. While before the principle was “Fail fast, fail often” it is now important to generate real data. In the end our goal is to pass verification and it is important to get an early benchmark of the design maturity.?

Vacuum casting is a good and alternative to injection moulding, with much less capital investment. For metal parts investment casting combined with a 3D printed wax prototype is a good substitute for more expensive mounds. Combining production methods, e.g. via a 3D. printed body and milled functional elements might also be a good alternative to keep costs down.?

Software will again be a tricky part. In the functional prototype a lot of component dedicated software will need to be replaced with the final software units. This means keeping track which elements were meant to stay, updated or removed. As you can imagine traceability is therefore an essential element in the prototypes development from a functional to a working prototype.?

• Custom PCBs?
• CNC?
• Vacuum casting?
• Investment casting + 3D printed wax prototype?
• Incremental prototyping (SW)?
• Evolutionary prototyping (SW)

Systems:?

We have seen how many different documents are part of Design Output which results in a vast variety of systems that are used to create it. To keep this section somewhat concise I have taken the following decisions:?

1. Exclusion of content creation system. Depending on your discipline you have to find the system that you are most comfortable with. There is no one-size-fits-all solution covering mechanical, electrical and software.?
2. Focus on Content Management systems – The big challenge with Design Output is how it is stored and accessible for the project team.??
3. Traceability to Design Input and verification is a huge plus, but can also be covered by the Requirements management systems.?

When selecting the right system there are some ground rules:?

1. Keep it simple - if you only use CAD data go for a PDM (Product Data Management) system or in case of a pure software products, something like GitHub could be sufficient. ?
2. Whatever you select make sure you control your native files appropriately.?I have to advise against using only a pure?document management systems like?MasterControl or SharePoint. They can handle the PDFs of the drawings, but not the CAD files, which means your actual design is probably saved on a drive and not version controlled.??
3. If you have a complex device with software, electronics and mechanics you will need a more sophisticated tool, but don’t leave it up to the engineers to play system administrators in their free time. These systems need proper maintenance (like any major company system) and should have dedicated staff maintaining and administering the software.?

I have to admit I’m a huge fan of systems that allow cross departmental, integrated workflows, as design never happens just in one place. The drawback is, as already mentioned, the complexity of the tools. Nevertheless if you are are looking I would advise to choose either an ALM or PLM:?

• PLM (Product-Lifecycle-Management) - The goal of a PLM is to centralise and streamline all product relevant information from design to production, service and decommission. As you can imagine this involves a huge number of disciplines and integrations with other services and software. Examples are ERP, MES, CAD etc.?
• ALM (Application-Lifecycle-Management) - An element is a PLM but dedicated for software and therefore has a few variations in its content. For example test and defect management is often included in the environment to enable fast development cycles.?

?

When selecting an ALM/PLM there are several element the system should encompass to be able to handle the Design Output and ideally trace to Design Input:?

• Document Management - You will want to store your part specifications, architecture documents, analysis and design decision in the same location as your CAD or code.?
• Product Data Management - well that's your CAD or code?
• Change Management – Design is always fluid and will undergo changes during development, you should therefore have a process ready and implemented in your system.?
• Reporting - you will want to know where a certain part, material etc. is used, so reporting is a pretty central element.?
• Requirements & Risk Management - Risk management is part of the Design Output and normally comes with a requirements management module. The latter is optional, but it makes traceability much easier if you can link your Design Input to the parts, assemblies or software units.?

?

I have also provided an additional list with features that are nice to have:?

• Configuration Management - If you have variants of your medical device this will help you handle the complexity. ?
• Test management - having you prototype test data easily available and linked to the baseline is very helpful, but not a must. Another plus is that traceability to Verification and Validation activities is possible.?
• Manufacturing Data and Process management – This is a huge plus, but can (depending on the production processes) also be covered with Word / PDF files in the document management module.?
• Supplier / Cost management - If you have your component information already in the system, why not add purchasing data to speed up communication.?
• Project management - Well you will always need project management capabilities and having them in the same spot as your project documents makes life easier.?
• Compliance management - As you probably found out, a lot of the nice to haves add further disciplines to the system to facilitate workstreams, in this case it is Regulatory Affairs.?
• Quality management - As quite a lot of quality processes need to be implemented in the system to fulfil the required functions above it might be opportune to fully integrate quality management in the application.?

?

I have reviewed ALM and PLM systems available and selected two each for a short presentation:?

Windchill PLM by PTC:??

Windchill PLM module covers everything from collaboration, traceability, reports, to change management, integration (ALMs & PLMs) and much more. It is even possible to use it with PTCs medical device specific, pre-validated environment called “Windchill Product Quality”.???

Windchills strength is the all-in-one approach, with the idea that you can start with Ideation and document everything from development, production to service without having to leave the system. You can find an over-view of the possible Windchill add-ons?here.?

?

Teamcenter by Siemens?

Teamcenter is a powerful PLM developed by Siemens and as Windchill has everything you could possible want. Valuable for the medical device development is its sophisticated quality management module with which you can coordinate projects, processes and build excellent traceability in one go.?

If you want to find out more I can recommend its YouTube channel or one of the many webinars available.?

?

Polarion?ALM by Siemens??

Teamcenters twin Polarion?is an ALM developed by Siemens and has everything one could want, audits, reports, change management, issue and defect management, project management and much more.?

The difference to Teamcenter is the focus of the system. While a PLM has physical models in mind and therefore covers CAD and production aspects, Polarion integrates aspects like testing, defect management and traceability to software units.?

For more information I can recommend the excellent?YouTube channel.?

?Jama Connect by Jama?

Developed around?requirements?& risk?management as well as testing?JAMA offers a robust and easy to use ALM. It's strength is a high flexibility through its various integrations with 3rd party applications. In addition it has all the standard features like reports, project management and much more.?

For more information check out Jamas?YoutTube channel.

Sources?

• FDA CFR 21 §820.30?
• FDA Design Controls Guidance?
• ISO 13485:2016?
• Greenligth Guru?
• Methodische Entwicklung technischer Produkte (ISBN-13: 978-3-642-01423-9)