Okay, so we've had a number of discussions today about this series of six questions. And what I'd like to try and do during this session is to spend a little bit of time looking at each of those six questions and what some of the different discussion topics were that came up and trying to look a little bit at if we've one captured all of the important items that came up because I was trying to pull this out of the summaries while we were having the discussions and to which of them do people think are the most important and most critical for the UDN going forward. Just a little bit of background to make sure we're all on the same page as we start thinking about this. The Common Fund Phase 1 support for the Undiagnosed Diseases Network runs through fiscal year 2017. We're now in the process of going through our continuation renewal phase 2 proposal process. And that would be for the next five years starting in fiscal year 2018. The Common Fund does not support programs for more than ten years, but that does not mean that NIH funding would necessarily end at that point. It just means that there has to be a plan for transition and sustainability of the program past the point in time that the Common Fund would be supporting it. So when we talk about sustainability we're really looking at are there ways that we can leverage the way that the program would be funded in the next five years to be able to try and help us get the answers that we need to be able to make it more sustainable when we get to that end of ten years of Common Fund funding to be able to help move it into either another part of the NIH or potentially out into other parts of clinical care and research. So these were the questions that we had in the agenda. We're looking at what are the best opportunities and justifications for continuing the UDM? What should we be emphasizing? What can we think of deleting or adding? And then how are we going to be able to prioritize these different topics? And we really want your feedback. So what I've tried to do is summarize the discussion so far, but if there's something that I have missed, please let us know so that we can capture that and make sure that it goes in at when we start preparing recommendations from this meeting. So under the intensive clinical evaluation, question one, we had a lot of talk about how should we be genotyping first or phenotyping first and could we potentially develop a best practice by looking at these two different options within the UDM and maybe having an answer by the end of another five years of funding? Related to that question, there was some discussion about the need to make sure that all of the data would be captured in order to be able to put together this kind of best practice guideline that we would need to have the phenotype data even if we genotyped first, that it was really critical to make sure we had both halves regardless of which order the evaluation was done in. There was also a call to collect environmental data, more history data, epigenetic data, and really think about the interactions between the different types of data that we are currently collecting as part of the UDM and potentially some of these other avenues as well. There was discussion about if there should be a reasonable minimum core dataset, potentially a set of phenotypes that would be collected on all participants in the UDM or some other type of uniform phenotyping across the network and how this could potentially help in recognizing patterns in the data. And then finally in this question one, we discussed that we could look at having focused expertise potentially at some of these sites or maybe looking at being able to disseminate these practices so that more of the local clinical communities could do some of the work up first before these patients made it to the UDM. So my first question for folks is, is there anything major that we missed? So I think I heard that some of the cases where there was a variant which you wouldn't bring in, there could be some kind of short work up or there could be some expertise applied to them, maybe without their even coming in, but that there be a different, still different kind of either center or work up, short work up without all the other stuff, but interpreting what was there, something like that? So that could potentially build off of what's captured here is this idea of a local work up first, potentially is there a way to either do the outreach to the community or it sounds like you're also suggesting that there might be the smaller way of people being able to have access to resources. I know I have that captured later in some of our discussions. Okay, Rachel? Well, I'm actually stealing one of Darcy's points here and he and I were talking about potentially, you know, as, and as Wendy was bringing up as exome sequencing, etc. becomes more, more universal, potentially having that as a as a first pass screen, whether it's paid for by insurance and is required to apply or that we pay for that we don't necessarily bring in everybody for the full phenotypic work up, if we can make a diagnosis that sufficiently matches their phenotype before they come in and only bring in those people who present deviations from that phenotype and or in whom we don't find a ready answer in the sequencing. And that then led to a discussion of is there the idea of capturing the phenotype in a sufficient way? How much of a work up is required in terms of, you know, a minimal phenotyping? Is there a way to scale that back at all so that we make it make it more generalizable to the general practice? Thanks, Rachel. So to your first point there of doing an exome on everyone first, I see that as being a little bit contradictory to the first point here related to being able to get the phenotype data on everyone. So I'm just curious what the group thinks about this idea of extending an enrollment criteria that would require having the exome first versus the idea of needing to be able to have both the genetic and the phenotypic data and what's the relative importance of those? So I think we shouldn't make a hard and fast rule. It depends upon the patient to patient.  In other cases, you need to look at the patient first. So I don't think this should at all be a hard and fast rule. I think there would also be some difficulties with access to the program if we were to require an exome first because of insurance payment being an obstacle. Although I would say in the scheme that kind of we were discussing, it was that not that you'd have to have it before you'd come in, it could be provided to you at a step before actually bringing you in for for the intensive clinical evaluation, which is I think by every account much more, much more costly than the than the sequence analysis. It's also a geographic consideration. We're already getting patients a thousand miles away. So we'd like to have some data before dragging them down. I want to do things in an orderly way. So I don't think we want to be hemmed in either. We need that option. And I think another point to remember here is that when exome or genome is done clinically, that is kind of different than what is done in in the UDN. We are we are doing quads and we are doing trios, where most commercial sequencing, which many of these patients come are just end of one. So when we look at the data, we kind of analyze it kind of differently because we have the benefit of having other family members. Great. So are there any other points to add? Yes. Yeah, do you then repeat when you do a quad? Do you then repeat the patient on whom somebody else had just done an exome sending spending a thousand dollars? Yes, there are some individuals who had pro band only exome and with a non diagnosis they may add additional family members. But I think the field really is moving more towards trios and to a lesser extent quads. So I think that's really going to become the standard, especially as sequencing costs go down. Okay. So Susan, give another point. Just we were just having a little sidebar here, which is making sure if you did try to get commercial sequencing data, getting it released is sometimes tricky. Not if you're in a center that can release it to itself. But if you have to get it from somewhere else, it can be hard. So I think most of the commercial laboratories, if not all of them do have a mechanism for release of raw data. There are some hoops that you might have to jump through. But that's really just to protect the data. But but I think most labs are considering that the patient does own their own data, and they will release it with some assurances. Yes, Cindy. I'm not trying to get free exomes on my patients, but you know, 50% of our patients have Medicaid and in our state Medicaid just started covering a small amount for microarrays. So you know, whole genomes are way in the future for them. But I think in trying to make sure there's more diversity among the patient population to, you know, facilitate maybe pre exome analysis, you know, in order to maybe be seen in the major UDN center, but to, you know, allow other patients to to get in. Okay, so if we've covered the general topics that were discussed during question one, are there any of these topics that folks would give higher priority to when we're thinking about how to design a phase two the next five years of the UDN? Yes. Well, this is perhaps a little biased. It being that I represent the metabolomics core, but I guess point three, should there be a minimum core data set? And I guess this gets to the question of how do you define a diagnosis to a degree? I mean, sometimes you get a diagnosis, you find a gene and that makes everything clear.  So, you know, is there a minimum data set should we couldn't do it with current budget? But should all patients, for instance, get a metabolomic profile on top of everything else? So you've got a larger data set, maybe addressing pathophysiology, etc. There was a lot of discussion about the importance of that kind of thing. So just something to throw out. Thanks, David. And I think that we can touch on that a little bit more. There'd been in some of the other questions, a lot of discussion about potentially needing to increase the funding to the core. So I think we can get back to that point there. Does anyone have any other items that they would really call out as being higher priority than the others? Or do you see these as being pretty equivalent kinds of recommendations? So what about lower priority? You can say that you think one of them is lower priority to that is helpful. So I think I'm going back to us. Steve Prescott was talking about earlier, is that we need to think about, for example, environmental history and epigenetics, because that I think again is mission creep. We're not going to have enough ends to really make any sense of that data and that all that hard work. So I'm not saying we shouldn't do it, but I'm saying that I think that point needs to be, again, rethought of. Yes, Howard. I would like to recommend that we be careful on prioritizing this area. We have about 170 people that have gone through this so far. The clinical workups are still going on. We're still trying to figure out where we are. I just would think we have a little bit of time on this before we get too far in this because I think by August, we're going to have more information to know what to think about. So I just urge caution on prioritizing too much here. I think that's a very good comment. Right now, what we're really trying to get is a general sense of are there certain items that people think are really critical to what makes the UDN the UDN? And are there certain things that have been discussed where people think that yes, that's something that we might need to keep in mind. But after the discussion, people think that that might be a little bit of a lower priority given what has come out as being where people see the UDN as potentially going for a phase two. Yes, please. I'll ask a historical question. In the UDP, has there ever been a finding that depended on the environmental history or the survey of the patients? And again, my part of my criticism is we start talking about objective data and this is not. Now we had a case of chromium and selenium toxicity where the Chinese nutritional people had put in 1000 times the amount that they intended to. So but that was pretty obvious. We didn't need a survey for that as it turns out. So I think this is ancillary information. Okay, any other comments on question one? We just had our first five day inpatient admit so it's not been abandoned. We're just being conscious about where we use it where we don't. Okay, any other comments for question one? So this may not be the right time, but I thought there was some suggestion that different units might do different things and that that was a plus because there would be multiple experiments or contrast between the units. Yes, you could have some variability. Part of that is this idea of, you know, potentially focused expertise, but it is also captured under one of the other questions, the idea of being able to have data from the various different types of potential ways that the sites are doing things. Okay, so for question two, the transitions of care, some of the things that we heard in the discussion were that the primary mission of the UDN is diagnosis, but we need to think beyond that and how you can change the life of a particular patient that right now the UDN is isolated from clinical care and practice, that we need to think about how to translate what the UDN is doing into a clinical care setting, that we need to think about how to make the research components more accessible and potentially leveraging other collaborative networks and research opportunities, that there was a need for a standard plan for what would happen next to these patients, that once their UDN evaluation was done, that it would be useful to have some sort of standard process for how the patients were handled in their transition back to their referring physician. And here's the point that we're just talking about there with Judy, that there's a need to capture, evaluate, and refine the diversity that is present in the clinical sites and that we need to really make sure that we're capturing this information so that it can inform future versions of the UDN. And then finally, once again, going back to this idea of leveraging existing resources and thinking about what already is out there in the community and what needs to be developed. Are there any major points that we missed from question two? Yes, Brendan. I think when you talk about leveraging existing resources, a lot of times we think about NIH supported, but there's enormous infrastructure out there that's industry sponsored, that's, you know, institutionally leveraged, and that's both at UDN sites and not at UDN sites. So I think it should be interpreted very broadly because I'm sure, you know, you find a variant in some phenotype. There is somebody in, you know, broadly speaking who will have resources beyond just obviously an R21. So I guess it should be broadly interpreted. I think that's a great clarification. Does anyone have anything else to add to the question two? Yes, Christine. I think we should have a definition for recontactive patients, especially for new gene diagnoses. So how far out are we going to be doing this? Is it five years, 10 years, forever? I think that's a great point. We can add that in probably as a clarification to the idea of a standard plan for what happens next with each of these patients. And Kalim, did you have a comment? I was just going to say I'm not sure. I agree that it's that isolated from the practice of clinical medicine. I think, you know, as Bill has said, it's really a return to the way that clinical medicine used to be practiced. It's this is by virtue of the diagnosis, you're bringing them back into traditional clinical care. And I think I'm just saying from the standpoint of portraying this to a council or whatever, just trying to make sure that it doesn't seem that the UDN is completely isolated from standard practice. It's an extreme of that spectrum. So perhaps focus on how to translate this back into clinical care and practice versus that the isolation aspect. OK, Sue, did you have another comment? I was going to second that motion because I think you will be enlisting the primary providers, whatever only are on the spectrum, that aren't part of your investigation team in continuing to facilitate that exchange information with the subject. So it's something about communication probably belongs in here and not again, not to emphasize the isolation, but building collaborative care. And I think this was brought up and I'm sure you're going to talk about it later in the training component. Yes, Bill. And in terms of leverage, I think Bruce has already demonstrated how he can leverage his own university's resources for this. And I'd point out that Mayo and Emory and Utah are establishing programs as well by leveraging their own resources. Are there any additional comments for question two? OK, then same question. Are there any of these points that people would give higher priority or lower priority than others? OK, it sounds like from the just the discussions here that a lot of these are very integrated with one another. Yeah, OK, so we seem to be in agreement there. So for question three, we talked about patient and family partnership. Some of the things that came up in the discussion were that we could potentially study patients and family psychological perspectives and look at how we could better classify them in order to be able to provide them with better support and care in the long run. That there is a need to be clear about the expectations of what is going to happen as part of a UDN evaluation and what is going to happen when these patients transition back to their primary care and referring physicians. That there is a need to create a patient advisory group for the UDN. We had a little bit of discussion about a group that's in formation, but there was a call that this should really be something that happens for the UDN going forward. And there was also a call to partner with Nord and other support groups to be able to start establishing more of a mentorship model where patients who went through the UDN we could help to provide them with links to different patient advocacy groups who might be able to provide them with support going forward. So this kind of links back into that transition of care idea. Are there any points here that we've missed? Yes, Callum. So one thing that I did notice in some of the admissions to the program that we've seen and comparing with our own patients is that because they were coming from centers that are unlike those in the network where there's an intense genetic effort that often there were family members who probably had related conditions that were only found very late in our assessment despite the fact that we were taking I think fairly advanced family history. So finding a way not only to engage the patients that I agree with all of those elements in the psychology and in the expectations and in thinking about the long whole, but actually also finding ways to engage more of the families up front in as much as it's feasible with HEPA compliance and everything else to be sure that you're not missing an obvious but low penetrance familial condition. So being able to engage more with the families at an earlier point in time to be able to collect better family histories and information to provide that feedback to the plans for the clinical evaluation. OK. Yes, Paul. I think the other thing we're seeing sort of explicit this way, but there's a difference between the pediatric patient and the adult patient. The adult patient we can facilitate going back to their internist, getting them to go back to a pediatrician is next to impossible. So if they've come to us from a subspecialist, that's an easier handoff back to Seattle, Portland, whatever. But sending back to a general pediatrician there is not really tenable. They usually freak out. They usually wanted to be handed off and not returned. So we need to think a little bit about I guess I kind of falls under the expectations of how much of this care really becomes the responsibility of the UDN when you're bringing a patient in. How much are they expecting that this then becomes their home care team versus the physician that had referred them to the UDN and managing those expectations? Yes. Yeah. And that's the reason why I really brought up the clear expectations about teaching families what research is. And then offer them the ability or an avenue by which to empower themselves to be able to help with the transition and try to get them so user friendly that the pediatrician will then take them back. So you can train people to be user friendly families so that they can help bridge their own way, get back. But the one thing that I wanted to mention is that if we're talking about what happens after the Common Fund doesn't fund this and then we have to find different funding to keep this alive because obviously in the patient arena we would be devastated if this program ever went anywhere. And discussing the fact that you can't ask for it yourself, the alumni from this organization could be very beneficial to help try to push the envelope to get funding from somewhere else. So it would be good to just keep the alumni together in some way so that we could help fight for whatever needs to be fought for in five years. Thanks, Simon. I think those are some great ideas potentially as topics for a patient advisory group for the UDN to start thinking about the idea of what the expectations are. How can we manage those as well as potentially building networks of patients who have become a part of the UDN? I would say that they're also a primary source for your advertising out about what services the UDN is able to do. In our TSC networks and consortium that we have, there are financial and academic disincentives for referrals to occur. So a lot of that is overcome by directly patient to patient communications. Thanks, Darcy. So are there any other topics that we need to add to these? OK, so same question once again. Are there any of these topics that people feel are higher or lower priority within the question? Yes, Susan. I think creating the patient advisory group should be your highest order of these. All of the rest of them will fall from that. Because they're going to be the people who are going to be best able to help you make things clear about expectations, facilitate those partnerships and create other models. So the sooner the better. I'm seeing heads nodding. Well, I also don't really think there's much of a difference between number three and four. That we would help in the establishment of a patient advisory group and that that would be one thing that would be part of partnerships with other support groups as well as a mentorship model. So that can just kind of be combined into one, I would think. Thanks, Paul. I think a patient advisory group always has to come from its own people. You know, you can't suggest it, but it takes one person to do it. So you can suggest it to all your patients in a given disease. But they are not going to do it unless they're really motivated and takes a special character to do that. And then they're very successful. And then the system works. But, you know, you have to may have to tell it to 10 or 20 people. Before one person takes it on. And you would think they would, you know, want to know. Yes, and this is something that has come up as we start thinking about this. We've been calling the patient engagement group within the UDN and trying to come up with the best way to create a group that would both be able to be beneficial to the patients, not overburdening them and making it so that it's really a group that's driven by the patients themselves. And Rachel, do you want to say anything else to that? Well, just that we are still struggling with with how to accomplish and I think part of what we struggle with is the need to form this group quickly ASAP, but also then getting to the point of finding the right people who are able to participate fully in this patient engagement group is something that may take time. So how do we balance those two those two priorities? So can I can not help us with that? Because they would know exactly the sort of people we would need. Sure. Yeah, absolutely. You can outsource a bit of that to us. Thank you. OK, any other questions or comments on our question three? OK, then we'll move on to question number four, which was training, sharing and collaboration. And some of the topics we discussed was that there was more training needed overall. There seemed to be general enthusiasm for the idea of doing more training and outreach with the UDN. There was comments on expanding outside the UDN, being able to use the UDN as a blueprint for how this type of training could be done, that you could have more folks coming in and learning from the individual UDN sites. That there was a need potentially for some curriculum development and being able to create new expertise in the community by educating these folks through training programs put together by the UDN. There was also discussion of wanting to increase collaborations. One idea that came up was bringing in health care providers to be able to get their perspective. And there was also an interest in international collaborations that we heard. And then finally, we had some discussions about exploring opportunities to be able to connect the data and really wanting to take all of the different data sets that were in the UDN and making sure that we were leveraging resources to be able to bring them together. Are there any topics that we missed from question four? Yes, Rachel. Well, I think this cuts across some of the other questions. So it may have been addressed there, but but I think the sub question there was how much support do do the outside collaborations require, like collaborations with outside researchers and how much support do do graduates of the UDN need and being connected to those resources? And I don't see that representative fully here. Do people have some thoughts on that? I know that we had some discussions about there potentially being a need to provide funding for the cores and that making them accessible to other sites potentially being able to have it so that more sites could be collaborative with the UDN and sharing data back and forth. And we'll be talking a little bit about that in some of the other questions. But what are folks thoughts about funding and support for these types of increased collaborations? Yes, and I just want to clarify kind of what I meant by that, because it might be different than what you're saying, which is that, you know, you have a patient who goes through, you have an interesting, potentially interesting finding and you want to do something more than ad hoc connect them to researchers you might know in the network. So then, you know, you have to do a search for who's the expert. And then you have to contact that expert and you have to facilitate what that collaboration might be. And so that was more what I was talking rather than core services. It's kind of the bespoke follow up that's required to get as much scientific knowledge and also benefit the patients as much as we can. And I think we'll touch on that a little bit more when we start talking about the virtuous cycle. But does anyone have any thoughts on that and support for being able to build resources for being able to find and connect to collaborators in the research community? It sounds like that's more of what you're trying to capture. Yes. So I think the biggest hurdle in that sort of outreach is that until unless the collaborators all and I think somebody alluded to that earlier, is unless the collaborators already working on that particular gene or that model, they just don't have the manpower most people given the tight funding that even if it looks like a great thing, they know that they're talking about allocating their own resources, somebody in the lab, a graduate student on a project that may be high impact, but high risk. So until as there is any money behind it, I don't think that is going to happen. No matter how I mean how hard we try. So in some ways, what Rachel was referring to earlier maybe was knowing if you find a gene that investigator XYZ at Stanford actually actually studies that gene and that particular pathway and that is an easier cell. But otherwise, I don't think, I mean, it's very difficult to do this. Yeah, the Canadian system uses that, you know, they post individual genes and the PIs can kind of look at the list and say, well, that's a gene I found in my network. I'd be interested then they can apply for a small grand of 50 K. You may want to think about that as a strategy because those people are experts. They know what the genes are. They have preliminary data that they can bring it into a network. And so I think that's another avenue. It's not truly an R 21. It's more like, you know, I want supplemental funding to put one person on this gene in the context of the research of the lab. Yeah, they're actually even smaller than R 21.  They're small awards. Yes. No, they're actually 25,000. Yeah. So I thought like they're run by Phil Heeter and Janet Rassant and 25 K might be on the low side. But that's what it is 50 K would probably be. And I agree with you. Yeah. And actually we're trying to be part of that. So not officially, but we're trying to do it sort of on the lamb. Maybe I didn't tell you guys that. Did I? Sorry. So we'll and I should be interested in some doing that something like that.  So we have had some discussions about this type of a model part of the issue with the way that they're doing it is that they're having the clinicians do the review and doing a very rapid turnaround where there's only a couple of months between the time that someone puts in an application and they are making the awards. And that just doesn't match up very well with any of the existing NIH tapes of mechanisms where if we could do something that rapidly with an administrative supplement, but then someone would have to already have an award that was studying that gene to be able to supplement. So we have to look and see how this could mechanistically work within the NIH system. So just for clarity, they can't divulge their list of variants because this organization has promised privacy to the people who are working on those lists on those variants. So what one has to do is describe a phenotype or tell what the variant is, that is the clinicians have to do that. And then it goes and the organization in Canada decides if there's a match with an organism or someone who's studying that variant in an organism. So I have no access and I never will have access to the list of 5,000 variants that are associated with model organisms in that group. But if I want to give a list of 20 variants and ask them to find one of their investigators who's studying that particular gene, then they can get back to me and put us together. That's the way it works. It's a little bit like gene matter in a way, in the modified version. A little bit, but there's little money associated with it too, as I say, 25K. And Rachel? I understand what you're talking about the need for rapid turnaround and that not linking up to NIH cycles. Would it be possible potentially to build this into either a coordinating center award or clinical sites award such that they could have funds in their pool to say rapidly issue out either a contract or a subcontract? There are ways that things could be done through contracting mechanisms, but that is a different model once again from what the Canadian group is doing because like Bill said, they're doing the matching. There is a clinical review board that's been set up and it's still being done within the group that's doing the funding. So it would be a different model if we awarded it to a core that was then running that process and putting out the awards. But it is an idea that we can pursue. Yes, Donna? And to make it a little more complicated, but to make it up to 50,000, a lot of times very, very small groups don't have enough money to impact research whatsoever, but they can get their money doubled. Like if they bring money to the table, will somebody then double it? So I work very closely like with the American Anthracic Society and my 30,000 has turned to 60 every year for the last eight years. So is this a possibility that it could be a small amount of money in a coordinating center that then could be matched by the families and then let the mentorship program teach them how to raise their 25,000 to get it matched, then make the 50,000 to start their research. Yeah, look for some kind of partnership model. It's also kind of put skin in the game for the it teaches them it's a small way to teach them how to start to do this right. The problem is it has to go fast because human geneticists I've learned like to publish fast. And so every collaboration I've had with human geneticists, you have to throw all your resources at once to it to, you know, bring it to bear in a three or six months period. This won't work for any other model organism. And then there's offline won't work for zebra fish or mice. And so it's a bit of a problem because, you know, the pressure very often they have one case and within six months there is another case. And so they're not willing to wait six months. So it's not that easy. I was going to say that this actually when we're thinking about points where healthcare pairs or public private partnerships might begin to impact. This is one point. So if you've got somebody who's cost a particular pair, a substantial amount of money and now you have a variant that might actually help them help not only that individual but their family, it's conceivable that might be a point where for a small amount of money, the the pairs might actually be interested in contributing. You can imagine some of we heard about Regeneron there are their entire projects in Geisinger, for example, that are completely funded off that model. So it might be somewhere where through Innocentive or some other online crowdsourcing strategy to get funding, you might be able to build a public private partnership. We would have to be managed quite carefully. I think as Bill says, there's a lot of sensitivity and Hugo pointed out a lot of sensitivity in this area. But managing that sensitivity is probably worthwhile to get the number of variants that you need push through the system, push through. Thanks, Cindy. And while I certainly agree that the basic science component is critical, but not to overlook the translational part and reaching out and collaborating with translational researchers who can help with the therapeutic side of things. Thanks, I think we'll get to that in some of our later questions as well. Are there any other things that need to be added to question for? OK, so then are there any of these topics that folks think should be of higher or lower priority? Well, I like international collaborations because that speaks into the sharing and we are one world. There are all sorts of patients out there that we're not even have don't have access to that we would if we had international collaborations that were more extensive. And once you start, you know, you get it. And I just yesterday got an email to get involved in Africa somewhere. Yeah, you know, and I get people who ask me knowing me three, four times a year in foreign countries. So it's right out there. It's available to everybody. Yeah, we need the ethnic specific variants in those first. But yeah, my my experiences, I'm collaborating with Australia now to for you the end in Australia is that like in Canada, people are competitive and they feel like this is really, you know, they should be doing this on their own turf. I'm sure you've sensed that yourself. So it's easy to say that you're going to have international collaborations, but they come mostly out of non develop underdeveloped countries, not from Canada, Australia, Japan, and now not even from China anymore either. We have collaborations with Australia and Gareth Bainham. We have collaborations with Kosaki in Japan and with Austria and Italy. Of course, and we have, especially in Japan, there's actually a case where we found a second case of a particular gene disorder because of that. I think part of it starts with our willingness to send them our list of variants and that's the start. So we've done that. I agree. It's not hugely successful and it's on a relatively small scale right now with individuals. But I think somewhat the whole milieu and philosophy is changing a little bit towards sharing because people are actually getting scooped when they go out their own anyway. OK. Any other comments on priorities for question four? Yes. Just to say that since this is a three part one, it's hard to prioritize because each one probably deserves its own focus there. Training is not something you bounce off against international collaboration. They're they're of equal priority and importance in many ways. I think that's a very good point. OK. So then we'll move on to question five, the virtuous cycle and integrating data. And here we heard a couple of things come up in the conversation. One was that we should think about treatment, not just diagnosis, that there are a number of challenges for funding and that if we are going to focus more on mechanism, that there would need to be more funding also for cores to be able to do more of that type of mechanistic study. There was an interest in the UDN model having synergies not just within each of the individual sites, but between them. And also this idea that finding the right researcher was really key. And this gets back to the point that Rachel was just bringing up about once you have a variant, how do you find the right researcher to follow up on that if you're moving more towards these types of mechanistic studies? So is there anything that we missed for question five? OK. So then are there any of these topics that people feel are higher or lower priority overall? So what do folks think about that? OK, so we wanted to talk about treatment and management as well as diagnosis. Or just management as opposed to just diagnosis. OK, so it sounds like we're hearing management. Yeah, people are saying management in place of treatment, treatment being a component of management is what I'm hearing from the muttering. But isn't care in the original aims? I mean, yes, in the language in the objectives talks more about management, optimal patient management, but nothing is really finished under your treatment. So I should just put treatment out there. And that's it. Whether you reach it now in 10 or 15 years, and it's just a goal and not care and not whatever management. It's also vague. So treatment is what you want. So I do have a question about this, because this did come up in the discussion. There was really some points of contention here about should the goal really be this diagnosis and we might be able to move towards management of some of these patients? Or is our goal really to drive towards treatment? And so are we really looking at, you know, management and maybe some mechanistic studies to better understand as part of the research? Or should one of the goals of a new phase of the UDN be to drive towards treatment? Yes, Paul. I'm all for treatment. I do a lot of oncology and but it's going to, it's a whole different ball of wax. We're going to start having compounds and toxicities that's going to be a lot more complicated on an IRB. Right now with diagnostics, a little bit easier on an umbrella IRB. Treatments are not going to fall on an umbrella IRB. Thanks Howard. Yeah, I agree. I think we mean I like treatment, but I think we have to be careful of really expanding the mission when we are already just trying to get our head around where this is going. So I like the idea of management. It could include treatment. It could include a lot of other things. But if we say treatment, it also carries a very specific meaning to people in the lay audience. And I just think we got to be careful when we say treatment. And David. Well, I'm not sure if these came out of the discussion or not. I think in my part of that, I was trying to make the point that there's a distinction in the approach of the UDN, which is diagnosis versus the approach to treatment, not to imply that we need to do both. The point was that we would need to think about how to translate our approach, which is diagnostic into the treatment realm. I would agree with the other comments, though, that treatment is not where we should be. Perhaps it's defining path of physiology, which sets a path to treatment. But I think treatment is, yeah, mission creep with the capital M. So I hear overall a lot of enthusiasm for the idea of potentially delving more into mechanistic studies and potentially some things in the realm of management for some of these patients that might come out of having better understanding from the mechanistic studies or the clinical evaluation of the patients, but not making a new goal to move towards treatment within the UDN. Yes. And so Donna and then Callum. Just like because of mission creep, I worried about that too. And it should be transition, not just diagnosis. So, you know, the diagnosis and then how do you transition that to the next step? I think that captures what we've been discussing really well. And Callum. I was just going to say, I think mechanism is an intrinsic part of making the diagnosis. I don't see how we're going to establish causality with N of one without having some sense of what mechanism is. Great. Are there any other comments on relative priorities within question five? Okay, then for question six, moving the UDN forward, we had a number of topics that came up. One that we seem to keep circling around to was how is this going to be funded? Are we looking at providing more money to cores and potentially leaving clinical sites to find their own money? Should we still be putting money into clinical sites? Should this be moving more towards CTSA's or potentially something similar to the comprehensive cancer centers? So I think there was a lot of uncertainty and question about how this should be funded long term for sustainability, though I also don't think that this is necessarily a question that we need to solve before the next five years, but something that we need to think about. How do we ask questions in a phase two of the UDN that will help us get to a point of being able to know what might be sustainable at the end of the 10 years of common fund support? We also had some discussion about what happens to the patients after they receive a diagnosis. We've talked a little bit more about that in the transitions of care question. And we also discussed the value of having access to the UDN cores and that opening them up to a broader audience could potentially have value to the larger community that's seeing these undiagnosed cases and that having ways for other clinical sites outside of the UDN to be able to access UDN resources may have benefit to the community. And then finally there was a lot of discussion about should we be broadening the UDN to be able to include mechanistic studies in the goals. And I think we just had some further discussion about that on question five. So are there any other topics that we missed in this general summary discussion? OK, and are there any of these topics that people would like to further clarify or state that they see as being either a higher or lower priority? Yes, Briswan? I would say the mechanistic would be higher priority. OK, and Sue? I think you're going to want to keep your eyes on the prize, which is making the diagnoses for the patients. All these other things fall from that. So how do people feel about Callum's comment that mechanistic studies are a part of making the diagnosis? Do those two things agree with one another? Seeing lots of heads shaking and nodding, so that's good. OK. Are there any other comments on question six? OK. I think we're going to have to talk with the CTSAs and NCATs about whether it's even viable to have that group support this in the future. And there was one thing that was suggested in one of the intermissions. And that is that it might be reasonable to figure or to hypothesize what might be the sustainable model for this in, let's say, six years from now and try that out over the next five years. So if people feel that that's appropriate, then we would have to maybe change reasonably drastically now and just see how things go so that six years from now or so things can be moved into a different model for funding. So I think build the problem with that is going to be that we are just starting. So you're not going to know. I mean, you guys have a lot more experience. So I digress. I mean, you have issues of experience, but most sites are just barely getting their hands around even the course. So I think we don't really know what's going to work and what's not going to work. And I think as somebody had mentioned earlier during the day is that our goal should be for the next five years to see what works and what doesn't work. So I think that is very important before we start making decisions about changing this or that. No, I agree with you. And I think that our personal our experience is a little bit irrelevant because it's it's not sustainable in the intramural program. It's just not the way the nation is going to handle this, et cetera. So you're absolutely right.  It's not necessarily a good proposal. Yes, and I can let folks know as far as a timeline here, if we do receive a continuation from the Common Fund and receive another five years of support, the next batch of funding announcements would be coming out about a year from now. So that's kind of the time frame that we're looking at to be able to gather more information. We're going to be putting together all of this information to be able to present it to the Common Fund around the end of the year. OK. John, so how do folks think about additional core needs? Is that something people feel is really important within a phase two? Yes, I think basically all patients who have who are being evaluated and certainly most of all those who have a neurologic disease or to have an eye exam and they shouldn't be skipped, you know, you just can't, you may see so much more in the eye than you see in the rest of the body and I think it should just be done. And I'm not sure it's always done. For the EM core, the key is accessibility to tissue and from most of the UDN, it's neurological and I'm not so sure how you're going to solve that problem.  So, you know, there is muscle sometimes in the muscular, neuromuscular sorrows. Sometimes you can get a, you know, a sensory nerve but it's also true that some of the genetic defects that affect clinically only the brain will have manifestations in the organ L seen in fibroblasts. Okay, any further comments on question six? Yes, first one? Not a comment, but since this is going to be put together later this year in the fall, so maybe one of the things to consider would be for the next in-person steering committee meeting. Some of these questions, this could be on the agenda for that meeting and some of these questions could be revisited at some level because we will have certainly more data. We will have actually real data about some model organisms. We will have patients, people who would have actually evaluated an N number of patients. So, we should probably clarify at least a small portion of this. Yes, I think it's great to be able to continue updating the data. Okay, any other comments? Okay, then our last task here is to really look a little bit across these different six questions that we had and are there any of these particular topic areas that people felt we really need to concentrate and focus on or do people feel that these are really things that are very synergistic and complementary to one another? I hear some mumbling down at the end. Mumble, mumble. I don't see how you separate these. I'm seeing some heads nodding around the table. That is true, but I think data integration is going to be very important. How do other folks feel about that? Do people feel that the data integration is going to be one of the real critical components of the UDN moving forward? Yes, Rachel? Well, this is something we kind of struggle with at the coordinating center because while we're gathering quite a bit of information in our centralized gateway, so much is left on the table, right?  You have the functional studies that may be supported through supplements or they may be just, as we said, ad hoc because somebody knows someone. And so those data are not currently systematically being collected in part just because of the resources and manpower needed to track all of those data down. But I think they would be unquestionable value in building a data set that's unrivaled in terms of its breadth and depth. Yes, Colin? I was just going to say, as I said this morning, even understanding the process and the decisions and how they're made across each case, whether they enter the network or not. And then as they progress through the network, we'll give some valuable information and it's probably more cost effective than funding everything for everybody. I think that's the tension that's obviously at play here. And it's just trying to get the sweet spot. How do you test some hypotheses in the context of what could be an astronomically expensive undertaking? Thanks. So does anyone have any final comments on prioritizing between the different questions? OK, then I would like to thank everyone for coming today. You will likely be hearing from the framers of your different sections as we put together the notes from this meeting to make sure that we have appropriately captured your recommendations. We want to make sure that we have all of the great information and ideas that we've heard from everyone today. But I think today's meeting has been very successful. We had a lot of really great discussion and you've been very helpful in helping us to think about our phase two for the UDN as we move forward. So thanks, everyone.


