April 8, 2014

FDA Hopes to Rollout New Adverse Event Reporting Tool in December

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

FDA’s Center for Devices and Radiological Health (CDRH) has finally picked a new adverse event (AE) reporting tool for devices. It’s slated to be in place by the end of the year. Of course, the agency missed a few deadlines to pick a new tool, so that deadline could slip, too.

FDAlogoThe creaky MAUDE, or Manufacturer and User Facility Device Experiences system, is out. It’ll be replaced by a PRIMO internet-based software platform developed by the November Research Group (NRG). FDA just inked a five-year contract with NRG.

While NRG touts its tool as a cut-above commercially available pharmacovigilance solutions primarily focused on generating the reports then sent to regulators, PRIMO is specifically designed for streamlined report intake and high-volume, intelligent report review, according to the company.

NRG’s tool is designed to, among other things, speed AE reporting into CDRH, and generate more accurate follow-up data returning to the device maker from the agency.

Years in the making, the upgrade was part of a concerted CDRH that included the September 2012 release of a white paper, “Strengthening Our National System for Medical Device Postmarket Surveillance.”  The white paper laid out the market conditions demanding an AE reporting system upgrade. It also included four specific calls to action:

  1. Establish a Unique Device Identification System and Promote Its Incorporation into Electronic Health Information;
  2. Promote the Development of National and International Device Registries for Selected Products;
  3. Modernize Adverse Event Reporting and Analysis; and,
  4. Develop and Use New Methods for Evidence Generation, Synthesis and Appraisal.

CDRH has said in the past that it receives more than a thousand AE’s each day.

NRG unveiled the new tool back in March.


Unique Device Identifier (UDI) Rule Now a Reality for Manufacturers

Jeff Mazik, Vice President, Life Science Solutions, AssurX

Jeff Mazik, Vice President, Life Science Solutions, AssurX

On Friday morning, September 20, 2013, at the UDI User Conference in Baltimore, MD, Jay Crowley, FDA’s Senior Advisor for patient safety, CDRH, raised a glass to toast the completion of a decade long journey. He, his staff and members from the Medical Device industry and solution providers celebrated the announcement of the publishing of the Final Rule for the establishment of the Unique Device Identification system. The final rule will be officially published Sept 24, 2013 on the U.S. Federal Register.

That date is an important one as it establishes the start date for the timeline for all medical devices to be coded with a Unique Device Identifier (“UDI”), which is to be printed in plain text and barcode (or other AIDC technology) on the device’s label. Manufacturers of Class III medical devices will have one year to comply with the rule. Class II and Class I devices which are used as implants and/or are life supporting/sustaining in nature have 2 years to comply. All other Class II devices must comply within 3 years of the publish date and all Class I and unclassified medical devices must comply within 5 years of the published date, per the Final Rule.

A number of changes were made from the original proposed rule, but one proposed requirement which was hotly debated by industry was the proposed required date format. The original date format on labeling was proposed to be the US-centric “MMM DD, YYYY” format.  However, with the final rule, the requirement has been changed to the more global-friendly (and ISO compliant): YYYY-MM-DD

UDI barcodeFurthermore, this rule institutes a new FDA Global Unique Identification database (or “GUDID”, pronounced “Good ID”), into which all manufacturers (or “labelers” as defined in the rule) must populate their unique Device Identification numbers. This database will also require providing FDA required attribute information. Once populated, the GUDID database will be used by healthcare providers and the public to search for and gain information about the device.

The initial goal of this rule is to be able to better identify devices in the healthcare area, to help healthcare providers identify items in cases of adverse effects/recalls, as well as to better understand and manage their inventory.

AssurX will be working with current and future customers to use our solution to help them comply with their UDI management and eventual submission to FDA’s GUDID database.


No FDA Guidance or Specific Regulation but Don’t Overlook the Criticality of Product Life Cycle in Medical Device Design Control

Dennis Payton, Executive Director of Product Marketing, Expandable Software, Inc.

Dennis Payton, Executive Director of Product Marketing, Expandable Software, Inc.

