• Decrease font size
  • Return font size to normal
  • Increase font size
U.S. Department of Health and Human Services

Vaccines, Blood & Biologics

  • Print
  • Share
  • E-mail

July 11, 2008 Transcripts - Blood Establishment Computer Software

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
Friday, July 11, 2008

 

PDF Printer Version (PDF - 241 KB)

   

   


List of Participants:

JIM MacPHERSON
CEO, America's Blood Centers

VICKI MOORE
Haemonetic Software Solutions

DON DODDRIDGE
President & CEO, Florida Blood Services

SHERYL KOCHMAN
Chief, Devices Review Branch, OBRR/CBER/FDA

LEONARD WILSON
Chief, Regulatory Project Management
Division of Blood Applications, FDA

SHELLEY LOOBY
Director of Regulatory Affairs,
Quality assurance,
Cerner Corporation

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

MR. MacPHERSON: Are we on? I'd like to have you take your seats please. I'd like to get started. I know many of you have flights today and we'd like to keep on schedule. So I'll give you about a minute to find your seat and then we'll get started.

(Pause)

MR. MacPHERSON: Good morning. It looks like everybody is pretty much in here. So I'd like to go ahead and get started. We had a busy day yesterday. We had good participation. We had good panels with a lot of good questions coming out of that. And today we're going to have a more perspective approach.

It's time to ask are there changes needed to enhance the state of blood establishment IT and discuss some possible solutions. Our first speaker will do just that. Vicki Moore (phonetic) is with us from Haemonetic Software Solutions. She has -- I'm looking for Vicki, there she is, before I start introducing her.

Vicki has had over 20 years of experience in blood center and hospital blood bank laboratories and 18 years regulatory experience with BECS, including a dozen 510(k) clearances. She is going to share her experiences from the perspective of the first vendor to receive clearance for both traditional and special 510(k) applications. Please welcome Vicki Moore.

(Applause)

MS. MOORE: So, good morning. I'd like to start out by thanking the ABC, especially for having this meeting, Jim and Rodeina particularly, because I know they've really been the driving forces behind getting this group together and I think it's been a really worthwhile exercise.

My objectives today, first to give you some background on myself and my experience, and then talk about our experience with the BECS process and FDA –- the good, the bad, and the ugly, Linda –- the value of the 510(k) process for BECS, and finally should there be a paradigm change.

I think I should start out by saying who is Haemonetic Software Solutions, I'm sure some of you have never heard of that company before. It was formed last year. IDM was acquired by Haemonetics early last year, and in August of last year, Haemonetics decided to merge IDM with a company called -- it used to be called 5D, and merged them together, and so that became Haemonetic Software Solutions.

As Don said, we were the first to do traditional 510(k) and we were the first to take advantage of the special 510(k). So why did we want to be first? It was really a strategic decision. Our strategy was there were medical device regs that nobody knew how to apply to blood bank software or any kind of software, but particularly blood bank software as standalone. And we thought it would be good to get in on that from the beginning and help the FDA define what all that stuff means.

We thought that we could help define a development standard, if you will, kind of set the bar. And we thought within all of that we'd be able to develop a good working relationship with the FDA. We felt at the time that we had -- the software development methodology was far above our competitors. The reason that we felt that was that we had already been inspected twice by FDA before 1994 both by Sam Clark (phonetic) in as early as 1988 and then again in 1991.

I'm not sure why we had this dubious honor but I suspect it had something to do with some of the guidance documents that folks were talking about yesterday. Sheryl's 1988 and '89 documents about computer systems and blood establishments.

I think even more likely though the reason is that we were the developer for Abbott's DMS System and the FDA was seeing that system in lots of blood center laboratories all over the country. So I think that peaked their interest to look at us.

For those of you who don't know a Samuel Clark, he was probably the first BECS expert at the FDA. When Sam came to visit us even in 1988, he said you are a device manufacturer whether FDA says you are or not officially. And he -- both times he was at our place he inspected us with that in mind. One of our 43 observations was that we didn't have an MDR, we didn't even know what an MDR was.

My point in telling you all this is that even before 1994 we had FDA recommended, if you will, software methodology, development methodology in place. Because of that, when -- in 1994 when the call for submissions and they announced that we were all medical device manufacturers, we had to make hardly any changes at all in our technical process.

So that gives me the perspective of knowing that since our technical process didn't change -- hasn't changed since then, that we could be relatively sure that all the things, all the experiences that we've had, had been as a result of the 510(k) submission process itself and not changes that we've had in our technology.

So what changes were –- we needed -- what changes do we need to do for the first traditional submission? Again no technical development process changes. We did have to enhance a couple of documents or design a traceability document and we were actually missing three documents that we needed.

So we worked with Molly Ray and Nancy Jensen who were the reviewers at that time, and created -- essentially made up what the hazard analysis should look like for BECS. And this will be interesting later when I talk about that.

We had to put more detail in our testing summaries and we had to invent this summary report of software development methodology you may or may not be aware of. It's a short three or four page document. It just gives an overview of our software development processes and it's written strictly for the FDA. So it's kind of in a nutshell where you can see what our processes are.

This is a very busy slide as you can see, but it is a history of our 510(k) experience at IDM. The first two lines are the traditional 510(k)s that were the first to be cleared by FDA. You can see they both took over a year, a little over a year -- thank you –- also right here –- both of them were traditional because that's all we knew about at the time. And then in 1998 when the special -- the new paradigm was announced and the special 510(k) and the abbreviated 510(k) became available to us, we got on that bandwagon right away.

If you could see, as advertised it was cleared within 30 days, and then we had a whole string of specials and one abbreviated, all of which were under either the 30-day or the abbreviated timeline. And everything was going on very cool until we get down here in March of 2005 and the June 2000 submissions. And both of these I thought would be 90-day clearances and it turned out that they weren't, they were much longer.

So I thought it would be interesting from our perspective today to look at those two submissions and see what exactly was it that delayed those. We were -- we obviously seemed like we knew what we were doing, I thought we knew what we were doing. And all of a sudden in 2005, we've kind of hit the wall. So again the 2005 abbreviated submission was submitted in March of 2005 and it was cleared in 126 days.

And knowing what our history had been, it seemed reasonable to ask some questions. First, what did change since the last two submissions? Why would these be -- take longer to clear? What were the issues? And then what was the cause of the issues and the delays?

Interestingly, there were no significant personnel changes on either side in this timeframe. The same people were working for me at IDM, same reviewers were at FDA, and they're just -- there wasn't any difference there.

As I said, we have made no significant changes in our development methodology since the Sam Clark era. So it wasn't because we had started doing something differently in our practice. And there had been no new or revised BECS guidelines, specifically BECS guidelines, published in that timeframe.

Then what were the issues for -- every time we send in a submission there, there's a request to clarify some documents or change them, or I usually forget to send something that they need, and you just expect that there's going to be some minor things that need to be done, need to be changed. We expect it.

But I was very, I guess, surprised when we found out that 10 years after developing the hazard analysis format and the contents with FDA, it was no longer acceptable. And then anomaly list, you're going to hear me whining a lot about anomaly list today. We had never submitted a standalone anomaly list in all our previous 10 submissions. A list of major software defects had been part of our hazard analysis document.

And up until this time, that was considered acceptable for that requirement that said we had to have an anomaly list. And then there were technical disagreements. The technical staff at IDM became very frustrated with the reviewers because they believed that the FDA really didn't have the depth of knowledge that they needed to have to understand the discussions that they wanted to have about some of these questions.

And finally, after creating the anomaly list we were told that we had too many anomalies, and that we had to do something about that because our predicate device that we had named had no anomalies, if you can believe that. So for the first time in our experience, FDA required us to correct -- fix some non safety critical bugs. Our experience, our practice had always been the revision that we sent to FDA has no major hazardous defects in it, nothing that's safety related.

But it quite often has nuisance bugs that we know would be a pain for the users and they would raise hell with us if we didn't fix them. So while that submission is at the FDA being reviewed, we typically do a bug-fix revision that hopefully gets done about the same time as the submission is cleared, and then as that second revision they gets released to customers that has all the bug fixes in it or most of them.

But FDA thought that we needed to fix those before clearance. So we actually did that and then submitted version 1.1 for the clearance. And then to top it off, we did that bug fix revision and FDA suggested that perhaps we should rewrite our designs specs because that was why we had -- that might be why we had so many anomalies since, because our design specs weren't complete enough. So we did that too.

Reasons for issues and delays and what cause these issues and delays –- a common theme is that I think the reviewer preferences change. It has been 3 years since our previous special and 6 years since our previous abbreviated submission. So it was normal for the reviewers to change some of their expectations as they had more experience and saw more things and kind of developed in their own mind what some of this stuff should look like.

Some of that usually is minor document changes but we did have some major ones. As I said, the hazard analysis that we had developed with FDA was no longer acceptable. I guess the ironic thing is I totally agreed with the FDA about the changes that they thought we should make to the hazard analysis, but I didn't think in the middle of the submission was a good time to have that kind of activity going on, when it wasn't going to affect the product at all.

And then the anomaly list, the famous anomaly list. You could say, well, we've been getting along without –- getting away with –- not having anomaly list for 10 submissions. So we ought to just be thankful and quit whining. But in any case the rules should be consistently applied and if the anomaly list was okay for those previous 10 submissions, it should have been okay with this one or there should've been some provision made.

We also feel that there is somewhat of a knowledge gap. It's not surprising that the reviewers are not technical experts, how could they be? The technology changes quickly and it's hard to keep up. And besides, we don't ask our software engineers to be regulatory experts. So why should we ask them to be technical experts, if you will?

And although we did win most of the technical disagreements that we had, they can result in a great deal of extra review time and discussion that's really aggravating when you're in the middle of -- when you're waiting for the submission to be cleared.

A submission is only as good as the documents that you send to FDA. One of the greatest challenges of the submission process is to try to make documents understandable and anticipate the questions that reviewers might have and areas where they might be confused and try to head that off by the documents that you send them.

So we struggle with supporting the reviewers from a distant location knowing that it would be a whole lot better, whole lot easier, if were in the same room sitting across the table from each other so that we could actually be showing them these things, and it would expedite the whole process.

Then in May of 2005, as you heard yesterday, there was a new guidance document issued, and a joint document by CDRH and CBER, and it -- although it was released in May –- our submission was in March –- it really shouldn't have had any impact on our submission. But I can't help think that the reviewers were somewhat influenced by that. I'm sure they were involved in creating that document and now they had different ideas of what things ought to look like, like the anomaly list.

We do the same sort of analysis with the 2000 traditional submission that was submitted in June, cleared in 189 days. I think that's about 89 days longer than I expected it to be.

Again, to go through the process of what changed since the last 510(k) which in this case was 2 years earlier, again, we had no significant personnel changes, no changes in our development methodology.

There was the new 2005 guidance document that we now had to work for. And we knew that one of the biggest areas in that new guideline was that we were going to have to start doing our traditional submission again because we were no longer going to be able to abbreviated for new products.

And then there is something I call "wireless hysteria" that was going on at the FDA.

The issues –- we had the usual changes and clarifications, mostly minor things, much the same as we had in the 2005 submission. Again, we had problems with our anomaly list. This new anomaly list that we had created, this new format in 2005, this time they said they thought it contain too many anomalies. It did have a lot of anomalies, but -- and they really couldn't -- they weren't written so that they could understand how serious they were.

So the only thing they could do is ask us to fix them, or we had to rewrite the anomaly list. Well, after many discussions with Linda, it finally dawned on me we were putting all these things on our anomaly list that they didn't want on there, that they wouldn't need to see. When they said, give us a list of your bugs, we gave them a list of everything –- enhancement request, things that would never be seen by the user. We just went crazy and showed them all of it.

So we renewed -- removed many of those defects, anomalies that weren't deemed pertinent to the user, and then we rewrote the remaining descriptions in less technical knowledge so that they could be understood. And that, I hope, is the end of the anomaly list story.

This product that we submitted in 2007 was very large and complicated. In fact, it was a change in intended use to that 2005 product. So, the documentation was somewhat confusing. We tried to present it in an organized fashion but it was difficult to review. In the end, we answered all the questions, and everything was resolved. But we did agree that perhaps we should do some more regression testing, which we did. And we found no other problems with that regression testing.

This has to do with the 2005 submission guidance document again. As I said, we realized that we had to submit a traditional submission, so we had several discussions with the reviewers, several months prior to the submission itself to -- because that's been a long time since I had done a traditional submission.

So we had discussions about exactly what is it that they wanted to see in terms of testing documentation in particular. We exchanged, sent them documents to look at, they reviewed them, they suggested this is what we want. I was just absolutely sure we had that nailed. But they -- that I have really understood what they wanted, but at the -- in the end, that didn't turn out to be true.

And then the wireless and technology communication issues. These ran the gamut from our specifications list in the user's manual to code existence testing.

Reasons for the delays –- again, I think, the reviewers' preferences changed. It just has to –- it's part of the learning process that they see some document they like and then when one comes in the old way, I think, they think, oh, it would be better if you did it that way, with no understanding of how frustrating that is on our side.

I'm an old blood banker. I have to be in control, and I'd like to know that when I send things in it's going to be accepted the same way as the previous one that's -- and that's just not always the case.

One of the examples -- to just give you an example, with this submission we had to reword the safety and effectiveness portion of our 510(k) summary which had been acceptable for all eleven previous submissions. Now, it wasn't a big thing, you know, it took five minutes to do what they asked. But it's just the idea of -- it's never right and you never actually feel like you have your arms around it.

The best example in this communication was with this testing documents that we had to send with the traditional. Again, I was confidant that I knew what they wanted, but when we sent it in, it turned out that they were significantly lacking. And then we had to send a lot more documents.

The good news was that we didn't have to do any more testing. We just had to copy more documents and send them in. But it was still very frustrating because I thought I had foreseen and I had prevented this problem, and it turned out that I didn't, I'd wasted my time.

Clearly, the most frustrating issue we've ever had with the FDA is the wireless issue. Because of heightened awareness of the agency at that time about the potential safety issues associated with wireless, this turns into an unfortunate situation and there was unnecessary delays.

It was complicated and, I believe, worsened by involvement of CDRH. We essentially wasted 4 months creating some new documents and new arguments and additional artifacts that were specific just for the wireless functionality.

We weren't inventing technology here. We were following standard protocols that were used in the communication industry. And kind of the topper was, there was -- the wireless functionality that was in this product was exactly the same as the wireless functionality that had been in the 2005 product that received hardly any scrutiny at all. So it just didn't make sense.

But in the end we won out. Everything worked out, we did not have to change the product at all. Everything was good, but we were in a situation where, okay, we'd won the argument but our clearance was 3 months late, which is not acceptable.

I thought it would be interesting to look at a comparison of what I've identified as the reasons in both of these submissions and amazingly enough they're almost identical. There were different issues that caused those things but with the exception of the new guidance document that was issued in 2005, they are identical. And I could probably be convinced that we should put that -- the new –- the guidance document on the 2007 list too because it had to do a lot with the testing submitted.

I looked at time records and determined what was the most significant time-consuming post-submission work that we were required to do. Clearly, the rewrite of all the design specs, and the bug-fix revision in this abbreviated submission well accounted for the extra 36 days.

With the traditional submission, it was the anomaly list rewrite and reinterpreting all of those defects, you know, a less technical knowledge. And then there's the wireless communication issue, just topped everything, clearly, accounting for more than 89 days.

