Posts in Tip Of The Week

Nobel prize technic on how make a decision about your management system

November 5th, 2018 Posted by Presentation, Tip Of The Week 0 thoughts on “Nobel prize technic on how make a decision about your management system”

Today I want to talk about the way we are making decisions. One way is to listen to your inside mystic voice telling you all kinds of fairy tells about do/don’t decision criteria, by the way, this can take you back to your mother voice in your head. Another way is to look at your decision in more statistical manner telling you what are the chances of making a GOOD decision and the 3rd technic is about our passive and active decisions that balance between the logical and emotional thinking.

On the most popular economical article of all times from 1979 by Prof. Daniel Kahneman who was our Nobel prize winner for economy describes a research indicating that we as humans feel that the bitterness of failure is 2 times larger than the sweetness of the success if we will take a decision. That means people are not taking actively decision, it is called “The Status Quo Effect”.

We meet everyday people that are in a situation where the emotional drive and the logical drive are in an equilibrium state. Yes, the forces of the day to day tasks do not let you stay there and you need to take a decision. Even if it is a decision to equip your organization with a software that can create for you controlled framework that you need in order to keep functioning under the daily tasks stress. The decision to stay passive and not do any change is much more attractive than the active decision to make a change.

How to take a decision in such matter, the way to do it is to separate from the active decision to positive decision. So in order to take a decision about system selection should start from the passive decision. Ask yourself what will happen if you do not take any decision, in that case, you will find the cost and pain that comes with not taking any decision, try to put numbers next to that cost. The default behavior of our decision process is not making a decision.

But if you want to make a change you need to do a bit more than do nothing. So now ask how you can take an active decision? Put yourself in the position of your next audit event. Now you do not know what will be the outcome of that audit, you do know what happened the year before and that you will be exposed to some faults. That though will drive you to take an active decision to make a change and have a system to reduce the chance for nonconformity. In other case imagine the time you spend every day on seeking and updating documents and the overhead activities you do to maintain the integrity of such documents. The idea is to change the passive decision to active by finding events close to your world and put yourself that point and evaluating your status quo of your organization.

 
Nobel prize technic

Preventing Potential Recall by Testing Right Your Product

June 23rd, 2018 Posted by Recall, Risk Management, Safety, Tip Of The Week, Validation and Verification, Workshops 0 thoughts on “Preventing Potential Recall by Testing Right Your Product”

On the QA Geek Week giving the following lecture based on a selected example of recalls researched by Orcanos to provide some preventive actions methods on the validation and verification methodology. These recalls give an example of how to pay attention to simple observational engineering faults that could harm the patient. All are true stories that just happened during 2017 – 2018 years which were already reported the increase in recalls during Q1 2018. The numbers shows that it is to be the largest recall quarter since 2005. Orcanos R&D effort is to continue to be a market leader by daily investigating these events and integrating into actions in Orcanos ALM/QMS system, helping to prevent the next recall to our customers.

Try for Free NOW!

 

What we learned so far from our launch of ORCANOS Service Center

December 8th, 2017 Posted by ISO 13485, Tip Of The Week 0 thoughts on “What we learned so far from our launch of ORCANOS Service Center”

We are supporting our customers using ORCANOS Service Center, among other tools such as live chat. Live chats enable our business clients to access agents, who are skilled to answer questions customers may have, as they learn how to use our system.

Read More: https://www.linkedin.com/pulse/what-we-learned-so-far-from-our-launch-orcanos-service-rami-azulay/

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

Tip of The Week – How You Can Be The Best Recall Specialist

April 26th, 2017 Posted by 21 CFR Part 11, ISO 13485, Recall, Services, Tip Of The Week 0 thoughts on “Tip of The Week – How You Can Be The Best Recall Specialist”

Recall Specialist – Medical Devices

Author: Rami Azulay (ALM/Medical Specialist at ORCANOS)

