My pleasure to present Chris Halls and Renee Engelhardt who will be talking about openoffice.org in Debian. Okay, thank you. Hi, it's nice to see so many people. We wanted to become one. I mean, OpenOffice is very popular among users that are to conference like this. There's not so many people that are interested. This is the Debian OpenOffice team. None of these people work full-time on OpenOffice. Well, Renee does a little bit in this day job. I work a little bit in my day job, but mostly we do stuff in our spare time. So, these two people are the people who process all of the bug reports and the packages, and so on, and I don't know how many of you have tried to build OpenOffice. Four to five, okay. Did anyone actually succeed? Oh, well done. So, yeah, and how long did it take you? I think it was overnight. Overnight, okay. But yeah, just packaging is a big job. And then, as Debbie maintained, we're also expected to coordinate with AppStream, who are about 60 developers, and also not really into the same type of free software as we are, most of them being at San. They just have a different view of the world.  And it's the same thing if we ask them, well, why are you writing this in Java? And they're just like, well, Java's quicker, and what's the problem? It's free. And so, we've got quite a lot to do. Yeah. So, we've got quite a lot to do. And I do actually wonder sometimes whether the maintainer field should be Debbie and OpenOffice team, because we often get mailed, like, could the team do this and maybe the team would like to look at this, and we're like, we don't have time. We're just trying to keep the packages up to date. Just keeping them up to date is a big job. So, at the moment, current status, about 321 outstanding, and this is climbing the whole time. Okay, so that's the bad side of our job. Let's tell you a little bit about OpenOffice 2. Everyone's probably wondering, when is it coming out? Well, so are we. OpenOffice 2, well, it was originally supposed to be out in March, April this year, and it's been put back for various reasons. There was supposed to be one beaten while it was really more like an alpha. So, there's talk of another beta coming out, and, well, there's no release date yet. But this is a time when you can actually test OpenOffice 2 and find out what problems there are before it actually goes stable. René's been doing most of the packaging over the last few months, and Matthias as well. Matthias is a Ubuntu maintainer, and he's helped us quite a lot with OpenOffice. So, we've got packages in Experimental, but not in Unstable, because the FTP masters aren't so keen on us having two versions of OpenOffice in Unstable, because it's quite big, in case anybody haven't noticed. Mainly because of the sheer size, the actual up-to-date version in Experimental is source and steps, 400 megabytes. One upload. So, I guess it's understandable why you don't want two packages of the option, and then the automators. Yeah, it grows with every version. Keep adding more and more stuff. It's another difference in mindset. These guys work regularly with Solaris and with Windows, and you don't have all of the nice package libraries together. So, what do you do to make it easier for developers? You lump everything together.  What's the biggest thing? Is there a gene they've been there at all the time? There was at some point, but just big libraries. We do actually patch them out in the packaging. That's one thing that René and I have been doing. As long as it's possible it's done. There is some libraries that are heavily patched inside the tree. ICU is megabyte and you can't build it out because it's so heavily patched. If the ICU maintainer wants a fairly patched version, maybe, but it's not happened yet, and AppStream wants to resolve that problem, but for later version. Yeah, AppStream have got a lot to do as well. Sun have got different priorities to us, and they're putting in new features, which may or may not be interesting for us. New database components are pretty good, apart from the fact that it is Java. They are putting more and more Java into OpenOffice, as you've probably realised. Thankfully, GCJ is getting better and better, and now with version 2 OpenOffice and version 4 of GCJ, we can actually compile OpenOffice with GCJ. Unfortunately, that makes it start up even slower, but we're hoping to be able to use the shared library, what is it, SO building of GCJ to actually pre-compile stuff, but there's some problems with the current version, so we'll have to see where we can get that in and working. But yeah, that's been a lot of top discussion. Richard Storman, for example, has actually been made regularly on the JVK list at AppStream trying to sort this out. So at least people have been taking an interest there, and that's moving forward. As far as the packaging itself goes, we have just been doing version 2 recently. There's a lot of bugs still to go, and one of the things that we've done is we've started moving over to use earlier to actually make it easier for people who aren't Debian developers to get involved. A year ago, at the last EPCOM, I stood here and talked to people about how to help with triaging bugs. We did get some help, but it's gone back to being just when I am myself really. Although OpenOffice itself is a big package and we use a lot of hardware to build it, there are still a lot of things that would help us. All of these bugs here, we try to work on the very serious severity ones. But if you go down to the normal severity, there are just pages and pages of reports by OpenOffice users. And generally OpenOffice users, on average, aren't used to writing bug reports as much as it might be for a more sophisticated development type of package. So we get really basic reports, and we have to spend time with every single one of these going back and forth with the user to work out what exactly is the problem and how to reproduce it. Just somebody who could help us with that, for example, looking at some bugs, that would help us get the countdown. There's a lot of really low-hanging fruit in these stuff that can be... Some of them may even not apply anymore. There is some bugs reported against 110 or even 103. I am pretty sure some of them don't apply anymore. Protracted is partly type-consuming, and the package can still go on. So it's not so easy to find out whether to close the bugs. Sometimes even the submitters don't answer anymore. Yeah. Yeah, just somebody going through and working out which submitters are timed out would help. Now this one, version 110, there's quite a big chance that that's been fixed already. Yeah, so this bof is actually a recruiting bof. No, not really. Do you have any questions about what we've talked about? So far, are there any of you who have some time and would like to help us improve the open-office packages? Oh, great. I wonder how many of you actually use the open-office packages. That's two in a room, so there's a lot higher than you'd normally expect. I mean, we do have millions of users, and most people don't really help us. And they also are under the impression that there are loads of people beavering away at Deviant to make these open-office packages. Does anybody have any suggestions about how we can actually get this message across better? Has anybody looked at the packaging, the project, the documentation? I'm wondering if I had the specific thing, the dictionaries. There was a thing I did some packaging for, not in Deviant, but a bit for the Deviant package work, which was a fairly easy dictionary installer for open-office, which would be installed either into the user or into the home folder. And now the dictionaries are sort of trickled in by the normal Deviant packages, and that actually has a lot more dictionaries available than the Deviant packages, and plus I suppose it would be easier to just package that instead of packaging every single dictionary. How would one go about suggesting a social thing?  How would one go about suggesting something reasonable? Talking about the actual technical issues and trying to establish why we've actually got the situation that we have. I might explain it to you a bit. The original upstream didn't have any installer at all. The MyStyle dictionaries do predate that. The advantage of having dictionaries as packages means that it's totally integrated with the rest of the system. But as you say, it doesn't scale. We don't have time to look after every language, but we would prefer somebody to look after their language. Since we have MyEyeSpell and Aspell dictionaries, it seems reasonable enough to say, here's the framework, go off and make your dictionaries, but as you say, they're not all done. Now, if you've got a... Sorry, Andrew. Just about the dictionaries, something that would make it easier to package individual languages would be if there was a framework which was just a single dictionary. The source package for dictionaries is a whole lot of dictionaries. That creates individual, deviant packages, which is fine if you've only got one maintainer, but if you've got one maintainer per language, it becomes difficult. I like being able to install a language support The point is that MyEyeSpell dictionaries can easily be built from the MyEyeSpell dictionaries. So what the most packages we do is not to take the zips from the upstream side, they convert the MyEyeSpell dictionaries into MyEyeSpell dictionaries. And so the maintainers are, of course, the family because it comes from the normal MyEyeSpell source package. Am I right, I think you were asking, is there like a template for a single dictionary? Yes, and it's about... We've had it for about three years, and it's in the CVS. But as Rene says, you can also build them from MyEyeSpell dictionaries. If you build from the zip files, you can get just the template. You can use the template, or you can use any other MyEyeSpell dictionaries because it's not built from an MyEyeSpell source package. But can we actually look at the idea of a central installer? The main drawback of it is that you don't have it integrated with your package database. How have you gone about solving that? What do you do? If I remember correctly, there was some time ago, if I remember correctly, you could give it sort of pre-seeded. So I suppose you could, on installing that package, you could let it choose why that comes with it, or the set of pre-seeds that are tied into the paper, whatever language you use on your system. And then it would obviously, on first run, automatically fetch those. That's a little hackish, I suppose, but might be easier as personally taking over the package. Okay, so it's something that you're downloading a bit like MSTT core funds or something, is it? Yeah, although the dictionaries are the MSTT free. Okay. And when you, you actually had that as a package? Yeah, I packaged that one. Some were, but I did not. Because obviously the framework was already there, you have your package, wondering if you, because I was also under misconception that there was an open office team working on it. And it might be a first step to alleviate some of your work. I don't think, well, by the way, my system, Yeah, that's a good question that is asked, does it conflict with my spell packages? What do you do with the dictionary list? Well, again, sometimes I'd have to look into that again, but from what I remember, even running it, I'll have to adapt some paths because there was written for red hat systems or whatever. But I don't think I've got any confidence. Again, I'll have over this. Yeah, what I meant, there's a single dictionary dot list file, and you need to maintain that file. Are you generating it automatically? No, it comes with the library. I actually don't do it. That's the problem. That's one of the things that we sorted with the MySpel packaging. There was a policy for that in place in the Lick Names comment package, which says the policy for Ispel, Ispel, and so on pages. And in the end, it was just provided info file for an script. Where you write in that info file what this dictionary list entry should contain. And at the post end of the packages should call your script, update on office tickets. And this script regenerates the dictionary list from scratch, preserving the eventual modifications but creating it from scratch. So that's everything packages installation has the new stuff we've got. Yes, so we're certainly open to it. Well, I'll have a look at that. Okay, great. Have a look at how the MySpel diction is worked with the updating the dictionary list. Yes, why not? Does anybody think of a reason why we shouldn't do that? Given that it doesn't work and it doesn't need to alter that. I suppose you're changing the user interface to how you install the diction. It's a DevConf interface, so is it? No, it's a GGA interface. Okay. I'm not sure about that. Sorry, Mattis. Okay, non-interactive. But my line's un-interactive. I'm not sure about that. I don't think anyone would think so. Okay. But yes, please look at it. It's something that I've been thinking about with this sort of data type of package where you've got masses and matters of different files per language or whatever. And it does end up not scaling perfectly when you're integrated into the package database. As you say, when there's more people making these dictionists and the package maintainers can keep up with. And where it's something regular like that, then yes, maybe we can find a better way of doing it. Did somebody look at what was facing MySpell with ASpell? Yeah. Now, the reason why ASpell could not be used on all platforms is because it doesn't exist on Windows, I would guess. I'm not sure, but it was a platform and compatibility problem. And efficiency as well, if I remember right. There was some technical reasons for not being able to use ASpell everywhere that you could use OpenOffice. I do remember there was an older implementation that used to use ASpell, but that was un-maintained. I don't think there's any real technical issues with using ASpell, but it would need somebody to maintain it. So it's just lack of manpower. ASpell wasn't a solution for all platforms. I think that's how it went. Do you know any more? No. That's almost everything. The license are compatible. So if anyone wants to buy the plug-in for ASpell, it's no problem. But I actually won't do it, and we will not have any range of... Anyone can do it using the RP. I think it's doing well. Now, there used to be an old implementation, but I guess it got removed. GCC-4, thanks to Matthias's work, we've got a lot closer to being able to use GCC-4. And they said it builds on i386, but not on other architectures yet. Is that right? It... I don't have the versions built on powerful C2, but somehow the registration of the components in the Office installation does fail now. I haven't yet used it. Why? Because I need to get packaging more finished. I hope with the new GCC it goes away. If not, I will have to look. On other platforms, it's more tricky. Spark didn't build at all. Even the 100 and i8, which did work on top of the i386, S390 didn't build at all, and M64 is the history for itself. Okay, we'll come on to 64 a bit later. I forgot to put it in the list actually. Okay, so why do we need GCC-4? The reason is that it has this symbol visibility feature. And why do we need that? Because by turning this on and hiding symbols from shared libraries, you end up with smaller binaries and you end up with a lot faster start-up performance. Over 60% are pro-quoted. I haven't actually tested it. And it says that it feels fast when it starts. It's effectively as fast as it is, but I haven't measured it either. So that for us is something that's quite important to do. I mean, packaging takes higher priority, but as soon as we can actually use that, it will make it a lot faster, easier, and quicker to start up. So, yeah. Doesn't 3.4 have visibility feature? Does 3.4 have the visibility feature? No. There is a patch which is available for it, but it's not in the Debian GCC. Red Hat and Sousa, I think, and maybe others actually applied that and have been building up an office with GCC 3.4, but we haven't been doing that. Well, it had for not being around the corner, then we must have thought about it. Sun, as they released the official in-store sets, we have two. They use an ONGCC also. Sun use the ONGCC. They use the C with the feature, and then build with that visibility. Yeah. Actually, at one point, I don't know if they still think that Vell was building an internal GCC just to build open office as part of their packaging. So, does this mean that a back port to search is going to be impossible or just difficult? Back port to open office or to? To. To search? To search. I just tried to... I figured. Because of GCC? Well, with those features, yes, it will be difficult. You can build it with C4, but then you don't have the visibility feature. The main problem with back porting is GCC, because if I want the users to have a future environment, I would need a back port of GCC 4 for search we got off GCC 4. Exactly. One day. Sorry. What we did for our woody back ports, which is another job that we've been doing, was to actually turn off features that weren't available. So, for example, I think the front config support was turned off, wasn't it? Things like that. So, actually going back to being more of a nilla version of the packages by doing that, we can actually get something that runs on an older one. So, that's probably the way that we'll have to go with Sarge, and if people want faster startup, they'll have to upgrade to Edge. Do you have any plans to do a Sarge back port? A Sarge back port yourselves? Well, I haven't got one at the moment. It could just be as we have time. I have... For the company I've worked for, we have... We've maintained some older systems, and occasionally I'm asked to do back ports for them, at which point I also check them in, and then, if it's not too much extra work, I'll then release them outside. But, yeah, at the moment, we don't really have enough time to maintain proper back ports, just stepping down again. As you know, just to put it quite out, they're calling GCC, do you know what they're doing? They're calling Sarge Java packages to be their port. That's what we're doing. So, you end up doing half a fetch anyway, just to... So, 30 Java back... 30 Java packages would have to be back ported for that. That's it. So, we need to get Edge out quickly. Yeah, that would be better. We could get Edge out quickly. But, truly, in the package relationships, there are some Java libraries in the defense. I would need to back port those through. I would need how to get them built on a Sarge system. I would need to back port GCC Field 4 for the Java stuff. You could disable the Java stuff, but then you have very interesting bugs in the Office Suite. So, it's not really... That's a good idea. In an emergency, yes, but I would not like to do it. Because a safe-ass dialogue who pops up every time you press Enter is not that funny. Yeah, that is true. I mean, if I notice correctly, basically, at Sun, there is a tendency right now to put a lot more Java than before into open-office. Do you feel that it might reach a point where it will no longer be possible to build anything useful for Debian because we don't have Sun's own GVM ported? No, because... Sorry, I should have to keep the question. Do we feel that there might be a point when the open-office packages are not really usable because there's so much Java stuff going in there? I don't think so, because we have enough influence to be able to say, Stop your... This is going in the wrong direction. It takes time to swing Sun, but the distributors, we do work together and have not insignificant voice. And also, the idea was that some would only start adding essential Java features once the free JDKs were ready to go.  It's more a case of the developers who are implementing the features don't realise the issues because they just use internal, their own Sun, and there are a lot of them, and it's very difficult to keep up with them implementing all of the new features. And also, there is this expectation that the free JDKs will get better. We did have an agreement with them that they wouldn't implement stuff that depended on new versions of JDKs, and that does hold. There are some features that need 1.4 JDK, but they're internally there on 1.5 already, but they've agreed not to use features, and also they have committed to actually replacing features that use proprietary Sun classes. They have done that to a certain extent. Again, it takes a long time, but they are working with us. They've also spent quite a lot of time in re-implementing the JDK loader, this JVM framework that actually makes it much easier to load a free JDK, well, a different JDK. So, such as a JCG? Yes, such as JCG, yeah. Okay, should we talk about 64-bit? Well, this is a project number, what was it, 284 in our list. It's actually from a 64-bit, and do you have a 64-bit machine now? No, do I. So, it's one thing that we've not actually per... it's not an itch that we personally have to scratch yet. It's an ongoing effort at SunSenseeers. They have at least two CVS branches for next now. Where the... CVS branches. CVS branches. Where the last one is still open, and now it's not yet finished. And Sun apparently doesn't do much work anymore, at least I don't see one. But some people from the community do now, and there is some slow, but steady progress. At the moment, rumors say it should build, it should start, but it should not be able to open documents. But at least it's a promise, it starts and builds. I should give you some background to this. OpenOffice started off a style office, and it was originally 16-bit. There's a lot of legacy code, and there are a lot of base classes that he used that make assumptions that you're not expecting to see 64-bit environments. So it's a case of going through all of the code and making sure that things work. You've got conversions from pointers to 32-bit integers, for example, and back again. And it's pretty fundamental. You have to go through and make sweeping changes to types all across the code base, and because it's so big, you've got a good chance of breaking stuff. So there are a lot of people that want to do it, and there are people who have been working on it for literally months already. It's just the code base is very big, and it doesn't all come quickly. Yeah. How big just to get the feeling of that? Code base. 8 million lines of code. I think 1.1 is 76, it's big. 1.0 used to be 70,000 swabs fast, and there's more now. My laptop here is a Pentium 3600 MHz, and it takes over a day nowadays to build open for some less. What does the ARM build demon take? For 1.1, it takes 7 days. That's actually one thing that we could improve a lot is to split things up a bit and not have to build it's one big chunk. The problem is that the current system works really well for the people at ARM because they all sit on the same network and they have an engineering department that set up servers, they've got NFS mounts with all of the source code. They don't even have to compile it themselves. It's actually, it will compile in a really modular way. If you actually look at the build scripts, you can treat each project separately. It's just that they like to distribute the source as one big block in 10 minutes. Wouldn't it be appropriate then for either the Debian project or some other open source player or distribution to basically ask IBM and one of the compatible manufacturer to basically loan us an SSH connection to a faster machine like a 1 or 2 MHz machine for both of the main architectures if we had hardware sponsoring. The problem with a remote machine is that you can't actually hack on the code so quick. And as I was saying, you can actually do incremental builds. The build systems fail sophisticated and you don't have to build a lot to do incremental stuff. If you're actually working on the code you don't need to do a lot of building at all. We've even got scripts that will link your active build tree into your system install so that if you're working on a slow machine you'll have to wait for the few source files that you've modified to compile but these will then be linked together into a shared library pretty quickly without having recompiled the rest of it and you can actually get the working out of this working. So it's really the speed of the machine that you're working at that's more important than the speed of the building. I mean, at Debian we have the build infrastructure and once we're ready we can upload it somewhere and it can go. What has been done is the tinderboxes, for example, to actually repeatedly build stuff. Novel, for example, sponsored machines. But if you think that's a good idea we'd certainly appreciate more help with hardware so please help us do that but we just don't have time to go and chase do political stuff as well as the packaging. Because one example that comes to mind that might be useful that happened recently is when the Mac Mini came out a bunch of powerpiece enthusiasts basically paid one to Benjamin Herringschmidt, the main kernel coder for PPC. Of course now we're talking about a fairly affordable piece of hardware, about 500 euros. But basically I'm thinking that what if company basically sent you, let's say, for six months some 64-bit hardware just to make sure that you get the part up to the perfection and then at that point we can resume using only the Debian Build D system. Yeah, actually personal hardware as you're suggesting actually getting a machine sent that would help us. We've got one back in the air anybody who's got a PowerPC machine will probably know this one. We've had, this is our oldest important bug the top one here and several duplicates that it crashes. It's really easy to reproduce if you try to load the bibliography but until recently neither of us have had a PowerPC machine. René's now got one but he's established it. I just tested it with a milestone and it didn't crash anymore and oh, lucky, okay, fixed. But the problem was I have this laptop since two months or so and before that I wasn't able to test it in any way. So... Yeah, that's made the idea of the machines. Did I get through my list? I live a project, did I mention that? Just that we've been moving stuff over to there to make it easier to for people who want to get involved to actually do something. One thing that we could do is is there anybody here who'd be interested in having a tool through our website? It's very out of date nowadays. There's the latest news. February 2005. Oh, we're done. Okay, I haven't done a user. But just somebody who's interested in the status. For example, the tool that was mentioned. Nowhere. Yeah, that's a true version too. Just somebody who's interested in following along a little bit and keeping up to date with what's going on and maybe saying on ISE what do you think... what do you think go 2.0 statuses or something and then just actually writing it up on the website, for example. That would be a big help. We don't really get a lot of constructive help on the mailing list. It's usually bug reports or complaints that the team haven't done this and that. But we really are open and we would like to help. Go on. It would help if the first paragraph of this web page would say that the team is two people because it implies that well, some people are working to get open of this running on Linux Alpha. It implies really a lot of people. Okay, this website implies a lot of people. This sentence is mainly referred to people who did the architecture part upstream. But you, of course, are right. We have more or less the same problem as the video game or security team. It's also written that it's a big team but it isn't. Okay. Yeah. Any volunteer? Okay. Any volunteer? Great, thank you. Anybody else volunteering? Yeah, great. That's good. We've had quite a few questions from Martin, isn't it? Cue Frank is I know you. On IRC. So yeah, that'd be great. We have our own channel and we'll sit there and answer questions when we... Please come and join us. And thanks everybody personally. Thank you.