So the summary of our total 510(k) experiences I've divided into negative experiences and positive experiences. And I'll do the negative first. I think there's a poor communication of requirements or inconsistent requirements. There is sometimes this IT knowledge gap that causes significant delays. And in the end, there's no obvious impact on safety or effectiveness after going through all of this.

There are positive experiences as well. There's no doubt that our user's manual and our development documentation is improved. It's better than it was before the FDA saw it. And the CBER reviewers are great, they're fair, they do the best they can, and we enjoy working with them.

I'm sorry if this comes off today like I'm being up on the reviewers, because that's not my intent. I'm trying to give you a sense of the frustration on the vendor's side and why it is we hate these things.

So what was the impact of the two submissions on the product? Again, improvements to product-labeling and developing documents. The anomaly list, God love it, it's a whole lot better than it was when we started out. We have much better wireless communication specs and information in our user's manual -- our user's manual overall is better. We have more complete traceability documents and our hazard analysis has improved.

Having said that, there was no apparent impact on safety and effectiveness as a result of all of those changes. The hazard analysis looks better, it's more aesthetically pleasing, I guess, it makes more sense. But no new hazards have been identified as a result of that.

Testing -- we're not going to -- no additional testing required after all of that discussion and delay. And the wireless technology discussion –- again, no change to the product after 4 months of wrestling with that.

Knowing that I was going to be here today, I sat down with some of my product managers and QA people, and I said, if FDA says tomorrow we don't have to do -- we don't have to do 510 (k) submissions any more what would you change, what do you want to eliminate?

And I was surprised they wanted to eliminate that development summary report that they only write for the FDA in the first place. But it's just a cut and paste every time so, it's not that big a deal to get rid of it. And they'd still want to write testing summaries, but they'd write them for a different audience. They'd be more technical and but they would still be there.

So if I look into my crystal ball, and say well, what would life look like without 510(k)s, what would be the impact on us and on you –- and in all of this I'm assuming that the BECS would remain classified as a medical device –- the only difference is, from today is that we'd no longer be a 510(k) submission.

If we look at it from the vendor or the device manufacturer's point of view, as I've said, I don't think there's any impact on safety and effectiveness in terms of the changes that we would make, we just wouldn't make many changes.

Clearly, we get the product to market quicker. We would eliminate the rewrite of a lot of the development documents which we do, making it less technical, so that they're easy to understand. We wouldn't do that any more. There'd be no change in our testing, either in the manual testing or in the type of testing that we do.

And there'd be savings of many hours in the post-submission, pre-clearance work, probably some grey hairs and ulcers as well. If I look at it from the blood industries point of view, products and new functionality should be available more quickly.

Then probably, there'd be less clear labeling as the user's manuals wouldn't look as good, and some of the other documents wouldn't look as good. I think, there's no doubt that that is one of the benefits of having those people look at our documents. I think we're too close to it sometimes, so we don't really see the forest for the trees.

I think the most significant effect would be, at least in an initial perception, that products are less safe. That would, I think, cause people to do even more validation testing than they do now, which is a lot. And I think there might be an increase in litigation when the attorneys find out that FDA is not looking at these products anymore.

And then finally, if we look at what would life be like for the patients? Would it have an effect for the patient? And I -- in my opinion, there would be none if BECS remains a medical device.

I feel like there remains a benefit and a need for FDA oversight. But is the 510(k) process the best method of ensuring that safety for BECS? I don't think so, and I think it's time to have a new paradigm. And it might look like this. BECS would remain classified as a medical device, there'd be no more 510(k)s, there would be quality system regulations that still followed all the general controls, and there would be improved field inspections . So, this is really an important one.

We need to have more BECS experts at FDA and in the field. It's a total waste of time when somebody else comes in and inspects us. It doesn't do anything for either side. It's very aggravating.

We -- as much a I dread it, when Sam Clark came the two times and Joan Loreng came a couple of times, we learned things from him and we had good reasonable discussions with him about what they saw. I think, when I look back on what we -- how we benefited from the Sam Clark visits and then visits by Joan, we did learn something and -- sorry, I lost my train of thought -- better inspectors, yeah.

Oh I know -- that when we have these knowledgeable field inspectors come, it has a greater impact on safety and effectiveness I think of our products than any of the submissions that we made.

So with that I'll stop.

SPEAKER: Are there any questions of Vicky? Can you go to the mike please?

MS. KOCHMAN: Sheryl Kochman, FDA. I can honestly say that I can't argue with anything Vicky said. But there are some things, behind the scenes, that she's probably not aware of.

One of the issues with what is perceived as changes in reviewer preferences is that we have access to and we review MDR reports for software. We also have had some of our reviewers go out on inspections. And so, we see things at different firms that we feel others need to be cognizant of in their processes.

So while it may seem strange that we ask people to address nuisance bugs, some of those requests come from knowing that when there are nuisance bugs, the users tend to do things that override some of the things that were good things with the software. Or they tend to want to find the quickest, easiest way to deal with that nuisance, rather than perhaps the correct way of dealing with that nuisance.

And so, yes, we have been probably asking for more clarification on things, for more explanation of things. Again, we do believe that a lot of what we're asking for is to enhance the user's manual and obviously you see some benefit to that.

But it's not that we're just making these things up. We're getting them from real life experiences. And I'd also like to mention the wireless hysteria.

(Laughter)

MS. KOCHMAN: It's not entirely hysteria.

MS. MOORE: Sure seemed like it.

MS. KOCHMAN: There have been cases and perhaps this is why you perceived the involvement of CDRH to make things even worse. CDRH gets reports of all kinds of problems related to wireless. And one of my favorites is that there was a laboratory that consistently had problems with one of their instruments, one that's -- they didn't realize it at first. They would periodically have problems with this instrument, and no matter what they did on that day, they couldn't fix it.

So then they started tracking when is this happening. And they figured out it was always on a specific day of the week. Then they figured out it was always in a specific time range on that day of the week. And the more they trended when these problems happened, they were able to narrow it down to the truck that picked up the garbage.

The man who drove the truck, who picked up the garbage, would call in while the truck was dumping the garbage to let his route driver or his route manager know where he was, and what he was up to. And while he was there, his wireless signal was interfering with the instrument in the lab.

And so, hysteria? Yeah, maybe we overreact, but maybe we need some time to see how bad the problem really is. We know it's everywhere, and we hear a lot about interferences and so my comments.

MS. MOORE: Thank you Sheryl. I don't want to re-argue the wireless discussion. We won that, and I should just shut up.

(Laughter)

MS. MOORE: But our point of view from the beginning was we know wireless interferes with other wireless devices. And so our products were designed so that when that happens, they shut down, they did something that was safe and foolproof. The user would know, and that was built into it. But we couldn't seem to get that concept across to anyone, especially the guys at CDRH for a long time.

MS. KOCHMAN: I also wonder and I'm kind of feeling defensive about turnaround times. The time on the FDA clock for BECS reviews within the last several years has been 90 days or less, period, no exceptions.

And much of the time that people add on to that review time is the additional time that the manufacturer has to spend answering our questions. So clearly, if you make a submission for which we'll have very few questions, your review time on your clock will be shorter, and potentially, the review clock on our time will be shorter, because we'll find what we need right away, instead of having to dig through it.

And there are probably ways we can help deal with that, but I do want to -- I'm proud of the reviewers, they are consistently getting things done by the 90th day. And that's not always an easy task to do.

MS. MOORE: I like the reviewers as I said. They're good people there, they're good to work with. Feel like they are under-resourced much of the time. But you know, I didn't mean to imply that they aren't doing the job. And you need to know that we want to send in the right stuff, if we just knew what that was.

You know, that's the frustrating thing, is I -- you know, I would have bet a lot of money, both of those submissions, that we had it nailed down, we knew what you wanted and then to find out that things were wrong, and that it's going to take weeks or months to get what you want, is just -- it just seems to be a -- there ought to be a better way to do it.

Thanks.

(Applause)

MR. WILSON: Just very briefly. I am Len Wilson. I was the branch chief for the first 5 years of the 510(k) program in the office of blood.

And I just wanted to make a comment about the communications relative to technical terminology. As an example, when the 510(k) program first started, we were faced with 40 different manufacturers, all speaking of their version of IT to us. We were not naïve about IT, but everybody went to a different school just as in medicine. And some of the engineering aspects of discussions can get pretty complicated.

As an example, at one point I had to throw up my hands and say, we want to eliminate the word "validation" from any discussions because it means something different to everyone. And oh, by the way, if you are going to use a technical term, I need you to define it, and use it in a sentence, because it was just chaos trying to get simple communication.

Now I don't think this is FDA s fault, I don't think this is industry's fault, it's technical communication. And I would offer that one of the things that would be very, very valuable is to try to go with as much plain English as possible and try to avoid terms that have been known to have very ambiguous definitions.

Thank you.

SPEAKER: Thank you.

SPEAKER: Our next speaker today is Shelley Looby who is the director of regulatory affairs, quality assurance, at Cerner Corporation. And she is going to speak on the challenges of entering BECS software market. She'll compare the initial challenges of 510(k) submissions, how the process has evolved, and the future of the BECS' market place.

Please welcome Shelley.

MS. LOOBY: Good morning. I have to read the notes here but I do have everything right. I would just like to echo Vicky's thanks to the conference organizers; I know they did a lot of work. And as a vendor/ manufacturer, it's very pleasing to me to see all parties come to the table, the vendors, the users, the FDA. It's encouraging that we've had this meeting, that the discussion has been open, and I think it would prove to be very, very, useful going forward.

These are the objectives I'd like to cover today. I'm not going to read them. I'll go through them as we go through the slides. So in 1994, Dr. Zoon's letter dated 3/31/94 to the blood bank software vendors turned many worlds upside down. Many of us who are members of trade associations, AdvaMed for example, knew what was coming. But to be honest with you, there's something about seeing that printed in black and white.

Overnight, for many of us, all our little IT shops became medical device manufacturers. We have a decision to be made, to remain in the market. And that we would -- we were going to be subjected to the device provisions of the Food, Drug and Cosmetic Act, and FDA's device regulations including establishment registration, product listing, pre-market notification, 510(k) approval, CGMPs and adverse event reporting.

So in the famous words of the group, Clash, "Should I stay or should I go now." For Cerner, it wasn't easy if not burdensome and an expensive decision. We had approximately 275 clients who were running our donor and our transfusion medicine software in production environments. Couldn't really just walk away at that point, in our opinions.

It also did not support Cerner's vision or mission to leave the marketplace, as our focus was on clinical automation, was solutions offered across the care continuum. So we weren't willing to walk away from the blood banks to transfusion services, because of the 1994 letter. At least not right away.

In addition, we were actively marketing these solutions, both in the U.S. and outside of the U.S. So we had already established a prospective client base that we felt, it was not fair to have, you know, approached them, marketed and try to sell, and then have to withdraw that.

Lots of challenges, when that decision came forward. First was the initial 510(k) submission. As was discussed yesterday, what were we going to use as a predicate? And that we really didn't know. We had a lot of questions in this area. Formats, you know, what format would be acceptable to the reviewers. Can this be done without reformatting all of our technical documentation?

It was very pleasing for me to hear Linda talk about the fact that she likes to look at what we look at, and we have had conversations with Linda on the phone. I have an engineer in the room and we walk through that. And that's very helpful. We don't send them many FDA formatted documents. They get what our engineers use, what our validators use, what the regulatory affairs folks see and use. They get what we produce day in and day out.

And we really feel that that's the only way they're going to understand what it is we are doing. But initially we didn't know if they would really understand what our documentation was trying to tell them. So we struggled with the format issues.

We also struggled with the content. We were unsure as to what was going to be required for proof of substantial equivalence to obtain clearance. I have the printout which I know you can't see, but it's from (italics) Device Advice and it's a wonderful, at least in my opinion, information, group of various pieces of information about pre-market notification 510(k). Gives you an introduction what is substantial equivalence, who is required to submit a 510(k). Oh, if only I'd had this back in 1994, I would have been so smart and so confident that we were doing the right thing.

But I have it today and we use it frequently. It's a great teaching tool when I have new people come in that are going to be involved with submitting a 510(k), whether it be to CBER or CDRH.

The reviewers' guidance was also a huge boon. We understood a lot more than about format and content, but back in 1994, we were struggling. We were making it up as we went and we were trying to figure out what the FDA wanted, they were trying to figure out what they wanted from us, and working back and forth. Giving the reviewers guidance put together was very, very, helpful.

So the challenge was initial 510(k), but at Cerner you're always forced to think –- 2 years down the road, 5 years down the road, 10 years down the road, we didn't believe that this was going to be a one-shot deal. We knew there were going to be future submissions. And as you can see, technically a new 510(k) is required every time a legally marketed device is changed or modified in a way that could significantly affect its safety and effectiveness.

How do we apply that to software changes? Software manufacturers as you well know make numerous changes to their devices every year, to address, both fixes and enhancements. So then what constitutes significant change in the eyes of the agency that would require us to submit new clearances?

Then the challenge was, if we keep submitting new clearances, are they going to be able to keep up. And so it was a challenge on trying to think forward and figure out how we could make all of this work.

In addition, becoming a medical device manufacturer, we were going to have to comply with the current good manufacturing practice regulations.

Now, the QSRs. Non-compliance allowed agency to view the software as adulterated or misbranded, making its distribution illegal under the Food, Drug and Cosmetic Act. Obviously this is not where you want to go. If you've already got 275 points on production software, and you have other people waiting to get converted, didn't want to face enforcement actions which bring a whole another trail of tears, and can allow all these things to happen.

So it was a big change to Cerner, because it didn't just affect our blood bank team. They were going to have to follow the good manufacturing practices et cetera but it also affected our validation group, implementation team and support staff.

Because we don't make just blood bank transfusion and donor software, we make many other types of software, we have individual groups that will do design, development, then outside of say, that blood bank review, we may have a group that does validation of a variety of different types of software, may do implementation of a variety of software and support of a variety of different types of software. So we had a huge education issue, because we were covering a large number of associates who are now considered medical device manufacturers.

Inspections –- that was going to be something new to us. We had had one previous inspection prior to 1994 and it was –- went very well, we had –- we did not have same people as Vicky did other than Dave Ferguson who was at our site several times and was a software expert and that was very helpful because he did understand our technical jargon and even though we had a cheat sheet that –- we tend to speak in mnemonics at Cerner, we had a cheat sheet for in the setup we say this mnemonic this is what we mean and we have given it to all of our investigators and it's very funny now, because they come in, they pull it out of their pocket and they immediately start speaking Cerner lingo.

But the fact that we were going to undergo routine manufacturer inspections was going to affect our day-to-day operations. And it was something we had to consider going forward.

I went back and looked and we have a variety of associates involved with each and every inspection. It's obviously the engineering folks, the clinical validation folks, the technical validation folks, the implementation team and support staff, who, you know, take the calls and answer questions from the client as well as RAQA and executive management, so that there's a lot of people involved in inspection.

The average number of days, FDA is at Cerner for an inspection is 6.2 days. We have had eight inspections at our world headquarters location since 1997, and three at other Cerner locations and that's been since the inception of the quality system regulations.