Are you eager  to join an innovative organisation? Do you want to play an integral role   helping clinicians improve  healthcare outcomes for patients? Have you always wanted to join a driven, entrepreneurial organisation that promotes from within? Then your ideal role is that of a Recall Specialist!

As a Recall Specialist, you will be required to provide Product Field Action, which means you will given direct access to all product design documents and verification, and validation protocols in order to perform effective  investigations. You will need access to both production and  manufacturing evidence documents on the device performance during production and  methods which support  the QC process. You will need access to the reporting entity so as to be able  to collect missing information needed to execute your CAPA process and of course, access to the support groups on Tier 1, 2, 3 and 4. These tiers support and manage a diverse range of medical devices. These tasks are only able to be carried out  through a collaborative working environment; not just in the human resource level, but also between the tools and repositories that hold that information.

The key duties of the recall specialist include: The regular reporting, follow-up and processing of regulatory actions, which require more time outside of your day to day tasks. While tools such as ORCANOS | MEDICAL system can provide you with proactive notifications based on Artificial Intelligence (AI) built into the system that compare your execution activity with the regulation and compliance to your organization standard operational procedure (SOP).  This will involve actioning on all aspects of Product Hold (PH) and Product Field Actions (PFA), and enacting the Universal Recall Procedure (Post Market Surveillance) to ensure the appropriate maintenance or removal of nonconforming products from the marketplace. Again ORCANOS | MEDICAL includes with the same system a Post Market Surveillance system call ORCANOS | SERVICE CENTER which act as gateway between the market to the manufacture or the distributor. It allows secured data communication between all parties, of course the AI system will cover regular reporting and follow up on actions, on that same system as well.

It is preferred that the Recall Specialist hold a tertiary science/engineering degree or equivalent. Such academic knowledge coupled with access to relevant and accurate information adds to the effectiveness of the Recall Specialist. ORCANOS Cloud based system, which is validated and 21 CRF Part 11 compliant, makes the world a much smaller place. Information that is needed is easily accessible  from anywhere – either from the event area (if you need to travel for investigation), or from your office where you communicate with other professionals, and information needs to be  secured as you work on  a quality event.

Having a single tool that can manage  all these activities R&D->Quality->Manufacturing->Support in one place, reduces lessens the learning curve for the recall specialist who has to be acquainted with multiple systems, reduces the cost of licensing which   enables access to  secured information needed to work efficiently. .

This role provides an exciting opportunity acting in the center of all things, using advanced tools and methods that can guide and protect the organization interest which will follow by constant recognition for creating a positive workplace environment. If you are looking to take your career within QA and post market to the next level this could a sure way to go.

Effective baseline management for ORCANOS | ALM Test Management

June 23rd, 2016 Posted by IEC 62304, Test Management, Tip Of The Week, Validation and Verification 0 thoughts on “Effective baseline management for ORCANOS | ALM Test Management”

ORCANOS | ALM  versions and baseline management have similar behavior as a source control, thus provides powerful and intuitive tools to manage and track versions, provides a full change history, prevent duplication, and allows reuse, using pointers (copy as link). orcanos

Overview

Rather than manage versions manually, ORCANOS | ALM has a built-in versions management engine, thus allows storing multiple versions views for single text case, or group of test cases, and handle each version separately, and this without duplicating information.

Test Execution

For instance, the historical steps results can be viewed at the point the execution of the test was performed. ORCANOS | ALM “Execution Set” is used for grouping test for execution. Once executed, the execution set stores historical data throughout each test cycle, and the full change history can be viewed in the “Execution History” tab.

Version views and baseline

As opposed to the common use of other test management tools, that physically duplicating test cases when project version advances, ORCANOS | ALM system maintains pointers of the previous version (which would act as a baseline), and track the changes in the current baseline. Test Cases information from older versions are kept, and once a test needs to be updated, Orcanos provides a BRANCH option that splits the test case to 2 instances. One in the previous version and one in the current. both instances are linked, so tracking changes is easy. 

