If you’ve ever wandered into a popular juice bar and decided to consume your favorite pressed beverage on-site, you may have noticed a few interesting aspects of the shop’s management that resonate with your role as a quality manager:

1. Juice bars are focused on health, as they provide drinks, smoothies and snacks that are full of vitamins, antioxidants and other vital nutrients. The best juice bar managers aren’t there solely to collect a paycheck; they are also focused on supporting the wellbeing of the people they serve. Like a juice bar manager, you also seek to improve the health and wellbeing of your organisation.
2. Fruit and vegetable juices are not everyone’s favourite. Moreover, even fans won’t necessarily go to great lengths to get their dose of juice.  Likewise, quality managers often promote topics that are not very popular.
3. Juice bar managers are tasked with reaching a wide audience, as otherwise their business is unsustainable. Similarly, your work is done with a vast variety of participants in mind, including your on-site staff, remote workers, suppliers and inspectors.
4. A visit to the juice bar is a quick stop along the course of your day versus a time-consuming, carefully plotted destination like a restaurant or theatre. This is done purposefully, as the most successful juice bars are those that make it convenient and simple for people to get what they need without much consideration. Effective quality management teams operate in a similar fashion, ensuring that it’s easy for end users to get involved quickly and trouble-free. Like juice bar managers, you’re well aware that although what you produce certainly impacts the way others operate, it’s not the main thrust of what they do.

As you observe effective juice bar managers, one thing is abundantly clear: success lies in how well they reduce friction and meet the target audience where they are. 

So, for example, while a juice bar located near a farm would in some ways make the juice bar manager’s life better — the air is clearer, the costs are lower and it’s more convenient for the manager to get his/her key ingredients — most juice bars are in urban locations, not out in the country.

Meeting customers where they are means putting the juice bar in a central locale like a train station to cater to the constant stream of commuters versus close to the organic farm where the vegetables and fruits are sourced.

This lesson applies to successful quality managers, too: you’ve got to meet members of your organisation where they are. For some teams, this could be close to the coffee machine or, in a more scalable way, on a digital workspace app.

If your team uses Jira and Confluence for ongoing project management and collaboration, then that’s where your quality processes should be. The amount of traction and engagement this streamlined approach affords you is huge.

So put down your pressed green juice and think about the platform you use for your quality management system. Did you choose strategically to increase engagement and reduce friction?

I’m not trying to put the squeeze on you; I’m just encouraging you to drink in the valuable lessons learned at your local juice bar to make healthier IT choices for the good of your organisation’s wellbeing.

These are exciting times to serve the life sciences sector – thanks to technological advances, innovations abound and progress marches on at a lightening-fast clip. Working with a wide variety of organisations, I see two very different types of teams searching for an answer to the same fundamental question: “How do I best do Agile and still comply with regulations?” (For example, ISO-13485, GAMP® 5, etc.)

On one side there are traditional pharmaceutical companies. These companies have established ways to create software and have the manpower, capacity, knowledge and procedures to manage compliant software systems. Still, there are significant inefficiencies related to time, effort and budget in doing business as usual. Given the copious benefits of both Agile and DevOps, as well as the ever-growing recognition of their efficacy, many pharmaceutical companies have realised they can no longer continue doing things the old way. For them the key question is: “How do we continue to be compliant, but also adopt Agile methodologies?”

On the other side, there is a flood of young, highly successful companies who have been developing great software in Agile methods outside the scope of regulated software. (Ahem, some health and fitness apps that shall remain nameless.) These companies are extending their reach and moving into new territories… which now includes operating in regulated spaces. These teams may have mastered Agile, but for them the question is: “How can we continue to be Agile, but also be compliant?”

As with any organisational change, making it happen depends on the perfect blend of process, tools, and culture.

Process: Extending Agile practices to support the requirements of GCP and medical devices regulations

There is no way around it: GCP, FDA Quality System Regulation and ISO-13485 each impact how you do Agile. It’s worth acknowledging this fact and making the most of it. These are my top three observations about how Agile in life sciences is different:

1. “Working software over comprehensive documentation” is not applicable to this domain. Comprehensive documentation is essential, and there is no way around it. The good news is that with the right tooling and practices, the burden of generating the required documentation can be streamlined. Moreover, the need for comprehensive documentation can be aligned with Business Driven Development (BDD) and other state-of-the art practices. This may make the transition more easily accepted and implemented by teams who previously have had less regard for documentation.
2. A story is not a requirement specification: Typically, the Agile story is focused on an additional feature or a modification to an existing feature. As the product evolves, stories describe the small changes that are introduced throughout the development cycle. A specification of a product in a given release version provides the description of the feature at that particular time. This is not to say that a story cannot also be a specification – it can be, but it certainly is not always the case. As a product matures, and each version represents an incremental advance, a story becomes less likely to be a specification. I have seen teams that have regarded their stories as specifications of the software, which is not a sustainable approach over time. It’s a form of technical debt you do not want to have. (For more on this topic: https://radbeeqms.com/agile-and-design-controls-from-story-to-specifications/ )
3. A comprehensive Definition of Done is key to success: As you need to have all the design specifications in place for the release, it is vital to not leave the update of these specifications as an afterthought of the sprint but instead consider it an integral part of the story work. Include in the Definition of Done the update of the specifications to reflect the story impact on user requirements, functional specifications, risk elements, etc. The benefits of this approach are:
4. It provides a more realistic measure of the sprint velocity, which is a key reason to agree on a Definition of Done and your plan as a whole.
5. There’s less risk of release delay due to incomplete documentation.
6. It also aligns better with a short release cycle and frequent releases.

Tools

Tools can be hugely helpful in reducing the burden of compliance, particularly in the following areas:

1. Generating the traceability matrices: To those who are still using Excel and Word to generate the traceability matrices, I say this: there is hope out there. With the correct tools in place, you can have release documentation only “one click away.” The key is to maintain the traceability elements (i.e. user requirements, risks, etc.) in Jira, and use Jira links to represent the traceability. You can then visualise the traceability in Jira and also export your release documentation from Jira. While this does require quite significant configuration work in Jira and a use of Marketplace apps, the benefits far outweigh the investment. The following are some of my go-to apps to use in this context:
2. Structure for JIRA (https://marketplace.atlassian.com/plugins/com.almworks.jira.structure/server/overview ) easily allows you to visualise traceability in Jira.
3. Xray (https://marketplace.atlassian.com/plugins/com.xpandit.plugins.xray/server/overview ) is a test management plugin, which also provides some reports to visualise traceability.
4. PDV View (https://marketplace.atlassian.com/plugins/com.midori.jira.plugin.pdfview/server/overview ) enables the export of any combination of JIRA information in a layout that makes it easy for FDA inspectors to digest.
5. Easylinks for JIRA (https://marketplace.atlassian.com/plugins/com.codedpoetry.easylinks.easy-links/server/overview) is a (free!) plugin, which is awesome in standardizing how different issue types are linked.
6. The software quality control process: This can be made significantly easier with Bitbucket, i.e. pull requests. Bitbucket can also generate the records required for future inspections.
7. Creating a solid Continuous Integration setup: This includes comprehensive coverage of automated tests and code quality control and is overall useful for the creation of good software, regardless of whether or not it’s regulated.

Culture

No matter if you are changing from waterfall to Agile, or from non-regulated to regulated, a culture change is required. As it goes, this is the aspect that typically is hardest and slowest. My two-cents on this kind of shift:

1. There’s no “one size fits all” for change: The bottom line is that it will take time for your organisation to develop the best methodology that works for all involved parties. Transition has to be gradual, and taking baby steps in the right direction is better than trying to make such a seismic shift all at once.
2. A high level of discipline is necessary: What is common to regulatory compliance and to Agile alike is there’s no room for sloppiness. While some people may think that Agile preaches for less process, in reality it is very structured and includes some widely adopted ceremonies. Looking at Agile through this lens may help you and others in your organisation become more open to the Agile approach. For example, consider making retrospectives part of your quality control process.

Contrary to popular opinion, being both Agile and compliant is not only possible, it’s preferable. Rather than look at it as if one side slows down the other, when you see both processes as complementary, you get a clearer picture of what you were striving for in the first place: organisation-wide victory.

This article was also published on the Atlassian Community.

Join our London Event on the 3rd. October 2018: Practical Solutions in Computer Systems Validation (CSV) and Software Development Life Cycle for GXP & MedDev

When teams set out to determine the requirement specifications for a computerised system, confusion often arises. However there are some simple steps you can take that will help you build up a clear picture of the requirements along with getting buy-in from everyone involved.

It’s all about the process

In order to determine the requirements accurately, you will first need a solid understanding of what the eventual computerised system needs to do. Whether you follow SIPOC (suppliers, inputs, process, outputs, customers) or another process mapping method, make sure you spend enough time exploring and questioning your beliefs about the target process. You can do this by conducting small group interviews and hosting discovery workshops, as well as reviewing relevant documentation.

You could then try developing a prototype. This can highlight things you might have inadvertently left out when you initially set out to describe what the system would need to do.

For example, when creating a new process setup in Jira, use a development system to devise a rough implementation of the process. You can then share that with the users and ask for feedback. This will help to identify fundamental errors like missing steps and duplication as well as revealing misconceptions and unexpected ideas.

If your platform doesn’t allow for quick prototyping, use storyboards instead.

A good description of the eventual process will form the basis of your user requirements and operating instructions. It will also help to make clear how regulatory requirements will impact the process, for example the need for electronic records to be created and training provided.

Taking regulatory requirements into account

It’s vital to consider the relevant regulations when working out the requirements of your implementation. Your best bet will be to add regulatory requirements to your list and manage them exactly as you would user requirements.

For the implementations we do, the two major sources of regulatory requirements are:

• The FDA Code of Federal Regulations, Title 21, part 11 (CFR 21 part 11 )
• Europe’s Annex 11

It’s important to follow legal requirements to the letter, so you you may want to consult an expert ensure that you fully understand how the regulations governing your industry will affect your implementation.

Requirement specifications in Jira

Jira is the perfect place to specify your requirements. Start by defining a dedicated custom issue type called ‘Requirement’. Using this to describe the requirements of the process will enable you to trace their connections with functional specifications and make sure none of the requirements are ignored in the development or testing process.

An efficient quality management system (QMS) is the lifeblood of any company in the health industry. Failure to meet strict regulatory and compliance requirements could mean lost business or even a complete shutdown of operations.

The challenge

Biotech start-up SOPHiA GENETICS has had a QMS in place since its launch six years ago. VP of Quality Jasmine Beukema and her team work hard to ensure that SOPHiA has always met the medical device industry’s strict standards. But what began as a six-person company that could easily operate with a paper-based system had since grown to 150. From excessive paperwork to unnecessary overhead, they could no longer afford the inefficiencies – especially during critical times, such as audits.

With an ISO-27001 audit only five weeks away, Jasmine knew that something had to change if SOPHiA was going to get recertified.

The process

SOPHiA was already using Confluence, which was a good start, as Jasmine knew the software would support the electronic QMS they desperately needed. SOPHiA brought us onboard to quickly, accurately, and effectively digitise and modernize their system.

After finalizing our initial plans with SOPHiA, we set up a staging environment where we could install prototype implementation and also easily collaborate with Jasmine and her team.

Our main focus was to extend Confluence to support SOPHiA’s controlled documents—the official collection of documents kept for regulatory, operational, and quality processes. This would make finding procedures, linking procedures, and uploading supporting documents easy for SOPHiA.

Jasmine and her team monitored ongoing improvements and provided constant feedback on the staging site. Once we obtained approvals, we were then able to transfer these improvements to their production environment. Along the way, we taught SOPHiA optimal use of Confluence, including lots of tricks and shortcuts to become more adept and efficient with the software.

We also carried out the system validation, which is a formal, documented testing cycle to ensure that everything was complying with requirements.

Because of the critical deadline, we went the extra mile to ensure that SOPHiA’s controlled documents were ready within five weeks, just in time for their audit.

The results

We provided what SOPHiA desperately needed: an audit-ready, fully digitised system in under five weeks.

A few days after SOPHiA’s paper-based collection of documents were transitioned to Confluence, the company was audited for their ISO-27001 certification.

They passed with flying colors.

According to Jasmine, “This audit was much less stressful and less invasive on the company because we didn’t need to disturb people while they were working to request specific documents.”

Moreover, she sees many long-term benefits, including improved efficiency across the entire company. This includes the streamlining of several crucial processes and the elimination of the needless overhead that was wasting human resources. She estimates that the digitisation of their QMS will cut down on at least 30% of the preparation time before future audits.

Jasmine and her team are left not only with a more efficient system, but also the confidence that they’re meeting compliance and regulatory requirements, and that their new quality management system will withstand future company changes and growth.

For more details on how we helped SOPHiA digitise their QMS to prove to auditors that they’re handling data in the most secure way possible and obtain critical recertification in just five weeks, read the full case study.

Without the right tools in place, traceability matrices can easily bring a project to the brink of collapse. Still today there are project managers who delay moving to production for a significant length of time while they put together a traceability matrix for the validation report.

Fortunately, with the addition of appropriate plugins, Jira provides an excellent solution. Using it to manage your specifications and tests will eliminate the need for tedious manual work by integrating traceability throughout every stage of the project. As user requirements and other elements emerge and evolve, the traceability will be updated, and a fully up-to-date traceability matrix will be available at any time.

What are the elements of a traceability matrix?

1. You analyse requirements to identify risks, and these risks needs to be mitigated. Those mitigations then become requirements. So a requirement will be connected with a related risk and that risk will be related to another requirement that mitigates it. When these links are all clearly documented we can describe this as bi-directional traceability.
2. Functional specifications are prescriptive and specific. In the case of configurable computer system, configuration specifications will often be dictated by functional specifications. Each functional specification has to be triggered by, or traceable to a requirement.
3. Tests are how you demonstrate that the system meets the specifications. You first need to plan the tests, and the plan will only be complete when all functional specifications can be traced down to tests.
4. The system can be declared validated only when there has been a successful test run for each test.

Choosing the right technology to manage traceability

Anyone who has ever tried using Excel to manage traceability can testify that it doesn’t scale well and is very tedious to use, even for the smallest project.

A good tool to manage traceability will:

1. be seamlessly integrated with your specification management – this eliminates duplication of effort
2. offer strong reporting capability, showing the different levels of traceability in a clear forrnat
3. be flexible, allowing you to define the report layout and content
4. make it easy to spot traceability gaps

Managing traceability in Jira

Jira comes, out of the box, with the capability to link issues. So, if you have a requirement and a functional specification set up as Jira issues, you just need to link them to establish traceability.

It’s a good idea to use meaningful link names, like ‘traceability link’, to differentiate traceability links from other links that may exist between issues.

There are many add-ons available that provide powerful features to extend Jira’s core issue-linking capability. The additional capabilities available range from auto-calculating coverage status to visually displaying the hierarchy of links and reporting.

Here are some concrete examples:

1. Links Hierarchy for Jira & Agile provides a visual tree of multilevel links for each issue, so you can see the complete path from requirement to test for each and every issue.
2. Xray for Jira and Test Management for Jira are both test management suites that provide clear visibility of test coverage and offer several convenient tracability views. Test Management for Jira creates traceability reports, which can be easily exported.
3. Xporter for Jira and PDF View for Jira are both report generation tools, which you can use to export traceability reports in almost any layout you want.

For international health industry companies, ensuring regulatory compliance is difficult. Add into the mix an outdated paper-based Quality Management System (QMS), and the task to meet regulatory requirements across multiple locations in an efficient, cost-effective, timely manner becomes impossible – and threatens to derail a busy, successful international organization for non-compliance. 

The challenge

 An in vitro diagnostics (IVD)  medical device and clinical lab organization with offices in the U.S. and Europe desperately needed a new QMS to better manage a vast quantity of paperwork. Beyond the risk of non-compliance, it was a daily challenge to ensure that procedures were standardised and the latest documents were being referenced.

For example, thanks to differences in time zones and schedules, it wasn’t unusual to lose days worth of productivity over small things, such as a signature or an approval. Furthermore, paperwork they relied heavily on — Document Approval Forms — was comprised of two separate documents so staff members had to manage both simultaneously and track down printed copies to be sure they matched. And other everyday necessities, such as internal complaint tracking, corrective action tracking, resolution, and personnel training, were also needlessly complicated by the antiquated paper-based QMS.

This led to perhaps the biggest issue of all: training new personnel to use this inefficient system, which was riddled with complicated processes for handling simple tasks.

Although this company had explored other options to update their QMS, none were successful. Understandably, management was a bit reluctant to try again for fear of another failed attempt. But internal complaints about using the paper-based system were mounting; the time had come to make compliance-related processes easier, using a customised solution that was simple to use and implement company-wide.

 The process

After examining numerous options, the company’s Vice President of Regulatory Affairs and Quality settled on Jira as the base software for its digitised QMS because not only is it “the biggest name in bug tracking in the software industry,” but also because it’s user-friendly and is continually being updated and improved. He then retained us to customize the software so that it was easy to implement a new, streamlined QMS company wide. Topping the list of the VP’s priorities was to make the system user friendly, so the learning curve for new staff would be minimal.

Working from a flowchart of how the company wanted the electronic system to behave, we implemented the system in a staging environment – starting with a customised change control form module that would standardise our client’s controlled documents into one easy process. Once approved, we uploaded the company’s hundreds of CCFs and numerous additional documents in just two days.

The final step to completing the digitised QMS was to develop a custom training management module, which made all types of training accessible and intuitive, from HR practices to department-specific processes. Beyond the benefit of saving the company significant time — thanks to the module’s ease of use — the training management module also allows the company to clearly demonstrate to auditors that all staff are properly trained on necessary procedures.

The results

The Senior Vice President of Regulatory Affairs and Quality estimates 500% more regulatory compliance efficiency and a resource cost savings of $150,000- $200,000 annually. Today 75 employees have access to the electronic QMS and rely on it daily. In less than a year, over 700 CCFs have been processed through the new system – and internal complaints about using the QMS are a thing of the past.

“We deployed our new quality management system from start to finish over a few months, for a fraction of what other systems cost,” the Senior Vice President of Regulatory Affairs and Quality raved.

For more details, read the full case study.

Last week a select group of 15 health sector professionals representing businesses from startups to large pharmaceutical companies gathered in Stuttgart, Germany for expert insights on implementing and maintaining effective quality systems. Featuring presentations by four industry leaders, attendees left the conference with actionable information – regardless of if they were initiating a new system or improving an existing one.

Given the focus on QMS sustainability and overall efficiency, the presenters illuminated their points with real-world examples of systems that are compliant but not excessive, are proportional to the clinical safety risk, and that use software and infrastructure to effectively lessen the burden of compliance.

Presenters included:

1. Ott Stellan, CEO of ott+partner: Stellan presented a compelling look at his company’s transformation from a cumbersome and wasteful paper-based quality system to a functional digital system using the Capability Maturity Model Integration model (CMMI) as the guideline for the quality processes, and a Microsoft team foundation server as the electronic platform for their project work. Along with a significant reduction in waste and increase in efficiency, the company culture also underwent a dramatic shift – for the better. As a supplier to pharmaceutical companies, ott+partner is audited frequently and their new processes have helped them consistently pass audits with flying colors.
2. Rina Nir, CEO of RadBee: An expert in implementing quality processes in Jira and Confluence, Nir explained the many benefits of using these platforms to reduce friction with quality processes and increase staff engagement and efficiency. She also provided three case studies using these Atlassian tools to support quality processes, showcasing how to use Confluence for controlled documents and JIRA for Corrective and Preventive Action (CAPA) management and to support Software Development Life Cycle (SDLC) and an eValidation approach.
3. Markus Roemer, CCS Consultant, demonstrated how he used Confluence to support SDLC and traceability. Despite a difficult start and a reluctant team, the system he devised and implemented was eventually overwhelmingly adopted and has now stood the test of time, successfully passing numerous audits over the last several years. Additionally, Roemer also provided an overview of regulations and standards that impact the industry, highlighting especially prevalent misconceptions and how some companies evolve a nonsensical and excessive set of processes.
4. Keith Williams, CEO of C3, gave guidance around the various infrastructure options available to businesses as the cloud becomes mainstream in GXP environments. From “on-premise,” to “hosted,” “private cloud,” and so on, he discussed the costs, benefits and risks that each option presents. Because there’s no one rule that fits all, Williams emphasised the need to avoid excessive spending, and advised companies to instead to seek out the fiscal and efficiency sweet spot where the compliance and quality strategy aligns with the patient and business risk.

Key takeaways from the conference included:

• The importance of finding the optimal point between doing too little and too much when it comes to implementing quality processes.
• How Jira and Confluence support effective QMS management, and why these tools are so engaging to users.
• Why moving an ineffective paper system to an effective eQMS using SDLC tools and eValidation is very achievable – as long as timeline expectations are managed.
• How a sound process to follow before implementing a new QMS involves setting your own risk approach, challenging it, and then getting input from the quality, business and compliance owners. From there, it’s essential to prototype and test to be sure it accomplishes all key goals before company-wide implementation.
• Why to ensure sustainability, it’s essential to first agree on what you need to do for quality and regulatory compliance in your business, then transparently track the processes. By continuously challenging those processes and measuring the performance, your system will dynamically evolve and improve.

Attendees delighted in seeing examples and receiving knowledge from different viewpoints and were particularly enthusiastic about real use cases. They also noted how enjoyable it was to be a part of this “friendly group” and appreciated the detailed insight into what must be done for compliance sake – and what’s excessive. The conference also revealed an important “need” to further discuss issues of “sensible approach to computer system validation,” and agile modern development trends within GXP and medical devices.

We are planning future events now and will keep you posted. Please feel free to let us know what topics you’d like to see covered as it relates to devising and maintaining an effective eQMS.

Doing Agile in a GXP or medical devices environment requires you to serve two masters: you need to practice the Agile disciplines on one side, and embrace regulatory requirements on the other.

In order to strike the balance, you must understand the difference between “stories” (Agile term) and “specifications” (Design Controls term). From my experience working with many teams that are “Agile first,” I have seen firsthand how easy it is for people to believe that Agile stories are the same as specifications.

Not only are they not the same, but also the difference is critical to how you work and your “Definition of Done.”

A story describes a new requirement or a modification to an existing one. There is a certain language formula to a story, including emphasising business value and all the other Agile-esque nuances. The key is that it does not necessarily describe the product, but rather the incremental change that is required.

In Software Development Life Cycle (SDLC) terms, a specification (i.e. a user requirement) expresses a regulatory requirement that the product (or the system) needs to meet in a subsequent version.

For example:

An Electrocardiogram (ECG) device provides an innovative report that features a special analysis of the ECG signs.

1. Version 1.0 is developed:
   1. Development gets a story: “Doctor needs a report so that [details of the report are provided].”
   2. User requirement: “Doctor needs a report with the following specs: [details of the reports are part of that specification].” (In this case, you could use the exact same language as the story.)
2. Enter Version 2.0 development:
   1. Development gets a story: “Doctor needs the report to also include a calculation of X in a separate column.”
   2. User requirement: “Doctor needs a report with the following specs,” and details of the report are part of the specifications. These details (of that extra column) are now updated to also include the new data mentioned in the story of version 2.0.

As the product evolves, stories describe the small changes that are introduced throughout the development cycle. A specification of the product in a given release version provides the description of the feature at the particular time of release. This is not to say that a story cannot also be a specification – it can be, but it certainly is not always the case. As a product matures, and each version is an increment, a story becomes less likely to be a specification.

Updated versions of a product may include the following types of specifications:

• Those that remain the same as they were in the previous version.
• Those that change from previous version.
• Entirely new specification elements, which are added if new features are implemented.

Once you understand this difference, you can still work Agile. However, now your “Definition of Done” will account for this. A story is done only when specifications have been updated to reflect how the product is after implementing the story.

While you could leave specification updates to anytime before the release, making it part of your story work (“Definition of Done”) is advantageous because it gives you a more realistic idea of your progress. If you don’t update specifications on an ongoing basis, then you risk unexpectedly delaying the release because you have to add them at the end. Specifications also become a helpful, more detailed reference for developers and testers during the release that more closely reflect the development version they’re using.

When designing in a regulated environment, it’s crucial, then, that you get your story straight – and differentiated from your specifications. Not only will it clarify your mission, but it also ensures a happy ending for your version.

If you need to maintain information for an FDA inspection or submission, Jira is a great tool to use. Be aware, however, that the Code of Federal Regulations Title 21, part 11  requires you to be able to export that data from the system into a readable, precise document:

11.10. (b) The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records.

When setting up Jira to support regulated process, you must ensure the export includes all elements of the Jira issue, including:

• Regular and custom fields in a human-friendly layout
• The history of the issue
• Information about all electronic signatures provided for the ticket
• Any necessary supportive attachments
• Sub-task information with all the bits of information (history, electronic signatures, etc.)
• The export date, time, and name of the person who exported it
• Company-specific styling, including logo, disclaimers, etc.

My go-to tool when setting up an FDA-compatible export is Midori Global Consulting’s PDF View plugin for Jira. This powerful plugin allows you to export any FDA-required issue into a world-class, well-designed, professional document. There are plenty of informative examples included with the tool, which takes you a long way towards implementing the export you need. All custom field types or rich text situations are covered, and any necessary attachment is integrated in its original format as an embedded file. You also can invoke dynamic scripts in the export process, giving you access not only to sophisticated calculations but also to Jira’s entire third-party API universe. For example, I use InLabs’ Electronic Signature  to easily add customisable electronic signatures. The resulting PDF is a self-contained and complete package of information that, using the tool’s own API, can easily be exported as part of the issue workflow or in any automation cycle.

The only downside of this plugin is you need technical know-how to implement it. The export requires basic notions of three technologies: .FO Syntax, Velocity templates, and Jira’s own API, so be advised you will need access to development skills to implement it.

Because your business relies on creating accurate, complete records, it’s imperative you use the best tools possible to generate your exports. There’s an art to delivering the right information that satisfies regulations.

Over the course of working with dozens of innovative, exceptional companies, I’m always struck by their commonalities of purpose and process. While they all are creating products poised to help us all live happier, healthier and more productive lives, ironically enough many tend to put themselves through sadly torturous, inefficient circumstances before their products can see the light of day.

And more often then not, the validation cycle is the place where all hell breaks loose.

Case in point:

One of the biggest and most innovative pharma companies in the world hired us to set up a Jira Service Desk for them.

The contract was signed in late June.

By mid September, the Jira Service Desk installation on their development environment and configuration were all completed.

This left validation… which took a jaw-dropping six months in order to finally make it into production.

This means:

It took just 12 weeks to gather requirements, iterate through several versions of configurations, and complete vetting technical issues and specification freeze. The technical specifications and manual test scripts were also finished during that period.
It took more than double that amount of time – 30 weeks — for validation, qualification and installation to production.
These numbers are more staggering when you realise that almost all of the delay was due to paperwork: manual adjustments, formal review and approval processes. The actual technical defects or infrastructure issues we faced were very limited, and all were resolved swiftly.

The lesson from this particular situation is clear – for those companies reliant on lengthy, paper-driven validation processes, innovation is slowed to snail’s pace. By the time it gets to make an impact, it is, well, old news.

Clearly, the industry is in transition. New organisations in particular are refusing to align themselves with archaic practices. It has already become mainstream to create all the design elements within tools, which automatically generate traceability matrices. In the near future, these tools will have to up their game and produce all the validation records (i.e. requirements specifications, test scripts, etc.) simultaneously as part of the Continuous Integration cycle.

Automation will not stop there, but instead will cover the complete spectrum of validation and qualification activities. Manual test scripts will be replaced with complete automation of the test cycle. Installation will be automatic and include qualifications tests.

Recently I met a startup that has the bold vision to deliver the first version of their product using a completely hands-free validation, installation and qualification cycle. Their current technical challenge is that their automatic cycle is using 64 servers and takes too long. Their tests cycle takes 24 hours.

Should I have told them that in some places validation takes as much as 30 weeks?

As it stands, the regulatory challenge they will be facing might be much larger then their technological one. Will inspectors know how to assess their hands-free approach?

While the answer to that is unclear in today’s transitional world, what is clear is that is where we are heading. It’s valid to want to automate inefficient systems, and more than that, it’s actually imperative. The companies that master the regulatory and technical challenges of hands-free validation today will steer their way clear to competitive advantage tomorrow.

If you’ve ever wandered into a popular juice bar and decided to consume your favorite pressed beverage on-site, you may have noticed a few interesting aspects of the shop’s management that resonate with your role as a quality manager:

1. Juice bars are focused on health, as they provide drinks, smoothies and snacks that are full of vitamins, antioxidants and other vital nutrients. The best juice bar managers aren’t there solely to collect a paycheck; they are also focused on supporting the wellbeing of the people they serve. Like a juice bar manager, you also seek to improve the health and wellbeing of your organisation.
2. Fruit and vegetable juices are not everyone’s favourite. Moreover, even fans won’t necessarily go to great lengths to get their dose of juice.  Likewise, quality managers often promote topics that are not very popular.
3. Juice bar managers are tasked with reaching a wide audience, as otherwise their business is unsustainable. Similarly, your work is done with a vast variety of participants in mind, including your on-site staff, remote workers, suppliers and inspectors.
4. A visit to the juice bar is a quick stop along the course of your day versus a time-consuming, carefully plotted destination like a restaurant or theatre. This is done purposefully, as the most successful juice bars are those that make it convenient and simple for people to get what they need without much consideration. Effective quality management teams operate in a similar fashion, ensuring that it’s easy for end users to get involved quickly and trouble-free. Like juice bar managers, you’re well aware that although what you produce certainly impacts the way others operate, it’s not the main thrust of what they do.

As you observe effective juice bar managers, one thing is abundantly clear: success lies in how well they reduce friction and meet the target audience where they are. 

So, for example, while a juice bar located near a farm would in some ways make the juice bar manager’s life better — the air is clearer, the costs are lower and it’s more convenient for the manager to get his/her key ingredients — most juice bars are in urban locations, not out in the country.

Meeting customers where they are means putting the juice bar in a central locale like a train station to cater to the constant stream of commuters versus close to the organic farm where the vegetables and fruits are sourced.

This lesson applies to successful quality managers, too: you’ve got to meet members of your organisation where they are. For some teams, this could be close to the coffee machine or, in a more scalable way, on a digital workspace app.

If your team uses Jira and Confluence for ongoing project management and collaboration, then that’s where your quality processes should be. The amount of traction and engagement this streamlined approach affords you is huge.

So put down your pressed green juice and think about the platform you use for your quality management system. Did you choose strategically to increase engagement and reduce friction?

I’m not trying to put the squeeze on you; I’m just encouraging you to drink in the valuable lessons learned at your local juice bar to make healthier IT choices for the good of your organisation’s wellbeing.

These are exciting times to serve the life sciences sector – thanks to technological advances, innovations abound and progress marches on at a lightening-fast clip. Working with a wide variety of organisations, I see two very different types of teams searching for an answer to the same fundamental question: “How do I best do Agile and still comply with regulations?” (For example, ISO-13485, GAMP® 5, etc.)

On one side there are traditional pharmaceutical companies. These companies have established ways to create software and have the manpower, capacity, knowledge and procedures to manage compliant software systems. Still, there are significant inefficiencies related to time, effort and budget in doing business as usual. Given the copious benefits of both Agile and DevOps, as well as the ever-growing recognition of their efficacy, many pharmaceutical companies have realised they can no longer continue doing things the old way. For them the key question is: “How do we continue to be compliant, but also adopt Agile methodologies?”

On the other side, there is a flood of young, highly successful companies who have been developing great software in Agile methods outside the scope of regulated software. (Ahem, some health and fitness apps that shall remain nameless.) These companies are extending their reach and moving into new territories… which now includes operating in regulated spaces. These teams may have mastered Agile, but for them the question is: “How can we continue to be Agile, but also be compliant?”

As with any organisational change, making it happen depends on the perfect blend of process, tools, and culture.

Process: Extending Agile practices to support the requirements of GCP and medical devices regulations

There is no way around it: GCP, FDA Quality System Regulation and ISO-13485 each impact how you do Agile. It’s worth acknowledging this fact and making the most of it. These are my top three observations about how Agile in life sciences is different:

1. “Working software over comprehensive documentation” is not applicable to this domain. Comprehensive documentation is essential, and there is no way around it. The good news is that with the right tooling and practices, the burden of generating the required documentation can be streamlined. Moreover, the need for comprehensive documentation can be aligned with Business Driven Development (BDD) and other state-of-the art practices. This may make the transition more easily accepted and implemented by teams who previously have had less regard for documentation.
2. A story is not a requirement specification: Typically, the Agile story is focused on an additional feature or a modification to an existing feature. As the product evolves, stories describe the small changes that are introduced throughout the development cycle. A specification of a product in a given release version provides the description of the feature at that particular time. This is not to say that a story cannot also be a specification – it can be, but it certainly is not always the case. As a product matures, and each version represents an incremental advance, a story becomes less likely to be a specification. I have seen teams that have regarded their stories as specifications of the software, which is not a sustainable approach over time. It’s a form of technical debt you do not want to have. (For more on this topic: https://radbeeqms.com/agile-and-design-controls-from-story-to-specifications/ )
3. A comprehensive Definition of Done is key to success: As you need to have all the design specifications in place for the release, it is vital to not leave the update of these specifications as an afterthought of the sprint but instead consider it an integral part of the story work. Include in the Definition of Done the update of the specifications to reflect the story impact on user requirements, functional specifications, risk elements, etc. The benefits of this approach are:
4. It provides a more realistic measure of the sprint velocity, which is a key reason to agree on a Definition of Done and your plan as a whole.
5. There’s less risk of release delay due to incomplete documentation.
6. It also aligns better with a short release cycle and frequent releases.

Tools

Tools can be hugely helpful in reducing the burden of compliance, particularly in the following areas:

1. Generating the traceability matrices: To those who are still using Excel and Word to generate the traceability matrices, I say this: there is hope out there. With the correct tools in place, you can have release documentation only “one click away.” The key is to maintain the traceability elements (i.e. user requirements, risks, etc.) in Jira, and use Jira links to represent the traceability. You can then visualise the traceability in Jira and also export your release documentation from Jira. While this does require quite significant configuration work in Jira and a use of Marketplace apps, the benefits far outweigh the investment. The following are some of my go-to apps to use in this context:
2. Structure for JIRA (https://marketplace.atlassian.com/plugins/com.almworks.jira.structure/server/overview ) easily allows you to visualise traceability in Jira.
3. Xray (https://marketplace.atlassian.com/plugins/com.xpandit.plugins.xray/server/overview ) is a test management plugin, which also provides some reports to visualise traceability.
4. PDV View (https://marketplace.atlassian.com/plugins/com.midori.jira.plugin.pdfview/server/overview ) enables the export of any combination of JIRA information in a layout that makes it easy for FDA inspectors to digest.
5. Easylinks for JIRA (https://marketplace.atlassian.com/plugins/com.codedpoetry.easylinks.easy-links/server/overview) is a (free!) plugin, which is awesome in standardizing how different issue types are linked.
6. The software quality control process: This can be made significantly easier with Bitbucket, i.e. pull requests. Bitbucket can also generate the records required for future inspections.
7. Creating a solid Continuous Integration setup: This includes comprehensive coverage of automated tests and code quality control and is overall useful for the creation of good software, regardless of whether or not it’s regulated.

Culture

No matter if you are changing from waterfall to Agile, or from non-regulated to regulated, a culture change is required. As it goes, this is the aspect that typically is hardest and slowest. My two-cents on this kind of shift:

1. There’s no “one size fits all” for change: The bottom line is that it will take time for your organisation to develop the best methodology that works for all involved parties. Transition has to be gradual, and taking baby steps in the right direction is better than trying to make such a seismic shift all at once.
2. A high level of discipline is necessary: What is common to regulatory compliance and to Agile alike is there’s no room for sloppiness. While some people may think that Agile preaches for less process, in reality it is very structured and includes some widely adopted ceremonies. Looking at Agile through this lens may help you and others in your organisation become more open to the Agile approach. For example, consider making retrospectives part of your quality control process.

Contrary to popular opinion, being both Agile and compliant is not only possible, it’s preferable. Rather than look at it as if one side slows down the other, when you see both processes as complementary, you get a clearer picture of what you were striving for in the first place: organisation-wide victory.

This article was also published on the Atlassian Community.

Join our London Event on the 3rd. October 2018: Practical Solutions in Computer Systems Validation (CSV) and Software Development Life Cycle for GXP & MedDev

Confluence is much more than a Wiki. As you become a power user of Confluence, there are many macros that can help simplify the process of writing better documents.

Take for example, the Comala metadata plugin (free plugin for Confluence server). By providing a set of macros that allows you to easily define your metadata, and then refer to it, Comala has long been a vital part of any Confluence (server) installation.

The following two examples illustrate how metadata can make your quality process documents both easier to write and maintain.

Use Case #1: Define Metadata once & use it multiple times

Say that you are writing a ten-step work instruction that explains a multistep process, where there’s always a sign-off at the end of each instruction, i.e: “Please sign electronically, providing your username and password.”

The traditional way to write this is to copy and paste the same sentence, ten times.

Now, imagine that you need to change the above to read, “Please sign this step providing your digital signature.” Obviously you would like that adjustment to be reflected everywhere where the previous electronic signature instruction was mentioned before. Theoretically you could do an automatic replace across all instances, but what if everywhere the sentence appears isn’t exactly the same? For example, if one has an accidental extra blank, then an automatic replace would not work. Furthermore, if the person who changes the text is less familiar with the instructions and is not aware that this sentence appears at the end of each one, then it’s entirely possible that he might change the first occurrence and forget to address the others.

That’s exactly where metadata comes into play:

• Step 1: Using the macro Metadata list, define a metadata: signature text =Please sign this step providing your digital signature (Tick the “hide” box so it’s concealed when the page is in “View.”)  
• Step 2: Each time you need the signature instruction to appear, use the Metadata value macro, fetching the metadata’s “signature text” from @self (the same page). 
• Step 3: Publish the page. Confluence will render the page as you want, with the correct signature text appearing each time the metadata is called upon.

ADVANCED OPTION: Metadata can be used across pages, so you can follow the same process to define something only once but have it appear in multiple locations. For example, you can define the name of your product in metadata, and  if ever the product name ever changes, then you’d only need to replace it once for it to appear everywhere you need it to throughout your document.

Use Case #2: Make it easy to change organizational responsibilities

This example is particularly powerful when writing Standard Operation Procedures (SOPs).

Very often a procedure has certain role within the context of an organizational responsibility, for example, a recruitment procedure will have a role for “recruitment manager.” This person will have responsibilities including finalizing job descriptions, publicizing employment opportunities, preparing employee contracts, and so on.

Who the recruitment manager is within the organization may change over time. For example, when the organization is very small, the job title may be “Office Manager.”  Later on, it may be assigned to other positions, such as the “HR manager,” or “Talent Champion,” and so on. None of these title changes fundamentally alter the procedure; however, it is easier to read if the correct title is used through the document. And so referring to the correct title (i.e. “HR manager”) is clearer and less ambiguous then referring to the role (“recruitment manager”). Metadata once again is the secret to automatically updating each procedure in multiple locations throughout a given document whenever there is an organizational change:

• Step 1: Using the macro Metadata list, define a metadata: recruitment manager =  HR Manager (Tick the “hide” box so it’s concealed when the page is in “View.”) 
• Step 2: Each time you need the correct title to appear, use the Metadata value macro, fetching the metadata, “recruitment manager” from @self (the same page).
• Step 3: Publish the page. Confluence will render the page as you want, and the “HR manager” text string will appear each time the metadata is called upon.

Engineering your procedures in Confluence is a simple – and sanity-saving – step. All it takes is installing a timesaving plugin like Comala metadata, and keeping your document up to date is a snap.

For many of the medtech and pharmaceutical companies I consult with, there’s a common clash of the validation systems “worlds” raging: traditional, “this is how we’ve always done it” paper documentation versus newer, tech-driven solutions.

In order to effectively harmonize business processes company-wide, I argue that innovation is critical, as the challenge is not just to validate a system for now, but also to keep it validated far into the future.

This kind of planetary shift in corporate culture doesn’t happen overnight. The resistance that stems from legitimate concerns like compliance often overwhelms progress.

Take for example a CEO for a large clinical research company that I recently worked with. The company had a systems validation process it had been using for eight years… but they also had an entire room solely dedicated to paper documentation, where every sheet required multiple signatures, screenshots and so on. They kept the paper-stuffed room not because they were ever going to use it, but because they figured they might as well keep it.

The CEO asked me, “Is this the definition of validation? Is this what we really need for compliance?”

And I told him, “Absolutely not.”

Still, doing away with the old system, even if top leadership knows it will save time and money, doesn’t ensure easy adoption by the rest of the company. Team members may cling to the old way of doing things, because it’s comfortable, habitual and in some ways, “ain’t broke” (so don’t fix it).

In cases like this, I find the best strategy to get buy-in from team members and fight resistance to change is to hold up a mirror to allow them to see things as they truly are.

So, in that company, I then asked people in the quality department, “ Are you really writing test protocols for each individual test run in Word? And then you have to print them out and then run around to get signatures?”

“Yes, this is what we do.”

At this stage, I pointed out that 80 percent of their time is spent preparing the test protocol on paper, with only 20 percent spent on the execution. Flip flop that equation with 20 percent spent on documentation and 80 on testing, and not only is it more efficient, but also job satisfaction skyrockets, as these team members didn’t study physics to collect signatures on paper.

There are also certain times of the year that are ripe for supporting this critical shift in the organization-wide mindset. Take for instance the annual Medica show in Germany that happens each November. Every IT company wants to present its newest software release, so by August, everyone goes into overdrive trying to figure out how to hit this important milestone.

The annual mad dash can be easily solved with a solid Computer Systems Validation (CSV) process. And while it’s for the good of the company, each team member also personally benefits from being part of a successful launch and ongoing validation. Thus the battle for the hearts and minds of every person involved in the process is won by moving to paperless validation.

Because in today’s global world, innovating solutions is the best way to rocket a project — and a company — to success.

Markus Roemer will speak on the topic of a sensible and compliant approach to Computer System Validation (CSV) for Jira and Confluence at the one-day conference, “Practical Solutions in CSV and SDLC for GXP & MedDev” on 3 October in London.

Thanks to Keith Williams for writing this article, as a preview to the upcoming conference on Practical Solutions in CSV and SDLC for GXP & MedDev (London, 3/10/2018)

Data is the lifeblood of any Life Sciences company – and trust is the heart.

For those of us that manage data, we cannot and will not allow drugs or medtech devices to be on the market unless we are certain about the integrity of the data that’s been associated with the research, development and production of those products.

This is, quite literally, a matter of life and death.

The shift in the management and storage of data into an electronic environment has particular challenges, as there are now masses of data that we don’t have control of — and recent trends make clear how critical it is we address this issue. The FDA reports for the last several years (from 2014 on) reveal a significant uptick of warning letters, with data integrity as the subject.. These include shared passwords, inability to verify data or audit trails, failure to review electronic data or contemporaneously recorded information, and so on.

If we are talking about the context of software or an application that is being marketed as a medical device, then it is incumbent on us that we do all we can to ensure that the correct procedures and processes are in place to create that software/application. That effort will support gaining the trust of regulators, and in turn, the public, who must have confidence that they’re buying efficacious, safe products.

To do so, you must understand the differences between data integrity and data quality in our industry, and create a common language for the gatekeepers that guide – and guard – them each.

What is data integrity & who’s in charge of it?

Data integrity has been an issue since ancient times, when information was first recorded on papyrus or in stone. What held true then remains to this day.

In order to ensure its veracity, data must be attributable, legible, contemporaneous, original (or if copied, unmanipulated), accurate, complete, consistent, enduring and available.

In medtech companies, it’s actually the quality managers who are focused on data integrity. These gatekeepers can be considered the protectors – the people whose job it is to ensure compliance so that their products are safe and efficacious.

What is data quality & who’s In charge of it?

While the focus of data integrity is to provide a value that can be both trusted now and in the future, the focus of data quality is to provide attributes that are related to the data value itself, such as context, metadata, and so on. This allows the data to be easily, efficiently and accurately sorted, searched, filtered and managed for use in a variety of contexts.

In medtech companies, the people who deal with the nuts and bolts of data, such as those who work in IT, engineering or process, are concerned with data quality. These gatekeepers can be considered the innovators — the people responsible for new software, features in medical devices and product releases.

The great communication divide

Data issues, like so many other business challenges, often are rooted in corporate culture.

It’s common for the leaders in a given organization to have a poor understanding of information technology. When an IT group is made responsible for all computing and software systems, and the people in that department don’t have an industry quality or compliance background, then data integrity is at risk.

Similarly, the quality units and other compliance stakeholders often have a poor understanding of how information systems work. This makes it extremely difficult for them to follow the data and work out the weak points.

Worse, this lack of understanding on both ends, between the innovators and the protectors, leads to a communication breakdowns, as neither speaks the other’s “language.”

How to bridge the data gap for greater success

Once you understand the difference between data integrity and data quality, then you can turn this common challenge into a massive opportunity to vastly improve business efficiencies. By introducing a language that innovators and protectors alike can speak, all elements of data can then be managed effectively – and compliantly.

In my opinion, the best way to bridge the gap is with a company-wide, paperless Computer Validation System that includes an integrated collaboration platform.

From my experience, the organizations that are more modern in their thinking and see their business as end-to-end are the winning companies of today, and I believe, in the future.

Those that struggle with old silos of capability, understanding and rigid job hierarchies — which unfortunately tend to be the bigger, more established companies — will be left behind.

The question is, will you help bridge the gap between the “protectors” and “innovators” in your company, and get the most efficiency in your business by understanding their language and what drives them, or will you just keep the same old traditional pharma hierarchies?

Keith Williams will speak about data integrity from a practical perspective. He’ll take a deep dive into real-world data, including examples from GMP,  including examples from GMP at the one-day conference, “Practical Solutions in CSV and SDLC for GXP & MedDev” on 3 October in London.

At a recent knowledge sharing and networking event in London, England, life science industry professionals gathered to glean insights from experts on the common challenges experienced in implementing effective quality systems.

While there were many important points made, the one consistent takeaway was that the key to practical QA and compliance is the reduction of waste.

This ultimate truth was expressed in a variety of ways across the various presentation. The following offers a snapshot of how a broad range of businesses and consultants see the importance waste reduction in the life sciences industry:

Digital shreds paper… and outdated systems, too

Stellan Ott of Wolfram Ott & Partner, a software company that manages the weighing of ingredients for pharmaceutical manufacturing, needed a dynamic, accurate, traceable quality system. The nearly six-year undertaking entailed applying Capability Maturity Model Integration (CMMI) based processes to automate validation activities and reduce other types of waste through the application of various agile software (Scrum) methodologies. Using the Microsoft team foundation server as the electronic platform for the project, Ott and his team managed to substantially reduce waste by eliminating repetitive, mundane administrative tasks, allowing developers instead focus the majority of their work day on development.

Today, thanks to the new system, Wolfram Ott & Partner routinely passes GXP audits with flying colors and has also experienced a positive overall shift in corporate culture.

Busting release documentation bottlenecks with the right digital platform

RadBee founder, Rina Nir, uses Jira and Confluence as the operational backbone for many projects – especially for those clients engaged in software development, which demands detailed, compliant release documentation. The possibility to configure these tools to support virtually any business process make them the perfect platforms for life sciences companies’ eQMS, including the review, approval and usage of controlled documents. From the automation and streamlining of “read & understand” trainings on an enterprise scale to a “one button creation” of release documentation, the powerful combination of Jira and Confluence mimizes time, effort and resources and makes it possible for companies to release fast and often.

Resisting change is the ultimate waste

Making large shifts, for example to paperless validation, is monumental – and for many companies, change is seemingly impossible. Consultant Markus Roemer is expert in guiding companies in innovating their systems so that compliant digital validation can happen now… and in the future. In his work, he frequently sees teams cling to outmoded QA practices. Markus cautions that if you hear someone boast about how their company uses GAMP5 for QMS (which is so large that nobody actually uses it), brag that their process was approved by the FDA (who doesn’t approve processes) or even that their system is 21CFR certified by their vendor (such certification is not possible), then you know you’re dealing with an organization that’s officially stuck. Empty claims aside, the truth is that all that’s needed is a solid digital Computer Systems Validation (CSV) process and a cultural shift to move from paralysis to productivity.

Digitised design control = DHF sustainability

Today, every stage of a regulated development cycle, from first submission through ongoing, annual or semi-annual iterations is critical. From delays to audit failures and recalls, challenges to timely product releases and updates abound. Want to preserve the integrity of your release, while at the same time streamlining and accelerating it? Laurence Sampson of Siemens recommends a closed-loop digital development cycle . Digitised design control is the key for a smooth launch to ongoing updates, and all points in between. This message was reinforced by Carl Pullen, from Cambridge Design Partnership, who shared his experience with using Siemens Polarion to do requirements engineering for a big pharmaceutical company.

Data integrity & quality saves resources – and lives

Nowadays, data integrity and data quality must co-exist in order for organizations to be effective, efficient, and sustainable. This may sound logical, but when the various gatekeepers get in the mix – all of whom speak a different language and have different priorities – reason often goes out the door, and along with it, the successful launch of many life-saving technologies. But, as consultant Keith Williams notes, this common challenge can be turned into a massive opportunity for life science companies to vastly improve their business efficiencies by implementing a company-wide, paperless CVS that includes an integrated collaboration platform.

Mind the gap: compliance is your bottom-line business game changer

In 2017 Epista Life Sciences pioneered a novel methodology that actually measures compliance in pharmaceutical, medical devices and biotech companies. According to Klavs Esbjerg, CEO and founder of Epista, the findings were telling: the same company that believes it “documents everything” – presumably to convince regulators that they are compliant – often doesn’t anchor their quality systems to anything that’s related to the actual processes. Compliance challenges ultimately are business opportunities: in fact, 75-percent of the companies Epista surveyed said regulatory requirements take precedence over business requirements and overrule business requirements, also at a strategic business level. Their bottom line recommendation? Life science companies must focus more on their processes and better integrate quality management departments to ensure they’re aligned with both business and compliance requirements. This allows organizations to quickly and easily pivot to focus on meaningful issues, for example, responding to price pressures and regulatory compliance, or overcoming technical challenges such as adapting cloud-based solutions, integrating AI, etc.

In the end, all of the contributing experts agree: old paper-filled environments need to be tossed in the dustbin, and new, facile digital methods must be employed by modern life science companies who want to remain competitive.

If you enjoyed these highlights and takeaways from our recent event, Practical Solutions in CSV and SDLC for GXP & MedDev, please contact us. We are planning future events now and will keep you posted. And please feel free to let us know what topics you’d like to see covered as it relates to devising and maintaining an effective eQMS.

Created by quality assurance experts and Atlassian Solution Partner, Radbee,
the app’s hands-free assignment supports improved productivity.

LONDON, United Kingdom, April 3, 2019: Life Sciences companies extensively use Read & Understood training to simplify compliance, yet the process is complicated by the burden of administration on Quality Assurance (QA) managers. Inspired by their work developing custom, automated, compliant training solutions for enterprises, Radbee has now made it possible for all life sciences companies to access a robust turnkey solution with their new Read & Understood Training Genius app for Confluence.

The app helps break through bureaucratic logjams with its intuitive automated process, easy-to-use dashboard and real-time, accurate training reports. QA managers are thereby empowered with greater control – they simply set the training matrix rules and the Training Genius takes it from there.

“At the organization where we had our light bulb moment for the app, we observed that QA managers routinely spent upwards of an hour to onboard employees, just to locate and manually assign necessary training pages,” says Radbee CEO Rina Nir. “And that same hour needed to be spent anytime anyone changed roles, exited the company, returned from maternity leave and so on. We knew there had to be a better way to not only support the managers, but also make it easy for auditors to confirm compliance.”

Additionally, the app provides significant management support as well. All data can be exported to Excel and used as a powerful management tool to track KPIs, including how quickly people train and which departments are more responsive than others.

Team members enjoy a personalized view of their training obligations, with automatic nudges via email from the system to complete anything outstanding.

“Our objective is always to help make compliance easier and organisations achieve more,” adds Nir. “The Read & Understood Training Genius app supports a path to better healthcare for all – a worthy goal Radbee is happy to assist life sciences companies attain.”

For more information, please visit the Radbee Read & Understand Training Genius app for Confluence on the Atlassian Marketplace.

About Radbee
Radbee is an Atlassian Silver Solution Partner dedicated to make quality management processes easier and more accessible for life sciences companies. Radbee’s leadership, headed by CEO Rina Nir and her team, knows how much time, effort and resources are spent on compliance vs. what truly matters: releasing quality products that support better healthcare for all. Radbee is on a mission to help QA managers in medtech, biotech and pharma make a difference, get more done and improve compliance.

Contact:
Trudi Roth, RadBee Ltd
Tel: +44 (0) 1223 234 992
Email: press@radbee.com