The other thing that we were challenged with is that our blood bank clients were now going to be having additional scrutiny when the FDA came to their sites as they were going to be looking at their clinical software. And while we didn't probably anticipate this very well, we quickly came to he realization that when the FDA walked into a client's establishment, they were getting on the phone with us saying, okay, I need you to stand by because I may have a question about this and about that, and, the FDA is here and I really want you to help me.

And of course we wanted to help them, and I have, to be honest with you I've had several conversations with field investigators who've been at client sites and they've introduced me over the telephone and we have answered questions and they have had, you know, mainly technical questions about the software, some of the –- some labeling questions, but we were just quite shocked when we got that first telephone call, and somebody said to me, "Shelley, the FDA's here." "Okay. Are you in the room with them?" "No." "Then why are you whispering?" "Oh, yeah, oh. Oh, yeah."

(Laughter)

MS. LOOBY: "I am calling because they're here and they have a question, I don't know if I can answer it. Will you be around?" And so it was just –- it was something that we had anticipated, and I can certainly sympathize with them because I know exactly how that feels, oh my God, what if they answer (sic) a question I can't answer.

And that was something else that we had to train our associates form is that, you know, the FDA will be coming here and they will be asking you questions. Please, if you can't answer the question, tell him you don't know the answer, but you'll go find somebody who can answer the question. It's absolutely okay to say, "I don't know." And it was okay for the client to say, I don't know, but I am going to put you in touch with my vendor and they will answer the question for you.

We also realized that we had to do some client education around the fact that they were going to be working with an actively regulated device. And which is, you know, just another part of what we had to take on.

I think one of the biggest challenges we've had was not so much the 510(k) –- well we've had –- we had initial challenges understanding what it was they needed, what we wanted to send, and everything that was required. We have got an excellent support from the FDA and we too have had our bumps on the road with the wireless thing, and I think we've gotten that figured out as well. We've put a protocol together for all devices that Cerner does, for that.

But for us I think the biggest challenge not only getting into the market but remaining in the market is the post-market surveillance activities. It's a requirement for all medical device manufacturers. We have a complaint filed, we have to file MDRs. It may have removals and corrections and recall. And this I think that we didn't really, truly appreciate. We always had had a complaint file and we've always kept it, long before I even got to Cerner.

But it changed quite a bit once we became an actively regulated device. Cerner has recorded, investigated, performed, corrective and preventative actions, for 162 complaints related to our blood bank software since 1994. We have a 12-page work instruction that supports our standard operating procedure, that supports our corporate policy on how you handle complaints.

And the complaint manager that works for me has been called lots of names. She's very particular about what goes into those records, has to have a lot of information in there, the chronology of the events, she's very, very particular. FDA reviews these every time they are in. We have never had any problems with it. I know that we have pushed back from associates right and left on this, but it is something we are absolutely adamant about, have to be perfect.

And it takes 15 pages of word constructions to get what we need in those complaint files. Of the 162 complaints 6 of those met requirements for filing as a medical device report and 5 Cerner considered and handled as class II recalls.

So there's additional work from a complaint file if you bump up and then you have an MDR and there's more work involved. And then if you have a removal and correction or recall there's additional work. So you have to make sure that you want to make that commitment, going forward with this actively regulated device to handle all of the reporting.

I mentioned the client obligations. It was up to Cerner, in our opinion, to help educate the client base that they were going to have some obligations as well with this new responsibility as using actively regulated software.

We wanted to make sure they understood the new requirements and their effect on us because it was going to change how things were done. We were going to be slower, we were going to require more documentation, more information from them when it came to, you know, a complaint. They had a responsibility to report themselves. They had to understand software system validation, the acceptance of increased cost of the device, and the support of the device, initial price of the device and support the device, acceptance of increased time to market, acceptance of fewer choices of manufacturers and devices. Because, while Cerner decided to stay in the market, as we heard yesterday there were several manufacturers who did not remain.

So I think overall, the challenges for us entering the market really come down to -- we had a huge lack of experience when 1994 hit. And we also had a -- while we had a lot of processes documented and everything was pretty much in place, the compliance, the strict compliance to it across the company because it wasn't just the blood bank team in our situation, it was probably one of the other big challenges.

The challenge to enter the market, as I said, for us was relatively easy, easy decision. The true challenges came in deciding to remain in the market. To be honest with you it is -- it's a very small percentage of Cerner's business. It's an important part of the business. It was commitment to those folks that allowed us stay there.

But the challenges to remain in the market clearly are the resources. We feel you need experts in Cerner to make sure that the product is valid. So that means we have to hire blood bankers. And don't have a problem with that but you don't just go out and find a blood banker here anywhere that's, you know, willing to come into a medical device manufacturing house, an IT house.

Time –- this all takes a lot of time. And as you all know time is money. So it eventually comes down to money. Do we want to -- is it good return on our investment to remain in the market? Today, Cerner is in the market on our classic software for both transfusion and donor, those are clear devices. We have had clear devices on our Millennium platform although we are no longer remaining in the donor area with our Millennium software.

But it was a challenge that we decided to take. We're still there. And I can comfortably tell you that we're not making any future changes with regards to staying in the market. And we are trying very hard to do what is right for the clients.

Cerner is also an ISO 9001:2000 and 1345 certified company. So that has, I think allowed us to use a lot of lessons learned with compliance with QSRs, to adhere to the standards for all of the company and it's not just our software, it's our service portion or ASP portion, everything is ISO certified.

Our challenge truly today is making sure that not only do we stay up with compliance with FDA regulations and compliance with ISO standards but we're dealing with the global situation as well. So we have regulations that we're dealing with in Canada, Europe, Australia –- you know the Mickey Mouse trail of M-i-c-k-e-you know, –- FDA, TGA, NHS, I mean the list is ever-growing, and the challenges to remain in the market for any software remain quite large and quite expensive.

Thank you very much for your time.

(Applause)

MR. DODDRIDGE: Are there any questions for Shelley?

She said wonderful since she answered all your questions. So Bob, will you come and -- while Bob's coming up to load the computer here I'm going to introduce our next speaker.

We are happy to have with us today Mark Weischedel who is the senior vice-president and chief information officer of the American Red Cross. Mark will give us a basic understanding of the history, successes, and limitations of the Red Cross BECS system. He will also provide the Red Cross perspective on the barriers to adopting new technologies on integration with third party software under the current regulatory scheme.

Mark?

MR. WEISCHEDEL: Okay, thank you Don. And Bob, I'll keep things going while you do your magic here.

It's a real pleasure to be here today. And before I get started on the overview of the Red Cross and our experiences with BECS I'd like to thank the conference organizers, the speakers, and fellow participants from blood banking, the vendor community, and the FDA for a -- yes, -- I'd really thank everyone for a dialogue that I think is very valuable and long overdue. And for my part I've already gotten a lot of value out of the last day, plus and I look forward to continuing that and I hope we do.

Right, so our objective is here to share our experiences and provide some perspectives on the current BECS regulatory scheme. I'll be speaking first on behalf of the American Red Cross and then later, most of my comments in terms of sort of, outlook, going forward, are relative to the industry as a whole.

So first, I -- there's no way to introduce the American Red Cross without, you know, sharing or reminding everyone that we are part of an international movement that's called the International Movement of the Red Cross and Red Crescent Societies. It's made up of three types of organizations, the International Committee of the Red Cross that is basically the owner, if you will, of the Geneva Conventions and provides our relief efforts in the areas of armed conflict; International Federation which is a loose federation of National Societies and there are about 181 National Societies of which the American Red Cross in one.

We are chartered by the U.S. Congress. We are not funded by the federal government in case any of you may be wondering about that common misconception. We have many diverse lines of business, but the way that I tend to think about the American Red Cross as a whole, in particular from a technology perspective, is to think about the different operating paradigms.

You all know the blood business and know it well and you know that it's a business of constant demand, a high control imperative, a public health imperative, to provide a safe and adequate supply of blood. And we can never go a day without supplying blood. It's about as highly structured a business as I really can imagine.

Contrast that with our disaster business which we do both domestically and internationally. And the easiest way I try to describe it is that most of our chapters –- there are 740 of those –- most of those on most days don't handle any disasters at all. And those that they do handle typically tend to be single-family fires and those kind of things and that kind of scale.

After Katrina, we helped –- in a 6-week period, we helped nearly 2 million families with -- in response to that disaster. There aren't too many businesses I can think of that have that kind of variability and scale. So we have in scale –- also a word you'll hear me use a lot –- we have problems or challenges I should say, of scale, in many dimensions.

So our volumes you're probably familiar with, we collect about 6 million units of blood and about 770,000 platelet donations from almost 4 million volunteer donors. We operate through 35 blood services regions around the country, and we operate 5 national testing laboratories.

From an IT perspective, our customers are a combination of certainly, our employees and volunteers. We have, once again, many of those, about 35,000 employees, about 600,000 volunteers, although the volunteer field force changes. And as you might imagine, people sometimes volunteer on a regular basis, if they have the time to commit on an ongoing basis. And they may volunteer spontaneously in response to a disaster or something like that. So that's an ever-changing part of our workforce. And then, of course, we have the American public through our web presence, online training, and many other services.

Geographically, we're represented in every state of the country as well as U.S. territories. And we operate in military stations around the world, and once again we have 35 blood regions and 5 testing labs. The IT services you can get a feel for what we do.

All right, so moving on to the BECS history. The -- our history, I guess, of the blood business started in 1940 with the pioneering work of Dr. Charles Drew. Now there are a lot of former Red Crossers here in the audience. Would it be inappropriate for me to ask for a show of hands, former Red Crossers? Mary Beth, would that be inappropriate?

MS. BASSETT: (Inaudible.)

MR. WEISCHEDEL: Yeah. Show of hands, former Red Crossers. Yeah, fair number. So some of you could probably -- could give a history lesson better than I can, but you have invited me here to do this so I'll share with you what I know. And ask you to be gentle with me if I get anything wrong and talk in terms of the early history.

But you know I'm sort of a new guy. I've been with Red Cross almost 5 years but it's still not unusual for me to run into people who can talk about, you know, the early, early, days of blood banking in the Red Cross. And I swear, some of those old blood bankers worked with Dr. Charles Drew himself. And I'm not sure of it, seems that way.

So really, I would describe the early days as a part of our grassroots heritage. The Red Cross started as a community service kind of an organization. There was at one time, upwards of 3,000 chapters across the country. Blood banking was done in those chapters as a community service. So while we operated under a single certain brand, at some points under a single license with the FDA, at some points, including now, under a single management structure.

But our heritage is a series of more or less independent blood banks and that technology followed with that. So prior to the early 1990s, essentially all IT was local. During the Elizabeth Dole era many of you remember, many of you were part of this, there was an effort called "transformation." And that resulted in among other things segregation of the blood business from the chapter and other businesses of the American Red Cross. And a component of transformation was a program called MACS which stood for Manufacturing and Computer Standardization.

At that time we operated somewhere around 50 blood regions and one of the, sort of, common threads since the early 1990s that continues to this day is a strong trend toward consolidation and standardization. It's essential to our industry and I would say if there's one thing that I clearly support is you know through all of the day-to-day things and distractions and complexities that I think is important for our organization and that it's important for our industry, is standardization, so that we can interoperate, we can make changes more rapidly, we can assure a greater quality and at some point we can achieve some benefits of scale economies.

So that trend has continued to the point where we operate what was about 50 blood centers to, at the time that our National Biomedical Computer System, the outcome of MACS went live, we were down to about 40.

Now the -- I don't know all of the process that went through -- that the organization went through to select the software, but I do know the software that became our National Biomedical Computer System was purchased from a vendor, not licensed, but purchased.

That software was modified and adapted to the needs of the American Red Cross that are different, they just are. We have a National Deferral Donor database, we have -- we operate in regions that are expected to be standardized, but that have some local autonomy. And that drives all sorts of different things that tend to be non-standard in our organization or at least that in those days they certainly were.

So the decision was made to essentially customize software. We can all look back and we can say, well, that was a good decision, that was a bad decision, but that was 15 years ago and we -- the reality is, in our case I'd say -- I'd call it a pretty unfortunate reality, the software that was chosen and modified in those days is still what runs our business today. And that's a real concern for us because it's pretty outdated technology.

So 1992, 1993, is when that decision was made and when development started, 1994 is when the FDA made a policy decision to govern, to regulate BECS as medical device.

So, as I understand the history, the team that was busy getting this program up and running, which by the way not only is part of transformation but also was a requirement of Y2K, so we had some hard deadlines in terms of when that needed to be done, so I suppose the team did what they needed to do to develop a 510(k) because that was the new standard, submitted it; ultimately did obtain clearance.

But that was a new thing. And I know from my days of developing software that you develop things in a certain way and you document things in a certain way. Many of us who started technically, know that developers are not really all that fond of doing documentation.

So if you don't have standards, you know you may not have exactly what you want. And the organization had to adapt to that at that time. And some of that documentation once again is still documentation we have in place today because that's the software that we developed.

So there was a period of time after MACS was successfully, I suppose, completed, in 1999, in time for Y2K. There were a series of consolidations of blood regions which quite frankly had some problems. And we had some problems with merging donors and identifying duplicate donors and all of this sort of algorithms and so those kind of things that you need to ensure that you've got the right documentation and the right history for donors that prior to that were viewed as being different, we sort of hit a wall, quite frankly. We did some mergers and had some problems, decided not to do that, going forward. So we sort of froze.

And there were some agreement with the agency that we weren't going to do anything unless we did it in a very, obviously, in a very safe and high-quality way. And we had some real constraints with the design of the software in terms of our abilities to do that.

So we're essentially frozen, if you will, on a 36 database structure that was developed, basically implemented in 1999 or early 2000 and so forth. And it's not really the structure that we operate our business with to this day. As standardization and consolidation marches forward, structure of our business has changed that –- everybody's business changes, but we are sort of stuck with that old structure.

So fast forward to a series of releases that were done, some of them done very well, the biggest of which was a release that collectively involved changes to about 15 different systems, in addition to the -- our National Biomedical Computer System. This release was so large that it was required for us to implement West Nile virus testing, that we sort of considered it kind of like the mother of all software releases. We actually aptly named it the "Clara Barton Release." And the people who were involved in that take great pride in being able to accomplish that. And it's the last really major release that we've had in software several years ago.

We've implemented a collection software, we use health care ID, what we call our electronic blood donations record. We'd like very much to go paperless, we are not yet paperless. And one of the big successes that we had throughout the early years of the 2000 decade was getting through our Test Results Management System. And I'm going to cover a little bit more of that because I think it's particularly germane to some of the challenges around BECS.

Finally, if you look at the lower right-hand side of the slide you'll see a COT strategy. So you know after many years of trying to get NBCS to meet our needs and to adapt to the changing needs of the American Red Cross business it became pretty clear to us that we were dealing with technology that was outdated, and making incremental changes to that technology was a massive undertaking. It's in many cases easier to start over, probably more economical to start over, probably best for safety.

We also made some of these decisions around the business that we wanted to standardize with industry that we didn't want to be different from everybody else. And we think that's in the best interest of the industry in general. So we adopted a COT strategy. And as you all know when there aren't very many offerings on the marketplace a COT strategy is pretty difficult to execute. And that's the situation we've been living with ever since.