So, in summary, BRANCHING Test Cases creates an instance of the test cases on the new version while preserving the original as a baseline. BRANCHING also easily manages and searches through test case versions, by setting up a multiple views to query the data.

Preserving Test Case Base Line as Test Runs

ORCANOS | ALM  uses both test cases and test runs. Test cases define the set of conditions, actions, expected results, and other criteria used to determine if a product component works correctly and meets its traced, specified requirements. Test cases can change over time to reflect functional changes in your product requirements. Such changes need to be identified easily and reflected on the correct baseline, which goes under testing.

Execution Runs on the other hand, are snapshots of test cases that are generated at a milestone in the testing cycle, such as when a new software release is provided by the development team. A test run contains all information from the related test case, in addition to the results of a specific instance of the test.

So while the test case may change in the future to reflect new user logic modifications, the test run steps that were executed in the past, remain in the history of the execution run, and will never change according to most restricted regulation standards for electronic systems, such as 21 CFR Part 11. By saving test runs, managers and auditors can look back on the exact steps followed during testing years, long after the tests have been completed.

A single test case can have one or more related execution runs such as Functional, Progression, Regression, Load and Stability to mention a few; depending on the test variants defined by test parameters selected when test runs are being executed. For example, should an application support multiple browsers, such as Chrome, Edge, and Firefox variants, these variants can be selected when you execute the test, creating a separate test run for each selected variant. The test runs include identical information, except for the test variant value, which indicates the browser used in testing.
orcanos

 

Viewing the Full Change History

As noted, test cases change over the course of the development cycle. Should  you want to view these changes, you may  select a test case, and then click the Execution History tab to view a detailed change report, including who made the change, when it was done, and what was changed.

Change reports display details of content added to and removed from a test case (or any item, for that matter), each time it is saved. ORCANOS | ALM keeps audit logs of changes according to best practices of  regulated design change management. These reports identify the specific changes made to a test case over time. Change reports are ALWAYS turned on and available for both historical item information logging, and detailed audit trail loggings for test cases.

 

orcanos

Once you are in the Change Report window, you will see content which has been added or removed from the test case. You can also view the electronic signature in cases where changes are made and signed (in ORCANOS | ALM 2.0 and later), and you have permission to view the audit log, If there is an attachment, a link to it will be visible.

Reuse Test Cases

Should you want to add test cases that share the same basic information, ORCANOS | ALM saves time by taking the test to the next baseline automatically. You can then decide if you would like to keep it as it is, make changes,  or just make deletions from that next baseline version. There is no need to duplicate an existing test case and then edit the new test case. Simply select the test case from the next baseline version on the product tree module, followed by selecting Edit Test Case by pressing the Edit button.

ORCANOS | ALM gives you the option to link the altered test case with the original test case into a new execution set. You can also specify the traceability between those test cases to a requirement, and any change to already existing traceability will be managed, based on the baseline it has been associated with.

For example, you might create a “Baseline Test Case” on version 1.0 traced to a requirement in 1.0, then you make changes to that test case in version 2.0. ORCANOS | ALM will alert you that there is a suspicious link needing attention. Allowing you to easily identify and manage changes.

Test Case Versioning in ORCANOS - IMG5

BRANCHING test cases also “copies” information you select from the original test case. Besides the results, all other information including attachments, are always included in BRANCHED test cases. The newly BRANCHED test case now has a new baseline for Execution Run that is kept in tandem with the previous version results. In such cases, you can measure the Feature Maturity by looking at the history of the test over executed version, and see that it gets stable. History of the test will be kept through both version 1.0 and 2.0 at the same audit log, as well as file attachments, links, and more, from the original test case.

Test Case Versioning in ORCANOS - IMG6

orcanos

Original Test Case

2016-06-28_13-28-45

Test Case after Branch

2016-06-28_13-29-09

For more information about duplicating test cases, along with step-by-step instructions, see ORCANOS | ALM online help.

Querying Using Views

