It has almost become routine: under narratives of increased patient safety and improved efficiency new regulatory requirements are developed, resulting in increased requirements on the industry. The new European pharmacovigilance legislation and the upcoming European medical device regulatory updates are only two examples. Being part of the industry you have very limited impact on the regulations but have to comply with them anyway. That is – if you were to continue marketing your device or drug. Under certain circumstances the cost of meeting legal requirements is so great it may bring into question the viability of continuing certain business activities. This is especially the case for smaller companies or niche products.

1. The quality system is, in itself, a high maintenance object which consumes ongoing resources:
   • It needs to be revisited often due to changes in the regulatory system or in the business environment.
   • Each change may affect many components of the system and a quick modification may cause inconsistency.
   • Each modification needs to be accepted, signed-off formally by several people and be disseminated via formally recorded training.
   • The organization should withstand audits and inspections in regards to the quality system.
2. Living with the quality system: Each SOP and work instruction has to be followed, and typically forms need to be filled, signed and filed.

Young companies which are just embarking on the regulatory path often do not realize these two characteristics of the quality system. Quick fixes in the form of SOP texts copied from other organizations or generic templates are being used to get the initial certification. However, as the organization evolves it realizes that a quality system is not a one-time effort and cannot be glued on from external sources.  It has to be streamlined and become part of the way that the organization lives and does business. Companies are enjoying the benefits of improved process design and automation on a large scale every day, in many areas. When recently did you see a delivery person arriving to a pickup without a Barcode reader, so that he does not need to fill any form manually? When was the last time that a software package was released without an automatic consistency check? So too your quality system and related processes may be dramatically engineered to serve you better.

1. Accept the fact that the quality system is a long term commitment and that it is very demanding.
2. Assume that the right software tools do help.
3. Think strategically, reviewing the whole standard, and try to identify the different areas, in respect to what type of software would help address those.

1. Document management: These are the various requirements relating to the procedures, manuals, and device related documents you need to have, and how they should be handled within the organization. The ISO elaborates in quite a detailed manner about how the controlled documents needs to be approved, who should access them, etc. Confluence is the key tool we use to handle all these requirements.
2. Procedures and records are the evidence that the organization lives up to its quality system: The various procedures and work instructions should be followed consistently on a daily basis, forms or other records should be collected as evidence. Some examples (with reference to the standard section):
   • Training( 6.2.2).
   • Customer complaints: (8.5.1).
   • Corrective and preventive actions: (8.5.2, 8.5.3)
   • Subcontractor approvals( 7.4.1)
   • Purchasing forms( 7.4.1).

Those records may be created as electronic or physical paper forms which need to be completed by the authorized person. However, a much better way is to implement an automatic workflow that makes it easier for the team to create, follow, and document all the various tasks they need to do. Such a workflow can automatically schedule tasks, remind and alert, thus triggering better compliance to the quality system and at the same time automatically creating the required records. This is a double win. JIRA® is our tool of choice and it provides a state-of-the-art solution to everything related to forms and workflows.

3. Design control: Some of the issues covered by section 7 of the ISO 13485 require quite advanced control along several phases of design and development. The risk mitigation measures and the product requirements should be, for example, verified in the product verification stage. This verification, or the test file, could be written as a simple Word or Excel document, but a far better implementation is to create it within JIRA. The advantage of JIRA here is the various reporting that it allows once the data is in and the fact that it can connect directly into the work scheduling of the various team members. JIRA is the principal tool we use for design control. Confluence can be used in some advanced implementations. If the medical device involves software, then the development suite from Atlassian can be implemented to provide a complete software life cycle management suite.
4. Manufacturing and product traceability: Some requirements relate to your manufacturing setup. Depending on the scale and type of manufacturing, specialized ERP may be the best option. When manufacturing is more basic and does not call for a full blown manufacturing facility, JIRA can handle the requirements of the standard.
5. Monitoring and improving: A key theme of the standard is the need of the organization to measure and improve (for example, section 8.2.3). The nice thing is that the framework we have put in place to support the other categories, if done correctly, should provide us with the reports, alerts, and statistics we need. Indeed, all the processes we have implemented in JIRA, as well as the various elements we have implemented in Confluence, may easily be collected and displayed in practically endless variations of reports and dashboards.

Recently I was invited to give a Process V&V presentation at the Medtec UK conference in London. My challenge was to create a presentation which is accessible to an audience with very different backgrounds: I wanted to introduce the newbies to the subject but have enough meat to keep the experts.

My solution was to involve a group of subject matter experts: I made 8 interviews and picked on the minds of people who are involved with V&V in different levels. I then distilled the input I got, in combination with my own experience, into six focus areas which are key to a successful process V&V. These six areas are:

1.    Gain CEO commitment.

2.    Establish a multidisciplinary team.

3.    Start Early.

4.    Know your suppliers and sub-contractors.

5.    Map your process.

6.    Manage the manufacturing records.

Each focus area is demonstrated by real life examples and rich imagery.

The audience loved the presentation!  You are now very welcome to watch it yourself, download and share forward.

Example 1: QMS entry/initiation points

Example 2: SOP related knowledge base

While JIRA is already a great platform for issue tracking and business process management, we find that boosting it with plugins makes it much more useful for quality management purposes. Here we list some of our favourites and explain the value they add.
Note: At the time of writing, all these plugins are only available for JIRA Server instances.

Electronic Signature (InTENSO Labs)

This plugin addresses the electronic signature requirement of FDA CFR 21 Part 11. I love it because it removes the need to create signature records separately from the process and saves on paperwork.
It’s also very easy to configure. Simply define an ‘InTENSO Electronic Signature’ custom field for each signature you need to collect in a process. For example, if the customer support team needs to sign off a customer issue before closing it, just add an electronic signature field to the relevant form.

A couple of points to bear in mind:

1. This plugin fulfils only the electronic signature requirement of FDA CFR 21 Part 11 compliance. The audit trail, which is the second major requirement, is built into JIRA by default.
2. The plugin has a few options that can be configured by system administrators. Some of them are crucial for compliance, for example the one that means the sign-off can only be performed by the user logged in at the time. Beware that the default settings are not always compliant with the legislation and you will also need to make sure the settings you select comply with your organisation’s own policies.