We did not have a 510(k) clearance software package that would meet either our functional requirements or our scale and performance requirements. And we're emerging I think –- the industry is in a much better place now than it was in 2001-2002 timeframe when we did the study. But we're still not there yet. And we've had a lot of challenges with performance and in particular the approach to having a single database across the national Red Cross system. And that which we are now revisiting in terms of having all over the safety features of a single database without actually having to have a physical database and we're working with our vendor partners to come up with the best design to approach that.

All right, so RTOMS test results management system started with consolidation and standardization of our testing labs which again was a huge success story for the American Red Cross. We had, I learned at dinner last night with a colleague, that we had at one time somewhere around 50 blood testing labs that were consolidated down to I suppose it was about a dozen. And we're now down to five. They run common instruments, common assays and common procedures. And it's -- it is again a source of great pride and a source of great operational efficiency for the -- for the American Red Cross.

The technology side of that didn't come easy I'll tell you. We started with -- we had a package called DMS, some of you might be familiar with DMS, ran on HP1000. I never heard of an HP1000 until I joined the Red Cross. And we had a tough time keeping that thing up and running for a while.

So we had urgency at every conceivable level. We were out of testing slots and we knew that there was more testing that needed to be done. We had operational stability issues as well as having regulatory issues because the DMS was outdated software. We didn't know all the 510(k) ports, so there were limitations on what we could do with that.

So we opted to -- we chose the IDM Surround software package through a series of many, many releases and project phases; ultimately did replace DMS in several other medical device packages with essentially a single central instance and multiple five national testing lab instances of Surround.

So now some of the challenges that we had do relate to BECS and they do relate to the regulation and our COT strategy, because essentially we have requirements that are unique. Certainly, we have requirements of scale. Now, "scale" is sort of an easy buzzword but you know what does it really mean?

Well, when you take our scale and you add the unique footprint that we have in terms of the relationship between our testing labs –- which again, bear in mind would be changing, so we started with 50, we went to 10, we're now at 5, who knows how many we'll have a few years from now –- right, so the relationship between a laboratory and a blood region –- and again bear in mind that our NBCS, our National Biomedical System that runs all of our manufacturing and collections and so forth, we have 36 of those and now we have 5 testing labs. And we need the resiliency so that if, let's say we had a power failure in Detroit some months ago, and we need to be able to recover and do testing from one laboratory to the next, the relationship is complex.

So we introduced something into the software that didn't exist before, required –- I believe it did require 510(k) –- Susan or Vicky could clarify that, it's been a few years –- called the central repository. So we had our architectural landscape connecting our testing labs, our corporate data center, and our regions just as different from what anybody else in the industry needed and different from what anybody else did, and we needed to adapt the software to do that.

Now we don't want to customize software. In fact as a policy I'd say we don't really truly customize and modify COT software. We need the vendor to do that. And the vendor of course is not only servicing the Red Cross, they're servicing all of their other customers. When the Red Cross needs a vendor to do something we stress –- we call it "stress," –- on our vendor's resources. We recognize that. Nobody has unlimited resources.

And the -- this technology is complex, the business is complex and there's only so much of that expertise to go around. So these are some of the challenges that we've had with our TRMS system. But I'm very happy to say that that program is done and has gone very well.

So in terms of the strategic questions that we face, like any large IT enterprise we face a number of decisions and those decisions have what I like to call "long tails." You live with those for a long time. So in the early 1990s somebody made a decision what to do with our national, you know, collections, manufacturing, and distribution software that we call our National Biomedical Computer System. We're still living with that decision today. Decisions that had been made over the past several years are things that we'll live with for 5, 10 –- who knows how long, technology does change fast.

But the blood banks, in particular, because of the demands on control and quality don't change, don't adapt quite as fast as the field of technology does, so we face all of the "make or buy," whether to do enterprise or line-of-business systems. And given that we have five different lines of business there is a tendency and under some regimes we've tried to standardize across disaster services and chapter environments and blood and those kind of things. And you can imagine with changing regimes and priorities and strategic programs how those kind of decisions might come and go over time.

You know we have to select whether (inaudible). I don't know that the BECS regulation is good or bad but I would say there's an influence. Clearly, how medical device software is bounded –- where the boundaries are and what the scope is of a medical device has relevance. It has relevance in terms of both, regulation as well as how you can integrate and what you can do with that software.

I asked –- during the breakout session I facilitated yesterday I asked of our software vendors how do you determine the boundaries of the medical device. Because, ultimately, that has a big implication for the footprint, it's going to occupy in our blood centers. And you know, quite honestly, I mean, as you might expect –- I mean, the vendors compete and so forth and there's no single right answer to that, but I think it's something that would be worthy of further exploration for our industry to try to see if we can get, for one thing, some industry input in terms of where those boundaries are and make sure that it's meeting all of our requirements.

So the regulatory implications affect strategy in many, many ways. I don't believe there is a single right or wrong answer. I wouldn't advocate for a change or deregulation of software or something like that at this time, but I think change is certainly something that is needed for our business.

So the challenges of the regulation are well-known I think to all of us. We had many expert speakers over the past since yesterday that had dealt with these things. I'm not sure that I'll add much other than to what I have on the screen. What I will identify is a few things that I think are noteworthy that maybe haven't gotten a lot of attention in our discussion so far.

The technology trends toward agile methods, services-oriented architecture, software as a service, cloud computing, certainly, mobile and wireless technologies. These are things that may have implications in terms of how technology evolves in our industry, given that our industry is heavily guided and constrained by regulation.

I don't want to say that regulation stops you from doing any of those things. I don't think it does. But I don't -- these things aren't all done in our industry today. We don't have, to my knowledge, any large-scale software as a service offerings for BECS as an example. We don't have large-scale BECS that's 510(k)-cleared that uses web services technology as an example. So it's hard to say how the regulations might affect that.

What I would say is that a partnership with industry will be, I think, very beneficial to allow us to find those answers and to position the way the regulations are evolved and apply to continuing technology change.

All right, so there have been many discussions. Obviously that's why we are here. And a dialogue has, I think, been enormously valuable to hear from the various viewpoints of many blood banks and vendors and the regulators. If we are to make significant change, and I do think change is a necessity, my take after about 5 years working with the Red Cross and now just a few months as a CIO, is that our industry is behind in technology, our industry tends to be for a whole variety of reasons slow to adapt, and technology is at present, by my thinking, accelerating in terms of pace of change. After the client-server period of the '90s and after the early days of web, what we are now going into in Web 2.0 is a significant change in technology as well as changes in vendor consolidation and outsourcing and many other transit effectives.

So while the pace of technology quickens, and while we have -- that therefore presents significant opportunities for our industry, the question is, are we well-positioned to take advantage of those opportunities and advance the state of technology. And I would say, right now we have some work to do. I think we have a significant opportunity.

So what I would suggest is a three-way collaboration in some form, and it can take many forms, between the blood establishments working in concert between the technology vendors and the FDA toward some clear commitments. And I'll get to my ideas in a few moments, but I'd certainly like to hear everybody's ideas because this is about what's best for the industry.

So what I would advocate is a commitment, three-way commitment to advancing the state of technology in the blood industry. Some examples of that are I would encourage modular and open architectures. I would develop, promote, and eventually enforce standards, for interoperability and data exchange. I would facilitate software development and entry, and yes, including the big players.

I believe there is role for the big players, not that necessarily they need to be the BECS vendors, but in our case, scale matters, and in many of your cases it does as well, and having a very, very reliable robust technology that exist in many, many layers of an architecture for any given solution.

The big players provide a lot of that technology and allow us to take advantage of what's happening in the rest of industry, so that we are not necessarily insular and limited by just what our BECS vendors alone can do. So I think that that should be a part of our equation going forward.

I'd like to see the pace of new technology adoption accelerated. My sense is we're getting better, but we have a long way to go. And as we can -- as we proceed to try to take advantage of new software models like SOA and web services, and new deployment models like SAS and cloud computing, then we take advantage of many of the efficiencies and economies of technology development in the long term.

One of the things that strikes me, I've learned a lot in the past -- yesterday and today, around the various conceptions or misconceptions around the quality system regulation and 510(k). And I would welcome again in a partnership, shedding some light on this to what I would call demystifying the 510(k) in quality system regulation.

We've heard that there have been new entrants in the business that have sort of gotten it right in the first time. So it can't be that hard, right? At least, I believe that many organizations have now sort of mastered this, but to many blood establishments and some of the vendors, it continues to be a struggle.

And there are many different things that are misunderstood, and it to me takes on sometimes the air of a black art with very specialized expertise and interpretations, and I don't think it needs to be. So I think clarification there is important in many ways.

So that's a mouthful, that's a lot, and we've all had many ideas and you have to start somewhere. So what I would recommend as a place to start, and certainly again open to input because this is about what's best for the industry, is to start by establishing a forum.

Now, we have many. Somebody said something about the ABCs of, was it Shelley, the ABCs of our industry or something at the regulator. So how about these ABCs; ABC, AABB, ISBT, ABO, and I'm sure there are many others.

So well, I would suggest we pick one. And then let's find some interested contributors, and I'll raise my hand and say the American Red Cross is an interested contributor. And we look forward very much to working with the rest of industry again in a three-way partnership to progress the state of technology in our industry.

Some places to start, perhaps could be developing a manifesto in terms of what our statement of intent is to guide the direction of technology in our industry, and then some kind of working agenda. Set up some working groups for planning, education, and standards across our industry, and then set up some communities of practice, so we have the ability to socialize and share best practices across the organizations and we can all learn from one another.

Our work with the FDA to prioritize, coordinate, and then develop some of the improvements, and again some of those are things that we've mentioned, some things that have come up with lots of good ideas. I don't claim all these are my own, but the things I like would be to -- certainly to facilitate BECS integration, and to recognize standards, so that if the industry works hard at defining standards, then we need the FDA to recognize those so that it can streamline adoption and approval from a regulatory perspective.

And certainly recognizing good industry practices, so we can sort of facilitate what is good from an agency perspective in terms of quality and safety. So those are the suggestions that I'd have in terms of our places to start. And again I'd like to thank you all for your time. And I'm happy to take any questions.

(Applause)

MR. DODDRIDGE: Do we have any questions for Mark?

SPEAKER: I think perhaps an opinion?

SPEAKER: I have no opinions. I like this approach. One of the things I think that might be intelligent to do is make sure we include a broad spectrum of blood banks, because steps that might be good for like you and I, and may be New York might be using a sledge hammer to kill a fly for some of the smaller blood banks. So we have to consider adaptability, would be my only suggestion.

SPEAKER: And I had a feeling it was an opinion, but those are -- thank you, John. I certainly agree, yeah.

MR. DODDRIDGE: Any other questions? Thank you, Mark.

MR. WEISCHEDEL : Thank you.

MR. DODDRIDGE: All right, the last speaker of the day is Mary Beth Bassett, who is the vice president at Quality Management, Regulatory Affairs and Blood Systems. In her position, Mary Beth is responsible for the development and execution of all quality and regulatory programs, for UBS, and Blood System Laboratories, and the Blood Centers of the Pacific.

She will get BSI's large system perspective on BECS regulation, and present some questions for further investigation. Please welcome Merry Beth to the podium.

(Applause)

MS. BASSETT: You know, I never know whether it's a good or a bad place to be as the last presenter of the day. And put that on top of being a last presenter before a break. So I have a bit of a double whammy, I think, to overcome.

You know, it has been, as the other speakers have talked today, a really tremendous opportunity for us to get together from industry perspective, from FDA's perspective, and from our vendors to share ideas and our concerns. And I'm really very excited and looking forward to what might come out of this, what we might look forward to in the future.

So today what I'm going to do is talk to you a little bit about blood systems, experiences, and challenges with our computer systems. I'll talk to you about our automation, the history of blood systems, blood establishment computer systems, some of our current configuration, and the challenges that we have experienced, and then give us some ideas and food for thought looking into the future.

Most of you know a lot about Blood Systems, and who we are, and how large we are, and where we operate, and how we're structured, and who our bosses are? So -- but I thought what I would do is give you a perspective about blood systems around our automation. We have 14 blood centers, and out of those 14 blood centers we have two blood establishment computer systems.

Our UBS centers use the MAK-PROGESA system and our California Centers use the Wyndgate SafeTrace system. We have two testing laboratories, and we use one BECS for that and that is Mediware and LifeTrak. On any given day at any given time, we have about 2,100 staffs that are using those systems. We have nine 510(k) approved or cleared devices in use or are on our horizon.

We have 16 standalone non-510(k) approved systems, and these systems are used to manage the information and data for about 1.5 million red cell collections annually. And of course the transaction of information from all of these systems, it occurs frequently and at a very high volume.

A little bit about our history. In 1983, is when we first implemented a computer system to automate our manufacturing process. And it was home-grown, we developed it ourselves, and it was called PBOS. Then in 1994, as we've heard during this conference, this is when we had these devices of ours that were now going to be regulated through the 510(k) process.

In 1996 was the year that blood systems went under the consent decree. So that is the year that we made the decision that we're no longer going to be in the manufacturing or into the -- to making our own internal software. So we know that there are experts that do that. And we had a lot of other things that we need to focus our attention on.

So we spent the next three years and had lots going on, but we implemented three 510(k) cleared computer systems. In February of 1999, we implemented SafeTrace at our Blood Centers of the Pacific, all of our UBS centers in November of that year implemented PROGESA and then at the end of the year in December, our laboratories implemented LifeTrak.

This is just a picture that shows your blood systems today. As I mentioned our BECS systems are really kind of in the middle here, it the heart of our organization, and it manages donor eligibility through our product distribution. We have lots of things that are hanging on here, whether they are through an interface or a data exchange, we've got our financial system Oracle that is interfaced, our LifeTrak system, which I mentioned is our lab management system.

It also has some 510(k) devices that are attached to it, that are feeding information into the LifeTrak system. We have a data warehouse that data is transferred, and then we have some things on the horizon, which is the transfusion service, component manufacturing, that's going to be automated through Atrius in the automated donor registration.

And then along the side are just some examples of some standalone systems that we have, and you can see many of those are what we use to support our quality system. So you can see we are really, highly automated, we use automation to manage our business in many different ways.

And because of this automation, most of you also probably have a very good change control process. But we worked many, many months to try to develop one that was very solid, very strong, and very rigorous to manage all of these automated computer changes and processes that are now part of either the BECS system or our standalone systems.

We use this change control process for all of our software, whether it's a 510(k), whether it's a non-510(k), and we are really using this because we want to be able to manage all these projects successfully. We need to have knowledge of what's going on in the organization, and we need to be able to know which ones of these systems should be integrated.

We do all this with the oversight of a change control board, it's made up of our corporate office executives, and we really are the group that accesses the risk, establishes the resources, the money, the staffing, and approve the software to move forward.

So now moving away a little bit from really the who Blood Systems is and our computers, and focusing a little bit for you all on the challenges that we've had with our blood establishment computer systems.

I've captured them in these five areas, and we've talked a lot about these in the past day-and-a-half. But I'm looking at are challenges around growth and expansion, around our vendors, around our interfaces, around data warehousing in introducing risk.

So growth and expansion, because we have grown pretty significantly over the years, we have really demanded and had a quite appetite for more increase in automation. So that of course means we have a greater need to transfer this information.

The information needs to be interfaced, we need to be able to talk to all of these systems. Also our remote access has increased with Blood System's growth. Our testing laboratory has increased as well. The Blood Systems laboratories volume has more than tripled over the past 10 years.