The ORCANOS | ALM view designer can be used to easily manage and search through different versions of test cases. In the View dialog box, simply select “test case” from the dropdown list, to add specific criteria to the view by selecting the field VERSION, and use the operands to search the data as you wish.

The end result should look something like this:

orcano

You can use this field criteria to identify the test case version for which each test case is valid, and make it visible at a glance in the test case list window. In the example below, you can see test cases and their version, as well as identify whether they were BRANCHED or not. You can also see the traced requirement of that test case.

Test Case Versioning in ORCANOS - IMG9

orcanos

Test Case Versioning in ORCANOS - IMG11

In this example, the user has also displayed the column for Version Baseline Test Case Traceability relations links, enabling you to see which test cases are linked. Clicking on the blue bar links directly to that traced item.

When the 3.0 update is released, ORCANOS | ALM will advance the project, and automatically all test cases from version 1.0 and 2.0 will be available and will be managed separately. Any current test case that does not change, or does not need an update, will keep its original version. If a test case does need an update, the user would add that test case to Execution Run built into version 3.0, without duplicating the test case, Execute the test cases, and it will be marked as valid for 3.0.

Creating a general custom field,  allows you to filter by many other attributes and creates KPI measurement on your overall productivity. ORCANOS | ALM enables email notifications about changes based on product version, enabling field-level security, and more.

Again, for more information about creating custom fields, see ORCANOS | ALM online help.

Folders are another option for managing test case versions in ORCANOS | ALM. Check out the online support and learning resources at www.orcanos.com for more information.

Tip Of The Week – Why ORCANOS | ALM and GitHub Can Work So Good Togther

April 12th, 2016 Posted by Tip Of The Week 0 thoughts on “Tip Of The Week – Why ORCANOS | ALM and GitHub Can Work So Good Togther”

The Branch Concept – Powerful Tool To Control Your Product Lifecycle and Not Just Your Code

April 11th, 2016 Rami Azulay in Tip of the Week, QPack

This week’s tip expounds on the GitHub concept of branching, and ORCANOS | ALM. While working on a project, you will  undoubtedly have a number  of different features or ideas in progress at any particular  time – Some of which are ready to go, while others are not. Branching allows you to better manage this workflow.

The life span of the R&D activity vs. the other parts of the product lifecycle have the same technical work style,  but in different magnitudes. So as we discuss product definition, we conduct  similar experiments as we do with our R&D activity. However,  since it is less detailed and more functional, there are less daily activities than in R&D. Yet we need the same ability as the R&D to differentiate one release content from the next one to come out. GitHub does that extremely well by way of  the Branch mechanism.

When you create a branch in your project, you are creating an environment in which you are free to try out new ideas. Changes you make on a branch do not affect the master branch, so you are free to experiment and commit changes, safe in the knowledge that your branch changes will not  be merged until it is ready to be reviewed by someone you are collaborating with.

What this means, is that , when you are working on a product release, you firstly need a place where you can evaluate your content against the market needs, and secondly, against the possible implementation by the R&D. This ofcourse is an advantage of ORCANOS | ALM. It provides benefits that are lacking in the GitHub. This deficit causes  a backlog of items in the pool area.

When a decision needs to be made about the content of your release, the ORCANOS | ALM branch mechanism should be considered. It gives you the option to create separate views (branches) for each release, and you are able to move/split/remove content from each view as needed. At the end of the day your view contains only the requirement, design, test, defects and so on, of that specific view.

Open a Pool Request

Pool Requests facilitates discussion about your new idea, while keeping design ideas in a  pool. Because pool requests are tightly integrated within the underlying ORCANOS | ALM repository, anyone can see suggested changes, and how they would be merged, should they be approved.

You can open a Pool Request at any point during the development process: Whether  you have few ideas or a single line description of your requirement, same can be shared as screenshots or general ideas.This approach is useful when  you are stuck and need help or advice, or when you are ready for someone to review your work. By using ORCANOS | ALM @discussion system in your Pool Request message, you can ask for feedback from specific people or teams, whether they’re down the hall or ten time zones away.