One online viewer asks, is it true that most U.S. schools require a payment just to apply? And we do not get that money back even if we're not accepted into the school. So, can you talk about application fees? Sure. Yeah, for the most part, most schools will require an application fee. They range in costs. I know that at Catholic it's about $55. And you usually are not able to get it back. So you pay the fee as part of the application. And that's just part of the standard application process in the U.S. The next step is usually a deposit. So that's a separate payment once you're admitted to the university, which is a little bit different and that's kind of confirming your attendance. But most schools do require an application fee to apply. And that application fee usually is not refunded. Correct.


Let's sing a song you don't hear every day. It's your old friend calling again. Hello, sweetheart. Smiling at McConnell, Aladdin, Lampman again. Have you heard this one lately? I saw your eyes, your wonderful eyes. Your love light and tenderness beaming. They thrilled me through. They filled me too. With wonderful dreams. I am dreaming. No need to speak. No more shall I seek. For my heart has taught me there me. And love has come at last. I know your eyes have towed. Let's play it pretty. Well, I seek has taught me there has come at last. I like to see the smile on your eyes when you come into our store and see our wonderful array of new merchandise, including Aladdin lamps and Whipple light shades. We can almost tell when you're looking at those lamps and planning just the places in the house, you can use them to best advantage, which is just about everywhere, in the living room, in the dining room, in bedrooms, or just anywhere that you want good light and good looks to pretty things up a bit. The electric lamps are available in so many different styles. They're floor lamps, bridge lamps, table lamps, why everybody can find exactly the lamp they want and at the price they want to pay. So come on in and see us next time you go shopping, won't you? And now, for our hymn. Cross of my heart on yonder hill Emblem of every suffering still Hope of my soul eternally Blessed O cross, art thou to me Cross of my heart, cross of my heart Emblem of glory and life Thou, my Lord, to see us of mine That's one of my own hymns, I hope you liked it. Well, honey, it's time to say goodbye again. Until next time, this is Smiling Ed McConnell, the Aladdin lamp man saying thanks for listening And we'll be back to sing us all You don't hear every day When we all come calling again