And what that means is that the customers that we have and the clients that we serve have to have our data transferred into their computer systems, so that they further go on with their manufacturing. We've also got a great appetite now for data. We want to make our decisions based on data. We institute a culture of Six Sigma and process improvement in the organization and that comes with a high price tag of needing more data.

More data then means better reports, because you really need to be able to manage a business and make your decisions based on this data and these reporting capabilities. And these have been real challenges for us. Also this growth and expansion in automation has really created the need for more technical expertise in the area of IT.

And this means technical expertise and quality, it means more technical expertise in our IT department, and these people are really very difficult to find. Another challenge that we've had is because of our growth, one, BECS is really not been able to meet our needs, and so we are faced with working with multiple vendors.

Now, before I get into this, let me just say that we have good working relationships, and good partnerships with most of our vendors. They really are trying to help us to meet our business needs with the growth of our organization. With that being said, we do understand and know that the vendor software is really not designed to support this intercommunication very cost effectively.

And most of this is due to proprietary concerns, you know, I get that as well. You know, I understand that its -- why does a vendor want to make somebody else successful and having us use somebody else's product, it's their competitor. All of that being said though, we still have a real need for that information to be interchanged among all of our computer systems.

And product development time has also been a challenge. You know, we are an organization and probably an industry that we've got something we really want to institute the development time is taking a long time before we can get it into our hands.

Interfaces, is the third challenge for us. Now, certainly I touched on that a bit when I talked about the vendor kinds of challenges that we have. You know, ideally you would want all of your systems to be able to communicate with each other to have good interfaces. And as I mentioned, this is just not possible today because of the vendor's proprietary concerns and some of lack of cooperation with each other.

An example, I have a couple of examples here that I thought would be important for you to see. It's not just our 510(k) approved devices. It's also 510(k) being able to talk to our nine -- non-510(k) systems. We've had an initiative in our organization for some time now to automate the donor interview process.

And they are two separate BECS systems that we need to have talked to each other, and we've had a difficult time getting an interface build. So we are using a technology on investigating the use of a technology called "Screen Scraping" to try to get the information from that automated donor interview into our BECS systems.

Now we know that that's not the best approach. We much rather have this interfaced. So -- but it is what we are left with today. And until we get that figured out, the screen scraping, we are going to be doing manual entry.

And I think it was Rodeina yesterday that talked about you got this great system, you get all this data in there, and then you print the record, and then you are now going to take and manually enter it into your BECS systems. Those are really not optimal solutions for a blood organization.

And we've had the same kind of thing as I mentioned with non-510(k). It was very difficult, very expensive to get our Oracle, our financial system to interface with our BECS systems.

The next challenge we've had is around reporting capabilities. It's really is some of our BECS systems do not have some of the best reporting capabilities, and I already talked about our growing need and appetite for data and for better reports.

So we have instituted something called "data warehousing," and I'm sure lots of you are familiar with that. We are just talking information from our blood establishment computer systems and putting them in to a data warehouse, so that we can manipulate the data, look at the data, evaluate data, and create additional reports to help us to run our business.

These are non-manufacturing decisions. All manufacturing decisions are being made in our BECS system, but we want to make business decisions based on the information that is in our BECS, and we can't do it. And so we have to put it somewhere else in order to be able to use that information.

It also has some issues because we have multiple BECS. They have unique attribute, so it's not a one size fits all. So we have some complication in trying to get the BECS information into the data warehouse. And the other constraint we have is that it's not real time. We do not have the data transferred into that until -- till the end of the day.

We also have some validation challenges, you know, how much is enough, what should be validated, does it need to be validated, can we just validate the extract. So these are all some of the issues that we have around our data warehouse. And really the last area that I wanted to talk about and I've kind of talked about this in the other areas, but it's a really important one and that's why I have it up here as a separate challenge for us.

Now, whether it's the 510(k) submission process that's holding some of this BECS, whether it's the vendors not being willing to talk to each other so we don't get good interfaces, but whatever the reason is, we in the industry and in blood systems, are really having to put in solutions that we think are not optimal.

Screen scraping, filing, file transfers, extracts, doing manual entry are just some of them. And as we know, all of these methods is they are more error-prone and certainly they are more costly than automated solutions.

Okay, enough about all of that, about the challenges we have because I think if we look into the future, we can do some things that would help minimize and may be make those kinds of challenges that we are experiencing, go away. So first of all, I think we should look at reducing the burden of the 510(k) process on the industry, on vendors, and FDA, and I think we've had lots of discussion as to what that might be.

More information, better guidance documents, may be more automation, may be we can automate the 510(k) process. So there is been lots of great ideas and discussions, and I think those things will be moving forward and that could help reduce the burden.

I think in the future, as we do today, we have to support the FDA to continue regulating our computer systems through clearly defined validation requirements, we talked about that yesterday, it's really difficult, validations is hard.

And clearly defined regulations, helping us to understand why we have the regulations we do. I really enjoyed hearing yesterday, because I think it's one of the things that we clearly didn't understand an industry it's -- which is the difference between a pharmaceutical and the blood industry, and why they regulated differently.

That was really very important because that is an argument that we talk about or discuss because that an argument, but something that gets discussed, you know, in our organization, and now we've got some of that information. So I think more of that trying to get rid of some of the misconceptions that we have also will help us to be able to move forward, and then certainly through our inspections.

And as Mark mentioned, you know, to have us all be working on this together, I support that, I think we all need to be making the kinds of decisions together to figure out what we need to move into the future as far as, as the computer area. And may be most importantly is to get ourselves to think differently, while we can still be in compliance with the regulations and the requirements.

And I've two concepts that I wanted to bring to forefront here. I called them kind of out-of-the-box, but I think I've heard some people talk about this. So these aren't, so may be out-of-the-box, but this may be a couple of different twists. So I'm going to take the risk and show you some future thinking.

So one of the ideas might be to develop something you call a core computer system. It is a blood establishment computer system that would be comprised of a 510(k) approved internal core. What that means is that we would want a streamline diversion of what is in our current BECS today.

You know, we -- our current BECS today is everything from donor eligibility all the way through distribution. So we would look at removing some of those manufacturing processes out of the large box. That small core would remain as the heart of the manufacturing system, and could this core be as simple as having labeling, quarantine, and inventory management.

Now, in order to do something like that, you would have to have an interface that would control this and an interface that would be approved through a 510(k) process that would allow us to hang the other parts of the manufacturing process into this core system. So core donor eligibility are testing, production and processing, be just an interface and not part of the core system.

Now, as I mentioned for something like that to happen you really would have to have a universal data interface standard. We just kind of made that term out. But it's just a standard way that we would have an interface to share this information. Now, the core system would make the medical decisions, it would be interfaced with those modules, and those modules would be gathering and feeding that data into the core system.

So how might we move forward to think about whether this is even a possibility? We'd need to clearly define what part of the manufacturing process should be regulated through the 510(k) process, or are there some things, are there some activities that could just be regulated, that could just be part of validation, could just be part of inspection?

Can we -- meaning the vendors, FDA and industry, challenge our current thinking of what has to be in a medical device. These are kind of just big out there kinds of questions. Can we redefine? Are we comfortable to redefine where control needs to reside?

So just a little information about this interface standard again wanting it to be something that's approved by the FDA through the 510(k) process, could be applied for both 510(k), 510(k) devices, it could be between 510(k) and non-510(k), applications as well.

But you would want to make it part of the submission, part of the approval process so vendors submitting for something, they would have to have this interface standard, this universal standard as part of their submission. And could it mean that if you have this approved 510(k) interface that there may be not some requirements for resubmission for additional devices that we've interfaced or when there's been approvals modifications made to the system.

Now, how we would do that? We'd have to really again work together with all of us to figure out how this could happen, but the vendors would have to build a design their devices to be compatible with this interface standard.

This is just a picture of what that might look like. In the middle, it's the core with labeling, quarantine and inventory management, with the other systems that are now interfaced with the standard. And then there are some quality systems that are listed there, and those could be interfaced as well, if you chose.

So could this help, could this help be the change that may be we are looking for to help us reduce some of the burden, that get us better communicating together between vendors and FDA and the industry.

For blood establishments, it might simplify our validation, that'll be a good thing. It certainly would allow more flexibility and scalability, helps to reduce cost and our effort to associate it with these additional applications, and it would enable us to immediately adopt some of the state of the automation. So if somebody came out with something better in the area of collection or they came out with something better in the area of donor eligibility you could take what you're using lop it off, validate, put the next one on and go on about your business. But it would allow you to take advantage of new technology that becomes available.

For the vendor, the product becomes more adaptable to our -- to your customers. At the smaller course system may require fewer changes because again it's less complex. Your standalone modules may be easier to get 510(k) approval, not sure about that but again they are not as complex. They are just more of one area functionality, and those stand alone modules could be sold alone in our part of the great big system.

For FDA, you might see that this helps to standardize computer systems and interfaces, decreases the complexity of the submissions again if there's more or less functionality to have to review and possibly could reduce number of submissions. So I just put that out there as some ideas and food for thought.

 

And in closing, I would just like to say that over the 14 years ago the Blood Establishment Computers became regulated as a medical device. And over the same past 14 years the industry has changed tremendously. It has grown and we are using automation today more than we have ever used automation.

So it is time for us and the industry and the vendors and the FDA to evaluate the application and how we are using BECS in the future. And this conference is indeed one way to do that. So I thank you, the organizers of the conference, and thank you all for your attention and that's all.

(Laughter)

MR. DODDRIDGE: Mary Beth, I think you stimulated some conversation; there is two up there already. Please state your name.

MS. NOZICK: Yeah, yeah. Hi, I'm Robin Nozick. And I'm from R F Nozick and Associates. But I think more importantly, because I've been listening to all of this and almost everyone has talked about interfacing, and so more importantly I am an executive committee member with the ISBT Working Party on Information Technology. And in ISBT we work as work -- in the working party as task forces. And since I don't want to duplicate efforts and since America is part of the world --

(Laughter)

MS. NOZICK: -- and we've been working really hard the Americans like Rodeina, Bonnie Lupo, me, on getting everyone to understand -- we understand we're part of the world. There is already a very active task force that has been -- was at first going to write standards for interfacing. And actually, our vendors are part of this, Be Close (phonetic) is part of this from Wyndgate. And there were people who come from Oliva (phonetic), the vendors to be part of the working party. So this is not a novel idea.

And what was discovered was there are standards already out there that are applicable to blood banking and can be used. And I thank you, Mary Beth, because I think your idea is perfect, but I don't think we have to develop standards. That's what I'm afraid of is that we're going to go as Americans and develop standards. And we don't need to, the standards are there. And this taskforce needs more members.

We've already collected a list of device manufacturers who interface. We're looking for more names because Eva talked about this yesterday. I send Eva an e-mail this morning, and I can't turn around and see if she is there because then you can hear me, but Eva has received an e-mail from me that has Ms Pia Bruce' name. Pia is from Finland. She is the chairperson of the working party for information technology. She would love to have American participation.

So I'm throwing it out there that we're having an ABB meeting in October, we are having it in Montreal. I'm sure that if Pia knew there was this much interest by the Americans and the Canadians, she would make sure that she is there holding an interface taskforce meeting. I'll be glad to get everybody information about that.

But please don't go and make new standards because the standards are there, and it's a waste of your time. What you need to be doing is working on this taskforce, and working with the rest of the world to write guidelines for how to use the standards. So that's what I --

MS. BETH: Excellent, I think that is great. There is no need to introduce and reinvent the wheel if there are things that are already available. I think it kind of goes to what we've talked about yesterday. There is just kind of a gap in what people know and the knowledge that's out there for all of us in the industry to even know that that's something that is going on. So thank you.

MS. NOZICK: I just have one more thing to add that that's one taskforce about a dozen taskforces and working parties that are already working in ISBT, and I don't see enough American participation. When I go to meetings I've seen a lot of your faces at the ISBT meetings. I haven't missed one in a couple of years. And we need more of you and there is -- we've donors, there is hemovigilance, and there is the validation taskforce --

(Laughter)

MS. NOZICK: -- that I co-chair. And Janet is here from Wales. And we have guidelines and we'll be writing more guidelines a new version. And we'll be writing educational material. So please use those because you're my fellow colleagues and I hate to see people writing separate things when we have already worked really hard on it.

SPEAKER: My turn. Not enough, so I'm taking it down from the Puget Sound Blood Center.

MS. NOZICK: Okay.

SPEAKER: And I share some of your frustrations, working with vendors that will not interface with their competitors. It makes it much more difficult for the end users if we have to write our own interfaces. And I agree with Robin, there is already a standard. HL7 is used through out health care.

And there are standards for blood orders that are already defined. There are not standards though for interfaces between devices and there is really no reason why we couldn't add on to the HL7 segments to define those messages. No reason to reinvent the wheel and do it ourselves.

MS. BETH: Great. Thank you, both of you.

SPEAKER: Hello, my name is (inaudible). I'm working for Grifols. Grifols is a company that is a collector for plasma. So we have no blood but plasma, little bit different, but we are collecting 3 million units a year. So we are quite big. And I -- really, I'm happy to be here, and hearing that we are sharing all the same issues and the same problems.

And I totally agree with this approach of the core -- developing a core system for our industry and also regarding the interfacing problem. And I totally agree with Robin that there are existing standards, we do not need to develop these standards. So we can take a look at the existing ones. And also the big players are using it, I mean, SAP and Oracle are using. And you can have more information if you want in the Internet.

The standards are UDDI, so you can have a look at uddi.org to have the complete information about business standards and also WDSL. And I think that we can take an advantage of that. And that is not -- the question is not having the big players introduce it in our standard for the HL7. So it's just -- we can do the opposite, we can join this standard, and going forward, and take benefit of that development, so.

And if you are developing this taskforce, for Grifols will be a pleasure to join, and to help on joining this efforts in this three ways so like joining vendors, FDA which is a very important thing, because its helping us a lot in developing more safety products and saving more lives. Thank you.

MS. BETH: Thank you.

(Applause)

MR. DODDRIDGE: We're opening some time for some panel discussions, so if you do have additional questions we're going to take a break. And I'd like to give you 15 minutes because many of you are checking out, and so let's try to be back here by -- between five and ten.

(Recess)

MR. DODDRIDGE: Okay, our final panelist is coming forward; if you'd please try to take your seat. Well, I think we've had a very successful conference, and I know that there's been a lot of questions raised, there's been a lot of proposed changes, there's been some status quo that we've come out of this meeting. But I think overall the best thing that's come out of this meeting is that we've had everybody in one room discussing the issues.

And I think we're all here for the donor and the patient and I think we're to -- our job is to find the right decisions, to make the right decisions and take the points that have been raised and see if we can move forward. And I'm going to ask the panel starting with Rodeina to introduce themselves. Rodeina is the co-chair of the committee that helped put this conference together and has done a fantastic job, Rodeina.

MS. DAVIS: Thank you. Becky was my comrade in times, so thank you, Becky.

MR. DODDRIDGE: So you --

SPEAKER: You have a mike?

MS. DAVIS: No mike.

MR. DODDRIDGE: And give it -- if you want each of the panelists can give an opening statement and then we'll go to questions from the audience.

MS. DAVIS: All right. I think we started with the planning committee to put this program together, and the idea is as I said in my presentation to start having dialog. And from what we have witnessed in the last few days, I think it's not only dialog, we had lots of great idea put on the table yesterday and today.

