Posts in Standards and Regulations

cGMP – Design Inputs (URS-FRS-MRS-ERS) – ISO 13485:2016 (7) Clause 7

May 30th, 2019 Posted by e-GMP, Requirements Management, Standards and Regulations 0 thoughts on “cGMP – Design Inputs (URS-FRS-MRS-ERS) – ISO 13485:2016 (7) Clause 7”

We expect that the Design & Development Plan be a written and reviewed document. Similarly, the Design Inputs also needs to be a controlled document. In practice, the design input document is created alongside the DDP simultaneously. However, before we start to analyze the design input, we should take a look at User Requirement Specifications (URS) or Customer Related Processes (see ISO 13485:2016 Chapter 7.2).

The focus of the URS should be on the customer experience. In other words, it should be a list of what the user desires rather than a list of requirements. Also, the list should not have solutions alongside it unless the solution satisfies the requirement of what the user wants to achieve using the product. Likewise, the URS should also include answers on what the customer experiences. In the medical device industry, the demands of the users should be considered from two perspectives namely;

  1.      As a patient.
  2.      As the device operator.

The moment the needs of the user is identified, the device designers have to translate those needs into the design input forms. Although the job is primarily that of the device engineer, inputs from crucial personnel in production, marketing, service, and others should be added as needed. Design engineers should strive to eliminate ambiguity in the design input process to reduce the level if inaccurate assumption. One of the effective ways to avoid false assumptions is to exclude design solutions from the design inputs unless the solution is part of the design. For example, let say a user requirement is; the device must have a foot switch to trigger operation. A suitable alternative would be not to specify a foot switch, rather have the requirement stipulate the need for a hand free operation for the device.

Design Input Categories

Using the User Requirement Specification, one can easily generate several input requirements documents. Input Requirements often fall into three categories namely;

  • The Functional Requirements (FRS): This requirement specifies the capabilities of the devices, its operations as well as its input and output characteristics.
  • Performance Requirement (PR): It covers the device behavior during use, and some of the behaviors can include; precision, ranges of quantitation accuracy, operational environmental ranges, and other performances.
  • Interface Requirement (IR): All interface requirements should be specified. Interface requirements can be either external or internal. However, all specifics relating to the interface should be listed.  External interfaces can be in the form of patient/product interface, external communication interface, and operation/product interface. Meanwhile, the internal interface can be software/hardware and communication interface. Each interface requires a review to ensure that the system works well together.

The documentation for each requirement often depends on the product and the organization. Although, almost all organization have functional requirement documentation or documentation that directly addresses design input requirements (DIR). Sometimes there are separate documents to capture specific requirements of the document such as a Mechanical Requirement Specification (MRS). Another example is the Electrical Requirement Specification (ERS) that are created within the sections or either the DIR or FRS documentation, Orcanos ALM system support over 58 different types of requirements and can be expended to more as needed.

Other requirements that deserve consideration are safety and regulatory requirement. We mustn’t forget the requirements for applicable risk management inputs.

Adequate Time

There should always be enough time to allow for the development of the Design Input Requirement (DIR). Each requirement should be ;

  •         Unambiguous
  •         Quantitative
  •         Contain expected tolerance.

The environmental conditions for optimal performance of the medical device and environmental specification for storage of the device should be stated. As much as is possible, organizations should try to capitalize on the standards set by the industry for each product. Nevertheless, the standards should be reviewed to ensure they cover and satisfy the design input requirements. A popular example is the referencing of ASTM D40169 for performance testing of shipping containers and systems as it relates to verifying the method of testing and packaging conditions. The standard sometimes might not cover the acceptance criteria like in this instance, and if such provision is left out of the DIR, the design input requirement will be incomplete.

It is expected that over the corse of product development, the design input requirement will change. For this reason, the change control will play a vital role in ensuring that the changes are reviewed based on their impact on other design input requirements, Orcanos traceability tools also includes integrated suspicious indication feature which proactively alerts on such possible impact. It is not unusual that a change in one requirement would affect another design input requirement. For more information see related links

Related Links

cGMP – Design & Development Plan (General ) – ISO 13485:2016 (5) Clause 7

May 23rd, 2019 Posted by e-GMP, Requirements Management, Standards and Regulations 0 thoughts on “cGMP – Design & Development Plan (General ) – ISO 13485:2016 (5) Clause 7”

Most device manufacturers find the concept of design control confusing. However, design control is better understood now as a result of better structure. The foundation for every product quality is the design process. Similar to a building, the better the foundation, the lesser the risk of collapse. In terms of design, the final product is dependent on the design process.