Discuss and review your change request

Once a Pool Request has been submitted, the person or team reviewing your request for changes, may have questions or comments. Perhaps the requirement template style does not match project guidelines, the change is missing test data, or maybe everything looks great and commendations are in order – Pool Requests are designed to encourage and capture these productive conversations.

In ORCANOS | ALM you can also continue to push to your view/branch in light of discussion and feedback about your changes. If someone comments that you forgot to do something or if there is a logical bug in the requirement, design or test, you can fix it in your branch and push up the change. Similarly, the  GitHub shows your new commits and any additional feedback you may receive in the unified Pool Request view.

The following flowchart demonstrates the basic concept of using the ORCANOS | ALM branch mechanism,  in order to increase control of content delivery and quality.

GitHub

Tip Of The Week – How to Build Your Design Inputs/Outputs in QPack According to ISO 13485

November 7th, 2015 Posted by ALM 2.0, KPI, Tip Of The Week 0 thoughts on “Tip Of The Week – How to Build Your Design Inputs/Outputs in QPack According to ISO 13485”

October 25th 2015 335d499  Rami Azulay in Tip of the Week, QPack


Start Your Free Trial Now


 

Post Overview

If you are a medical device vendor, then you are probably aware of how the ISO 13485 methods of design and development. In the design phase, we draw on  all our market and product requirements, which are  used in designing. This data also informs  the project plan. Later comes the specifications, which are also determined by the  design inputs, which could be Software/Hardware/Mechanical requirements and their coupling detail design.

How Do I Create Design Inputs In QPack?

In QPack there are 36 work items that have different processes and procedures. Two of them belong to the design input phase. One is the Business Requirement work item. This work item is used to describe the business goals of the product. It is not yet a mandatory document for all medical device vendors, but if your medical device is software (Ex. Mobile Phone App.) only then you must start with that document. Yet best practice demonstrates that most successful projects start with thinking about market needs, and then goes downstream to defining the product.

2015-10-31_14-29-56

 

 

This is  a recommended template, which may be used to increase user productivity and focus on market goals, rather than features:

 

Field Description
MR Identifier QPack ID
MR Name Item Name
Directive

<Provide the instruction that guides and directs functionality being sought by the user.  Each directive addresses a facet of the market problem.  The directive format is:

“User [persona] <shall/should[(high/medium/low)]> be able to <functionality>.”>

<Comment: The special conventions used in the directive are:

  • Square brackets “[ ]” denote optional arguments
  • Pointed brackets “<>” denote mandatory arguments
  • Slash symbol “/” denote the “OR” logical operator.>
Priority QPack Item Priority
  • Rationales
<Provide a list of all possible rationales; the reasons that support the introduction of this market requirement.>
  • Sources
<Each rationale must be supported by a source.  Sources are a list of references and information origins that validate the market requirement.>
Constraints <Provide a list of all possible constraints; the limitations imposed on the solution relevant to this particular market requirement.  Each constraint should be supported by its own rationale and source.>
  • Rationales
<Provide a list of all possible rationales; the reasons that support the introduction of this constraint.>
  • Sources
<Each rationale must be supported by a source.  Sources are a list of references and information origins that validate the market requirement.>
Persona <List names of all personas applicable to this market requirement.>
Use Case <Provide a use case statement or use case identifiers applicable to this market requirement.  Entry of use case information is applicable only if a product or product concept actually exists.>
Buying Criterion <Indicate via this Boolean indicator (Yes/No/NA) whether this market requirement will foster a product feature used as a buying criterion.>
Differentiator <Indicate via this Boolean indicator (Yes/No/NA) whether this market requirement will foster a product feature that is a key differentiator, relative to competing products.>

 