And I would either hope that as we move forward we will all partner together on this. I think more important to me what occurred today is we all were getting more and more aware of the role of system in IT in blood banking. And that is a message that we always wanted to get across to our organization, to our industry, and we're really trying to see how we best can meet our business strategy and provide patient safety as well as donor safety.

So I think together as a group we were able to accomplish a startup of how we can move forward with this, and I do want to recommend that we do look at what already exist. I think the FDA have quite a bit of documentation that I'm hoping that we can all try to find out more about them, and establish a mechanism how we can facilitate excess of these documentation, or maybe provide more training, or a better way of -- and there's then being and reducing all the misconception that we have two of the 510(k) and others.

But I want to mention there is as Robin said the ISBT working -- IT working party that have done excellent job at trying to come up with some answer to some of the question that were raised today whether in the area of validation, the area of security, the area of interfaces.

And we have another taskforce working on the RFID standard, so we do want to figure out how the AABB IT committee that we have, the ABO IT committee, the ISBT IT committee, the FDA and all of us -- and the ABC IT committee. How can we all partner together and be come up with some solution that can really streamline our operation.

I do want to thank Jim and mostly D. D. Dodd for keeping with us, putting this program together because D. D. at the end, he is the one with the team, with the staff at the ABC, who need to work hard to make it happen with lots of support from the FDA staff. Thank you.

MR. DODDRIDGE: Thank you, we'll start with the far left, if you just introduce and if you have an opening statement short.

(Laughter)

SPEAKER: Hi, everyone, it's really short. I am the talking vendor. Rodeina asked me to sit up here, so if you want to take pot shots at the vendors, please I'm the one. I think this really was a great meeting, and I really encourage you to keep continue with this meeting. The vendor community responds to industry needs, so please just keep going.

MR. WEISCHEDEL: Good morning once again everyone, I'm Mark Weischedel , American Red Cross. And I can't say enough about how important this session has been and in varying, sort of, small groups there've been discussions for many years as long as I've been in this business about IT and in index collaborating and working together towards in better solutions. So it's very gratifying to see this coming together. What I would say is that there are so many pockets.

I used to think Red Cross was the acronym sort of alphabets to and now I'm learning it's a blood banking industry thing. You know so the ABC, ABO, et cetera getting everyone together in this place, I think has been enormously beneficial to try to help get everyone onto the same page, and see if we can work toward a -- toward a shared agenda. And certainly the Red Cross will do everything we can to support that.

MR. DODDRIDGE: Okay, Jay.

MR. VALINSKY: Well, first I thank you Dr. Richard. I think that this has been a very successful meeting because there has been an open exchange of ideas and perspectives. I think what's probably important for me is to say what FDA hears. Obviously, we're not going to make policy from the podium. But I've heard that there is a general perception that bringing BECS under device regulation has added to the value of BECS that there isn't a strong desire for it not to be a device and comply with regulations.

The question is, how do we have oversight. I think that I've also heard that validation of software remains essential given the criticality of software in the blood system. I think what we've heard is that there is a need to make improvements that some of these improvements have to do with FDA process; it's been called streamlining of 510(k). I hear that, but I think there's also the issue of clarifying expectations.

I think that we've heard at least one very potent idea, which is a modular approach to regulation software that has to do with defining the boundaries of the software, maybe that's what the core computer functions are that's a boundary over BECS as well as a standard interface.

I think we heard from Dr. Weischedel that we have to focus on a proactive collective approach to new technology that the essential frustration that's been heard here is that we're falling behind the curve being able to access and implement new technology opportunities, but that that would require a cooperative approach.

So that the regulatory requirements are understood, we have a clear idea of how to use these tools. So, you know, with demystification, cooperation, focusing on new technology opportunities, intra- operativity, reducing complexity of submissions perhaps reducing number of submissions.

I think those are the chief tasks that lie ahead, and I think that our main point here is that that we do -- we will cooperate in a collective effort, that I think it has to be approached in an orderly way.

Now, what are the critical oversight functions, who is best positioned to do them, is there some sharing of risks and burdens that could be changed between what FDA does and what industry does and how to ensure accountability. You know, how much looking into the black box, how much really needs to be into the "white box." But I think that these are things that we can address together and that there is progress to be made here.

MR. DODDRIDGE: And last, but not least again Mary Beth.

MS. BASSETT: I think this would be an appropriate time for me to say dido. There isn't a lot more really that I can add, I'm really very encouraged though to hear from you Jay and the FDA that they're willing to kind of sit at the table and help us figure this all out, and so I think we just have to stay on it and make sure that we take these ideas and really turn them into actions. That's all.

MR. DODDRIDGE: Thank you. The format we're going to use, there's a couple of written questions that were turned in, which I'm going to bring up on the screen and Jay they seem mostly directed at FDA --

(Laughter)

MR. DODDRIDGE: -- so if you want to call for some help from senior troops you can and as we're doing that. And when we finish those we will open the floor and please go to the mike and state your name, and direct it to -- if you want to direct to one of the panels or if you don't have one in particular they can take turns. The first one was --

(Laughter)

MR. DODDRIDGE: Would the FDA premarket approval process add value if the manufacturing firms were all certified to a regulatory standard? Who would like to take that? Jay, that --

MR. VALINSKY: I'll take it first crack at it. I think that recognizing suitable industry standards can only help. However, I think that it may not in and of itself be sufficient. There are firms that are ISO compliant and still have regulatory problems. So it's not a panacea, but I think it's an extremely helpful trend and that we can make use of recognizing more industry standards.

I think another domain that links to this little bit less specific to the question is this whole issue of the 510(k) being specially formatted for the FDA. This is something that we don't actually require, it sort of lives in the domain of misconceptions. We see providing an example of what we want as simplifying things.

But if it's actually having up the perverse effect of creating more work, we can be a little bit more proactive saying well, we recognize documentation according to the following published standard.

And so it's along the general lines of industry standards, but certainly, you know, we're believers in ISO, we think ISO adds value, I think it's helpful I'm not sure we should just say its sufficient. In other words, if a firm is ISO compliant, does that mean we don't need to inspect. Well, I'd say, no.

MR. DODDRIDGE: This one has multiple parts, if the hospital system has corporate waste --

MS. BASSETT: Oh, Don.

MR. DODDRIDGE: Now we have -- okay.

MS. BASSETT: Can I just add to that, Shelley Looby, Cerner Corporation. I mentioned that we are an ISO certified company to two different standards, actually coming up on two more. I just want to say that while it helps I think greatly ensuring that we have quality processes in place, and that we have as a corporation, good practices worldwide for us.

Our audits from FDA as compared to our audits from our notified body are very, very different. And I do not believe that one could replace the other. There's very distinct things that the FDA is going to look at when they come in and there are very distinct things that BSI looks at when they come in. And while some of them do overlap there are very wide differences, and I personally don't feel that one can replace the other just from our experience.

MR. DODDRIDGE: Thank you. Our second question if the hospital system is corporate based and system upgrades or patches are requested by the manufacturer, how should the notification be made? Should it go -- I think what we figured out from this, should it go to the corporate first or should it go to the individual, hospital or user?

MR. VALINSKY: I'm not sure I can answer that because the answer might be either. Sheryl or Linda do you have an opinion on this. I mean, you know, one of you go to the mike though and --

(Laughter)

MR. VALINSKY: That works for me.

(Laughter)

MR. DODDRIDGE: And we've a couple of more questions.

SPEAKER: First of all, it may just be the wording is not right because we do not regulate hospital systems that is our sister agency CDRH, and I'm not sure they even regulate them. So was the question as to BECS?

MR. DODDRIDGE: I have no idea that is the way it's written, if somebody is in the room that would like to clarify that?

SPEAKER: Okay. Okay, if the BECS is corporate-based and upgraded, or patches, or requested by the manufacturer, how should the -- okay, to begin with I may be misunderstanding so correct me, but every bug fix, or patch does not need to be cleared through 510(k). It's only when it reaches a certain -- which I covered yesterday a certain level.

Once it reaches that level of affecting the safety or effectiveness in new intended use, you know, something wild and new technology then it should be made by the firm that manufactured it to the FDA, and I'm not sure if I still understand your question. But it should be made as a 510(k), it could just be a special depending on what the changes were, but keep in mind every change does not require a new 510(k), certainly not bug fixes.

MR. DODDRIDGE: If you would like further clarification I think you can talk one-on-one after the conversation.

SPEAKER: Yeah, sure because I'm not sure that we understand. Okay.

MR. DODDRIDGE: Next one. Can the FDA investigate posting changes and 510(k) submissions?

MR. VALINSKY: Well, let me start on that. We have policies about when we post. Generally, the rule of thumb is if there are three specific manufacturer interactions that have a common thread that we can then post that. The dance here is between, what's a confidential communication with the agency and what's a policy update.

So we are mindful of the need for more than one user to get information when something has changed, and we are generally trying to use web posting more flexibly as opposed to issuing guidance document under GDP, which is a much more labor-intensive, time-intensive process for us. So I guess the answer here is we appreciate the request, we are trying to do things of that nature, but we do have to figure out whether the issues are confidential.

MR. DODDRIDGE: Going under the next one. If their one submission -- is there one submission template for 510(k)s, there are many confusing documents that seem to require slightly different documents or information?

MR. VALINSKY: Well, I think the answer is that the regulations specify the categories of information in the 510(k) that's the fundamental framework. Beyond that we don't currently have more specific templates. In other areas, of regulatory submission, we have been moving toward what we call a "Turbo" submission, which basically is an automated submission where the template exists in a computerized format which, you know, you download and can fill it.

Now, we don't have this right now for BECS, but it's not inconceivable that we could try to move in that direction, you know, through some cooperative effort. So I guess the answer is only going to be partially satisfying to you that again the domain of information requested by the FDA is highly specified in the regs regarding 510(k), but the details have to be called out of guidance now, and could be automated. And yeah, we'll think about that.

And special thanks to Allen because he's been a pioneer of this Turbo approach.

MR. DODDRIDGE: What is the difference between an Intended Use statement and an Indications of Use statement?

SPEAKER: (Off mike).

MR. DODDRIDGE: Okay, we'll then go ahead.

(Laughter)

MR. DODDRIDGE : Your turn.

SPEAKER: Whatever it is in the drug industry I know is very difficult with software, it was for me when they first -- I said, what -- basically it's the same thing for software. Sometimes the Indications for Use statements is a little bit longer in terms of what features you offer.

Often we get -- most often we get a 510(k) that actually has the same intended use and the same indications for use because all of our devices are used on the same population usually. So it's kind of a different concept, I can understand your frustration was trying to decide the difference between those two.

Jay, if you want to.

MR. VALINSKY: And well, Linda is behind you and he's quite expert in this, I was going to give a caveat to, go ahead.

SPEAKER: Well, to just to -- Linda gave a practical interpretation, there is nothing wrong with that. From a technical regulatory point of view the term "Intended Use" is unique to devices. It doesn't exist in drug or biologic regulation, indications for use.

Intended use is what the manufacturer of the device intends for it to be used, or how it is to be used, and it's a formal requirement that they needed to state that explicitly. They also need to add in an "Indications for Use" statement in other words a population number which is going to be used, how it is applied to et cetera, similar to how it is with drugs.

MR. VALINSKY: I think another way of looking at it, the Intended Use is generally broader and more general. You know, to determine the suitability of a donor would be a function of the software as a whole. The medical indication tends to be more setting-specific. So it says something little bit more specific about that application.

So for example whole blood versus source plasma might be an intended use, I mean an intended use setting in medical indication, sorry, an indicated use. They are related though, and I think that's what leads to most of the confusion.

MR. DODDRIDGE: Well, Celso, we are ready to open the floor up, are you going to be the first one.

MR. BIANCO: Okay, it's a question for Jay.

(Laughter)

MR. BIANCO: But it's more of a request than a question. Jay, you mentioned on a couple of occasions that we have many misconceptions about the way the 510(k) work or the way FDA regulates what we do. Would you be willing to state a few of those so that we take home a message of what we have wrong in our minds?

MR. VALINSKY: Well, I can start and perhaps others who deal with this on a daily basis can amplify. I think the first misconception is you can't talk to us. We have really an open door policy, we engage in pre-filing meetings, you know, pre-510(k), pre-IND, pre-IDE, pre-BLA. We do this on a routine basis, it's a structured conversation we expect you to come in, propose an agenda, you know, we offer a timeline for a meeting. But we do this routinely, and it's a tool that can enable better clarification in the FDA expectation.

What do you want to see on paper, you know, how to do want this indexed? If we put it in a CD is that enough, do we also have to send it to you, you know, on the web, things like that. So there is that opportunity. And along those lines this also the interactive review which is again has been part of CBER's practice for a very long time.

It's now in an agreement under the user fees for devices, but it provides once again a structured conversation, but one which is open-ended where a sort of small matter is going to be addressed informally. So I think the first misconception is that you can't just talk to the FDA. I think another misconception which is related is that you can't argue with the FDA.

(Laughter)

MR. VALINSKY: You know, we are science-based, and we tend to be convinced by data. And I think one of the things that has bothered me in the last day and a half is that there is sort of paucity about data to help us understand the underlying causes of the current problems.

So for example we don't hear from the vendors who dropped out. You know, what did they think the barriers were, or from the vendors that opted out and what did they think that barriers were.

And then the flipside, is it better that those particular players, you know, did opt out or drop out because they didn't think they could comply with regulation. And the argument tends to be well, that's a bad thing that they are not playing, but maybe it's a good thing that they are not playing. But what's the evidence and I don't know the evidence. Jim knows the evidence.

(Laughter)

MR. MacPHERSON: Well, I don't have the answer to the question, but it prompted me to say that when we organize this we try to get two organizations involved Pharma and also to get its -- the health -- what it's called Rodeina, the health --

MS. DAVIS: HIMS.

MR. MacPHERSON: HIMS. And at first -- and Pharma refused to -- they said they wouldn't attend, they didn't want to be involved, they didn't want to surface, they didn't want to be even thought to have the fact that they would be that their software would be regulated, and so they just -- they just ignored us frankly.

HIMS initially was very interested, and in fact they were going to provide a speaker on Microsoft -- for Microsoft to tell us why they don't -- they won't work with us directly and the person from Microsoft said, "Hell no."

(Laughter)

MR. MACPHERSON: So it's their absence here I think is probably tells you something, but do we have data, no. But I think their absence speaks volumes.

MR. VALINSKY: Well, it doesn't tell us all about their motives, only where they stand on it. I think that that hooks I mean I am getting a little bit away from the issue of what are misconceptions, but whether engagement of software giants is in and of itself a strategic goal here I think needs some clarification and I am not sure are we well-served or ill-served by the current landscape of vendors.

And the arguments been made that it's a more robust system if there are more vendors. The arguments also have been made that the industry giants have more at stake to stand behind products, you know, they are not going to be able to walk away because that's the end of their credibility, you know, worldwide in many, many domains and not just BECS.

And on the other hand a small vendor might just decide well, this is not working for me whatever reason and you're on your own, you know, you can purchase rights to my source code, but you know you're on your own now. And the industry looks upon that prospect, you know, with horror.

So I think that there are unclarified issues with respect to the market forces, and that whereas the FDA regulation plays a big role in the landscape sort of the market forces, and I just think that there is a lot of reality testing that hasn't gone on to truly understand, you know, which force is dominant over which issue.