The design control process can be implemented for medical devices, manufacturing equipment, and operation, and software systems can make use of a similar process.

Below is a diagram of the waterfall system of design.

Waterfall Design System

 

The diagram depicts a simplistic version of an approved FDA control guidance. The design is typically more complicated due to several elements developing at the same rate. However, the waterfall diagram does serve the purpose of aiding understanding of the operations of the design process.

Common Mistakes in Design Development

One of the prominent mistakes to make is to assume that design control is the same thing as the development process. Although, the development process is a vital part of design control, a more accurate description for design control is to envision it as a lifecycle.

By picturing design control as a lifecycle doesn’t mean that design control will cover requirement for feasibility or marketing. While these processes are vital to the product development process, regulations are in place to monitor product design rather than concern itself with the success of the product in the market. Regulations are more about the safety of the design product instead of the general welfare of the business.

It is important to differentiate between the design input requirement and the marketing requirement and feasibility studies. The design input requirement is also known as the product concept document.

Document Approval

A common problem that most organization face is the approval of documents. There is always a reluctance to approve product design documents as they have to create a room for change and improvement on the document. However, by maintaining control over the document, the approval process tends to become tedious. The goal of control is not to restrict flexibility but to ensure that every phase of the design process is sync, especially when dealing with cross-functional teams.

Typically, approval can be given for revision 1 of a document with To-Be-Determined (TBD) values in certain sections. Meanwhile, teams can start preliminary drafts for the second revision of the document. Subsequent sections will address the core elements of the design control process. However, implementation of the process will depend on the following;

  • The maturity of the company.
  • Product complexity.

It is worth noting that most organizations prefer to breakdown these processes into individual (SOPs). But, it is possible to have a document that covers all the requirement of several elements of the design and development control process.

Related Links

Tip Of The Week – Common Faults A Document Controller Can Avoid

September 11th, 2017 Posted by 21 CFR Part 11, Collaboration, Document control, FDA, ISO 13485, Standards and Regulations, Tip Of The Week 0 thoughts on “Tip Of The Week – Common Faults A Document Controller Can Avoid”

Common Faults A Document Controller Can Avoid During The Document Control Process and Their Mitigation

 

OVERVIEW

Whether you are a  medical device vendor or function in another regulated field, the document control process is an essential part of successfully launching a product. You have the option of using an archaic filing system riddled with a minefield of human errors, or an automated electronic system. So if you are at the point where you are under a significant workload, and wish to have better compliance with the regulatory authorities, such as FDA, CE, it is time to consider an electronic document control management system, an e-DMS (Electronic Document Management System).

ISO 13485 section 4.2, describes the requirements which must be adhered to when producing documentation. Such documentation includes quality management manuals, procedures for approval, distribution, and change of a document and the designation of a person or persons who should implement those procedures. In the ISO13485 2016 edition,  specific procedures outline the prevention on of record loss, as printed documents filed using a traditional system, are at high risk of being lost. 21 CFR Part 820, is an essential regulation not only for medical device firms but for the food and pharma industry. For both, document control is an imperative.

ISO 13485

The ISO13485 2016 edition  (sections 3.2, 3.10, 6.2, etc.) is indicating both individual and corporate how to route documents in your document management system, for example, the following routing phases: document creation(draft), approval, rejection, change control, retrieval, and obsolescence.

According to FDA statistics, document control errors are frequent and numerous. Clinical trials indicate that many documents routed and logged, are inadequately documented and contain inaccurate case histories. These deficiencies make up the second most commonly cited FDA problems, and they rank fifth by the European Medicines Agency (EMA). In warning letters and audit observations, it was discovered that inadequate documentation impacted the thoroughness and level of care physicians can offer patients.   Poor document management is the direct result of paper documents, that can be easily misplaced.

In this article, I will discuss common issues which arise in every phase of the life cycle of a document. The information I will share comes out of my  25 years of experience developing ORCANOS Medical e-QMS  (Electronic Quality Management System) software solutions for regulated companies,  as well as my direct involvement in the implementation and deployment of ORCANOS Medical solution by quality professionals who are responsible for document control and quality management.

The 5 Routing States of the Document Control Process

 

Stage 1: Document Draft Creation

 

Problem #1: Collaboration is time-consuming.

Rarely one person is generating the document person, and almost always get approved and cycled over several stakeholders. Collaboration is normative during the initial phase of creating a document. This activity is time-consuming and can be rather costly. Bringing all stakeholders together in one room can also be impractical,  as relevant individuals are rarely in the same place at the same time. Additionally, the traditional method of routing a document via email is increasing the chance of conflicting edits.