nFeed (Valiantys)

The nFeed plugin can be used in many contexts, but we usually use it to achieve one particular effect – to link two issues in a way that’s more specific than JIRA’s built-in ‘issue links’ mechanism allows.
For example:

• JIRA maintains your list of training topics, eg sterilisation process training and customer issues training, as well as your actual training tasks (ie training particular people on specific training topics). The nFeed plugin allows you to populate fields in a training task using information from the equivalent fields in the relevant training topic.
• When a corrective and preventive action (CAPA) is created as a result of a nonconformity, nFeed allows you to indicate the specific nonconformity record in the ‘source’ field of your CAPA.
  nFeed comes with good documentation and support. However, to configure it you will need at least a basic understanding of SQL and HTML.

Dynamic Forms (InTENSO)

This plugin allows you to define the appearance and behaviour of one field in a screen based on those of other specified fields. We use it to promote best practice in the way processes are managed.
Often a quality management process will have to accumulate different information depending on the data users put in. For example, when handling a CAPA, it’s good to have a checklist of questions that encourage (or force) users to consider particular things. If a user answers ‘yes’ to a certain question, Dynamic Forms will enable another relevant question to appear, like this:

• Could this CAPA affect risk management?
  • Can you provide a short explanation of how?
• Is the CAPA related to a process or a product?
  • Which process or product?
• Has a similar CAPA been raised in the past?
  • Which CAPA was it?

Dynamic Forms allows us to ask all these questions without overloading the JIRA forms. Only the first level questions will appear on the screen and the additional fields will only appear, dynamically, as appropriate.
This means the forms look simple, despite being geared up to collect a high degree of detail. That makes for a much better user experience without compromising on the quality and depth of information collected.

JJUPIN (Kepler Rominfo)

Last, but definitely not least, the JJUPIN plugin extends the workflow processing capabilities of JIRA almost indefinitely. It makes it possible to tie sophisticated business logic and automation into the processing of issues.
I’m yet to encounter a quality management process flow that can’t be implemented with a few short JJUPIN scripts.
Here are some examples of where JJUPIN scripting can come in handy:

• If a nonconformity has triggered the creation of a CAPA, we can prohibit the closure of the nonconformity until the CAPA has been validated.
• If a CAPA has been validated, and an effectiveness check is not required, we can skip this default behaviour and close the CAPA.
• An engineering change request (ECR) will have many subtasks associated with it, such as design activities and completing documentation. We can enable the ECR to move automatically to a new status once all associated subtasks have been performed.

There are other powerful automation and scripting plugins in the JIRA marketplace. However JJUPIN requires the shortest learning curve and the most limited understanding of JIRA’s internal structure. All the scripting can be done directly from JIRA’s user interface, using a basic information model to represent the complex Java programming that’s actually at work behind the scenes.
Anyone who has ever programmed in C can quickly master scripting with JJUPIN to implement automation in JIRA.

Plugins like these enable us to tailor JIRA to meet the needs of a wide variety of life sciences companies. If you’d like to find out more about how we could help you transform your quality assurance workflows with JIRA, please get in touch.

Confluence comes with built-in document version management. Each time a document is modified then saved, a new version is added to the history and automatically tagged with a version number, starting at v.1, then progress through v.2, v.3, etc.
This innate versioning mechanism provides a host of features:

• The document history is easily accessible through the tools menu on every page, providing details such as the user who made each change and the time it was modified.
• Each time they save the document users have the opportunity to add comments summarising the changes they’ve made. These will appear together with the history.
• Each previous version is still accessible, and it’s possible to compare any two historic versions.

Let’s call this version saved with Confluence’s own versioning mechanism the ‘internal version’ of a document.

How does this apply to controlled documents?

In the case of controlled documents, a new version of the document usually means a new approved and finalised version. Let’s call this the ‘official version’.
In between two consecutive official versions there would typically be quite a few internal versions, reflecting several authoring and review iterations that occur before it’s approved.
The naming convention for official versions will depend on an organisation’s preference. Some stick with 1, 2, 3. Others apply multilevel numbering, inspired by software releases. In this case whether the version number will increase from 1.2 to 1.3 or 2.0 might depend on the nature of the modifications or other factors.
How to register and maintain the official version of controlled documents is one of the essential decisions to make before making the switch to Confluence. I’ve seen several methods implemented in different organisations, ranging from simple to complex.
There’s no right or wrong approach, and what will work best for your organisation will depend on your specific circumstances. However here are three options for implementing official version numbering that you might like to consider:

Option #1: Using Metadata Plugin

Metadata Plugin is a free plugin for Confluence, which is one of those ‘must install’ plugins for any Confluence installation. As its name suggests, it makes it possible to add metadata to documents. You can add a metadata field called ‘Version’ and update the value for each new official release.
This metadata will become part of each page, and will be displayed wherever you choose – typically right at the top of the page. You can use the same mechanism to bring together other metadata, such as the document number, department and product, in a single table. Making this metadata part of your template is the best way to ensure that everyone uses it consistently across all controlled documents.
The metadata can then be pulled into reports. Metadata Plugin comes with its own reporting feature, however it’s also possible to use various other plugins to provide additional metadata reporting facilities.
If you then want to export a document to Word or PDF, we always recommend using K15t’s Scroll Exporter plugins, rather than the native Confluence export facility. This will enable you to easily incorporate your metadata information into the header or footer of the exported document.

Pros:

• It’s easy to implement, with a single free plugin and the addition of a table to your controlled document template.
• It’s easy to use.
• The version information is accessible for reports through the metadata mechanism.
• Metadata Plugin is available free through the Atlassian Marketplace and is compatible with other reporting plugins.
• Your organisation is free to choose the most appropriate naming convention.
• The metadata table can be located anywhere on a document.
• Using Scroll Exporter plugins makes it possible to keep the metadata showing when the document is exported to Word or PDF.

Cons:

• Each author or editor is responsible for manually inputting or updating the version number. This may lead to errors, such as inputting the wrong version value or failing to update it when a new official version is published.
  That is likely to be more of a problem in larger organisations where many authors are involved in releasing documents, making it more difficult to enforce uniformity.