Okay, but just to come back to a few misconceptions, so I touched a little earlier on the misconception about the formatted document. FDA is actually a lot more flexible about the format of the documents that we receive.

What we care about is that they address the correct issue, and that they should be interpretable. And obviously there are semantic issues and, you know, complexity issues and trackability issues and all of that, but fundamentally it's not a reluctance of the FDA to deal with alternative formats.

I guess another issue has to do with new technology. I think the point has correctly been made that when there is a whole new technology in front of the FDA, it's going to take us some time to work through the issues whether that's, you know, RFID and, you know, interference whether it's, you know, wireless which of course is related, whether it's open-ended use of web service. These things do present regulatory challenges.

But I think the misconception is that FDA is not willing and able to engage, we are willing and able to engage. It's just you have to approach us that way, say look, we have something new we want to put on the table here. I can tell you from the perspective of sort of, a broader portfolio within FDA.

We deal with a new widget or a new concept everyday of the week. We are attentive to the need to define regulatory standards in the face of something new. That's not to say that it's done instantaneously, it's done deliberatively it means to be deliberative, otherwise we can make very, very big mistakes.

So -- but the misconception is why we can't engage FDA on that issue. And then I guess these are a little bit narrower, but it has to do with the whole issue of what to submit and when to submit. And I think that the rules tend to be a little bit more flexible than many vendors realize, you know, what, you know, bug fixes do you have to submit as a new 510(k). You know, how many things can you bundle and you don't have to file things like that.

But again I think the remedy to that partly it's guidance, partly it's conversation because it always comes down to specifics. If we had guidance, we'd still be in a quandary over the specifics. So I think those are the ones that leap out to me, there may be others that Sheryl or Linda or Joan might want to comment on, but I think those are core misconceptions.

SPEAKER: I think I commented on some of them.

MR. VALINSKY: The mike.

SPEAKER: -- I commented on the misconceptions I see yesterday and I don't know financial anyone has any other questions about that. I reiterate what Jay said about we don't care as -- we don't review for format, we review for content and other than repeat what I said yesterday I really don't have anything else to add.

MR. DODDRIDGE: Let's go to the next question, and if you'll come to the mike and state your name.

MR. COBURN: Hi, I'm Tim Coburn (phonetic). I'm a recovering vendor. And my question is to Nicholas. We heard -- brought up several times the issues of interfaces between systems. And as an expender I'm fully aware of that. And I want to get your comments. There are obviously technical issues that some of the ISBT groups are -- various committees, technical committees can address.

However, there is really the marketing issue and the proprietariness of trying to protect your customers. And I think if -- Jim, I think ABC and GSABC is kind of in a unique position to maybe force cooperation in their vendor or approval process to say if we can figure out the technical issues then if you want to be approved vendor then here you got to play ball. I think that vendors want always to be treated the same. And so I’ll cooperate as long as everybody else does. So I wonder if -- Nicholas if you could address that.

NICHOLAS: I agree with you. I -- as I mentioned in my opening comment. You, industry, the customers really can drive us a lot. And I heard multiple comments that some of the vendors don’t work with you. It seems like there was a little bit of commonality there. And it is, as you said, if we all come to the table it’s going to be a level playing field. If one of us don’t we wonder why they don’t come to the table. It is a little bit small market compared to the Microsofts and others. You know, I'm not sure if it’s a niche market. In a way you could call it that. But it’s hard with the small number of players to sit down and opening yourself up. Why isn't the others opening themselves? And I think ABC could help them.

MR. DODDRIDGE: Any other panel want to take this question, or have any answers?

SPEAKER: I would add that it is in the industry’s best interest to -- for all of the vendors -- key vendors in this space to participate. And again the Red Cross will do what we can to support and encourage that. There is one of these things called the tragedy of the commons that if you don’t have enough players, and if everybody’s self interest in the marketplace doesn’t reinforce certain behaviors, then the whole suffers. And we don’t want to see that happen. And we’ve all had experiences that we want to learn from and apply on behalf of the whole industry. So without getting to specifics about negotiations with vendors and those kind of things I’d say that this is a key priority for us.

MR. DODDRIDGE: Any other questions from the audience? And I'm sure there are a lot out there. We got two coming forward. Jeff?

MR. WALKER: Tom Walker, Canadian Blood Services. Mr. Chairman, I don’t really have a question. I actually would like to answer a question that Ms. Loreng raised yesterday, and also just provide a little bit of information supplementing my presentation that might prompt some comment from the panel, if I may.

First of all, yesterday Ms. Loreng expressed surprise that Health Canada had the power to inspect a supplier that was not licensed when I mentioned that Health Canada had gone to visit MacVergesa (phonetic). In fact Health Canada doesn’t have that power. They have the same powers as the FDA to inspect.

What happened with MacVergesa is that they were exercising an entity that they offer us, which is the on-site data review. We submit summaries of our testing and validation. When the reviewer goes over the summary if they find that their review would benefit from looking at raw data they give us a call and say, can we come onsite and look at the -- and go through the data and discuss it with you. They spend a day or two with us. They identify the documents that they need to take home for the file. And we find that this expedites the review from both sides, because it doesn’t create a huge stack of paper. Well, we don’t have to create a huge stack of paper that Health Canada then has to read through to find the appropriate parts.

Now, in the case of Mac I'm not sure whether Mac issued the invitation, because of the cost and effort required to copy all the paper and ship it across the Atlantic, or whether the Health Canada reviewer decided that he would benefit from a trip to Paris more than the data would benefit from a trip to Ottawa. But at any rate it was not a case of Health Canada arriving and saying we’re going to inspect, there was an invitation issued by Mac.

The second point, in my presentation I dealt only with submission of new systems. I didn’t discuss how we handle upgrades and minor changes et cetera. Those are handled through the routine license amendment processes both for the Blood operators and for device manufacturers. Therefore, the submission requirements are scaled based on the risk of the change. Now, we still have long, meaningful discussions with Health Canada as to what the risk of the change actually is, and therefore how much data we have to provide.

But it does mean that issues like changing the system to export data to a financial application don’t have to be considered. We had also -- in the process of those meaningful discussions about risk we’ve actually or effectively move towards the concept of a core system, or not requiring suppliers to modify their, or modularize their software.

And I saw we, I should give the credit to Health Canada, because they have looked at the manufacturing processes and stratified those according to risk so that we have the core manufacturing processes, and the software that supports those processes gets the full regulatory scrutiny. They have also identified low-risk processes, and software that supports that is regulated through inspection. So --

MR. DODDRIDGE: Thank you for those clarifications. Any follow up from the panel.

SPEAKER: That I would just have to say falls right in line with some of my thoughts and comments that I made about kind of a core system and what that would look like, and we’d have to really clearly define what that would mean. And then are there ways, as he just said, that the parts would be 510(k) cleared or for submission, and other things could just be reviewed on inspection or through validation. It does kind of fall right in line. And I really haven't gone to Canada. I didn’t know what they were doing there. But it sounds very similar.

MR. DODDRIDGE: The Canadians come to Florida during the winter.

Jeff.

MR. McCULLOUGH: I have two questions. And the first one is for anyone on the panel and the vendors, I guess. In thinking of a totally different area, field that is beginning to struggle with how data -- electronic data is managed and communicated this deals with indwelling medical devices, pacemakers, cardiac defibrillators, drug infusion pumps and so on.

And in those situations the big guys are in the field, but those companies -- Medtronic, Boston Scientific, St. Jude and others -- are coming to -- we happen to live in the midst of most of them. And so they are coming to us saying that there are no standard ways in which that electronic output occurs. There is no way to ensure that it is compatibility, or talks to each other.

And as their patients who now have more than one implanted device sending off data systems they are looking for dialogue that would help to begin to figure out how to bring some cohesiveness to all that. And I wonder if that setting -- maybe it’s a question for Jay, do you think that setting applies to the situation with Blood Establishment Computers?

MR. EPSTEIN: Well, I don’t know the technical issues well enough to comment except to say that we talk all the time to our colleagues in CDRH to deal with those devices. For example in approaching the whole set of issues of RFID which have to do with, you know, using radio waves to transmit information, we’ve dealt with things of this nature. So I don’t know what the prospects really are for standardized interfaces. But I guess I feel optimistic about it, that, you know, we’ve invented these technologies, we should be able to find ways to standardize their use. But beyond that I think it’s more a technical question and a little bit out of my element.

MR. DODDRIDGE: Anybody else on the panel?

SPEAKER: Yeah. It’s been mentioned multiple times, the HL7. It is a very good example how in the hospital market you really cannot enter without an HL7 interface in talking to the other systems. And I really would recommend to the industry to get involved. There is a special group already looking at defining the messages or amending the current HL7 standard to send to specific donator, or collection specific, manufacturing specific messages, and to be able to exchange data. I think you just need to force us to do it. And you need to help us define what those standards are.

MS. DAVIS: And I was going to say almost the same thing. I think the vendor - we are waiting for our industry to tell them what we want, and as we put the taskforce together to look at system interfaces -- I mean, this has been going on now for over 8 years, and no activity (inaudible) has happened. We went after -- from both ways we went after it from the instrument to -- you know, all our instrument to the system, and then from a system to a system. And now that our instrumentation became really more network than have -- or have the capability of creating (inaudible) or interaction via (inaudible) transaction.

So we eliminated the instrument to system interface’s need. And we said we need a standard to use in blood banking, in transfusion medicine that (inaudible) between talking system to a system. And that is the taskforce that I mentioned is going to have a meeting at the ABB. I think whoever is interested in this I will be very happy to send them the information. My e-mail is RodeinaDavis@ -- Rodeina.Davis@bcw.edu. And more activity, I know that Wyndgate is onboard with us. We have some other vendor that are on there. But we do not have many blood banker on this.

MR. DODDRIDGE: Jeff, you had a follow up or --

MR. McCULLOUGH: I almost hate to bring this up, but it’s a totally different subject. A number of times in the last day and a half it’s been mentioned that whether or not you want to call this a niche market or a small market, the size of the market, and that determines of course the total revenue that’s available to the vendors, and that’s going to determine how imaginative you can be. I gather that there is some concern that some of the technology isn't as up to date as it might be, and enhancements don’t come as quickly as they might.

And so to what -- I guess the question for you and other vendors in the room, to what extent is revenue and money really a major restraint in your ability to provide the kind of state of the art systems that we need.

SPEAKER: Yesterday. In Mark’s group we kind of discussed this. And I realized yesterday when you say technology I'm not sure what comes to terminology. Is it functional requirements or using like RFID, and -- you know, is the big question.

A lot of times the problem with technology is a lot of them come and go. If you look at the technology, especially in the past 10 years the number of new ideas that everybody jumped on, and then it turned out to be not working as advertised, we are a medical device as of to that. It is hard to implement and use a technology that’s not really proven.

It’s hard to be a pioneer and keep putting money when the customers are waiting for other functional requirements where we could, you know, expand our systems a little better. So it’s hard to jump on the technology right away. RFID is working through a lot of issues that -- the technology is great, and it works great in other industries, but just because of the liquid it creates its own challenges, as an example.

MR. DODDRIDGE: Any other panelist want to comment?

SPEAKER: I would add that this is another area where terminology sometimes gets in the way. I mean, you know, many of the discussions that have occurred yesterday and today center around, you know, the state of technology, and how do we as an industry avail ourselves of technologies and other trends such as service-oriented architectures and software as a service.

And sometimes we get tripped up in are we technology, and is it a question of technology readiness, or is it a question of do we have, you know, the economic wherewithal, do we have the right economic forces to encourage development in certain areas. And these are, I think to Jay’s point, very complex matters. And the interplay of regulation and economic forces and technologies is not in many ways really very well understood within our industry. And so it’s hard to say anything conclusive. But I think the question that Jeffrey asked is a good question around is there enough economic vitality, is there an adequate revenue base to drive and sustain technology advancement in our industry. And I'm not sure we have an answer to that. But I would be interested also in more information from vendors on that.

MR. DODDRIDGE: Okay. Jay.

MR. EPSTEIN: Well, I just wanted to add -- mention the fact that the user community is very heterogeneous, and, you know, you have very, very large systems with highly specific needs. You have small operators with less validation capacity, and perhaps modest needs, and maybe they don’t need the latest of the latest of the latest to address their structural problem.

So that’s just another element that plays into this, that pace of change may be an advantage for example to a very large operator that needs a new technology solution, and it may be a disadvantage to a small operator that’s doing, you know, very well, thank you very much.

MR. DODDRIDGE: Okay.

MR. ABRAMS: Hi, Philip Abrams from Talisman. I'm a vendor. Let me throw out a -- sort of a minority view. One of the frustrations that we often have is, you know, we have new technology. And what we see a lot in the blood industry is reluctance on the part of blood centers to adopt technologies quickly.

The cost of change is high. You’ve got, you know, regulatory issues, training issues, documentation issues, cost issues and so forth. And there are certainly times where we feel that, you know, we could move more quickly if only customers would adopt technology more quickly. I think some of the other vendors can certainly share the frustration. For example, of how long it takes for customers to implement new releases. I mean, that's just the tip of the technology iceberg.

So, one of the things I'd like to see is figuring out ways that we can make it easier for the blood industry to adopt new technologies more quickly without a lot of the overhead that they currently have.

MR. DODDRIDGE : From a CEO's standpoint, better reimbursement.

(Laughter)

MR. DODDRIDGE : Any other responses to that?

SPEAKER: I think when we talk about technology, we are really not talking about, you know, using the widget that everyone else is using or the -- what we are really talking about when we have a technology, when we start talking about the capability to have open system, new system, to help us in creating some functionality, complex functionality, create intimacy with our donor, be able to do the donor questionnaire using the internet, make sure we have the proper security, make sure that we as organization, as an industry, have the ability to do it.

Now, given to implement that new technology that you give us, as a vendor, and we are very happy that many of you are already offering some of these technology, we don't need to validate it in our environment and we need to make sure it's working. And the major problem we have right now is when we bring that new technology and we try to put it in, there is no way for us to integrate it with our BECS.

So if we're -- I mean, it's too silently -- it's, you bring the technology for us and we love it. I cannot use it because I'm not-- I don’t have the capability to integrate it with my blood banking system. So the question is, as we said, that's why we are having this dialogue, for all of us to get together and say these are the right technology for us to use.

And we do study -- I mean, when we do study, for example, on the RFID, we're not saying we got to RFID tomorrow. We're doing a study. We are evaluating whether the technology is going to help us in streamlining or it's going to help us in patient safety. And we'll work together. We would like to put a group together to work together on this. But it is the idea of really getting together and determine -- I'd love to have your new technology but there is no way for me to deploy it in my blood center because I have no way to put it into my system. So it's a catch-22 kind of thing.

MR. DODDRIDGE : Any other comments from the panel? Any other questions out there? I do think one point that was brought up earlier today I think from one of the speakers over here is the global aspect of what we're talking about. And I think that is very important. And we do have some success stories out there. Although we're slow and coming, we managed to implement ISBT code 128 with -- started out with ISBT and, I think, that was success stories on both sides of the water here.

SPEAKER: Hi, I am Dan Taksigi (phonetic) from Grifols in in Los Angeles. I work with Jazella (phonetic) from Spain, but I had -- I'm going to pick on Nick. But you recently had a 510(k) that got passed, and I was wondering if you could share some of the points, key points, that allowed you to get it -- put it through in such a short period of time.