Collaborative tools, such as Google Docs is an excellent way to cover some of the issues local office documents introduce. However, while Google Docs collaborators have the convenience of working together online, it does not resolve the critical obstacle of traceability. This approach requires extra work to approve and distribute these documents.

Our Suggestion for Collaboration

A Cloud-based document control system creates a virtual collaboration workspace. The workspace allows team members to add their files in a secure and real-time environment anywhere, anytime. The workspace gives global access to every employee, to add his/her document without having to wait for someone else to unlock the document. A cloud-based system not only allows access to authorized users 24 hours a day, but also eliminates the constraint of being in the physical location of the file, improves search capabilities and reporting, and allows Metadata definition for each file. DropBox, Google Drive or any other file sharing system are not supporting these capabilities.

ORCANOS e-DMS provides lot of capabilities, subjected to user privileges.

 Orcanos

Stage 2: Document Routing Process Approval and Distribution

 

Problem #2: Availability of personnel delays and grinds productivity to a halt.

People are not available. The process might involve executives who travel a lot. In the world of paper-based or hybrid process, there is a challenge to control or escalate a case where the approver missed its target. With an electronic system, you may have an alternate signer, who is authorized to replace the original signer (according to SOP). Also, such a system ensures that approvers do not misplace the right cell to sign on a printed document.

ORCANOS eDMS puts a due date for each document to sign, and fire an alert when the time is due.                       Image result for Availability

Problem #3: Misuse of revisions that are an obsolete revision.

The control on old document revisions is still a major challenge to QC and others departments. Once a new revision becomes effective, accessing older revision (which is now obsolete) should be forbidden, leaving only the last approved revision available for download. Using the obsolete revision of a procedure, drawing or specification is still the source of many errors. Lack of access to released documents, as well as difficulty in finding them, is often the result of staff making uncontrolled copies, either paper or electronic.

Problem #4: Training can fall through the cracks.

The cycle of approval of a quality document ends with distribution. There is a major challenge in notifying relevant stakeholders.

In such cases, it is needful to create traceability from the approved documents to training forms. Such training form needs to have a life cycle of its own, but it will be clear what action needs to take place in order to make the document effective.

ORCANOS e-Training module allows you to create these links easily. So for example, if new working instructions need to be deployed the working instruction documents must first be approved. You will next need to create a training form which specifies the audience who needs to participate in the training of the new working instructions and trace it back to the released document. As quality personnel, you will have all the information in one place, a system that will also notify when the training has completed. Ensuring that the appropriate people understand the change and are competent to perform the newly revised work instructions can be challenging for many organizations.

Our Suggestion for Mitigation:

In our 12 years of experience, we have found that companies reduce their review and approval turnaround time significantly after implementing ORCANOS e-DMS process. Routing, follow-up, escalation, and distribution are all automatic, saving time and effort. Usually, companies run into trouble to manage such copies of the old revisions. The distribution of new revisions has also become time-consuming, requiring control and follow-ups. Using electronic system brings the ability to control your document copies and tracking of will solve great problem controlling your documents. The integration of document control with your learning management system ensures that training tasks related to document changes will not fall through the cracks.

Stage 3: Review/Reject and Change Control

 

Problem #5: Neglecting review during document cycling.

As a Document Controller, you need to follow the document review procedure which is used to review and ensure that a document’s content is applicable and accurate based on current project objectives. In many cases, processes evolve without the documentation being updated, so changes done in the document are not fully reflected. ORCANOS e-DMS system is helping to implement the standard operating procedure and ensure that the actual process and documentation process are in sync.

Problem #6: Who needs to review what and when, is a big challenge. Image result for Review Reject document

Each document requires a different set of people to review it. Ensuring that each change is well documented and executed correctly, requires that the right people are involved in the change control process. Having too many people involved does slow down the process and reduce efficiency. At the same time, overlooking an individual or group during a change can result in issues down the line. So if for example, we perform engineering changes by the R&D group, it may be acceptable to the regulatory and quality team, but not passed by the manufacturing team, who may need to adjust their tools/jig to adopt the changes.

Problem #7: Product iteration information is largely based on “tribal knowledge.”

Knowledge preservation or knowledge transfer is always a risk. The complexity of some of the products as well the regulated path it needs to go through may take several years. So it is reasonable to think that at some point in time some of the people in the original design team might have been assigned to other business units or have left the company. In a manual process, you will need to collect paper documentation from remote resources. Some of them may be on someone’s  local PC or spread over email inboxes, so product history becomes not handy and overburden understanding the product evolution.

