Dr. Donald Fortin led the development of the Duke Information System for Clinical Cardiology (DISC) software. In this interview, he speaks about his attempts to market the databank software to other physicians.
JESSICA ROSEBERRY: This is Jessica Roseberry. I'm here with Dr. Donald Fortin, and it's July Eighteenth, 2007, and we're here in the Duke Medical Center Archives. And I just wanted to thank you so much, Dr. Fortin, for agreeing to be interviewed today.
DONALD FORTIN: Oh, glad to be here, glad to be here.
ROSEBERRY: We're going to be talking a little bit about the cardiovascular databank history, and I wondered if I might start by asking you just kind of the beginning of your involvement in that project.
FORTIN: My involvement actually began shortly after I arrived here as a cardiovascular-cardiology fellow within the Cardiology Division. I got involved in a couple of projects with Dr. Califf and Dr. Pryor that ultimately evolved into my doing the research aspects of things within the cardiovascular diseases databank. It involved looking back retrospectively at the previous five years experience with coronary angioplasty within the division. We ended up actually doing a number of interesting things. It was sort of a crossroads time I think both within the databank and within information technology. We had an opportunity to begin testing out some new technologies within the computer realm involving things like relational databases, which were just coming into vogue in '88, '89, which is the timeframe I'm talking about. And we got involved with-graphical user interfaces were just coming into vogue as well, so we actually did a couple of sort of, I think, cute things retrospectively. We simultaneously on a couple of different fronts began developing new systems. It was all specifically for this particular project (the retrospective look at our angioplasty experience), but it formed a foundation for a number of things that were to come later. We began retrospectively going through all the information that had been collected on those angioplasty cases that I was referring to, and that information was in a variety of different places. Some of it was just stored in SAS datasets. Some of it was stored within TMR, the Electronic Medical Records System that Ed Hammond and the Family and Community Medicine Department had created. Some of it was stored isolated in the Cath Lab, and what we did was we began putting all those pieces of information together within a single relational database. We also retrospectively re-evaluated all the coronary angiograms. We (Jack Cusma, Tom Bashore, Larry Spero and others) developed some software to analyze the coronary angiograms and then to record using a graphical-user interface some of the details of the coronary anatomy that were then merged together with the demographic and procedural data that had been collected. That formed the basis for a number of things that were going to occur in a short time in the future, jumping ahead a couple of years.
ROSEBERRY: May I ask what the timeframe-?
FORTIN: Well, this took two years to accomplish, get our feet wet, get an understanding as to sort of the size of the task that was ahead of us, and then I ended up joining the faculty in 1991 and spent the next three years beginning to look at how migrate from where the databank was to the next iteration of where the databank, at least the clinical side of it, was going to go. Within the databank itself, we were-I think this may sound a little more dramatic then it probably really was, but the databank was at a crossroads. A number of the people who had been involved early on had either physically or intellectually moved on to other things looking for new challenges. Drs. [Robert] Califf and [David] Pryor, who had been jointly running the operation for the better part of a decade, really began to diverge in terms of their overall interests: Dr. Califf focusing much more on the clinical trials aspects of things; Dr. Pryor on outcomes research, and you began to see sort of the evolution over a relatively short time period into two main groups or divisions within the databank and the clinical piece, the piece that started the whole thing, was sort of in no-man's land in between them. Neither one of them wanted to claim responsibility and take the helm. They unwittingly or wittingly found someone to participate in this exercise, and that was me.
ROSEBERRY: The clinical piece.
FORTIN: The clinical piece right. Although I did have my hands and feet firmly entrenched in both camps for a variety of reasons. But in '91 I sort of took over the operational reigns of the clinical piece of the databank.
ROSEBERRY: Still observational? Was that still kind-?
FORTIN: Still observational, yes. Although it did form the basis for some things that were occurring within the outcomes group if there were outcomes that were-outcomes, endpoints that were being evaluated by the outcomes group, formed the basis for a number of things on the clinical trial sides, if there were clinical trials being performed. And it was really, I think, the ability to go back and forth between the two groups. Sort of take the best of both worlds thinking about how changes in information technology were occurring and beginning to put all that together into sort of a game plan to begin proceeding forward. You have to remember back in the '89 to '91 timeframe, we were still talking about DOS-based PCs. The concept of things like networking were still in their infancy. The Internet was several years away from even being an idea in Tim Berners-Lee's mind over at CERN. So we were in the stone ages in terms of computer technology. So we began this iterative process of beginning to put our thoughts together for how we wanted to evolve the databank, and the best way to go ahead and do that is obviously to look towards past successes and how those past successes were implemented, how they were received and how they were used. So we went back to the very beginning. We began looking at the first system that Dr. [Frank] Starmer put together, CIRCE, and the way that that particular software evolved. Unfortunately I arrived several years too late to actually see this in operation, so I can only go off of what I was told-what information was relayed to me, but it really sounds as though it was a very practical operational implementation of a very nice piece of software that solved a lot of logistical problems at a time when there were enormous constraints on computing technology. People used this apparently day to day in their clinical practice. The volume of information accumulated pretty dramatically over a relatively short period of time, and it became immensely valuable to people doing clinical research.
ROSEBERRY: Is that the-it's the interface for the clinician, is that what CIRCE is?
FORTIN: CIRCE was the-my understanding-again, I never saw this thing, so I'm going off of the information that relayed to me, but it was really the entire package, I believe. It was the constellation of the user interface as well as the underlying, the database underpinnings that formed the usefulness. It had a number of things that were added onto it. There were a number of, I'll used the word nomograms for lack of a better term, but a lot of scales that were implemented into it that allowed the practitioner to get an idea as to how well the patient would do with various types of treatment. The prognostigram, that's the word I was looking for, was one of those things that came out of it, and my understanding was it was implemented into the software directly so that as you completed their catherization report, the prognostigram nomogram was automatically output and gave you an idea as to how this patient might fare with medical therapy versus bypass surgery which were the two main forms of treatment at that particular time. We also looked at the then current implementation and I spent a fair amount of time with Ed Hammond talking about what his thoughts were for The Electronic Medical Record [TMR], how TMR was actually used within Community and Family Medicine as a day-to-day practice tool and how it was used in cardiovascular disease where it was a hands-off, a very back-office type application that the clinicians never touched. And that was a decision that was made of how to implement the system-that decision was made long before I arrived, so I won't claim any special knowledge of how or why that was done. There were lots of unique things about how TMR was implemented that we sought to go ahead and see if we could replicate in a completely different environment with a completely different set of constraints and again tried to take the best of CIRCE, the best of TMR, and then thinking about how to go ahead and put all these things together for the future. That was really where DISC, the Duke Information System for Cardiovascular Disease came about. At its core, it was really a relational database with a graphical-user front end (i.e., Windows). We tried to do a couple of things that emulated what went on with CIRCE and the Family Medicine implementation of TMR, which was to put it back in the hands of clinicians, not necessarily the attending staff, but we tried to dangle a carrot out there for the people in training who were the ones who were mainly responsible for filling out a lot of the data-collection forms and completing sort of a bunch of the baseline work that went into compiling information for the databank. We worked with a group of software programmers up in the cath lab to build a nice graphical user interface that was an extension of the previous work that I had done looking at the angioplasty population. That information was now integrated in with the remainder of the clinical demographic procedural information. We extended to application in collaboration with the folks in the cath lab to incorporate inventory control and other procedural details directly out of the monitoring modules that were used in the cath lab itself, and then the carrot for the cardiovascular fellows was to set up the user interface so they could enter the information directly, generate their own cath reports, eliminate the middleman so to speak, and give them immediate feedback as to what was going on. We built in just enough data validity checks to make sure the data was going to be rigorous enough for future researchers and voilą! the process that used to take could take sometimes weeks depending on the backlog of information and forms that were waiting for data-entry personnel to enter, get questions resolved, et cetera, really could be done within the space of several hours after a procedure was being performed. The graphical user interface allowed people to literally point and click information so that in a matter of minutes after a procedure was performed there was something they could slap in the chart that gave a very nice graphical depiction of what the coronary anatomy looked like or post procedural details or whatever.
ROSEBERRY: So any kind of information that they were looking for? It was to be used for their own-?
FORTIN: Right. Right. And it was meant to be, to really try and bring this back to as near real time as we possibly could for its implementation. It was interesting trying to go ahead and implement a lot of these things in a very busy clinical environment such as Duke. There's a lot of things going on. There's a lot of moving pieces and parts, a lot of fits and starts in terms of making it all happen, a lot of tuning that went on behind the scenes. Ultimately it actually went live on April First, April Fool's Day of 1994. It had a couple of hiccups over the course of the first couple of weeks. The initial focus was on the cath labs, the intervention labs and I think maybe the treadmill and the nuclear medicine laboratories, and that was where we initially started. Ultimately we moved all of the modules over so that areas like Center for Living and Pediatrics and a number of other areas that were not necessarily part of the core types of things were ultimately incorporated. The cool thing was that they actually shared information among all the quote-unquote "modules." There was a core set of procedure or event information that was immediately available to people looking at the system from anywhere within the application. So if you were in the treadmill lab and I was in the cath lab, as soon as you entered the treadmill information that was immediately available to me for review and also for incorporation into my reports, so I didn't have to then re-key all that information in, so it really in some respects was sort of a little mini medical record, a very small snapshot of the overall medical record but a mini medical record for use within the specifics of cardiovascular disease. So along the way a number of people saw the interface, saw the kinds of things that were being done, got pretty excited about it. Thoughts of moving things off the confines of Duke campus came into play. There were a number of candidates for migration. There were mobile cath labs that had to record this information. A very Rube Goldberg type system had been setup so that they could communicate back with TMR to enter cath lab information.
ROSEBERRY: Is this still within Duke?
FORTIN: This is still within Duke. There were actually cath labs that were mounted in eighteen-wheel trucks that went around to a number of communities that did not have permanent cath lab facilities of their own at the time. So they would drive the truck out there, set up shop, perform the caths, and then they'd have to record the information. Well, they were Duke physicians, so they were used to doing things the way that they were doing them on the Duke campus, so they wanted that same look and feel to everything. So we came up with DISC on a PC. Took an ordinary PC, loaded all the software, stuck it on the truck and voilą! you had the entire system sitting now on a little personal computer instead of running on a VAX or some other little mini computer. So that was sort of another step forward. Along the way other interested parties got involved. Dr. Charles Bethea at Oklahoma City, the Baptist Medical Center, was really beginning to get very, very involved in terms of really focusing on outcomes and how those outcomes played into interactions with payers and enhancement of types of services that could be provided to the patients that he was taking care of, and he was very actively involved in a number of initiatives with Dr. Pryor and the outcomes group, so it sort of became a natural evolution to move the software out to his location. There were other sites that also got migrated. I guess its called Northeast Medical Center these days in Concord; the old Cabarrus Medical Center was also another site where software got moved.
ROSEBERRY: This is the same software?
FORTIN: Same software, just basically now it's DISC in a box that you just pick, load everything onto a personal computer, ship the whole thing out. It could run on a laptop if you wanted to. It really, the software was miniaturized in such a way that it essentially became a commodity, I think is probably the most straightforward way to think about that. With the idea that it could become a commodity, then you begin thinking about, Well, can I shrink-wrap this stuff? and that was where I think the opportunity to potentially move the software out into the commercial arena really began to come into play. There were a number of folks in the chancellor's office who were interested in technology transfer who began to see some potential opportunities out there in the commercial arena for more commercialization of the software.
ROSEBERRY: So there wasn't necessarily a need for-within your group. It was an opportunity to make this available.
FORTIN: Right.
ROSEBERRY: Externally.
FORTIN: Right. It's one of those-I think it's one of those things that happened sort of about the same time we'd been doing a number of interesting things with some software companies. We were the first academic site to get involved with Microsoft for the Windows NT Operating System, and there were a number of things that we got to test for them. They actually invited me up to Redmond [Washington state] to speak a couple of times on the use of their technologies within healthcare, and it gave us a couple of interesting presentations talking about the trials and tribulations of-healthcare dollars are stretched in this particular times-it's gotten worse since then, but the healthcare dollars were stretched-there's a lot of information technology needs, a lot of those needs are unmet, commoditization of the software, of the components that are necessary for really figuring out how to roll all this stuff out was very important, and we needed to do it in a low-cost way. Along the way we ended up getting lots and lots of either reduced or free software to go ahead and focus a lot of the development efforts on, and I think it was exposure to some of those aspects that I think put the highlight on a number of things that did make it commercially viable we began thinking about moving this out into that realm. Being a very long extended courtship over a couple of year timeframe, trying to figure out who was going to be the best suitor, i.e., Was this something that you'd approach venture capitalists for, was it something that you approach another software firm for? and in the end it came down to Summit Medical Systems, they were located just outside of Minneapolis, became the strongest suitor to go ahead and license the technology from Duke. Summit's strengths at the time were that they had relationships, single-vendor relationships as a matter of fact with the American College of Cardiology and the Society of Thoracic Surgeons to provide software and to create the national databases for both respective groups. So from their software they would-they use the term harvest-they would harvest all the data, incorporate that into a single large data warehouse and then publish annual reports on a number of procedures being performed, a number of the demographics of subjects, et cetera, et cetera, et cetera, and that model they used to actually expand into other arenas besides cardiovascular disease, but they were told, they'd just gone public in the '97 timeframe, and they were told that their software needed a jump start, that it was old-timey software, single-user, that the mode of software in healthcare was going to this client server technology with a central relational database, graphical-user front end, and that was sort of where we came into play. That was the underpinnings of what we had. We were in a similar therapeutic area, cardiovascular disease. We captured and were contributors to a lot of the database fields that were being collected by the American College of Cardiology and the Society of Thoracic Surgeons, and it sort of became a natural fit. It turned out to be the best overall fit I think from a commercial standpoint and seemed to make synergistic sense at that particular time.
ROSEBERRY: May I ask who some of those other suitors might have been?
FORTIN: Actually the majority of them were either electronic medical record vendors, who couldn't quite figure out what we were all about. We were such a narrow slice of the pie but very, very detailed, whereas they were very broad-based but very shallow in terms of the amount of information and kinds of information they were collecting, and they really couldn't figure out what the fit was going to go ahead and be. They were also concerned that there was finite marketplace. There's only so many cath labs or were so many cath labs and so many interventional programs, and so many bypass surgery programs in the country that they were concerned that even if they captured a majority of the hospitals or centers within the US that that was going to be insufficient to maintain cashflow sufficient to go ahead and support the products out there. The other group were venture capitalists who were interested or were not interested actually probably for similar reasons in providing seed funding for something that was so narrowly focused. So there was a big push to, Well, we'd be interested in funding this but only if you can broaden the areas that you're capturing information into. And while those things were on the books for future endeavors within the medical center, it wasn't going to happen in the timeframe that we were looking for, so-and the decision was made to license the technology to Summit Medical Systems.
ROSEBERRY: So there was a sense that it would expanded, it would be broadened?
FORTIN: Well, I don't know that it was necessarily ever discussed internally. It was certainly my hope that it was something that we could go ahead and do. There was nothing unique to cardiovascular disease that was, there was nothing specific within the way that we had designed things that would limit us to cardiovascular disease. It was really a matter of finding enough willing people within the medical center to work on the development aspects and find sufficient funding to go ahead and make it all happen. The cost of developing software, as you are probably aware, can be; it's an awful lot of money that's involved. You've got to pay software developers. You've got to buy software for the development environments, and a lot of that has really come down in price, but the people price of getting the experts involved to go ahead and build the software the right way, build the database in the right way so it can be extended and then getting the interested parties to provide you with, a, the initial concepts of the kinds of information they want to capture and then that ongoing feedback plus the final implementation is very costly. It runs into the millions of dollars. It ran into the millions of dollars even for us to go ahead and just simply transfer existing ideas, concepts and data to a new platform being done in a little bit different way, but it's extraordinarily costly, and it's costly to run on an annualized basis. So.
ROSEBERRY: So Summit.
FORTIN: So Summit licensed the technology, and we ended up forming a joint venture between Duke and Summit. It was called Cordillera. Cordillera is a geologic term that talks about that is a mountain range where all the peaks are united so it was sort of a little spoof on Summit, which their logo was a mountain. So we were because of our network technology we were uniting all the individual little peaks. It was cute at the time. We ended up taking the technology, adapting it to the commercial arena and rolled out a commercial product that Summit could go ahead and sell that captured the American College of Cardiology information. The Society of Thoracic Surgeons had a built-in data warehouse so that all the information could be integrated and summarized and reported on, done in a client server environment so that there was central relational database multiple workstations all over the place. It was rolled out in the October, November timeframe of 1998. I may be off by a year. It may have been '97 when all this occurred. But it was either '97 or '98, and there were some problems at Summit. They had exclusive relationships with the Society of Thoracic Surgeons and the American College of Cardiology, and one of the challenges that came up was the societies decided that they wanted to go through a much more formal request for a proposal process. They wanted to see other vendors come into the mix, and they weren't willing to sign an exclusive relationship. There were grumblings from a number of the members that the cost of the software was too expensive, that there should be more things being done gratis for the membership. The price of the software for the Society of Thoracic Surgeons was six hundred and twenty-five dollars with a two hundred and fifty-dollar annual fee to go ahead and collect, harvest, and report all this information, just to give you a feel for the amounts of money that we're talking about. This is the same timeframe that healthcare was undergoing sort of a major upheaval. There was a big shift towards HMOs and major cost constraints were occurring. So at the same time we're thinking about rolling out a much more expensive client server-based package which is going to be significantly more expensive then six hundred and twenty-five dollars and two hundred and fifty dollars a year for maintenance, we're running into a cost-constrained environment, and it was already constrained by there's a fixed number of cath labs, a fixed number of bypass surgery centers within the country, and it was not a pretty sight. So you have a company that all of sudden is losing its main revenue stream, it's losing its exclusive relationships and it's trying to roll out a much higher-priced package. And there were a number of other internal issues related to some business dealings that the company had done that led to a huge amount of internal turmoil, layoffs, cost-cutting within the company and a decision to go ahead and turn the company into a different environment. It was still a publicly traded company. It still had cash in the bank. A new CEO was brought in who thought that the best thing to go ahead and do was turn the organization into a CRO, a clinical research organization, to focus on clinical trials. At the same time that technology was licensed from us, licensed from Duke to incorporate into the corporate scheme, they'd also purchased a consulting group consisting primarily of ex-FDA personnel from the Center for Devices and Radiologic Health, the medical device side of the business. It was strategically a good fit in terms of the overall focus of the company, because they were primarily focused on cardiovascular devices. So with the help of the people from the consulting group, the company turned into a CRO and ultimately ran as a CRO and then ultimately was acquired in 2002 by a much larger CRO, i3 Statprobe. So that's sort of in a nutshell the history of sort of where things went. One of the questions that I get asked on a periodic basis is, Was Cordillera successful? what was the downfall of Summit? We'll start with the first one. Cordillera was the joint venture where we licensed the technology. Summit were the ones who licensed the technology. We ended up-the group of software developers that were employed at Cordillera repackaged the thing based on the specific needs requests and requirements that Summit placed upon that. So that software was re-engineered, but it was Summit's software to go ahead and sell and support and really do whatever they wanted to go ahead and do with it. Our mission was actually to begin developing web-based technology, and we had initially focused on a Web-based registries of information, take a look at products that had been approved by the Food and Drug Administration for which there was additional information that was being requested either for safety reasons or for marketing reasons by the device company or by the drug company. And we ended up doing probably one of the very first Web-based data collection systems for a product of one of the large pharmaceutical companies.
ROSEBERRY: When you say we, that's Cordillera?
FORTIN: That was Cordillara. Yeah. Collected information on seven thousand subjects, complied all the information into a series of monthly reports so that the individual sites got feedback on how they were comparing to a number of other academic and community sites in terms of their particular use of this product, the kinds of side effects or adverse effects that were being seen in the particular populations, whether the drug was being used for the approved indication or not, did it fit the profile that was on the package insert label, et cetera. So we think Cordillera was extremely successful. We had a very large project out of the box that we successfully completed within the allotted budget and allotted timeframe. Clients seemed very happy with the work that had been done. So from that standpoint, we were successful. Cordillera was acquired, though, by Summit later on that same year. So ultimately our fortunes went the way Summit's fortunes went, and things didn't turn out the way I think that all of us had hoped or intended. It was a very good environment to learn an awful lot of things about the business side of things, the interface between business, business academia and the field of clinical research. So I don't think that necessarily it was a loss. There was obviously some very painful times that occurred during that whole exercise, but I think it was a very valuable exercise at least for me, let's put it that way.
ROSEBERRY: Do you think that software was ultimately marketable?
FORTIN: I think in retrospect there was probably a reason why the venture capitalists didn't bite, (laughs) and in large part I think it was because there was really not that mass-market appeal. There's a couple of different approaches to selling software, one of which is you come in at a very low price and have a very high ongoing maintenance fee that allows you to have a sustained revenue over an extended period of time. The other of which is to come in at a high price and a much lower thing where you get that upfront money for which you can then use to drive a variety of other development projects. Summit didn't choose either one of those. They did an awful lot of work really for the customers without necessarily recognizing what all of this was costing them internally. It was a very expensive proposition to go ahead and collect all this information and to go ahead and massage it, analyze it, and then report it, and I don't think that people put two and two together in terms of what-the costs were exceeding what the money that was being brought in. And they did not adjust the efforts so that those two things matched, nor did they go back to the respective societies to say, Hey, we have a little bit of a problem here, we're not making enough money to be able to support the activities that are occurring. A painful lesson but not atypical of a lot of things that went on in the Internet boom where people thought that you can make an awful lot of money by developing software without necessarily doing a whole lot of things or that, I don't have to worry about the future here, it's all about the immediate period of time.
ROSEBERRY: Well, how did this affect Duke?
FORTIN: Actually I don't know. I'm probably the wrong person to ask that, since I was out on the outside of the fence.
ROSEBERRY: So you had left the fence? You had gone over-?
FORTIN: Yeah, I had stopped practicing medicine in early '99. I met with people here periodically on an ongoing basis, but that was not a topic that I brought up. It was just not something that came up during our everyday conversations. I think people were aware of what had gone on and what had happened, but it was something that was licensed to an external group, and it didn't turn out well. It's not going to be the first. It wasn't the first, and it won't be the last of these types of things that happen, so I don't think in the end that there was specifically any major harm that occurred to the university. The university retained the rights to use the software to modify, to redevelop, and re-license it as a result of this thing. So I think that if they chose to again proceed down this particular road if they wanted to go ahead and look again they certainly could.
ROSEBERRY: So they could use the original design that you had-
FORTIN: Yeah. Although my guess is that the original design has evolved, or I hope it's evolved since-in the last ten years. I think the big problem though again as in 1996, '97 is, is there enough mass-market appeal, does it reach a broad enough section of the marketplace to be able to be self-sustaining, because that's really the critical component. It's a very expensive venture as I mentioned earlier, and you need to have sufficient revenues in order to be able to keep the boat floating in order to provide additional enhancements and incorporate new features as they come along so.
ROSEBERRY: So do you know if it's still being used within Duke or-?
FORTIN: Yes, it is.
ROSEBERRY: May I ask what you do now? What you're-
FORTIN: Yeah, actually I actually run a small company that provides data management, statistics, and medical writing services to pharmaceutical, biotech, and medical writing in medical device clients. So I guess we're probably a small CRO, if that's the term that you want to go ahead and use. I had run, when the company, when Summit morphed into a CRO, I ran a similar group within the company that changed its named to Celeris. I ran the group for five years and had some definite ideas about what I wanted to do and how I wanted to provide services to people and hooked up with some old friends in 2003 when the company had been acquired and have been having an awful lot of fun over the past four years, five years in working on a number of interesting projects. Interestingly enough most of them are not cardiovascular related, but I get to live vicariously in all these other areas, so it's worked out well.
ROSEBERRY: Do you have a programming background or-a medical background.
FORTIN: As you're aware I'm a cardiologist by training. I got involved very early on in a number of these relational database things, and while I don't have-I took a number of programming courses when I was in college. They didn't have degrees in programming back then. I'm showing my age, because we were still programming on punch cards, just to really date myself. I took a number of programming courses then really began using computer programming in a number of things related to just research that I was doing as an undergraduate, and then when I was in medical school wrote several software programs actually related to the Nutrition Department and some things for diabetes research in terms of how to come up with schedules for people so that they could do their food exchanges. So while I don't have a degree in computer programming, I've been doing this for thirty years now.
ROSEBERRY: Well, are there any questions that I have not asked you today that might need to be covered, anything that you'd like to add?
FORTIN: No, I don't think so. I think I pretty much rambled. (laughs)
ROSEBERRY: It's been great.
FORTIN: I rambled through pretty much everything. (laughs)
ROSEBERRY: Well, thank you very much, Sir. I appreciate your time today.
FORTIN: Sure. Thank you.
(end of interview)
|
Questions? Comments (919) 919-383-2653 dumc.archives@mc.duke.edu Last modified: September 27, 2007 |
|