After a discussion of the short FDA CFR 21 Part 820 Quality System Sec. 820.30 and Sec. 820.40 on Design Control, even with the expanded FDA ‘Design Control Guidance For Medical Device Manufacturers’, there is not any mention of controlling the device lifecycle as part of the design controls. With the high degree of findings in the Design Control regulation, an important piece not discussed is the state or status of a product and definitions surrounding the Life Cycle of products. An important distinction and critical element of any Design Control fully defining a Product Life Cycle (PLC) and assigning stages of a product through a design process supplies a critical element in any general product management and can play a critical role in Medical Device audit and FDA Design Control compliance. Development of a Product Life Cycle (PLC) along with a solid Product Development Process (PDP), a topic for a later discussion, provide the provide the necessary corner stones for a complete Design Control and Device Management compliance. In this article we’ll explore the basics of a PLC to provide the basics, each manufacturing and development environment may need to adjust the model to meet the needs of the given environment but meshing the PLC with a solid PDP that align and complement each other provide a very solid Design Control base platform.

General Cradle to Grave Product Lifecycle

A simplistic product lifecycle has some very basic phases of life: research, development, production and end of life. These can certainly be expanded as needed by a specific device design & manufacturing complexity, or simplicity for that matter, as well as device class, category and classification. There can be sub-phases in the product development (prototype, engineering build, alpha, beta, archived, etc., level of product status, for example) but the main concern is to define the lifecycle that best meets the overall objective while being able to track the various product and versions of product in development, in the marketing place and archived after manufacture discontinuance (still have to support those products in the market place even though the selling cycle has ended).

The diagram below provides the basic PLC model and a generalized flow of life. A good deal of the life cycle flow should be overlaid with a device development process so while the PLC is discussed here remember that both the PLC and PDP for a given manufacturing environment should be developed in conjunction so that the two mesh well and complement each other as part of the total design control of devices.

Source: Expandable Software

Source: Expandable Software

As a Product Manager each of these phases of a product are of concern. The FDA defines some flexibility is design control as to when those controls should engage somewhere in the gray area between Research and Development mainly in an attempt to loosen up compliance a bit to help encourage research of new technologies and device for the medical industry. While the FDA being somewhat flexible in the front end research, for a Product Manager managing products even in the research phase needs some definition to help define when technology can be developed for the market place and further defined as viable for the business, market and developed into a marketable device. With the remaining PLC, the FDA will certainly want solid design controls and tracking of the device history from development through to product end-of-life (EOL) although for all purposes the EOL of products doesn’t mean that they disappear, rather they are product designs that gets archived for any reason that they might need to be revisited for support of product in the market. Here again the other end of the PLC spectrum may have deeper EOL process depending on the device(s) a manufacture is delivering to the market and how those devices live beyond the final sales.

Key points to consider in the development of a specific product life cycle (PLC) are:

  1. General enough to apply to finished product as well as supply chain components
  2. Define a solid definition between a research phase and development phase that will meet the definitions of controls for a particular product. Note: the FDA can be a bit more flexible with the research phase as far as hard and fast design documentation but best to make sure there is a clear distinction and definition built into a PLC and PDP and assure adequate regulatory coverage
  3. Perform a clear and clean hand off between Development and Production with all associated documentation approved and release. Be sure there is a process built into the PLC to review current product for meeting needs (both marketing and business) and allow for adjustments/changes as the product traverses it lifecycle
  4. Design a process around the End-Of-Life of a product both from a business perspective (not to strand any inventory, leave customers without solutions, etc.) but also from a regulatory perspective in that no product really “ends” – it rather gets archived and stored so that design history is retrievable (very much like Levi’s…they “never die they just fade away” but the history must endure). Note: although the general case of the PDP provided in previous sections has been focused primarily on the R&D and production phases of this PLC, the EOL Process is equally important to define and put in place so that product is properly archived for future reference, retrieval and audit compliance.

This short article can never do full justice to defining a full Product Life Cycle (PLC), there have likely been many books written on the topic, but the key point here is that there is not a whole lot of FDA regulation or guidance for Design Control that discuss PLC. A basic product management tool like a well-defined PLC can play a huge role in compliance to Medical Device Design Control and overlaid with a well-defined Product Development Process can help avoid design control issues, FDA finding or even worse warning letters or other punitive action. From a Product Managers perspective the earlier in the startup device manufacture and earlier in the product life that these principles can be applied the better managed the overall product can be managed both from a compliance perspective and from a business perspective. Regardless of the FDA compliance managing the product from a business perspective can pay big dividends in determinate time to market when managing the PLC married to a well-defined and practiced PDP. These PLC and PDP topics along with a perspective of FDA Design Control normalization and enterprise tools that manage the process and can accelerate time to market are discuss together in an Expandable Software white paper: “Quality System for Startup Medtech Companies: Design & Documentation Controls”.

