Last time we opened our discussion on the Development stage of the systems engineering approach to medical device design and discovered that the best design concept is the one that meets all stakeholder requirements. Let’s use the flow chart shown in Figure 1 to illustrate what comes next in this stage.
Figure 1To begin the transformation from concept to completed design, engineers review documentation created during the Concept stage, including design notes, concept sketches, and of course the final requirements specification which has been approved by all stakeholders. Once the review is completed, it serves as a guide to the creation of detailed design documentation, including mechanical drawings, electrical schematics, and wiring diagrams. A bill of materials, or BOM, is also created, listing all parts needed to produce the final product. Each part designated within the BOM is associated with a specific manufacturer or supplying vendor, and each has been qualified with regard to price, availability, functionality, and quality. The design documentation and BOM are also subject to a review by a fresh set of eyes, engineers who have no involvement in the project. If they should discover a problem, the design is rejected and sent back to the design engineers for revision. This process of evaluation and correction are repeated until the design successfully passes a final review. Only then can the fully approved finished design move on to the production stage. Next time we’ll continue our discussion of the Development stage, moving our concept medical device further along its journey to the Production stage. ___________________________________________ |
Archive for December, 2012
Systems Engineering In Medical Device Design – Concept Evaluation
Monday, December 17th, 2012| How many times have you bought something and lugged it home, only to discover that it didn’t work as advertised? These days this scenario is all too common. Chances are it was developed haphazardly and rushed into production without adequate research and testing. A chief contributor to the product’s not living up to expectations is very often the result of a poor beginning. In its concept and development stages, design engineers failed to use a systems engineering approach.
Last time our discussion of the Concept stage of systems engineering identified stakeholder requirements as being of three basic types, serving the needs of functionality, performance, and constraint. Once identified, these requirements were incorporated into a detailed specification that is approved by all stakeholders involved, then used to devise alternate medical device concepts in order to really size things up. Let’s now move on to the Development stage of the design process to see how the alternate concepts are evaluated. The Development stage of the systems engineering approach to medical design begins with research and development of alternate device concepts. Stakeholder requirements as defined in the original product specification are used to guide the process, then mockups and prototypes of the alternate concepts are built, tested, and analyzed in view of the requirements. Considerations such as cost, ease of manufacture, operation, durability, and potential risk of harm to users are evaluated. As often happens, the best alternate concept satisfies all but a few of the specified requirements, resulting in a “good enough” scenario. That is to say, if stakeholders can agree the requirements not met aren’t all that important in the scheme of things, they may be willing to remove them from the specification, thus approving the concept for further development. If an agreement such as this cannot be reached, it may be necessary to return to the Concept stage and begin the entire process again. This re-evaluation of the process should result in a set of requirements that are further refined and from which better options in alternative concepts can be developed. Next time we’ll continue our discussion of the Development stage and see what it takes to finalize design and begin manufacture. ____________________________________________
|
Systems Engineering In Medical Device Design – Concept and Requirements
Monday, December 10th, 2012| Last time we introduced the first phase of the systems engineering approach to medical device design, the Concept Phase. It’s a phase which emphasizes clear communication between design engineers and stakeholders in the project. Effective communication results in clearly defined stakeholder requirements.
Stakeholder requirements are of three basic types, serving the needs of functionality, performance, and constraint. A functional requirement is a basic starting point, specifying the tasks to be accomplished by the system and its basic operation. For example, a medical diagnostic imaging device can be required to operate on a dedicated 15 amp branch circuit when plugged into a 115 volt wall outlet. Performance requirements delineate specific expectations as regards the system’s functionality, typically specifying parameters within which the system is to perform. For example, a medical device can be required to process a minimum number of test samples per hour. As for constraint requirements, they’re typically concerned with satisfactorily complying with both governmental regulations and industry standards. Governmental regulations include those established by the US Food and Drug Administration, as well as any applicable foreign agencies that may be involved should the medical device be introduced to other countries. Once the draft specification is written, design engineers review it in painstaking detail. Stakeholders’ requirements must all be accounted for and interpreted correctly. This is typically done by sitting down with each stakeholder and reviewing the draft. Finally, each stakeholder’s signature is obtained, signifying their approval. Now complete, the approved specification is used as a roadmap to guide project development through to the next and final step of the concept stage, devising alternate medical device concepts. Why discuss alternate concepts? Just like consumer comparison shopping for TVs and other goods, you’ve got to have a basis of comparison in order to make a sound judgment. This holds true for the medical device industry as well as private households. Next time we’ll proceed to the next stage of the design process, Development. We’ll see how alternate concepts are evaluated to find the best overall option, thus beginning the actual design process leading to manufacture. ____________________________________________
|
Systems Engineering In Medical Device Design – Concept and Communication
Monday, December 3rd, 2012| “Ask and you shall receive,” like “Make your thoughts known,” have the same objective, to initiate a dialogue between someone with a vision and those who can get the job done. In other words, if you don’t ask for it, you’re probably not going to get it, and the moving force behind it all is communication. Communication is as important in design engineering as it is in marriage.
Last time we learned that a system is a combination of interacting components organized to achieve one or more specific purposes and that communication is a key ingredient in the process. Now let’s see how the systems engineering approach is used within the medical device design process. The systems engineering approach consists of five key stages, the first being Concept. In this stage the objective is to identify all stakeholders, that is, those who have a stake in the outcome, then exhaustively define and capture their requirements. Crucial to this stage is a good line of communication between design engineers and stakeholders. This usually takes the form of brainstorming sessions in which all parties meet to toss around ideas. These ideas eventually solidify into design requirements. Once the design requirements are identified, they are incorporated into the first draft of a working specification. This specification will be written using plain English to minimize any potential misunderstandings. Within the specification each requirement is not only well defined, but traceable back to whoever proposed it. To this end, all requirements are listed in tandem with the names of stakeholders proposing them. Accountability is the main concern here. Next time we’ll talk more about these design requirements, and how they must serve the needs of functionality, performance, and constraint. ____________________________________________
|