Live from New York, it's theCUBE covering Big Data NYC 2015. Brought to you by Hortonworks, IBM, EMC, and Pivotal. Okay, welcome back everyone. We are live in New York City. This is theCUBE's Silicon Angles flagship program. We go out to the events and extract the signal and noise. I'm John Furrier, the founder of Silicon Angle. We are here as part of Big Data NYC in conjunction with Strata, Hadoop. We are live in New York City. One block from the Javits Center, and we're here with two special guests, Ryan Peterson, Chief Solution Stretch at EMC, and Tom Brailey, the CEO of Cloudera. Guys, welcome to theCUBE. Thanks, John. Great to see you. Could it be here, John? Could it be here with Ryan? Great to see you. Tom, Cloudera, obviously it's a show that's been starting the whole ecosystem. You know, we were there, President of Creation seven years ago, watching Cloudera. Even when they were in stealth a few years earlier, Armour was at Excel Partners, kind of doing sting, Mike comes together, Jeff Hammerbock, all these guys came together at the time.  What is Hadoop? You know, InstaGray was an early investor, I was talking with him yesterday, and we were talking about what was on the mind of those investors early on, because right now we're at that same tipping point where Hadoop was not known, became known, the hype cycle, now it's here, the show is all about value right now. So we're hearing that message. I want to get your take on theCUBE here. What does that theme mean for you guys, and what is the key message that you guys are sharing and sending and hearing at the event? Well, thank you, John, for that history. And when they all show the history, I think the early founders of Cloudera had some great foresight when they set up Hadoop World, not as a single company event. It's an event we sponsor, but it's a community event. And to see the hundreds of companies here, and the most exciting one are all the new companies that are starting and emerging here, just shows how much innovation is being done by this broad community. And if it weren't for the community, we wouldn't be creating all this amazing value in such a short amount of time. At this event, we're celebrating Hadoop as 10 years old. 10 years old. There are a few industries that are having such an impact on businesses, whether it's through operational efficiency or delivering transformative applications on a platform at a scale, as we're seeing with Hadoop and the community. And it's because of all these different organizations coming together, contributing to this project that we're seeing this amazing value be delivered so quickly. It's interesting. You know, we've been here now, it's our 60 year with theCUBE, and every year it's Hadoop real, it's Hadoop real. Again, this year, is it real? But it's not only is it real and relevant, you're seeing an abstraction where values now being created outside of Hadoop because the ecosystem has changed significantly. So I got to get your take. We're here with EMC, a big whale, it's whale season here in the big data world we were seeing earlier in theCUBE. The ecosystem isn't just startups anymore, it has grown in the past 10 years, a historic rise in value creation, but it's just beginning, right? So I want you to put some color around that ecosystem growth and what that means to customers because customers want stuff faster. They want the technology faster, they want outcomes faster. Yeah, so I think, you know, someone asked me earlier, did Hadoop catch the market by surprise? That's not actually what happened. The demand for a solution such as ours has pulled this market because what we're seeing is not only the explosion of data that we're all familiar with, but enterprises are truly wanting to become information driven and they're wanting to get value out of all their data. And so you take a look at why our partnership with EMC is so important. For years, these large enterprises have been putting all their data into Isilon. And now they want to get value out of it. And that's where Hadoop comes in with the co-development work that we've done and the tests we've done, we're like saying, okay, let's bring computation to that Isilon storage. And what Isilon is, is it's the world's biggest data lake, right? And now we can get value out of it. Right, it's happening everywhere. Ryan, I want to ask you, we had EMC on earlier in the queue and Bill Schmarzo and Aide and O'Brien were talking about doing the big data. And the quote was, big data is a team sport. And, you know, because we always talk about sports metaphor, the ESPN of tech, the queue. But more importantly, the integration aspects of data. What's your take on that? Because that means you guys store a lot on your drives and everyone knows you guys have got great storage. You have a relationship with Cloud Air. Talk about that relationship and the level of relationship. And obviously it's a community, everyone, everything's transparent. So just lay out your relationship with Cloud Air and expand. Is it kind of a thin relationship, a deep relationship, is it development, joint sharing, is there IP? Can you just go into detail about the relationship? That is a great question, John. So we started this relationship a couple of years back and it was obviously a slow start, right? Can I figure out where do we play together and those things? And what was really impressive to me is Cloud Air didn't just say, hey, let's work with Icelon, let's figure out how to make it function, do joint testing, and let's stop there. Like most of our partnerships, frankly, are. It's just, you know, test and validate, see if it works. They went to the next level and said, you know what, we want to make it easy for our customers. And this was Cloud Air, Cloud Air's customers to be able to hit a button. That says, hey, we're using Icelon. And so instead of Cloud Air Manager, there's a button for Icelon. You hit the button and it just deploys and it's ready to go and you're done. So that simplicity of usage was, I think, really the most powerful thing that Cloud Air brought to the table. And so our integration is not just at a superficial level, it's a deep development, of code development, really, effort. And we want to continue to move that relationship forward, though. So, Tom, your take on team sport, because this talks to customer value and the word outcomes, insights that was out there last year, certainly insights, get insights out of the data. But when you start talking outcomes, that's code words for, I have a big, fat check I want to write. I want value. And I don't really care how things are assembled. You guys figure out your relationships. I just want it to work. Are you finding that that's the customer orientation, that's customer driven that way, or is the customer just saying, you figure it out, Cloud Air, EMC, you're our vendor for storage. Cloud Air is the big data guys. Figure it out. What's the customer narrative to that? Did they get that right? And what's the view there? We're in the midst of that trend. If you were at this event three or four years ago, we were all talking about these very technical projects. We were talking about how they stitched together and why they were faster or why they were lower cost. Today, and Mike Olson said it this morning, we're no longer talking about pig, scoop and flume. We're talking about business use cases driving real value. We're talking about churn reduction, anti-money laundering, fraud, saving lives by detecting sepsis in hospitals, the connected cars. In the discussion, and what Mike said is, Hadoop is fading into the background. And what's coming forward are these transformative applications changing industry, changing lives, saving lives. Protecting a day and we're just going on and on these powerful use cases, and those use cases now are the discussion we're having, not the technology underneath it. All right, let's talk about what the customer's view is. We heard also on theCUBE, Brian, and I want to get your thoughts on this. Creativity, creativity is driving. We saw on the keynotes the creativity of a weekend and some caffeine, and you got, guess my age, from Azure, Microsoft on stage, you know, all these kinds of, there's many examples. There are numerous to say, but basically creativity is unleashed. New use cases are popping up. Internet of things is around the corner. That's certainly being hyped up, but there are new use cases. So I got to ask you a question. Data is the competitive advantage. So there's two approaches. Do you hoard the data or do you open the data up? And so this is a big dilemma because the old world was data is power, and the new world, sharing is power. So how do customers resolve this? Or do they care? Is it algorithms that do it? What's the deal? You know, honestly, this is something I'm really passionate about.  I'm thinking about how excited this is.  One is bring all that data to one place. But secondly, with tools like Clutter or Doop, start to score and classify that data to understand what you have, what security and permissions, what contains personal, identical information, PII, what things would break security controls, all these different things. And now you can get to the point where you say, you know what, that data is really valuable. But unfortunately, not to me, it's really valuable to a partner of mine. Now how do I share that information becomes, I think, the next big question, the next big step that we need to figure out. And there's a lot of things, governance and security and permissions, but. I love to share just one great use case. I'm very familiar with it. So I love the cybersecurity space because I used to run a cybersecurity company. But today, you can no longer have signatures in advance of attacks. You have to do anomaly detection, behavior analysis. If you see an anomaly, you respond to that. Well now, there's a great partner of ours called Threatstream where companies, when they detect an anomaly, they can share it to peer companies. And so I detected this and you might be affected by the same attack. And so no longer are the vendors creating these signatures, it's these anomalies and then they're sharing them. And that's a perfect example. We're seeing this with banks. So we have lots of conversations with banks and we say, hey, are you guys willing to share data? Cause it seems like something that's probably one of the most secure information we have. And you know what their answer is? Yes, to remove fraud from the environment. We would be happy to share information for that. So I got to throw up some concept out there. Just kind of made this up, but it was from another concept we talked earlier is, will there be an SLA on data? And let me caveat that. Meaning, let's just say you have data, you put it into a Hadoop, it's in a data lake and you run a report, it's a system of record. You pull it out, you get stuff a day later, you know, a week later, maybe a couple hours later. That's a different value because you store it in a low cost storage, your storage or a commodity open source, you move compute to the data. We've been there, that was four years ago. Now you have engagement data, you have credit card transactional data. Now you have systems of intelligence which Wikibon has been promoting heavily. We're machine learning and new stuff's happening. That are going to change the game on speed to notification value. Meaning, if I am a human being, I only have 100 milliseconds in my head to click a button. That's recommendation engines. We've seen that stuff. I mean, Jeff Hummerbacher said, the brightest minds are working on ad tech, which essentially click on an ad the right at the right time. But that's a human equation. When you get into the machine equation, you're talking about huge speed advances, more than 100 milliseconds that the humans can handle. Will that new systems of intelligence change the game on the value of the data? And will that impact the ecosystem and offer opportunities? So I think this goes right back to your creativity concept earlier. We can't imagine how our lives are going to change because data and insight can be delivered at the time of interaction. Whether that's our human interaction down to machines interacting and making decisions or altering things based on some insight. We can't think of them. Today we're doing things, someone swipes a credit card and then they get an SMS text saying, did you really want to make that purchase? It's odd. Before that purchase is completed. That is pretty powerful stuff. And we wouldn't have thought of that use case five years ago because the technology didn't exist. One thing I do know when you look at the roadmap and you look at the pace of innovation, one of the areas that's moving fastest is the speed of computation. We're moving things into memory and Intel's making these specific chips. Dreaming, all this stuff. Yeah, so I don't think the SLA is going to be how fast can we produce it. I think the technology is going to outpace our ability to think of those use cases. Hearing customers say, will there be an SLA for data, service level agreement for data? I mean, are they getting advanced enough? Are they still just kind of doing reps on basic stuff right now? Certainly depends on the customer. We have some customers who say, you know, we need SLA's because we're already there. Just talk to customers, talking about how they have an internal marketplace of their data assets. And in that case, the SLA started to come conversation. Other people are early on in their journey and they're just kind of developing where is their data and how they get it in and what are the componentaries needed. And those customers are less interested in what the SLA is and more how do they get value. And so it is sort of a journey, a process that these guys take to get there. One question I'd like to ask you, Tom, because Cloudera I think is the perfect poster child in this company that lives in this era of living in the future, but operating in the present. I mean, every interaction I've had going back, you know, 10 years ago with the Cloudera folks is, you're always, you guys are way ahead because you're looking at stuff with Cloudera that's really futuristic, but not operationalized. EMC is operationally relevant in every major enterprise. So this balance between living in the future and operating in the present as CEO, that must be challenging. We want to begin with culturally, but how do you handle that and how does a customer bring that innovation strategy to their world? Yeah, so I think, you know, this is exactly the role and value proposition we're supposed to play as one of the companies in this movement. It goes back to a lot of this innovation that originated in Google. And building Apache Hadoop and then building distributions and testing it in documentation and training is to help every other enterprise get there, right? And get there in the shortest amount of time. And so there's so much innovation happening here at Hadoop World. You look at all these new companies and one of our roles and our responsibility is to help curate, to help test, to help integrate, to make sure it interoperates. It's well tested and there's security that goes across all these different projects. And then bring that to enterprises so they get value out of it. Brian, I got to ask you, I heard Mike Olson's keynote that I always watch Mike's because it's always a tip to the future.  And he's really talking about- I tell him not to do that. You know, but we know him too well. He's a great guy because he can't, he has to leave a little bread friend, Easter egg out there. Mike, if you're watching, we got your tell sign. But his tell sign clearly is the value is coming now. This is time, rubber's hitting the road, meat on the bone. Customers want value now. We've been now in the 10 year anniversary. So, hey, congratulations, pat us out in the back, but let's get decked out in the business. And the business is I have to deliver value because the customers now want stuff now. So that brings up the equation of, what is that innovation? How do you talk to customers and you say, hey, we got your, you just say, hey, we got your back. Don't worry about it. We're tight with CloudEra. What's the development plan with CloudEra? What are you guys doing to get your customers' backs? So first of all, I'll agree with that. I think that there's this concept like vertical business gravity of solutions. And the concept there is that you've got telecommunications organizations have been using big data for a while and each one has a different use case. Well, those use cases start to get shared amongst each other and all of a sudden now, hey, there's a big opportunity around solutionizing. Is that a word? I don't know, solutionizing. Opportunities around telco and then same in banking and the same starts to happen in healthcare. And I think that's a big, a big movement. We've been finding is that as customers have started to hit certain limitations of what Hadoop does today, like you talked about SLAs, they're asking for the next generation of technology. What, maybe it's a Kudu, maybe it's a new application that's yet to be built or maybe it's a new technology. And so one thing we've done is we've worked with CloudEra now to start building a new technology that EMC has been working on for quite some time. We can't say what it is yet, but look for it and look for it in a little bit in a few months. So you're writing code with CloudEra, joint software development. Joint software development. And the intent is to try and make the fastest possible Hadoop cluster on the planet to really solve some of the latency challenges that we've seen in the past with Hadoop, to go after new workloads, things like say Monte Carlo simulation over the top of Hadoop in a latency and performance application that you wouldn't normally see with a traditional architecture. So we're really trying to work with CloudEra to find that cutting edge balance. EMC, as you said earlier, we are playing the balance of how do we innovate and at the exact same time maintain that very stable control. And it's because we have this idea of emerging technologies group and we kind of push those boundaries. Tom, talk about your growth strategy. Okay, you guys haven't filed an IPO yet. It was summer speculating, you will. I've said on theCUBE you'll never sell because I know the founders don't want to sell. They want to build a durable company and be that next day. So that's my prediction. CloudEra will never sell. Someone on Facebook with the number can be high. Thank you for answering your question. I mean, IPO and build the sustainable company, that's the founder of the vision. You guys could have sold many times. I know that. But the reality is you still got to have a growth strategy. Evaluation is $4 billion. What about your ecosystem and your growth strategy relative to the product and ecosystem? Because with EMC and your other partners, you guys are doing a lot of joint development. You're doing a lot of ecosystem work on the biz dev side. Is that fundamental part of your growth strategy? What is the CloudEra growth strategy for the company? Yeah, so you answered it better than I could in your question. So we are going to be a long-term enduring business. And the market wants us to be a long-term enduring business that works for the ecosystem of partners that allows for best-of-breed decisions at every level of the stack. So what we realize is that we are a platform provider but our customers want solutions. And so that solution layer comes from our ecosystem of partners. And we work with them to deliver the complete solution. And the customers like to see the vendors come together and say, we've done the integration. That's the development worker. We're doing code development work to do the integration. Therefore, a customer gets value in a quicker amount of time. How many code development deals do you have right now going on with other partners? We have a number of code development deals. We have a very large organization called Partner Engineering that does certification of our integrations. I think our relationship with EMC is different than our broader set. This is a partnership we're very committed to. And so we want to do some very unique things. Yeah, storage is not dead. Obviously it's been over a decade, two decades, storage is supposed to be killed two years ago. But you know how the storage fabric, you got to store the data somewhere. We look at it very selfishly, right? We have no value if we don't have data. There's a lot of data in our partner here. And so we bring value to their data, which brings value to our customers. One of our first CUBE interviews with Joe Tucci, and I said, Joe, storage sexy, storage sexy. But Dave was laughing. But the reality was we saw then, storage isn't going away. There'll be different layers of storage and different intelligences. So that sounds going to be an integral part. Final question on the disruptive technologies. What do you guys see right now as a disruptor? Obviously Spark is the center of the conversation here at Strata Hadoop and Big Data NYC. So what is, besides Spark, what disruptive technologies do you see really taking us to the next level fast because the growth is significant across the board, not only for the companies you've seen, Cloud Air, but the entire ecosystem. Customers want to deploy now in production all the time. It's a challenging question for me, as I'll say that I look at all of these individual projects that come up with an Apache as somewhat disruptive to the previous version, the previous possible solution. But I don't look at them as hugely industry changing. I think it's more product Hadoop changing. So I really think the disruptive technologies, the things around, things like data sharing and data monetization, the application development frameworks that are pulled up now to take the content that we're creating from all this big data, the value, the insights and turning that into actionable data sets and then repeatable applications, to me that's the things that's really changing the business.  Well, so people like to think that Hadoop is all about HDFS and MapReduce. In the past few years, it has evolved so quickly, right? And the most recent example is around Spark and everyone's so excited about streaming and the machine learning capabilities. And there's going to be more and more innovation. And none of it, I think all that innovation makes this ecosystem of projects increasingly more disruptive and more capable. But one of the things that I think industry started to understand is that this community of projects has many years of legs to go. And we have a lot to do to make it much more stable, more manageable, and then new workloads keep coming on. And so, and Spark is the most recent example. We are fascinated with the uptake of Spark in our customer base. What's the Cloud Air position on Spark? What's your official statement on Spark? I know Mike addressed it in his keynote today. What is, are you going to continue investing in it, funding it, partnering with it? What is the Cloud Air role of Spark? Because that's a real hotbed right now. Well, our role is we're very committed to it. We're very committed to the project. We're the first to introduce it into a distribution. We believe it will be the standard in this set of capabilities. We announced our one platform initiative where we've taken all of our enterprise classings, whether it's systems management, data governance, security, things like we introduced Kudu today, we introduced Record Service and we built work automatically with Spark. So our one platform initiative says that Spark is going to play a front and center role. We believe that all future jobs won't be written in MapReduce, they'll be written in Spark and a lot of old jobs will still exist in MapReduce but everything new is going to move to Spark. All right, final question. Put the bumper sticker on Strata Hadoop this year. What's the bumper sticker on the car read this year? You have to summarize the show in one bumper sticker. We're finally talking about business value. Okay, business value. Here with the CEO of Cloudera and Ryan from EMC, Ryan Peterson, we'll be right back with more right after this short break. Live in New York City for Big Data NYC and Strata Hadoop, we'll be right back.