I'd like to thank you guys for inviting me to speak about our work. Our goal is to address the problem of variants of uncertain significance to the development of high-quality, high-throughput functional assays. I'm going to tell you about two applications of that, the tumor suppressor BRCA1. So although the very famous hereditary breast and ovarian cancer risk gene, BRCA1 has been sequenced in at least 1.5 million people and has been the subject of countless research dollars. And there are still 350 variants of uncertain significance across the gene. In the literature, and there could be many more that have been, you know, reported by a myriad of different genetic testing companies. Somebody have the drum set. Mary, I need that drum set. Conventionally, we have tried to interpret the impact of variation through classical genetic experiments, like retrospective or familial studies, or one-off functional assays. But at the rate we're discovering VUSs in very important genes, like BRCA1, these methods, while they're highly accurate, they lack the throughput these days. On the other hand, computational predictions of pathogenic, of variant pathogenicity are obviously scalable, and as Daniel and Doug showed yesterday, they are getting much better, but they still could use some more work. So as a potential path forward that provides validity and throughput, we've been developing a toolkit of methods for functionally assessing hundreds of thousands of variants in a single experiment. So we do this with massively parallel functional assays, and they can be very different depending on your protein or your gene of interest. We call them massively parallel reporter assays when we're looking to assess mutations in regulatory regions, demutational scanning when we're looking at protein function, and saturation genome editing when we look to multiplex genome editing to look at either protein function or splicing. These assays measure different mutational effects, but they always consist of a few key steps. First we generate a library that contains all the variants for the sequence of interest. We and others have developed several ways to do this, and then we introduce those libraries into cells, and next we functionally characterize the variant library in a multiplex assay, meaning that although all the variants are present within the assay, we can simultaneously measure their activity, and for each, we might measure the, for example, we might measure the abundance of each mutation within a population of cells, both before and after a competitive growth assay, which is dependent on that protein of interest. The key here is that we can separate cells with that harbor functional and non-functional variants, whether it be through flow sorting, affinity purification, or differential growth. And this is by far the hardest part of development of any of these experiments. But yeah. And then we measure the abundance of each of these variants by high throughput sequencing before and after the selection using next generation technology. And finally, we analyze the changes and abundance to estimate the effect size for specific mutations on the functional activity of any sequence of interest. And today I'll tell you about our effort to apply demutational scanning and saturation genome editing to mis-sense mutations in BRCA1. So the first question when developing one of these assays, or what are the biochemical and cellular functions of the protein that we could build assays around? So first, BRCA1 is a large protein encoded over 24 exons, and all of those clearly have to be spliced correctly. And then after greatly oversimplifying the cellular role of BRCA1, the full-length protein is required for homology-directed DNA repair, and that's abbreviated HDR. I'll be using that a lot. The HDR activity is required for tumor suppression. BRCA1 has to dimerize with this other protein, Bard1. Otherwise, it doesn't fold at all. The two proteins interact at their end-terminal ring domains. And together, they actually form an active ubiquitin ligase. And most amino acid substitutions that have been found to be pathogenic in the protein are actually in the ring domain or the BRCT at the other end. But what we really want to get at is whether or not variants affect BRCA1's tumor suppressor function, but we can't do those experiments. But we do know, as I told you, that the ring domain of BRCA1 must bind to Bard1 in order for the entire protein to fold and function. Because if it doesn't do this, it just gets degraded. So to start, we developed two assays for two functions of the ring domain, and I'll tell you about those experiments first. And later, I'll tell you about our lab's effort to test the effects of SNVs on splicing in Exxon 18 using a different technology. First, we tested the effects of mutation of the ring domain on the ubiquitin ligase activity using a multiplex phage-based system that I developed. Again, we used DNA sequencing to track the abundance of each variant before, during, and after selection for this function. Variants with deleterious effects become depleted from the population. And we visualized these effects in a sequence function map like Doug told you about yesterday. So on the X axis, we have every position in the ring domain, and on the Y axis, all the possible amino acid changes. And above are just diagrams, the structural features of BRCA of this domain. Shades of blue represent variants that were depleted relative to wild type, and red represents variants that were enriched during selection. So we took the same library and we tested for effects of variants on the ability of the BRCA one ring domain to bind to the barred domain, and we did this using a multiplex these two hybrid assay. Again, sequencing the population at multiple time points, and yeah, so there are striking patterns in these maps. So you can see here that these are stop codons, and they are bad for function. So that's a nice control. We always like to see that that's working. Additionally, these areas in loops one and two of the ring domain are required for ubiquitin and ligase function, and in general, those are more deleterious to protein function than other mutations. Whereas in the same domain or in the same regions for barred binding really, only the zinc binding amino acids that are really important for the structure of BRCA one are really intolerant to mutation. We also found regions in the four-hill expundal. This is actually new information that these four-hill expundal amino acids are really required for binding. There's really interesting things in these maps. As a biochemist, a trained biochemist, for example, there's an arginine to lysine change that makes the ubiquitin and ligase 100 times better. Who knew? And these are really fascinating, but that's not what we're interested in. Ideally, we'd like to use our data that we collected in model organisms to estimate the likelihood that any variant would be either pathogenic or benign for hereditary breast and ovarian cancer. However, there are only 18 variants classified as pathogenic, and three is benign in the domain, and that's not enough to build an accurate model. But what we do have are HDR rescue experiments for many more BRCA1 variants. And so thus far, all the HDR activity assay for BRCA1 has been 100% specific and sensitive to both benign and pathogenic mutations in the protein. So we felt like this was a good proxy. So we trained a support vector regression to transform our ubiquitin and ligase and barred binding scores into HDR activity predictions. And we next compared the accuracy of our model using leave-on-out cross-validation to variant effect predictors like polyphen and CAD. And you can see that they do a fairly poor job predicting the effects of amino acid substitution in BRCA1 on its HDR function. Molecular effect predictors grant them an aligned GBGD, do a little bit better. But our empirically derived E3 and barred binding scores do a lot better at predicting whether or not the full-length protein is going to be functional. In addition, when we add the best performing molecular effect predictor, aligned GBGD, to our data and retrain the model, we don't gain any extra information. Since we had trained a good model, we applied it to our data to predict HDR activity of the BRCA1 variants that have been identified in patients through clinical testing. And the results are showed in these histograms. All of the benign variants are predicted to have high HDR function, whereas most of the pathogenic ones have low HDR function. We misidentified this guy. But these two are splice variants. And this is a caveat of using CDNAs. And I'm going to tell you about assays that and get at splice variants next. But what we do find also is that six variants that are currently classified as VUS are predicted to have very poor activity, whereas 13 are predicted to be just fine. But beyond those just seen in patients, we have an additional 1,200 variants that we can use to predict HDR function. There's a bimodal distribution of predicted effects. So while some variants are predicted to have poor HDR activity, many more would have wild type HDR activity. While we would predict that proteins that are amino acid mutations that fall here have done so much damage to the protein that we would predict them to be pathogenic, whereas the guys in the high HDR that are predicted to have high HDR function might be benign, except again, these are CDNAs. And we really don't know anything about splicing. So I'm going to tell you about our work to assess SMVs on Exxon 18 splicing using saturation genome editing, which is a slightly different method. So the first step in a saturation genome editing experiment is to transfect CRISPR-Cas9 and a guide RNA, targeting your sequence of interest. And in this case, it was Exxon 18 of BRCA1. And to edit the genome, we also transfect library of repair templates that contains SMVs over the Exxon of interest. At a low rate, the repair templates are incorporated into the genome, and this creates a heterogeneous population of cells. And after five days, the genomic DNA and the RNA are collected in selective PCR that only amplifies the edited genomic DNA and CDNA are used to amplify the Exxon. Like before, each variant in the genomic DNA and the RNA samples are counted by next generation sequencing. And the effect of each variant in splicing is determined by looking at the ratio of the RNA over the genomic DNA. Again, for CDNAs that are depleted, that ratio will be lower. Shown here are the ranked ratios of CDNA to GDNA for a single experiment. And you can see that edits where a splice enhancer is created, shown in Richmond, are a stable amount of CDNA. Whereas when splice silencers are nonsense mutations that trigger a nonsense mediated decay or created, those RNAs tend to be depleted from the sample. And this is a sequence function map for splice effects of 98% of the possible nucleotide changes across Exxon-18. You can see where there are large depletions of CDNA, it was either due to a position being changed to a nonsense codon and therefore triggering nonsense mediated decay. Or in most cases, they were also predicted to be effects splicing by the mute-pride algorithm. And this guy right here is a VUS, valine 1714G. So I would say that that's probably pretty bad. So clearly, we're in need of new technologies to deliver on the promise of genetic medicine. And we believe that massively parallel technologies like the deep mutational scans of the BRSA1 ring domain and the saturation genome editing of Exxon-18 that I told you about represent at least a partial solution to the problem of VUSs. But I don't want to discount what we've already done, but as you might have already noticed, BRCA1 is a lot bigger than its ring domain or just Exxon-18. In addition, there are many more genes that one might say are high-value targets. In my mind, I see the hereditary cancer risk gene panels, but many people in the room probably have their own list of genes. There are challenges for scaling up. As I told you, the first step in these experiments is library construction and variant delivery, and we think we're actually pretty good at that. And the next thing we would need are parallelizable assays for protein function. And we're working, as Doug was telling you yesterday, about more generic assays that get it protein folding. But we're not biologists, so if anybody has assays for their favorite gene of interest, we'd be interested in hearing about them. It would also be great if there were a suite of genes that could be tested using the same assay because this is the most difficult part. So for example, BRCA1 and a lot of the other proteins that are involved in double-strand break repair can all be tested in the same assay, which is very nice. Sequencing of variants, we've got that. Doug's group has built a very nice computational scoring pipeline. And then again, we like to use these scores to calculate likelihood estimates for pathogenicity or damage to the protein. And we'll just need access to large-scale projects like EXAC and the forthcoming PMI. So we believe we could, by doing more scans of high-value targets, that information could be useful immediately. That would create better databases. So when somebody comes in with a new mutation or a new variant, that those scores would be out there. And then those data can be used to build better variant effect prediction models like Doug was telling you about yesterday. And I'd like to thank all the people that helped me with that work. Thank you very much. We'll have, as you remember from the format, we'll have some time for a few questions for this presentation. And then we'll also have the open discussion. And the good news is there's only about 20,000 candidates for your list. Yeah. So I think you'll be in very good shape for a while. It's fine. It's just fine. Sorry? You can't. All right. Dan Rudin's being literal. So we'll have to, yes, 40,000. All right, Howard. So that was very impressive. I'm just curious on what cost and scale. So in terms of scaling up, what's the cost and what's the time window? Because I think part of the challenge in thinking about how do we go forward on this is, so can you give us some feedback on what the cost and time would be to do what you just did? Well, we were learning. I was exploring a lot of the space around experimental mistakes. So now that we've got some of that down, it takes a bit. But again, it's the functional assay, the building of a functional assay that takes the longest. So if somebody came to us with biology in hand, we can build the libraries and get the sequencing done and do the experiments within a few months. And then the data analysis on the other end is also the hard part. So building these models and building error models around whatever the assay is is actually quite difficult. So would that be $250,000 for the gene in six months of two postdocs? Because I'm just trying to get a sense. I get you ahead to build it. But I mean, if we're thinking about scaling and trying to do $20,000 or whatever the number is, it's just useful to get an idea of what does that mean. What does that mean? Oh, please. Let's go, Weiss. It's $20,000.  So that's where you'd start. You start with something that's practical, manageable in the context of what we're actually trying to return. It's those genes where the VUSs are causing the biggest problem. So I think it's a much smaller number than you guys are talking about. And even in the context of somatic sequencing and cancer, we might have 700 genes on our targeted panel, but only about 150 of them are regularly returning results that we even think about acting on. So you're right. The universe is not $20,000, but it's also more than one. Yes. And also, we're hoping that by taking large gene families. For example, the ring domain is there's a family of 600 of them in the human genome. So we're hoping that some of our results at least will build better predictive models immediately for entire families of genes. Peter Dahl. Is your model trying to replicate the germline or somatic situation? And by that, I mean, the function might be different in the germline setting where it's the only gene mutated as opposed to the somatic situation, where there's a bunch of other genes that are also mutated. That's an interesting question. I think we're really just trying to get at the function of that protein. So we're trying to build these assays so that they are sensitive to mutations in that protein and that protein only. So I guess it shouldn't really matter if it's germline or somatic. But I'm not sure how to answer that question. All right. It'll be Mike and Kalman and Gail, and then we'll have the next session. So Mike? Really interesting work. I have a question about the splicing component, and perhaps it's too early to know the answer to this. But do you have a sense of when you looked at Exxon-18 and Bracka-1, where was most of what you're finding things that would be generalizable to other Exxons, or was most of what you're finding something specific about the regulation of that particular Exxon-Exxon joining event? Because I'm wondering, are you creating a resource that you could use to study all of splicing? Right. So actually, most of what we found with the splicing actually is fairly similar to what's predicted by algorithms that are already out there. So I don't think there was anything special about Exxon-18 in particular. It's just more to show that we can do these experiments at scale in multiplexed assays, I think, was more at the point of that experiment. But yeah, there wasn't really anything special about Exxon-18. Kelly? You alluded to sort of universal assays or more broadly focused assays. Have you tried any unsupervised or supervised learning methods with a simple cell system or something along those lines? There are some very successful phenotype-driven drug screens that have been powerful even for non-cell autonomous phenotypes in cell autonomous states. We have not tried that. We're looking at generic stability assays right now. And that will be an interesting thing to apply to those, I think, machine learning algorithms. So. Gail? Yeah, I'm glad someone else said the ACMG-56. One of the other classes in that, besides cancer gene or the channel genes and cardiac arrhythmias. And I guess I've wondered about it's not as scalable, but Xenopus oocytes and looking at channels and whether one could think of something like that for that group and whether any of the folks here who work in some of the models could say something about that. So we have the fallow reagents in our lab. And we're starting not with we picked the wrong channel to work on first because we picked a really big channel to work on first. So we're doing the same thing Doug did. And we're sort of honing in on a particular domain. And the really interesting question is whether you can develop high throughput assays that don't rely on electrophysiology. There are multiplexed electrophysiologic assays that you could do in multi-well formats that allow electrophysiologic readouts. We think what we're trying to look at is generic questions like does this variant prevent a channel from getting to the cell surface? Does this variant allow a channel to find its partners or not? So those are going to be easier for high throughput. But at the end of the day, we may end up having to do the electrophysiologic measurement. It'll probably be in a transfected cell as opposed to a frog egg, which is big and technically not the right way to do it. And the other idea, of course, is to incorporate IPS cells into all this, which is sort of like down the road, I think. Way down the road. Doug is nodding. We're not quite there yet. Yes. Yes. Leah, thank you very much. Excellent.


