expandable medtech whitepaper medtech whitepaper ... (mrd) and product (prd), ... these documents...
TRANSCRIPT
EXPANDABLE SOFTWARE, INC. 900 LAFAYETTE ST., SUITE 400 SANTA CLARA, CA 95050 1-800-680-6050 WWW.EXPANDABLE.COM
EXPANDABLE MEDTECH WHITEPAPER
Quality Management for Startup Medtech Companies: Design and
Documentation Controls
Expandable Software, Inc.
by Dennis Payton - Executive Director of Product MarketingExpandable Software, Inc.
33
3
4
5
5
6
6
8
8
8
9
9
11
12
13
14
14
161617171818
WHITE PAPER Page 2Medtech Design and Documentation Controls
Page 2 Expandable Medtech
Table of ContentsExecutive SummaryFDA Regulation of Medical Device Design and Documentation Controls
US Law and Regulation
Interpreting the FDA View of Design Controls
Key Points of an FDA View of Regulation for Design and Development Model
Developing an End-to-end Product Design and Development Model
Product Design Model with Widening Market Exposure in Process
Basic Generalized Product Development Process Model
Managing the Product Lifecycle
General Cradle to Grave Product Lifecycle
Generalized Product Lifecycle Model
Design, Production and Documentation Control Tools
Key Production and Change Control – ERP/MRP Systems
Key Design Control and Product Lifecycle Management – PLM Systems
End-to-end Control for Product/Item Lifecycle Management
PLM Product Design Release to Production ERP Integration
Key Documentation and Quality Management – QMS Platforms
Document Management and Training Process Flow
SummaryReferencesAbout the AuthorAbout Expandable Software, Inc.Arena Solutions, Inc.AssurX, Inc.
DisclaimerThis brief contains an interpretation by Expandable Software, Inc. of FDA regulation.
The document is intended to be informative and not binding on Expandable Software, Inc. Any
detailed inquiries regarding the
• Pure Food and Drug Act of 1906
• Food Drug and Cosmetic Act of 1938
• FDA or CDRH Regulations
• FDA or CDRH Guidance
should be directed to the relevant governmental agencies responsible for enforcing the laws and
regulations in these areas.
WHITE PAPER Page 3Medtech Design and Documentation Controls
Page 3 Expandable Medtech
Executive Summary
Some of the shortest descriptions in the FDA CFR 21 Part 820 Quality System regulation are found in
Sec. 820.30 and Sec. 820.40, totaling about a page of written language around Design Controls and
Document Controls. However short, these two sections can be the most complex aspects of Medical
Device controls when actually complying with the regulation.
Fortunately the FDA does give a bit more background to help a new Medical Device Company
understand these two key elements (see Medical Device Quality Systems Manual, A Small Entity
Compliance Guide). With the detailed complexities, even those few pages of guidance (covered in
section 9 Document and Change Control) fall short of providing the coverage needed to understand
their impact on a company’s Medical Device Quality System.
The good news is there are some very good tools that can help mitigate the complexities and
streamline controls. The bad news is that it still takes a very strong detailed and sustained effort to
insure complex controls are in place for continued success and compliance with regulation.
The objective of this brief is to shed a little light on how the FDA views Design Controls and associated
Documentation Control, as well as to provide a high level view of enterprise level software options that
can help alleviate some of the pain in developing and implementing control processes.
With over 25% of FDA issues related to Design Controls, any FDA-regulated business should maintain
a highly focused effort toward capturing design detail, getting approvals, archiving historical design/
design changes and procedural documentation and making sure that it is done with a high level of
collaboration for all stake holders while maintaining rigorous compliance audits.
FDA Regulation of Medical Device Design and Documentation Controls
US Law and Regulation
The two Acts of Congress that provide the basis and framework for the FDA to define and produce
regulation for Medical Devices in the US are:
• Pure Food and Drug Act of 1906
• Food Drug and Cosmetic Act of 1938
A key Medical Device regulation derived from these Acts is the Medical Device Quality System
CFR 21 Part 820 that defines two specific areas:
• Design Control (Subsection 820.30)
• Document Control (Subsection 820.40)
WHITE PAPER Page 4Medtech Design and Documentation Controls
Page 4 Expandable Medtech
These subsections combined provide a whopping single page of written regulation and can pack
a wallop to a Medical Device’s success or non-success in complying with regulation for the U.S.
marketplace. When the FDA crunched the numbers, they found that 25% of the Medical Device issues
were centered on Quality System compliance, with... wait for it…“Design Controls” by far being the
leader in issues recorded by the FDA with devices in the market (circa August 2011).
So there is no doubt that the two smallest sections of the Medical Device Quality System regulation
have a significant impact on design, development and bringing a medical device to market with
compliance.
Interpreting the FDA View of Design Controls
With a wide variety of Medical Device suppliers there comes a wide variety of processes, procedures
and controls that are developed specific to a business and to the Medical Device(s) being produced. It
is important to understand how the FDA tries to normalize a specific business to the regulation when
auditing that business for Design Control compliance. Having a bit of understanding of their view will
help make for a much smoother comparison, analogy and a much cleaner and successful audit of a
company’s design processes.
A simplistic model can be derived from the 820.30 regulation that the FDA may use to assure design
coverage and compliance of a device design and/or manufacture to the regulation. The design and
development model can be graphically depicted and loosely linked to the regulation as follows:
Figure 1
WHITE PAPER Page 5Medtech Design and Documentation Controls
Page 5 Expandable Medtech
Key Points of an FDA View of Regulation for Design and Development Model
1. Ensure that there is a logical design and development process flow with well-defined review
stages, gates and/or checkpoints.
• Allow for documented design reviews by key cross functional teams
• Remember that most designs are “living designs” and that change management needs to
be accounted for and built into the process
2. Design reviews should be continually verified against the original design intent with adjustments to
assure an ongoing high level of quality.
3. Final product should also have specific validation against the market/user needs to assure
addressing the market needs while maintaining high quality and high level of public safety.
4. Considering that each stage can have associated documentation, each review can have a
review document, each verification cycle and validation cycle can have its own supporting
documentation:
• All the documents generated throughout the process must be controlled for version,
approvals, communication and training
• Each document associated with a given design (including obsolete, historical, active,
archived, etc.) becomes part of the Design History of that device including not just
the design files (CAD, Electronic Schematics, Source Code, Production Assembly, etc.)
but also the documented review results, QA results, design input documents (market
requirements [MRD], product requirements, design requirements) and other device-related
documentation
Again, like the FDA regulation on Design Controls, this is a very short summary of complex processes,
document definitions, controls and general management and approvals about which volumes of
books have been written. The objective should be to have a very good understanding of how the FDA
or other regulatory entity views the Medical Device controls such that a business can demonstrate
how their particular controls map into the regulatory model. A logical analogy of a company’s design
and development model should be able to map to the regulatory normalized base line model(s), and
in doing so, will result in smoother audits with a higher degree of success and hopefully less time and
expense in managing through the audit process (something the regulatory folks don’t really care about
but as a business we all do).
Developing an End-to-End Product Design & Development Model
Most product managers will view products from two perspectives while developing and managing a
product physically to market, here we are only focusing on the concept to market physical side (there
are of course all the other product management pieces: pricing, market sizing, selling points, etc. that
are equally important but of no concern to the regulatory agencies that are mainly focused on the
public safety of devices rather than the financial business side):
1. PDP – Product Development Process
2. PLC – Product Lifecycle management
WHITE PAPER Page 6Medtech Design and Documentation Controls
Page 6 Expandable Medtech
These two aspects are key to the regulatory agents in assuring there are controls for the development
and maintenance of devices from cradle to grave. For most any industry this is probably not a surprise
as most modern quality management systems, whether industry driven or government regulated,
require design controls for both the development process and managing changes over the life of the
product(s). The objective here is to present a general model for each of these processes and discuss
key points to be aware of when developing these models specific to a Medtech business or product
development process aligned with the regulator’s normalized baseline design and documentation
perspective.
Product Design Model with Widening Market Exposure in Process
A generalized PDP model this author has developed over the years among various businesses not
only captures the development stages but also depicts an ever-widening product exposure as the
development matures throughout the process. In this general model, the process is broken into stages
where each stage is reviewed not only for design intent for regulatory needs but also for marketing
and business validity (as we need to ensure running a business that meets its financial objectives as
well as meeting the obligations of the regulatory environments) before moving to the next stage.
One can see that this particular model is easily mapped to the FDA normalized regulatory perspective
by adding a few steps. Also as a design progresses to a fully released product one should attempt to
limit the exposure in the early stages and provide an ever increasing product exposure until formally
released to the market.
An important item to note is the initial stage of definition; make sure all functions of the business
have input to the design requirements; both market (MRD) and product (PRD), and acknowledge that
these documents are living documents throughout the process and therefore need to be controlled
requirement documents. Upon kicking off or starting a project the initial exposure of the product is
restricted to Management and Design Engineering for design and development. Then, as the design
matures, exposure to other critical functions is widened for verification, validation and finally full
exposure across all business functions, including regulatory approvals, when made generally available
to the market. Finally once a project is complete all the associated support documents throughout the
process need to be archived and retrievable in support for each product as a complete design history
detailing any changes that are required to maintain the product in the market.
Basic Generalized Product Development Process ModelCross-functional and market exposure modeled against the project schedule over time for each phase
of the development process would look something like the figure below.
WHITE PAPER Page 7Medtech Design and Documentation Controls
Page 7 Expandable Medtech
Each stage should be a cross-functional review at various points in the development process to
assure the product meets the intended market requirements and is technically feasible, supportable,
marketable and demand creating. Initially, inbound marketing and engineering are heavily involved as
the business cases and technology are proven out. As the evolution of the project heads toward the
market, support and sales take the lead as inbound marketing and engineering resources wind down
in order to take on other new projects including any needed changes to existing product lifecycles
already in the marketplace.
This diagram doesn’t detail out any iterative design and reviews that may occur within the stages or
throughout the process, as it would clutter up the flow and discussion, but a full PDP will need to
detail out each of the stages, define product PDP status (definitions of product in development, alpha,
beta, clinical trial, approved for market(s), etc.), define relevant review documentation and detail out
gating requirements throughout the design of the development process.
In summary, the key points are:
1. Build in initial cross-functional design input up front in the development process before kickoff
and checkpoints for cross-functional review for both market and business needs, at logical stages
of the PDP process before moving to the next development stage.
2. Be sure a logical analogy can be made to the FDA’s normalized view of regulation design control
and any related documentation control.
3. Be sure the product meets the needs (verified, validated, tested, supported, sold, etc.) of the
market for the FDA but also for the business case.
Figure 2
WHITE PAPER Page 8Medtech Design and Documentation Controls
Page 8 Expandable Medtech
4. Make sure that there is an expanding exposure as the product is developed and that those
exposed to the product have approved working documentation and are properly trained to build,
sell, support and use the product(s) based on their functional support of the product.
Managing the Product Lifecycle
While the PDP is under development another critical piece to develop and overlay is the lifecycle of
the product. Product lifecycles not only apply to finished product sold but also to raw supply chain
products and/or sub-assemblies used on the final product. One of the biggest FDA concerns is dealing
with changes to an existing product as piece parts, sub-assemblies and third party components
inevitably change in the supply chain. Dealing with existing products: obsolete components, end-
of-life, replacement qualifications, etc., are major factors that require diligent procedures to control,
document and archive that overlay the design and development cycle. Finally the finished product itself
will have its lifecycle as business needs and marketing needs/requirements change over time. Both the
supply chain and actual final product life need to be considered when managing the overall lifecycle
and the product development process should account for new development, change development and
product/change introduction.
General Cradle to Grave Product LifecycleA simplistic product lifecycle has some very basic phases of life: research, development, production
and end of life. These can certainly be expanded as needed by a specific PDP. There can be sub-phases
in the development (prototype, engineering build, alpha, beta, archived, etc., level of product status,
for example) but the main concern is to define the lifecycle that best meets the overall objective while
being able to track the various versions of product in development and in the marketing place.
Figure 3
WHITE PAPER Page 9Medtech Design and Documentation Controls
Page 9 Expandable Medtech
Key points to consider in the development of a specific product lifecycle (PLC) are:
1. General enough to apply to finished product as well as supply chain components
2. Define a solid definition between a research phase and development phase that will meet the
definitions of controls for a particular product
• Note: the FDA can be a bit more flexible with the research phase as far as hard and fast
design documentation but best to make sure there is a clear distinction and definition
built into a PLC and PDP and assure adequate regulatory coverage
3. Perform a clear and clean hand off between Development and Production with all associated
documentation approved and released
• Be sure there is a process built into the PLC to review current product for meeting
needs (both marketing and business) and allow for adjustments/changes as the product
traverses it lifecycle
4. Design a process around the End-Of-Life of a product both from a business perspective (not
to strand any inventory, leave customers without solutions, etc.) but also from a regulatory
perspective in that no product really “ends” – it rather gets archived and stored so that design
history is retrievable (very much like Levi’s…they “never die they just fade away” but the history
must endure)
• Note: although the general case of the PDP provided in previous sections has been
focused primarily on the R&D and production phases of this PLC, the EOL Process is
equally important to define and put in place so that product is properly archived for
future reference, retrieval and audit compliance.
Design, Production and Documentation Control Tools
Developing PDP, PLC and document management processes takes some thought to assure the right
model is put in place at the right time. While a company is starting up it needs enough design and
document control in place to be effective without over-burdening its resources. However, at the same
time it needs to provide a vision toward growth and success by having the ability to expand the scope
of its controls.
As product portfolios become more involved and as the business grows, enterprise tools should enable
communication and collaboration across a larger employee base. Some of the enterprise solutions
that can be utilized at various stages of growth include engineering controls and quality management
features built into Enterprise Resource Planning & Manufacturing Resource Planning (ERP/MRP)
systems, Product Lifecycle Management (PLM) systems and Quality Management Systems (QMS). With
any level of enterprise solution the critical component is seamless integration of design management
with production management to insure that documentation is controlled with approvals and training
records for employees that use documentation to execute.
Key Production and Change Control – ERP/MRP Systems
As a company moves from seed funding toward manufacturing of goods to be sold, the primary
system generally is a fully integrated ERP/MRP system that provides financial controls, manufacturing
planning for lean production, supply chain management, inventory controls, order and order
WHITE PAPER Page 10Medtech Design and Documentation Controls
Page 10 Expandable Medtech
fulfillment, product tracking and traceability (Serial Number and/or LOT controls), etc., to meet
the needs of a complex medical device manufacturing environment. Many ERP systems also offer
Engineering Design Control and Change Management for releasing product design into the
production environment that offer the basic Design Controls and Lifecycle controls required to release
product design from the development environment to a production environment.
As an example, an ERP system may provide an engineering module that allows the separation of
engineering designs from production designs so that revisions to released products can be managed
and new products can be introduced into the production environment.
Engineering design management contains three critical elements:
1. Engineering Approved Vendors/Suppliers (EAVL) – Engineering and Development working with
new vendors to supply new parts or technologies.
2. Engineering Parts – generally new parts, exploratory parts/technologies, etc. that are being
considered for product design but not yet used in production environment.
3. Engineering Bills of Materials (BOMs) – engineering parts list and associated material, parts,
quantities, etc. that make up a product, sub-assemblies, parts, etc. in support of a top level final
assembly design.
Figure 4
WHITE PAPER Page 11Medtech Design and Documentation Controls
Page 11 Expandable Medtech
On the production side of the system, there are matching modules for Vendors, Part Master and
Production BOMs that are in active production or have been produced, potentially obsoleted, and
maintained as production records for products that have been manufactured. It’s important to
separate products in design/development from those in production. When releasing to production,
transfer only designs that meets the PDP process for pre-production or general availability with
sufficient controls and approvals.
Engineering Change Management is the second critical piece that allows the PDP controls between
designs and production with approval controls.
Two key elements are:
1. What product/components/piece parts are being released
2. Who needs to cross-functionally approve the release into production
These two elements of change management are optimally handed with an Engineering Change
Notification and the assignment of Approvers to release changes or new product into the
manufacturing environment.
The critical functionality to demonstrate to regulatory agencies or industry quality auditors is the ability
to have separation between product under development control and product that has been released
to production, along with the controls to introduce changes with authorized approvals into the
manufacturing environment.
In general an ERP system can provide a new business in its startup or early market entry stages with
the basic elements to address regulatory requirements by meeting the design controls, development
process and approvals for managing a product from design into production.
Key Design Control and Product Lifecycle Management – PLM Systems
As a company matures and expands in the marketplace its product portfolio, resources and complexity
also expand and options for deeper controls and potentially a more detailed PDP and PLC are required.
There are a number of products on the market that specifically focus on the design development
process and managing the lifecycle of products as well as providing a deeper level of engineering and
management tools to meet the needs of an expanding business.
Product Lifecycle Management (PLM) provides the capability to define product lifecycles and the rules
required to manage products through a development process. PLM systems also provide extensive
interfaces to both the ERP system for production delivery of approved production design but also to
the extensive engineering tools sets that may be involved with electronic designs, mechanical design
and other Engineering CAD platforms. PLM systems also provide extensive tools for evaluating design
and design changes that aid in product or quality audits and managing changes throughout a product
lifecycle.
A PLM system working alongside an ERP/MRP system clearly provides a separation of design and
production. However, in order to assure a smooth, efficient transfer of products from the engineering
environment to the production environment there must be a seamless integration between the two
systems for accurate and timely design transfer with cross-functional approvals required in releasing
product to market.
WHITE PAPER Page 12Medtech Design and Documentation Controls
Page 12 Expandable Medtech
End-to-End Control for Product/Item Lifecycle ManagementPLM systems generally have tools that allow the end-to-end definition of product lifecycles and
provide flexibility to define various rules to help a business define or refine a development process as a
product is carried from development through end-of-life of the product.
Figure 5
The PLC model shown in Figure 5 takes the general case discussed earlier to a wider PLC (aka Item
Lifecycle as referred to by many PLM systems since the lifecycle can be applied to piece part items,
subassemblies, top-level product, etc.) and details out the initial stages, design stages defining
abandoned designs, and production stages with EOL archival states for deprecated and obsolete
product as well as various production states. At each level a set of approvers can be defined as
products move from stage to stage and should align with a company’s PDP processes and review
stages.
With PLM features in place, a highly robust and flexible product lifecycle and development processes
can be achieved, and equally important, demonstrated in internal audits and external compliance
audits.
There is one critical piece remaining, however, and that is the seamless transfer of the product from
the PLM system over to the ERP/MRP manufacturing production environment that still needs to be
addressed.
WHITE PAPER Page 13Medtech Design and Documentation Controls
Page 13 Expandable Medtech
Figure 6
PLM Product Design Release to Production ERP IntegrationThe critical piece left is the transfer of PDP approved designs to pre-production/production. This critical
integration piece needs to done accurately and in a timely manner. All PLM systems allow for the
electronic extraction of product data that aligns with ERP/MRP systems. Extracts can be provided in
various formats including Comma Separated Values (CSV) or more modern standard IPC-2571 PDX file
formats.
In general the same three engineering elements we discussed in the ERP section are required: Vendors,
Items/Parts and BOMs for the manufacturing environment but also defined and used are the Vendor
Contacts and Vendor/Manufactures Part numbers. Approved product, product changes and obsoleted
product are gathered up (scheduled or manually triggered) in a CSV file or PDX file and sent to the ERP
interface that pulls the electronic data into the MRP for production planning and production.
An ERP-PLM interface provides adherences to any production business rules for the ERP platform
and should be maintained in the transfer such that manufacturing can accurately produce the
product for the market. With seamless integration, critical business benefits can be realized: assuring
manufacturing is building the correct product, allowing purchasing to stop procuring obsolete
product, making arrangements for last time buys of product that has been planned for discontinuance,
and others. For these reasons it is equally important to involve cross-functional approvals in the PDP
process to avoid unnecessary stranding of obsolete inventory, ramping new supply channels and to
minimize any financial impact of design changes to the overall business.
WHITE PAPER Page 14Medtech Design and Documentation Controls
Page 14 Expandable Medtech
A PLM system integrated with the ERP/MRP system provides a strong enterprise solution for flexible
implementation of a comprehensive product development process (PDP), including product lifecycle
management with approvals. They provide complete separation of design from production and
accurate delivery of approved design for market production. These two tools greatly enhance a
growing company’s design controls and development processes with a high degree of compliance to
regulatory design control requirements. PLM not only reduces product error but enables companies
to meet increasingly stringent FDA standards with features that allow companies to better manage
design history files and device master records. These along with other features allow for auditable FDA
compliance while increasing the ability to innovate device designs. This leaves only one final and critical
aspect to address in the regulatory items discussed thus far; that is Document Management tools to
address Document Control, Approval and need-to-know training.
Key Documentation & Quality Management – QMS Platforms
Key to any successful regulatory or industry quality system is the ability to manage and control
documents and use relevant, up-to-date and approved documents in a highly cross-functional
collaborative way with stake holders that need to be aware of updates, deprecation of operating
procedures and critical product documents.
In addition to controlling the documents there is a real need to maintain training needs of employees
that are executing on those documents so that users are referencing correct, up-to-date and released
documentation in performing day to day tasks. Without this level of document diligence, the best
PDP or PLC process can fall flat when the controlling design documents (MRD, PRD, Functional Design
Docs, Reviews, etc.) fail to meet regulatory requirements.
Other critical documents may be required to be supported in the product lifecycle. For example,
production assembly documents, build process documents and other related business process
operational procedures, product support documents, and user documentation also need proper
controls. A Quality Management System (QMS) serves as a much wider platform for addressing quality
processes of a regulated business.
Corrective and Preventative Action, Manufacturing Non-conformance, Vendor Quality Tracking, etc.
are among a small subset of quality functions a QMS can deliver, but one critical area relative to design
control is comprehensive documentation management tools and training tools.
Document Management and Training Process Flow
Among the key and most widely used QMS functions is Document Management. Hand in hand with
document management is the ability to trigger training and maintain training records for up-to-date
documentation critical to running the business and obtaining regulatory compliance. Many quality
systems provide for document control and the documents in many ways can be viewed as a product
with its own lifecycle. New documents should be allowed to be created, reviewed as well as existing
documents changed, updated or archived as obsolete or inactive complete with cross-functional
approvals for each stage of the document lifecycle.
WHITE PAPER Page 15Medtech Design and Documentation Controls
Page 15 Expandable Medtech
Figure 7
A basis of document control and management is illustrated in the process diagram above. This process
flow covers the basics:
1. New Documents – introduced into the quality system.
2. Document Change – ideally with the ability to compare documents against each other for red-line
change review.
3. Document Revision control – as documents change over time revision control is a critical part of
tracking those changes and staying current with the latest approved documentation.
4. Training and Training Records – the human element is key here to be sure that there is a level of
collaboration between the control system and employees that need updated documents and
training on the new procedures… this can be formal or as simple as reading and signing off on
the latest release note changes to a more involved training program.
5. Obsolete Archival – documents that are no longer in the lifecycle of the business are archived and
clearly obsoleted or inactivated for historical retrieval.
To meet regulatory requirements documents are very similar to actual physical product. In fact many
Product Managers view documentation as a component of the product itself. Quality System auditors
also view documentation as critical and the need to control with versioning, approval, release and
archival as being no less important than tracking the product design and development.
Take extra care in building a quality document management process. As with any document they are
only as good as they are communicated and necessary training delivered to employees with document
updates and most current approved procedures followed in day to day execution.
WHITE PAPER Page 16Medtech Design and Documentation Controls
Page 16 Expandable Medtech
A strong QMS platform can deliver this plus a wide array of other quality functions critical to a
business in meeting the documentation controls and other regulatory quality system requirements.
Summary
It is interesting that a simple written US FDA regulation for design control and document control can
have such a profound impact on a business. Hidden behind those few paragraphs is a mountain of
detail that far exceeds a short white paper. The bottom line is to develop design process, product
lifecycle and documentation procedures that meet business requirements. Maintaining a balance of
effective and efficient processes without over processing or over controlling are keys to running a
successful business.
Highly successful companies start small and generally begin early in the life of a company with an eye
to the future. When growth and business demands expand, their processes become more complex
and products are more diversified to the market. Keeping the quality eye forward with regard to
product, design traceability, cross-functional management and making best use of enterprise solution
tools (ERP, PLM and/or QMS) can make a company’s growth curve much more manageable, while
maintaining strong compliance with required quality regulation.
References
1. TITLE 21--FOOD AND DRUGS
CHAPTER I--FOOD AND DRUG ADMINISTRATION
DEPARTMENT OF HEALTH AND HUMAN SERVICES
SUBCHAPTER H--MEDICAL DEVICES PART 820 QUALITY SYSTEM REGULATION
• Subpart C--Design Controls - Sec. 820.30 Design controls.
• Subpart D--Document Controls - Sec. 820.40 Document controls.
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820&showFR=1
2. Medical Device Quality Systems Manual, A Small Entity Compliance Guide First Edition (Supersedes
the Medical Device Good Manufacturing Practices [GMP] Manual)
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequirements/
QualitySystemsRegulations/MedicalDeviceQualitySystemsManual/default.htm
3. Food and Drug Administration San Francisco District, Design Control – An FDA Perspective, FDA
Overview and Presentation, August 10, 2011
4. Arena Solutions – Arena BOM Control User Documentation, Custom Item Lifecycle Phases
5. Generic Requirements for Electronics Manufacturing Supply Chain Communication –Product Data
eXchange (PDX), IPC-2571, November 2001
6. AssurX – AssurX CATSWeb QMS User Documentation, Document Management Process Flow and
Expandable Quality System Corrective and Preventative Action Process Flow
WHITE PAPER Page 17Medtech Design and Documentation Controls
Page 17 Expandable Medtech
Expandable Software, Inc. 900 Lafayette Street
Suite 400
Santa Clara, CA 95050
408-261-7880
www.expandable.com.
About the Author
Dennis Payton, as Executive Director of Product Marketing, has responsibility to drive both inbound
and outbound marketing efforts for Expandable. Dennis has 25 years of telecommunications,
networking experience, product management, and executive experience prior to joining Expandable
Software. His’ career began at Bell Northern Research, the research and development arm of Northern
Telecom and Bell Canada as a Hardware and Firmware Senior Architect and Design Engineer, where
he developed high speed switching and call processing platforms for next generation Meridian 1 PBX
business switches. Prior to joining Expandable Software in 2008, Dennis played a key executive role
at GoDigital Networks in taking system level products to market and in the exit acquisition by CTDI.
Dennis also played a key role in the founding and initial funding of Intera Systems and in designing and
developing products based on terabit multifunctional switching fabrics. Dennis’ background includes
architectural design, finance, product management, marketing and proven leadership. He holds a BS in
Electrical Engineering from California Polytechnic San Luis Obispo and did his post engineering studies
in software methodologies and neuro-networks at Stanford University and University of California,
Santa Cruz. Dennis has also completed the UC Berkley Haas School of Business Product Management
credential program and leadership development with AMA and Nortel Leadership Development
programs.
About Expandable Software, Inc.
Expandable Software, Inc. develops, markets and supports and enterprise resource planning
(ERP) software suite designed to help fast-growing manufacturing companies maximize business
performance.
Expandable’s fully integrated enterprise solution achieves a low total cost of ownership by delivering
long-term deployment of a single system implementation.
With its unique model of direct sales and support, Expandable minimizes implementation costs and
assures expert ongoing customer support.
WHITE PAPER Page 18Medtech Design and Documentation Controls
Page 18 Expandable Medtech
Arena Solutions, Inc.
Arena pioneered cloud PLM applications. The company’s products,
including BOMControl, PartsList and PDXViewer, enable engineering
and manufacturing teams and their extended supply chains to speed
prototyping, reduce scrap, and streamline supply chain management. Arena
cloud PLM applications simplify bill of materials and change management
for companies of all sizes, and offer the right balance of flexibility and
control at every point in the product lifecycle—from prototype to full-scale
production.
Based in Foster City, Calif., Arena holds a spot on the San Francisco Business
Times’ Best Places to Work list for 2013.
AssurX, Inc.
AssurX, Inc. provides highly regulated organizations with enterprise quality
management and compliance solutions. With a choice of OnDemand (SaaS)
or OnPremise (licensed) software delivery options, AssurX’s flexible, all-in-
one system automates quality and compliance processes so issues can be
centrally managed. It helps collect, organize, analyze and share information
to better manage and improve quality and compliance performance
everywhere in your enterprise.
Copyright © 2013 Expandable Software, Inc. All rights reserved.