In the first part of this module, we learned about the geology of igneous rocks, again coming back to looking at materials that form by the cooling of molten magma beneath the surface of the earth or a flowing lava at the surface of the earth. And as that liquid cools and crystallizes, we form crystalline rocks. As we've discussed before a little bit, Heather and I had a chance to exchange some terminology and develop a common vocabulary over the course of making this class. And one of the really interesting things that we discovered early on is that the way geologists use the term porphyry or porphyritic and the way art historians use the word porphyry, have two slightly different meanings and they're in no way mutually exclusive, but they do have a somewhat different significance. So we have a couple of examples of porphyry here, one taken from a riverbed and one nicely cut here. What makes this geologically speaking porphyry is actually the texture of the rock and the distribution of crystal grain sizes. So in this particular rock, I believe you can see that there are some lighter colored large feldspar crystals that have grown within the rock. And then those large crystals are contained within a fine grained matrix. So typically we define an igneous rock as being either coarse grained or fine grained and the porphyry is a little bit funny because it's a bit of each. And the way this works is that the feldspar's were growing slowly within a magma chamber beneath the surface of the earth. And then there was an eruption that carried the magma with those large feldspar crystals already in it up to the surface and then proceeded to cool the rest of the way very quickly. So we have some large light colored crystals that reflect the slow early growth beneath the surface and then some darker very fine grained crystals that reflect the final stage of growth upon eruption. Not always, but in some cases the oxidation of iron in the matrix of this igneous rock, which means in the lava that it crystallized from, serves the purpose of coloring it a beautiful purple color. And that's where the meaning of porphyry particularly in the context of art history comes in. If you were to ask an art historian generally about porphyry, probably the picture that would pop into the art historian's head would be of a purplish reddish porphyry like this. And that's because some of the most famous works made from porphyry are made from what we call imperial porphyry. And it is this very rare purplish color that in the ancient world could come only from a single quarry in Egypt in the desert mountains between the Nile and the Red Sea. And there was tremendous effort just to get to this single quarry.   But this rare stone was reserved just for members of the imperial family. And just like other forms of purple that were quite rare like Tyrion purple, a dye that is derived from thousands and thousands and thousands of sea snails. They have to give up their little gallbladders and it takes like 10,000 of them to do enough to trim a Roman toga. This purple was rare and difficult to obtain and therefore it was incredibly high status. And it leads to words like porphyrogenitos which in Greek means born to the purple. That's how you describe someone who is of the imperial family.