Option #2: Using Comala Workflows plugin

The down side of option #1 can be avoided by using the Comala Workflows plugin to automate the page release process.
As long as the version numbers increase in straightforward consecutive order – 1, 2, 3 etc – it’s possible to adjust the script to automate the process using this technique.
The solution relies on a workflow accessing and manipulating the metadata. Unfortunately the scripting language doesn’t support mathematical operations directly, so modifying the script to increase the version number requires a creative approach.
Here’s an example, using notation based on Workflow Supplier:

Step 1: Initiating two metadata values when a page is created

officialVersionCount uses a string of a particular symbol, eg ‘+’, to represent the number of released versions.
recentOfficialVersion is the name of the last version released.

When a document is first initiated these strings will be empty, as no version has been released yet.

{comment}
**** Initializing the two metadata values (to null) upon creation of the page.
{comment}
{trigger:statechanged|state=draft|initial=true}
{set-metadata:officialVersionCount}{set-metadata}
{set-metadata:recentOfficialVersion}{set-metadata}
{trigger}

Step 2: Updating the metadata values related to the version when it’s released
The length of the officialVersionCount is extended by a single character, eg ‘+’.
recentOfficialVersion is set to reflect the size of officialVersionCount.

{comment}
**** Once the page is approved, update metadata information
{comment}
{trigger:statechanged|state=Approved and pending training}
{set-metadata:officialVersionCount}@officialVersionCount@+{set-metadata}
{set-metadata:recentOfficialVersion}@workflow:metadata > officialVersionCount > size@{set-metadata}
{trigger}

Pros:

• Offers all the advantages of option #1.
• It also enables automated version numbering.

Cons:

• It requires implementation of a Comala Workflows release process, this is not a downside if you need to implement it anyway.
• There are limitations in business logic and numbering convention.

In theory this method could be extended to support multilevel numbering, however, in that case it would be more straightforward to use Option #3.

Option #3: Using a listener

This technique is more complex to implement but makes it possible to automate more complex official version numbering.
This approach assumes that there is an agreed convention (within the particular Confluence instance) of how a document is released. For example:

• A process is implemented, which includes a specific release stage (this may be achieved using Comala Workflows, but there are other options too).
• Special labelling (eg ‘released’) is added only to released documents, but not to drafts.
• A document is released by moving it to a different space.

We can use this convention to detect the release of a new official version and automatically update the metadata of the page with a new version number.
This type of plugin is called a ‘listener’ and requires programming. The actual code for the plugin will depend on the event you want to capture (in this case, the release event) and the version numbering structure you want to apply.

Pros:

• Offers all the advantages of options #1 and #2.
• It also makes it possible to automate more complex version numbering.
• You can implement this approach without using Comala Workflows.

Cons:

• It requires the development of a dedicated listener plugin.

Whatever your version numbering convention for controlled documents, we should be able to automate it for you as part of the process of moving to Confluence.

When considering using Confluence to develop and release controlled documents, one of the main concerns many companies have is whether they will be able to approve the documents directly from the application.
This is possible using Comalatech’s Comala Workflows plugin, which allows us to configure your desired approval workflow right into Confluence.
This plugin has the two key components required for FDA CFR 21 Part 11 compliance:

• each approval step can be linked to an electronic signature
• and each approval activity is logged in a dedicated page activity report, creating an audit trail.

This makes it suitable for the controlled document process in organisations that need to adhere to good manufacturing practices (GMP) and other stringent regulatory frameworks. Figure 1 below shows a screenshot of an example report.

Deciding on the approval process

Once the Comala Workflows plugin is installed, you’ll need to decide on the approval process you want to use. Many teams don’t have a formally defined approval process until they decide to manage their controlled documents in Confluence. Until then approval often depends on various people adding their signature to a final draft once it has been reviewed.

In fact the informal review phase leading up to final approval is often very important, making it possible to incorporate the feedback of many stakeholders. Fortunately a variety of collaboration features built into Confluence facilitate this.

Installing the Comala Workflows plugin makes it possible to follow the informal review with a formal review and approval phase, where approval and electronic sign-off are logged on the system. This stage can replace your existing paper or electronic sign-off.

One of the interesting aspects of the plugin is that it makes it possible to apply different review and approval processes to different controlled documents, using a single workflow definition. This is helpful, because some documents by nature demand a more complex approval process than others. Obviously, it’s also possible to define several separate workflow scripts to use in different cases.

Below is an example of the code involved in an approval workflow, which demonstrates many of the features available. First, figure 2 shows a brief overview:

Approval workflow work example

The workflow below is tested for the following configuration:

• Confluence server 5.7.3
• Comalatech workflow 4.8.2

We’ve added a few notes within the script for clarity.