NICK: We had this discussion again yesterday. So to some folks it's going to be a repeat. We believe that the 510(k) process and the regulation is actually a good business. We have incorporated everything, all the documentation that we need to do into our software development process. So at the end of every release, we have the documentation ready and it's literally just putting it together and putting the other additional documents that we need to put on and we can easily submit.

And if you really look at it, other than the submission, you really should do that for any kind of product because it's just software development 101. You are going to start out with requirement, then you're going to create some specifications, you're going to code it and you're going to test it to make sure it works. We don't have really any problems doing any submissions. I mean, Linda, you are all reviewers, so please, you know, jump -- I mean --

MS. WEIR : What's the name of the software products --

NICK: Again, multiple times it's been brought up that you can't talk to the FDA -- we've been on the whole on a regular basis just to make sure if there were any issues or clarification needed to be, we just dealt with it, and it was a very easy process. Again, that's just our point of view. Did I answer your question?

SPEAKER: Yeah, I thought you're going to say, a real software with zero bugs.

NICK: Yeah, right.

(Laughter)

MR. DODDRIDGE: Okay, any other questions? I can't believe after a day and a half of this stimulating conversation that we've had that there's no more questions out there. Are we all just burnt out? Last call for some questions or if the panelists would like to add anything before we close, and then we'll bring Jeff up to have some closing statements and follow up with Jim.

SPEAKER: Hello, I'm Jeannette Simms (phonetic) and I have come to see the conversation from Wales. I have had a fascinating couple of days here. I've heard such a lots. I'm sure most of you are aware we don't have to comply with the 510(k).

Personally, I think it's a great idea. I wish we had it. It would make my job a lot easier. Just a general observation. I understand why everyone is consumed about the speed in which you can implement new technology. I just wondered whether anyone has any information about what's happening in Japan as they are the world leaders with gadgets and things. Does anyone have any comment on --

MR. DODDRIDGE: Does anybody have any experience with Japan on how they do it, any vendor in the room?

SPEAKER: Shelley Looby, Cerner Corporation. I do know that we have done significant amount of investigation with regards to Japanese device regulation compliance. Their rules are massive. And not only that, the import rules are very overwhelming as well. And we opted for not going into the market. We didn't have a lot of interest anyway from the Japanese market, and didn't feel that we could fund complying with their regulations and their import laws with the interests that had been expressed to-date.

Nicolas, you may have some other insight in that, but I do know that when we started investigating, and I used a person on my staff to start the investigation, we used a couple of attorney in Japan that do medical device law over there, I was overwhelmed. It was -- this looks like a cakewalk compared to what we had to deal with there.

MR. DODDRIDGE: Okay, well, thank you. I'd like to go ahead and wrap this up. Jeff, if you'll come forward, and Jim, if you'll just follow Jeff. I want to take this last opportunity to thank you for attending this on behalf of ABC and our partners who put this together, and a special thanks to our committee who set up this conference and also to the ABC staff that did a fantastic job. Thank you.

(Applause)

MR. McCULLOUGH : I have no revelations. I'm really going to summarize or emphasize some of the things that all of you have discussed over the last day and a half. And I'll put these as short-term and long-term suggestions. First, I think it's apparent to everyone that this has been an extremely valuable day and a half, and again, I congratulate ABC and Jim and -- for taking the initiative to put this together. Obviously, it has benefits all the constituents.

And so I would assume and hope that this isn't the end, but actually it opens the door to establishing some kind of a forum that would include a variety of individuals such as IT vendors, IT experts from blood establishments, the FDA, but also quality assurance and operations people. I think there are very few operations people here.

And so we'll touch on this a little bit more in a couple of minutes. And in fact, I think one of the vendors who I met in the bar last night, but I don’t recall your name, has asked us to force you to do some things.

(Laughter)

MR. McCULLOUGH: And I think one of the ways that will happen is if we are sure that our operations people are also involved in helping to drive the process. Secondly, to mention the potential to explore interactions and collaborations with the ISBT taskforce on developing standards.

Thirdly, exploring ways to improve the interaction with the FDA, the jargon that's been used to streamline the 510 process. I think a number of people have given examples of how that could happen, and I don’t need to refine them here, but also as part of this, to refine and improve the understanding between a vendor's blood stead and the FDA about validation expectations.

I think for others who didn't have the opportunity to be here in the last day and a half, continued visibility from the FDA, and again, John's nice two or three slides illustrating to agency's vision of the difference between pharmaceutical and blood manufacturing, that really do form the basis for this approach that 510(k) regulations is helpful.

The other thing that has come out from a number of speakers, Mary Beth and others, is a my last bullet point on this slide, that if some attention can be given to defining those portions of software, which really have to do with blood safety and those portions which are more management functions, and then look at differences in applying the 510(k) regulations to those different segment software.

This is really not a series of longer term exactly recommendations, more like issues or things to consider. But several people have said, some more bluntly than others, that we are -- we, blood establishment folks, are actually part of the problem. We can't sit here for a day and a half and blame all this on the FDA regs. We have a role in all this, and so we need to look at ourselves and look for ways how we can help vendors to provide enhancements to improve the situation.

We have already heard specifically from Jay that the FDA is, as we know many of us, from other interactions with them, they are very willing to talk. They will look forward to talking and interacting and helping vendors understand how to work with them efficiently. But the blood establishments including our IT people, our QA people and our operations people need to take responsibility to help in this whole process.

Some of other issues, some discussion a number of times about large and small vendors, is this good, is it not good. The market will ultimately answer this for us. But it's mentioned in various ways that it is good, that it's bad, that we force out small vendors. And I think as Jay mentioned, and I think I did yesterday, maybe that's not so bad. If somebody doesn't have the expertise to go to the FDA, then maybe they shouldn't be doing this.

On the other hand, we also need to keep on open mind that there may be new people coming into this industry that would be able to make remarkable contributions. And so we need to be constantly aware of how not to prevent that.

A number of comments about the big guys aren't in the field. And I mentioned yesterday and I think Jay did also, is this bad, is this good. The implication is that it's not so good, but if it is important, then what kind of strategies need to be put in place to entice the Microsofts of the world to begin to work with us.

And the next bullet point on here is, I'm not enough of a technology wizard to understand the jargon talk about that we don't have systems that are as contemporary as the technology would allow. Assuming this is true, what do we need to do, all of us, in order to help create an opportunity for those contemporary systems to be brought in to help us.

Jay made some nice comments yesterday about the difficulties in global harmonization. On the other hand there maybe some kinds of discussions that would at least be partial steps toward global harmonization that might make this field more attracting to some vendors, and those discussions would be important to initiate.

We've talked a little bit about the systems interfaces and also emphasize that maybe something that can be addressed as workgroups begin to be formed. Are there new technologies that should be implemented? If so, again, those of us in the blood establishment particularly focus on operations have a responsibility to interact with the vendors to try to identify those opportunities and make it known to the vendors that we desire these kinds of enhancements to be developed and make it available to us.

One comment for the FDA. I started to put in parenthesis in the beginning of the second bullet point "Behind closed doors." I'm sure it's nothing that the agency could or would talk about outside of the privacy of their offices, but there must be some thoughts about a balance in which the regulations are appropriately applied, but also applied in a way that does make it possible for innovations to be implemented and moved ahead, particularly when these innovation might improve patient safety. And the fact is there is a balance between adhering to regulations but also applying those regulations in a way that allows us to continue to enhance our systems so we can do a better job and a safer job for making blood available to patients.

Another point here is what can we learn from the plasma industry. I'm delighted that Grifols is here, and there may be others that I don't know about, but they have systems that obviously are very effective for them, and maybe there are things that we can learn from them.

Our last bullet point on here is -- here -- partly from some of the more recent comments, but also my own experiences in other aspects of transfusion medicine. And the fact is, I hate to say this, but those of us in transfusion and medicine and blood banking don't have a track record of being the most creative and imaginative and willing to move quickly to adopt improvements and enhancements. And I think that probably plays into the situation that -- in which we find ourselves.

That may be my last slide, but I must have passed over -- let me back up. I had one point on here that -- I guess I don’t know where the slide is on here, but I had one line on here for Jay, that you -- in responding to one of the questions, you got a good start, and the line was that we should provide Jay Epstein the opportunity to give us his top 10 lists of misconception about the FDA.

(Laughter)

MR. McCULLOUGH: And you gave us two or three already. But I think that would be -- it is helpful. I think it's valuable for people, all of us here, to hear your thoughts. And then by getting out those misconceptions, it's a way conversely to say here is how the agency is prepared and willing to work with everyone in order to move this field ahead. So thanks, I think, for inviting me to come.

(Laughter)

MR. McCULLOUGH: And that concludes my thought.

(Applause)

MR. MacPHERSON : Well, thank you. Thank you, Jeff, very much for doing this and for coming. Thank you, all for participating. I think you seem to be happier this morning than a lot of you were yesterday afternoon. Jeff said it kindly and I'll say it sort of bluntly, it was sort of amusing to me and very interesting to hear the friction going on back and forth between the QA and the -- quality people and the IT people because every time the IT people would say they wanted more choices, the quality people kept saying, "And things are fine just the way they are regulated."

(Laughter)

MR. MacPHERSON : So I think that it bespeaks that we have some job into actually even getting your own acts together in terms of what it is that we want given the tension that exists sometimes between the quality people and the IT people and the operations people, and then the CEO, which there's only about three of four here, of blood centers who want to try to keep the cost down because of either competitive forces or because of the pressure coming from hospitals to keep costs down.

So I think that, as I said, we probably need to do a better job, meaning, ABC, in trying to figure out exactly what it is that our members want. This conference ultimately goes back to -- as a series of recommendations back to, both, ABC and ABO. As I mentioned in the beginning the mysterious alliance upon operators, this conference is under their auspices. And that it's not actually all that mysterious.

It's -- the IT effort is sort of fledgling at this point. It's headed up by Terry Harns (phonetic) from Canadian Blood Services and there is a member from each of the groups. Angus is part of the group from -- representing the European Blood Alliance. We are part of the group. As far as their next steps, I think we're going other try and feed into them what we heard here, but, of course, there a more global component. The Australians are not here, for example, and there are very few Europeans here except for Angus and the young lady from Wales in terms of where that all feeds into.

But on a practical basis, I think we heard a lot of next steps. What we need is a lot more communication. ABC, with its members on these particular issues, I need to go back, we had started within ABC an IT working group. We started it primarily because of the launch of the data warehouse, but at this point it seems to need to take on a bigger role as to how it all feeds into the ABO group and who participates and how we better network within our own members.

As far as outside of ABC, if you add up ABC and Red Cross, it's 95 percent of blood supply, but that still leaves out hundreds of other players including people like Catharine Sasemu's (phonetic) group. And we can't -- we have tried to open up our membership, but our members won't -- don't seem to like that. But there are other avenues as we heard. There is a -- BB (phonetic) has an IT group, ISBT has a group, and a lot of the people that are in this room are part of those groups as well.

But I do think that as the communications gets out, it can only help. I will go back with Bob and with Rodeina, we will go back to the planning committee to see what they see in terms of next steps and to pick out from all the recommendations that came out in the -- especially in the last couple of hours of what we should pursue.

It's clear FDA is going back and taking a reexamination of what they do and how they do it. And as I think Jeff said, this is the beginning not the end. This is not a destination. This is the beginning of a process, and it's a huge process and it's an important process.

One thing I would throw out to the vendors, and it's just a thought, that -- and that is you don't have a umbrella group. You could have one. ABC and Red Cross together, especially under the ABO umbrella have been working more and more with AdvaMed. And AdvaMed has everything you need in terms of the relationships with FDA, the relationships on the Hill, in terms of any legislative agendas. They have the framework for dealing with proprietary issues and dealing with any trust issues for when you guys sit down and conspire to do whatever you need to do.

It's expensive, I know, to belong to AdvaMed, but at the same time, as I said, it is a group we are using more and more. They have a blood sector group, which tends to be mostly the other device manufacturers, if you will, the test manufacturers and the guys who make the blood bags and the freezers equipment.

Shelley is the only one here that I know who is part of AdvaMed concern, who is a member of AdvaMed. And how I first met Shelley was about 15 years ago when I was still in charge of the transition from Codabar to ISBT, you can see how successful I was in that, that we used to meet, I used to meet, with an IT group within AdvaMed that disappeared in the mid-1990s, I think, when the 510(k) regulations came out because, as Shelley said, some of the groups dropped out, and we haven't seen some of those vendors since.

But you new guys, the Wyndgates and the BBCSes and the Macs of the world are now a part of that group. So again, I -- that's a potential umbrella for you to work under, and I'm sure they would be happy to meet with you and at least talk about it and see what could be worked out. It would make it easier for us to organize you that way. I know Tim Coburn said, you know, that ABC has the power to bring you together and ABB does and whatever, but I think it's much better when you do it within the framework of your own trade association.

So that was one -- so that just was one more suggestions. Let me see my notes here. I've pretty covered -- I did want to mention something. And we talked about harmonization, and my good friend Angus coined a term a couple of years ago that I think we probably should use more than harmonization and it is called convergence.

Harmonization is a difficult process because you're trying to fit things together that sometimes don't fit, and you're trying to impose regulatory schemes in some areas in which the culture is not ready for it or they do the same thing but they do it differently. But if everyone who thought about convergence in that we all want to be headed towards the same goal, that whatever we do, we can't ignore the fact that there is much more global market out there and that there are vendors that are becoming more global, some of them already are. And so we need to all be pushing in the same direction when we talk about this. Rodeina has -- is Rodeina in the room? Oh, Rodeina has moved farther away from me. The --

(Laughter)

MR. MacPHERSON: One piece of advice for the ISBT group. We need to know what you're doing. I don’t think anybody knows what you're doing, and that's the problem with having a trade association -- oh, no, it's not a trade association, but a professional society with one staff person, but -- and all volunteer are free. But again, think about using the existing routes whether it's ABC or ABB or whatever organization that does have the ability to get that information out to its membership and that -- so I would say, you know -- because we don't know what you're doing. I don’t think most people in this room what you're doing, and -- or have seen your standards or read the efforts, which is a shame, which is a waste of time for you if people don't see it.

I think I have covered pretty much everything. As I said, it's sort of general. One thing, I think we have all your e-mail addresses, is that correct? Is that correct, don?

(No audible response)

MR. MacPHERSON: Yeah. We have all your e-mail addresses, of those of you who registered and didn't sneak in without paying. And so what -- again, we need to talk about some specifics in terms of next steps, and I think what we'd like to do is within a couple of weeks just give you an update in terms of where we are and also let you -- at least give you a link to the transcript so you can enjoy this whole conference all over again. When you can't sleep at night, then you can read it over several weeks as you -- just before you go to bed, and so you'll know where everything is out.

Fill out the evaluations, please. We need to know what you thought of the conference in general. Even if you don't talk about specific speakers, we just need to know if you -- what we're hearing that people say this is worthwhile, whether it really was. Those are really important. Even if you just take two or three minutes to write a few comments, we'd like you to do that.

And I think I am done in terms of any comments and next steps. And I will just wish you all well. It's -- we're letting you out 45 minutes early. The gift of time is always really a great gift. Thank you very much.

(Applause)

(Whereupon, the PROCEEDINGS were adjourned.)