 So just two real quick disclosures. My employer, Partners Healthcare, receives royalties from the sale of Gene Insight software. And my group builds open source smart on fire applications where part of the funding for that work comes from persistent systems. So I think for this group, this is motherhood and apple pie, but core contentions that underlie the recommendations that we're about to make. It is incredibly valuable for the clinical genetics community when it is possible to demonstrate clinical or economic value associated with clinical interventions. The notion that the second contention is that electronic clinical decision support will often be critical to the adoption, use, and safety of these interventions. And third contention is that eMERGE is in a unique position to accelerate the development of genetic aware clinical decision support. So we are really big believers and really hope that eMERGE 4 contains a focus on clinical decision support. That said, however, we also think that it's important to go into this with our eyes open. Recognize that the building of clinical decision support is very different than the building of research IT. There's a feeling that we really need to focus our resources that clinical decision support, genetic aware clinical decision support is a huge area. And we need to decide what places within that area resources can be focused, both from the perspective of making sure that we can succeed in the projects that we take on, and also from a pure patient safety perspective. Good news is there are lots of different options that we could focus on. And our feeling is the goal is just to decide which options to choose which ones to focus on. So this is a schematic of setting up clinical decision support, genetic aware clinical decision support. It starts with a laboratory transmitting in sufficiently structured form, genetic test results, a provider receiving those results, storing it in the EHR ecosystem, and then standing up clinical decision support, which will often take the form of either event-based support, where you monitor transaction flow through the EHR to identify transactions that you feel you can improve if you intervene on, or display-based clinical decision support, giving clinicians access to better information, better analysis in the hope that they will use that to make better decisions. Regardless of which is chosen, there's a need to, any form of clinical decision support, alters the clinical workflow in some way. It may introduce a minor change. It may introduce a major change. The changes to the clinical workflow need to be assessed. You need to determine whether that change is adopted and whether the overall effect of that new workflow is better than the existing workflow. And then, of course, has been discussed. It's very helpful to measure clinical and economic effects pre- and post-change. One of the things that's nice about clinical decision support is it can enable you to better structure data. Now, associated with that, one of the biggest expenses that we've found in standing up clinical decision support is actually getting the clinical data, in addition to the genetic data, in sufficiently structured form to execute the analysis. So to Terry's initial sort of driving point on eMERGE, that it's great that eMERGE has identified that research, that clinical data can be used for research purposes. Now the problem we have is often clinical data is not great to use for clinical purposes. And we need to, this becomes a way of beginning to address that problem, forcing that problem to be addressed. So, but associated with getting better structured data through this process, it does give you the ability to start managing knowledge. And that can be done within a system to sort of start to iteratively set up beginnings of learning models. You can also start to use repositories like CDSKB, ClinVar as a way to share knowledge across institutions and start getting learning going across a network. So within eMERGE Phase 3, the EHRI working group, really focused just in this area. And we're really proud of what was accomplished there. This is, eMERGE creates this heterogeneous environment of multiple laboratories communicating with multiple providers, both clinically and for research purposes. And so this heterogeneous network has been stood up. But it's important to recognize both that a great deal of scope exists outside of this box on this diagram. And also, as we, at a point that's been made by George and others, as we go through this process, what you wind up learning is additional clinical context that you need to put around data, that you need to put around standards that will then lead to iterative requirements coming back here and needing to be accounted for. So even this is not totally done relative to what needs to happen further down the line. So in terms of considerations for eMERGE for ways to think about scope, couple of different trade-offs that could be considered. So we could focus on display-based CDS, which would point us more towards the Smart on Fire standard, or event-based CDS, which would point us more towards the CDS hook standard. We could focus on generalized genetic support, or we could focus on taking a look at support that can be given that is specific to clinical conditions where we think we can intervene to affect care of patients with those conditions. To Ken's point earlier, we can focus on site-specific objectives or allocate resources to enable more network-based objectives and more sharing across institutions. We can focus on building foundational, fundamental infrastructure that would allow 1,000 flowers to bloom in eMERGE 5, or we can focus on more end-to-end scenarios which would inherently be more narrow for the same amount of resources. So just some very specific examples of things that potential models for this. So this is work that Mary and St. Jude's have done that was taken and codified into digitized implementation guides. This is event-based clinical scenario-specific CDS. What this does is monitor the clinical flow for prescriptions of field purines and then checks whether TPMT genotype status has been assessed. And if so, whether that assessment is consistent with that prescription and provides an alert, if it's not, because not taking into account TPMG genotyping status in these orders can produce life-threatening results. This is work that was done by partners and Geisinger. This is a design for a smart app that I believe maybe talked about a little bit more in the next presentations. What this does is display the variants that have been found in a patient, the laboratory assessment of the pathogenicity of those findings, as well as the ClinVar three or four star significance of pathogenicity as it is currently understood. So this potentially provides a way for keeping genetic test results up to date over time in the EHR setting. Could be event-based elements to this, but as displayed, this is an example of genetic-specific display-based CDS. Final example, this is an app which is in piloted Brigham and Women's Hospital and is, we believe, will go live very soon. What this does is it takes HLA status and it pulls together information from four different systems so that you can display to the clinician the patient's HLA status, and I apologize for the amount I had to reject here. The blood bank for each unit in inventory, how that unit's HLA status compares to the patient's HLA status, as well as information on how well the patient is accepting transfusions, platelet transfusions. So right now, about 15% of platelet transfusions for bone marrow transplant patients are rejected because of mismatch in HLA types and the goal of this intervention is to reduce that number. So this is condition-specific display-based CDS. So getting real specific about potential things that could be considered for eMERGE Stage 4 could focus on developing a smart on fire app for managing genetic test results and then work to implement that app across the network with labs being able to send data into it and the sites being able to actually link it into each of their different EHRs. Could focus on implementing the Digitized Implementation Guides which focus on event-based CDS for two pharmacogenomics scenarios plus Lynch syndrome. The idea that generated the most excitement within the EHRI working group was developing display-based or event-based CDS for a specific clinical area. So saying eMERGE sites, please choose a clinical area where you feel that genetics could materially improve the care of patients and then sort of saying to the IT, the EHRI people, use all of the tools at your disposal pragmatically to try to install clinical decision support to help those patients and then assess how well that goes. Another idea is to continue focusing on the building out of de-identified case repositories as well as knowledge exchange networks with the idea of moving these things more towards clinical over time. This is my last slide. Key takeaway points are end-to-end support for clinical genetic workflow does involve enormous IT scope. As Casey pointed out, reproducibility, data quality diversity and replicability will be key considerations for generating usable data for CDS. And if there's one takeaway point, what we really want to emphasize is we think that there is an enormous amount of good that eMERGE phase four could do for driving clinical decision support forward. But in order to do that, we really need to focus on one or two specific areas and make sure we make a real impact there. Thanks.