Confluence page versioning that suffices FDA Part11 and requirements for medical devices

[Tuelle]

Hi,

I am wondering if it would be possible to setup Confluence such that we can manage our documentation for medical devices  in Confluence without making print-outs for collecting signatures and archiving (i.e. FDA Part 11 compliant).

We need electronic signatures (there are plugins that fulfill all requirements) and a review workflow with reviewer and approver (can be implemented Comalatech Workflows). However, I cannot come up with a good solution (convenient to use, fullfils regulatory requirements) for the versioning and traceability of changes. I don't consider the plugin Scroll Versions to be suitable, because it requires one space per document. We have several products, each having multiple versions (which are on-going projects at the same time) and lots of documents per product version. This would result in way to many Confluence spaces in our case.

If a document is released, the approval date, reviewer and approver must be stored (for all times) in a header at the beginning of the page. Additionally, we have a specific versioning scheme which includes a document id, major and minor version. Some Confluence users propsed to use variables stored as metadata with the page. These can be filled by scripting with dates, names and id of signed confluence version when the document is approved  This is fine as long only the latest version of a document/page is relevant. Once a new version of a page is approved, the values of the meta variables change also in the former approved version of the page. We however have to proof that also the former versions are still aproved documents and provide information about the approval date, reviewer and approver, because these versions are still relevant for e.g. other versions of our product, Additionally, other product documents still have to link to the former approved version,

Any proposals how to solve this? I found several other related discussion threads but I did not find any good solution to this problem yet. 

Best regards and thanks you for any feedback

[Rina Nir (AC)]

Hello Tuelle,

To address the full breadth of your concerns you will need to use several tools:

1. Comala Workflows: provides the review/approva/signature solution to create official version of pages. you can refer to the following blog post I published a while ago with an example of an approval process https://radbeeqms.com/using-comala-workflows-for-approval-of-controlled-documents/ . I do recommend to user also Comala Publishing and seperate between the authoring space and the official space because it makes permission issues easier to handle and because of the links issue (see point 3).
2. To show the history of approvals along previous versions as well: I do not know of an out of the box solution for this, but we have implemented a proprietery solution that uses Confluence content properties capabilities (see: https://developer.atlassian.com/confdev/confluence-server-rest-api/content-properties-in-the-rest-api ). Every new official version is added to the content properties along with all the signature information (see image).history.jpg
3. Regarding the links between pages as well as other inter-page relations (such as include pages), and the question relating to how this effects the content and the validity of approval. The solution here is less straight forward but still achievable: you need to decide what links you want to support and understand for each link type how you can technicaly ensure that the published version is 'correct'. For example- links should always be done to the 'published' spaces not to the authoring spaces. (BTW: if you also use the Include Page macro then have a look at ScriptRunner for Confluence that has an excellent built-in macro that allows you to include a specific version of a page). Once you undertsand the options you support you can enforce that only they will be used. This requires again a bit of programming but we have implemented in several instances 'legal checks' on pages to ensure that only pages with correct configuration are published.

Hope this helps
Rina
Disclaimer: RadBee is an Atlassian Solution Partner specialising in helping life sciences companies use the Atlassian suite for their compliance related needs

[Tuelle]

Thank you very much  Rina, that information is really helpful!

Thorsten

[Rina Nir (AC)]

You are welcome:)

In that case would you be able to kindly upvote my answer? 

[Tuelle]

Hi Rob,

I agree, one space for product & version seems to be the most logical setup. 

The problem is that we indeed have different reviewers and approvers for different documents. Since people are also switching roles over time, the e.g. reviewers of a document can also change over time.

Somehow I have the feeling that we cannot get around adding some static information with approval information either in the document or as an attachment, if we want to have easy access to this information for every published version of a page (also for former versions). However, injecting a table with this info as part of the final approval would probably cause an additional (unapproved) version of the page to be generated.

It would be great if the metadata fields could be configured either as "local in time" (meaning their values are kept for the specific version of a page and are not overwritten by later versions or "global in time" (meaning that they are shared by all versions of a page). That would actually solve my problem in a very nice way.     

[Rob Woodgate]

I was going to answer, but Rina has provided a good suggestion

[Rob Woodgate]

Hi Tuelle,

Based on that scenario, I'd suggest having one space per branch per product, so you end up with 20 spaces. (5 products x 4 branches).  You could then have 1 page for each document, so 25 pages per space (or 25 "header" pages, each with additional pages underneath if you need to split them up).  You can use space naming to determine the version - e.g. Product A v1, Product A v2, Product B v1, Product B v2, etc.

Assuming that each branch has the same reviewer and approver, you can go to the Space tools > Look and Feel > Sidebar, header and footer tab and add CSS and markup to add styling and information.  In your case, you could add a User Profile macro (see the bottom of the help page for the wiki markup to use) for the reviewer and approver, and any other information you wanted (e.g. you could set up a table of historical information on a Confluence page and add an Excerpt Include macro to the header to display it).  Or you can use markup to just display simple text if you prefer.

The downside to this approach is that the header and footer apply to every page in the space, so if you have different reviewers and approvers for different pages this won't work.  However, there's nothing to stop you using the built in page history and comparison view to check who's done what, although you'll need to enforce (through policy and procedure) people adding a comment to the page before they save it.

I'm happy to keep suggesting things, but only if this is helpful for you....?

[Tuelle]

Hi Rob,

We have 5 products today (hopefully getting more in the future). Each product has about 4 on-going branches (for hotfixes for about 3-4 years) and each branch contains about 25 types of documents. This would already today result in 500 spaces, right? It is perhaps technically feasible, but does not really sound like an attractive and scalable solution to me.

To my understanding the proposed plugin would also not conveniently display information about the approver, reviewer etc. for the most recent and former approved and published versions of a document. Reviewers can change between versions of a document so I would like to have this information included as a static header at the beginning of each page/document for every approved and published version. This would allow us to quickly look-up this information during audits. It metadata fields are used only the information for most recent approved version can be easily accessed an displayed, right?

One workaround could be to automatically generate a PDF file of each approved version and to attach this file to the page itself. This PDF could then contain a cover with reviewer, approver, date, etc. and the content of the specific version of the confluence page. But I don't know if this can be done in Confluence with scripting or plugins

Thanks for your thoughts!

[Rob Woodgate]

Hi Tuelle,

Can you explain why Scroll Versions isn't suitable?  You can archive spaces if they're not needed any more (e.g. to keep them available for auditing, but not cluttering up the space directory or the search), and it seems like that approach - 1 space per document - would give you confidence that each version can't be "contaminated" by later versions of the documentation.

Edit: You might want to look at the Comala Workflows for Scroll Versions, as it might give you more of the functionality you need.  Short of manually versioning your documents, or building your own add-on, Scroll Versions is probably the only option for you so it would probably be worth making sure it definitely can't work the way you need it to, before discarding it as an option.