Get the full detailed White Paper here.

About the Author

Dennis Payton is executive director of product marketing with Expandable Software Inc. He has 23 years of engineering, product management and executive management experience. He holds a BS in electrical engineering from California Polytechnic State University, San Louis Obispo, and post studies at Stanford University, University of California, Santa Cruz, and UC Berkley Haas School of Business.



New Guidance Offers Clarification on IDE Requirements

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

School bells are sounding the death knell of summer across the land. But, as we’ve noted before, the FDA didn’t take much time off to enjoy surf and sand.

The agency capped a busy season last week by issuing a new guidance aimed at Investigational Review Boards, Clinical Investigators, and Sponsors when determining if an Investigational Device Application (IDE) or an Investigational New Drug Applications (IND) is warranted.

Structured in a helpful Q&A format, the guidance should make it easier for device and drug companies and other entities to understand what’s expected of them in this often gray area.

For example, the guidance reaffirms that an IRB must review the qualifications of clinical investigators who conduct FDA-regulated research.

However, the agency does illustrate some situations where there is interpretive leeway for regulated entities. “In many cases, the IRB may have previous experience with an investigator or institution that would allow the IRB to readily determine that the clinical investigator is appropriately qualified to conduct and supervise the proposed research.” If that’s the case, you’re probably okay to get started.

The guidance also reminds us clinical investigator report cards are available on the FDA website. IRBs may check the lists posted on FDA’s website to determine whether a clinical investigator has been the subject of an inspection by the agency and the results of such inspections (e.g.,Warning Letters). FDA also posts on its website a listing of all investigators who have been notified of the initiation of a disqualification proceeding or have been disqualified.

FDAlogoThe guidance also spells out the requirements to determine whether submission of an IDE application to FDA is required. That determination is based, in part, on assessing the risk factor for the device. The IDE regulations (21 CFR 812) describe three types of device studies: significant risk (SR), nonsignificant risk (NSR).

The sponsor is responsible for making the initial risk determination, and presenting it to the IRB. If the sponsor has determined that a device study is NSR, the IRB must review the sponsor’s determination. If the IRB disagrees with the sponsor’s NSR assessment and decides the study is SR, the IRB must inform the clinical investigator and, where appropriate, the sponsor. The IRB should also document its SR/NSR determination in the IRB meeting minutes.

FDA can assist sponsors, investigators, and IRBs in making the determinations. Information on how to get started can be found in the agency’s 2011 guidance Procedures for Handling Inquiries Regarding the Need for an Investigational Device Exemptions Application for Research Involving Medical Devices.

FDA’s lists of investigators it has examined can be found here:





FDA Wants Your Patient Preference Input for Medical Device Regulatory Processes

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

After a surprisingly busy summer, the FDA is leaping into September with a two-day meeting where you can be the star — or on the defensive.

Mark your calendar for Sept. 18-19 at FDA headquarters in Rockville, MD for “The Patient Preference Initiative: Incorporating Patient Preference Information into the Medical Device Regulatory Processes.”

FDA’s goal is to open a dialogue on the best ways to incorporate patient preferences on the benefit-risk tradeoffs of medical devices into the full spectrum of the Center for Devices and Radiological Health (CDRH) regulatory decision making.

It also aims to advance the science of measuring treatment preferences of patients, caregivers, and health care providers. The agency intends to use information gleaned from the workshop and subsequent public comments to help regulators, industry, providers, patients, and device innovators to get on the same page.

FDAlogoMeantime, FDA’s busy summer included a slew of new warning letters. In Taiwan, Soleetech Corporation, a manufacturer airway (extension) connectors, flat out told the FDA it didn’t have, and didn’t plan to develop, any kind of Corrective and Preventative Action (CAPA).

I understand that different nations have different cultural quirks, but telling the FDA you aren’t much interested in CAPA is a universally bad idea.

