lundi 29 avril 2013

Un centre de traitement de produits sanguins montré du doigt...

Dans une récente mise en demeure, la FDA a mentionné plusieurs écarts entre la gestion informatisée et le statut ou la localisation physique des stocks :


5.      Failure of distribution and receipt procedures to include a system by which the distribution or receipt of each unit can be readily determined to facilitate its recall. [21 CFR 606.165(a)]. For example,
(a)    A query of your firm’s computer system for expired products which are not in quarantine and not previously shipped, identified seven units of Red Blood Cells, Fresh Frozen Plasma or Platelet pools. Your firm cannot determine if the units have been transfused or distributed since they are electronically still in inventory but cannot be physically located.
(b)   Your firm identified instances where a final disposition could not be determined. Your firm calls these “discrepant discard” for tracking purposes, though the term “discard” is only used for the electronic discard and there is no evidence that the product was physically discarded...

(c)    During our inspection, a Red Blood Cell component was identified as being in quarantine according to an electronic inventory inquiry on January 30, 2013. However, the component could not be located in the expected physical quarantine location. After the discrepancy was identified by our investigators, a search was initiated and the component was found in the discard bin. The component had been physically discarded without maintaining a record of the discard as required by TS 500-2, Final Disposition of Blood Components.


Enfin cette Warning Letter pointe des défaillances dans la maîtrise du changement et la validation des systèmes informatisés :


6.      Failure to check input to and output from the computer or related system of formulas or other records or data for accuracy [21 CFR 211.68(b)]. For example,
(a)     On June 3, 2012, you identified that donor and patient identification numbers are carried forward from previous override functions when an override is performed by the same user. This causes the patient and donor numbers to be replaced with incorrect identification numbers on laboratory override reports.  On June 8, 2012, this issue was reported to the computer software manufacturer, however, you failed to implement the computer system workaround identified by them.  For example, on January 6, 8, and 10, 2013, at least three units were missing the Patient number and Order number from the PSBC Transfusion Service Laboratory Override Report.
(b)    ORF-000055354 documents a problem where demographic changes, including blood type, CMV status and name changes can be lost if a different user is updating the record in another session. On September 4, 2012, this issue was reported to the computer software manufacturer, however, you failed to implement the computer system workaround that the manufacturer identified.  During the inspection, your software was tested by BCS staff who confirmed that this event continues to occur when demographic changes are made by different users.

lundi 15 avril 2013

Des nouvelles remarques sur la constitution des Master Batch Records...

Une mise en demeure récente mets à nouveau l'accent sur la constitution des Master batch record et l'approbation des changements par la Quality Unit :

5. Your firm failed to follow written procedure for the preparation of master production and control records designed to assure uniformity from batch to batch (21 CFR 211.186(a)).
For example, employees made handwritten changes to pre-printed information on Batch Production Control Records (BPCR) in order to describe drugs being packaged. However, your quality unit did not review or approve the corrections, nor did your firm revise the Master Production Control Record (MPCR). These handwritten changes resulted in packaging errors.

jeudi 11 avril 2013

La société RALTUS présente les évolutions récentes de son logiciel ProcedureCapture


Ce qui suit est un extrait d'une communication de la société RALTUS Software :

"You can now control the level of step detail and imagery shown based on Risk and Step type (supporting, proving and non-proving). This allows the level of detail and degree of rigor of the testing script to be tailored to the risk.

We have also added the ability to use your own Word docs as the template basis for the outputs produced from execution whether this be in a paper or paperless environment. The benefit of this is that your validated outputs are exactly the same as your SOP's and are therefore consistent right across scripts. 

Secondly, we have recently signed a number of customers to use our solution for validating their systems. These include companies such as Sonexus Health, Ranir, Volcano, ASO. We now have case study evidence which demonstrates that customers are reducing their time for script creation by about 40% and the effort to execute scripts by between 45-60% (dependent on whether they are using paperless execution or not).

Lastly,  we are finalising the design functionality for release 9 and this will include the ability to manage and report on requirement specifications.