In addition, QPack Product Requirements  can also be applied as a design input requirement. According to ISO 13485 section 7.3.2, design inputs relating to product requirements shall be determined and records maintained (see 4.2.4). These inputs include the following information

  1. a) Functional, performance and safety requirements, according to the intended use,
  2. b) Applicable statutory and regulatory requirements,
  3. c) Where applicable, information derived from previous similar designs,
  4. d) Other requirements essential for design and development, and
  5. e) Output(s) of risk management (see 7.1).

These inputs are reviewed for adequacy over PDR and CDR, and approved. Requirements are complete, unambiguous and not in conflict with each other.  

How Do I Create Design Output In QPack?

According to ISO 13485 Sec. 7.3.3, the outputs of design and development are inserted on a form, which also  enables verification ,and is approved prior to release. Design and development outputs:

  1. Meet the input requirements for design and development                                                                                                                                                               2015-10-31_21-56-25
  2. Provide appropriate information for purchasing, production and for service provision
  3. Contain or reference product acceptance criteria                                                                                                                                                                              2015-10-31_22-02-12
  4. Specify the characteristics of the product that are essential for its safe and proper use.

 

QPack FMEA Section

Risk Product Characteristic

Records of the design and development outputs are maintained (see ISO 13485 Sec. 4.2.4).

NOTE: Records of design and development outputs may include software/hardware specifications, manufacturing procedures, engineering drawings, and engineering or research logbooks.

In QPack you have several sets of work items that can be used to describe the design outputs. In the case of software, the system include work items such as Software Requirements/Software Detail Design/Firmware Requirement/Firmware Detail Design. In relation to hardware design outputs, the system includes Hardware Requirement/Hardware Detail Design, and in the case of mechanical design outputs, there are Mechanical Requirements/Mechanical Details Design (Drawings). All 8 types of work items complete any possible medical device design output.

 

Tip Of The Week – Use QPack ALERTS To Keeps People On The Same Page

October 24th, 2015 Posted by ALM 2.0, KPI, Tip Of The Week 0 thoughts on “Tip Of The Week – Use QPack ALERTS To Keeps People On The Same Page”

October 25th 2015 2015-10-24_07-14-47 Amita Gupta in Tip of the Week, QPack


Start Your Free Trial Now


 

 

Use QPack ALERTS To Keeps People On The Same Page

Alerts are very powerful tools useful in keeping track of updates or anything new that happens during the process of Application Life-cycle Development.  Alerts can be configured to signal any type of information in well organized manner. It can also be configured whether you want them to be delivered or not and when. This is done simply by creating views, and by using those views, one can create his own alert to send those views results as email notification to selected  a preset audience. Alerts minimize  the need to gather  updates from each individual in the organisation. For example, alerts are beneficial to a  manager who may want a daily update on how much testing is done, and which requirements have been covered by teams. So instead each team member emailing  reports on completed tasks,, the manager can simply create an alert that collects  the information about the work being done by the team members and schedule that to come in before every morning meeting. So time spent on meeting is less and important issues are raised first.

How Alerts Can Serve Quality Manager?

As a quality manager, there are many events within an organization that requires strong documentation and actions. One of the best uses of QPack Alerts, is creating  what is called Pre Audit alerts. These alerts serve as watchdog agents within the quality process. inconsistencies such as the following, can be found:

  • Broken Traceability
  • RISK without Mitigation
  • Failure in the V&V process
  • Complaints out of SLA
  • CAPA with overdue actions items etc.

How to Create Alerts?  

The Admin user can create alerts by giving his own user defined name. For Example the name “Daily Test Execution Status Report” , will be the subject line for emails received from the system to the users. Additionally, the email body may contain useful data about how to correct the fault discovered by the alert.

Setting the time and add the Notifier

A User can set the time to generate the email to be received by a group of Users. The period of time for which an Alert remains active can also be defined, relieving users of having to worry about daily updates.

 

2015-10-24_07-25-34

Tip Of The Week – Build yourself an Aggregate ORCANOS Solution for Cross Projects Reports