{workflow:name=Controlled document workflow (demo)  1|key=com.radbee.controlleddoc2.demoworkflow.01|label=demoworkflow|stickylabels=controlleddoc}
    {description}
        A controlled document needs to be approved by various stakeholders and by QA person. Optionally- A review cycle may also take place prior to the approval cycle.
    {description}
    {comment}
    *************************************
    ****** workflowparameters
    *************************************
    {comment}
    {comment}
    *************************************
    ****************** workflowparameters: Non editable
    *************************************
    {comment}
    {workflowparameter:Organization options}
        Operations, Research, Quality, Administration
    {workflowparameter}
    {comment}
    *************************************
    ****** workflowparameters: all these are editable (per page)
    *************************************
    {comment}
    {workflowparameter:Document ID|description=Is NA if this is a new document with no ID set.|edit=true}
        NA
    {workflowparameter}
    {workflowparameter:Organization|type=list|options=@Organization options@|edit=true}
        Operations
    {workflowparameter}
    {workflowparameter:Training|type=list|options=Required, Not required|edit=true}
        Required
    {workflowparameter}
    {workflowparameter:Who needs to approve|type=list|options=Only QA, QA and others|edit=true}
        Only QA
    {workflowparameter}
    {workflowparameter:Author|type=user|edit=true}
        @creator@
    {workflowparameter}
    {comment}
    *************************************
    **** Charlie is the default QA approver. It is possible to change the QA approver for specific page through the workflow settings for that page.
    *************************************
    {comment}
    {workflowparameter:QA approver|type=user|edit=true}
        charlie
    {workflowparameter}
    {comment}
    *************************************
    ***************** States
    *************************************
    {comment}
    {state:Draft|approved=In Review}
        {state-selection:states=In Review,In Approval|user=@Author@}
    {state}
    {state:In Review|approved=In Approval}
        {approval:Assigned reviewers|assignable=true}
        {approval:Revert from In Review to Draft|user=@Author@}
    {state}
    {state:In Approval|approved=In QA Approval|updated=Draft}
        {approval:Assigned approvers|assignable=true|credentials=2}
        {approval:Revert from In Approval to Draft|user=@Author@}
    {state}
    {state:In QA Approval|approved=Approved and pending training|updated=Draft}
        {approval:Assigned QA approver|user=@QA approver@|credentials=2}
        {approval:Revert from In QA Approval to Draft|user=@Author@}
    {state}
    {state:Approved and pending training|updated=Draft|expired=Published|taskable=true|duedate=PT2M|changeduedate=true}
    {state}
    {state:Published|final=true|updated=Draft}
    {state}
    {comment}
    *************************************
    ********************** Triggers
    *************************************
    {comment}
    *************************************
    **** the user who cause the page to go into draft mode, is assigned to be the "author" in the workflow.
    **** because of the other constraints in the workflow, an author can change only when a page is published 
    **** and the work on the next version is initiated, not in midst of a review/approval cycle.
    *************************************
    {comment}
    {trigger:statechanged|state=draft}
        {set-metadata:Author}@user@{set-metadata}
    {trigger}
    {comment}
    {comment}
    *************************************
    **** If training is not required, move directly to publishing.
    *************************************
   {comment}
    {trigger:statechanged|state=Approved and pending training|@Training@=!Required}
        {set-state:Published}
    {trigger}
    {comment}
    *************************************
    **** If "only QA" needs to approve, skip the "In Approval" state.
    *************************************
    {comment}
    {trigger:statechanged|state=In Approval|@Who needs to approve@=Only QA}
        {set-state:In QA Approval}
    {trigger}
    {comment}
    *************************************
    **** Publish the page to the "published space". This depends on the Comala Publishing plugin.
    *************************************
    {comment}
    {trigger:statechanged|state=Published}
        {publish-page}
    {trigger}
    {comment}
    *************************************
    **** A bunch of triggers to send emails on approval assignments to the concerned users.
    *************************************
    {comment}
    {trigger:pageapprovalassigned|approval=Assigned reviewers}
        {send-email:user=@assignee@|subject=@content:title@, is pending your review}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:pageapprovalassigned|approval=Assigned approvers}
        {send-email:user=@assignee@|subject=@content:title@, is pending your approval}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:statechanged|state=In QA Approval}
        {send-email:user=@QA approver@|subject=@content:title@, is pending your approval}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {comment}
    *************************************
    **** A bunch of triggers to send emails on approval events. 
    **** Note the way that the Full Name of the user is retrieved.
    *************************************
    {comment}
    {trigger:pageapproved|approval=Assigned reviewers}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, review by @workflow:metadata > usertmp > full name@ completed}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:pageapproved|approval=Assigned approvers}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, approval granted by @workflow:metadata > usertmp > full name@}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:pageapproved|approval=Assigned QA approver}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, QA approval granted by @workflow:metadata > usertmp > full name@}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {comment}
    *************************************
    **** A bunch of triggers to send emails to author in regards to rejection events.
    *************************************
    {comment}
    {trigger:pagerejected|approval=Assigned reviewers}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, was rejected by @workflow:metadata > usertmp > full name@}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:pagerejected|approval=Assigned approvers}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, was rejected by @workflow:metadata > usertmp > full name@}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {trigger:pagerejected|approval=Assigned QA approver}
        {set-metadata:usertmp}@user@{set-metadata}
        {send-email:user=@Author@|subject=@content:title@, QA approval rejected by @workflow:metadata > usertmp > full name@}
        The latest draft can be viewed here: @pagelatest@
        {send-email}
    {trigger}
    {comment}
    *************************************
    **** Apply edit restriction on a page during the review andapproval stages.
    *************************************
   {comment}
    {trigger:statechanged|state=In Review}
        {add-restriction:type=Edit|user=@Author@}
    {trigger}
    {trigger:statechanged|state=In Approval}
        {add-restriction:type=Edit|user=@Author@}
    {trigger}
    {trigger:statechanged|state=Published}
        {remove-restriction:type=Edit}
    {trigger}
    {trigger:statechanged|state=Draft}
        {remove-restriction:type=Edit}
    {trigger}
    {comment}
    *************************************
    **** Trigger the move of the page to draft during review/approval stages (as this can only done manually during the review and approval stages).
    *************************************
    {comment}
    {trigger:pageapproved|approval=Revert from In Review to Draft}
        {set-state:Draft}
    {trigger}
    {comment}
    *************************************
    **** Because of the fact that there is a second approval on this state (which allows the author to move the page to draft)
    **** then, in the case that the review is approved we need to proactively trigger the page into the next stage.
    *************************************
    {comment}
    {trigger:pageapproved|approval=Assigned reviewers}
        {set-state:In Approval}
    {trigger}
    {trigger:pageapproved|approval=Revert from In Approval to Draft}
        {set-state:Draft}
    {trigger}
    {trigger:pageapproved|approval=Assigned approvers}
        {set-state:In QA Approval}
    {trigger}
    {trigger:pageapproved|approval=Revert from In QA Approval to Draft}
        {set-state:Draft}
    {trigger}
    {trigger:pageapproved|approval=Assigned QA approver}
        {set-state:Approved and pending training}
    {trigger}
{workflow}

Some key points.

The role of ‘Author’ and the review process

‘Author’ is a workflow parameter. When a document is created, the role of Author is assigned to the user who created it, and is reassigned every time someone moves the page back into draft status. So, essentially, any person initiating a change becomes responsible for taking the document through to approval (see lines 81 etc).
The Author can edit a document without causing it to revert to draft. They may also choose to revert a page to draft by manually approving a ‘Revert to draft’ (see lines 201 etc.)
Only the Author has the permission to edit a page while it’s in review (see lines 176 etc).