Our goal on this is to be the only tool which can be used right across the lifecycle and were you can manage requirements, create and execute test scripts (both paper and paperlessly) and sign electronically and do all this without having to purchase separate tools/licenses or additional electronic signature add-ons.

If you could be assist with the requirements questions, we would be delighted to hear from you. Lastly, some new CSV demos can be viewed, if you are interested at http://www.raltus.com/demos.htm "

lundi 8 avril 2013

Une récente "Warning Letter" rappelle quelques règles relatives aux "Master Batch record" et à leur identification

Cette mise en demeure adressée à une société japonaise de production d'API mentionne l'écart suivant :

4.    Failure to prepare adequate batch production records and failure to identify produced batches with a unique batch identification number.
Batch Record (b)(4) Lot (b)(4), reviewed during inspection, was not controlled or reviewed by your firm prior to the release of API for distribution. Your firm failed to ensure that batch records were completed in their entirety or that they specified the equipment used during API manufacturing.  At least one executed batch record was observed to have no associated lot number. 
We also noted that your firm has no written procedure for assigning lot numbers to API products and failed to ensure that lot numbers were unique identifiers.   While firm officials stated that certain unwritten rules are followed in creating batch numbers, application of these rules appeared to be inconsistent.  For example, while firm officials stated that the (b)(4) signify the date of manufacture, our inspection found that lot number (b)(4) was actually manufactured on March 9, 2011.
In response to this letter, please include a copy of your written procedures for the preparation and review of master production instructions and the issuance, review, approval or rejection, and archiving of executed batch records. Also include your written procedure for unique lot number assignment. During the review of your documents, obtained from the FDA inspection, we observed your firm’s inconsistent use of terms such as batch, batch record, and lot.  Please include definitions of these terms within your submitted procedures.

Ainsi qu'un autre écart sur les règles d'attribution des délais de péremption et/ou de recontrôle :


5.    Failure to have an API stability program to monitor stability characteristics of your firm’s APIs, and failure to set an expiry or retest date for APIs based on the evaluation of data derived from stability studies. 
The inspection documented that the label for API (b)(4), lot number (b)(4), provided a (b)(4) expiration date.  Your firm failed to provide stability data to support the expiration date provided on the label for this product.  Furthermore, representatives from your firm stated that the firm has no stability program for any of the API products manufactured at your facility.
In response to this letter, include a copy of your stability data to support any assigned expiry or retest dates.  In addition, provide a copy of the written procedures by which you plan to monitor the stability of your APIs on an ongoing basis.   Provide a summary of the validation of the analytical methods used in your stability program and describe how you have demonstrated that these methods are stability-indicating. 

lundi 1 avril 2013

Absence de validation sur un système de SAV

La société FISIOLINE (dispositifs médicaux) a été notifiée d'un écart par la FDA pour la non validation de son logiciel de SAV :

4.    Failure to validate computer software for its intended use according to an established protocol when computers or automated data processing systems are used as part of production or the quality system, as required by 21 CFR 820.70(i).  For example, the software developed by your firm to record, evaluate, investigate, correct and repair incoming technical assistance calls, complaints, and service records was implemented in the first part of October 2012, and has not been validated.  No validation documentation was available for an established protocol, any testing data, or a finished report for the validation of this system. Mr. Lucca Ferrua, the Assistant Manager, indicated that your firm had not validated the software system.

Ainsi que des lacunes sur la qualification de conception :


5.    Failure to establish and maintain procedures for validating the device design, as required by 21 CFR 820.30(g). For example, the design validation procedures outlined in “PP1 Design and Development” do not include:
 
a)    requirements which ensure that protocols with acceptance criteria are established prior to the performance of validation activities; and
 
b)    requirements which ensure that the results of design validation, including the identification of the design, the methods, and the measuring equipment used, are documented and filed in the design history file.
 
Software validation documentation for a new user interface on an existing laser model did not document the above information.


Plus d'information ici.