Welcome back aboard USS Jason Dunham. Thanks for joining us here in Kiel, Germany. Over the last few days at Baltops, we've gotten to do so many more exciting exercises and important exchange opportunities. Sailors from Jason Dunham visited the Danish warship HDMS Absalon and got to see how our allies in Denmark operate at sea. Once again, we spent some time alongside our French allies on the French ship Somme taking on fuel. We even got to see Allied minesweepers detonate a mine. Thanks to an inflatable target provided by the Danes, we got a bunch of practice shooting. And our Polish allies on board got some as well. After successfully completing these exercises, it was time for much-deserved celebration in port. And what better way to celebrate than to return to port as a team to kill Germany during its famous Kielevocha celebration. We've played soccer with our foreign shipmates and even got to show some German citizens around our ship. But the fun isn't over yet. Join us as we continue to visit our partners and allies in the Baltic region, building a unified, global network of navies. And experiencing the rich culture of our host nations. There should be plenty more sea stories coming up next.


Okay, guys, welcome to the security Devroom talk about application whitelisting in Linux environment by Radvan Sroka. Please welcome. Hello, Fosden. My name is Radvan Sroka, and I'm working as a software engineer in Red Hat in Bernou. And I'm very excited to be here as a speaker and as a developer. So let's talk about application whitelisting. What is an application whitelisting? Well, it is a security practice where the application or the software itself is able to run according to its presence on the list. And usually administrator is responsible for maintaining such a list.  Why is that so important? Well, it adds another level of security to the system. And application whitelisting capability is a part of the many certification schemes such as common criteria and many others. This basically pushes software vendors to implement some sort of application whitelisting solution. So where is Red Hat? Well, we introduced FA policy framework in role 8.1 and Fedora 29. And it's available to use for everyone. FA policy framework is a very simple and lightweight solution. And it benefits from RPM and DNF integration. It has also audit support and it is built upon FA Notify API. FA Notify API is a kernel API which is very similar to iNotify. Who knows iNotify can watch file system events based on system calls like open, read, write and close. But FA Notify can also watch exact system calls and moreover, it's blockable on system call side. That means that system call will be paused until decision has been made on the other side. So this is very simple scenario how FA Notify can work. So we have two processes here. The first on the left is Vesh which is being watched. And it would like to run PS command, standard Linux utility. And this system call will be on hold. Execution of the system call will be on hold. And kernel will notify the email which is the watcher in this case. FA policy the email and it sends an event to this email. And the email can see that something is happening on the system and we can see from the event that Vesh is going to execute PS command with such as ID. And this demo has to decide what to do with it. Well, it can send a lot, decision a lot. That means that exec VE will be eventually success on the other side. It can send the night. And that means that exec VE will fail. And Vesh will be not able to exec PS command. This is how FA policy the framework architecture looks like. Well, it has multiple backends. And the most significant part of the project is the demo itself. When the demo starts, it loads all data from backends and it saves them into database. And then it can create some query to verify trust, let's say. So how can we configure it? FA policy D can be configured in three ways. The first one is a rules file. We can find there the default set of rules like set from distribution. The second way is configuration file for the demo. We can tweak some performance options there, usually. And the last way how to set it is FA policy D trust file. And there we can put a list of applications with trust, with trust, actually. So as I said before, there are multiple optional backends. Right now, there are two possibilities implemented. The first one is RPMDB, which is the backend which loads all data from RPM database. And the second one is FA policy D trust file, which, as I said, contains the list of trusted applications. And when the application is trusted with the default set of rules, it will be allowed. So FA policy D has its own rule language implemented and it has subject object notation, very similar to SOE nukes or audit. And it can be divided into four parts. Where the first is the decision. Decision is the action what will be taken when the rule matches. And it can be allowed or denied. We can combine it with audit. So it also, the decision will be audited. And we can find the decision in audit logs. The second part of the rule is permission. Permission can be open or execute that comes from FA notify API because there are two types of events there. And it is based on system calls. And there is also any keyboard that can match any of them. The third part of the rule is subject. It's started before colon. And it is a process that is running and it wants to call exact or open system call. And the object, the part after the colon is usually file that is going to be executed or opened. We can install FFPOLCD framework very easily on Federa or REL. It's as simple as that. So let's try to run it. And we want to, let's imagine that we have some applications in HomeDeer and we would like to run them even if they are not installed from RPM. So for example, I have in my bin two applications. First is my binary, which is a normal, usual compiled binary. It is actually copied from OS command. And the second is some Python script. So if you run this, binary, it works. So let's start the demo. When we run it in debug mode, as a root, of course, and we save the output, we can try to run it again and it is not possible. Because this particular application is not trusted. So what can we do about it? Well, we can investigate the output, of the FFPOLCD, if we start looking for my bin, we should find something like that, which says that rule nine from rules file has matched. It is some default rule that denies everything, let's say. And it's denied, this event which had a type execute and some metadata. And we can see that the subject is shell, it is SH, and the object is my binary. So my shell would like to execute my binary with this file type as an executable. So let's try to construct a rule from that. So we want to allow this event that has permission execute with this subject, which is shell, and we would like to force that shell has to be trusted. Okay, that means it has to be installed from the standard repository, let's say. And there is my binary, which is in the path, and it has this file type, and we know that it is not trusted, but this is optional, it doesn't have to be there. So if we put this rule at the beginning of the rule file, then we can try to run our binary again, and we can see that it works. What about that Python script? Well, we are able to run it right now with FFOCD disabled. So it's some whole world script. If we run again the demon as before, we can see that it is not possible to run it, this Python script. So we will investigate again the same approach. We will grab from my app, and we can see that there was an event that says, actually it is very similar event as before. It has the same subject, the shell, but the object is different. Now it's my app, and it has a different file type, which is application Python right now, or text Python. So if we construct the rule, it is also very similar rule as before. We can set trust one for subject, and we should be able to run this Python application from ZSH as we were able to do before. But we are not able to. So let's start the second round of investigation. If we grab again the output of FFOCD, we will grab two lines now. The first is allowed, permission execute. So the rule we put at the beginning of the rules file, it actually matched. But there is second event that says it needs to open this file actually from shell. So it looks like shell is first, or part of the execution or exact system call is also called open system call, right? So this is the reason why it's that self. So if we can see that these two lines are very similar, we can use any keyboard for permission, and we can allow these two events with one rule. If we again update our rules file and run the Python script, now we can see that we are able to. What's the difference between these two ways of running Python scripts? So on the left side, we can see that shell is opening this Python script. But on the right side, it looks like Python 3 interpreter is running this script, right? So if we grab for my app again, we can see that subject is different. But we can fix this with all keyword instead of exact. So we have rule that will allow any permission and with any or all subjects that are trusted. And again, the object is the same as before. The second way how to enable this application is to enable whole directory. But this is not very secure, right? And the third way is the best from my point of view is to add these applications to the FAPOCD trust file, as we can see on the image. And we are able to run them. So if we are okay with our configuration, we can just simply enable FAPOCD with SystemD. That's all. Thanks. Any question? How do you prevent race conditions in the policy handling system? Especially during boot, it might take some time for the demo that you use in order to set up the policy. It's available. It depends how the unit file is based on. So we can start this demo very early, or even in the early boot. Alright, so I've got two questions. Hopefully one of them will be pretty short. So are you aware of any efforts to enable FAPOCD in other distributions than Red Hat based? I mean, it seems that apart from RPMDB integration, there's nothing under it that should not work. Well, I made a page last week that made Leap RPM optional, and there is an API that can be easily extended to some other trust source. Now, it is not possible. You can use it just only with this trust file, but you have to maintain it, but it's not easy. But you can implement some other source of the trust very easily. There are, I think, three functions you have to implement in C. Second question. If I understand correctly right now, it's very much limited to identifying files to allow or deny by their location, which obviously means that if you have got permissions to copy and execute files from some directory, like you give from the home directory, all the users have to do is just copy the file to a different place. I suspect it might be a limitation of the Feign Notify API, but are there any plans to extend this to some sort of integrity-based or hash-based policies? Let me think. So, yes, we are not checking the integrity. We have all the hashes. We can do that. We have hashes from our RPM database. So theoretically, it can work. It can be implemented with a few lines of code, but we are not doing this right now because it has some performance impact right now, and we would like to put it down. But if you want some real solution for that, that will compute all hashes and all files, so there is an IMA, but that has a big overhead, really. So adding the trust just confirms that the package is installed, and that's it. That's the only check that's happening. Adding trust one, all that does is check if the package is installed and it's running from that location. It doesn't do any Shah-based checks, nothing else. I just said that. Any other question? Which system calls are you preventing? Are you also preventing like P open stuff like that? We are looking for whole family of system calls, right? So all exact system calls or open system calls. They are watched by this API. So any other questions? Have you considered on implementing this with SE Linux or app armor style of settings instead of doing it in new? What I want to say is, would it be possible to do exactly this with SE Linux in a special setting like you do not have to disallow everything with SE Linux just like a small portion and then allow stuff again? Or was it Oscar ready because he's laughing? Because it's like common question. Well, some limited scope can be implemented by SE Linux, but there is a problem with these labels because you have to check them all the time and you have to realize that these labels are okay. So you would technically need to loop RestorCon or something like that all the time. So we would like to enhance this application to really check hashes and content of the file. And this is not possible with SE Linux because SE Linux has the label, but it doesn't really care about the content of the file or hash or something. So one last question, anyone? So if no, thank you for your presentation.