Note that, for edit restriction to work properly, the configuration parameter of ‘Space Tools > Workflows > Configuration tab > Workflow Activity and Drafts Visibility’ needs to be changed to ‘Anybody’.

Use of workflow parameters to control the review and approval process

1. The identity of the default ‘QA approver’ – the person who needs to approve a document – can be changed for each document using the relevant workflow parameter.
2. Approval by ‘QA approver’ is obligatory, but only certain documents will need additional approval. In order to simplify the approval process where appropriate, you can just change the ‘Who needs to approve’ setting (see line 93 etc).
3. If training is required before a page can be published, you can set a fixed delay within intermediate status, using ‘Approved and pending training’ (see line 66). In the example we’ve set a delay of two minutes, but in reality this can be set to a week or more, as appropriate. Whether the delay happens or not will depend on the workflow parameter ‘Training’, which can be set to ‘Required’/’Not required’ (see the triggers in lines 85 etc).

Email notifications

Emails are sent automatically:

• to participants when their action is required (see lines 110 etc)
• and to the Author when the status of a document changes or when another user approves or rejects one of their documents (see lines 130 etc).

Getting started

For more details you can refer directly to Comala’s helpful guidance on using the plugin or send us an email.
If you would like assistance with implementing a controlled document approval process using Confluence and Comala Workflows, please get in touch.

Cambridge, UK, 12 October 2015: RadBee Ltd, which specializes in providing software solutions for quality assurance in the medtech, biotech and pharmaceutical industries, has been approved as an Atlassian Expert. This means that RadBee is endorsed to sell licenses for the Atlassian JIRA and Confluence collaboration products to “unleash the potential in every team”. They can provide customer support in the form of project tailoring for Atlassian users; and they can create and sell plugins for the software.

RadBee helps life science companies to reduce their regulatory compliance burden by providing them with customized software solutions based on JIRA and Confluence. These software products enable them to streamline regulatory-documents and quality management processes.

JIRA is a tracking software that, when customized for life sciences quality assurance, makes it easier to manage corrective and preventive actions (CAPAs), nonconformities and customer issues, and to follow standard operating procedures (SOPs). Simple forms, rules and automatic escalations ensure regulatory compliance. Collaboration features help to get everyone in a company engaged with quality assurance (QA), and the intuitive dashboard and reporting show the bigger company picture, helping to highlight opportunities for improvement.
The Confluence collaboration platform enables clients to streamline their controlled document process. It allows multiple parties to work together to create better controlled documents, faster, and by keeping a record of all discussions about a document in one place, ideas and clarifications are easily accessed by users.
Rina Nir, Director of RadBee, commented: “Life science companies are spending significant operational costs on quality assurance, yet too often the time and effort being spent does not contribute to quality, operational excellence, or better products. By combining our understanding of Altassian’s powerful JIRA and Confluence tools with our expertise in the medtech, biotech and pharmaceutical industries, we implement transformative, easy-to-use and compliant quality management systems for our clients.”

Matthew Coughlan, Expert Partner Manager at Atlassian, said: “Although the Atlassian products were developed for the software development industry, 30% of our users are working outside this field, and that number is growing. RadBee are doing a fantastic job of tailoring our software products to meet the needs of the life science market, which is why we have approved the company as an Atlassian Expert.”

RadBee moved from Belgium to Cambridge in November 2011, and has recently taken up residency at St John’s Innovation Centre. Rina Nir added: “Cambridge has grown into one of the world’s leading life sciences hubs, and our services could support many on their journey to safeguard compliance and promote a culture of shared ownership of quality.”

Rina Nir founded RadBee in March 2014, as she saw a need to streamline the quality management processes within life science, biotech and pharmaceutical companies.

About RadBee Ltd:

RadBee Ltd offers software solutions for quality assurance in the medtech, biotech and pharmaceutical industries. By tailoring JIRA and Confluence software to meet their clients’ specific needs, RadBee create quality management systems that make compliance easy and help organizations achieve more.

About JIRA

JIRA is Atlassian’s industry-leading project and issue management software. More than 22,000 companies including NASA, Square, and BMW choose JIRA to capture and organize issues, assign work, and follow team activity. JIRA, when customized for life sciences quality assurance, makes it easier to manage corrective and preventive actions (CAPAs), nonconformities and customer issues, and to follow standard operating procedures (SOPs). Simple forms, rules and automatic escalations ensure regulatory compliance. Collaboration features, including notifications, comments and assignments, help to get everyone in a company engaged with QA. Plus, the intuitive dashboard and reporting show the bigger company picture and help to highlight opportunities for improvement.

About Confluence

Available in the cloud or on premises, Confluence is a team collaboration platform that connects teams with the necessary content, knowledge, and coworkers needed to get work done, faster. When customised, the Confluence collaboration platform enables clients to streamline their controlled document process. It allows multiple parties to work together to create better controlled documents, faster, and by keeping a record of all discussions about a document in one place, ideas and clarifications are easily accessed by users.

For further information from RadBee Ltd, please contact:

Rina Nir, Director, RadBee Ltd
Tel: +44 (0) 1223 234 992
Email: rina.nir@radbee.com

Zyme Communications (Trade and Regional Media)
Lorna Cuddon
Tel: +44 (0)7811 996942
Email: lorna.cuddon@zymecommunications.com

In the beginning there was the SOP. Then a form was created to collect all the necessary data and signatures to prove that the SOP was followed. Then people forgot why the process was developed in the first place, because as long as they filled in the form properly, all would be compliant.
But is being compliant enough? After all, the original purpose of developing standard operating procedures was to keep patients safe. Why are so many resources sunk into meaningless form-filling when you’re meant to be in the business of saving lives?
With JIRA you can go back to basics and make your processes meaningful again.

What difference can JIRA make?

Switching to using JIRA for your quality management system (QMS) does more than improve efficiency. It can also increase the impact of your quality management processes, and the people involved, in a variety of ways:

1. Getting your team actively engaged
   • At each stage of a process, and for each of its related subtasks, team members assigned to an issue will be able to comment on it, contribute ideas and keep track of any changes.
   • The relevant people will receive notifications so they can react immediately as appropriate.
