Treatment system data analysis - Subject to CFR part 11? Entire system?

[mbeuget]

Hello everyone,


I am engineer in computer science and I have to build a system that have to be compliant with CFR part 11. But it is hard to me to understand and interpret every point of the CFR, and if I am subject to certain point.

To explain : my company has developped some really efficient algorithms in signal processing for biological data, so they want a SaaS plateforme to automate the treatment and generate automatically some reports that are interessing for their client : biologist and labs.

So we do not produce any data, clients upload their files, choose treatments and visualize/download the result. We only proccess records and generate graphs, etc.

And I have to make the plateform compliant with CFR part 11, so I have some questions :

- If a client is not compliant with CFR part 11, predicate rules, then their records aren't compliant too, so in this case I haven't to be compliant too ?

- If a client is compliant with CFR part 11, and their records respect predicate rules, then if he uploads a compliant record, what I have exactly to ensure ?

-> for the record integrity I compute sha-512 both in client side and server side, then I compare the two, if equal, then it hasn't been altered by the upload.

-> for the record storage/access control/audit trail I store everything in a MongoDB database, and it is impossible to alter the record : the only permitted operation is download the file through the client account, the administrator cannot himself delete the record. (and I store the sha-512 also). My plateform logs everything, my database logs every access, my system logs also every system operation, and I am able to export it.

-> of course the plateform is secured.

Open source databases like MongoDB or MySQL is considered reliable by the FDA, isn't it ?

Am I subject to electronic signatures ??
-> If a record is not compliant then we haven't the goal to make it compliant, it is a client side problem and there are no signatures.
-> If a record is compliant then it has probably been submitted to the Agency so it has a signature attached ?

We don't need to register to FDA if we don't want to submit any file ?

For a compliant record do I need to let the FDA access the file through the plateform ? Or FDA access the file through the client system ?

The 'report' we generate are they subject to CFR part 11 ? It is the result of some treatments, it should not be submitted to the agency as if the record is compliant ?


I'm sorry but I'm a bit lost with all these questions, I think I am compliant with the part B but I don't know what is my scope exactly ...


Thanks to help me !!

 

[JJ_FDA]

If your client's records are subject to predicate rules, then your system must be able to respect the record-keeping requirements of predicate rules and the Part. It's really up to the client to make this determination; I'd think your role is to enable them to fulfill the requirements of part 11 (audit trails, e-signature functionality, access to their records by auditors, access and role-based controls, validatable by the client, etc. etc.).

In addition to Part 11 itself, have you taken a look at the guidance and articles like this? Are you familiar with validation frameworks like GAMP?

 

[mbeuget]

Thanks for your answer.

When you say "If your client's records are subject to predicate rules, then your system must be able to respect the record-keeping requirements of predicate rules and the Part",
does that mean that if the record is subject to predicate rules and Part 11, all I have to do is to :
1) ensure that the record hasn't been altered during the upload (sha functions is usefull there);
2) ensure that the record has been correctly "recorded" in the database (sha functions usefull too);
3) periodically check that the record hasn't been altered "by the time" (sha functions too).
4) ensure the access control and general security ?

The electronic signature is inside the file, right ? So if SHA-512 hasn't change, the file hasn't changed and the signature too.

In my case we produce others document relying on the record but we never modify the original record. If we ensure that the transfert is correct, the storage too, and that we have a strong access control and security on the plateform, we should be compliant ?
The treatments and results of treatment aren't subject to part 11, are they ? Or they meet others requirements to ensure that the algorithms treat correctly the record, aren't they ?

I don't understand very well when you say : "I'd think your role is to enable them to fulfill the requirements of part 11 ", our goal is to treat records, and display the results of automated or supervised treatments, not to help the client to be compliant with CFR. We just want that if the record is cfr compliant, then we don't make it "uncompliant".