October 15th, 2015 Posted by ALM 2.0, KPI, Tip Of The Week 0 thoughts on “Tip Of The Week – Build yourself an Aggregate ORCANOS Solution for Cross Projects Reports”

October 7th, 2015  081c888  Avi Harrary in Tip of the Week, QPack


Start Your Free Trial Now


 

 

This week’s tip addresses how we deal with complex technology such as medical devices, smartphones, or any large scale system. In many cases, we need to provide our executive a well-defined cross-project report that supports their decision process. This is never something that one person should take action on. Instead, such projects are best approached in a collaborative manner.  One of the greatest capabilities ORCANOS has pioneered and brought to the market was the ability to give users a way to simulate the architecture of the product and break it into deliverable components; almost like we do when we build the BOM for our manufacturing process. Using the Solution project work item provides the option to gather under one roof, all the subcomponents needed to manage projects. This type of view in ORCANOS gives you endless ways to review each subcomponent, including all projects details.

 

The example below illustrates my point:

Let’s assume we have 3 different products that are being represented on ORCANOS, using three different ORCANOS Solutions:

  1. Product 1 is being represented by Solution 1, and comprises the following sub-components underneath, which are being represented by ORCNAOS Projects:
    1. Subcomponent 1 is Software Project: Software 1
    2. Subcomponent 2 is a Hardware project: Hardware 1
    3. Subcomponent 3 is a Mechanical project: Mechanical 1
  2. Product 2 is being represented by Solution 2, and includes the following sub-components underneath, which are being represented by ORCANOS Projects:
    1. Subcomponent 1 is Software Project: Software 2
    2. Subcomponent 2 is a Hardware project: Hardware 2
    3. Subcomponent 3 is a Mechanical project: Mechanical 2
  3. Product 3 is being represented by Solution 3, and entails the following sub components underneath, which are being represented by ORCANOS Projects:
    1. Subcomponent 1 is Software Project: Software 3
    2. Subcomponent 2 is a Hardware project: Hardware 3
    3. Subcomponent 3 is a Mechanical project : Mechanical 3

 

Now, let’s assume we would like to have a lateral view, Cross discipline: In This case, we will establish a new QPack Solution called ‘Reports’ , and relate all projects to this Solution. The Reports Solution structure will be as follows:

 

Reports (Solution)

  • Software 1 (Project)
  • Software 2 (Project)
  • Software 3 (Project)
  • Hardware 1 (Project)
  • Hardware 2 (Project)
  • Hardware 3 (Project)
  • Mechanical 1 (Project)
  • Mechanical 2 (Project)
  • Mechanical 3 (Project)

 

This kind of aggregative tree structure, will enable retrieving cross products data, using the ORCANOS Views (Filter) capabilities.

How To Create Cross Project View?

As mentioned above, the solution lies in establishing one ORCANOS Solution, which holds all relevant ORCANOS projects underneath it. From QPack Admin interface you can create a solution such as Portfolio View, which will include as many other project components as required.

  1. Establish a new ORCANOS Solution called ‘Reports’ (How To: http://www.orcanos.com/help/Knowledgebase/creating-a-new-project/)
  2. Relate all projects to this solution (How To: http://www.orcanos.com/help/Knowledgebase/addremove-projects-from-solution/)
  3. Build yourself cross project filters and dashboards.

 

Notice that this technique is effective only when all project data are being managed on a Project level, and not on a Solutions level !!!

Applications:

QMS Solution: This solution includes all the Quality Management System components are useful when required by the Quality Manager to perform tasks. In such cases you may find for example the following projects

  • Document Management System
  • Service Center (Complaint Management)
  • Risk Management (RMF File)
  • QMS E-Forms  (CAPA, ECO, Training, MRB etc.)
  • Risk Mitigation Related Projects (Software, Hardware, Mechanical)

Having all the above projects under one solution gives the QA/RA personnel a means of controlling quality events, and performing all quality control activities as required such as; traceability and action items.

 
2015-10-21_15-37-26

 

Page 1 of 2
1 2
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