Menu
▾
▴
Re: [Psidev-ms-dev] PSI-MSS WG call minutes
|
From: Susanna <sa...@eb...> - 2008-06-11 13:02:39
|
Hi Randy, could you, please, expand on this.... > I presented a way of using XML for data submission for the FDA to Janet Woodcock > who is their Chief Medical Officer and is now head of the drug approving CDER group and she > was very supportive. ..do you refer to proteomics submissions to FDA? Thanks, Susanna Randy Julian wrote: >I have met extensively with both the FDA DSI (audit division) and Pharma >QA Reps (and been audited for GLP compliance at Indigo). Based on this, >I suggest we look at a standard data integrity method which leaves the >document as clear XML. > >I have not dug in depth yet, but the XML digital signature standard >seems like a good place to start. > >In essence, I think you encrypt a SHA1 (or MD5) of the document to >create a Message Authentication Code (MAC) using a Public/Private Key >Pair. The traditional key stores should work, but I have not gotten >further than this. The receiver decrypts the SHA1 with the public key >and then compares it to the computed SHA1 of the document. This would >protect the entire document and confirm authorship - we might even be >able to come up with a time-stamp mechanism which would help with IP >protection use cases. > >Since we have created the index schema already, it seems like a good >place to put additional authentication devices. I really favor leaving >the raw data and audit trail itself as normal XML (and readable). > >21CFR11 does not suggest that binary encoding is a sufficient method for >protecting the integrity of data. You have to have SOPs in place to >ensure document security even with binary files. The agency has >accepted the argument that the degree of difficulty in recreating a >valid binary file set for a data system lowers the probability for an >undetected modification, but SOPs have always been required on top of >this. > >I think we have a great opportunity here. I presented a way of using >XML for data submission for the FDA to Janet Woodcock who is their Chief >Medical Officer and is now head of the drug approving CDER group and she >was very supportive. It fits very nicely with their Critical Path >Initiative and also helps the Quality By Design Initiatives, where >analytical instruments are used in-line during manufacturing to >continuously monitor processes. > >Does anyone have experience with the XML Digital Signature standard? > >Randy > > > > > >-----Original Message----- >From: psi...@li... >[mailto:psi...@li...] On Behalf Of >Pierre-Alain Binz >Sent: Wednesday, June 11, 2008 3:56 AM >To: Mass spectrometry standard development >Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes > >Inbetween, I have also contacted a world-wide QA in Pharma and asked >what they are doing to comply with text documents, across regulation >bodies (FDA, ISO, etc). Let's see >Pierre-Alain > >Mike Coleman wrote: > > >>I agree with your points. >> >>As far as I can see, the checksum within the mzML file is not good for >>anything other than as an additional check that (say) Windows hasn't >>flipped any bits in the file. Arguably, this kind of checksumming is >>barely worth doing, unless you're also checksumming the other parts of >>the system regularly. Who among us periodically checksums our >>instrument software or configuration files, for example? >> >>If you're concerned about instrument operators faking results, it >>seems like the only meaningful bar would be to have the instrument >>software cryptographically sign the result file. This would entail >>all kinds of key management problems that would rule this out in >>practice (I would think). >> >>If you're concerned about downstream people faking the results, my >>thought would be that you'd checksum (SHA1, etc.) the file at creation >>or "publication" (the point at which others have access to the file), >>and then publish that checksum in a "read only" location. As you say, >>this is pretty much the method used by thousands currently for file >>verification. If you already have a decent backup regime, just >>backing up the checksums might qualify. Or you could publish a >>grand-checksum in the newspaper occasionally, or whatever. >> >>Note, though, that for these latter scenarios you specifically *must >>ignore* the checksum within the file itself, as it is (as you and Jim >>say) not trustworthy. Rather, the checksum must be recalculated. >> >>I'm not familiar with 21 CFR Part 11, but it would seem that the mzML >>file itself ought to simply include all of the useful details about >>what it contains. Any further audit trail should happen outside of >>mzML, though--once the file comes off of the instrument, it should >>never change, in my opinion. >> >>Mike >> >> >> >> >------------------------------------------------------------------------ >- > > >>Check out the new SourceForge.net Marketplace. >>It's the best place to buy or sell services for >>just about anything Open Source. >>http://sourceforge.net/services/buy/index.php >>_______________________________________________ >>Psidev-ms-dev mailing list >>Psi...@li... >>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> >> >> > >------------------------------------------------------------------------ >- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Psidev-ms-dev mailing list >Psi...@li... >https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Psidev-ms-dev mailing list >Psi...@li... >https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- Susanna-Assunta Sansone, PhD NET Project - Coordinator www.ebi.ac.uk/net-project The European Bioinformatics Institute email: sa...@eb... EMBL Outstation - Hinxton direct: +44 (0)1223 494 691 Wellcome Trust Genome Campus fax: +44 (0)1223 492 620 Cambridge CB10 1SD, UK room: A229 |