 I really want to thank the organizers for giving me the chance to speak on digitize, but to those same people following both Mary and Heidi. It's a little challenging, but I forgive you. Can you stay close to the microphone? Oh, I'm sorry. So digitize stands for displaying and integrating genetic information through the EHR. It's an action collaborative organized under the Institute of Medicine or now the National Academies of Science, Engineering and Medicine. It pulls together a number of different types of stakeholders to try to drive forward. Government stakeholders, healthcare providers, laboratories, vendors, patient representatives, and very importantly standards organizations. There's been a very large number of people who have contributed their time to digitize over its lifetime. It really benefits from divergent use, looking at problems and often coming up with ways to simplify those problems. Its overall purpose is to really drive and facilitate the development and roll out of genetic aware clinical decision support. As broadly as we possibly can. There's two ways that we go about focusing on doing that. The first is developing implementation guides. And then the second is working to facilitate collaborations to get those implementation guides into use where the implementation guides specify how you can develop specific kinds of genetic aware clinical decision support rules. So I'm going to talk about each of these things, sort of what we've done in these areas. And I'll also really try to focus on where our challenges have been because I think that may be what's most useful to this group. But before diving into this, I want to talk to general context that we operate in, which I think is really important in terms of thinking about how to increase clinical decision support performance. Genomics going forward. So just about all academic medical centers either have gone through this process or are going through this process of starting on a legacy EHR. I'm just trying to figure out how to get this. There we go. Starting on a legacy EHR could be commercial, could be homegrown, deciding that you're going to migrate to a commercial EHR. And these projects are huge. So within my institution, Partners Healthcare, this is over a billion dollar project that lasts, you know, many, many years. And then ultimately winding up on that commercial EHR than having to enhance it over time. So this is a major deal within a healthcare institution. And one of the things that happens here is you have the legacy EHR will have a certain amount of funding going into it and a certain staffing level associated with maintaining it. Often one of your objectives in making this transition is to be able to decrease that staffing level. But what actually happens is when you start this transition, you need to maintain the legacy EHR while at the same time staffing up to handle this commercial EHR. So your staffing level goes way up during this transition. And then your goal is to reduce that staffing level down to below where it was before at the end of the transition. So you've got major contention for resources here in terms of getting the staffing level going up. But then once you're done, what winds up happening is if you think of these legacy EHRs as EHRs that have been really custom made, designed to really fit specific clinics, specific clinical areas, workflows. And then you compare those EHRs with the commercial EHR that replaces them. There will be even if for 95% of the clinics, the new EHR is better, you've still got 5% of your clinicians who now have a more suboptimal workflow and are going to be incredibly noisy about getting their support back to where it was because they have to be in order to do their jobs well. The reason that all of this is relevant to the things that we're talking about here is once you're over in this area, in this area you've got all kinds of contention very, very hard to get new innovative projects done. Once you're over in this area, you still have that challenge because what you wind up doing is competing new innovative projects, wind up competing with these projects that are designed to get the system back to baseline. So in order to get new forms of clinical decision support in, you have to somehow overcome this and that takes time. So the first task that we're focused on, developing guides. So the first guide that we developed which came out of a suggestion that Mary made at the very beginning of the digitized process was to focus on abacavir and immuron and clinical decision support for abacavir and immuron. So identifying situations where a clinician may be ordering these drugs inappropriately either because a patient's genetic profile contraindicates them or because the clinician has not, there's no evidence that the appropriate genetic test has been ordered. So in that situation, and I should note, one of the things that led us to choosing these alerts, and this was a while ago, but these were the areas that, these were the only two areas at the time where we could get complete consensus across all of the different clinicians involved that these were, you know, sort of 100% necessary non-harmful alerts. So in order to make this happen, and this goes to a question that came up at the end of the last session related to standards, to make these alerts happen, you need data to move from the laboratory that produces that data to the electronic health record infrastructure where the alert is going to be implemented. And the standards for moving that data are not widely implemented. The vast majority of genetic tests do not move in sufficiently structured form in order to enable clinical decision support. So even if the knowledge is represented in highly structured form, they are limited in the ways that you can deploy it if you can't match it to the appropriate data in the appropriate patient. So a great deal of our focus was on specifying this. And then we recommend CDS logic that should be implemented by the provider. This is the first guide to on the digitized website, which given that these slides are going to be shared, there's a link to the digitized website in the beginning. There's an awful lot of very, very detailed work that needs to go into making these guides as simple as possible, determining the exact codes that should be used for transmitting information about these tests. I would say that this would have been, all of this would have been completely impossible without the work that CPIC does, both in terms of the guides that CPIC has put together and also in terms of the organization itself being able to help us get answers to questions that would have been incredibly difficult to answer without them. Next guide that we're working on is one with the CSER, being driven by CSER, the CSER EHR Working Group. This one involves Lynch syndrome, identifying when patients would benefit from colonoscopies and getting proactive alerts, and it requires prompting clinicians to consider putting Lynch syndrome on the problem list when there's a genetic result indicative of Lynch syndrome. So a couple of key learnings from this. The first is it has been really heartening and amazing to see the degree to which different types of people will donate their time in order to try to drive towards something that they believe will help patients that are in critical need of help. And this definitely extends well beyond academia and government. This really applies to a lot of people in the private sector who identified a lot of time to help us. But the other thing which goes to conversation that happened related to CPIC is we've also found that in addition to all of this broad effort with a lot of different points of view, you really need an individual to put together these guides that can put focused time into it. So Larry Bab was the person who really did this for the first digitized guide. I would estimate that it probably took over 100 hours worth of work to really coordinate between the different groups, the standards agencies, and get all of the details worked out. We're still working on identifying this for the second guide. It looks like the University of Washington will be able to supply us with somebody. But there are a limited number of people who can play these roles, and these are the exact same people that are needed for the EHR transitions that I was talking about earlier. So there's contention for these types of people in order to achieve that. Okay, pilots. So the other thing that we do is pull together different organizations to pilot the guides as they come out. So there are a number of different organizations. I think that there's probably eight or nine right now that meet regularly, that are trying to implement the digitized guides that meet regularly to discuss progress. They're significantly engaged, but the process is long. Few learnings from this. The first is that we initially thought that we would be able to get vendors to implement a great deal of these rules into their system and just roll them out. That is not the way it is played out. Hospital IT groups are the real people who have to put in the work in order to make this happen. Again, those same groups that have major contensions in place. So key lessons learned here. So the competition for clinical IT resources is extreme. There tends to be multi-phase approval processes. So within our organization, the first phase of the approval process is demonstrating that there is a clinical need for the rule. These rules sail through that. The next phase of the approval process relates to ordering of resources and ordering of tasks. And that's where we've really run into challenges as have many, many other sites working to implement these rules. Again, they go up against pathology orders are not flowing from this group into the system. And you need to be prioritized against that when you're standing up these rules. And also, as you get into implementation, you get into more levels of complexity. So you have the rule specification, but you start to have to work on, okay, for the historical data that's out there, how exactly is that going to be a process? How is that going to be processed by source? Under what circumstances are we going to allow alerts to be suppressed? And how do we truly optimize this to maximize the benefit while minimizing patient time, clinician time impact? So I just want to end by coming back to this slide, because I really do think that for so much of this, this winds up being the key, figuring out how to integrate with this process. And what I'd say is my organization right now is right here. So lots of other organizations have, you know, been here for a long time. There are some that are coming up and will be here soon. But regardless, once you're here, the clinical IT groups, they do face, they still face major resource contention because of these legacy issues, but they also start to pick their heads up and start to think about, okay, how do we become a part of innovation? And how are we going to innovate going forward? How are we going to organize ourselves to innovate going forward? And those discussions, I think, are often happening now, which means that there is an opportunity to influence them. So I think that one of the things that may be useful here is to think about whether it makes sense to engage clinical IT folks more in kind of the consortiums that are built within NHGRI in order to draw them into these processes. Because I think that there's an enormous amount of interest in genetics. I think that ideally there would be more links between these groups and the research sort of grant funded groups that drive a lot of innovation. And I think that those may be possible, to do more possible to establish as folks come out of these phases now than it's been in the past. Thank you very much. Thank you, Sandy. We have time for some clarifying questions. Dick. First of all, that was a great presentation. I was visiting professor at the Brigham and they said $1.3 billion. And I said, I can beat that. We're spending $1.5 billion. It's not a contest you want to win. But everything you've said about the IT being a choke point is exactly right. We're in exactly the situation that you are. I had to make a presentation to our IT resource allocation committee just within the past couple of weeks. And I think their involvement and what has happened at our place is that to their surprise, some of our IT people have seen this as a career path. That genomics and barnacle genomics, which is my provincial area, can become a, it clearly has continuing need for the innovation you're talking about. And I'm just seconding what you said that I think we need those people at the table when we talk about how we're going to move forward. Because it's not just when you implement Epic, which every place in the world is doing right now, but it's going to be that innovation phase as we move forward. So all I can do is second everything you said, even more strongly. Yeah, I think it's a really, really good point and a really good opportunity that as folks start to readjust their organizations after an implementation has happened, that can be kind of a scary time to be in clinical IT. And creating a path and sort of showing how clinical IT can get more into the innovation space I think is an enormous opportunity. So I can just contribute to what our experience at Northwestern was, which was because of our involvement with some of the, like, Emerge and some of the other organizations. We actually funded some of the clinical IT folks on those grants and that went a huge way to getting them engaged and excited and now they want to be involved in every project. And so that's a strategy that works really well to open the door, especially as they're in that ramp down phase. If you can get some people that are trusted, you know, epic programmers to come in, it helps get you over that barrier of, you can't touch my system, which is what we've all encountered. And to just add into that, we've taken the same approach and actually we, from a governance perspective, the thing that you didn't specifically say is that in that enhancement phase, there's usually a huge queue. And genetics and genomics never gets anywhere near the top of the queue. And so one of the things that we established was that if we had funding through grants and contracts, that we could skip the line. And we also take a lot of advantage of our development environment. So almost all of these electronic health records come with a development environment where you can really test it out, make sure that it's working, and then put it into sort of the pre-implementation environment, usually called stress or something of that nature, to make sure it's not going to crash the system, because as you pointed out, the most important thing in that transition is the plates have to keep spinning. Everybody has to have access to that EHR. And so if you turn on pharmacogenomics and the entire system goes down, that's a real bad outcome. And so all of that has to be built into the planning. And I would also endorse the idea that, you know, more engagement with the medical and clinical informatics community would be important. And I know that there's a number of us sitting around the table that actually have that type of certification, but we could use more of the operational folks. If I may, as the moderator's prerogative, ask a question. So in this enhancement phase, do you see full integration with the EMR as necessary, or could there be sort of an app store around the EMR that's sort of smart, fire-enabled and more portable? And is that a model that you're looking at? Yes. So almost my entire group is actually shifting to exactly that internally. You know, we're looking at the way that we want to enhance the EHR through smart-on-fire apps and looking at how we really invest so we reduce the cost of building those apps and reduce the cost of integrating those apps. So we're big believers in that. And that should also lead to the extent that as much of that as possible can be done open-source. Then that can, you know, facilitate the sharing, et cetera. One more question. I'm sorry, we're going to have to move on. Not even a question, a response to that. So that is the strategy that Guy Singer's taking. For a long time, we've been fully integrating things and we're finding that that makes it very difficult to keep up with all of the epic upgrades and you end up kind of on your own flavor that then the upgrades don't work. And so the way to stay with epic upgrades is to make all of these one-offs apps in an app store. And then if an app breaks, it's one thing to fix instead of not being able to get the upgrade. Thank you. Now that you're used to hearing Marilyn's voice, ask her to come up and give the last talk in the session on FarmCat.