2. Making the quality assurance team the heroes of your organisation
   • Instead of being viewed as its police force, your quality assurance team will start to be seen as leaders, mentors and facilitators of change within your organisation.
3. Allowing managers and their teams to see the big picture
   • Dashboards and automatic reports will ensure everyone has a good overview of the processes they’re involved in as well as access to all the details.
4. Ensuring no issues fall between the cracks
   • Built-in escalation rules will ensure no customer issue is neglected and no CAPA is left without an effectiveness check.
5. Capturing regulatory evidence automatically
   • Data, including audit trails and signatures, will be collected as an integral part of issue processing.
6. Helping you make better decisions, faster
   • Having all the relevant information in one place and access to clear reports with meaningful metrics will facilitate decision-making.
7. Helping your organisation learn and improve over time
   • All historic data will be easily accessible from a single source, including file attachments, links to external resources, free text comments and the complete audit trail of each issue.
   • This will make it possible to refer back to and learn from the way you handled past events.
8. Making sure management reviews address core issues
   • Current and historic data will be readily accessible for trend analysis and statistical investigation.
   • This will make management reviews more constructive and make it quicker and easier to prepare for them.
9. Ensuring the whole team is in synch
   • Everyone will have access to the latest version of your SOPs and each of your controlled documents.
   • There will no longer be a risk of team members working with outdated information or following old processes.
10. Keeping everyone in the know
    • All the relevant information will be easily accessible to all the right people, wherever they are, including when they’re out on the road.

Imagine what difference having a quality management system that delivers on all those fronts could make to your team.
We can create a solution based on JIRA that will do all that for you, without breaking the bank. Get in touch to learn more.

Outside the software development sphere, for which JIRA was originally developed, probably the most frequent quality management process facilitated by JIRA is the corrective and preventive action (CAPA) process.

Here are a few of the reasons why:

• CAPA management is a key quality management process in the pharma, biotech and medical devices fields as well as others, such as the food industry.
• Managing a CAPA can be a very complex process involving multiple steps, which can take a well-coordinated team anything from a few days to several months to complete.
• Because of this complexity, companies invest many resources in performing CAPAs. Managers are keen to have good visibility of how effectively these resources are being used and the efficiency of the CAPA process itself.

If you’re considering switching to using JIRA for your CAPA management, you will inevitably have lots of questions. To help you, I’ve pulled together a few of the questions people most commonly ask us and our answers.

Can we link our CAPAs with other processes, like managing nonconformities and customer issues?

Yes, you can.
CAPAs are triggered from other processes, such as customer complaints or audit nonconformities. A CAPA often also triggers other processes, for example an engineering change request (ECR) or a training activity. Linking CAPAs with the other relevant processes in JIRA helps to provide the full context of the CAPA, avoids the need to duplicate information and efforts and facilitates coherency. Linking can also be used to enforce certain business rules. For instance we can avoid the CAPA being marked as ‘implemented’ before all the related activities are completed.
The way the links work will depend on where the other processes are managed.
If your linked process is managed in JIRA, whether in the same instance or a different one, the link can be customised to implement and enforce business logic. The processing of the two linked issues will be mutually dependent. For example, a nonconformity cannot be closed until the related CAPA has been validated. It is also possible to configure what information about the linked issue will be seen in the CAPA and to adapt the link name to whatever terms you use.
If the other process runs on a system which is not a JIRA instance, it may still be possible to implement a link between the two. JIRA supports a large variety of interface options. In many cases, the exact function of the link will depend on the technical interfaces available on the other system.
Even if the other process is managed in a way that doesn’t support an electronic connection, it should be possible to include a relevant data field in the CAPA process.

 

 

Can we attach files to the CAPA?

Yes, JIRA makes it possible to attach multiple files to each issue. These files may be of any type, and may be added to the issue at any stage.

Can we use metrics to measure our CAPA performance?

Yes, you can use a variety of key performance indicators (KPIs) to measure CAPA performance. These may be based on factors such as:

• the time between the opening of a CAPA and when validation is completed
• the percentage of CAPAs found to be effective
• the number of similar cases reported after a CAPA has been processed
• the number of work hours directly associated with the CAPA.

All the above and many more options can be accommodated. Once a KPI has been defined, a corresponding report may be created. The KPI report can then be displayed within JIRA in a table, pie chart or other format of your choice. Alternatively, you can export the data from JIRA into Excel or a specialist statistical package for analysis.

Can the system notify us when a CAPA is updated?

Yes, JIRA provides a rich set of possibilities to keep you up to date with the various activities. Each user can set up notifications to suit their needs. The options include:

• Email notifications for every update.
• Email digests – You can choose between a daily digest of all CAPAs which were updated that week, a weekly digest of all new CAPAs or a weekly digest of all CAPAs where validation is more than a month overdue.
• The JIRA dashboard – This is a secure web page that displays a concentration of stats and reports relating to your CAPAs. The dashboard is live in two ways: 1) it refreshes at regular intervals to reflect the latest information and 2) the information displayed links directly to the data from which it is derived. That means that in one click you can investigate or act on any information you see on the dashboard. People who work regularly with JIRA tend to keep the dashboard open in their browser continuously and some companies display the dashboard on a big monitor for everyone to see.

Can the system indicate when a CAPA effectiveness check is due?

Yes, JIRA can help with this.
Ensuring follow-ups occur at the correct intervals is one of the sticky areas in implementing an effective CAPA system. When you need to make an effectiveness check on a CAPA will be dictated by a combination of factors:

• Regulations.
• How long it takes to demonstrate that the CAPA has effectively mitigated the reason for its creation.

When you implement a CAPA process in JIRA we can ensure this follow-up occurs at the correct point. The date can either be set manually or be based on defined business logic. The CAPA will then go into a ‘dormant’ waiting status. When the due date arrives, the CAPA will automatically transition to ‘Effectiveness check is due’ status. At this point it will appear on the dashboard and in reports and email notifications, to remind the assigned staff to carry out the appropriate check.

Can using JIRA help us standardise our CAPA process and promote best practices?

