 Okay, thank you for that summary and actually I'll ask Brandy just to queue up my reactor slides so now I'm shifting halves to be the reactors of those and actually I just shot it down some things immediately when I saw Josh's slides. But first of all, I apologize for using the original eMERGE network banner. It's kind of like the throwback uniforms of the NFL teams that were using their team from the 70s, but hey since I actually did that logo on my desk, I'm entitled to perseverate with it so if you would slip the click list slide to the next one. My reaction about the lessons learned reflects that there was some hope I think early on that we could somehow have an all-purpose phenotype detector machine, you would simply pour the entire eMER into it and out would come all possible observable phenotypes. I think we've disabused ourselves of the achievability of that and have I think gotten closer to the notion that from a computer science standpoint, phenotypes are at least NP-hard. They may be NP because of this combination that they represent the recording of attributes overlaid with business processes, overlaid with the interpretive skills and the documentation skills of individuals and so it takes to disaggregate all of that complexity, it looks like it's going to continue to take human beings. So in that context my first question was, well okay how could you expand the EMR phenotype workforce beyond eMERGE and that is what do the lessons learned say about the skills and the technology needed for an institution that doesn't do it now, say your average CTSA awardee and could eMERGE at least imagine creating a reference document for an institution that would like to be able to get in the game of both using and developing new phenotypes, join the CKB club if you will and what would it take for them to do that because I think there are a lot of at least CTSA organizations that would like to do that because these phenotypes have a lot of utility that extends beyond genome correlation to all the way into clinical care processes. One of the observations early on at Vanderbilt it was that the type 2 diabetes algorithm immediately got the attention of the diabetes center as a way where they might be able to find people who were out there in the population and who had diabetes that was not yet diagnosed and if one additional piece of information could be acquired it would allow them to improve the quality and consistency of care processes similarly that kind of reuse utility of the phenotypes is something that eMERGE I think has discovered and has general utility and then my second bullet so stated otherwise what would be needed to scale up to dozens or hundreds of collaborating institutions for purposes of being able to remove the phenotyping bottleneck. So the second idea is that we have a set of almost stovepipe like standalone you know it's getting up in the 60s but it has the appearance that complex phenotypes all have to be developed from scratch with domain experts and can they be decomposed in the subunits that are like modular software where you could string them together or be able to use them in a way that you could build up perhaps not an arbitrary phenotype but at least get pretty far down the pathway of having a high quality cohort selection logic that is built on a set of little components little Lego blocks that are currently subcomponents of complex eMERGE phenotypes but are not sort of called out and don't have their own ROC and their own kind of they haven't been characterized with respect to their subcomponent information recall and precision. So this I think would have a large leveraging effect on the institution both within eMERGE and future partners not having to reinvent things from scratch. Next slide. So this one I can jump over because it really is just the systems view of the questions that we just discussed in the discovery versus implementation and that is one thing that informatics people don't do is they don't start working on stuff until somebody agrees that here's the use case we want to hit. And so clarity of what is the decision support target will do very much to catalyze an awful lot of coding and exchange of information and standards for heterogeneous systems. And so I think that as the discussions have already been well covered. Next slide though I think is one that I think actually represents the communications challenge for eMERGE because we're a very informatics savvy group and we tend to use the lingo of clinical decision support as informatics people talk about it. And so we talk about things like rule based systems. And it's been my observation that for example another NIH institute director who will go unnamed building a effort to create a rare variant disease specific database said well this is not going to be a bunch of rule. And so what people misunderstand is when informatics people talk about rules it really is just a structured ability to recognize the condition of interest by looking at a bunch of features of it. But other people if you use the word rule based will think oh well that's cookbook medicine you're going to tell doctors what you're doing and remove all of their latitude as professionals. And so I think it's important to recognize that intervention can at least include these five and they really go beyond that too. So clinical decision support could be educational prompts. You know the general notion here is additional information to consider. Data gathering prompts that is given what we know it would be helpful to get this additional data guidance that does improve the certainty of diagnosis given the data that's available. The pharmacogenetics one that's been emphasized already which is best evidence based therapy selection but also information relevant to either prevention or prognosis. And so keeping a broad view of possible implementation at systems level I think would serve the consortium best and I'll stop there.