Our Suggestion for Mitigation:

Any developing industry using ALM tools will utilize iterations. Most commonly used methodologies such as Agile Scrum, DevOps or even traditional Waterfall are based on release and lifecycle of development reflected by their versioning number. Such iterations are used both before and after the product is released to the market, which makes change management crucial. Since requirements, test and all other types of changes are described by documents, we need to control every change. With an electronic system, you can control singular changes in the level of requirements, and route it based on relevancy to different groups of people. This will cause the change control process to be both efficient and thorough. Additionally, having a centralized repository for all product documents provides the ability to create traceability between documents, so when one is changed you can easily discover the impacts on others. Cloud-based systems also allow easy reference to the relevant documentation even long after a product has been launched. Having an electronic system also gives the organization the advantage of performing basic tasks such as e-signatures which comply with CFR 21 Part 11, Implementation of ISO 13485 Sec. 4.2 completely, timing and scheduling reviews, dynamically collect the relevant people for review and automating the distribution of approved documents.

Stage 4: Retrieval

 

Problem #8: Searching  a document

The need to reference a document arises in several cases such as daily use, internal audit, external auditor during any quality event. The ability to retrieve such documents efficiently is part of what today’s organizations are measuring up to. A common challenge among organizations is the investing of significant effort finding documents when they are needed. Using traditional paper documents in filing cabinets or electronic versions on file shares increases the risk of not being able to do intelligent searches. You want users to be able to search for documents and find them quickly.

Our Suggestion for Mitigation:

Many people are accustomed to searching for information by simply typing in the terms they are searching for, getting the desired results. In some cases, it is more efficient for users to find the documents they are looking for by browsing an organized hierarchical structure. It is important to support both search and browse approaches to finding records. In either case, associating the proper metadata to the document, as well as supporting full-text searching are critical. The system should enable your organization to find the needle in the haystack quickly.

Stage 5: Obsolescence

 

Problem #9: Misuse of documents that are obsolete.

Part of a regulated company’s day to day task is to maintain document archives, stored for historical purposes, as well as to avoid misuse. It is important to keep documents for as long as they are effective. The effective date of some documents may expire, and you need to renew them. It is not enough to only control the approval process, but the lifespan of a document must be determined. The document shall not be deleted by the concept but being blocked from mistaken use. Over time, the collection of documents can be overwhelming and clutter your quality systems, making searching more difficult.

Problem #10: ECO release of documents timing cause great effort.

Part of the change control procedure is the ECO release. The ECO form may include a set of documents to be released, and also reflects the changes in the revision of each document showing the newly approved version, as well the obsolete document. Using traditional methods requires close observation and control of each document through the logging of changes. Human errors and fault are common in such heavy ECO releases and can cause misleading distributed documents.

Our Suggestion for Mitigation:

Companies standard practice is to archived documents up to 15 years. There may be issues with keeping records longer than that period. Regulatory requirements usually dictate a company’s retention time frames. The time frame a document remains available becomes a RISK to meet the minimum regulatory requirements. An electronic system is ensuring that the access to approved documents or obsolete is well controlled. Storage today has become a neglected issue by most IT department.

So what do you need to do, to avoid the problems above?

If you are using paper-based or hybrid processes, making a move to a fully automated system will improve your quality management significantly. If management of your documents is your most pressing problem, it is time for you to find an out-of-the-box tool that fits your needs.  The available features as well as the complexity, and the amount of effort required to set up a system must all be taken into consideration when deciding on an electronic system.

Document Management Software Tool Selection

As you consider which document management software to select, or QMS, ensure the DMS covers other areas of your product lifecycle for example ALM (Design Control). The ALM part covers the R&D phase and the traceability to the design and validation documents, as well as to the traceability between different requirements in the V&V paradigm. ORCANOS | Medical solution is a one of a kind product that enables you to manage both R&D and Quality Management in one place, such as  RISK management (ISO 14971) and Complaint Management (ISO 13485 Sec. 4.2) which are an integral part of any Quality Management System.

ORCANOS Platform contains all core applications,  allowing access to an integrated quality management suite with the unlimited ability to create new modules and tools (BOM, ECO, CAPA, Training, Printing Labeling, Manufacturing with e-DHR and more) that you can use as needed. ORCANOS e-DMS systems can be used as a starting point solution, but also as the foundation of a quality management system. It is scalable, configurable, and there is room for adding more solutions and addressing future quality needs. ORCANOS is a leading vendor and pioneer introducing such integrated platform.

Conclusion