Yes, standardisation can be built into the process.
One approach is to use standard checkpoint questions, such as:

• Have non-conforming products been released to the market?
• Could this issue affect other product lines?
• Could this issue affect risk management?

Going through those questions forces the team to carry out an effective analysis of the problem. Once the analysis is done and the CAPA moves to planning and implementation stage, the same questions may be used to create the required actions. In JIRA, these actions are called subtasks.
If, during the analysis stage, it was indicated that ‘This issue could affect other product lines’, an ‘Evaluate possible relevance to other products’ subtask would be generated automatically. If it was indicated that ‘This issue could affect risk management’, a subtask dedicated to performing risk management would be generated.

By building the process in this way, we ensure that all the relevant complexities and possibilities are followed through

What about FDA CFR 21 Part 11 compliance?

This issue deserves a whole post dedicated to it, or even several. However, here are two important examples of how JIRA could help you adhere to the FDA CFR 21 Part 11 requirements.

Electronic signatures

Using an extension such as inTenso’s Electronic Signature plug-in we can enable the relevant people to submit electronic signatures in JIRA. To electronically sign the process a user has to introduce their user credentials on the JIRA transition screen. The signature is then logged together with the issue.

Audit trail

JIRA, out of the box, creates an audit trail for each issue. The trail includes a record of the issue’s creation and any modifications or comments.

 

What about validation?

Some companies opt to create paper copies of the CAPA records, to serve as the master records. This approach is usually motivated by a combination of the following factors:

• It reduces upfront investment in the system compared to implementing electronic validation.
• The compliance officer believes a paper copy has less risk of being deleted or lost then an electronic record.
• A lack of sufficient IT governance resources.

If your organisation is ready to move to a fully electronic system for your regulatory compliance, you will need to develop and implement a validation strategy. Bear in mind that the regulations require that the system is validated within its context of use and with the relevant procedures in place.
This is an area where we work closely with our customers, to provide the support they need to achieve validation and put a good long-term revalidation plan in place.

Can the JIRA implementation of the CAPA process reflect our SOP or form?

Yes, we can configure and customise JIRA to reflect your standard operating procedures (SOPs) or your existing forms.
When a JIRA issue is created, it transitions through several stages to closure (‘Done’ in JIRA language). This is called the issue workflow. Each issue consists of several data fields, including Summary (this consists of the title of the issue, description and creation date).
Out-of-the-box, JIRA comes with several workflows and data fields, mostly designed to suit software development activities. However, it comes with a full set of features that make it possible to define an infinite number of other workflows. This is the foundation that allows us to define virtually any CAPA process in JIRA.
The figures below show schematics of two CAPA workflows that we’ve implemented for clients. Although each one has nuances specific to the organisation, both embody some common CAPA principals.

Life sciences quality management procedures are often awkward. Dotted with their own strange lingo (observation, device master record (DMR), technical file, essential requirement etc), they can take some getting used too. Many seem to be designed with auditors in mind, rather than auditees, with a primary focus of demonstrating an intention to comply with regulations.
One of the most awkward procedures of all tends to be the one for managing issues brought forward by customers, often called a customer complaints procedure. Here are some of the reasons why:

• Prioritising regulatory compliance over customer satisfaction
  In many customer complaints procedures and forms, a significant proportion is dedicated to addressing the regulatory aspects of handling complaints. A brief statement such as ‘We need to update the customer about our actions’ may be the only element that actually relates to resolving the complaint. How to manage a complaint in a way that will delight the customer isn’t taken into account at all.
• Lack of joined-up thinking
  In addition to complaints, you need to handle simple enquiries from customers about usage, billing, maintenance and the like. So why not handle complaints as part of a single strategic approach to customer support and post-sale communications?

As a result of these factors, customer complaints procedures in our industry tend to be compliant but out of context and inadequate for what the business needs. The easiest way to turn this situation around and create a customer support process that works for your team and your customers, as well as the auditor, is by using JIRA Service Desk.
This product comes out of the box with many of the best practices in customer care already embedded. It’s also so flexible that it’s straightforward to set it up to meet the regulatory requirements.
Here are some of its best points:

1. It makes it very easy for your customers to ask for support or submit a complaint
   With JIRA Service Desk in place, a customer simply needs to send an email, which will automatically generate an issue to be processed by your customer support team. The issue can’t fall between the cracks and will be managed according to a defined internal process. This increases the likelihood of resolving your customers’ problems to their satisfaction and remaining compliant.
2. A simple customer-facing process can be coupled with an elaborate internal process to manage customer issues effectively
   For the customer the process will feel like a simple exchange of information leading to a satisfactory resolution. Behind the scenes you can get the whole team involved in several complicated stages of the process, but your customers will see only those bits you want them to.
3. You can guarantee that all the compliance-related boxes are ticked
   With the flexibility and adaptability built into JIRA Service Desk you can guarantee that no procedural aspect related to compliance is being neglected. This will mostly be handled within the internal part of a process, which is not seen by the customer.
4. It allows tailored processes to be put in place for different types of customer issue
   JIRA Service Desk supports tailored work processes for different request types. For example a customer complaint may be handled differently from a request for maintenance.
5. It makes it easier to capture relevant information from your customer
   You can now set up a customer portal, which will allow specific forms to appear depending on the issues your customer wants you to address. For example when someone makes a request for maintenance, the form will prompt them to provide a serial number. If they’re requesting a training session, they may be asked for the number of trainees and their previous experience. This will help your team resolve each issue more quickly.
6. It supports improved response times
   JIRA Service Desk allows you to define your response time targets, or service level agreements (SLAs), and monitor them constantly. This will encourage your team to work proactively towards meeting SLAs, helping your organisation learn and improve in the process. Isn’t this what quality management is all about?
7. It helps you make best use of your team
   The allocation of tickets to team members can be done both by push (assigning a ticket to a specific person) or pull (allowing a team member to proactively take on an issue). Load balancing rules can also be applied to help you use your resources in the best possible way.
8. It will empower your customers to help themselves, saving time for your team
   Connecting your JIRA Service Desk to a Confluence knowledge base can help your customers find answers to many issues without the need to open a ticket. This will result in less repeat issues submitted to you, so your team can use their time more productively.