August was indeed a busy warning letter month. As of August 22, more than dozen had already been issued. And with the month not over, and a lag time in posting some letters, August is shaping up to be a big enforcement month.

Nearly half of August’s warning letters zeroed in on Medical Device/Adulterated/Misbranded/Lacks PMA and/or 510(k) alleged shortcomings. Typical of this trend was an August 8 letter to Healing Dives Inc.

So, as we all drive back from the beach, it’s time to examine FDA’s next moves. Look for an upcoming post from fellow blogger and former FDA inspector Patrick Stone with his wish list for what he views as the FDA’s most burning issues in September and beyond.



FDA Warning Letters Emphasize CAPA, Design Issues

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

The FDA focused its regulatory laser beam on the Midwest and overseas in the latest wave of medical device warning letters.

Enraf-Nonius B.V., a device maker based in the Netherlands but doing business in the U.S., was hit in several areas, including:

Failure establish and maintain device controls in relation to acceptable validation during a clinical trial, failure to set up procedures to determine whether device changes require validation or verification, and failure to document post-production design changes.

As is so often the case in FDA warning letters, CAPA again reared its head. In the July 5 letter, the device maker was charged with several alleged CAPA shortcomings. These include failure to establish a process that makes certain corrective actions are noted and take steps to prevent the issue from happening again, and failure to address illegible, missing and/or incorrect component codes.

Back here at home, Pennsylvania-based firm Lenfest Media Group was advised in a July 1 letter that its product claims lack FDA clearance or approval. Lenfest markets its WaxVec that it claims “gently draws dirt particles and moisture out of your ear quickly and safely.

warning640In Ohio, x-ray systems-manufacturer Meridian Medical Systems was hit with CAPA violations, and alleged design history violations, including:

  • A design plan for the project
  • Established or approved design inputs/outputs for the system
  • Verification or validation testing for the system
  • Design transfer
  • Risk management for the system
  • Design reviews

The firm was also warned for allegedly not having a handle on its suppliers, an issue that the FDA appears to be focusing on more and more. It could be, in part, because more and more domestic firms and outsourcing device manufacturing work overseas.

Completing our latest round-up, we travel to Turkey, where FDA issued a June 27 warning letter to Aygun Cerrahi Aletler A.S. Surgical Instruments Co., with charges of CAPA shortcomings and several other issues, including failure to establish and maintain procedures to ensure that the device design is correctly translated into production specifications, and failure to establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.



Electronic Medical Records: Don’t Feel So Secure

Patrick Stone

Patrick Stone, President, TradeStoneQA

How often do we see HIPAA violations issued because a regulated entity did not secure the electronic records at the hospital and small clinics? Large scale security breaches and, sometimes, the selling of your e-records by various third party sources are in the news. In Massachusetts and New Hampshire an e-record vendor recently admitted to large scale e-record breaches. The FDA has provided some guidance on what is expected for e-records, but no real guidance on security. That may be one of the reasons that so many of the E-Systems I have reviewed meet the minimal requirements but have security vulnerabilities.

The second half of this story will send shivers down your spine, and then make you mad. Your e-records are being sold to insurance companies, debt collectors, and prospective employers. Yes your e-records are for sale to the highest bidder.  The 1996 HIPAA law left provisions for certain entities to access your entire medical record. Some of the stolen or hacked e-records get sold, and that’s terrible of course, but ironically most of the time your e-records are sold it is “legal.” Securing medical e-records comes with a price and even with some of the best security there may still be a breach. In most business models for building e-record systems security is last on the list. Sadly, it doesn’t appear to be much different in the healthcare industry.

So, what’s to be done?

doctor electronic health recordWill it take a 21st century modernization of HIPAA, written almost twenty years ago and before the e-record mandate? Or will we limp along with legislation that is increasingly showing its age?

In our digital age of e-records our security should be insured since we pay for the care we receive. HHS and congress should be focusing on this but they are currently being distracted by advocating or decrying Obamacare.

And speaking of Obamacare, that new law also has some troubling provisions about who is allowed access to your records, and some “interesting” exceptions to those provisions.

But don’t get me started on Obamacare implentation before we deal with HIPAA.

For now we can only trust (read: hope) but not verify who really has access to our medical e-records that are weakly protected by a 20th century law.