I have a last question, our client will most likely use some xCELLigence RTCA Instruments with its software, do you know if these kind of instruments are compliant ?
(can't post the link ...)


I'll read your links in detail, unfortunately we haven't the GAMP 5 ...

thanks

 

[JJ_FDA]

I have no experience with xCELLigence XTRA instruments, so I do not know if it is capable of compliance, but I'd like to point out a subtle distinction: equipment, instruments, or computer systems in and of themselves cannot be compliant to Part 11, but their implementations can be validated as compliant. In other words, they can be capable of compliance, but how they are being used determines the state of compliance.

What this means is that you cannot buy something that is capable of Part 11 compliance, use it right away, and say, presto!, I am Part 11 compliant.

With SaaS, this means that the system as a whole needs to be considered: the part that you are developing and that you are selling to the client, and the part at the client's end that interacts with your software (e.g., Web browser, I imagine, and whatever data storage they use at their end). All this, considered as one system, needs to be validated as Part 11 compliant.

For example, if they download some data processed by your SaaS, and then that instance of the data is sent of as part of their application to FDA, the integrity of that downloaded data probably needs to be assured. However, you have no control over what the client does with the data once downloaded. It could be stored on a shared drive with no access control, breaking one of the requirements of Part 11. So even if your SaaS piece is capable of Part 11 compliance, the system as a whole is not.

This is why I say your role is to enable them to fulfill the requirements of the Part for the SaaS piece of the system, there's no way that you can sell them something that is immediately compliant out of the box.

This is also sort of why I pointed you into the direction of GAMP (which is not a requirement, but only one way of looking at validation).

As for records, you need to make sure that the original entry and any subsequent changes to the entries can be recreated (audit trail functionality) in terms of what changed, who changed it, and when it was changed. The requirements are spelled out in the Guidance. If you're familiar with version control software such as SVN, it's sort of the same principle.

Requirements for e-sigs are also detailed in the Guidance.

Note also the record keeping requirements that the Part may impose on you, the software developer.

 

[mbeuget]

Ok, thanks it seems more clear to me.

And do you know what could be the form of an electronic signature ? I know you need to validate a certificate so you possess a private key, and you can generate a signature with that and attach it to your document.

But what is it exactly ( generally for biological data like a big xls document ) ? a picture ? a token ? encrypted data ? watermarking ? (didn't find it in the guidance)

If I understand I may have to extract the signature of a client from a document he uploaded ( once I'm sure it's not altered with the upload ) and then paste it on documents we generate, and keep them ready for inspection by the FDA auditor, if the client want to submit it to FDA ?

So I have to create a special account for the FDA auditors ?

And last question, is the treatment in itself important for the FDA, if the results we generate are submitted to FDA for inspection ? The algorithms are really the intellectual property of my company there is no way we send them to the FDA, only the results.

Thanks

 

[c.mitch]

Hi,
Electronic signatures don't have to be rocket science like biometrics or complex certificate systems.
An electronic signature can be a login + password. Then when a user signs a document, he/she enters his password.
A few set of basic functions need to be implemented to ensure a minimum of security and to avoid impersonation:
-one login per user
-disallow weak passwords
-password expire after a configurable number of days
-password needs to be typed when user logs in and for each document he has to sign (acceptable though for a group of documents at once)
-application disconnects after configurable idle time
-audit trail of logins logouts, password changes, failed logins attempts, documetd signatures, ...

Regarding the FDA, you may have a special account for auditors, to let them see the audit trail. But I don't think your software will be any data to the FDA for inspection. Hence FDA inspections are in the client premises, not remote.

 

[JJ_FDA]

As long as your implementation of electronic signatures satisfies the criteria of Subpart C of the regulations, FDA will not worry too much about how you implement e-sigs.

I would go back to the predicate rules as well to learn about the goals and purposes of electronic signature to be sure that your implementation fits the bill.

As for accounts, definitely plan on creating read-only accounts for FDA and other people that can see both the data, and the audit trail for the data. Make sure that they can be jailed to only the data being audited (i.e. they are auditing client A, so they should not be able to see data that belongs to client B).

 

[mbeuget]

Okay, thanks to all !