9. Implementation is easy
   Your JIRA Service Desk implementation can grow and evolve with your business.
   The hardest bit will often be working out what you need it to do to help you address customer issues in the best possible way. However you can start with a very basic but compliant process and develop it to streamline the handling of issues that you find customers are raising most frequently.
10. It facilitates FDA CFR 21 Part 11 compliance
    Last but not least, to keep auditors happy, JIRA Service Desk comes with an audit trail facility built in. The requirement for electronic signatures can easily be accommodated by using a marketplace plugin such as Intenso’s Electronic Signatures.

Removing the awkwardness of the customer complaints process and replacing it with JIRA Service Desk is one of the best things that can happen to a quality management system, maximising regulatory compliance, internal efficiency and customer satisfaction. Your team will love you for it!

The information revealed through a CAPA process can lead to real customer and business benefits. On the other hand, triggering too many CAPAs creates unnecessary noise, burdens the CAPA management team and can pull resources away from more important activities.

Triaging customer issues to determine which ones warrant starting a corrective and preventive action (CAPA) process can lead to great efficiency savings, particularly if a certain root cause lies behind a number of customer issues. But how do you go about pinpointing when it’s worth creating a CAPA?

Let’s take the example of an imaginary head of customer service at a life sciences company – Tim.
At Tim’s company, the service desk team handles day-to-day management of customer issues using JIRA Service Desk. They know when to escalate an issue to the authorised representative but, in the vast majority of cases, are competent to take issues through to a satisfactory resolution for the customer.

Tim regularly goes through the issues that have come up recently to see which should trigger a full blown CAPA process. He’s particularly keen to spot the ones that are not isolated incidents but part of a pattern that needs investigation so, over time, he has developed a set of methods that help him quickly identify them.
Tim’s methods rely heavily on the built-in reports and data available in JIRA Service Desk. Here are few examples:

1. Identifying at-risk components

Each month, Tim checks the number of customer issues associated with each of a pre-defined list of ‘components’. He then checks these against the equivalent figures for each month over the last year. A significant increase in the number of issues raised for a particular component may suggest that something fundamental has changed for the worse, making it appropriate to trigger a CAPA.

2. Investigating regional differences

Tim also checks where the customers who report issues relating to each component are based. Using pie charts created automatically in JIRA enables him to see at a glance the whole spread of components for each country. If the split between components is markedly different in one particular country, that could indicate a specific local problem that merits investigation via a CAPA process.

In the example below you can see that packaging-related issues are much more prevalent in the UK than in other countries. This might be due to a quality control issue at the regional level, such as in the warehouse. The fact that this geographical difference has been highlighted gives Tim and his team the opportunity to look into the problem and, hopefully, eliminate it.

3. Monitoring issue resolution performance

Tim’s team is committed to certain response times, which are outlined in their service level agreements (SLAs) with clients.

Having had time to perfect its processes, the team manages to meet those commitments for the vast majority of requests. However, the fact that JIRA Service Desk automates the monitoring of missed target response times means Tim can easily access a list of issues where the first response was late. He can then apply the benefit of his experience to work out where it might be worth implementing a CAPA process to investigate the reasons behind the delay.

4. Standardising best practice

The end result of this approach is fewer CAPAs, each of which has a greater potential impact on the way Tim’s company works.

Even better, triage methods like the ones he has developed are easy to spread, because the reports and graphs created are readily available to other key stakeholders, such as the quality assurance manager. This means the criteria can easily be incorporated into standard operating procedures (SOPs) for dealing with customer issues, forming part of the company’s official methodology.
All this drives efficiency and makes the work Tim puts into working out when to implement a CAPA process even more worthwhile.

If you would like to experience these benefits and more for real, speak to us about how we could help you make the most of JIRA Service Desk for your quality management.

Often, when life sciences companies are working to define their controlled document management process, they spend a lot of time considering the regulations and ensuring that their approval process and electronic signatures are compliant. However, the regulations don’t require the process to be easy or efficient, and prioritising compliance over practicality often results in cumbersome and complicated procedures.
Of course it’s crucial to make sure your process is compliant, but we would suggest focusing on the document lifecycle too (see figure 1 below), to ensure it’s also efficient and user-friendly.

The authoring cycle

The first stage in any controlled document’s lifecycle is a cycle in itself – the authoring cycle. It’s here where each document is written, reviewed, amended, approved and eventually published.
At any point in the future a document may revert back to the authoring cycle, when a new version is prepared.

Document consumption

Once a document has been published it enters the consumption phase of its lifecycle. In the case of controlled documents, this may mean being used as:

• training collateral
• a brochure
• a manual or guidelines
• reference material for audits.

Getting the balance right

When only the regulatory requirements are taken into consideration, the consumption phase is often neglected. However it’s important to bear these facts in mind:

• It is in the consumption phase that the document actually matters. If it’s not consumed, the document will have no impact at all. This means it’s important to make sure each controlled document will be readily available at every relevant point of use.
• In most cases, many more people will be involved in consuming a document than in authoring and approving it.
• The people who use a document may have a wide range of different skills and needs. Some documents may be accessed by patients looking for information about specific treatments as well as their doctors and your company’s own employees. The needs and abilities of each potential audience need to be taken into consideration.

These key facts trigger a whole set of requirements and priorities that are specific to the consumption phase.
The following table provides a high-level checklist of requirements for your controlled document platform, taking into consideration these two fundamentally different stages of the document lifecycle.
This could be a good starting point for mapping your document control platform requirements. Note that the importance of each need at each phase will vary, even for different documents within the same organisation, so you may need to complete the checklist a few times to cover different categories of document.

When companies ask for our help setting up a new controlled document management system, we first use this table to explore their requirements and priorities. We also consider other crucial needs, such as:

• document retention and archiving
• business continuity and resilience.

We then configure Confluence accordingly and supplement it with a tailored mix of commercially-available plugins and extensions we’ve developed ourselves. The end result is a system which is not only compliant with regulations, but also with the needs of the people who will be developing and accessing the documents.
If you’d like to find out how more about how we could develop a document management system to suit the needs of your team and the people who use the documents you create, please get in touch.