 So thank you, everyone, for inviting me. I really appreciate the opportunity to be here. It was a little tricky, and I'm really glad I was able to be here because it's a lot of really great people and great conference. So I was asked to talk about patient portals and EHR portability. This is the exact title, Moving Data with a Patient. And let me just set up the timer. Oh, the timer's right there. So basically with patient portals or online websites or mobile applications, they provide secure storage and access to personal health and medical information here. We have a few of the common ones from common EHR vendors. But they do have a few limitations, and that's what I'll focus on in the rest of the talk. They really have a few use cases. They're designed by vendors. So think about it kind of like when cell phones were designed originally the flip phones by the vendors who are selling you the minutes, they're not in the business of creating apps that work specifically for your needs. And so back then when you had flip phones, it may be that the counter app doesn't sync with other apps. You know, the calculator doesn't have scientific functions. And that's because they're kind of designed by one organization. And so originally they were actually designed as a one-way communication of lab results to the patients. That was kind of the starting point. And typically designed for the patients to use on their own and lack integration of complex information and including genomic information. The other key issue is that it's a closed environment. It's kind of hard to add new use cases. It depends really on each our vendor for that. So it's hard to get third party innovation. There's interoperability issues and access is limited. I've talked to patients where they'll lose access to their portal once their insurance changes or once they move to another provider out of the network. They lose their portal. So a number of issues like that. So, you know, let's think about this. You know, people are thinking, what about apps, right? This is a real kind of comic here. And you can see kind of, I think, let's do like a little impression on this. Like it's this kind of work of art in some ways. Like you can see it's sort of a paternalistic kind of a, saying like you should be shoveling. That is the way to do it, right? Not to be using an app. You should be doing shoveling. And that is kind of the instruction from let's say the doctor to the patient. And we'll see in a little bit that maybe there are other options. So there are actually many use cases in genomics. That was one of the problems with the portals. As part of HL7, we just published last year, a domain analysis model. The first one for clinical sequencing. Contained a list of use cases and workflows for clinical genomics. Focus on clinical sequencing. We also, this year, just approved and it's in the publication process. A more general guide covers all of clinical genomics. So even more use cases. The works has already formed the basis for several national and international programs. I need to look at use cases and evaluate which ones to use. It's also being used as a guide. We were surprised by a number of provider institutions looking to institute precision medicine and seeing which ones would be a good value to try first. All right. So there are many, many use cases. Some of the typical ones are there, but there's many dozens of use cases. The patients themselves, they want to be more engaged in their own care and data sharing than is typically seen in a portal. Kind of a one-way portal. I mean, sometimes you can send an email to the back to the physician, but it's often one-way. And so I discovered this little addition that actually, Dad, there's a number of apps for that. And you know, it's true. I looked up and I don't know if they came up after the comic or they were already there, but apparently there's a whole ecosystem which we'll talk about later from becoming a shoveler to requesting a shoveler to Uber, you know, a lot of different options. So what I'm saying here is basically, you know, a way was presented first. You shall shovel. There is no app. And then that was the way kind of said by the system and the child, perceived as a child in that case, thought of a unique, a different way. May not be as good, may be good, but a different option and that's sort of by leveraging these third parties developed some innovation and develop an ecosystem. So the same may be true about genomics, we're thinking by creating an EHR ecosystem. So these are apps that we've already designed at different stages in pre-production use, using smart on fire for issues like diabetes, kind of germline, genomic testing, precision cancer medicine. The thing that's kind of common all these is that we want to integrate the users, the patient caregivers and the physicians all in the same picture. So I don't know if we've got a laser. Yeah, we do, okay. So in the laser we see like, we have something that is kind of more for the kids in juvenile type one diabetes. It makes expressions and faces based on glucose levels which could be interpreted by the parents but then other things, other details here are more for the physician. And so they can kind of sit together around a screen and see each have a piece that they can inform and give some of these are from remote sensors that, you know, it's useful to have the patient's engagement like, oh, do that sensor fall off when I see this weird value and things like that. So bringing together the patient, the caregiver which could be the parent and the patient being the child and the provider and environment and genetics can be quite an interesting thing that people are interested in. The other thing is that providers, as we had discussion yesterday between providers, what do they know, what they need to learn? Providers want to leverage what I call extra EHR resources and services, things outside the traditional EHR and services. So we did something called Smart Cancer Navigator. It's a framework for implementing ASCO workshop recommendations to enable precision cancer medicine. So creating this app that brings information from the EHR and then allows you to look up relevant genetic information to that patient and the doctor's able to do that and then share information with the patient. Some of that information is visible and readable for the patient as well as looking at different treatment options that are possible, both standard of care and more experimental. So how do we enable this sort of ecosystem? Well, we looked at the disadvantages of Portals First. We want to go to many use cases. We want to open environments to foster open innovation. Problem, the problem is right now we have a lot of places where we're just receiving PDFs or faxes. I think that was noted by Larry and a few others in the workflows. So data is buried in these PDFs. How can we change that? How can we create these contextualized dynamic action where we'll recompute all results in these apps? Well, we need to have structured information. It's not pretty, but the computer likes to read this rather than PDFs, which it treats as images or kind of a natural text. And so once you have that structured information, you can create comparisons. How are you similar to the population? What's different about you in your genomics? You can do all that in an app. This is one we did with Vanderbilt University. So the vision is, can there be this kind of unified clinical and genomic standard? What involves both of them? So it can be used with the EHR information. It leverages the technologies of both and is workflow ready and uses modern technologies. So as you see, a couple of the past standard technologies kind of got ruled out by that. And this was noted by the past talk. So thanks for hyping up, or I don't know how to say it, but really kind of introducing and bringing that nice segue to fire. There are certainly a lot of things in benefits and negatives about fire, but certainly has some positives that we found. One is that genomics is really just a part of fire. There's many different modules in it, essentially. And so when you get to use genomics within fire, you get all those other modules kind of with it. And I think is a great benefit. The other benefit is that we've designed things so that you can adopt things in layers in the past, like there's version three and others. You kind of adopt almost everything before it gets started. And then just people would not get started. It'd be too complicated. And so what we wanted to do is think about, can you adopt things very easy one at a time, starting at the beginning with just simple observations that people are used to from version two, maybe use some loin codes, add in a little bit more profiles with context. Some of these things are evolving through different versions. As the overall fire community decides different ways that it represents information. And we want to continue with that flow so that we fit in with that frame of a fire. So our modules work with all the other modules there. And that's kind of some of the we're going on now, getting toward DSTU4 to integrate some of those. But the overall scheme here of these levels and adding more information, whether you're a traditional lab, which starts with results but no raw information, or you're an NGS lab, which starts with a lot of raw information and needs to move up and slowly adopt going to kind of clinical relevant information. This is a pathway for that. We've seen a lot of success in kind of adoption and mentioning of this kind of technology. Some three or four slides, I just picked this one because it seems like a lot of people relate to all of us program. In the actual, our original RFA, it mentioned smart on fire genomic standards is one of the things people needed to describe how they're going to be using standards. And this was the paper that kind of came from. And so I want to explain a little bit about what is smart. You know, we talk about fire and fire genomics. It's kind of the genomics part of fire, right? Anything that it may be related to genomics, whether it be within the clinical genomics workgroup or other resources that can work with this but are under preview of other workgroups like the risk assessment resource. So the smart part of fire really adds on to fire. As you can see here, fire is the API and data model. The smart part adds authentication, authorization, the OAuth and the user interface experience to make that common. And so what you end up seeing, and I think these slides will be online, so you can check it out later if you'd like, if I go too quickly through them, is that you start with these fire resources, extensions, profiles, and you build, this allows you to have apps by having the security layers so you can allocate certain resources to certain parties and so forth. And so, you know, there's really a landscape of how do you do adoption? Implementation science was discussed about, well, you know, we first started with these things called fire connectathons. You've got like two, three days. You're really actively trying in a very synthetic environment to communicate from one place to another, connect. You know, not bad, but you can learn a few things from there, but I really learn a lot more, we found, by piloting in real cases with real data if possible, but at least real situations and real use cases and lately just being kind of an expert in this field. I've been seeing a lot of people gravitating and asking me about doing pre-production production now and so I feel like that's the next stage and it'd be a waste if we didn't get their feedback too, so as people give feedback, I try to collect that as well and that feedback can go into the standard tool development and things like that. But we're definitely up on that red arc right now, which is great, making a lot of progress. Okay, things that I'm seeing toward the future that may be useful, I think we're moving away from this sort of point to point thinking, which was kind of from version two and from some other approaches toward more thinking of a networked ecosystem, this ability to communicate in a heterogeneous ecosystem with multiple parties, each of those multiple parties have different levels of capabilities and information needs and so we need metrics for measuring the different speed of adoption, where they are, so you know who to communicate with at what time. I mean, someone's gonna be using version two, version four, version four beta, how are you gonna know what exactly within genomics you can count on them? And so here I just show an example of a paper published in 2016, and we looked at it as like, hey, which of those are actually in some way looking at smart on fire and supporting it? This example was in oncology, so we just kind of looked, those are already supporting, these are kind of, they have pilots to support and so as you see, it becomes an ecosystem. It's not just like pairs, and so it kind of grows with a network effect and you get a lot of benefits from that. And the end all thinking is that, yeah, you could use it for both clinical care and if you're smart about it, kind of as Chris was alluding to, you can use it for research care, right? You could take advantage of it. One thing I wanna point out here is, you see here the EHR has a plus jacks, that's sort of a nickname we, a name we procured a couple years ago, I think when all of us program started, it's basically like a PAC system, which is where the genomics could go. PACs is where pictures go, x-rays and some of the data is in that system and some of the data is kind of in the MRBA. Most of the raw data of the imaging is in the PAC system. Similarly, we could have a jack system and whether or not they're called that or not, there are a number of these out there already kind of trying to be in this field but I think recognizing this aspect that there's probably gonna be some amount in the EHR and there's gonna be this back and forth in the communication and can we strategize in a similar way to PACs might be interesting to think about, especially as we look forward and we see a number of these cloud-based solutions. So looking forward, I think we're gonna see smart on fire powered cloud-based servers with patient apps, apps stores that enable patients to customize their experience based on needs and the patients have an ability to control information sharing in real time. If you think about sync for science basically, under the hood is a smart on fire server, right? It's just, it's for sharing information, allocating information to a certain purpose but that's like a subset of the smart on fire server and it's a great use case. And so there's a lot of capabilities basically with the overall package and apps that enable patients and providers to collaborate on care as I mentioned. So it's not just information presented to the patient, you will shovel, here's the shovel but like you know what, we need to clean up the snow, let's work together on a plan to do that, we need to do it by tomorrow. So, let's see. So yeah, the screens can be used to provide a provider patient engagement potentially and applets are designed to, for genomic, applets that are designed for genomic care coordination I think is a big area that we need to worry about and think about for the future where patients can control the information sharing to enable some of that care coordination. A lot of issues around for Zeppelin family history, other places where you need to kind of collect information from different places, share from different organizations. So yeah, it looks like I actually finished early. So, let me see if there was anything more to say. About the data model. Now maybe I'll just talk a little bit about this that traditional, I feel like traditional labs have a very different way of looking at things than NGS labs. So the way things were designed is that the beach of them could adopt it from their own way of thinking. If we only had one way, the traditional labs would maybe adopt, well, the ones that are doing very simple tests and they see genetics as just like a test of yes, no, you have your bracket one positive and negative and they'd give you that result with like a loin coat or something. But then on the other side, you have the next generation sequencing labs where they're just giving you reads and that's what you're getting at the beginning. And so we're trying to get them to come to the middle by adopting from both sides. So the ones who are traditional labs to get them not just the clinical interpretation but to get them to reveal some of the more variant and eventually raw information. We know there's some, you know, trade proprietary information but that's kind of the goal of going in that direction by doing this so that you can adopt slowly. You don't have to adopt everything at once so that you can at least get some information. And then on the other side, the NGS labs going from that raw information and then getting to a CLIA certified or other labs where they can give you more interpretive information which would be nice on their side. So each one has like a different way to walk this ladder. Going up or going down. So I think that's it. Open up if there are any, or five seconds, any clarifications or questions. And feel free to email me if any questions. Thank you. Excellent. Can you clarify questions for Gil? Yeah, just very quickly, there was one slide that you zoomed through. Could we back up and just look at it for 10 seconds more? It was the one where you distinguished between the smart functionalities and the fire functionalities. Oh, I can't see. For the non-expert, that was quite something I really didn't get around. Is it this one? Here? Yes, that was the slide. Oh, perfect. So basically this is saying, so basically the way things actually originally started was fire didn't have a genomics component at all. We were developing something called SMART. It was an ONC funded project. And we thought, okay, developing SMART it'd be great to have a genomics part of it. So we did SMART on fire genomics and then talked to fire about like, hey, why don't we integrate some of these thoughts into the first version. And then iterate on it based on all the feedback and so forth. So that's what happened here. And so SMART on fire, rather than reinvent the wheel for the AP on the data model, it basically snaps to fire. So whatever the HL7 clinical genomics work group wants to do for fire, of which I'm a co-chair and lead the fire discussions typically, we use that. And then on top of that, there are different things that SMART provides, which include authentication, like OAuth, Open Connect, user interface standards. And in fact, some of these are also being now pushed into HL7 to be part of the standard process. But I just want to point out, these are very important because otherwise you basically, you just have a way of communicating information, but what's really useful is if you have a way to communicate information for a particular patient with the patient being able to log in, get that information, get the context from the medical record so that that app works within the workflow of the patient and or provider, rather than just someone having to re-typing all the information. Once you log in, you're able to get the context from the EHR and that app knows what to do from that log in. So hopefully that helped with that. Jeff, you had another clarifying question. We have a question. Yes, so one of your slides talked about a national standard, I think at the end. And I'm wondering to what extent is this an international opportunity or how are you thinking about moving data across international borders? Yeah, so that's an excellent question. Where was that? I think that's a precision medicine slide. Here. Oh, go ahead. Oh, so yeah, you're right. National, single national standard. So yeah, we could say international, but we decided to be modest at national, I guess. But the thing is, we thought, we actually are, we do have an I have a slide which I didn't show would show internationally people using it. But I felt that, and you know, Genomics England, others have come to me, they're like, yeah, we wanna do this now, but it's like they wanna do it, but I haven't, like I'd like to see a little bit more before I would, I mean, maybe we could say the vision is a single international standard, but I feel now based on a number of different governmental reports and events even in this administration in the, you know, from across administrations, what I mean, from the last, this one in its first couple of years supporting fire and getting organizations to say they support it, you know, just a couple of weeks ago at the White House, for example, that it does fit under national. If we'd hear that from other countries, that I'd be more comfortable to say that that's now, but certainly the vision could be international and there are people piling in it international. So I think that's a great idea. And if there's interest to discuss that, I'd love to do that afterwards. Well, I was going to say that on the clinical side, clinical data standard side, it says it's on. It's blue. Oh. I didn't know that. I would assert that fire already has become an international standard and it's enjoying rapid adaptation and in many countries, I would say most countries are looking at it very carefully to become the basis of a national standard. So I chaired the ISO Committee on Health Informatics for many years. I've seen nothing in my career have the uptake and enthusiasm in the HIT standards community that fire has enjoyed internationally. And I think it's also a component, if I'm not mistaken, Gil of GA4GH, that that's being discussed as part of the data standardization there. Yeah, I'm co-chair of one of the data exchange streams, I think, with Grant Wood, I don't know if Grant Wood's here, but, and that is an important topic that certainly we talk about. Because I mean, at the end of the day, I think the reason why people think it's critical is, you know, the data's in the EHR and it's kind of like locked in there. This is a way to kind of get it out and have the patient be able to play with it and use it and have other people access it. It's one of the few, so you're not vendor dependent and not locked in. So it's kind of a standard way to do that. Now, in terms of, yeah, Fire Internationally, there's overall Fire Internationally, we've seen some of the leaders in the, in Fire in terms of, you know, are in Australia, Netherlands, Canada, you know, so there are leaders that are kind of helping to promote the message internationally. Our meetings are alternate, they'll be in Europe, they'll be in the US, being Canada in different places. So yeah, I think there is, I recently saw a lot of interest actually in China, that's another place. So yeah, I'm happy to change that and maybe list a few examples for people. If I could just be a little bit of a devil's advocate or maybe what I'd like to call a realist about some of the stuff is that right now it should be clear that fire is not a normative standard. It's, they in themselves have not gotten to the point where it's a normative standard. It's awesome. I agree 100% that there's incredible adoption and I have not seen anything like this either. There's no doubt it will be a standard but it's gonna be a few years yet and just to really emphasize our goal which is clinical genomics and genomics medicine, that aspect of it will lag behind the core standard going normative. So the models and the fire resources that you're hearing here, as awesome as it sounds and as ready as it is to go is not ready, it's gonna change a bunch and it's gonna change because we have to get the model right. We haven't done that yet. So that's the first thing that has to happen. I can't stress that enough. If we don't do that, then we're just gonna keep having this discussion that everything's a standard and it's great and it's awesome. The smart thing is fantastic. That should be a standard. That's a platform that is not about the model. That's about being able to deliver the tools and the resources to make it easier for smaller innovators and smaller companies to go out there and integrate in a consistent way with creating personalized apps and patient apps and that kind of thing and that's absolutely fantastic thing. Should be a standard but it's different than getting the model right first so that people can do it. Everyone that's up there and you can correct me if I'm wrong, Gil, but if you look at the Vanderbilt app that he had up there, fantastic app, great resource. Again, it's a solution that works with their profiles and their extensions at the time they did it. I would venture to guess that those profiles and extensions aren't 100% in line with the guide, the implementation guides that are currently in fire that are gonna probably change again before it goes out. So while you can do this and create it, you still have to share your profiles and extensions with your little network of people that will do it and it doesn't create this ubiquitous model that I think Chris was trying to get to and I'm trying to get to which is allowing everyone to share it in a common way. It's about the information model and Bob Friedman could talk for hours on that because that's what he works on in the CG group in HL7. But to play the anti-devil's advocate, I agree that it is not yet a normative standard. In the clinical space, I don't think there's anything that comes closer to being a stable standard than 3.5 and they're going for a normative ballot on the next round. So I would assert that in the clinical space there has been stabilization and we are de facto at a place where we can depend upon that model. I think the clinical model is effectively finished and part of the reason why it's effectively finished is because they have deconstructed the problem into these Goldilocks size elements and that's what they focused on and those are much easier to get straight than some very large prematurely bound large scale research model, which is my thesis. Yeah, so just wanted to make sure that, yeah, I think I agree with what Chris said. The observation, patient, a number of those are looking to go normative. We already have major EMR vendors that already for a couple of years have released releases that support fire, even if it's in its draft standard for trial use before it wasn't normative. We've seen apps being released by companies that people are just using on their phones every day. So the ecosystem is here, for sure. Now, just like when you have a version of Word, that's 97, version 2000, sometimes they're incompatible because of different versions, but across, within a version, it should be compatible. So I think the early adopters are now adopting and they're the ones who are gonna help define the future of this field. There are other people who are gonna wait until everything solidifies, but my fear is that then they won't get to have their input in terms of how they would like the standard to be. So now is a great time, if you wanna join the fire calls, they're, I think they're Mondays at 11 or just feel free to send an email and get your input in. I think now is a good time to make a movement and learn to try it out and adopt it.