27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements through Design to Quality Documentation

Editor's Notes

• #4: Poll 1., Is your market clearance related contents ready by the time the device design completed? - Regulatory submission contents ready prior engineering finishes the design - Regulatory and engineering contents are ready almost at the same time - Regulatory submission contents mostly delay beyond the time whe
• #5: Medical device development is a special in a sense that it works in a rather regulated environment. Requirements for market access are set in multiple layers There are the following: Market regulators -> US FDA, EU, Health Canada, etc. Market regulations -> 21 CFR 807, EU MDR/IUDR, etc. Harmonized, recognized standards -> IEC 60601-x, ISO 62304, ISO 82304, ISO 14971, etc. Quality managemen systems for the design organization May be the part of the Quality managemen systems for the Customers Also, Engineering practices that is from the design entity experience Standardization Landscape for medical software engineering Generic safety standard 61508 Generic IT and software engineering standards 12207, 90003 Generic Medical process standards 13485, 14971 Med and Health SW specific process standards 62304, 82304 62366 Electric MED Product standards 60601-x Electric equipment for measurements, control and laboratory use 61010, 61010-x
• #6: STORY kell!! Design organization day to day challenges 1., Time constrains From the Organization itself -> timing of product roadmaps From key Customers -> feature expectations on a timely manner From Market Regulators -> Design contents for market clearances 2., Resource constrains Project that is planned for 6 engineers for a year cannot be accomplished in a month by 72 engineers Keeping team motivated Providing sensible, value added activities Minimize unnecessary administrative work -> Help to preserve employee retention 3., Balancing Safety and Quality One end of the scale: Fully and perfectly safe device does little to nothing from functionality prospective. -> Safe, but not viable from marketing prospective Other end of this scale: Ignored safety for the device that is actually rich in functionality -> Attractive on the market, patient safety however compromised
• #7: Design framework for MedTech companies 1., Best in class, compliant process framework 2., Extended contents for the deliverables. Design contents for regulatory purposes is a must. How does it approached … One end of the scale Dedicated technical and regulatory documentation team is dealing with all the market clearance contents. Tipically after design completed. Other end of the scale Nothing is implemented unless the mandatary design contents are ready. Probably not any of these are practical. Mid-way out of this challenge -> Incorporate regulatory requirements in the early design phases, and carry on with these through product desing and development. Result could be -> Design readiness will correspond to regulatory clearance readiness for the design. Poll: 2., What are the key challenges for your design organization? - Ensure and maintain safe device design - Manage resources for engineering activities - Maintain consistency for device characteristics - Go to market on a timely manner - None of the above
• #8: Merging practises to common platform. We have a NEW tool solution for all of these, called Intland Retina. It is new common, integrated, easily accessible ALM platform with eQMS capabilities. All software development teams in all key industries can benefit from Intland Retina. To serve the needs of the Medical Device Software developers facing regulatory challenges, we have created process templates.
• #9: The project template contains configuration based on a Data models. These UML models have been created based on the requirements of regulatory standards. This image shows the main areas that our templates are dedicated for, and their connections points.
• #10: Primary medical devices where Retina can help Template -> Pre-configured medical industry ALM solution
• #11: This slide focuses on the values and benefits of using Intland Retina and its medical templates. Fast Implementation: Intland has invested the time and effort to develop project templates according to standard requirements, so you won’t have to. Plus the new UI is intuitive, meaning it requires less training, so rollout is quick and smooth. Audit Support: Intland Retina is strong in both design control and QMS features. End-to-end traceability is ensured and is easy to query. Customized reports may be simply created, and approved in one click. Domain Experts: Intland has outstanding domain experts in-house to contribute to the development and maintenance of our solutions and templates. One Template, Multiple Standards: Medical is a highly regulated industry where many standards may be applicable to a single product. With our 2 medical templates, we support 6 regulatory standards and the successful completion of compliance audits. Validation Support: Intland Retina powered by codeBeamer is TÜV Nord-certified Trusted Tool. Our templates are validated by industry experts. We offer a Validation Kit with almost 800 requirements and test cases to support tool qualification processes and to cut the costs of validating your software tools. Easy-access Approvals: Both the tool and our template offer easy access for Reviewers involved in the approval process. Using our solutions, they can accept and approve documents and reports with timestamped e-signatures that are displayed in a human readable format as per regulatory requirements.
• #12: The Template intends to support medtech delivery processes end to end. Starting with the medical system’s design, it supports risk management (risk assessment and control). It also supports the design of both hardware and software subsystems. The Template comes configured to support Validation and Verification (testing)processes. Support for all additional requirements is buillt in such as the management of source code or housing needed for implemetation.
• #13: How do we do it. Key aspects to design ALM application. Can be done by user customization, can be by the Template or by the modification of the template.
• #15: Core integration to Product Risk Management. Information containers, Can be done by user customization, can be by the Template or by the modification of the template.
• #17: Before the product demonstration, let go through quickly the workflow we will see. New feature development Step 0 -> Customer, Product Management, Product Risk Management, Marketing has a new idea for a feature for an existing product. Step 1-> URS created together with Engineering Change Request discusses from timing, resourcing, budgeting and impact analysis prospective Step2 Planning for release -> Task management planning
• #18: Medical device design has some special characteristics Deliverables management is one of these. Deliverables for software devices are not limited to binaries and user manuals. Design contents are key parts for market clearances. Two key part of deliverables: 1., The design itself 2., Design, development, verification and validation contents for users and for regulators
• #19: One roadmap milestone may include a single, or multiple change requests. Change requests are elaborated on task levels References, relationships of Change requests and tasks is a must to manage product development effectively. Development phases varies from one company to another. Phases can be set for V model or Agile kind of development processes. IEC62304 or IEC82304 process phases are also can be easily set in the Template if applicable. Change request sets relates to roadmap milestones. Tasks are assigned to a single phase or to multiple phases for activity tracking. Tasks for design content compilation and completion can be set here and assigned to the corresponding development phase. It could be tasks for: System requirement compilation, Product Risk Management activity delivery, Verification protocol and verification activity completion, Etcetera. Artifacts to these tasks also can be assigned if needed by customization.
• #20: Tasks also a workflow on itsown, that workflow is pre-configured. Managing tasks with workflows enable to evaluate either automatically or by manually the status of corresponding tasks or artifacts. Criteria could be: 1., Is the product risk related activities and/or artifacts are complited already 2., What is the design phase where we are in 3., Readiness of the key market clearance deliverables (URS, SRS, SDD, etc.) Poll 3 : What is the most resource intense area of your device design activities - System design - Product risk management - Implementation - Verification - Clinic validation - Regulatory submissions - None of the above
• #21: Built in, default system tool to gain further confidence of tasks, change requests, artifacts statuses. 1., On-lin traceability browser 2., Reports from analytics, on-line reporting system 3., Kanban boards for all item types 4., Customizable, however pre-configured, role-based dashboards
• #22: This picture shows the information flow via documents. An imported document can be, for example, the requirements of a new device, or change requests for its new version. That document can be imported and further managed across Design Control, Risk Management, and Verification. Data storage trackers allow you to export data to documents, which can then be approved using the Review Hub. The Review Hub allows users to review (approve, reject, and comment on) documents with multiple reviewers using e-signature functionality. After review, the status of those documents may be set to approved, and could serve as input for Regulatory Reporting documents. Those files can be collected and stored in the Template’s Document Control area as Design History Files, Risk Management, or Test Files. Szaby: Document export process flow from internal information container to office document. Also, suitable to import contents from office documents into the Template. Importing happens once for the preconfigured information containers, than contents, like System/subsystem/Design requirements, architectures, references, test protocols, managed in Intland Retina. One exception is the documentation containers, like DHF, RMF, etc, where documents are managed as a documentation management system. Part11 signatures can be applied if needed for any workflow steps.