Patrick Stone is the author of Bubble Gum Badge – An FDA His-Story. You can also follow him on Twitter.



Jeff Mazik joins AssurX as Vice President, Life Science Solutions


Jeff Mazik, Vice President, Life Science Solutions

Jeff Mazik, Vice President, Life Science Solutions

AssurX is pleased to announce the appointment of Jeff Mazik as Vice President, Life Science Solutions. Prior to joining AssurX, Jeff served as IT Head, Manufacturing & Engineering Systems for Alcon (a Division of Novartis). Jeff worked at Alcon for 15 years, and was responsible for the global rollout and support of many varied global software systems in the areas of Quality Management, Engineering, Manufacturing, Corporate, and Safety/Security/Environmental Affairs.

During his tenure at Alcon, Jeff helped implement and/or oversee the global use of many varied software solutions, including the rollout and use of over 60 CATSWeb processes, the implementation of physical access security systems to all plants, a global corrective and preventative maintenance solution, an eMSDS solution, global ERP initiatives, Business Intelligence solutions, as well as corporate projects such as CCTV systems, and the Point of Sale solutions for the company’s cafeteria and company store.

Furthermore, from 2008 to 2012 Jeff served as one of Alcon’s 9-person core team in the start-up of the Alcon Singapore Manufacturing plant. He was intimately involved in the initiation, planning, design, development, construction, commissioning and startup of Alcon’s first Asian-based aseptic pharmaceutical drop-tainer filling plant in the Republic of Singapore. As such, he oversaw the implementation and validation of multiple applications and was responsible for the design and implementation of the entire IT infrastructure for this new pharmaceutical manufacturing plant, including plans for cable tray trunking, network drops, communication room design, and audio/video conferencing technology. As the IT Manager for this new plant, he was also responsible for determining the policies and procedures for the operation of the new IT department: including processes required to meet FDA, HSA, and other regulatory guidelines for pharmaceutical and medical device companies.

Prior to his career at Alcon, Jeff consulted for a Division of IBM (ShowCase Corporation), implementing Business Intelligence and Data Warehousing tools to healthcare providers. Prior to IBM, Jeff was the Director of Implementations for McKesson Provider Technologies (previously Enterprise Systems, Inc.) implementing software solutions for Materials Management, Operating Room Scheduling, and Finance in Hospitals across the United States.

In 2003, Jeff won AssurX’s Customer of the Year, and has seen CATSWeb used in many varied ways to meet regulatory and business needs. He is excited to be able to help all of AssurX’s Life Science customers better realize the value of CATSWeb to meet their business demands in this constantly changing and evolving industry.



You’ve Got eMDR Questions; FDA Has (Some) Answers

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

In a new 47-page guidance the FDA appears to be doing its best to cover the waterfront for medical device manufacturers who need to better understand the complex Medical Device Reporting (MDR) requirements. Topics range from the big picture (who is subject to this rule) down to specifics (how many times must a manufacturer call a user facility for information before it can close the file).

In a perfect world, the FDA would pick an intelligent, telegenic representative and provide this information in a live Q&A format with follow-up questions from the audience. Until that day, we’ve got to rely on the new guidance, published July 9, 2013.

MDR is FDA’s mechanism to work with medical device companies to identify and monitor adverse events, with an eye to detecting and correcting problems as quickly as possible.

Medical device makers are required to report when one of its devices may have or could contribute to a death or serious injury. Device makers have between five and 30 days to report, depending on the severity of the potential adverse event.

eMDR, Electronic Medical Device Reporting

The Electronic Medical Device Reporting Process (Source: AssurX, Inc.)