Well, thank you very much for this great invitation to be here today. I want to thank Eric and Barb and Colleen also for this wonderful invitation. I also want to thank Karen, who long ago and far away when we were both at Georgetown got me into the genetics of smoking and thinking about clinical translational issues. And I feel like this work really has the potential to affect health outcomes on the ground. It's very exciting to be working in an area where you feel like you can make a difference in people's lives, unlike some of the things that we do that have less applicability in the immediate. So challenges to successful translation. There are multiple challenges to translating exciting, novel, efficacious applications of genomics research into clinical practice. Tailored smoking cessation treatment is exciting because it would be potentially the first PGX treatment in primary care practice, a group of physicians that historically have not had much experience with genetics outside of the OBGYN context. So providers' willingness and capacity to incorporate new pharmacogenomic treatment strategies into practice is a major potential hurdle. Secondly, patients' willingness. And here there's two points of willingness. I think most of us have focused on consumers' willingness to undergo genetic testing in order to receive tailored treatment. But as you'll see in what I'll present later, a critical piece of this is patients' willingness to follow the treatment recommendations indicated by the test. If we don't have that second piece, we're dead in the water. There are also a host of coverage and financing issues. I also have a background in public health and in healthcare financing in the public sector of Massachusetts. And I'm happy to take questions on that. Right now, for example, pharmacotherapy is covered in about 66 percent, for 66 percent of folks who have private insurance, but only 16 percent of Medicaid, of this as a means tested low-income segment of the population, have access to coverage. So those issues are also important. And then lastly, there's the logistical hurdles. I think that we forget the primary care physicians, more than half of patients are seen by primary care physician practices that are either solo physicians or a partner, just two doctors. And many of them throughout the country are still the traditional model. You have the physician with perhaps his wife as the secretary, and that's it. So when we think about clinical integration, half the population is served by these very small physician practices who probably are going to be the last adopters of EHRs, right, and who don't have the infrastructure to think about delivering this kind of complicated service, then we really need to think about them also. So in the interest of time, I'm going to focus heavily on providers' willingness and capacity and patients' willingness and capacity. I also am a health disparities researcher, and I know that NIH has a commitment to ensuring that novel treatment strategies reach those most in need. As Eric has said with Mark, genomics will only achieve its full potential to improve human health when the advances in engenders become accessible to all. And we'll also face the greatest challenges dealing with underserved communities, and we don't want to leave them behind. Otherwise, the trajectory in terms of smoking-related morbidity and death will really become a much larger problem proportionally. So let's start with providers. A few years ago, this is work that I did with the T-Turk funding from Robert Johnson Foundation that partnered with NCI. We did a random sample of 2,000 physicians in the U.S. We had a great response rate, and we were trying to identify challenges anticipating. One of the things that was very forward-thinking about the T-Turk program is that they had Robert Johnson Foundation partner, and the idea then was, let's not just do the science first, but let's simultaneously try to anticipate and address issues in translation that we think we can be facing. So we did a lot of work with primary care physicians doing intensive focus group with physicians in D.C., Boston, Chicago. We did one-on-one interviews. We did cognitive testing of all new survey elements, because at this time, this is about seven years ago, folks were really not conversant in genomics, particularly primary care physicians, and we wanted to make sure that this would work. We also did a pilot under actual survey conditions. And what we found, which was similar to some other research in smaller populations of physicians that were out at the time, is that only 5 percent of PCPs felt confident in their ability to interpret genetic test results, and only 4 percent fell prepared to consult patients considering a genetic test. In terms of ever-ordered, in their practice history, ever-ordered any genetic test, we weren't surprised that it was 60 percent because of the OBGYN-related tests. And those tests need to be made available for Medicaid providers as well. But we had about 30 percent of physicians who had ever ordered a test for VRCA 1 and 2, even once, at about 16 percent for colorectal cancer and Huntington's disease as examples of other tests. Obviously, they don't have the infrastructure or the knowledge and should not be ordering tests primarily. They should be referring to specialists. And so here we saw that 62 percent of primary care physicians had ever referred a patient to genetic testing for a testing center or counseling. And 62 percent the same had ever referred a patient for a specialist for the patient's condition. Interestingly, only 16.7 percent of PCPs nationally had ever referred a patient to a clinical trial. In a more recent survey by Stanek and colleagues that was in nature last year, we can see here in terms of pharmacogenomics in particular that a very, right now we, you know, the understanding of pharmacogenomics is not the problem. 13.6 believed genetics affects drug response. And 30 percent have received PGX training in medical school or postgraduate training. What's interesting here is that you see the last three bars here. You see an interesting pattern where 26 percent anticipate ordering a test in the next six months. However, only 10 percent feel informed and only 13 percent have ordered a test in the last six months. So there's this kind of optimism about their capacity to be able to deliver pharmacogenomic treatments. So the barriers now are not so much understanding the basics of PGX medicine, but rather what tests are available, how do they procure them, when do they use them, how do they interpret the results, and how to apply results to an individual patient sitting in front of them in real time. And here EHRs, Electronic Health Records, could be a major facilitator to clinical translation of these novel treatments. Our team at Harvard was the research team for the Office of the National Coordinator for Electronic Health Records and had hit adoption in the U.S. And we had done a lot of work with physicians, the first physician survey and hospital survey about hit adoption. And now we're at the point where about 70 percent of primary care physicians are in a practice that has an electronic medical record. And this is really tremendous progress due to the focused federal support for this. And a very interesting wrinkle that we'll get to when we talk about community health centers, which is a safety net provider serving exclusively almost, minority, uninsured, medicaid, insured, and other underserved patient populations, because of the recent funding at the federal level, nearly all health centers will have an EHR within the next year or so. So that's really a great thing to take advantage of. So in terms of looking at the variation in early adopters of pharmacogenomic testing, I want to point out here that if you look at these oncologists, not surprisingly, have had much more, have had much more experience. But you can see here that family and general practitioners, primary care providers still have had very little, this is from last year, have had very little contact with pharmacogenomics medicine in their actual practice. So in terms of the work when Karen and I first started out with the work with a T-Turk, what we were doing was trying to understand how would physicians respond to a new genetically informed test to tailor smoking treatment. So we had a randomized scenario in which the new test, half the group received a survey in which the new test tailored treatment was described as a protein, something based on serum protein, and the other half the test was described as a new genetic test. And just that one difference, just the word genetic reduced PCP's willingness to offer the new test to their patients by 11 percent. That might not sound too dramatic, but when we convert these percentages into daily smokers, it's actually four million daily smokers who would not be offered the test, just because of that reticence around the word genetic. We also were interested in thinking about the genetic variants that were under study at the time. We created a clinical scenario that was very realistic, it was based on Karen's research and other research at the time about the likely test characteristics, and we gave them three additional facts about the test after getting their first response. Once we said in addition this particular, and again these were still randomized, this particular genotype or protein has been shown to predict an increased risk of becoming addicted to nicotine in the first place, other things to consider, that the prevalence of this genotype or protein is approximately 43 percent among white smokers and 53 percent among African American smokers. And the same genotype or protein is also associated with an increased risk of alcohol and cocaine as well as some other conditions. So they're getting at the pleotropy of the variants that were under study at the time. And you can see here that you're controlling for a range of physicians' characteristics, demographics, their own smoking status, what year they graduated from medical school, their practice setting, their current smoking treatment practices, and their general attitude about genetics, that each of these additional facts reduced physicians' willingness to offer the test to their patients. And again I should say this is stated willingness because we're trying to anticipate and we don't actually have an intervention to offer them. Just to further complicate things, we also found significant differences in patient and physician attitudes about willingness to incorporate genetic testing to tailor smoking treatment into practice by the self-identified race of the physician, him or herself. And here you can see that Hispanic physicians were much less likely to state willingness to try this new test. And then also there was some variation across the different facts that we provided in terms of test characteristics. Since my work is in disparities, I was also interested in looking at how adoption might be different or how the experience and trying to anticipate issues for minority serving physicians. And we define minority serving physicians. We looked at the percent of their patient populations that were from minority communities. And we ranked them nationally. And those in the top 20% were identified as minority serving in terms of the distribution. So we saw here that in terms of ever-ordering a genetic test, that those that were minority serving in the top quintile were significantly less likely to have ever ordered a BRCA 1 and 2 test, a test to assess colorectal cancer risk, and a test to assess Huntington's disease risk. Now as I said, we would expect them to be referring. But here we found some interesting results. We still are in the direction that we think, although the first two were not significant. But ever referred to a clinical trial was really interesting, particularly given the trouble recruiting minority patients to the study populations. So ever referred to a clinical trial, this is ever in their practice history. Maybe half as likely to have ever referred a patient to a clinical trial. And then also Medicaid. So Medicaid providers, Medicaid generally reimburses at rates lower than private insurers. And people who are high concentration Medicaid providers definitely are more under-resourced settings. They see a lot more complex patients, poorer patients with multiple comorbidities. So we also saw that this is another factor that we need to keep an eye on. And I want to talk a little bit about community health centers as an example of what the IOM report identifies as safety net providers. So these are providers who either by mission or who by mandate, as in the case of CHCs, they run out of the HRSA program here. And basically community health centers by law have to take all comers. They have no option to turn a patient away. So when a new novel therapy or some new capacity comes online for CHCs, they operate at practically zero margin. So they really need special targeted financing. The only way that CHCs are ahead of physicians in general is because of targeted financing for EHR capacity in CHCs. So anything special needs a special pot of money for CHCs or it will not happen. And as you can see here, fully, we're looking at close to 80% of their patient population, 85% that are either Medicaid or uninsured. Okay, this is a very depressed group of patients in terms of finances. And that in terms of reaching the minority populations, minority smokers, you can see here that basically about 60% of their patients are a minority. So if we develop some effective strategies that were targeted at community health centers, we basically have a ready infrastructure. There are about 1,000 community health centers right now. We have a ready infrastructure to disseminate to community health centers. We're capturing 10% roughly of all minority, uninsured, non-English speaking, and migrant patients in America, just through this one provider group. So we did some pilot work funded by NHGRI where we were asking them, they're mandated to provide OBN, GYN related genetic assessment. So we're interested in what other kinds of genetic tests they might be providing. And this is either directly or through referral, because again, they have very little capacity on site. And we found that there was 5.3%, that was it, that had had a capacity to get their patients, BRCA 1 and 2 testing, if it was indicated by clinical guidelines, about the same percentage for colorectal cancer, Huntington's disease even less, sickle cell more, largely because of the population that they're serving. So minority patients are likely to face greater challenges in accessing the quality genetic services. They're overrepresented among low literacy patients, so there's implications for informed consent. They're more likely to be served in settings with less skilled personnel and lower quality care. And so there's poor access to health services in general, due to health insurance issues. They're disproportionately represented among underinsured and uninsured, okay? Underinsured where you have some bare bones plan that will cover you if you get hit by a truck. But short of that, you're probably out of luck. So now let's move to the patient perspective. And the question is, if we build it, will they come? If Karen and Rachel are successful in coming up with this biomarker that's really ready for prime time, will patients be willing to undergo the assessment in order to NMR testing? And then will they be able to follow the treatment results that are indicated by the test? So with work, this is funded through the LC program. We have completed recently a national digital survey to investigate lay understandings and beliefs about the role of genetics and other factors in addiction. And we didn't want to look just at nicotine. We also wanted to see if there were cultural differences. Is this between black and white adults? Because we didn't have the funds to have adequate sample size for other racial and minority groups. So basically we wanted to look at whether alcohol and cocaine, these patterns, differed by those substances. And among smokers, we wanted to assess their willingness to undergo testing to receive tailored treatment. So as I said, 2,400 adults in the US, this is a random digital survey. We achieved a 40% response rate among those who we actually were able to get to as a live person. I mean among those in general, which includes people that we just got an answering machine. But among those who we actually made any kind of personal contact with, we had 81% participation.  So we did a lot of work. We're trying to understand what are the consumers, what are they thinking, and how might that thinking affect their willingness to undergo NMR testing. So we did a lot of focus group work in rural Alabama and in the city of Baltimore and Boston to try and come up with language that reflected the way that the average patient that was less than a college education would be thinking. And we came out with this question that took a lot of work and a lot of field testing. And this had to be something, remember, that could be asked easily on the telephone. Please pick the choice that you think has the greatest influence on a person's ability to quit smoking. Would you say willpower, having family or friends who support the quit attempt, a person's genetic makeup, using medications or smoking cessation counseling and having God's help? And these were generated again by this extensive qualitative work. The results are very striking. As you can see here, African American respondents, 50% rated having God's help as the most important factor in a person's ability to quit. And 58% of white respondents rated willpower as the most important factor. And in multivariate analysis, controlling for age, sex, education, smoking status, self-described religiosity. So we're already controlling for that. And health status. Blacks were still more likely to rate God's help as the greatest influence with an odd ratio of 4.7 and less likely than white smokers to rate, sorry, this isn't the smokers, this is everybody, and less likely to rate medications as the greatest influence. 0.41, a very striking finding. And we found also that these views, that this cultural difference really persisted across substances. So you can see here, in terms of having God's help as the greatest influence on a person's ability to quit, it persisted across nicotine, to quit drinking, to quit using cocaine, very consistent results. And in terms of rating medications as the greatest influence on a person's ability to quit, the results for black were very less consistent, but all in the same direction and all significant. So in terms, let's turn now to those results were for the whole entire RDD survey of 1,200 blacks and 1,200 whites in the US, a nationally representative sample. Now let's turn to our 392 smokers. So you can see here, not surprisingly, that the portion of smokers that had ever used medication for smoking cessation, 32% black and 57% white. The proportion would ever use counseling, again, a racial difference. But then look at the next one. The proportion rating medications and counseling is very important. So here, you have black smokers rating medication as much more important, even though they're much less likely to ever use them. And then, of course, we have this difference in terms of having God's help. And in our regression model, with willingness to undergo genetic testing to be matched optimal smoking cessation treatment, we had an odds ratio of 8.94 in terms of those who believe that medication or counseling on the ability to quit, if they believe that that influence was very important, they were nine times as likely to say that they'd be willing to undergo genetic testing. And then look at the odds ratio in terms of the influence of having God's help, a completely opposite effect. Now, we need to address these cultural differences in consumers and smokers' views. We need to identify new strategies to engage black smokers, because what's at stake here is, particularly among black men, you see that they are much more likely to die of smoking-related illnesses. And as I said, if we don't solve these problems now, these racial disparities are likely to increase. Almost the more successful PGX smoking treatment is, the more dramatic the black-white racial disparities gap will be in smoking-related illness and death. So smokers' attitudes and beliefs, I believe, are the linchpin to realizing the promise of genetically tailored treatment for smoking. And it's these two things. I want to come back to this point. It's the potential of pharmacogenomic treatment strategies. It depends on smokers' willingness to undergo genetic testing to be matched to optimal treatment, but this other piece about using medications indicated by the test results. That's the other piece that we need to keep our eye on. And concerns about the translation have really focused more on the genetic testing and racial differences and willingness to undergo genetic testing in various contexts. But the real barrier, I believe, is in the bread and butter issue of smokers' willingness to use medications in general in order to help them quit. And so here we have pharmacogenomics research actually pointing us back to a very fundamental issue in tobacco control. And with black smokers, there's a particular conundrum. So black smokers are far more likely than white smokers to express a willingness to undergo genetic testing. And this is a nationally-represented survey with a very good response rate for a random digital. But African-Americans are less likely to rate medications as having the greatest influence. And this is substantiated by actual past use. Black smokers are less likely to have ever used medications than a previous quintetempt. So we have this disconnect. So they're willing to undergo genetic testing, even though the purpose of the test is to match them to optimal medication. So what is this having God's help thing about? What does this mean to black smokers? And how does this affect pharmacotherapy use? Might this be a new link for trying to understand low pharmacotherapy use among black smokers? 79% of African-Americans, according to a recent Pew survey, say that religion is very important in their lives compared to 56% of US adults nationally. So to try and probe this, with help from NHGRI, we've conducted some other formative qualitative research in order to direct our future research in this area. We conducted 12 African-American extra focus groups, sorry, six extra focus groups in rural Alabama and inner city Baltimore, going back to the same sites where we went originally in designing our survey. We had about a dozen African-American smokers per group.  So if we can move this group of black smokers into a willingness to use medication to help in a quit attempt. And on a screening survey, they rated having God's help as the most important.