Hazard analysis simple, powerful method to identify risk, says Chatterjee.One of the simplest yet powerful software validation The certification that an information system has been implemented correctly and that it conforms to the functional specifications derived from the original requirements. Such validation is often performed by a third party consulting organization. tools is hazard analysis A hazard analysis is a process used to characterize the elements of risk. The results of a hazard analysis is the identification of unacceptable risks and the selection of means of controlling or eliminating them. , which helps to semi-quantify and standardize stan·dard·ize v. 1. To cause to conform to a standard. 2. To evaluate by comparing with a standard. the assessment you go through to identify risk. This allows companies to demonstrate where risks are early in the software development process and to be in a position where the software development life cycle is flexible enough so that software professionals can design code that meets both user and regulatory requirements Regulatory requirements are part of the process of drug discovery and drug development. Regulatory requirements describe what is necessary for a new drug to be approved for marketing in any particular country. , noted the founder of San Francisco-based Pharmatech Associates in a recent teleconference by Expertbriefings.com. Bikash Chatterjee, who spoke April 3 in a presentation on a risk-based approach to software validation, stated that hazard analysis "is a great tool for both quality and regulatory people, and prevents you from testing everything under the sun." In addition, he noted, FDA FDA abbr. Food and Drug Administration FDA, n.pr See Food and Drug Administration. FDA, n.pr the abbreviation for the Food and Drug Administration. favors hazard analysis. "The agency says, 'great, justify why you are doing it and go after it,"' Chatterjee added. The speaker stated that a hazard analysis involves engaging in a brainstorming exercise early on in software development as a framework to identify risks, causes/effects and safeguards. "The idea is to identify failure modes a priori a priori In epistemology, knowledge that is independent of all particular experiences, as opposed to a posteriori (or empirical) knowledge, which derives from experience. , and to tie product risk to software risk," Chatterjee noted. The categories he usually uses are no risk, moderate risk and high risk. Normally, you identify "two to four items that are the largest risk in terms of application of your code. You might have 20 or 30 hazards associated with those items associated with the application of your software. Then you identify three of four of those hazards that are the highest risk." This allows you to have "a very focused effort from which you can design user requirement specifications," said Chatterjee. Those identified risks must be mitigated mit·i·gate v. mit·i·gat·ed, mit·i·gat·ing, mit·i·gates v.tr. To moderate (a quality or condition) in force or intensity; alleviate. See Synonyms at relieve. v.intr. To become milder. as you go through your quality assessment, software development and quality exercises. This provides you with the core of your software validation assessment plan as you put it together. "It is a nice way to narrow the field in which we develop software." Chatterjee said that some of the tools that can assist developers with hazard analysis include "old fashioned n. 1. A cocktail consisting of whiskey, bitters, and sugar, garnished with with fruit slices and often a cherry. Noun 1. old fashioned - a cocktail made of whiskey and bitters and sugar with fruit slices " cause/effect diagrams--"a fabulous way to understand how potential risk is related to your software development. Another good tool is a process flow chart, which can be used "to organize attributes you create in your code and relate them to the product in which they will be used," noted Chatterjee. This can help to reduce the components you focus your efforts around in your software validation. Hazard analysis is a good way to depart from traditional validation See validate. validation - The stage in the software life-cycle at the end of the development process where software is evaluated to ensure that it complies with the requirements. models, such as the V model. This identifies each aspect of software design in isolated "buckets" that does not generally account for the constant "leaping forward and back" that occurs so often in software development now, he said. "Many companies fall back on the classic V model, which sounds good in theory, but often our firms don't have the expertise in development or quality to live up to that model," said Chatterjee. He added: "The worst thing you can do is making a model that looks compliant but is not. It is better to tailor a solution that speaks to points of compliance, maybe is a bit light on compliance, but is compliant with that particular process. Regulatory exposure is much less, and is easier to explain to your quality and regulatory groups." What we have learned is that the greatest sources of variation are human factors. We know that there is much scrutiny on user trials by CDRH CDRH Center for Devices and Radiological Health (US FDA) , he noted. "Our challenge is being able to craft a risk based software validation approach that addresses the human error factor. We have to understand how users will use the product. This aspect has been moved to the beginning of development with such tools as hazard analysis." He said that software code is easy to change. FDA knows this. "We need to be able to show we have control on the technical and human factor side." He also highlighted what FDA generally looks for today in software validation: * Good software engineering to support the final conclusion that the software is validated--specific model is not required; * Approach is based upon the intended use and the safety risk associated with the software; * Software verification Software verification is a broad and complex discipline of software engineering whose goal is to assure that a software fully satisfies all the expected requirements. There are two fundamental approaches to verification:
* The party with regulatory responsibility needs to agree the software is validated; and * Software validation focuses on minimizing risk and establishing a level of confidence in the code's performance. Chatterjee also mentioned a promising new standard: ASTM ASTM abbr. American Society for Testing and Materials E2500. "This is a very interesting, radical approach that just came out that was designed for the pharmaceutical and biopharmaceutical industries. It has been reviewed by FDA, EMEA (Europe, Middle East, Africa) Refers to that region of the world. For example, one might see products packaged differently for the UK, EMEA and Asia Pacific markets. and Japanese regulatory authorities Noun 1. regulatory authority - a governmental agency that regulates businesses in the public interest regulatory agency administrative body, administrative unit - a unit with administrative responsibilities All have read it and agree to it. "Now validation professionals need to interpret it and work with it. It is nice that this document exists and shows a future of where validation needs to go," he concluded. The CD recording of Mr. Chatterjee's April 3 presentation is available for $325. Please visit www.expertbriefings.com to order. By Joseph Pickett Managing Editor |
|
||||||||||||||||||
Printer friendly
Cite/link
Email
Feedback
Reader Opinion