We won’t try to summarize the entire document here. Instead, we’ll highlight some of the more interesting FDA “answers” to its questions.

  • How should you handle a voluntary report when you don’t know the source of it? FDA says to first evaluate the complaint to see if it is a reportable event. Base that determination on in-house information, and consider contacting a user facility, importer or other initial reporter related to the alleged event. “Your decision about whether or not the event is an MDR reportable event should be based on the findings of your evaluation,” the agency says.
  • What is a ‘remedial action,’ and are those reportable to FDA and included as part of the more urgent 5-day report? The short answer is yes. FDA wants medical device manufacturers to attack problems with a wide lens. “FDA does not consider an action taken to correct only a single device involved in an MDR reportable vent to be a remedial action.” In other words, don’t forget CAPA and root cause analysis.
  • What does FDA require for developing, maintaining, and implementing written MDR procedures? FDA says medical device manufacturers must include internal systems that provide for: timely and effective identification, communication, and evaluation of events; a standardized review process or procedure; and timely transmission of complete reports to the FDA.
  • What information contained in an MDR report is subject to public disclosure. The bad news: All of it. The good news: FDA, before releasing a MDR report subject to a Freedom of Information Act request, will delete information covering trade secrets, personal medical information, and names and other identifying information of a third party that voluntarily submits a report, e.g., physicians and other health care professionals.

Comments are due in early October. Submit them to www.regulations.gov. Include the docket number (1828) with comments. Short URL for the draft guidance document: https://federalregister.gov/a/2013-16395


Eating GMOs Isn’t Kosher For Anyone

Kim Egan

Kim Egan, Founder, Saltbox Consulting

What do China, the State of Maine, the State of Connecticut, Chipotle, and Whole Foods have in common?   They all think you have a right to know whether the food you are eating contains any genetically modified organisms, known as GMOs.

I like that.  Why do I care? Because the genes in GMO plants have been altered in a laboratory to do something that the plant would not normally do.  This means that Mother Nature did not deem it good.  Mother Nature did not deem it good that a tomato should live forever in its fully ripened state, even after traveling around the world in a crate on a truck or boat or a plane and sitting in a grocery store for days if not weeks.  Mother Nature did not deem it good that corn should be able to kill insects while it grows.  Mother Nature created insects.  They are useful, whereas acres and acres of corn are not.  Mother Nature created corn to feed birds and deer and the occasional human.  Not to feed every livestock animal in the country or to sweeten the chemical concoctions that the soft drink makers dream up.

I find it ironic that the vote in Maine on labeling GMOs took place the same month that Edward Snowden demonstrated that he, too, thinks Americans have a right to know.  And that Congress – the greatest legislative body in the world – appears to agree that all Americans have a right to know all the super-top secret stuff the government is up to, but doesn’t think Americans have a right to know if they are eating GMOs.  I know I’m going out on a limb but I don’t think we should expect this Congress to pass a bipartisan bill to require all food manufacturers and restaurants to label GMOs anytime soon.

Okay, next one.  What do Amy’s Kitchen (frozen pizza), Blue Diamond (peanuts and almonds), Arrowhead Mills (stone-ground everything), and Silk (the company that brought tofu to America), have in common?  They all refuse to use GMO ingredients in their products.   Let’s all raise a cheer for these companies!  This is what makes America great!  Government won’t do something the people want?  Do it yourself!  Decide your elected representative is a lazy-good-for-nothing fat cat eating pork out of a barrel?  Take matters into your own hands!

corn_on_the_cobOkay, next one.  What do Judaism, the Church of England and Saudi Arabia have in common?  This one seems a little harder.  But it turns out that all three of the world’s major religions prohibit GMOs.  Saudi Arabia bans them outright, as does Algeria, Brazil, Egypt, the European Union, Peru, and Thailand. The Church of England won’t let any GMO crop trials on any church property, which amounts to 60,000 hectares in England.  A hectare is approximately 2.5 acres, which is 150,000 acres, or the equivalent of about 234 square miles.  That’s what the Church of England owns. The whole of England is only about 50,000 square miles big, from which, if you are a GMO scientist, you must subtract cities, towns, factories, airports, train stations, banks, houses, roads, outbuildings, seaside resorts, castles, Stonehenge, palaces, manor houses, Kew Gardens, etc.  I bet there’s not much left after that.  And lastly, GMOs aren’t kosher.  There’s so much more to it on that one.

There’s more to say about GMOs, such as the fact that the U.S. government regulates GMO corn as a pesticide, not a food (that’s why we want to know what we’re eating, right?!), or that Tasmania has declared GMO rapeseed to be a weed (weeds are bad, not good).

But the worst thing I learned researching this post is that M&Ms, Stoned Wheat Thins, Pringles, and all Pepperidge Farm cookies have GMOs in them.

The horror, the horror.


Switch to our mobile site