In regulated environments, document control is the sound basis of quality. It is not a stand-alone system; it has branches and links to other procedures and processes that directly/indirectly affect product quality and safety. The control of all relevant documents (and the process for changing those documents) is a   highly complex management task. Automating your manual or hybrid processes will significantly increase your organization’s efficiency, accelerate time to market, help maintain compliance, and reduce your overall compliance costs.

Related Links

Closed System LOOP FDA Recommended CAPA Methodology

October 11th, 2015 Posted by 510(k), FDA, Medical Device Directive 93/42/EEC, Standards and Regulations 0 thoughts on “Closed System LOOP FDA Recommended CAPA Methodology”

In this paper we are going to examine the quality of the event management process, and in particular the CAPA, referred to as corrective and preventive action.
As we think about the quality management systems (QMS), and their different components, certainly quality event management is one of the most important.
Additionally, as we look at the quality event management system more specifically, we see that it may be broken up into primary components:
Read More.


Start Your Free Trial Now


 

Risk management terminology and characteristics

August 30th, 2012 Posted by IEC 62304, IEC60601, ISO 14971, Risk Management, Standards and Regulations 0 thoughts on “Risk management terminology and characteristics”
Basic terms
  • Hazard: Potential  source  of  harm (what can go wrong)
  • Failure cause: what causes the hazard
  • Harm: Physical injury or damage to  the of people or property
  • Risk: the calculation (RPN) of the Probability of occurrence of Harm and its Severity
  • Risk control/ Risk mitigation: the means taken to reduce the risk
  • Residual risk: Remaining risk after risk control measures have been implemented

So, Hazard creates the risk that can cause harm: what can go wrong, what is the likelihood for this to happen, what would be the consequences and is the risk level tolerable or not?

Example 1 : Risk analysis to mobile phone: The radiation (hazard) that caused because of crack in mobile phone body (failure cause) causes severe headaches (harm) solved by using materials according to relevant standards (risk control)

Type of optional hazards – hazard category (partial list)

  • Energy
  • Biological
  • Chemical
  • Environmental
  • Hazards Related to the Use of the Device
  • Functional Failure
  • Maintenance
  • Aging
  • more…

Risk probability/frequency values (the probability for the harm to occur)

  • Improbable (So unlikely, it can be assumed occurrence may not be experienced)
  • Remote (Unlikely, but possible to occur in life of an item)
  • Occasional (Likely to occur sometime in life of an item)
  • Probable (Will occur several times in life of an item)
  • Frequent (Likely to occur frequently)

Risk severity values (the severity of the harm!!)

  • Negligible
  • Minor
  • Moderate
  • Major
  • Catastrophic

Risk control types

  • Safety by design
  • Protective measures – in the medical devices itself or in the manufacturing process – alarms, production line tests
  • Information for safety – marking, user manual
  • Operational – Workshops, training courses…

Risk properties

  • Hazard – what can go wrong
  • Category – see list above
  • Failure cause – what cause the hazard
  • Condition – Normal use, single fault, incorrect use
  • Affected – Patient, operator, service personal, bystanders, environment
  • Probability1 (also known as occurance/likelyhood/Frequency) – probability of the harm before risk control
  • Severity1 – severity of the harm before mitigation
  • RPN1 (risk level1) – the risk estimation result (Severity and probability) before mitigation
  • Control type – see above
  • Reduction necessary? – yes/no for hazards that are in ALARP zone
  • Probability 2 – after mitigation (risk control)
  • Severity 2 (not always in use, usually equal to Severity1)
  • RPN 2 – after mitigation
  • New hazard created – yes/no. Indicates if new risks arises from risk control
  • Related artifacts (for control) – relations to SRS, HRS, user manual…
  • Status – risk status, see in our blog some examples (hazard identification->risk estimation risk control identification->risk control implementation->verified)
  • Verification type – external labs, test management, training (you can use a descriptive field as well)
  • Verification description
  • Applicable component

ISO 14971 For Medical Device Risk Management

February 23rd, 2011 Posted by ISO 14971, Standards and Regulations 0 thoughts on “ISO 14971 For Medical Device Risk Management”

ISO 14971 represents the requirements for a medical device risk management system.

This standard establishes the requirements for risk management to determine the safety of a medical device by the manufacturer during the product life cycle. Such activity is required by higher level regulation and other quality standards such as ISO 13485.

ISO 9000 Quality Standards

  • ISO 9001:  Design and Manufacturing
  • ISO 9002:   Manufacturing Only
  • ISO 9003:  Inspection and Testing Only

Orcanos

Contact

8 Tozeret Ha'aretz Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use