Public Workshop
America's Blood Centers: Blood Establishment Computer Software (BECS) Conference
DEPARTMENT OF HEALTH AND HUMAN SERVICES
FOOD AND DRUG ADMINISTRATION
CENTER FOR BIOLOGICS EVALUATION AND RESEARCH
Maryland Ballroom
Hilton Washington, D.C./Silver Spring, Maryland
Thursday, July 10, 2008
Printable Version (PDF 365 KB)
Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®.
List of Participants:
JIM MacPHERSON
CEO, America's Blood Centers
DON DODDRIDGE
President & CEO, Florida Blood Services
SHERYL KOCHMAN
Chief, Devices Review Branch, OBRR/CBER/FDA
RODEINA DAVIS
VP CIO, Information Services, Blood Center of Wisconsin
MARSHA SENTER
Products Manager
LINDA WEIR
Expert CSO, FDA/CBER
T.W. WALKER
Executive Director of Regulatory Affairs And Quality Audits, Canadian Blood Services
ANGUS MACMILLAN DOUGLAS
Consultant, Alliance of Blood Operators
JOAN LORENG
National Expert investigator, Biologics, FDA/CBER
TAMARA POLING
Information Systems Committee, AABB
JEFFREY McCULLOUGH
MD
* * * * *
P R O C E E D I N G S
(8:30 a.m. )
MR. MacPHERSON: Good morning. When we budgeted for this conference, we figured 50 to 60 attenders. We have 170 registrants. So it's going to be very cozy for the next 2 days. And hope you appreciate that, and it will get -- it will force the network be even more so. We have people from all over the world here at this conference. It's interesting conference, the first of its kind to address these kinds of issues. And I'm going to give a bit of an introduction.
I'm Jim MacPherson. I'm the chief executive officer of America's Blood Centers. And I'm just going to give you a little bit of background. I'm going to go through it very quickly because a lot of you understand this and know this. Just to tell you who are the sponsors and who's been involved in this. ABC took the lead on this in cooperation with the Alliance of Blood Operators.
Now, the Alliance of Blood Operators is a -- if you will, a burgeoning trade association, if you will, of trade associations that includes at this point, ABC, the American Red Cross, the Australian Red Cross blood transfusion services, Canadian Blood Services, the European Blood Alliance, and the NHSBT, which is the English Blood and Transplant Service.
We are looking to figure out how we can open up membership in the future without sort of becoming deluged, but that's who we are right now. We've been around for about 3 years.
CBER, part of FDA, the Center for Biologics Evaluation and Research, is a cosponsor, and was very heavily involved in all the planning, very supportive, and I want to thank certainly Alan Williams and Jay Epstein and all the people from CBER who have been very cooperative and helpful through getting this thing together and helping to get it organized.
Additional sponsors -- AABB, AdvaMed, and the American Red Cross. And as I said, American Red Cross is a member of ABO. This is the planning committee. Wasn't quite a cast of thousands, but it was an interesting group to get together, and especially want to recognize Rodeina Davis as co-chair, along with Becky C (phonetic) from blood services, the quality source.
And you can see this. It's a good group of people and very representative. There are four CBER people on the planning committee. Let me just go through a little bit of history for backgrounds to frame this, and then I'll introduce Don Doddridge who is ABC's president, to talk a little bit about what we are going to do today and where we are going to go.
And this is from memory, so I -- if the facts are slightly off, forgive me, I'm sure someone will correct me. But in the early 1990s, after a major recall and several major incidents involving unvalidated blood center manufacturing software, ABC -- at that point it was CCBC -- we sent a letter to CBER requesting that CBER regulate software as a medical device.
So if you want to look at the enemy here, it's us. We asked for this, and so here we are 15 years later, saying we didn't mean it. No, we -- saying, well, we've got a problem -- (tape interruption) -- oh, excuse me --
(Laughter)
MR. MacPHERSON: Now, the rationale at that point was there was little or no blood center expertise and computer software to really understand what was in the black box. That frankly was it, and that's -- that was the overwhelming opinion from our members. Well, certainly times have changed.
In 1994, FDA issued a letter stating that it would treat software intended or used in the manufacture of blood and blood components as a medical device that needs to be separately cleared by FDA through the 510(k) process as you are all aware. But then we got the suspenders. In the late 1990s, FDA said that just like every other manufacturing facility that's regulated by FDA, that we needed to extensively validate the software before it's used.
Now, that approach of validation before use has been adopted worldwide. Some of you, I'm sure, are aware of PICs (phonetic) -- I forget what it stands for. Someone -- I'm sure someone can tell us. But anyway, there is a -- the PIC standards. It's sort of a self regulation, but it's a group of manufacturers along with the regulators of various different countries.
They work together to come up with standards -- voluntary standards that organizations will implement. And they -- and actually I found out -- I didn't realize that there is a PIC standard or a PIC guide that pertains to blow establishment software that was released late last year. And the number is, as you can see, is on the slide.
More recently, FDA had stated that software used in the clinical setting, the cross-matching, transfusion services, tracking blood to patient bedside would be subject to 510(k) clearance if controlled by a licensed blood establishment, which I think is also sort of stimulated saying okay, do we really want to go there, and if so, how do we want to go there?
Now this is, of course, the biased opening point of view, but the unintended consequences of the way BECS are regulated at this point. And again, this is my opinion so you can throw brickbats at me. Worldwide blood establishments are served by a -- have -- wind up being served by a niche industry of poorly capitalized software houses.
Now, this is not a bad thing to say about any of the software houses that are represented here, and you are here in very large numbers. But the reality is that it is a niche industry of mostly small and a few medium-sized software houses. Available software is usually years behind what's technologically available off the shelf, and changes are slow and expensive, because again, these are fairly small companies and they are struggling to keep up.
State-of-the-art and reliable off-the-shelf and Web-based software available to pharmaceutical manufacturers is not available in the U.S. Now, I make a point of this, because we are the only industry, the blood establishments are the only industry that are subject to 510(k) requirements. The pharmaceutical industry is only subject to validation requirements.
So the result is manufacturers such as Microsoft, Adobe, SAP, which are heavily involved in the pharmaceutical industry, refused to serve the blood establishments because of the 510(k) requirements. Now yesterday, our IT consultants from a company called Lunexa in San Francisco made a presentation, and I inserted this slide. So this is not in your folder, but we can get copies to you if you want.
But it doesn't really say too much, except what I was struck by is that he gave an analysis of the industry compared to other industries. And what he said -- and he is in the room and so if I misquoted him or over-quoted him, I'm sure he'll correct us. But basically, unlike any other manufacturing setting, the blood center niche market created by 510(k) regulation, there is no what's called "ERP," and I just found out what that is yesterday.
And I remember -- I think its enterprise research, but I don't know what the "P" stands for, meaning -- but meaning end-to-end manufacturing software in the blood center market -- there is none. What we are doing is putting pieces together, the regulated software versus all the other pieces that we need to run our business to control personnel, to control training records.
All this that's not regulated, we have to put these pieces together. And so, those systems don't naturally talk to each other, and that requires us to put fixes together for that, because we are just putting pieces together, which is another risk involved in doing this. And the systems don't talk to each other.
In ERP manufacturing software, the systems are designed so that they do talk to each other. But our systems don't talk to each other. And therefore this lack of coordination means no easy means of correlating -- correlation of practices or experiences. And this is -- as I said in the beginning, this is sort of unprecedented in manufacturing setting, so.
Now, this leads to two questions and again, this is -- these are my biased views of things, but we've -- this has pretty much come from a lot of discussion within -- certainly within our organization and with the American Red Cross and with other organizations. Does BECS still uniquely require both 510(k) clearance and user validation requirements? Are the benefits of 510(k) clearance which are poorly documented, worth the risk of unintended consequences?
And are there alternative ways to both assure the confidence of the regulators and the needs of the blood establishments? So starting giving that overview, let me introduce Don Doddridge, as I said, who is the president of America's Blood Centers and the president of Florida Blood Services in Tampa St. Pete, to tell us what we are going to be doing today. Thanks, Don.
MR. DODDRIDGE: Thank you, Jim. Just a couple of housekeeping. We -- I know as we all have cell phones, I don't think anybody travels without one, if you do have a cell phone, make sure it's either turned off or on vibrate. And another housekeeping; the restrooms are at the back of the room in the hallway. And we will have a morning break, then break for lunch, and then we'll have an afternoon break.
I'd like to welcome you to this conference. There's many people out here that are good friends, and we've been friends for many years. I guess we're all getting a little greyer over the years. And this is our first attempt at a Blood Establishment Computer Software Conference, as Jim spoke about.
Before I introduce the first presenter, I'd like to briefly describe the goals and the structure of this conference and -- so that we can proceed. BECS conference is a workshop for information technology stakeholders in the blood banking community. The aim of the workshop is to answer two multifaceted questions.
Do the current regulations of BECS not only help ensure the safety of the blood supply, but also allow blood centers to keep abreast of the most current advancements in blood banking and in software? And if not, why not, and what step should we -- be considered to modify that current situation? Now, if we accomplish that today that will be a miracle, but if we make some first step so that I think everybody will say that this conference was a success.
We've had a committee of representatives from blood centers, national blood organizations, the federal government who had planned, I think, an excellent program today. During the first part you will get a better overview of the IT landscape including facts about the software blood centers use, how it's validated, and why it is regulated to the 510(k) process.
During the second half, participants will take that information, and in breakout sessions during this afternoon, we will have a panel discussion. And tomorrow we'll attempt and hopefully reach some common ground on ways that the current scheme works, and ways that it can be improved. And hopefully, while we're on that common ground, we'll all agree on the next steps.
So keep that in mind as we go through this process. Hopefully by tomorrow afternoon, there will be some agreement among all the parties involved. It's a special pleasure today to have with us Dr. Jeff McCullough. And Jeff, where are you in the room here? Jeff, please stand up. Jeff is a longtime friend, and I'll call him a pioneer in transfusion medicine.
He's been a strong supporter of the blood banking community and been, like I said, with his work in -- with transfusion has been outstanding, and we're lucky to have him with us today. Jeff will be helping us frame our questions today; he will be playing the devil's advocate, and hopefully challenging us to find more innovative solutions when we get stuck.
Towards the middle and the end of each day, he will review and crystallize the issues and recall highlights from the presentations or comments that help us reach some consensus on what is needed to move forward. After lunch there will be breakout slips available at the registration desk in the foyer.
Each breakout will have a slightly different topic, and you are encouraged to pick up a slip for the breakout session which you have an interest in. If the slips are gone for a particular breakout session, please take the next slip of your second choice. You will find the breakout topics on your agenda in your packets, and there will be breakout facilitators and scribes at each sessions.
Before I introduce our first speaker, I'd again like to thank the AABB staff who have done an excellent job in putting on this conference. And Bob, special thanks to you for helping to keep us all together here. And now, I'd like to introduce our first speaker.
Our first -- since FDA regulation is one of the central issues of this conference, appropriately our first speaker is from the FDA. Sheryl Kochman oversees all aspects of the BECS device review program in OBRR, and she is well qualified to give us a short lesson on the history and rationale of regulated BECS as a medical device. So with that, I'd like to welcome Sheryl. Please, Sheryl.
(Applause)
MS. KOCHMAN: Thank you. As I'm sure you can imagine, AABB and ABC were instrumental in bringing this to fruition. FDA is grateful to be here and to bring the issues to the surface, to have a chance to speak in an open forum. And it's been a long process, but hopefully it's going to one that's worth the products of the two days.
With that -- most of my talk is probably going to be ancient history to many of you . I won't call them "fond memories," but they are probably memories.
(Laughter)
MS. KOCHMAN: I have a lot of slides, but many of them, as I said, are a rehash of ancient news, so I'll go through them quickly. My objectives are to help you understand the issues that led to the review of BECS as medical devices, to understand FDA's current perspectives regarding regulation of software in general, to understand the regulation of medical devices, and to understand the assignment of responsibility for software as equipment versus software as a medical device.
As you all recall, initially when blood banks started using software, FDA was regulating it as if it were an instrument or a piece of equipment in the laboratory. We were not at that point regulating that other device at the manufacturing end of things.
In the late 1980s, FDA started noticing that because of HIV the number of donor-screening questions asked significantly increased, as did the number of tests performed that's resulted in increases in the volume of data to manage. Reliance on computerized data management and automation became very prevalent as opposed to the careful personal checks and double-checks that were being done annually.
And as you can imagine, errors leading to the release of unsuitable units of blood were bound to happen. In 1988, in response to congressional concern about the safety of the blood supply, FDA initiated 100 percent inspection of blood establishments. And I want to quickly go over the timeline from that point to where we are today.
In April of 1988, the FDA issued two different memos to blood establishments, one about the control of unsuitable blood and blood components, and another about the recommendations for how to implement computerization in blood establishments. That was followed a little over a year later with a memo to blood establishments specifying requirements for computerization of blood establishments. That was September 8, 1989.
Interestingly, November 13, 1989, the draft FDA policy for the regulation of computer products was made available. This described FDA's authority to regulate computer hardware and software products. It described three levels of regulation based on risk to the patient if the software were to fail.
It described current and future exemptions. It described the 510(k) process and the PMA process. As I said, it's interesting that this came out shortly after the inspections were started. It specified that computer hardware and software used in blood banks would not be exempt from the regulation.
Then in March -- on March 20th of 1991, two memos, two additional memos were sent to blood establishments; one, the responsibilities of blood establishments related to errors and accidents in the manufacture of blood and blood components, and another, deficiencies relating to the manufacture of blood and blood components.
We are continuing to hope that we could regulate and help people understand how to validate. So in September of 1993, the draft guideline for the validation of blood establishment computer systems was made available. The target audience for this document is the manufacturer of blood and blood components, not software manufacturers.
Then in November of 1993, there was an FR notice stating that there would be a workshop on validation of BECS. And it made known the availability of the draft guidance and it requested comments. The workshop occurred on December 6th and 7th 1993, which was called workshop on validation effects.
On March 31, 1994, a memo to Blood Establishment Computer Software manufacturers first went out. It stated that software used in blood establishments is a medical device. And shortly afterwards, there was a talk paper published April 13th of 1994. It stated simply at the top "Blood Establishment Computer Software regulated."
What's important to note here is that it clarified the term "blood establishments" includes blood banks, blood centers, blood product testing laboratories, plasma freezer centers, and transfusion services. So it was made clear as far back as 1994, of all the places that FDA acknowledged, this type of software was being utilized.
Then in August of 1994, the March '94 letter was actually published in the Federal Register rather than simply being mailed out and posted on a Website or something. February 10, '95 a letter to BECS manufacturers announced that the deadline for submission of 510(k)s was March of 1996. This gave people just over a year to get their things together and submit it.
On July 11th of 1995, there was another workshop addressing quality. This one -- I'm sorry, another guideline addressing quality -- this one, "Guideline for Quality Assurance in Blood Establishments." I put this here because this one also included references to validation of computers and that sort of thing.
In October 3rd of 1995, there was an FR notice that published the February 10, '95 letter, and also an extension of the time period for the pre-market submissions. November of '95 there was also a memo to blood establishments, guidance to -- for blood establishments concerning conversions to FDA-reviewed software products.
We stated at that time that we believed software conversion should be completed by March 1996, but that we would handle request for extension on a case-by-case basis. May 7th of '96, we felt a need to a send a letter to BECS manufactures reminding them of our previous letter, telling them to submit a 510(k).
And on January 13th of 1997, the guidance, "Reviewer Guidance for a Pre-Market Notification Submission for Blood Establishment Computer Software" was published. This was the document that was developed, because this was a brand new program . This was the first time we were going to be looking at software.
We knew we would be looking at a lot of submissions at the same time. We knew it would be critical to ensure consistency in the review process. So we started out developing lists of things to look at, and eventually turned out into a reviewer guidance.
On March 20th of 1998, there was a Blood Product Advisory Committee meeting, at which point we proposed that the committee sit as a medical devise panel and vote on the classification of BECS. At that BPAC, inspectional findings were reviewed. The device classification process -- since most of the devices are classified through CDRH device panels, we felt it important that our advisory committee understand device classification -- that was reviewed.
We discussed the use of a special control for Blood Establishment Computer Software to allow for the submission of abbreviated 510(k)s. There was a unanimous vote by BPAC to classify BECS as class II devices. And I'm going to discuss the classification process in a few minutes. This vote had the effect of requiring manufacturers of BECS to manufacture under the design controls of the Quality System Regulation.
It also allowed for submission of special controls with conformance to design controls. After long debates and discussions, in January 21st of 2000, the responses to two citizens' petitions were sent out. One petition came in on March 7, 1996, another came in on January 28, 1997.
Both of them were contesting the fact that Blood Establishment Computer Software was a -- met the definition of a device, and that FDA had the authority to regulate it as such. The citizen -- the response to the citizens' petitions describes completely FDA's rationale and their findings related to the jurisdiction and the authority for us to regulate software as a medical device.
On January 11, 2002, the "General Principles of Software Validation - Final Guidance for Industry and FDA Staff" was published. And it's very important for me to point out at this point that this is a joint document between CDRH and CBER. We had input into previous guidances that CDRH published, but generally it was not recognized as such. You sort of had to note it through the things that were said within the guidance.
This was one of the first software-related guidances were we clearly stated by having both our names present on the coversheet, that this guidance document was a joint effort. Again, it's clearly stated in here that "software that is itself a medical device," and they give us the specific example of blood establishment software to show that we had universal thinking on this.
May 12th of 2005, another joint guidance was published -- the "Guidance for Industry and FDA Staff for the Content of Premarket Submissions for Software Contained in Medical Devices." The title is a bit misleading, because clearly BECS is not contained in a medical device.
So the title is misleading, but the scope does say that it's applicable to those devices which are themselves standalone software. Again, it shows that we are being consistent with CDRH, that this is the FDA's approach to software regulation. On January 3rd of 2007, there was a draft guidance published by CDRH, "Radio-Frequency Wireless Technology in Medical Devices."
As I'm sure you can imagine, wireless devices -- wireless equipment is pervasive. And CDRH was hearing reports of problems with interference, problems with delays in the signals getting past. So they developed this guidance to assist industry systems and service providers, consultants, FDA staff, and others in the design development and evaluation of RF technology in medical devices.
This guidance references several national and international standards, and discusses some of FDA's regulatory requirements for medical devices, including premarket and post-market requirements under the Quality System Regulation.
Most recently, FDA signaled its confirmation that software can, indeed, be a medical device by publishing a proposed rule in February 8, 2008 -- "Devices: General Hospital and Personal Use Devices; Reclassification of Medical Device Data System," otherwise known as MDDS. This proposed rule recognizes that use of computer-based and software-based products as medical devices has grown exponentially.
Many of you have probably been to the doctor and seen him pull out his PDA to pull up some kind of record, or document some kind of record, and knowing that it had gotten that far, FDA became concerned. They also noted that interconnectivity and complexity have grown in ways that could not have been predicted in 1989 when the first draft software policy was published.
Growth and expansion have created new considerations for elements of risk that not -- that did not previously exist, but the level of FDA oversight is still directed primarily on the risk to the patient if the software fails. So we're -- our thinking of where the risk lies, and how to regulate according to that risk, has really not changed.
A little bit more about the proposed rule. It describes what an MDDS is, and it recommends classification of them. And much of this text is actually taken directly from the proposed rule. It is available on the Web if you want to pull it down and read the whole thing. But in general, MDDSes are relatively simple devices that transfer, exchange, store, retrieve, display, or convert electronic medical data.
They do not provide any real-time monitoring, alarm detection or display, or diagnostic or clinical decision making. They may be reducing some risks related to manual recording. For example, they'll -- they should cut down on clerical errors. But they also present new risks because of the lack of transparency and because users tend to rely entirely on an automated system once they have it.
They put all of their trust in the automation, and they tend to believe whatever the device is telling them. In this case, FDA believes that MDDSes can be regulated as class I devices. They believe they're low risk, that there is low risk to the patient, and they also believe that they can be exempt from submission of a 510(k).
So now, as I said, I'll get into regulation in medical devices. The first question we ask when someone says do I need to submit my thing to FDA, the very first question is, is it a medical device? "A medical device is an instrument, apparatus, implement, machine, contrivance" -- just where software fits in -- implement --
(Laughter)
MS. KOCHMAN: -- "implant, in vitro reagent, or other similar or related article, including any component part or accessory which is intended for use and ..." and I've left out a whole bunch of the definition, because it's like a paragraph long -- intended for use in the diagnosis of disease or other conditions or in the cure, mitigation, treatment, or prevention of disease.
So we believe -- and we believed then and we believe now that software is -- BECS software is a medical device. It's certainly a contrivance, and we believe that one of its main intended uses is to prevent transmission of disease.
Our next question is, is it an interstate commerce or commercial distribution? 510(k) regulations actually apply when a product is for sale or for barter or exchange in interstate commerce. We also consider that the data -- that the software itself may not be in interstate commerce, but the data may be transmitted or accessed across state lines. And so that's another question that we ask.
Now, back again to some ancient history, device classification. Pre-amendments devices are those that were on the market prior to the enactment of the Medical Device Amendments of 1976. Once those amendments were promulgated, we began regulating medical devices. And it was determined that they should be placed into three classes based on the risk -- class I, class II, and class III.
Class I devices are those devices wherein general controls alone are sufficient to provide reasonable assurance of safety and effectiveness, or it is unclear if general controls alone are sufficient, but the device is not life supporting, life sustaining, or of substantial importance in preventing impairment of human health.
And I've highlighted "not life supporting" and "substantial importance in preventing impairment to human health." And you would rightly ask, but what are "general controls"? That are the controls described by the act establishment registration, here's who I am, product listing, here's what I make, conformance to at the time the act was promulgated.
It was good manufacturing practice, it's -- we now refer to it as the "Quality System Regulation" -- conformance to device labeling requirements, submission of a 510(k) if applicable, and anything else in the act such -- there is other things such as prohibition against misbranding and adulteration.
A little bit more on class I devices. Most of them are now exempt from their requirement to submit a 510(k), and if for some reason they are not, they are designated as reserved. Most of them are not subject to the design control provisions in a Quality System Regulation. They are subject to the rest of the requirements, and some devices are even exempt from other requirements of the QSR.
These would be the least stringent regulatory category. The most common examples that are given of a class I device are Band-Aids -- excuse me -- adhesive bandages, tongue depressors, things like that. But for this audience, I thought you probably would want more related kind of an example, and in this case that would be blood grouping view boxes.
Class II devices are those where general controls alone are insufficient to provide a reasonable assurance of safety and effectiveness, and there is sufficient information to establish special controls. Special controls are performance standards and/or -- and these are all and/or -- special labeling requirements, guidance documents, recommendations, patient registries, post-market surveillance, other actions deemed appropriate by the commissioner, and they are in addition to the general controls.
They are generally moderate-risk devices. They may be life supporting or life sustaining, and some have been exempted from the requirement to submit a 510(k). And a good example, I think, for this audience is the automated blood grouping antibody test system. These are class II devices, and they are not exempt from 510(k).
Class III devices are those where there is insufficient information that general or special controls will provide this reasonable assurance of safety and effectiveness. That means there is no predicate. There is not something on the market that the manufacturer can say my device is like or similar to that device.
In addition, the device is life supporting, life sustaining, or of substantial importance in preventing impairment of human health, or it presents a potential unreasonable risk of illness or injury. We handle these under premarket approval, and the manufacturer must submit a PMA. Class IIIs are high-risk devices. They are in the most stringent category and again, general controls apply.
An electromagnetic blood and plasma-warming device is an example. This slide is too busy for you to read it here, but you can take it away later on and notice that the degree of regulation increases with the increase in the class. And I wanted to quickly go over the differences between regulation of something as equipment versus something as a medical device with BECS in mind.
If it's equipment, FDA is not necessarily going to know anything about the manufacturer, and the users are going to know about some of them, but probably not all of them. If it's a device they'll be registered with FDA, so we're going to know about them, and you have access to the database so that you can find out about them too.
The product is not known to FDA normally, and it is known to some users usually if it's equipment, if it's a device it's listed with FDA. So if you keep going through this list -- and I'm running short on time here -- you'll see that if it's regulated as equipment, the regulatory burden falls on the blood establishment. It does not fall on the manufacturer. It falls on the blood establishment.
If it's regulated as a medical device, the regulatory burden falls on the manufacturer, and FDA has control over it. One thing alluded to was what -- knowing whether or not regulation has changed things; it's hard to tell. At the 1989 or 1998 BPAC, they've presented data that covered 9 years. They've indicated that there were 16 recalls involving 10 firms.
In getting prepared for this workshop, I reviewed the data from 1999 to the present, which is also almost 9 years. And we have 16 recalls involving 8 firms, but one of the firms had 9 recalls. It's hard to tell; it's hard to really look at these data and know if it's really the same as it was before.
It's highly likely that we have better reporting now, and so there is a better estimate of the effective regulation, and that there was underreporting prior to the BPAC; it's hard to say. So I also looked at medical device reports which are reports of device failures that resulted in death or serious injury, or could have caused death or serious injury.
In the Mod (phonetic) database from 1996 to '98, which is only as far back as it goes and is about 19 months, there were 15 reports or 0.7 reports per month. Since the BPAC, the time period that I covered was 87 months; there were 124 reports or 1.4 reports per month. But again, we know that the reporting is not always accurate. It's not clear that there is actually a two-fold increase in the number of reports.
I also want to clarify what substantial equivalence is; it's similarity of a new device to one that is or was already legally on the market, or as we call it, the "predicate device." I note I do say "was," it can be a device that was on the market and that the manufacturer took off of the market.
Substantial equivalence is not a determination that a new device is exactly the same as one that is or was already legally on the market and it is not an FDA approval.
What this means is that since there were many different software products with varying features on the market for manufacturers to identify as the predicate device when submissions were first being made, they will continue to be different software products with varying features, unless FDA promulgates performance standards; in other words, a list of required features.
So in conclusion, standalone software can be a medical device. The level of regulation is proportional to the risks associated with device failure. Regulation as a medical device gives FDA various authorities to intervene, to correct problems, and it reduces the users' responsibilities. Thank you. Don't have time for questions. Probably don't have them.
(Applause)
MR. DODDRIDGE: Thank you, Sheryl. Are there any questions? We do have time for maybe a couple of quick -- we want to try to keep the conference on schedule. But if you have a question at this time, please come to the mike.
(No response.)
MR. DODDRIDGE: I think that's a good foundation for us to continue herein. I think she did a great job. There were no questions, so she answered all of your questions today. Now I'd like to bring up Rodeina Davis, who is the vice-president and chief information officer of the Blood Center of Wisconsin, and the unflappable co-chair of the BECS Conference Planning Committee.
Rodeina is going to describe the winter landscape for blood centers and the drivers and barriers for blood bank IT organizations. Rodeina.
MS. DAVIS: Good morning. First, I want to say I'm a blood banker first, and IT professional second. It's a pleasure to be here with you to talk to you a little bit about the system choices we have in our industry. And as I really reflected on what to write about here, I wanted to make sure -- can you hear me? All right. Okay, thanks.
As I reflected on what to write, I was thinking during my experience as a blood banker, I had the opportunity really to build the system, and I had opportunity to push a system leading with BECS. So I thought let's talk about what is my experience of being -- using -- whether to build a system or to buy a system.
And in relation, really, to the regulation that Sheryl have explained to us, the objective of my presentation really is to go over the landscape of what's been going on with the technology and where we are with the vendor as of today, to talk my role as an IT professional, and how do I position IT within any organization I work for, share my experience in developing BECS, so prior to and after the regulation, and really examine some inhibitors that as a leader in my organization will be able to deliver the IT solution to really meet the business need.
And those have -- some have to do with the regulation, but many don't have to do with regulation. But I will share some of that with you. Just to reflect back, I feel really privileged and fortunate to work for three great organizations. I was at New York Blood Center from '89 to '92. I also worked at Carter BloodCare, and I'm currently working at the Blood Center of Wisconsin.
During all the -- my tenure in three of the organizations, I had to make decision regarding whether to build or acquire a software or -- and to execute in that decision. Sometimes it's easy to make the decision as a consultant and walk away from it, but when you get the point -- am I still not? I'm sorry.
And then make the decision after that and execute on it, it puts you in a different position as you move forward. Just to -- during my tenure in blood banking, I look at little bit what's happening to the technology. And prior to 1992 -- and some of us still -- probably till now or we still deal with additional implementation wherever we have mainframe application and we use dumb terminal to access the data.
In '92 to 2005, I think we went into the client/server type of architecture. We started with the fat client and then we moved into the thin client. And I'm assuming everyone know the technology what is it about, but the fat client was basically lots of the logic of the software beside the GD on the PC or on the client versus being on the server.
And when we went to the thin-client architecture, most of the logic was really on the server, and you were able to access it via certain tool that was there, such as Citrix that most of us use over here. As we're looking in 2006 and now, we find more and more we're going into the Web browser application.
And really what we are accessing the data, the text, the images, using -- that are located on a Web page and that's where we are all moving to, that's where we would like to be, the question is how can we get there within the blood banking application.
The future what I see coming in 2000 -- as we're putting our suggestion planning for 2009-2012, we're looking at GD, at rich Internet application where you're either going to be integrating with rich media such as video. We're going to have photo. Web 2.0 is going to be in. How do we, as an organization, try to fit the new technology into the application to meet the business need?
As I looked at being in blood center and not in transfusion services, I did look at the core functionality when I look at my ERP in a blood center. And I looked at what are the main functionality for the blood center to function, and identified those, because I think we all are aware of them, whether production, laboratory, inventory management, ordering, shipping, billing, donor management, donation management, and recruitment.
That's the basis of what we do in every blood center. We have processes around it, they're all generic processes. We might have some exception here and there, but those are really the core functionality. And as I looked at the vendor that delivered the core functionalities -- so excuse me, some of the vendor, if I didn't list you here.
But I tried to look at the list of the vendor that provide the total solution. As we look at it right now, as you can see, we do have a landscape of vendor that partner with us in our industry, and that they're trying their best to deliver the solution that we need.
We also have many Point-of-Service vendor that complement the existing vendor, that give us something dealing with mobile scheduling, for example, give us something dealing with predictive darning (phonetic), to give us quite a bit of additional functionality but the core functionality are not bad.
And I think which is wonderful, because maybe you don't want to be married to one vendor all the time. The problem become how do I work with these vendor in order to create a data integration. And I think that is the challenge we all face today.
We talked a lot yesterday about the IT positioning and the IT role within an organization, but as an IT leader, I believe my mission and my job is to align the technology and the solution with the organization's strategic objective.
And for me to do that, I need to continuously improve technology, I need to make sure I capitalize on my investment that I did, make sure I would do my ROI, make sure that all the investment I did in one technology, and keep that technology up-to-date so it doesn't become obsolete.
I need to mitigate the business risk while providing disaster recovery, business continuity program, support the growth and enable all the new business offering. We talked yesterday a little bit about the offering that as a blood center we're still not in a competitive mode, we still have to come up with new offering, and we still have to create intimacy between us and our customer whether they are donor or whether hospitals.
And this is the mission -- my mission of my department right now is really to advance the mission of the blood center through high quality services, innovative, and cause effective technology solution. That's the only way I would be able with my team to deliver on the services that my blood center needs.
So a little bit about some of the guiding principle we really use, and really just to provide product and services, as I said, aligned to be able to create knowledge management and offer analytic that would help the executive and the management team make decision, have a standard configuration.
That is very important, to stay up to speed with the technology, and have a standard configuration in order for us to provide efficient and sustainable operation. And the other thing is, I believe like everyone else, before I started thinking about building an application, the question is there any application on the market that meet 80 percent of the requirement of my organization.
So I have to make -- so help making that decision and provide guidance in that regard. I thought I would share little bit of my experience with New York Blood Center. When I joined New York Blood Center, they were performing over four million tests each year for which they were only entering the negative -- these aren't many. It was what was called the "negative fill (phonetic) system."
I mean -- and their driver to put -- automate that area was quality, compliance, reliability, connectivity, and production course. All the vital testing instrument were not connected to the computers. We used to get list of report, the folks used to take those report. They -- one person would enter only the positive or very active and other person would verify it.
It was the course of doing this and the potential for errors was very high. So I was thinking that was the time now that -- Sheryl, I'm trying to put your timeline along this timeline. That was the timeline, I think, when they take him up with all the automation on computerized requirement for -- so I remember Dr. Caplan (phonetic) and Dr. Bianco here said we need to do something about this.
So in order to do something, we -- really we had to look hard how to get this done. Software, at that time, was not available on the market really to deal with the volume that New York Blood Center had. They were collecting over 550, importing 250,000 from the European, a total of 750,000 units.
So we didn't have an IT resources' knowledge about a new technology. We had at that time PDP-11, we had excellent IT folks that focusing on that technology. And as we were going to build new system, we needed to partner with someone else to get it done. The problem with when you build, you need the subject matter expert.
And when you -- as we all know, you cannot build with the IT folks. You really need to partner with the subject matter expert. And at that time, we did not have dedicated subject matter expert. And as we started working, we really needed to select -- we pulled people from the lab in order to work on this. And it was a very good marriage of the subject matter expert and the IT staff to build the system.
And of course when we started that, they have not done a major project like this. We didn't have a business portfolio and project management process, and we needed to import that and put it in place. What did we do about this? We builded a system called Safe Blood that ran for production and laboratory function. Later on NYBC built another system, Safe Donor for donor management and recruitment.
The blood center has invested lots of dollar, lots of amount building excellent system, and I'd be happy to say that Safe Blood was really nominated for the Smithsonian Award and we got the second prize. I think WebMD got first at that time. I don't remember who was the -- but then the FDA introduced the BECS in 1994.
As Sheryl said, none of us knew what the heck that meant, the BECS (inaudible). I mean we were thinking what does it mean for us, what do we do. We had no idea what to do. And I think at that time, as we started getting clearance around 1997, I think that was the time Sheryl mentioned when a guideline was published.
And during that time, we started all looking at it and evaluating whether -- do we -- do I as a developer need to submit the 510(k). And we really didn't know. So there were lots of question, and I remember talking to some folks at the NYBC and they had some consulting helping them. So the question was what do they make a decision to pursue 510(k) or not.
And they made that decision. It wasn't only -- talking to Jim yesterday, he said it wasn't only the 510(k), it was also the 2(k). So they had to have resources to do both of them. So they have decided at that point -- among other thing, they decided to abandon the development and to acquire a vendor software in 1999.
When I moved to Carter BloodCare, my experience was little bit different, but it was similar issues. The issue with them was the donor management and the manufacturing process, little bit different from what was the need at the New York Blood Center. The driver there was exactly the same, quality compliance, old system, and the interesting problem with that system, it has an operating -- it was a Honeywell that was almost 20 years old, it had a trigger on the operating system, that trigger would shut down that system within 2 years. And the need for books and the decision on component manufacturing.
So component was a major issue, and we really wanted to look at how to automate the component piece, which is we have not done that when were at New York, that was a totally different thing we were looking at.
Same issue there except New York Blood Center had money. When I joined Carter BloodCare, at that time it was Wadley, and at that time Wadley did not have much money to develop or purchase a system, but it had a problem to deal with it, to stay alive.
So what did we do there? Well, we reviewed the landscape of vendor in 1992 and 1993. It was limited vendor that met our needs, especially in the area of component manufacturing.
So –- but we were fortunate to find someone that really helped us quite a bit in the area of donor management functionality. They really -- we got them in, we were able to partner with them, and within really 6 to 9 months, we were able to put donor management and really get rid of all the compliance problem that we had dealing with the (inaudible) management piece.
Meanwhile, what we did is to focus on building a lab, a module for production and laboratory to facilitate the books and the decision in component manufacturing and labeling. We completed that in '93 and we did the inventory management ordering and shipping in '95, and then we went back and recreated the donor application to replace our software that we have and that was in 1998.
As you see –-during that timeline lots of things was happening with the regulation and we had to make lots of decisions along the way. So again, we needed to make a decision whether to move with the 510(k) clearance.
I think Sheryl brought up something here, which she did it with -- it was an interesting. You determine it's a medical device, then you need to determine whether it is medical device class II, and whether there is anything across –- to go across, intercommerce state or data going across.
So I think the decision –- when I was thinking about -- as you were talking about this, in New York Blood Center they were doing business in both New Jersey as well as New York. So definitely there is an intercommerce playing here. When we were in -- at Carter BloodCare, the question is do we need to do 510(k).
Well, we were doing a lot of testing across or someone else -- we were doing testing for someone else. So the question is, is that a 510(k) or not. I mean, it was -- we're not selling the product, we're treating the product internally. I think those are good questions to ask today and to have a dialogue around it.
If I'm going to develop my system for myself, and I'm using it to receive data or to send data, is that really a medical device class II? I mean, those are good discussion to have today.
So you can see here, we learned a lot with the lab module. We became an expert after that. I think with the distribution, we went to abbreviated 510(k), took a 6-month, then with the donor, we got that thing is three months. It was wonderful, we celebrated for that.
But I think it was a very interesting experience, and I'll talk a little bit about it later –- but I think what happened with that at Carter BloodCare, the cost of owning the software as well as to sustain 510(k) because what we believe, and maybe I was wrong, I always believe in high quality system and regulation in my shop, we really had a separate function doing nothing and I said have it now in my -- in every organization code, I ask quality.
And we had a large group and I asked quality that do we need documentation, validation, training, overseeing, auditing, everything we do. So we have to build additional layers in top of what's there, but in this case for the 510(k) instead of having four people, we had seven people. And did I need the seven people at the time? I don't know, but I felt I needed to because I didn't know much of what the regulations are.
I mean, those are the type of discussion we need to talk about, and we really now are much more sophisticated of understanding the requirement of what do we need to do to sustain it than we did at the time.
But as you can see, because of IT, it has pushed beyond 8 percent. To give you an example, my cost, right now, of IT at the Blood Center of Wisconsin, is 6.5 percent. The averages go between 4 and 7. Mine is high right now because we are in the middle of implementing many new applications, adding lots of new functionality. But I would see in blood banking to be around 5 percent.
I think we have lots of discussion at the board level as well as the executive level, and we all decided we could not sustain the cost. So we, the Blood Center marketed, and I become a marketeer and a sales person to try to sell the software for a while. But we ended up selling the software in 1999 to a commercial vendor.
I think this is a picture of my lab submission when we submitted the lab there. And look at the picture, I aged quite a bit from 15 years ago probably, but what I'm pointing here , because we really didn't know what we were doing we submitted over 36 binders to the FDA, and I remember Dr. Jay Epstein calling Dr. Murrow (phonetic) and said, "What the heck are you guys doing?"
And I think maybe –- after looking at everything there, maybe you guys decided maybe let's get rid of all this, let's go for the abbreviated 510(k), after looking at the number of volume we submitted down to them. But it is an education because at that time that was right when the publication started coming out. So we really did not have a chance to understand what's needed. So we took everything we have in the file cabinet and we copied it and we sent it to the FDA.
In my third experience going to Blood Center of Wisconsin I figured out, got a chance to develop two system, got a chance to put 510(k), got a chance to make sure –- the organization could not support them, I better learn from my lesson. And let's talk about little bit what's going on and what happened at Blood Center of Wisconsin.
The issue remained the same with every blood center when you let your system go down. I mean, we had issues that are similar to what Carter BloodCare has similar to what New York Blood Center had. There were systems, HP 3000, they have not been upgraded for over 10 years, 12 years, so we needed to do something right away for them.
And at Blood Center, we are not only a blood -- we have our blood services arm, but we have also the diagnostic laboratory that needed all system as well. So when we started there with the -- trying to look at system, the first thing we said, we're not building, we're buying.
And we replaced our core system for the blood bank and the diagnostic lab in the first 3 years. Then we started really at that point –- we were talking little bit yesterday about how do we mature IT within an organization. And we started working very closely in developing part of the strategic plan -- organization strategic plan, develop the IT strategic plan.
Our first IT strategic plan that we developed after we did the upgrade is really, I called it the "phase of solidifying." And really what we needed to do is to take every system we have and replace every system. So we upgraded the infrastructure, we look at the process, we look at the service we provide, the quality, and the people.
We brought a brand new team and we upgraded the team –- the technical ability of the team we have. We really worked very hard; we were introduced to ITEL as a framework for providing service management. We worked very hard on that, and as we moved through 2006 to 2008, as per our strategic initiative, the thing here was to really extending, going away from what core application is and to add value.
And as we speak, I'm completing my 2009-2011, and I'm calling that phase of our strategic plan as "transforming," really how to use the technology to enable business transformation. And I think I feel very strongly that's where we need to be and the question is what are my challenge to get there.
Just a little bit –- this is what I'm working with as my strategic plan into the digital age in our healthcare sector. My boss, my CEO want a Web 2.0 right away. I needed to implement Web 2.0, social networking, PC University (phonetic) education collaboration. So we need to work on looking at the relationship with using the latest technology with the hospital customer, donor, and donor-sponsor, and really knowledge management.
I'm going into knowledge management because with the Web 2.0 it's going to give you the tool and the capability, to help create that knowledge management internally as well as externally. Technology we're looking at RFID, you heard enough about this, YMS, and I'm glad that we now –- we have some guidance around it and that's helping us moving into that area.
We -- I think maybe toward 2011, we'd be looking at voice recognition, but bandwidth is a large thing now. We're starting upgrading all the bandwidth in our network to allow us to do the technology we need. Data warehousing, data mining, electronic medical record, and being –- supporting a large resource institution we are looking into large patient and biorepository databases. And of course, we're all dealing with the security issue when you deal with all the new technology.
I thought I'll share with you a little bit what is our enterprise architecture. The way I see it for the blood center, our blood center and other blood center, and I'm going to share with you the issue we have with getting there. So this is my BECS, this is everyone's BECS, donor management, donation management, laboratory, distribution, production, recruitment, and how are we going to manage all that.
So first –- this is the basic. We have established the basic; let's look what we need to add to it right now. As I look at that, the second area we went into it, on looking at is really the recruitment software, the code-tracking software, device scheduling software, device coordinator, and the CRM software. So when I was talking about those, in that system these are key to the success of our operation.
And we need to have these software, and guess what? We need to have these software to talk to our BECS, because as I schedule an appointment, I need it to schedule –- look at the BECS and schedule the appointment, whether that person is eligible to donate, when that person is eligible to donate, how is that person and when I'm going to call him, what kind of procedure I'm going to ask him to do.
So there is quite a bit here of think just how I'm going to create the data integration between these areas. And as I look at it, we added now automated health history and phlebotomy capture. So previously, and we're still doing that because we are in final phase with this, what we do right now, we ask the question out in some piece of paper, everyone answer it, then we review it, we take the answer that we need to put it –- data entry staff enter it into your system.
Well, now we are really very sophisticated. We are asking the donor to answer all these questions online; they'll answer it, enter all the information, we print the VDR. We print it, we take that printout and we go and we give it to the data entry, and they enter it again. Where is the error? I'm creating two places for errors.
So how do I think about streamlining the process, how do I make sure that my data is correct? The quality of the data that's coming in between once it get in, why can't I move it all the way along? Another area we've looking and working on is what we call community inventory network.
We were talking about that little bit yesterday about the ability to really create transparency between us and our customer. We are looking at order management, community inventory management, not only what's in the blood center, but what is in our community, what every hospital has. Can we see it? Can we create data transparency across the whole system?
Looking at the area of demand planning, what is the demand planning? What is our production planning based on the demand planning, and can we create forecasting? A very similar thing, every manufacturer does –- is their ERP, basic ERP, can we forecast what do we need to produce for the coming 6 months? Can we forecast what we need to do for the coming week? I mean, this is the question we face all of us together.
Analytic -- and I cannot say much about it because we're talking a lot about data mode, data warehousing, try to visualize and try to search and mine data and come up with the solution. So this is the area we're building like now. If I look at everything you see here, this is -- most of this is done. We are in the process of now thinking, our next year looking at demand planning and forecasting, this year we're finalizing the inventory management and the order management piece. And we have put the data mode and data warehousing last time.
So collaboration portal for hospital and sponsor, Web 2.0, we will add those. Order replenishment –- well, every manufacturer had, with the details, have order replenishment, so we will want to do that. This is what we are going to add.
And to streamline everything, we want to add the RFID to our supply stream in order to make sure that we improve our processing and to increase the safety of the patient at the transfusion services. So well, how do I do this? I need something. I need a gateway, I need data integration. I need a way to talk -- these system to talk to each other.
And this has been really my critical, the most critical piece. And I don't know who to talk to, whether it's the vendor, whether it's the regulation, or whether it's us as an industry, not understanding what's BECS regulation is all about.
And I'm hoping in this session today and tomorrow, we get to some better understanding, what is my responsibility versus what is the vendor responsibility in integrating the data. I think, when I look at –- the challenge I have, to deliver the solution that is expected of me as a leader is really to look at interoperability and to look at the access of the new technology.
And really the question is we don't have a standard for data exchange and blood banking. I need a way to get this data across. Do I have the right to go into BECS' regulation system, and update the data. It's my data. The data belong to the Blood Center. It does not belong to the vendor.
Where does BECS' stop, the creation stop? I mean, I talked to vendor and said you cannot touch those data. It's my -- it's a closed system. Otherwise we had to go to the FDA. Where is the line there? I mean, we need to have better understanding. The same go with the access to the new technology.
Our existing BECS software are not up –- current with the new -- with the existing technology, and to invest a new technology, it is going to be very expensive for them.
So this is where I am with my conclusion after I thought about it. Following proven software development life cycle, as we all know, I think we end up –- really connect with the system that provide quality software, that include all safety critical function.
I would say the system we developed or the system we did before the BECS or after the BECS, both of them had the exact same quality product at the end deliverable with it. I really think we can do better with –- when we look at –- try to translate the medical device requirement and try to associate those through the software development.
We all have major -- it took a long time to figure it out. As a matter of fact, we had a loyal office staff to help us figure out how to translate what we were doing and the SCLC (phonetic) to what the –- really the 820 it's telling us to do.
I really think the hazard analysis methodology under the BECS regulation is more applicable to blood banking software than any others. If I like anything about the whole 820, I like that hazard analysis because it really force you to come up with true labeling of the product, so the user can understand what is controlled within the system, and what is not -- what else you need to control via your SOPs. And I think that's key for us, and we'd like to adopt it; as a matter of fact, I adopted in my methodology right now when we developed system.
BECS regulation to me, it's more guiding a less experienced development house to have quality process in place. If I am an expert developer, it –- I think it's in line of what I'm doing, it's not adding much volume to me as a developer, it's making sure I have documented the process.
I'll follow the process, I document the deliverables for SCLC, but this is –- really tell us little bit more about, you know, if you want to remember what happened, you know it.
Wrapping up, I think perspective on value from the BECS regulation is different among the stakeholder. We must balance it and reconcile it for us to do a win-win. I don't think we can transform forward the value unless we know what work and what doesn't work. I think Sheryl tried to share some metric with us this morning, but I hope you can come up with more input on that.
And I really hope that this workshop will create dialogue for us all. The idea is to be able to promote quality system, but at the same time meet our business objective here.
Thank you very much.
(Applause)
MR. DODDRIDGE: Thank you, Rodeina. I think that one slide said it all. We have our basic system and with everything we have to integrate outside, that's the whole question we're trying to answer today.
Are there any questions to Rodeina? If you –- please go to the mike, if you do. I think it's just great, our speakers are really presenting the material and everybody is understanding it today. Thank you.
Our next speaker will bring a vendor perspective, as Marsha Senter is a product manager of LifeTrak at Mediware. She has been with Mediware since 1999 but she has much longer history in her focus on multiple 510(k) submissions, for both donor and transfusion systems. She will discuss the pros and cons of the 510(k) clearance.
Marsha?
MS. SENTER: Good morning, everyone. Can you hear me okay? Okay. Now, can you hear me? Can you hear me now?
Hi, I'm Marsha Senter, and I'm very excited to be here this morning among all of these distinguished speakers. Most of you do not know me. So I'm going to give you a little bit of my background.
I'm a med tech. I was the subject –- one of the subject matter experts that Rodeina had when she developed the LifeTrak System. Since then she introduced me to the IT arena. I've been sitting there for 16 years.
Not just sitting, we've been moving along quite a bit. Moved from quality assurance to regulatory affairs and now I've gone back as someone said to the "dark side." I'm in product management.
My objectives this morning were to -- are to describe the evolution of our submission process, and identify the impacts that we had, hurdles and horizons that we had to get over and things that we see for the future. And I want to discuss the class and status that cleared BECS.
In the early days of the 510(k) –- 1994 was the decision point for several vendors who were out there, some of them just folding in and saying we are not able to more forward. And that continued on for several years.
So that did stick it out and manage had a lot of work ahead of them, and it was a long and tedious road, not just for the vendors but –- I not in the vendor arena at that time, I was at the Blood Center, Carter BloodCare, and the other -- the users have the system. So we were working with FDA.
FDA was -- we were all in a learning position. FDA was new with this, and so were we. The learning experience was quite unique. It was a hit-and-miss for both sides for a long time.
We had consultants. Most of those consultants were from previous FDAs. We had meetings with FDA, people were going to Washington, there were conference calls, everything was going on back and forth, and some of the discussions got pretty heated and some of them were not.
Sometimes we were just at a loss as what do we need to do next. Rodeina stated it very well. We just didn't know how to deal with this, it was something very new to all of us. The documents that we got from FDA at the time, they were pretty lacking. There was no cohesive guidance initially when we went in. They've improved quite a bit, but still having something that is specifically for BECS, for software, has been an issue over the years.
Our first-time experience, it was very timely. We actually submitted –- our first experience with it, with LifeTrak, was the submission of 510(k) that we inherited back from a company that decided they were not going to pursue it. So we got back, well, I think it was one binder. Rodeina said it was two binders that were the entire submission. You saw the picture of what we ended up submitting after about a year-and-a-half of discussions with FDA. Our first initial submission was 26 binders.
You have to submit them in triplicate. So Rodeina had a pretty good sized office which had paperwork spread all over the floor sorting out documentation, making sure it was correct. We labeled these binders meticulously, only to find out when they got to FDA, they dumped them out of those binders and rebound them.
We didn't know that at the time. So we spent a lot of money on binders, we spent a lot of money on doing this beautiful presentation, to find out it was set by the wayside, the review was never looked at. It was very organized. After all was set and done with many conference calls going back and forth, many, many hours on redoing things, the -- we actually felt like going in. We were doing it correct.
We felt like we had accomplished quite a bit during that time. The testing that we did, Rodeina was actually very active in developing testing protocols, working with a validation process. We felt like we had done a good job. And today, I still feel like we had done a very good job except that there was a couple of a thing at the time that FDA didn't like, so we had to redo some items.
It was fairly objectionable, but when you say you have to do it, you have to do it. We submitted it and went on. We got our first letter back saying, well, we want you to do a few other things, so by the time we submitted that, it was seven more additional binders, all bound nicely and neatly, again, all in triplicate, which we had to keep the copy of the binders back at our facility to go over and understand what they're looking at when they call us and give us a question. So again, that was a lot of time and a lot of effort for something that was tossed.
So, do it right, do it wrong, we didn't know; FDA, at the time, really didn't know. We were going back and forth again. We've reviewed everything that our system did, in and out, upside down, backwards and forwards. The information that FDA got, we felt like it was very significant.
It was the validation part of it that really kind of threw us because again, like I said, we felt like we did a very good job on it. They had some questions, so we had to add additional information for that. Perspectives, part of the initial problem was the "substantial equivalence." We were kind of at a loss for what did they mean by "substantial equivalence."
We had to claim conformance to a product that was in the market prior to, I believe, it was 1976. Going back that far, trying to find a computer system that is equivalent to what you're doing today, 20 years earlier was very difficult to do.
Basically, FDA told us at that point, we don't care if you're building a Cadillac or Volkswagen. We want you to tell us how you're building it and exactly what you're doing. Finally sunk in we got it. One day, after all of this was going on, there's a moment of silence from FDA where you really don't hear anything, and you're going okay, is it good, is it bad, what is it?
We got a phone call out of blue, saying you're cleared. If I had -- if I could backflips down the hall, that's what I would have done. But I was so excited at that time, and we felt like it was a real accomplishment and it was a two-year period.
Mediware's first –- I was not with Mediware at the time, I went to Mediware in 1999 –- but Mediware's first 510(k), their system was a transfusion system, and it was fully entrenched in multiple facilities. There was a great lack of software, availability of software for transfusions at that time.
They decided that they were going to go ahead and move forward. They looked at what needed to be done, again, quite a bit of expenses and consultants. They did several visits to FDA, conference calls. It was time-consuming; their experience was much like ours on a little bit different level, and they did receive their clearance. But it was pretty much the same game and I think it was like that for most people who were submitting during that time. And again theirs took just about 2 years.
Moving ahead, the picture showed it all. We had all those volumes of binders and that was just one set. Put it in triplicate, the cost of mailing that was unbelievable. Along came the abbreviated 510(k) which was wonderful. It let us claim adherence to a special control which was the reviewer guidance that was published in 1997.
I actually liked that document quite a bit. It gave us a template for other documents to be used, which –- the hazard analysis we still use today. And there is not a lot of templates out there that are available for use.
But this one, Rodeina actually said they still use it, it was identified a hazard, what causes it, level of concern, likelihood of occurrence, your method of control, your trace to your designed document, your requirements, and now there's another field in there of your trace to your validation. And this is a key document. This little template saved us hours and hours of agony and it was just one little line in this document. They had another template for functional requirements.
It would be very helpful to us today if we had more of these type of templates available, simply because it's -- you can put forth the document, you don't know if it's right; you can ask for input –- they can give you certain –- they can give you information, but they don't have templates or anything like that that's readily available to tell you, this is what our expectation is, to see –- but we also need templates that are not just for presentation-type documents to FDA. These need to be viable working templates that are utilized functionally within your center. This one actually is very good and it's utilized.
The 510(k) relief with the abbreviated 510(k) was wonderful. It was much less volumes. I think our first abbreviated 510(k) either had seven or nine volumes, took much less time to construct it, we only used up about half our office instead of the entire floor.
Cost savings was immense, but again we still did not know about the binder policy or they take everything out of the notebooks. It was much easier to manage, the submission was easier, there was a lot less to review. It basically contained documents that were required in a hazard analysis. We did not have to submit our validation at the time, we had to submit your alpha test –- your test plans and your testing summary which were utilized for the validation. And there are other documents that are required in there, but they are less –- you are labeling for one thing, all of your user documentation which we have quite a bit of.
So it made it a lot easier to submit. We made sure, it was very organized. If we wanted to look at it and find something –- we had to make sure that the paper trail, which is all FDA really has to go on, the paper trail is easy to follow.
So in this same review time period –- but looking at 26 or 35 binders within 90 days versus 7 binders within 90 days is a significant decrease in the amount of time and frustration that's been on it.
There were several FDA documents, one of then which is still in effect today, and I find this document very difficult for us as BECS, it's deciding when to submit a 510(k), for a change to an existing device. This document is not meant for software. It is not meant for anything like BECS. Actually, it's probably very easy to go utilize that document and say, I don't need to submit or I do need to submit, based on how you want to steer your information.
The new 510(k) paradigm also gave us more information, but exactly did not fit to BECS. None of these documents actually fitted for a BECS. The closest thing that came to it was this guidance for the content of pre-market submission for software contained in medical devices. Except it had a disclaimer in it, not it's a draft policy for standalone software was yet to be developed, the entire document, and that's what stuck out. So we were still kind of at loss on what we need to do with this document. So still, limited specificity for BECS.
Ambiguity –- we are using documents that are geared for a true production line. You've got a widget going on the line and a widget coming off and it's got some software in it. That was the best that we had.
The real value in these documents would be, we really need to know what you need to have presented to you, but it also has to be a document that's truly utilized in the blood center or in the development arena at your vendor area.
It's very difficult for newcomers, those who have never submitted before to pick up all of this and look at it and know what to do. It would be –- I would never be able to do it on my own, it's a conglomeration of things that you need to know and it would be very hard for a, like I said, a newcomer coming in, to try to know what to submit for a BECS clearance.
FDA is now doing collaborative documents with CDRH, I mean CBER is doing the collaborative documents with CDRH. And this one that came out in '05 or the guidance for the content of pre-market submissions for software, it actually moved us back to more volumes for submission, not nearly as much as the initial 510(k) process, but it's much more documentation than what the abbreviated is. We lost our special control with that, the guidance that was for 1997, the reviewer guidance that we couldn't submit under that any longer.
It clearly states in this document, here is what you need to do. BECS is outlined very strongly in that. So there is no question, and it does help guide you in the type of document you want submitted. Part of that was I ended –- as soon as I read it I called the FDA and I said, "What is this revision history document you're talking about," and a part of it is just terminology, understanding the terminology on what they're talking about and the terminology on what you're using.
We happened to use a piece of software for that revision history where we keep track of all of our past and failed test cases, that type of history and this was basically a benchmark of where you were at different phases of your validation process. So instead of us keeping it basically in our software, we now had to pull it out and map it out in a document that's going to be presented to FDA.
So part of this is a better understanding of the terminology in the documents and we need a means for proof, such as things that are kept in an automated system that we use internally for our quality system regulation process controls versus documents that have to be sent to FDA. And we understand the need to ease the burden, so it's a large burden on the vendor, on the blood bank community, as well as on FDA, going back and forth trying to decide or decipher what all of these information, how it needs to be presented, and what the information is.
The FDA has always been very willing and very cooperative with me when I was at the blood center and also with Mediware. We have a very nice working relationship and they've been very helpful. I've never hesitated to make FDA our friend on questions that we need answered and they've been very, very helpful with this.
The hurdles that we found is, I think there is a fear of submission among many companies. They just –- they don't want to have to ask FDA anything. They feel like if they have to ask FDA, FDA is going to tell them yes, you have to do it. That's not the case. I have found that, that's not necessarily the answer you're always going to get. So I do not abide by this don't-ask-don't-tell type situation.
They limit the movement for smaller companies to move into this arena because they don't know what they have to do and the larger companies too who just say, I don't want to deal with the submission process.
So what do we submit? Part of it boils down to are these presentation documents that FDA wants to see or are they real buyable documents that are usable within your facility. It's a hard line sometime to make that distinction. I've had development staff, I would give them a document and they'll look at it and go, but this is not what I'm used to, it's not giving me the instructions that I need.
So to make these documents more easier, friendlier to use, they have to be something that is not presentation format for FDA, something that is a real usable document, real world applicability.
It would be nice for these 510(k) submissions, if we had more formats and examples of what needed to be submitted. There was an open forum, and especially in places like this where we could meet with FDA, talk about the development process and talk about the things that we need for them and the things that we can supply to them that is mutually beneficial to us both.
Expectations currently are that everybody does what they're supposed to do. Most people do what they're supposed to do. There are -- we would have no 483s, no vendors would ever have a 483 if we always did exactly what we were supposed to do.
Same in the blood industry; a donor's in our transfusion service, -- no one would have a 483 if we knew exactly and follow what we were supposed to do all the time. So the expectation is that, yes, we all make mistakes, but we want to have a better process, a better control for moving forward.
The whole caution or the whole reason for going to a BECS is so we can make that process move forward and have a better transfusion or donor software, plasma center also.
Hurdles –- again the time –- the preparation time for making these submissions. You basically are printing off volumes and volumes of documents that you already have.
Electronic signature –- some people have a hybrid system where you're still using a manual signature not electronic signature to do your documentation. So just printing those documents all is not always the thing you can do, you have to do scan copies which makes it a little more timely.
The binding process –- we found out not until 2002 that the --we were not supposed to submit in all of these notebooks. That made it much less expensive for us and easier to do. They just use those cardboard binders that you buy at office depot or something, they're the heavy duty binders, and label those. And it did make a big difference and how long it took to bind it and having readily available the supplies that you needed.
It also could cause a delay in our review time, the binding alone, because when they would receive these in at FDA, before they ever got the Reviewer's Office, they were taking them out of the binders and rebinding them which left a very uncomfortable feeling in my stomach, because I know we worked very hard to get these in the exact, perfect, right order and if one of them were dropped or something, basically our submission could be held up several days just because we were trying to reorganize.
I'm going too slow. The cost of the actual submission of those volumes of documentation in triplicate, in-house volumes that we had to keep, I traveled quite a bit so I had a volume that I had to keep in Chicago and a volume that I had to keep in Dallas. So we didn't do three volumes, we had to do five volumes.
Other hurdles were reviewer resources. That office has a limited amount of resources anyway for the amount of the work that they have and then the training time for the reviewers was quite a long process. So sometimes you would get a reviewer in there who had to have a more senior person with them just to get you through your review process.
The consistency –- we would submit a 510(k) and it would be perfectly cleared and then the next time we would submit it we would miss a document out of it, but it was document that wasn't in the previous one and most of these ended up being forms that were required by FDA that we didn't know about previously. And I don't know if we just missed them or if FDA missed them when they did the review process.
The pace of movement –- it's slow by design. There's nothing we can do about that currently. We're here today to see if we can speed up the process. The documentation again is lacking as far as specificity for BECS, it is getting better. Technology is moving ahead so quickly that the review process and submission of these BECS preclude the ability to move that technology forward in the blood centers and the expectations of industries is that we're going to stay up and meet their demands and meet their needs.
Technology changes –- again, rapidly evolving, innovation, ability to keep pace and they're very difficult for us in the vendor arena. The user community is ever evolving, we need to be able to be quickly responsive to them and they have struggles in the industry, the struggles to meet the demands of their blood supply, the struggles to meet their, development of their internal processes as far as moving out and spreading their wings to develop further business.
Horizons –- we need do fear abatement as far as FDA. They're our friend, they're not our foe, now they have an interactive review process, which we always made it an interactive review process, and we kept the lines of communication open.
Our focus here today is to help them help us. Conferences like this are very important. This is the first of its kind and I'm very honored to be here and I think this will help us move forward and let them understand as a community, a community of users and vendors, what we need to do to help us keep up with the technology changes.
Collaborative documents –- there is an industry document out there, it was published I believe, in 2003 and it's the ISBT document for guidelines, for validation and maintaining the validation state of automated systems in blood banking.
I'll speed it up. It's a very important document -- he's given me the go ahead. We need to remove the confusion around BECS submission. Specific documentation, frequency, and updating of the 510(k) remain timely to technology changes. This is all hard to put into one package, but a lot of us don't know exactly when to update the 510(k) or how frequent to do it.
We need examples. We need to be appraised of the status throughout the process of our 510(k). If we could log on to a system somewhere and find out here's your status, know where we are, what type of review, what's missing, that would be very nice, and enhance the clearance notification process.
I found out that you do all of this work to get cleared and then they send you out a letter -- I believe it was third class mail? Third class mail. So that's not as responsive as I would like for them be.
(Laughter)
MS. SENTER: Technology in the submission process –- we are looking at possibly online -- if we are going to maintain this online submissions, electronic documents, it would save a lot of time, reduce cost, reduce errors on our part, binding all of those documents, ease the burden and accessibility suit submissions.
There's a paradigm shift, this is apparent -- and I'm going to breeze through these real quickly -- this is apparent of our paradigm shift and we need to enhance these processes. I'm not even going to go through that one. I'll skip that.
Why are we here? We know it's a criticality of the device, but there's other devices out there other software that's just as critical if it's not treated as a device.
Validation -- all of us have learned from the validation processes. What happens is less than expected validate in-house or less than expected validate in-house, the community blood centers do a lot of in-house validation. When you get to the hospital-based validation that's a higher volume of outsourcing. Many use third party and many depend on the vendor. Validation services are flourishing today, flourishing.
Here is a little stats, it'll be last slide. There a 116 cleared BECS, 42 percent of them were cleared before the year 2000, 36 percent of the clearances are held by four vendors today, 64 percent clearances are held by 41 vendors, 18 percent have one clearance and only 6 percent of those were cleared before the year 2000.
Thank you.
(Applause)
MR. DODDRIDGE: Thank you Marsha. I'm assuming –- Marsha's assuming there is no questions for her, so –- but she'll be around during break if you need to ask her a question.
We're going to take a 10 minute break and try to be as -- I have 20 after about, is that correct. So we'll try to be back here by 10:30.
(Recess)
(Discussion off the record)
MR. DODDRIDGE: We'd like to stay on time, so if you'd please take your seats we'll try to get started. I don't have my gavel like I have at Rotary, but I'd like go ahead and get started here. Our next speaker is Linda Weir, Linda is the FDA's expert on the regulations of BECS. She is going to describe in more detail the 510(k) process including turnaround times and the differences between software used in blood centers and transfusion centers and I think what I heard her just -- with Alan talking to her, she's got a couple of updates that she has learned during those first few presentations. So without further ado Linda would you come forward?
(Applause)
MS. WEIR: Okay, I have a question. How many in here know you might find me by voice?
(Laughter)
MS. WEIR: Okay, same here, so come up and introduce yourself during lunch or something, so I can match a face to the voice.
The mike –- can you hear me now? I'm afraid to touch it. He has so much -- can you hear me now? Okay good.
These were the topics I'm actually going to discuss, no matter what this gentleman said. And having listened to the previous two submissions, I'm going to add some to it, because I think this conference actually is going to be very valuable for both of us, because I've identified some more common misconceptions from Rodeina especially, and even from you, that hopefully I can clear up. And we need to identify a better way, I think, to get these out to you so that we don't have to you know, spend all this money to come here for us to tell you.
But I have planned on talking about the documents FDA request in the 510(k), why we request these documents, frequently encountered problems in the 510(k) process briefly, the fact that innovation and regulations are not incompatible and common misconceptions which has grown exponentially since I got here.
The documents that we request are those recommended -- okay, can you hear me now -- okay, are those recommended in the guidance that she mentioned unfavorably –-
(Laughter)
MS. WEIR: –- guidance for the content of pre-market submissions for software contained in medical devices issued on May 11, 2005. It's used for software embedded in medical devices such as instruments as well as for standalone software such as BECS and I have to be honest with you, every software that's reviewed in the agency, if it's a device embedded, if it's embedded in the device or if it is a device in itself is reviewed under this guidance.
It was developed by CDRH and CBER, I actually sat on the committee that wrote the guidance, because we believe FDA should be consistent across centers and what we asked to see in 510(k)s were similar type of submissions such as software.
And to tell you the truth, I hate to tell you, if we issue the guidance document specific for BECS which we may be doing after this conference, it would be this guidance with the omission of data recommended for minor or moderate level of concern which we will get into lately.
However I feel the level-of-concern information contained at the beginning of this guidance is valuable for you to understand why we consider BECS to be a major level-of-concern device.
The recommended documentation depends on the level of concern of the device. There are three levels minor, major, moderate, depending on risk. BECS has been determined to be a major level-of-concern device. We asked for the software description, software requirements specs, architectural diagram or design, software design specifications, traceability analysis, hazard analysis, the description of the software development environment, verification validation and testing, a revision level history which some people thought was all of their bills, every single bill they did. And what we meant was just those that we released, you know, to your customers, we didn't want the detail of the bills.
And any unresolved anomalies which are commonly known as bugs and limitations of the software. Who knows the difference between a limitation and a bug? That's a common question too. The really simple answer is limitation is built into the software, you meant it to work that way. Like you meant not include electronic crossmatch.
If it's something you didn't mean to happen but it happened that is the software defect or bug. So a limitation is something that you -- someone might think your software does, but it doesn't.
I had a conversation with a gentleman one time. He was arguing, the word "bug" or "defect" has a bad connotation that these -- his list of limitations were not bugs, and I said, "Well, let me ask you, did you design your software to do this?" And he said no.
(Laughter)
MS. WEIR: I said, "Okay, that’s a bug," and if you do submit the list of limitations or the defects, I mean, you should tell us the work around and give us some sort of timeframe of when you're going to fix it.
You don't have to -- it's not firm, but give us an idea of what your plans are. The reason we request these documents is we believe that if you're doing good software quality engineering, these are mostly going to be an exercise in photocopying and to speak to what our last speaker said, I actually prefer to get the real working documents.
When I get things that are obviously setup, you know, just for FDA it makes me question what are they doing and how -- because this is just what we really want to know, and I think we've evolved over the years in learning this at FDA and I had rather call you and help you -- help me learn to navigate through these documents and I know they're what you're really using.
The whole idea of using this guidance was to -- these should be documents, we felt, that you would have in your development and could just submit to us.
We had two -- actually three, since this was written, success stories and don't anyone in here feel bad, if you're not one of them. Recently we received two 510(K). Both were from firms who had never submitted a 510(K). One was from a firm who had not even requested pre-submittal support and it contained wireless technology.
The second one fell from the skies. We said, we'd never heard of the company, didn't know what they were doing, it came in, I said, oh, my gosh, you know, it's going to be a mess and it wasn't.
And they both received one minor additional information letter and were cleared. They told me they had followed the recommendations in the guidance and were successful.
The following slides will compare the documents requested in FDA 510(K) for BECS to those contained in the American Society for Quality Software Division Body of Knowledge, and if you're not familiar with ASQ they have various exams you can sit for to be certified in various areas and each of their areas will have topics that will be covered on the exam, and that is where they expect you to be expert on in order to pass the exam.
And I chose these rather than other standards for simplicity only and of course FDA is not specifically endorsing the ASQ recommendations.
The left column obviously is what we request in the 510(K) and the right column is ASQ. I'm not going really go through these in detail, but if you read through them, you'll see the terminology may change a little, but they are basically the same documents.
I'm looking to see if we see any differences here. (Inaudible) have more detail under verification, validation testing, test planning and design, test coverage, test plans, test implementation, test documentation, test report. They also want -- they stress defect tracking and the severity of the anomalies, which we did too.
Now, to get to some frequently encountered problems, probably the most frequent problem we get in a 510(K), and often leads to AI letters or worse, is the quality hazard analysis.
Not in the format that it comes in, but in -- in particular identifying the cause of a hazard as the hazard. An example would be identifying the hazard as mistyping the patient's blood, when the actual hazard would be the patient receives incompatible blood with the potential cause being mistyping the recipient's blood, and note that hazards can have multiple potential causes.
Also the inability to trace forward and backward between requirements, detailed design, hazard analysis and testing. We have more and more problems with that as we've used automated tools to track these things.
What we found ourselves lately doing sometimes is actually calling you, because these things are online with you, and you can just go back and forth and zip, and help us find it.
You know we get -- the biggest 510(K), the largest was a 180 volumes. The typical one now is probably between 20 and 30, and I hate to break it to you, we don't read all the 160 volumes. So what we do is we look at the hazard analysis or the requirements and pick out some high risk areas that we do want to look at it in more detail and we depend on your traceability analysis to help us navigate and see if that hazard was mitigated, did you test it, and the mitigation worked.
So that’s why it's important to us, the forward and backward. It's important for you, the vendor, those of you who are. It's because if you detect a defect in a certain stage of development, you need to be able to locate where the defect was injected and correct all other stages that might be affected by the defect and as you're all well aware, the earlier you can pickup a defect, the less costly it is in rework.
Also your requirements documentation, as you also know -- probably know, should be written from your requirements and you need to be able to trace the requirements to your testing to make sure all of your requirements have been tested.
Now the most frequent cause of -- not substantially equivalent are NSC, it's the easy thing to say too many software anomalies or bugs, but the few of you who may have gotten the letter didn't say that you've got too many bugs, bad software.
It probably said that you had -- did not submit performance data -- enough performance data, or that you had failed to consider the modifications you had made to your software and considered the impact they would have on the device, the safety and effectiveness, but this all leads to too many software anomalies or bugs and I say that because the fear that we have, NSC had a lot of software anomalies and bugs as well as problems in these other areas. So in other words you're going to get bad software.
In 9 years, since I have been there, CBER has found only three BECS submissions to be not substantially equivalent. All of them have more than 200 software anomalies or bugs, and in all cases the applicant corrected most of the anomalies, resubmitted the 510(K), and were determined to be SCENARIO (phonetic).
We tried to work with you as much as possible to prevent this happening and if I can go back to pre-submittal support, we do offer that, those of you who aren't aware, Marsha is obviously.
We find it easier to do the work upfront than afterwards, so that when we get the submission in, we've got something we can review fast and reach a determination on fast.
You can request a meeting, you can call us, we'll offer advice, we'll answer questions, we'll even pre-review sections of the documents you plan to submit, like the hazard analysis, say you're on track, you're not on track.
What we won't do is we won't do a complete prior review of the submission, which some people have tried. Innovation and regulation are not incompatible.
Recent innovations we have cleared include self-administered donor health history questionnaires, included via the Internet using audio and video.
Use of biometrics -- so far we've only seen fingerprints. We haven't seen retinal scans to identify donors, the use of digitized tablets to compare -- to capture donor signatures and staff signatures.
We've seen Transfusion Safety Management Systems, which are used for positive patient ID at the bedside.
They may be used when the specimen is collected for compatibility testing, they aid in the decision to transfuse or not and they may be used to report post-transfusion events.
This last one is something I've seen referred to in the literature as a blood vending machine. The system provides complete tracking of the blood component from the time it leaves the transfusion service to the time it is transfused.
It tracks the time out of refrigeration and warns if the blood component has been out of refrigeration too long.
Maintains a record of the ancillary refrigerators such as the OR or ER, in which the component is located. It maintains a record of the drawer the component is in. What does this mean?
A provider can order a unit of blood or a blood component. The order is sent to the transfusion service by an interface.
The transfusion service software may perform an electronic cross-match. If a compatible unit is in the refrigerator, the transfusion service software sends back to the provider the refrigerator and shelf ID or draw ID in which the compatible unit is located.
The provider scans the patient's armband and the refrigerator. If the unit is not in that refrigerator, the door won't open.
Now there is an override, say the electricity or something is down. The provider then scans the drawer. If the compatible unit is not in that drawer, the door won't open.
They then scan the unit. If it not the compatible unit in the drawer, the software issues a warning. All of this without human intervention, except for scanning.
Wireless technology which has been a rocky road for all of us here initially, I think we're smoothing it out a little bit.
We've seen that in everything from bedside transfusion management systems, mobile drives, communication between a wireless aphaeresis instrument and its associated software management system.
We've seen something called proprietary dots, which are basically two dimensional barcodes that don't look like a barcode. They're configured by the user, contain procedural information.
A nurse scans the dot on card or worksheet, for the procedure she wants to perform, in our case transfuse blood, it might be vital signs or other things.
The information is transmitted to the server which prompts the wireless handheld to ask predefined questions and/or give appropriate instructions.
Now, we get to some common misconceptions which I'll hit on, some of the things I've heard, as well as what I've got on the slide.
Probably most common one I hear is all accessories, things interfaced to BECS, require 510(K). Whether to submit a 510(K) is risk based. In other words it depends on the intended use of the accessory. For example, an interface to billing or shipping software does not require 510(K) or inventory software unless it issues used for look back.
Another one is the addition of any interface, even if the manufacturer is cleared for a similar interface, requires a 510(K). The truth is, if a manufacturer has received clearance for an interface of a similar type and protocol, for example, an instrument interface, they do not have to submit a 510(K) for a new interface to a new instrument.
Interface is also -- let me back up there -- are now reviewed as a special 510(K) with a 30 day turnaround time, which should make many people in this room happy.
Bigger means better -- that’s not always the case. We had a large software developer submit a 510(K) that had the following deficiencies, in part, because I only have half-an-hour.
The hazard analysis was not a hazard analysis, but a list of the anomalies that were corrected in this version of the software presented in the hazard analysis format.
There were no software design specifications and the submission had over 300 anomalies or bugs. On inspection of the manufacturer we found significant quality system regulation deficiencies including virtually no requirements or design specification.
This particular vendor did many applications in the -- throughout the country in the non-medical device industry.
Another misconception is that every modification or enhancement requires a 510(K). FDA requires a new 510(K) for a modification to a cleared device, if the device has a new intended use, new technology, or if the cumulative changes to the device taken as a whole could affect the safety or effectiveness of the device.
This last point is the one that causes most problems. We have same firms who have gone years between submitting a 510(K).
They had gone from version 1.0 to version, you know, 4 or something like this and had not submitted another 510(K) and it hadn't come to our attention, because they said well we didn't have any showstoppers in there.
We in particular didn't add anything that we thought would make us require 510(K), when the truth is they would have pages of modifications which we felt that taken as a whole could have affected the safety or effectiveness of the device.
I do agree with Marsha that the document I want to submit is difficult to read and three people can read it and maybe come to the same or different solutions.
So feel free to call if you're trying to make a decision on that and we'll try to be honest and give you a honest opinion about what we think you should do.
If you -- let me add some other common misconceptions after hearing the first one. We do use client-server -- most of the applications we have now are client-server.
Many of them are with thin and thick -- I mean, you know, the things that you were talking about. We do have 510(K)s that include recruitment and distribution.
We just don't review that part, because it's not -- we don't consider it clinically significant, but certainly you're going to need that in the operation of your blood center.
So we have many that do that. We have both audio and video right now. It's on the self-administered donor health history questionnaire, which can be silent, they can be touch-screen.
We have paperless donor management systems because they use those digitized tablets to capture the donor signature.
They may or may not use the fingerprint to identify the donor and essentially they have a paperless system.
Hardly anyone that I know of -- and 10 people probably would correct me -- that have self-administered donor history questionnaires, those are usually integrated into the software so that you -- some do but you don't have to sit down and actually input it manually into that -- into the software.
It's actually automatically -- once it's accepted by the employee as accurate and they question the donor with any additional questions, it automatically is stored in your database, so that saves time.
And we have a lot of web-enabled applications. That’s also a very common thing we're seeing now, is the majority of them are web-enabled.
So if you have any questions -- that’s my contact information, if you don't know it. I included a lot of links and I realized last night of course, that I had not included a link to the guidance on wireless.
If you don't have that you can contact me and I'll be glad to give it you or you can Google it, which is the way we find most things. Just say, you know, guidance to wireless technology and you'll probably find it.
So does anyone have any questions for me? Oh-oh, first question.
(Laughter)
MR. HARBER: We had to have at least one question, right, because we haven’t had one --
MS. WEIR: Yes.
SPEAKER: Could you speak into microphone?
MR. HARBER: So. Well, anybody can --
SPEAKER: And you have to identify yourself.
SPEAKER: I'll do --
(Laughter)
MS. WEIR: Oh, look what I've -- (inaudible).
MR. HARBER: Oh, just being silly. And I forgot my question.
(Laughter)
MR. HARBER: No, wouldn't it be worthwhile to convene like a working group to help define -- you talked about somebody who had done four versions and had been implementing all kinds of changes -- to convene a working group to better define that?
MS. WEIR: That’s something we could consider. I think that’s a common problem people have. I honestly don't -- I may be naïve, but I think that most vendors are really trying to do the right thing.
And I always look at things that way when they come in, you know, that it's an honest mistake, and I believe even in the companies that have done that, I don't think they were trying to slip something by. I think they just didn't have an understanding of that. So that might be something we could consider.
MR. HARBER: Yeah, and that seems to be a common theme, so may be some of those other things where people are seeing confusion, I mean, I would certainly volunteer for such a thing.
MS. WEIR: Yeah.
MR. HARBER: People are probably tired of hearing me say that. My last three companies were software companies, so now I'm on the other side.
MS. WEIR: Okay. Molly.
MS. RAY: Yeah, quick question. I want to make sure I understood your slide correctly
SPEAKER: Will you please identify yourself and use the microphone?
MS. RAY: I'm sorry. I'm Molly Ray from SoftwareCPR. On slide 24 it says that interfaces are now reviewed as a special 510(K) with a 30-day turnaround time. So if the addition of an interface changes the intended use, is -- I just want to make sure that this isn't misunderstood, so that would not be eligible for a special --
MS. WEIR: Well, that’s what -- yeah, I know, Molly used to work for FDA years ago.
(Laughter)
MS. WEIR: In those years, that was so chaotic, was it not?
MS. RAY: The painful years, right?
MS. WEIR: Yeah, that was a decision we reconsidered recently and it was also risk-based and trying to be least burdensome and we didn't see any added value to having to see your entire system from soup to nuts, when all you've done is added an interface.
So we may have gone that -- about that in a backwards way, but we decided it was not the intention of a new intend of use, because we really don't need to see all that data and you certainly don't need to submit it.
And I know that your customers frequently want additional interfaces to various instruments and things like that. And we felt it would be very helpful to the user community to get those turned around faster. So we no longer consider that a new intended use, Molly.
MS. RAY: Wonderful news, thank you.
MS. WEIR: I know, I agree.
MS. SYLVESTER: Hi, Linda, this is Ruth Sylvester with Americas Blood Centers.
MS. WEIR: Hi.
MS. SYLVESTER: You made the comment that you don't look at all the volumes, you only look at the hazard analysis and see them.
MS. WEIR: Well, I wouldn't say that. We do the labeling and we do a lot about this --
MS. SYLVESTER: Well, I understand that and if you listen to this morning's speakers, you know, one of their biggest issues and problem with the whole process is the number of volumes that you have to submit.
Perhaps -- and this would an ideal item to look at to improve and streamline the processes as for the document you really look at. And then if you -- from those you need additional documents, ask those to be sent in.
MS. WEIR: Well, to tell you the truth, we look at the hazard analysis to try to pick out some critical -- we look at the labeling and I don't -- I don't want to over simplify it. We do look at every single document. We just don't read every page. Oh dear, Jay.
(Laughter)
MS. WEIR: I have a personal emergency. I have to go.
(Laughter)
MS. WEIR: But we do look at all of those documents. I'm saying to get -- it helps us to have that trace -- to be able to go backward and forward and trace between, you know --
MS. SYLVESTER: I understand, but again --
MS. WEIR: And the thing of it is sometimes people on a hazard analysis, when we look at it, they don't have -- they have not identified -- in our opinion, most of us have a medical background -- all of the hazards that should be considered. So if you just --
SPEAKER: And if you --
MS. WEIR: -- submitted the hazard analysis and only those documents that were mitigated in the hazard that -- then you're probably getting a letter any way, because they are often -- one of things that are often missed in a hazard analysis are what we call implementation hazards that have to do with data corruption, duplicate records, so the -- you know, the hazard analysis is not always perfect.
MS. SYLVESTER: I understand. I understand, and then -- so maybe another thing that could come out of this meeting is how do we improve the hazard analysis that's being done by the industry.
MS. WEIR: Yeah, yeah, I think there's a lot of ways.
MS. SYLVESTER: So that's one thing and then how do we streamline the process.
MS. WEIR: Right.
MS. SYLVESTER: Rather than just having a meeting where we come in here for a day-and-a-half and we, you know, throw up on the slide everything that we don't like about the system, what do we identify to improve, to move forward, is really we're going to try and identify --
MS. WEIR: I think unless Jay tells me I'm crazy, I don't see why we couldn't have something like that that would be useful.
SPEAKER: Did you already cut Jay off --
MS. SYLVESTER: Now step out, Jay --
MS. WEIR: Yeah, I cut Jay off and --
MR. EPSTEIN: Linda, I'm from upper management here to help you.
MS. WEIR: I know.
(Laughter)
MR. EPSTEIN: I think -- and you can correct me if this is wrong -- but I think a way to look at this submission is that whereas we may not read every page, every page is a page we might need to read.
MS. WEIR: Exactly, that's good, yeah.
MR. EPSTEIN: And then I think what Linda is describing is that the pathway into the review is driven by the hazard analysis in the late run --
MS. WEIR: And the traceability.
MR. EPSTEIN: -- but -- and traceability matrix -- but as we do the review, we wander through the entire submission and any given page as the page we might need to look at. If the contact --
MS. WEIR: Well, some people actually look at all pages. We do have reviewers who read every single page. And if it's a difficult review -- I have read every single page trying to figure out where things are, what they're really doing here, what the problems are.
So I was probably oversimplifying and trying to explain why the traceability matrix was important to us.
MR. EPSTEIN: That's right. With that said, we have an open mind.
MS. WEIR: Yeah, yeah.
MR. EPSTEIN: I mean, if there's a way to streamline submissions, we're all for it.
MS. WEIR: Yeah, I agree.
MS. DAVIS: Rodeina Davis. Since you have an open mind -- I like that Jay.
(Laughter)
MS. DAVIS: I have some confusion little bit in your slide when we talk about enhancement or amendment of 510(K), and I think that is one of the issue that we're really dealing with --
MS. WEIR: Yeah.
MS. DAVIS: -- as a user community with our vendor. If a vendor is going to stay compatible with the technology that they are currently supporting, and I'm going to give an example that can be -- if are on a version 9i with Oracle, and Oracle no longer supporting 9i and they need to go to 10g or something else.
I'm finding that we are having difficulty with our vendor keeping up-to-date with the current technology. Even so they're not any longer supported by the vendor, who -- of the third party vendor, without -- because they have to submit a 510(K), so I do -- and there's an amendment to it.
I do understand the question if you introduce new technology there is some changes. But if you are upgrading your current technology, without other enhancement to the functionality of the system, would that be requiring an amendment to 510(K). I just want to clear up that on.
MS. WEIR: When I said new technology, I was more referring to virus, or you know, something like that. When it comes to operating systems and database management systems, you can -- the vendor can upgrade the operating system to a different version or the database management system without submitting a 510(K).
They just have to test it and validate it and keep that documentation on sides that when John (phonetic) shows up, you know, they'll have that.
Now if you're changing totally, say, from Windows to UNIX, you know, we do want to see a 510(K). Another thing that you might want to consider is that -- and I've just lost my thought. I said if you convert to UNIX -- I've totally lost my answer there so I --
MS. DAVIS: But I think you gave me the answer and I want to make sure that our vendor heard that.
MS. WEIR: Yeah, the vendors, I've found --
(Laughter)
MS. WEIR: That's a common misconception about vendors. Yeah, I have heard complaints from firms. They call me and say, oh, we're having this problem, they want to upgrade and I'll talk to the firm actually and say, you know you can do this without submitting a new 510(K). I think I'm being given the boot here. All you have to do is validate it. Now, if you switch totally, totally platforms then, you know, you do need to submit. Also, I know what I was going to say, just a second.
Also, in the 510(K) if you have -- there are multiple platforms that your software can run on like Oracle and Windows or you know, take your pick, you can submit data for one of those platforms and certify that you had tested the other platforms to an equal extent, and they were found acceptable.
So they're not limited to just one platform even in their 510(K). So then the vendors here -- okay. If you have any questions, catch me at lunch.
(Applause)
MR. DODDRIDGE: I have a feeling Linda will be getting a lot of questions at lunch. Our next speaker is Tom Walker. He runs a Regulatory Affairs and Quality Audits for the Canadian Blood Services.
Tom has worked in Canadian blood system since 1983, and he's going to describe the health -- Canada regulatory scheme for BECS and that should give us a good comparison between the two models. So Tom, if you'll come forward.
MR. WALKER: Good day. First I'd like to -- on behalf of Canadian Blood Services, thank the organizers for the invitation to contribute to this conference.
It maybe emphasizing the obvious. I'm presenting Health Canada's regulatory scheme from the standpoint of the regulated industry. I'm not the regulator. The regulator is however in the room so --
(Laughter)
MR. WALKER: I mean, if I messed up I'm sure I will hear about it. Well, what do I want to do this morning?
First of all, provide an overview of Canada's blood system, just to put things in context. Then introduce who regulates what in Canada, quickly go over the rules for computerized systems, then look at how the approaches actually work in practice.
I've got three real-life examples and I hope that our suppliers will forgive me for naming them but I don't think I've let slip anything proprietary.
A look over -- I'll talk to the advantages and disadvantages of the Canadian approach and give you the bottom line from our point of view.
Well, this is Canada and this is Canadian Blood Services. Canada stretches for several hundred miles east of Maine to just north of Seattle.
I'm from Point Pelee, which across Lake Erie from Cleveland to the North Pole, and North Pole actually has a Canadian postal code H0-H0-H0.
(Laughter)
MR. WALKER: -- which receives copious amounts of mail every December. Almost over 30 million residents live close to the U.S. border.
Major exceptions are the cities of Edmonton, Saskatoon, and St. John's, Newfoundland. CBS serves nine of the provinces and three territories.
We have 12 manufacturing sites identified thus. They make components. They also include permanent site clinics.
We have three testing labs identified by circles. We have 13 additional fixed collection sites which only collect blood and sent it back to one of the manufacturing sites.
We also have two regional transfusion services. Hema-Quebec, who is also in the room today. Somehow -- I don't know where you are, but I did see you going up in the elevator. Hema-Quebec serves the 10th province, Quebec. They have one manufacturing site and testing site and one fixed site clinic.
The third blood operator in Canada is Cangene. They're a fractionator based in Winnipeg -- old Winnipeg and they collect source plasma for production of hyperimmune globulins.
A few statistics, and as usual I was working on this presentation very close to the wire, after everybody else had gone home, and the only stats I could find at the time were for the last half of 2006, but the numbers aren't that different now.
We, CBS, serve about 855 healthcare facilities. We have about 4,500 employees and 17,000 volunteers. We have around 450,000 active donors. In a year, we produce about -- or we collect about 870,000 units of whole blood, 50,000 units of aphaeresis plasma almost all of that aphaeresis FFP, although we're trying to build up our collections of source plasma and we also collect about 33,000 aphaeresis platelets.
Hema-Quebec adds about 250,000 to 300,000 units of whole blood, 12,000 to 15,000 units of aphaeresis plasma, and 8,000 to 10,000 aphaeresis platelet units.
Let me introduce our regulator.
(Laughter)
MR. WALKER: Health Canada serves the minister of health. It addresses virtually all aspects of the health of Canadians except the delivery of healthcare and the practice of medicine which are provincial responsibilities.
The one exception to that is in terms of First Nations and in youth communities. We deal with one branch and within that branch, three directors.
So, yeah, health products and foods brands has a very broad mandate. Most of our staff meet the people from the inspectorate.
They go out and visit the sites every year. But most of our interchange is with the Biologics and Genetic Therapies Directorate in which there is a Center for Biologics Evaluation, so that could give some idea of the translation.
BGTD reviews all of our operational changes, not at devices bureau which is in another directorate, regulates the suppliers of systems used for collection and testing of blood, also computer systems that are considered devices and I'll try and sort out which systems are considered devices in a few minutes.
Now, definitions between Canada and the U.S. are quite similar. A drug is a substance used to diagnose, treat, mitigate or prevent a health problem, or to restore a correct body function.
It's also a disinfectant in Canada. That covers all blood and blood components, stem cells, and bone marrow, so that's why we are regulated.
And the definition of a device is quite similar to what we saw earlier for the U.S. The difference between a device and drug is that a device is a thing or a contrivance, not a substance.
Same sort of uses, few extras included, so blood bags, freezer machines, transmissible disease test kits, the systems used to execute those tests and some computer systems, are all devices.
Now these definitions came from the Canadian Food and Drug Act. The Food and Drug Act applies to the sale of a drug or a device or a therapeutic product and sale does not necessarily mean that money changes hands.
It means that ownership of the product changes hands, so that's equivalent to the U.S. situation. Well, we don't get tied up in concerns about crossing provincial boundaries, so this issue of interstate commerce is not --
A computerized blood system is defined as a system involved in handling data, maintaining or processing data used to determine state of suitability, maintaining data used to trace.
This is Canadian for BECS. Computerized blood systems are not medical devices. Health Canada is considering revising or removing this bullet about tracing, also making this bullet specific to cases where the data handling involve some sort of manipulation of the data, not just copying a file.
If that change goes through, it will mean that this definition applies exactly to what Health Canada regulates in other areas for other types of drug manufacturing.
They're focusing on the systems that control the manufacturing process. Now these inventory in distribution systems are still regulated.
They're regulated however through inspection. They must employ and comply with GAMP, Good Automated Manufacturing Practices.
A pre-approval submission to make changes is not required, so that makes things quite a bit more bearable. In fact, for CBS, we have not had to make submissions for the inventory system for our plasma products that we distribute or for preparing an electronic packing list for fractionation of plasma.
One interesting point is that, although this technically would apply to a system used in a transfusion service, it's not currently being enforced because Health Canada does not currently regulate transfusion services.
So the systems -- the version of PROGESA that our transfusion services use is not subject to this. Now when we want to put in a BECS, what do we have to do? Well, we have to provide what we call the seven part submission.
Part one is list the changes to the manufacturing processes and operations. This has to include a description of the software development process and the software development standards which we have to get from the software supplier.
Part two, the plans for validation has to include the overall plans for validating the software including the testing, I believe the supplier is going to do, or did.
Part three, results of the validation plans from part two. So again we need to help provide Health Canada the results of the supplier's testing.
Now, production trial -- okay -- production trail means the implementation of the new system in one location to contain the damage if the system doesn’t work the way we think it's going to. So we do a trial implementation before we roll it out across the country.
So part four of the submission is how are we going to do that. That also has to include plans for dealing with incidents including software bugs and must indicate what support will be provided by the supplier -- full information from the supplier has to be available to Health Canada.
Then we give Health Canada the results of our production trial, our plan for rolling -- finishing rollout to the rest of our sites and a detailed implementation plan.
In contrast, if the system is a medical device, the supplier must obtain certification of their quality system. CMDCAS is a Canadian Medical Devices Conformity Assessment System. So you have to comply with the ISO standards for quality systems. Then you have to submit safety and efficacy data for pre-market review. If you're successful, you will get your device license. You have to bring the registrar in annually for an update and every 3 years you have to go through recertification.
You're still subject to inspections by the -- to visits by the inspectorate. The ISO certificate costs about $10,000 Canadian for the initial certification, 3,000 a year for the next 2 years and about 7,000 for recertification.
Now this approach is similar to that applied in Europe and I believe with Australia. If you plan the inspection and the registration correctly, you can get certifications for several jurisdictions simultaneously.
It's not the same price, it's slightly higher, but it's cheaper than doing it the same way or doing it completely for each jurisdiction. As far as I know however, the ISO certification does not buy you anything with the FDA.
Now, first example, MAK-PROGESA. This is the system we use to control the manufacturing process and maintain our records. It was classed as a computerized blood system. Our first submission to Health Canada on this was in January 2002 and we got our acceptable license amendment letter in October of 2005.
Now, most of that 55-month elapsed time was related to the rollout of the 14 sites -- 14 at the time, and resolution of some issues around our contingency plan for what we were going to do if the system crashed.
There we are. Now, BGTD, we understand requested considerable information from MAK and essentially it was the information that Linda Weir just listed with the 510(K) submission and it went to Paris for an onsite data review. BGTD focused the review on the changes that had taken place in the MAK system since they received their 510(K) from the FDA. So the 510(K) actually gave MAK some advance standing.
Also our review was expedited somewhat by the fact that Hema-Quebec had had their MAK implementation approved ahead of us.
Then we decided to upgrade our laboratory information system and we chose HSS Surround (phonetic). We use it to consolidate all our testing results and upload it -- upload them into PROGESA.
We don’t maintain any records beyond 30 days. This system was classed as a medical device because it looks at multiple test results and determines the final interpretation and a medical lab or a hospital could afford to buy the system and use it for similar purposes.
Now, we submitted that in October 2005, got our permission to proceed with implementation in December 2006.
We're still finishing the submission on that. We owe Health Canada information on disaster recovery process.
Now, we had to provide a description of the software and development standards from the supplier to both Medical Devices Bureau and to BGTD.
Part of this was because the system was not -- is not a licensed device. We are importing it under what are known as special access provisions.
There are no licensed systems like Surround in Canada, although many medical labs have installed OIS. May be they are not using them to interpret data, I don’t know. If it had been classified as a BECS, we would only have had to deal with BGTD.
Final example is HSS (inaudible) system. We are proposing to use this to implement electronic health screening. It's been classified as computerized blood system. And I have the question mark there because I still don’t fully understand why, but I'm not asking the question because I got the answer I wanted.
(Laughter)
MR. WALKER: We don’t have any idea of the time to review. I believe the -- it wasn’t called a device because the system only consolidates information.
It doesn’t interpret -- does any interpretation -- the interpretation is made by the screener. But it doesn’t align with the definition of a computerized blood system either, because it makes no decisions and it doesn’t store data, so.
The requirement information that Health Canada require -- regardless of what we classify it as is -- it lines up with the outline of the seven-part submission anyway, so we're just proceeding with this and trying to get through as quickly as possible.
So, what are the disadvantages of this approach? One, we're the intermediary between the supplier and Health Canada. So we have more workload, more responsibility. We have to enforce quality system requirements and we don’t have any guarantee that the supplier is going to tell us about problems that an ordinary customer has detected.
We have more to submit. The division between BECS and other software is very confusing, difficult to understand, and the requirements are inconsistent between BGT and medical devices.
On the other hand, we don’t have any problem of finding suppliers. We can go shopping for any BECS available anywhere in the world. And certainly we've got evidence that the medical device licensing is impeding the availability of lab information systems based on our experience with Surround.
We only have to deal with one regulatory body and that happens to be the one that's most familiar with what we do. Bottom line is we think the advantages -- the disadvantages and not only should BECS continue not to be regulated as medical devices but computer systems should not be regulated as a device unless they are sold to healthcare providers. In other words, they are actually used directly in diagnosis, treatment, medication, et cetera.
So, once again I'll thank the organizers and thank you for your attention. Mr. Chairman, I return the floor to you hopefully in good condition, and if there's time for questions, I'd be happy to try to answer them.
(Applause)
MR. DODDRIDGE: Okay, can you hear me in the back?
SPEAKER: No, turn it up.
MR. DODDRIDGE: No? Okay can you hear me in the back?
SPEAKER: Now.
MR. DODDRIDGE: Okay, if there's no questions for Tom -- I'm sure he will be available throughout the day if you do have questions.
This time I'd like to bring forth a good friend of mine. I've known him for many years and I can tell you one thing. If you are in Scotland, do not let him take you out for a scotch tasting.
(Laughter)
MR. DODDRIDGE: You will regret it the next morning.
Angus Macmillan is from Scotland. He's the former head of the Scottish Blood Transfusion Service, and is now a consultant and it says on here a small farmer. I'll call him a gentleman farmer. He is not small. And he's going to provide us with an another model for comparison sakes, the European regulation of BECS.
Angus.
MR. DOUGLAS: Thank you.
Don, thanks very much. While this is being set up, I might just tell you it's always a great pleasure to come to this country.
I arrived at your board of controls last evening off a British Airways flight and a pretty chatty and delightful gentleman said "I see your name is Angus" and I said "Yes" and he said "Like Aberdeen Angus cows."
(Laughter)
MR. DOUGLAS: I said, "You've got the name right."
(Laughter)
MR. DOUGLAS: And he said what are you going to do here, and I said, I'm going to a Health Conference, and he said, "Well, I suppose you're going to be speaking on mad cow disease."
(Laughter)
MR. DOUGLAS: So you have very pretty intelligent border guards, I think.
(Laughter)
MR. DOUGLAS: Right, this -- the purpose of this slide really is to emphasize two points. Firstly, that -- I am by no means an IT expert, what you will be getting here is a management perspective, a management overview, if you like.
And secondly, the information contained in this presentation comes from some work that Martin Gorham and I did with ABO members, the Alliance of Blood Operator members, around Europe and North America over the last 2 years to get the impressions from blood services, from one regulator, and from pharmaceutical companies on the best way to regulate IT.
I'm actually only going to touch on Europe, a certain amount, a little bit at the end. This is actually a Transatlantic set of information.
The objective of the -- objectives of the session, to really, I hope justify a considered judgment amongst the blood transfusion services that we've talked to. The lack of choice of IT systems, which presently exists in much of the developed world, creates a major strategic risk.
And that is not to criticize the providers of systems that do exist, but it is to say that that is a limited choice.
Secondly, to try and justify that blood transfusion services in Europe and the United States are doing what they can to reduce that risk.
Thirdly, to try and justify that the risk cannot be adequately managed without some help from the FDA, and fourthly to describe the position in Europe, which is by no means perfect. I'm not going to suggest that but the regulatory position is slightly different.
So what IT systems are we talking about? What are the risks? Why can't blood transfusion services and IT providers manage these on their own?
Well, blood transfusion services as everyone in this room knows, but not everybody knows, are dependent upon the IT systems for maintaining quality, safety and management decision making and control.
We are all dependant on IT systems. I will give examples of this, but in summary, I would just make the point that once a blood service moves to a fully integrated IT system, there is no safe way of going back even for a day.
The IT system must work 24 hours a day, 365 days of the year. Therefore, if there is a failure of the IT system or a lack of capacity of that system or linked systems there is a real strategic risk to the provision of safe and adequate blood supply to the area that the blood service covers.
And this is why the Alliance of Blood Operators has classified this particular risk as one of its globally strategic issues. And it only has, I think, around 4 or 5.
And that surely is why this meeting today is so important. It's basically saying that the status quo across the developed world isn’t safe or isn’t sufficiently safe.
So what do IT systems actually cover and Rodeina Davis did a much better job than I'm going to all of this. She -- but I will still go through these things again, because it really does demonstrate just how much we are dependant upon IT systems.
(Tape interruption) -- relationship manage issue at the front end of our services, the donor relations. The strong support logistics from the donor sites back to the processing and testing sites and then from the processing and testing sites out to the hospitals.
There is what I've called the core systems, the blood testing and processing systems. The process control linked to SOPs which are at the heart of all of our organizations and which the BECS systems really address.
The stock management, which may or may not include hospital stocks -- in Scotland where I've managed the blood service for a few years, we moved to include most of the hospital stocks.
In other services it doesn’t necessarily do so. But the link to hospital systems is absolutely critical, because without that you can't ensure traceability, and nor can you reconcile the amount of blood you've given the hospital with the patient records. You actually don’t know how much blood is being used, except on a subtraction of the amount of blood given and subtracting the amount of blood given back, which isn’t perfect.
Demand forecasting -- a area that many services are now getting more and more involved in, because you can actually, in many of our services, forecast demand.
You may not be able to forecast it perfectly but you can certainly forecast it within confidence limits. And then there are all the support services IT systems which are so important to the management, and interlinked anyway with the operational ones, the HR ones, the payroll -- the payroll and finance and costing systems. And the individual pieces of equipment, the medical devices which have their own IT systems as part of them as -- if you like, closed systems.
If these are in place, if all these things are in place, and are linked, they facilitate management's ability to manage safety and effective operations. Any break in at least the top or five of those bullet points creates a safety problem, I would suggest. And therefore the message from this slide, I suppose, is that IT is fundamental to safety in the modern blood transfusion service.
So what are the risks, what actually is the problem? Well, first let's look at the background. T he global blood transfusion service market is relatively small and is highly fragmented. In many of the services, there aren’t very strong IT teams. Clearly, there have been some exceptions to that that demonstrated today. But many services except in Europe don’t have very strong IT teams. And the IT providers themselves, as you've seen, the providers of the core systems are relatively small. Therefore there are certain risks which certainly were perceived by drug services and others when we went around and talked with them.
In-house systems are becoming increasingly fragile; it's more and more difficult to actually keep up -- keep your in-house system up with latest technology, et cetera. Limited choice of commercial off- the-shelf systems, so-called COTS, I've already mentioned. The capacity of the COTS providers -- this is a risk; the customer support, their ability to retain their staff, their ability to keep up with new technologies, their ability to link to other IT systems, and their potential financial and organizational strength; in other words, the sustainability of the whole company.
Now, many of these services do a first class job, and I’m certainly not here to criticize them. I know what the blood transfusion services that we talked to. But these risks just are the risks of relatively small companies trying to be at the cutting edge of their particular business. Also if you’re going to run any organization effectively, the overall management information system; in other words, all these systems we saw before linked together is what really provides you with the best service.
And that is what the pharmaceutical companies we talked to said was the big advantage of going to generic providers. Yes, there was a high cost of getting there, but they, if you like, contracted out the risk and they got linked systems.
So if we look at these strategic risks from a slightly different perspective, from a very head-on perspective of the blood service, there is the risk of a service going -- of a provider going out of business, through financial failure or some other reason, the failure of the in-house system to be able to keep up with best technology, or to continue to maintain the right level of staff.
There is always the risk of a small provider being unresponsive, especially in the event of operational systems failure, which is absolutely critical if the service -- if your service is going to continue to provide the blood that it should do in a safer way, as it should do.
And it is difficult to link the COTS provider system to other management systems. Now, this doesn’t -- wouldn’t matter in many markets. We, every day, make judgments about whether we're going to go for very large companies to provide us with services or smaller perhaps more easy to deal with companies. We make these judgments every day, both traditionally -- both professionally and personally. But normally, you would have considerable choice in the market, and if you have choice in the market, you can exercise what sort of provider you’re going to.
What I hope that I have demonstrated is that there are a number of blood services, certainly in Europe, and I know also some in the U.S., who are concerned about the lack of choice of commercial off-the-shelf providers. And they consider this does create a strategic risk to their business, and therefore of course to their customers.
Now, I was certainly impressed going around the blood services; how much they are trying to do to manage this risk yourselves. Many services are adopting a modular approach to system selection. You have a personal system, you have a donor system, and you link these together.
Now, obviously, that reduces the systematic risk of failure, but it does have the disadvantage that you don’t have necessarily a comprehensive management information system. Many services are limiting the customization of their computer services as much as possible to reduce the complexity of support and the time required to problem solve by a vendor. And this obviously also is an extremely important way of reducing the risk because you don’t have a different system effectively in every center, but some customization is almost inevitable.
Services are trying to ensure that they have what we call certainly in the U.K., super users; people who are not IT experts, but understand the system so well that they can keep it up and running if there is a small failure, or they can do basic work-arounds in case the response from that provider is not as quick as they would like. A number of services are negotiating source code escrow agreements with the COTS vendors. So if the vendor goes out of business altogether, they can actually get to the basic ingredients of the "black box," if I can put it like that. And so potentially, they can keep the system going. But I don’t know if one of those things has ever worked in practice, and there really is potentially a risk if a provider goes out of business altogether.
And many services are working closely with their providers to identify and reduce risks wherever it is possible to do so, and try and put support systems in place wherever it is possible to do so. So we certainly found the blood transfusion services are acting themselves to try and reduce the IT risk to their businesses, and to the product safety. But none of these measures deals with the risk of having limited choice in the market.
Now, as the alliance of blood operators, we have discussed about how you might increase choice in the market, one or two blood services could try and achieve greater choice by encouraging a generic software provider to enter the market. But we've got to face here the market realities. Blood transfusion service market for IT systems is relatively small, it is highly fragmented. The United States makes up about 30 percent of the developed world market; Europe makes up about 50 to 60 percent.
So it's very difficult if one large component of this market is not, for one reason or another, welcomed by the generic providers to increase the number of providers who might enter the market. And this does bring back the focus on to whether -- regulation could be based more on whether systems work than in practice and in operations than before -- than go through a whole licensing system before they are marketed.
But of course, this is very difficult because there are different legal systems and different traditions. Pharmaceutical companies -- and I talked to two -- normally do use the generic systems. They recognize there is considerable investment upfront, but they do effectively transfer the risk to the IT provider.
And I suppose in a sense that would also transfer some risk from the regulator to the IT provider. But it does take an upfront investment, and it does mean that once you’ve got the system in place, you’ve got to follow it, and not have lots of local customized sort of subsets of it. Also, if this was going to happen in the blood transfusion service business, it would require a coordinated approach within obviously competition rules to attract and maintain long-term commitment of the generic provider.
So some suggestions for discussion; blood transfusion services themselves can reduce the risk of a lack of choice in information system providers in a number of ways. We can move away from a cottage industry approach, we can move away from wanting to tailor individual systems at different sites and even between certain different services. And we can try and have a management discipline that makes it easier to manage the system from a center, and therefore to repair things that go wrong.
It is possible that blood services are unwittingly contributing to creating a small and high-cost market for vendors to penetrate; also incidentally, a market with high reputational risk. So it is important the market is made attractive to vendors because if they do fail, not only is the financial risk high, but the reputational risk is extremely high as well. But there are some causes that certainly we found the blood services cannot overcome on their own. The size of the market outside the U.S. is probably -- at least in the developed world, is not sufficient to attract the generic vendors, and that very much throws into the spotlight, the importance of the regulatory regime within the U.S.
If we can’t resolve this issue, then we're left with these perceived risks. Now, let me go on a little bit to Europe and where Europe differs slightly from the U.S. Firstly, each European country has its own regulators -- got a big difference in itself. But the general differences from the -- between Europe and the U.S. are the next three bullets.
In all European countries, it is the responsibility of the commercial off-the-shelf provider and the blood transfusion service to design and implement an adequate IT system. And that includes local tailoring; any local tailoring that might take place in order to maintain safety and protect the patient.
That has implications of course, because it means the legal liability stops with those two parties. And of course, the fact that many blood services in Europe are owned by national governments may make that easier to manage than if they weren’t. The regulator is not normally involved before the IT system is designed, marketed, and implemented within the BTS. This clearly may be different for closed systems within a particular device, but the logic on why the regulator isn’t involved is because the -- certainly, the U.K. and German regulators work on the basis there will be some local tailoring and they would rather inspect it when the system was in place, rather than in its generic form.
Then of course, the regulator inspects the blood services IT systems as part of its general operations to ensure that the blood services outcomes meet requirements. Now, I think the service that I am slightly surprised has this open approach as this, in a way is the German one, which I know reasonably well because in Germany, blood products -- product components are licensed.
And the normal approach -- which they are not in most other European countries -- and therefore the approach in Germany for a device is normally that you have to get the regulator's approval before the device is implemented, and then the state, the "lander" within the country inspects its actual operations to make sure it works as expected or as described. Now, the reason that BECS systems are not included in that process is because there is an assumption there would be some tailoring of the software after or during implementation. So I don’t know if that logic is -- transfers in any way, but that is the situation as I understand it in Germany. Ladies and gentlemen, thank you very much.
(Applause)
MR. DODDRIDGE: Do we have any questions for Angus before the break? Okay, thank you. Just a couple of housekeeping -- the proceedings are being recorded and there will be transcripts made available by FDA after the conference. And also, I remind you to pick up your breakout slips that -- which session you’re going to this afternoon, I think they are in the back of the foyer, and lunch will be in the Chesapeake Ballroom, and I believe that’s to the left, and Marie (phonetic) and a couple of others will be back there to help you on your way. And we will try to reconvene at 12:50. So keep that in mind, 12:50 is the time to reconvene. Thank you.
(Whereupon, at 11:57 a.m., a luncheon
recess was taken.)
A F T E R N O O N S E S S I O N
(12:51 p.m.)
MR. DODDRIDGE: Okay, I would like to go ahead and get started. I'd like to introduce our next BECS speaker is Joan Loreng, who performs inspections for the FDA focusing on biological IVDs, pharmaceuticals, vaccines, blood banks, and most relevantly, blood banking software. And I can attest for that she's done our inspection a couple of times on our software. Joan is going to give us some insight into FDA's field experience, including BECS manufacturers and blood establishment. Please welcome Joan.
(Applause)
MR. DODDRIDGE: And while Joan is coming out, I do want to make one announcement. P eople have asked if they could submit written questions. If you all submit those to Bob, we will find time.
Bob, hold up your hand again, and get those questions to Bob, he wants to make sure he can read them. And we'll find some time before the end of this session to see if we can have those questions answered.
MS. LORENG: Thank you, good afternoon. So the objective of this talk is to provide a basis for the understanding of the inspectional process for blood establishments and for software, blood software vendors. And I’m sure some of you have run in -- run across me, or I've run across you in my experience.
SPEAKER: We can’t hear you.
MS. LORENG: Okay, I'll try again. I'm going to -- it's not on?
SPEAKER: Well, checking.
SPEAKER: It’s a little red line on it.
SPEAKER: Well, it's just gone off. Let's do this.
MS. LORENG: And can you hear me now?
SPEAKERS: Yes.
MS. LORENG: Okay. Okay, the objective of this presentation is to provide a basis for the understanding of the inspectional process for the blood establishments' software vendors and for blood establishments themselves, and to discuss the regulations applicable to each of those.
So what I'm going to talk about is inspections and the inspectional process and our authority to do the inspections. I'm going to touch on validation a bit, and the difference of the degree of validation is actually possible at a user facility, which is different.
And some comparisons I was asked to talk about was -- I wasn't personally asked to talk about, but nobody else came up to the plate --
(Laughter)
MS. LORENG: -- was drug inspections and drug manufacturing software versus blood establishment software, and my feeling is they are very different. And I will talk -- so I'll talk a little bit about that.
So inspectional blood establishment software manufacturers, we inspect for compliance with the quality system regulation that's 21 CFR Part 820 that would -- and also with the medical device reporting regulation, and with the correction and removal regulation. And the QSR are basically the GMPs for manufacture of a medical device. And the MDRs require that any incidence of serious -- death or serious injury be reported to FDA whether or not it's a malfunction, and then if it is a malfunction, even if it didn't cause a serious injury or death because it has the potential to, that needs to be reported also as an MDR.
Then corrections and removals are really just another way of saying recalls. There -- in the past, there have been what we used to call in FDA, "the silent recalls." Or somebody would send out a field correction or something like that, and not notify the agency that they had in fact recalled this product; "We've done a field upgrade," or something like that.
So the quality system regulation, according to our compliance program that we use to inspect medical devices, they're divided into 4 major subsystems; management controls, design controls, and production and process controls; and corrective and preventive actions.
Now management controls, it's more or less -- this requirement here that I didn't list, it's that the management should have a quality policy. So it's giving the overall -- well I'll use the word "philosophy," but I have to tell you, we had one training --- web training that I was asked to review, and it actually said that when we go into a firm, we should determine the firm's philosophy.
And I said, "Well, wait a minute; we don't inspect philosophy, we don't regulate philosophy, I wish I could, but okay." So you know, but it didn't -- I can think it kind of meant the policy, like do you have a good quality policy, and will you take responsibility for it and stay informed of what's going on.
So they need to assign responsibilities for different activities, provide adequate resources -- and that's a very big issue -- the resources, maintain oversight, and that's usually by these meetings, and they have them periodically, usually big manufacturers -- I mean, at least quarterly -- where they look at the complaints, the time to resolve a complaint, any issues, are they -- are the projects on time and things like that. And so they need -- and we need to review the suitability and effectiveness of the quality system.
Design controls: In my mind, the design controls in the QSR are closely aligned with software development lifecycle principles. You know, you have a requirement, the requirement becomes a specification, it's an iterative process, you do a risk analysis, you have control over changes, and not only -- and have SOPs for all of the activities throughout the lifecycle of a software.
Okay, I've left out verification and validation -- I said that -- and of course documentation. We always need to see documentation of any activities performed. Now, production process controls: People might argue with me about this like, where does it end for software because except for the media, you really don't have a something, you don't have an object.
So what I tend to think of it is, is that configuration management where you're putting together those different bills and rolling them up into a release. I think of that. Of course, the QSR, you might think of that as design transfer. So and that's under the design control part. But I like to think of this because when there are changes made, you have to go back and make sure that the most up-to-date version that is to be put in a certain release is rolled up and compiled.
So version control, release notes, creation of those in the user manual, but specifically the software duplication, distribution, and installation. Now in device regs, installation can be done by a third party or something like that, but a lot of vendors actually install electronically, the latest software into the testing and validation environment.
And in the release notes, we would expect to see any -- I've seen, I've been to blood establishments, and I've seen good and not so good release notes from the vendor. I mean, you'd really like to see is it a mandatory upgrade, is it a cumulative upgrade, so they know if it's not cumulative they need to install all those previous versions.
Be upfront about the bugs that have been fixed and put them in the language that the person can understand. You know, yeah, it's nice to promote your new features, but you know, if you could say these bugs have been fixed, you know, it's really -- it really helps the user and they can, you know, to have more control and more confidence in what they're buying.
And corrective and preventive actions; again in blood establishments -- oh, I'm talking about devices, I shouldn't talk about that. Blood establishments now are using this word "CAPA," even though it's a device reg. Okay, and back to the device.
The QSR says you have to identify the defects in the product and they should be externally identified from like the help desk or the user complaints; things like that, but also be internally identified. And sometimes, there's two systems I don't see integrated. I see the -- and I don’t mean just electronically.
Electronically, there are systems built for each of these functions to track bugs on the software side, and then to track complaints where the SMEs help the people through the problems.
But at some point they should be integrated, so that if a complaint comes in, you can relate that complaint number to this bug, so that you have traceability and see that, you know, all the complaints are being addressed by a certain bug and then the bug fixed. And they should hopefully identify at what phase that bug was identified; was it during testing, during the investigation of another defect, or during development of a software update.
A manufacturer of software needs to identify the defects in the process. This is another thing that we see lacking a lot of times, they'll fix the specific requirement or the specific specification -- they'll fix the specifics and they don’t look globally like, could you improve that requirement definition phase, or you put it, so the requirement is more understandable, so when the person links it up to the spec to implement that requirement, it's clearly understood.
So there's a problem then with the communicating requirements, the subject matter expert communicating that to the programmer. And we do see problems here that the programmer assumes something, you know, and then the SME assumes something and they don't, you know, they're at cross-purposes, and -- well, I said is translating the requirements into specifications, adhere to programming standards, did the programmer not adhere to your defined programming standards.
They need to make the peer review more rigorous, develop better test cases, so that you will catch those types of errors in the future, and is the testing rigorous enough. So this is like, look at the process, not just the discrete issue in CAPA. And you should have a deeper tracking system so that the problems are -- that are identified, that they're captured in some systems, so you know, you get it done -- but a lot of people we see, they want to decide what it is before they capture it, and sometimes it gets lost because it's not captured as soon as something happens. So you know, capture the event and then decide what it is.
Okay, talked about this. Oh, so the corrective of action could be correcting the code, it could be developing work around -- it could be just notifying the users that they're aware of the issue. It could be to correct the requirements and specification documents or correct the test plan.
Examples of preventive action on addressing the underlying cause of the deficiency is better definition requirements, better communication between the programmers and subject matter experts, keep them in the loop throughout whether, you know, as the project is going on that they're in communication, an understanding if things change, or the SME wants something done, but it's very difficult, you know, compromise that maybe they can't have that nice feature they want to have; they have to compromise.
Enforce programming standards and develop a knowledge base. A lot of places I've been to have what they called a knowledge base, where their program is like, if they see people are tending to forget things they should be doing, the standard operating factors, but they are not doing it, they haven't -- they put it up in a knowledge base, you know, that they can go to see if there's a similar problem there they're coming across now.
Okay, medical device reporting which we inspect for adherence to the reporting requirements, which I said, a death or serious injury caused by your device or a malfunction that may cause a death or serious injury.
Problems we've seen with the programmers and the software developers are on understanding the requirements. This misunderstanding, we've seen it in -- mostly, I've seen it when changes are made. I've seen it like when somebody makes a change to defaults, and the ones that always get them are the two-time hit for CORE (phonetic), and the two-time hit for HTLV. The programmer doesn't -- sometimes doesn't understand that that's different from all the other defaults. So they're making a change here and then not realizing that, oh, this was actually in one place called another variable in another table, and they totally didn't see it anymore because they weren't looking for that variable.
And explain the limitations to the users, so they understand that, you know, I think it's where the -- Sheryl and Linda both said that the user sometimes thinks the software can do everything, you know, and it's like things have to be done in a certain order; you get out of that order, you got to make sure this that, you know, the software goes back and reiterates, you know, that that step that you interjected there or overlooked.
Now especially, you do something like change a default; if you have to go in and change that or all the other processes, or change a test result is they're going to go back and look, and upgrade the default.
So okay, inspection of blood establishments; all the blood banks are saying they know this really well. Compliance with 606s, 640s and the 211s, the quality assurance issues and the 211s and the software -- software at a user establishment is regulated under 21168, for intermediate equipment. Those regs are old; we're trying to update them, but we're not there yet. We keep getting comments and getting turned back.
But I mean we do -- we do try to address your issues with the regs. But we got lawyers and they don't --
(Laughter)
MS. LORENG: I mean, why are we asking you do this, like we even had one about like why do you want you to write a report, it's like how the heck do we know what you did, and how do you know what you did if you don't like summarizing a report.
But, that's the kind of things we get, and then we -- you know, then it goes out, then we get comments from other people that have things they don’t like done. Okay, and then for biologics and blood stems, we have to -- it's quite analogous to MDRs -- but the BPDRs, the Biological Product Deviation Reporting.
So for blood establishments, we go by compliance program, 7342001 or 002 for source plasma establishments. And right now, to conserve resources, we -- I don’t think we are using these words because people think "Oh, gosh, if you don’t abbreviate it, you are not doing as good a job. But I mean, it's basically what we used to call a comprehensive inspection or an abbreviated inspection. We are doing -- but we got in there, so people wouldn't overlook the biggest thing, the worst thing could happen if blood establishments should release an unsuitable unit, and you're all aware of that.
So during all inspections, we put in there that the investigator has to check that to trace reactive test results to the unit, to the default, and just make sure taking a sampling of reactive units that shouldn't go out, that they do not get out the door, because initially when the program was devised with this comprehensive abbreviated testing was considered a system, and so nobody can just take testing out, I mean.
So we had to make sure that, you know -- I mean, to me that's -- well, that's the biggest part of our job, you know, to ensure public health and that reactive units aren't released.
So -- oh, and then another thing that's a misconception too; inspections. Well, we've had investigators and when we got criticized by GAO many years ago, GAO -- Government Accountability Office and the -- whatever the other heavy ones, yeah, criticized by some other people too.
(Laughter)
MS. LORENG: Now, we weren't looking at the computer systems, and I said, don't ever put that in the report you don't look at the computers -- you're looking at electronic records all the time. You're looking at inputs and outputs. So don’t say you don't look at the computer system. I mean, maybe you didn't look at the validation of it or something like that, but you're always looking at data entry transmission and reports coming out of that computer.
So okay, but if you are specifically looking at computer systems, we want to look at the documentation of the system components that you have defined your system, and know what it is. But you have to define certainly before you validate that. It is really obvious, but you'd be surprised that people think they can jump into validation without defining what they're validating. Have to do equipment qualification; document their user-defined tables, those things like what kind of default codes are you using, what kinds of dating, for what kind of products and those codes.
User acceptance testing and validation, change control; that you have change controls and you know when you put a version into use in the production environment, patches and take those user-defined tables if you've changed them, so it's traceable when that happened. You need to document those errors.
Again, in the past it used to be something -- a computer error was like sacrosanct, and nobody documented it like you're documenting every other mistake people are making. But if the computer did something funky, you didn't you didn't document it. So we want to do that.
Security; especially, you know, in this type of -- in the blood industry, the security is very important. You know, the access privileges, who can go in there and enter data, the personal registers, how much can they see and is their security access commensurate with their job description and what they're expected to do. And of course, we'd expect that for the person that could go in and change your test result or change a default that they will have higher security privileges. And there should be a process for that, not loosey-goosey, like you have a SOP for how you're going to assign security access and things like that.
Okay. Problems we've seen at the -- the user is also understanding the limitations because what's obvious to a blood banker isn't always obvious to a programmer, and vice-versa, and with an IT person. And performing operations out of the usual sequence; it's hopefully, your system can recover and go back and do the operations that have to be done to make all the related things happen.
But we see that as a problem. And I don’t put in here, but I should have put -- another problem we've seen is for the big establishments and you know who you are.
(Laughter)
MS. LORENG: Sometimes, the systems have been done for the features and not the performance capability, and can it really meet your needs for the number of concurrent users, the response time, processing time and things like that. So that's an important, really important consideration, can it meet your workload.
Okay, validation. Because I've heard said that, you know, the users can validate it, and why do we need a vendor -- why do we need to regulate the vendor to make sure they're doing a proper validation. Well, the manufacturer knows the design, they know the source code. They can put forward a detailed risk analysis because they know the risk mitigation strategies they used.
They can do white box testing. They know if the programming standards and design rules were followed, and they can challenge the design, the file structure, the relationships, and the application software. The blood establishment doesn't know the design, they don't know the code, and even if they had that thing, will they go out of business and with the --
SPEAKER: S curve?
MS. LORENG: S curve, thank you. You know, they -- that's future if they're -- well, I have seen that code transferred to people and people have taken it up and, you know, worked with it. But they don't know the designer code. They can only perform a really -- in reality, a high-level risk assessment. They can identify the critical functionality on what they've done to mitigate, but they don’t know what's going on behind the scenes in that code.
They can do black box testing. They can -- after they've identified these critical activities, they can test that the user defined tables they have created work properly, and things like that. They can evaluate whether programming standards or design rules were followed; maybe they do inspect that vendor, but maybe they're not allowed into that vendor, I don’t know.
But even if they were, it's just like us. We don’t see everything when we go in. You know, we're like taking a snap shot, and so -- and they can't challenge the designs, since they don't know how it was designed. And that's proprietary, and I don't think they're going to be told that.
Okay, so the validation of blood establishment; they can execute the manufacturer-recommended test scripts, and I don’t see anything wrong with that. I think most of those vendors know the -- like I said, they know what's -- how it's designed. So they know how best to challenge it with the user-defined tables, you know, for that user. They give recommendations of how to define those tables. Then they execute their own test cases, they qualify their equipment, they verify that the networking is working, and they verify the performance of their maximum workload.
And I just want to point out that there is a draft guidance on validation that went out that the blood bankers, I'm sure, have seen, because it is for the user establishment. It was issued in October, we got comments; we looked at them, we didn't get any really bad comment, and so any clarifications are going to be addressed. So they had to go back to the lawyer, so we'll see when that comes out again.
So -- oh, and then, I was -- like I said, I was asked to talk, by default, about drug establishments. And I have inspected drug establishments; I've done it recently, so this is what I see. There's automated -- in drug manufacturing, there's automated equipment; there's programmable logic controllers that the manufacturer puts their recipe into, okay.
Then there's a distributor control systems, there's supervisory control and data acquisition systems, there's LIM systems for the laboratory testing, there's the MRP, which is material resource planning which is two steps down from the ERP that was mentioned -- enterprise resource planning. And the MRP is basically an inventory management system in the drug facilities.
So the comparisons; you really needed to define the functionality before you start making a comparison. You really need to define what you're taking about. So let's do a little of that. Okay, what's the raw material in a drug facility?
It's a material, it's a substance. They have approved supplier list, and it's either yes or no; it's an approved supplier or not an approved supplier. They have incoming inspection and/or testing, and that's either pass or fail. One lot of a raw material drug can be used in multiple finished product batches.
Now for blood, you have the donor history. The donor comes in off the street, and there's the questionnaires, the medical history is taken, the testing is done. There's algorithms to determine acceptability considering all prior donations and the medical history. Testing those algorithms to determine the acceptability of current donation and future suitability -- and it's one unit; one donor, one unit; multiple components, but basically one unit. The testing in drug, there's multiple testing of this during drug processing.
There's multiple in-process tests performed, there's finished product testing, and this is even when they're using process analytical technology that's kind of like in-line testing, but it's still -- it's multiple testing event. You have multiple occasions where you can catch if something is going wrong whereas in blood, there's one test of record for the ABO, and there's one test of record for each trio marker. So I consider them very different.
Comparisons: drug problems with the system in my mind may be more easily detected; you have automated equipment, there are sensors, there's alarms, there's printouts, there's feedback groups, there's just -- in distributor control system again, it's another level above the PLC piece of equipment. There's monitoring and alarms and printouts, you've the in-process testing again, you have finished product testing, you have hardware and software controls.
And expiration dating is another example. In drugs sets assigned from the date of manufacture; whatever they consider the date of manufacture, which may be the date of filling or some date, but it's a set date, and then it's 24 months or 36 months from that date.
In blood, the suitability of product for release is dependant primarily on software algorithms. It's software. The suitability of product for transfusion to a patient; you take the history of the antibodies, warnings of being compatibilities are generated again by an algorithm in the software and computerized cross match.
Again, all algorithm-driven, not discrete testing, and yes or no into the inventory management system. Expiration dating, again in blood, I mean it's calculated initially from the component that is manufactured, but then it's modified.
And then that modification can, you know, when they started irradiating blood, they had one product and then, you know, there is an algorithm to determine that it's, you know, would never go beyond its original expiration date, and be confined by the new expiration date.
So in conclusion, I discussed -- and the market and size, I'm not going to run through this, even though -- discussed inspection of drugs manufacturers and blood establishments. I touched on the validation by the developer versus validation by the user, and I identified some differences in processing of drug products and blood products.
Oh, I do want to say one thing when, you know, another issue was made about -- I hope I got this right, I wanted to ask you a question, but I didn't get up in time -- about the Canadian paradigm. And so it's not called a device, but the regulatory authorities can go into that facility at any time. See we are constrained by our law, where if it's not defined as a device, I don't have any right to go in there.
I mean, I need -- it needs to be something that we regulate for me to go in there and give a notice of inspection and poke around. So, if I got that wrong, let me know. But I mean, that's -- and in Europe, where you know, where it's mentioned that they were regulatory. The blood systems were owned by the national regulatory authorities, well that's a lot different too. They can go in there at any time. So I just -- I just thought that should be, you know, highlighted that -- you know, if it's not a device, we don't have any right to go in there. I mean, in cases of emergencies, I've had to go in places, because like a PCB leakage or something -- and I was asked to go out. Well, it was like, "What are you doing here, you don't regulate us." And I'm like, I'm trying to do you a favor, you know. You don’t have to let me in, but I'd like to give you some information that could be beneficial to you. So that's all I have.
(Applause)
Thank you.
MR. DODDRIDGE: Thank you Joan. Are there any questions for Joan?
SPEAKER: (Off mike).
MR. DODDRIDGE: Yes, please.
SPEAKER: Looking at the design controls and production process control slides that would be on page 3 of the handout, and this is -- question is not necessarily directed to you, but looks at the people who've gone through this process before. What would be your opinion on how well defined these design control and production process controls are under the FDA regulations? If you could (off mike) --
SPEAKER: For drugs?
SPEAKER: -- and people who have experienced it, how well they define.
SPEAKER: Are you asking about the actual regulation?
SPEAKER: The slides here say that design controls are not software development principles, and software development principles come in as many colors as there are stars in the sky. And you can pick your choices on what it makes it good or bad software designing development method, and there are many of those.
How well would that define as people run through the process, how well is that defined? You know one person prefers a rational method, one person prefers a (off mike).
MS. LORENG: Oh, I would just say that QSR itself talks about requirements, specifications, iterative process, design review, validation, risk assessment. So I -- what I try to do is, since it's a software talk, I try to say design controls and how -- and software development principles would -- you could say they're your SOPs too for how you're going to develop it. But --
SPEAKER: Yeah, Chris Fletcher (phonetic) from (off mike). And yeah, basically it's all around fitting your software development process into what the FDA is looking for, the things like designing tools, designing plan, design outputs, verification, validation and (off mike).
No matter what particular process you're following, a particular method, or a structured method, whatever, you still develop those kinds of products and they still fit into the design controls of the FDA. Is that answered?
MS. LORENG: We don't -- we don’t endorse one development-type model, if that's what you're getting at.
SPEAKER: No, no, that's not what I'm getting at.
SPEAKER: And let me try it in another way that might make more sense. And I think that from what I heard you say is that it's kind of like a CobiT standards inspection, in that you have to have your software development method documented, and then the FDA is going to come in and test it against your method to make sure people follow. Is that what I'm hearing? And the FDA doesn't say you have to do it this way or that way or the other way, they're saying --
SPEAKER: And against the QSR, I mean new development has to meet -- be in compliance with the QSR.
SPEAKER: My question to these folks is, is that that clear enough defined from a software development methodology, in your mind -- because I've never done it, so.
MR. DODDRIDGE: I suggest that that may be good cocktail information that you can discuss with the members. Thank you.
Our next speaker is Tammy Poling who works for Sunquest Information Systems, but she is also a member of the AABB Information Systems committee, and I believe will be speaking on behalf of the committee.
She is going to present the results of a survey that ABC and AABB conducted of independent blood centers, hospital blood banks, and transfusion services. The survey questions were developed by the members of the BECS Conference planning committee, and included several staff from the FDA. Please welcome Tammy.
(Applause)
MS. POLING: Good afternoon. Do you hear me okay? All right. As we said, we -- I'm going to start with giving you some survey results that we did as a team. We developed the survey as a planning committee. The survey was distributed by ABC, America's Blood Center, and AABB, and we distributed in June of this year. The ABC sent the survey to their members, and AABB sent it out to their transfusion members.
They divided it up, AABB divided it up to their hospital blood banks and their transfusion members, and then ABC sent it out to the donor members. We sent it out and collected the responses. We are linked to a website survey software.
Of the 75 ABC members that we sent to, they received 63 responses, which was an 84 percent response rate. AABB receive -- sent out over a thousand surveys and received back 312 responses. While this is only a response rate of just over 30 percent, for AABB that tends to be a pretty good response rate, to be honest. They were actually hoping to get between 15 and 20 percent back and they received over 30 percent. So as far as the AABB goes, they actually got a pretty good response rate for -- on the survey. With that many members, it actually is kind of tough to get back a really strong response rate.
So the ABC members, so again this is the larger donor centers, your ABC members; 38 percent of the responses were from members that drew less than 50,000 units, 32 percent were members that drew between 50,000 and 100,000 units a year, and then 30 percent were over 100,000 units. So their responses were divvied up pretty good, 30 percent almost equivalently between -- almost equally between 30, 30, 30, the different-sized collection centers. And over 94 percent of them used a computer system. So that's probably a good percentage, and that's where we would respond. I don't think there is a whole lot of people who are still manually out there.
And I'm hoping those are the really small ones. Sixty -- 73 percent of them said they are on the latest version of their software, 25 percent of them said they are not on the latest version and 2 percent of them did not know.
Of these survey respondents, these are the users. Again, these are the ABC respondents, 35 percent said they use BBCS, 29 percent WinGate, 10 percent SysTec, 8 percent Mediware, and then a variety of others. And again these are just the people that responded to the survey. This is by all means it's not a --
SPEAKER: (Off mike) respond. They didn't want to --
MS. POLING: Again, this is not a complete list of donor software vendors. This is just the people that responded to the survey. The ABC-responder profile, we asked them how do you use this software. And this is the top uses. Obviously, there are a whole lot of other uses that both Rodeina and Angus have covered today, but this was the top uses that came in. The primary use was donor management, component manufacturing, inventory management testing, donor health history recruitment. These all came up in the top 50 percent of uses for their software.
Eighty-four percent of them received their IT support internally. Their validation: 89 percent performed validation both by the IT department and by the users, 8 percent of them had their validation performed only by the IT department, 3 percent did validation by the users. No one that responded to the ABC survey had validation performed either by -- either with vendor assistance or by an outside consultant.
Okay, the AABB respondents. So these are primarily transfusion centers or hospital-based donor systems, so they are smaller donor centers based on a hospital. This was not divvied up so well. I guess, we didn't give them as good a range. 70 percent transfused less than 10,000 units a year, 29 percent was 10,000 to 40,000 units a year, and then only 1 percent was greater than 40,000 units a year. Again, about the same, 95 percent used a computer system. Only 53 percent are on the latest software, 38 percent are not on the latest version, and 9 percent of them are just not sure.
And here's the breakdown of users and what software they are currently using. And again, we have some other brands there. But again, this is not just a list of every transfusion software out there, but these are who responded to the surveys. And again, the primary functions; we receive back transfusion management, component manufacturing and testing, and again there's a -- with a whole lot of list of other functions they do. But this was at the top of the list.
Seventy-nine percent received their IT support internally, 40 percent did their validation both by the IT department and the users, only 4 percent had their validation done only by the IT department, 34 percent did their validation only by the users, 11 percent was vendor assisted, and 10 percent was done by outside consultants, which is very different than what we saw from the donor centers, seeing that almost 20 percent had outside help with their validation. And I'm thinking a lot of this probably comes by who does the IT support, thinking that probably in a transfusion center service, we're going to see a lot of the IT support coming from LIS department that only does part-time transfusion support or even a hospital-wide IT department that again is only giving part-time assistance to the transfusion system. So they're going outside to get their help probably with the validation and putting more money into outside assistance.
Okay. So now, I'm going to read you some of the questions we actually put out here for them to get a feel more for their view of the 510(k) process. Since we're here today discussing some of the advantages, disadvantages of the 510(k) process, we wanted to see as a committee, what the view of the industry was.
So one of our first questions was does the requirement for the FDA 510(k) clearance limits the number of software vendors willing to enter the market, forces them to assume regulatory liability that outweighs the revenue potential that may derive from the software product. Then we asked them to scale this; "This greatly helps my facility/somewhat helps my facility/has little or no impact on my facility/somewhat hurts my facility/greatly hurts my facility," or "I completely disagree with the assertion."
Now, the first row is the ABC members, and then the -- again, the AABB members were grouped into either transfusion services members or hospital blood banks. The hospital blood banks or the small hospital donor centers, this is how AABB divides up their membership. And so you'll see, for the most part, we have a little difference between the AABB members and the ABC members.
The ABC members tend to skew a little more towards "Somewhat hurts my facility." The AABB members are more "Little or no impact." And if you go to the next slide, you get more of a graphical representation where you can see the ABC members are slid a little bit more to the right, while the AABB members, both of those graphs are "Little or no impact."
The next question we asked them, FDA regulation of BECS as a medical device in general and 510(k) clearance in particular, improves the safety of BECS software on the market. And we have pretty much down the line "Somewhat helps my facility." Now this is one of these questions where I really didn't expect to see much in the "Somewhat hurts my facility" or "Greatly hurts my facility" column. I can't imagine anyone would say the safety would hurt their facility. We were kind of more interested in, you know, how far towards "It helps" or "Little impact" or even "Disagree" would -- what would fall into there.
For the most part though, we did get a pretty strong 50 percent response down the row in "Somewhat helps my facility." And so graphically, that's where we see that.
The question as to whether the 510(k) clearance slows downtime in the market for improvements and upgrades, and contributes to blood centers maintaining older and antiquated systems. We got a little skew to "Somewhat hurts my facility," and a little higher on "Greatly hurts my facility" for the ABC members. You don't see that so much on the transfusion side. Though you do have a 10 percent of the ABC members disagreeing with the assertion, and this is another one of those where you don't expect to see much on the "Helps my facility" side. So you'd -- you know, I'm little surprised to see much there at all. And again, just a graphic representation of that for the visual folks out there.
The FDA 510 clearance requirement increases cost for the vendor that are passed to the consumer through increased product support and implementation costs. Again, we don't have -- we have a little skew to "Somewhat hurts my facility," nothing amazing or strong either way. Another one of those; I wouldn't expect a lot of skew to the left just because of the wording of the question. You wouldn't expect anyone to really say "It helps your facility."
But everyone seems to be falling in line. So these last couple of questions, you don't see much disagreement between the donor -- the donor systems and the transfusion systems.
FDA ensures processes are in place for the vendor to notify its customers in the event a significant safety issue arises with its software. Again, you see a pretty strong left movement here though; "Greatly helps my facility" and "Somewhat helps my facility." And you don't even see a very strong disagreement with that. So everyone pretty much just to the left on that. And again, you see a pretty good agreement between all the surveys. The current regulatory scheme limits the integration of third party software to BECS. Interfaces must undergo medical device 510(k) clearance. This is actually an interesting one because we really did see a strong difference between the ABC members and the AABB members. You see the ABC members, that 40 percent, in "Greatly hurts my facility." And I think that may be a difference between the transfusion software, is really only interfacing with the LIS systems and the --
SPEAKER: (Off mike).
MS. POLING: And the -- yeah, and the -- and the donor systems are trying to interface with other systems. But the transfusion systems, really, it's the LIS systems that are trying to go outside, and they don't have to get the 510(k) clearance for the LIS system to integrate. And so I don't see the transfusion systems so much, needing to get the integration or the 510(k) to integrate.
So if you look at that graphically, you see the huge difference. Okay, we had a couple -- actually, did I skip a note? We had a couple of true or false questions. The FDA requirement for 510(k) clearance helped to reduce the number of bugs in the software prior to release to market. The blue is true, and the red is false. So for the most part, the ABC members were kind of 50-50 on that, but the transfusion members pretty much, 65 to 40, or 65 to 35.
Do you believe that 510(k) clearance helps reduce the number of bugs in software prior to release to market? And then the FDA requires BECS software vendors to have quality processes in place to ensure a minimum level of safety and quality. And that's 90 -- 90 percent difference, and pretty much straight across the board.
(Applause)
MS. POLING: Yes, sir.
MR. BIANCO: I am Celso Bianco of the America's Blood Centers. Just a couple of questions we're trying to gauge. Who were the people at each of these institutions that answered the survey? We got to cut down with the cost or something like that, we see a full -- with kind of very different answer from the quality department.
MS. POLING: It varied. We sent it to -- for AABB it required -- it depended on who the contact person was. And we did ask that question on the survey and I didn't have it here to present on the slide. Most of the time at the AABB -- on the AABB survey, most of them were transfusion services supervisors. At the ABC, I believe, most of them were IT people.
SPEAKER: IT quality and the AABB --
SPEAKER: Yeah, and --
MS. POLING: IT --
SPEAKER: -- and the second of these clarifications that you see in terms of the four centers that have their own systems, those are exactly the 6 percent. You said 94 percent said "yes, we have a computer system," and that 4 didn't have any type of computer system. Could that be a confusion that those were the 4 that had in-house systems? And I believe the question was great because I cannot believe that a blood center to date doesn't have a computer system.
MS. POLING: Could that -- could be, okay, yeah, it could be.
(Laughter)
MR. DODDRIDGE: Any other questions?
Okay, thank you, Tammy.
I would like to take a 15-minute break, and I want to again emphasize that if there's any questions, Bob will be taking those questions. He'll be roaming around this room and probably out in the foyer. So if you see him, please give him those written questions. One of the things I was amazed that there were still, what was a 4 percent that did not have end-user validation; they had their IT department do the validation, I hope that was a mistake.
Okay, well, Jeff will be giving us a wrap-up right after the break. So we're going to take a 15-minute break and be here in just between 1:00 and 1:05 or 2:01, I'm sorry.
(Recess)
MR. DODDRIDGE: We're about to get started again if everybody could come on in and take their seats?
Can we please take our seats if you are in the back of the room, then we'll get started?
I'll turn this off before we start it.
Okay, we're going to start the next session with Jeff McCullough. Jeff will be -- I've seen him taking copious notes over there. So I'm sure he's going to have a lot of points for us to consider this afternoon.
Jeff, I do appreciate you putting this conference over your African safari. I understand that you were to be over in Africa, so we appreciate you making the sacrifice, so Jeff?
MR. McCULLOUGH: Thank you very much. And at least, I won't attacked by elephants or something here, but maybe attacked by some of the audience. I don't know.
SPEAKER: Yeah.
MR. McCULLOUGH: I had to, I guess, with mixed feelings, thank you for inviting me. It's been an interesting day so far. I think as most of you know, I don't do this on a daily basis. And so I'm probably the least informed person in the room which may be to some advantage. And I apologize upfront if I'm asking some rather naïve or inappropriate questions.
But I have been able to jot down some things that occurred to me as the discussions have gone on. And so what I like to do is just start to go through these. And this isn't intended to be a presentation, because I'm going to ask you to join in with the discussion or consideration of these issues.
And so it seems to me starting with some of the larger issues; first point I have here is to what extent has the situation changed in approximately the last 15 years or so since the regulatory approach was applied. Some of the discussions have implied that the -- certainly, the technology has changed, but some of the discussions have implied that the level of expertise has changed in blood centers, or other things have occurred in the environment, which would cause or enable us to think in 2008 terms about the way in which these systems are regulated. Would anybody like to say anything about this?
Rodeina, maybe you would? I don't mean to put you on the spot, but I want to have -- why not.
(Laughter)
MR. McCULLOUGH: I think you did allude to this at least in your discussion.
MS. DAVIS: (Off mike) I think I did, and want to add that probably it wasn't too clear what all of the presentation this morning is. And firstly I think -- this presentation is still at the maturity level of the IT folks in our blood center, who do we have? And the maturity of the level of understanding the technology and really understanding the complexity of what are the blood banking functionality are, as well as the knowledge and the system that are in place regarding validation.
I do support what the discussion early this afternoon regarding we do have the FDA go to a software vendor and look at their older design culture. It is the vendor role to look at their own cycle through and make sure that they do it right, and they are following the proper methodology. I think when we were in 1990 as I witnessed during the change of the past 10 years within IT, we came a long way as an organization, understanding the technology, understanding what we need to do. And I think we need to look at this point, how can we as an industry, work together to get the best out of everything we have, versus -- or spinning our wheel in trying to do something and stepping on each other without getting the result that we need. So I leave it open if any other folks want to add to this.
MR. McCULLOUGH: Okay, well, thank you. Let me, I guess, in the interest of time, I'm going to have to go through these little more quickly than I had planned. But it seems to me that several issues surrounding this whole point that are illustrated here in it; does this regulatory approach help assure or improve blood safety?
And is there some evidence or suggestion that quality and safety has improved as a result of this regulatory environment? So I'm not sure that we have any answers to that. I'm sorry I don't remember, one of the speakers showed some data about recalls and that sort of thing which seemed to suggest that they weren't much different today than they were pre-regulatory, which maybe that's good news or bad news.
But it seems to me that where we've to start is, is this regulatory framework improving blood safety and helping patients. Secondly, a number of speakers -- and there's a sort of a general toeing in the room that the big -- the big guys don't play in this game; IBM, or Microsoft, or others. And there is another -- these are various ways of referring to this, that it's a niche market or there are unlimited number of options.
So my first question is, does it really matter that Microsoft and IBM aren't in the business, number one. Number two, is this really a niche market, or is it just a modest-sized market when one thinks globally. And I'm not sure I'd really think of it as a niche market so much as there is a finite size to this market, as there is for most things that we sell to blood systems.
And so there's lot of discussion that the current limited choice is a risk, at a limited number of vendors. One of the slides again, that someone showed that something like 37 percent of the clearances were with four companies and the other 67 percent were with 41 other vendors, 18 of which had only one clearance.
Well, that's a lot of vendors. It would suggest there are at least four fairly substantial vendors, which is two more than the vendors for NAT reagents, by the way.
(Laughter)
MR. McCULLOUGH: And so I want to mention that as an example, clearly these systems are essential. You can't go down on these systems and begin to function. On the other hand, we can't go without NAT reagents further so and continue to function. And as you know, we can't substitute the other manufacturers NAT reagents, because the devices and everything else are designed for that particular system.
So apart from that as an example, I'm not sure if we think of plastic bags, or are there other five or six global manufacturers of plastic bags, also blood taping reagents. So I'm not sure -- I don't know what the ideal size is for the number of vendors that would be ideal in this field, but it isn't obvious to me as a new kid on the block that the number of vendors that are there now is somehow a limitation or a problem.
So it might be something for similar discussions. But if -- one of the implications is that the -- well, final implication pretty clearly stated that the regulatory environment prohibits more vendors from entering the field. But if we already have twice as many vendors as we do for NAT reagents, and about the same as we do for making plastic bags, the question is while it's a disaster, if one of these systems goes down and the blood center can't operate, is this really that much of a threat if we have four, five, six really solid vendors.
So we'll continue with that. But -- well, one other point along those lines, for instance, with plastic bags if or when the Avian Flu pandemic hits, so we'll probably be out of plastic bags before it ever gets to United States because they're all made in other parts of the world. So I'm not so sure the number of vendors is as bad as it sort of been implied here.
It would be, I think, very helpful to have some more discussion, and I'm really sorry I don't remember all -- the particular speaker's name, I think it was you Joan, right? You had two or three really nice slides where you compared the pharma versus blood systems, processes, and how your view is that there is such a fundamental difference about the way the software functions, that it's appropriate to have regulatory differences.
I think that's an issue that would really be very helpful and would benefit from further thinking or discussion. I don't mean to disagree with your slides, but it seems as if that's one of the things that's at the heart of some of these regulatory issues.
If one is trying to find global harmonization of regulating software, and the U.S. is different from everyone else, it would be helpful to have more discussion about the basis for the thinking of the United States versus other regulators, and maybe there isn't a way to harmonize it, but that -- those were really nice slides and it would be a nice basis for more discussion.
The other point on this slide is the -- I liked, I think it was you also, the white and the black box, and that's another area that would benefit from discussion of clearly most blood establishments will not have the expertise to really review what's in the vendor development process, and therefore it does become a black box.
Does this matter and is it realistic to think that blood centers would probably not, so is it necessary for anybody; and if so, it makes sense that it would be the regulators, but to what extent is it important to be able to analyze what's in that vendors development system, and what's in that -- what is the black box to most of us.
A couple of other comments here, one of the concerns has been that the regulatory environment inhibits technologic advances and that it prevents us from implementing cutting edge technology. While -- and I concede that of course, we all want to have cutting edge technology, my question is to what extent do we need cutting edge technology.
To what extent are we getting caught up in the guys that used to hang around in my fraternity in college who every time there was a new speaker system that came out, they wanted to get the new speaker system because it had one more refinement in the sound system that it was providing, but when you sat and listened to it, you couldn't tell one bit of difference in the sound system.
So it may be a dumb analogy, but of course, they are extremely creative people in the technology industry, and the technology is going to constantly evolve and change. And so I think it's really more of a thoughtful management decision about how important it is to evolve and change a lot, just as along with that, versus how much can we stabilize and standardize what we do and go through generations of iteration which leads me to also suggestions for the agency to consider.
I'm not sure where it is on this list, but there has been some discussion about whether there might be ways that the agency could either provide more information or more guidance or somehow streamline things so that when there are really valuable enhancements or technologic enhancements that are appropriate to introduce that this could be done in a reasonable and realistic way. And it seems to me one of the -- if I could just make an aside or comment, that one of the wonderful values of today and tomorrow is that you're all here.
I gather that this kind of dialog has not occurred much at all, and so hopefully, ABC has taken a wonderful leadership position here in beginning to foster this kind of dialog because it's bound to be helpful to move things forward.
A couple of other points here; deciding when to submit -- a couple of people mentioned that we don't know when to submit for an enhancement. Well, can't you call up the FDA and ask them? Maybe, I comment this from a different -- I know I commented a different view because a lot of what I do these days is dealing with novel zygotic therapies of stem cells or tumor vaccines or things like that.
And this is a new regulatory arena for the FDA, and we talk to the FDA all the time. And often we call and ask them how they think about regulating something, and they say we don't know and we should talk about it. And there are regular meetings where various investigators and key FDA individuals meet and talk about how to address these sorts of things. So maybe one of the outcomes of today will be some more of these kinds of sessions where this kind of dialog can occur.
Another point was made by somebody that it's very difficult for newcomers to submit, is that bad? You know, I'm not sure that I want to operate my blood center with a newcomer. So if a newcomer has so little expertise that they're not sure how to go about this, maybe there is a lesson there. I'm not sure that's a disaster.
There are a number of comments also about -- which seemed very appropriate, about how to interface these systems with other systems. And I have two or three other slides which I wanted to show, but the way I think about all this is, the central thing to me is the control of the manufacturing process which also means qualifying the raw material which are the donors.
So the donor evaluation and donor selection, all the manufacturing process, but there are different aspects of this from that. There's the management aspect, there's the business aspect, those sorts of things, which I think of as different. And then also, if you're trying to interface with the hospital transfusion service and the computer system there, these are challenges.
And ideally, the systems will fit together and -- but it seems as if this also could benefit from a dialog with the vendors and the blood systems, and the FDA, as to how one can enhance those integrations, but yet find a line, where one has moved over into things that really don't need regulatory scrutiny.
Well, I think maybe I'll just comment on the last line on this slide. I think it was our colleague from Scotland who also points out that we may also be contributing to the situation. And I just end with one little anecdote of when I was at Red Cross national headquarters a lot of years ago, we -- in the '80s we had BMIS, the Blood Management Information System, which was an IBM system that we'd in about 20 of our centers at that time.
And we had IBM all programmed, all planned; they had committed to develop a single comprehensive system for the Red Cross to roll out, and they were going to do it at their cost and make it a donation to the Red Cross. But a month after I left Washington to go back to the tundra in Minnesota, the IT folks at Red Cross convinced Ms. Dole that they could do it as well or better than IBM, and I think IBM excels in the market.
So you know, there are probably are a lot of ways in which we're also a part of this situation, and maybe the best outcome from today and tomorrow is that this were just one of the first of many of these kinds of meetings where some nice progress can be made. So I'll try to hang in there and do what I can over the next day or so. That's it and thanks.
(Applause)
MR. DODDRIDGE: Jeff, I thank you for giving us lot of points that we can take to those breakout sessions, and hopefully there we can find some answers to them. We do have -- I hope you've all picked up your slips for the session that you would like to go to. If you haven't, I'm sure Laurie may have some extras in the back, or I would suggest you just find -- follow one of the packs going out of here and find your room.
I'd like to ring up the leaders now, if you have a slip for topic one, Mark and Eva. Would you hold up your hands, where's Mark and Eva? Mark's in the back, well, that will be in Severn, which is across the hall to the left, I believe. So those that have had topic one, if you'll go ahead and follow Mark. We'll try to get one group out at a time, and see if that will work.
Okay, we have group two; Galder (phonetic) and Tammy, would you hold up your hands. He's Galder, Tammy? They will be in the Annapolis room which is down the hall on the same level. We need to, like these tour guides overseas with their little umbrellas or the banners that they wave. If you're in group three, Katherine and Gem. Gem is right there, he's hard to miss there. Gem will be taking you down to the assembly room on the mezzanine, which is one level below.
And last but not least, we have our group four with Mary Beth and Becky, right over here on the end. And they will also head over the council which is also on the mezzanine level. So if you're in group four, follow Mary Beth and Becky, and that will be down on the mezzanine level. It's one level --
(Recess)
MR. DODDRIDGE: If we could find a seat, if all the sessions are over we are going to try and get started. Bill, do we know if all the sessions have ended?
(Pause)
MR. DODDRIDGE : Okay, I see our last group has arrived, so I think we'll try and get started. Could I have your attention please, and let's try to start the session. I did take the opportunity to go to all four breakouts, and there was a lot of lively discussion going on. So I think we are going to have some good discussion that as each of the facilitators come forward and give us a review.
The format will be that we'll have each group come up and give about a 10-minute presentation today. so our first group to come up is -- will be on the issues in applying medical device quality systems, regulation to contemporary software development. And Mark and Eva, who is going to give that presentation?
MS. QUINLEY: I think got the stuff with --
MR. DODDRIDGE: You think you got stuff -- oh, he is following you.
MS. QUINLEY: So I do it from here, is this okay?
SPEAKER: Bob is that okay or do you want to --
MS. QUINLEY: Oh -- you want it up there --
SPEAKER: Go up to the (off mike).
MS. QUINLEY: Well, our topic was issues with the applicability of the QSRs, and one of the things we found out right off the bat that it's not so much the regs, but it's ourselves that are the issues in many ways. And so some of the things that you will see we discovered are actually because we are blood bankers and we are kind of set in our ways.
One of the questions that Mark brought up was, how do you feel the applications of the regs affect the development of software, and one of the things that came up was that it's very important that you engage your customers in the development, so that you get the requirements right.
The regs want us to have a list of requirements and really sometimes we can't have that list complete until we actually get into the development. So it's important that the vendors work with the customers to do things like have user groups, look at industry trends, have advocates within the vendor staff that are actually blood bankers who understand the process, and use focal groups as much as possible.
One of the things that came out here though is that often times there is new technology that come out -- that comes out, and we are very slow to implement that because we are not comfortable with it.
The Internet was brought up, for example, but it took years to be comfortable with that both from the FDA's standpoint and from our standpoint as well. So that's one of those areas where the issue is really with ourselves, and our comfort level of a new technology.
The other thing we asked, and then we had lots of interest in the room, which was great was how do you view the regs from a competitive nature, and here the statement says it all. If you want to apply the -- if you want to get in the game you got to play it by the rules. And so these are rules and -- quite unexpected, I guess, I didn't expect this.
There was a lot of positive about the regulations that they felt without those regulations we would have crappy software that was a terminology that was used. So that it is important.
The users though that were in the room had a little slightly different view, they felt that it impeded us getting something very quickly. Because often times you had to you know go through the requirements, the hoops to get something quickly. So we came up with this issue about interfaces, and we talked a lot about what if we had a standard interface.
And from our FDA folks that were in the room, they said well, if we had a consensus standard certainly that would be something that they might approve the entire thing or they might approve part of it. There's an issue there though because of the proprietary nature of many of our vendor's software. So that's an issue with the applicability of the rules that came up.
Another thing that we talked about was there's a lot that goes on in the software that really is not critical to the outcome of making sure that unsuitable product doesn’t get out the door, or that the donor is not harmed. So do we have to do the clearance on everything.
And many of the people in the room brought up, and I think rightly so, well, how do you segment what you are to put through the clearance and what you are not. And you are going to limit, actually it's going to limit the vendors in their marketability of their product if they do that.
Around this consensus standard though there was a lot of discussion about if we were to do that how would we go about doing that. We brought up ISBT and we all know how quickly we got that, so --
(Laughter)
MS. QUINLEY: So there was a lot of discussion about what we should do, if we should have ABB convene a group, and then the vendors brought up, well, the market is international now, and so we would have to ensure that whatever group convened that would have representation from the globe because that's where the marketplace is spread to.
There was also a question about if blood banking were very sophisticated, and we had very sophisticated internal external vendor audits, would we even need these things, would we need these regulations. And the answer was yes, because we don't want a lot of different people coming in and doing audits of us, it's much better to just have the FDA come in.
And I thought that made a good point. Now, one of the vendors that was there, said they had 12 different vendor audits in a very short time period, which I would tell you would drive me nuts.
Anything else Mark that you can think of. I have a lot of notes here, I write a lot of stuff. I think that’s pretty much it, that we came up with -- it was a good group that we had, we had vendors, we had users, we had a lot of people that were very opinionated about the software, and very passionate about it. So we had some really good discussions.
MR. WEISCHEDEL: You know, I would -- this is Mark Weischedel, CIO of the American Red Cross. I'd add that there was a great deal of energy in the room around standards, not -- as you might imagine when you talk about standards in technology there was not consensus on what to do, when to do it how to do it. There wasn't really consensus on much of anything really. But --
(Laughter)
MR. WEISCHEDEL: But the standards are very much needed, and it's something that is probably long overdue in our industry, and a great deal of interest in moving forward. And other than that I thought -- by the way, I am from Philly and Eva is from Tennessee, I really thought you'd enjoy her accent more than mine. But I'd be happy to take any questions.
MS. QUINLEY: Thank you all.
(Applause)
MR. DODDRIDGE: Our second group topic was to identify the top barriers and advantages of a FDA 510(k) clearance in the development of BEC software. And Gouter and Tammy will be giving that presentation.
GOUTER: Thank you. You know, I actually put a small little presentation here, so let's see. We had a great group. See that --
(Laughter)
GOUTER: No cholesterol, no flak (phonetic), easy flow.
(Laughter)
GOUTER: You know, we had a really vibrant team, we had users, we had vendors, and we had FDA. We had a lot of exciting discussion. We didn't even know how time went by, so in the last two minutes we were trying to cover up and come up with the things that we thought are important to share with this group.
So here it goes. This is a consensus of our team. Our topic was five top barriers and advantages that are associated with the 510(k) process. The advantages and barriers. Number one --
TAMMY: The number one advantage, to the 510(k) process is --
(Laughter)
TAMMY: Improves quality and adds assurances of quality.
GOUTER: Number five, the last barrier --
(Laughter)
GOUTER: Negative experiences cause ripple effects.
TAMMY: The number two advantage to the 510 carrier -- to the 510(k) process, it ensures the processes are followed.
GOUTER: Item four barrier, false sense of security for some users.
TAMMY: The number three advantage, keeps vendors accountable.
GOUTER: It certainly creates a closed system.
TAMMY: Number four advantage promotes getting bugs fixed.
GOUTER: Interfacing and integration of satellite systems with the 510(k) system becomes complicated.
TAMMY: And the fifth advantage is that it ensures common minimum standards.
GOUTER: Of course we have been talking all day in every presentation 510(k) process does up bring the cost and also has the time factor with the process. So not only we talked about the advantages and barriers. The more we talk about -- okay tell me some advantage, but we kept talking neither advantage nor barriers. So then we thought it is important here to share what other ideas our team came up with.
That would help the process is streamline the 510(k) process. So meetings like this going forward, some kind of a workshop, some kind of a platform where we streamline the -- discuss about how the 510(k) process works and streamline it. Gather more data to determine effectiveness of 510(k).
So we tried to come up with the barriers, and the advantages without having enough data not evident it is hard to quantify those opinions, better communication with, among from users to vendors to FDAs, in that 300-day cycle we need a better communication.
And the process is hard. Sometimes we thought it's a -- it could be a perception getting 510(k) a review process, getting 510(k) clearance, so we think process is hard, so the team felt that they could be sometimes as a perception. That's about it, any questions for us? And our team was great, thank you for everyone who participated in the team.
(Applause)
MR. DODDRIDGE: Now, that sounded like David Letterman's top ten list there.
(Laughter)
MR. DODDRIDGE: And we got a little tech savvy there going on, is it like the two groups, I want to see if you could beat that, that is the only PowerPoint we've had so far. The third group is the impact of FDA's medical device approval process, and 510 clearance on blood safety, and that was Kathleen and Jim. And I believe Jim you are going to give the report?
SPEAKER: (Off mike). Do you have anyone --
MR. MacPHERSON: Oh, no this is low tech. This is low tech, sorry. Well, our topic was some what -- oh, let me get rid of this, that's a distraction here. We'll go back to the desktop. Our topic was -- oop -- similar, in the impact of FDA medical device approval and 510(k) approval on blood safety. But we were able to dispose of that topic fairly quickly.
Because there was a general agreement that, and probably not for the specific regulation of the computer systems, but the integration of requirement for quality systems in the early 1990's on blood products on the blood establishments. That had a huge impact that rippled throughout the entire organization, and certainly as far as computer systems, but in all systems, in all processes.
So the application of the quality systems, everyone agreed it was extremely important. We also agreed that we are not -- it's not that we are regulating the wrong things, or not having to paying attention or having standards to the wrong things. In fact we are probably measuring or looking at the right things.
The question was process. Are we reusing the right process, are we using the most efficient process, are we using a process that has kept up with the time as opposed to a process that may have been put in place 15 - 20 years ago when the situation was much different, and the players were much different than our level of sophistication was much different.
And I think that's where we had a lot of different thoughts and different ideas, which I will try to go through some of that, and it's all going to be verbal but. I think we -- there were some discussion and I can't say there was agreement. There was discussion as to whether we -- whether the issue is that the 510(k) process itself is a problem.
You know, should we be going to a system that's similar to what the Canadians or what the Europeans use, and putting the focus all on the end user, the blood establishment, and all through validation, but measuring the same things as opposed to the 510(k) process. But if we are going to continue with the 510(k) process, how can that be simplified.
And could it be simplified even to the point of similar to CE marking to Council of Europe marking. Where it's almost voluntary but the same things are required in terms of the vendor to provide all this information and then -- and invalidation is based up on the disclosure of all that kind of information.
The theme though that we talked about through most of our discussion was opening options. You know, the options because what we have in place right now is a barrier to upgrades, is a barrier to change. And that we are using the -- it was pointed out we are using the latest accounting system.
And we are using the latest HR tracking system, and we are using the latest of this system and that system, but when we get to regulated systems, the systems are far behind what state of the art, and really that's our core business. And that's what we are doing, yet we are not using the best systems out there.
And it isn't the vendor's fault. Jeff McCullough asked the question, you know, was four vendors enough, and the other question that was asked is, is this the right vendors. Why aren’t we, you know, we have blue chip companies as far as providing us with math and serological testing, but where are the blue chip companies when it comes to a computer systems.
And -- or will we always have niche players, because we are such a small industry that there is a barrier to the market that the large manufacturers will see we're too small, and too specialized, and they may stay away. It's not clear how much of the small market is the barrier versus the regulation.
Clearly the regulation is a barrier because the vendors will say that, if you talk to a Microsoft if you talk to SAP and they just say they don't want to get into that because they don't have to, and make money. And yet at the same time we are a small, we are a very small market. Even worldwide we are very small market.
So I think that's an issue. I think those are the top issues that we talked about. There were lots of specifics that we talked about. There were some discussions about the fact that there is a lot of variation from country to country.
You have a lot of national systems that are lot easier to regulate. A national system that uses one computer system versus in the U.S. where you have over 200 -- 250 organizations collecting blood, on the other hand you have the 8020 rule. And with 20 percent of the players collecting 80 percent of the blood, and the question is are we regulating to the lowest common denominator, and to the disadvantage of the larger organizations that are being slowed as well.
And let's see. See if there is anything else that was mentioned -- any body in my group want to add something -- oh, an example of -- in terms of is the 510(k) process is a FDA barrier, and Rodeina gave the example of -- she's been working with a number of other blood centers and a number of companies on application of our FID to tracking blood from donor to patient.
And it's very feasible perhaps eventually economically feasible, but certainly systemwide it really lends itself to what we do, and yet the very companies that are the experts in this area. Once they were told they would have to potentially go through, and that there is no final decision on that. But potentially have to go through 510(k) approval has said no, we are not interested in the market if that's if we have to subject our self to 510(k).
And I think one vendor said that the 510(k) process was basically a waste of time that they could dummy up the process and fool FDA except maybe for the inspection. But that the system itself could potentially be fooled. There was a question of whether there are far more standards available today than there were 15 - 20 years ago, and the ISO was mentioned that the fact that most of the vendors to sell in European anyway have to be ISO certified in addition to the CE marking.
And you know is that sufficient at this point, and something that we should look in terms of harmonization. I think that covers it, anything else anybody can think of --
SPEAKER: (Off mike)
MR. MacPHERSON: Pardon me.
SPEAKER: (Off mike)
MR. MacPHERSON: In -- yes the -- again a simplification of the in-house developed software. You want to make the point Rodeina?
MS. DAVIS (Off mike): -- well, I thought you were --
MR. MacPHERSON: Well, I yeah -- but I'd look at my notes, and it just says in-house development. And I am not sure I captured the points you wanted to make.
MS. DAVIS: I think the question here whether we would be able to have in-house developed software. Where that software can be run under the license of one blood center although that blood center to enter state commerce where they have such as (inaudible) or Red Cross or you know, blood center where you have different chapter, or different offices across the state, but you still developing your software.
It is your own software, running it for your own organization under your license. Is that a potential not to have need for a 501(k) for in-house developed software.
MR. MacPHERSON: Oh thank you. And also the fact that there will be notification of changes and inspection would be based upon how many changes you made over the last year -- even looking at that as a possibility. And I think we are done. Thank you.
(Applause)
MR. DODDRIDGE: I don't suppose that software vendor would like to raise his hand.
(Laughter)
MR. DODDRIDGE: Our last speaker today is and the last topic is to identify validation and documentation strategies for BACS, and that will be Mary Beth and Becky. So come forward, please.
MS. BASSET: Well, there was no lack of discussion passion or questions around the topic of validation. We had more questions than we had answers for. There seemed to be lots of confusion, and you would have believed probably that since we have been in this validation business for as long as we have been in. That we really wouldn’t have had so much confusion, which just tells us that we need some more information.
So our approach was to create kind of a list of questions, the hottest topics people could think of that they really want it to address. We tried to prioritize those questions, and then went into our discussions. We had representation from the FDA from vendors, from transfusion services from blood, the blood industry and from the plasma industry, so we were really very well covered.
So our first question that we asked was, if the 510(k) process was changed, or removed what would be the impact on the end user for -- regarding validation. Now, we had lots of discussion about whether or not 510(k) ought to be removed, what that process should look like. And then we decided that that really wasn't our topic we were to talk about validations.
So we decided not to render an opinion on that particular topic, but we did decide as a group, or discussed as a group that impact would be very large. Validations would be increased for the end user. This would drive up our resources. It would drive up our money, it would cost more, it would take more time, and require more expertise, which this then possibly could impact the cost of blood.
Our second question was what clarifications do we need? This discussion really told me, and I think the group because the list was really long, that we really do need some more information and some more guidance. So some of the questions -- and I am just going to list them here. There was more than this, but I just kind of picked the highlights.
What is meant by validation strategies, what is that extent of validation needed when software is implemented at multiple sites? Confusion of what is meant by IQ, OQ, and PQ. And I really supported that because I looked at a multitude of presentations on this topic, kind of just trying to prepare myself. So I looked at presentations that industry had given, FDA had given, plasma, blood centers, and there was a real variety of definitions around those very topics. So it just does point out that maybe we do need a standard definition that we can all wrap our hands around.
What validation is required to the modification of off-the-shelf software? What is the extent of revalidation for operating system versus changes and packs -- and patches? To what extent can we rely on what the vendor has done and how much documentation is enough? So that just kind of gives you a flavor of the kinds of questions that got thrown out that people really didn't have the answers to.
And our third question was kind of out there. What would you change, if you could? What are some innovative ideas that we could come up with to present to this group that could have some thoughts for discussion? And I've got two of them listed here. And I really am going to ask couple of people that were part of the team because I'm not an IT expert. I really am just a quality professional.
And so they were talking about things that were kind of like up here for me. So the automated validation system and Robin, if you could just go to the mike and talk just briefly about what that is. This again is kind of future kinds of things to do.
(Laughter)
ROBIN: Okay, well, so in automated testing, we're -- that's talking about using a tool that's written in a coding language that actually runs by itself. And it's set to run a set of inputs and the output would come out only if all the inputs were correct. And if it wasn't correct, then it would come out as incorrect. And we discussed using those kind of tools in the future.
MS. BASSET: Thank you . And then Tim, if you could talk about application service provider. Did I get that right?
TIM: Yes, sure.
MS. BASSET: Okay, I got that part right.
TIM: We were discussing -- thinking outside the box of things that would be game changers. And it's clear that the responsibility for validation is enormous. And the smaller blood centers have -- it's more difficult for them, they have less internal expertise and resources.
And what I suggested was maybe that the industry consider an ASP model where a single -- either a vendor or a single blood establishment validate a system. They accept the responsibility for validating it for the hardware validation, for the disaster recovery capabilities, for all that stuff.
And then each of their clients then would have a much more minor validation for their own specific configurations. It might also help by -- convince people to standardize a little bit more, which would further reduce the burden of validation.
MS. BASSET. Thank you . And then the group went on to just come up with a few recommendations that maybe could be considered for the future. Because of all of the clarifications that -- and questions that came out of the group, they all believe that maybe a task force that was comprised of FDA, and vendors, and blood centers, plasma transfusion services, Canada, to all get in a room together and try to give us some kind of guidance on the lists of those things needing to be clarified.
And I'm sure there are lots of other things. But kind of all those people coming together to try to give us some answers and then to follow up that task force with a workshop that really would identify all of that information for us. And then, hopefully, that could become our industry practice.
And then the third recommendation was gathering a better partnership between the industry and the vendors around validation requirements and what is really needed for the end user and to try to work together to define what that is. Maybe having a number of end users get together that are going to have to validate this system and really try to come up with the kind of guidance that we need as vendors or as the people that are validating these systems as to what is enough.
We had a great group. It was an active discussion. And I really thank the people that were part of that session. And that's all we had.
(Applause)
MR. DODDRIDGE: I think we've heard some common threads throughout these discussions on the four topics today. And Jeff may have found some of those. And if Jeff is ready, we will hear his report to kind of end the day today.
MR. McCULLOUGH: Excuse me. I'm sorry that the -- these first several slides are the same ones I showed a few minutes ago but larger. So I apologize to those of you in the back of the room who couldn't see the first set that I showed. And I don't really plan to go back over these so much as to -- we have a few minutes. So I give you the time to attack me about some of the things I said earlier or disagree with them.
Maybe while you're thinking, Jay or someone from -- whoever you might think appropriate from the FDA, could you talk a little bit more about a couple of analogies that occurred to me that are maybe dumb ones and maybe don't apply? But the analogy of a pacemaker or a defibrillating device, where the device itself operates on software, but also I assume there is software used in the manufacturing of the device as well.
And is there anything from devices like that that we can learn that might apply to this situation? Maybe another sort of dumber analogy would be in aphaeresis devices, where you've got software that controls the device to some extent. Are there any analogies or do those not apply? Or --
MR. EPSTEIN: Well, my reviewers may wish to comment. But the general picture is that software embedded in a device such as an aphaeresis machine, which we call firmware, is regulated. But it's regulated as part of the review of the device.
So it's not a freestanding software system. It's part of the device review. And the standards for regulating that software are pretty much the same thing. In other words, we're looking for all the kinds of validation documentation that we asked for for BECS .
Now, when you talk about software that controls manufacturing, I think that the critical distinguishing feature with respect to BECS and other systems at Center for Devices that are regulated as freestanding software -- there are various systems used in the hospitals, for example -- is whether they are providing data that is contributing to clinical decision-making.
And the concept is that the functionalities go beyond merely library functions. In other words, they're not just databases. They're not just indices. But that the software contains logic functions which are substituting for or augmenting a human decision that affects health.
So that's really the distinguishing feature because you can have very elaborate library-type data systems that we're not regulating. On the other hand, you can have fairly simple logic systems that we would regulate because they're involved in clinical decision-making.
So it really just comes down to two things, that we believe that BECS, as a device, are systems that have high risk because of the impact of error on patient safety and which contribute to clinical decision-making. So that's the general framework. And it's the same framework at CDRH.
It is not simply because of control of manufacturing. And I think that that's the key misunderstanding. Yes, there are lots of systems in drug world where software controls manufacturing. But it's the clinical decision-making element. In other words, the doctor decides whether to use the drug. The software didn't help you decide whether to use the drug. It helped you manufacture the drug. But it didn't decide whether to use the drug or how to use the drug.
MR. McCULLOUGH: I'm going to skip ahead. I'll come back to some of these. I was surprised, actually, through the day that there did seem to be -- and I think, Jim, you mentioned this or it came up in your session that I came here expecting that the FDA would be attacked for regulating these devices and there would be huge enthusiasm to try to convince the FDA that they didn't need to do this at all. But in fact, that's certainly not what I'm hearing.
And in fact, in a couple of the sessions and I think someone said that there doesn't seem to be much question in the belief that this regulatory approach has certainly improved quality, overall quality and therefore, safety to patients. It's a little hard to tease out of that exactly how much the software systems have contributed versus all of the other quality-related activities.
But it seems to me that the -- that a lot of the focus of what you're talking about has to do with the ability to have enhancements, the ability to move fairly quickly to integrate leading technologies and things along the lines of how does it work rather than is this trip necessary.
And then, of course, there is the difficulty of harmonization that it is, even globally, a small market. And if you fragment that market into the United States and outside the United States , it's even smaller. And so this is not a good incentive for companies, even companies already in the market to be able to have an attractive business model.
So maybe, Jay, I'll ask you again. If you want these slides, Jay, I can give them to you soon after I write it all down. There seems to be a lot of interest in the possibility of harmonization. But yet, in most other aspects of regulatory affairs, we don't have global harmonization.
And so you know , are we -- are you whistling in the wind here? Or -- I mean, there are many other examples that we can illustrate of different regulatory decisions or even different approaches in the U.S. versus outside the U.S. And do you want to say anything more about that, Jay? Because this seems to be also one of the things that I keep hearing a lot about.
MR. EPSTEIN: Well, I think there's a shared goal of harmonizing because it could facilitate markets. And it makes it much easier for the whole business model. Many of the industries that we deal with are global. It is a barrier to markets to have different regulatory systems in different countries. And we hear all the time from large manufacturers that they would like a simpler world, where it's common set of formats, common set of standards, common clinical trials, common requirements.
But then there are the realities. The realities are, you know , sovereignty, different laws, different practices and precedents. And so the reality is that it's very hard to get there, even if you have a shared goal between countries. So what are the baby steps?
Well, the baby steps are that there have been a lot of initiatives on information sharing. The FDA has information sharing agreements with easily a dozen and maybe more other regulatory bodies around the world. And we're capable of having a dialogue over pre-decisional matters. There are, generally speaking, constraints. In other words, we might be able to share certain protected information but not trade secret information. That might require the permission of the manufacturer.
But those dialogues are helpful because it enables the regulators to benchmark. And it sometimes -- I would say it often, when utilized, enhances our database. In other words, we get information from other sources we might not otherwise get. But in terms of harmonizing the regulations per se, I don't think that challenge has been surmounted.
You know , the international committee on harmonization, which basically was driven by the large pharmaceuticals has made a lot of progress in establishing common guidance and common formats for applications. And FDA uses a lot of these now-globalized formats. That's a simplification that industry has appreciated very much. And it does save money and it does save time.
But -- and then there also have been some success stories with sharing of information, for example , on inspections so that we might recognize or receive the data from, say, an EU inspection. But it doesn't quite get to the point of reciprocal recognition of approvals. And that gets to the sovereignty issue. And it gets to the underlying laws being different. Because after all, each regulatory authority is following the laws of, you know , the country or the EU in the case where they have directives.
And so the conclusions have to be based on the determining factors established in the law. And those are not the same. I can tell you right now that a CE mark and a device approval just aren't the same thing. So what does it mean to harmonize them?
Well, really, you can't harmonize them. You either have to agree on some new set of common standards or you've got one or the other. You know , you could decide to do things this way versus that way. But they aren't the same thing.
Now, are there initiatives in the device area? Well, yes. There is the Global Harmonization Task Force, GHTF, which is a body more or less like the ICH, which is looking at devices, looking at the framework for categorizing devices, looking at the standards for assessing devices, and seeking, ultimately, harmonization in this domain.
But I think that we're a long way from having harmonized regulatory systems globally. That's the bottom line. It's not lack of interest and it's not lack of appreciation for the fact that it could lower the costs of doing business and therefore, speed up, you know , progress. That's perceived and it's a shared view. But actually harmonizing regulatory frameworks is just not imminent.
MR. McCULLOUGH: Great, thank you . Are there things about the discussion or the comments that I made earlier that anyone would like to disagree with or elaborate on? Celso , you disagreed with some of what I said. Yes, Angus.
MR. DOUGLAS: Can I just make a point, not a disagreement. You raised the question of, I think, does it matter if we don't have any large software providers. I think that was your question. And I don't know if it matters or not, but it does have consequences.
It does mean that when the pharmaceutical industry tell us that they feel they can transfer risk on things like keeping up to date on technology, keeping the best staff available for their IT systems, having the necessary backup systems, all that sort of stuff. They can transfer the risk to the providers for that with absolute certainty. That certainty may not be quite as great without -- t hat was just the comment I wanted to make.
MR. McCULLOUGH: Thank you . A couple of the other themes that seemed to me from the discussion today and the four reports are it seems that one of the challenges of this discussion and this meeting is that there are multiple constituents. There are probably more than what I've listed here, but blood centers, large vendors, small vendors, and there may be others.
And probably each constituency has some particular set of issues. And to try to find a way to have a dialogue that would address all of those, and it may never be possible to make everybody happy. But I think it's one of the challenges of Don and Jim at putting this day together and maybe deciding how to go forward from here is to try to find a way so that a variety of points of view and constituencies can be considered coming to some sort of an approach for moving ahead.
And the fourth bullet point on here, process could be improved. Trying to avoid, Jay, asking you to go back to the microphone. But clearly, there is a lot of discussion about how to help vendors and blood centers understand when they need to go back for additional approval -- 510 approvals, what the -- how to speed and simplify the process and that sort of thing.
And I'm really not involved with this enough to -- it's not for me to come up with any kind of solution so much as that I wonder if the communication back and forth between the vendors and blood establishments in the FDA has been as effective as it might be in trying to help understand these things.
Maybe others of you would have some comments about that. I can only ask the people that I happen to know if they want to say anything. They probably don't. But Tim Coburn (phonetic) and I go back a long way. Would you like to add anything to this or anything else that you've said?
TIM: (Off mike).
MR. McCULLOUGH: Don't say no.
(Laughter)
MR. McCULLOUGH: How can the -- how can the process be smoothed not necessarily for the original submission but for, you know , steps to continue to enhance it, steps to put in the right kind of modifications.
TIM: Well, it's clearly -- in our session, we heard a lot of talking about communication and understanding what is -- it appears to be one of the biggest in our -- group is that this -- that the timeline to get innovations out, and validation is a big part of that timeline, and the 510(k) process is a significant part of that. And although eliminating a 510(k) would eliminate a big chunk of time, eliminating QSR or the regulations or the confidence that vendors have in the process is it wasn't well received.
So it's clear that -- from our discussion that we heard that a lot of people like that -- the comfort of knowing the regulations are there to protect them and that not having them instills a certain amount of fear about what then -- is the burden then shifted to them and increasing the amount of work that they have to do.
Those are the types of questions that needed -- need to be addressed and answered. And you know , just -- maybe ISO -- accepting ISO certification following QSR would be enough to -- and subject to vendor's inspection -- vendor inspection by the FDA might move us in that direction.
MR. McCULLOUGH: Thank you . Okay, Marybeth, you're next.
(Laughter)
MR. McCULLOUGH: I was struck by your comment that if you -- if the 510(k) process was somehow decreased, that this would probably greatly increase the workload and complexity of validation, so -- and therefore, costs and everything else. So do you want to -- could you say a couple more things about that? Because it does make sense that there is some trade-off there. See, it's a disadvantage to have you (off mike) .
(Laughter)
MS. BASSET: Well, I don't know what else to really say about it. But the -- you know , the discussion really was around we do feel somewhat protected because there is the FDA that is reviewing our -- the documents before it even arrives into our hands. And there is a certain amount of regulations that have to be followed like the quality system regulations have to be followed by vendors.
Lots of things about design control in there. So from a quality and regulatory kind of professional, there is a level of confidence and some security that when we get that piece of software, that we aren't going to find all the bugs and the kinds of problems that we might find if we didn't have that kind of upfront review happening by the regulating agencies.
And so if we had to do more validation because we didn't have that assurance, we're probably going to find maybe more anomalies, more bugs that have to then be fixed. And that could just all start to drive up our expenses in the organization. We probably right now, internal to a lot of organizations don't have that internal expertise around validations and the kinds of things that you maybe would have to extend yourself into if you didn't have somebody else kind of reviewing on the front end. Is that what you were looking for?
MR. McCULLOUGH: Thank you . Are there any comments? Surely, someone that I don't know must have a comment.
(Laughter)
MR. McCULLOUGH: Well, let me go back through them briefly, just kind of a repetition of what the different breakout sessions supported. But some of these that struck me is -- first is the question of do the regulation, the 510(k) regulations inhibit development. And if so, how? I don't have the answer to that. But we continue to think and talk about that. There does seem to be -- and we've already talked about this now a few times. There does seem to be the general thought that this does slow the implementation of enhancements or new technology.
But -- and also, I'm hearing a pretty good consensus that this has improved the software. A lot of discussion about what can be done to make it easy to -- easier to interface these systems with the other sort of non-regulated parts of the software. And it would even go so far as to -- as whether it could be defined that there might be some aspects of the software that don't impact patient safety the way Jay has described and therefore, might be free of 510 regulation.
The second breakout session also emphasized that this does ensure improved quality, ensures a standardization of processes. And the regulatory framework does provide a stringency to the vendors.
And the third session again seems to emphasize that this regulatory framework has led to improvements. But the question is whether in today, in 2008, whether the regulations are still properly focused and whether the processes are ideal. And of course, I've been hearing a number of times that they may not be.
And the question of whether the current system is an actual barrier to improvements or if there are ways that it can be somehow tweaked so that it can at least not be a barrier but even possibly assist improvements. We've already talked about the harmonization or the segmentation of the U.S. and the non-U.S. markets. And the point, the first bullet point is what Marybeth was just talking about.
So Don, I'm not sure I have anything more to say. But I guess my job was to try to prod people and be provocative. I hope I haven't antagonized anybody and I look forward to tomorrow's discussion.
(Applause)
MR. DODDRIDGE: Jeff, I think what you have done is you have stimulated us all. And as we go to the next room for maybe a little refreshments, we could probably have some further talks. I've been asked by Bob that you do have evaluation forms and that if you would please fill those out and leave them at the table. And Bob and the other members from ABC will be gathering them.
And I think, if nothing else, what we've accomplished, we've got all the players in a room together today to kind of discuss the issues. I don't think -- what we've seen is that the process is broken.
But if there are ways of improving the process, certainly, there can be further discussion. And I hope tomorrow with the two topics that we have coming up, we could further define what needs to come out of this session. But Jim, I think it was a session and it was well worth it. And I think -- and everybody in this room appreciates the effort that ABC has in putting on this session.
We will be meeting for a reception in the Potomac Ballroom, which I believe is on this floor, Bob. And that will start at 5:00. So let's carry on the discussion and also be able to relax a little bit after a long day, especially those that have traveled from the West Coast which are probably still suffering a little bit of jet lag. So thank you and we'll see you again tomorrow at 8:00 o'clock. And at 8:30, the session will start.
(Whereupon, at 4:51 p.m., the PROCEEDINGS were adjourned.)