Technologies in Preventive Medicine. I'm Dr. Angela Michelide, Vice President of Programs and Education at the American College of Preventive Medicine. And I'm so delighted that we're joined today by Dr. Colby Uptegraff, who will be providing our presentation. And this session will be moderated by Dr. Leith States. Just wanna share a little bit about our organization. The American College of Preventive Medicine is a professional medical society of approximately 2,000 physicians dedicated to improving the health and quality of life of individuals, families, communities, and populations through disease prevention and health promotion. Our members are licensed medical doctors who possess expertise in a broad range of healthcare skills, including biostatistics, epidemiology, management of healthcare organizations, research, and the practice of prevention in clinical settings. They work in a variety of settings in this country, including hospitals, government at the local, state, and national levels, the military, laboratories, business, and academia. I have just a few housekeeping tips. The audience has been placed in listen only mode, but we encourage you to type questions in the Q&A box throughout the session as we'll be addressing these at the end. In addition, the recording will be posted in the ACPM Learning Management System in a couple of days. So if you want to listen to it again or share it with friends, please do so. And at the end of our presentation, we will have a brief feedback survey so that you can express your ideas about this webinar, as well as any additional topics you'd like us to consider moving forward. Now, it gives me great pleasure today to introduce our moderator, Dr. Leif States. Dr. States currently serves as the acting director of the Office of Science and Medicine and the chief medical officer in the Office of the Assistant Secretary for Health, or OSH, within the U.S. Department of Health and Human Services. In this role, he leads the office of the chief medical officer, Center for Health Policy Innovation, and Innovation X Office. He also advises and supports the Assistant Secretary for Health and other senior OSH leadership regarding issues of national public health importance through collaboration with OSH program offices, enterprise, and the interagency, as well as external stakeholders. An area of recent focus has been health equity in aging populations relating to health tech access and utilization. The collaborative effort with the White House Office of Science and Technology Policy, Administration for Community Living, and OSH, resulted in multiple publications in 2021, highlighting gaps and opportunities in this space to improve equity for this rapidly expanding segment of our population. Next steps included a developing collaboration with the Center for Medicare and Medicaid Innovation, exploring opportunities to increase equity-driven use of health tech in Medicare Advantage organizations. Dr. States also works in the areas of climate change, environmental justice, the social determinants of health, stigma reduction, and behavioral health. Dr. States is a Navy veteran, former preventive medicine officer, and his personal awards include the Meritorious Service Medal, Navy and Marine Corps Commendation Medal, Navy and Marine Corps Achievement Medal, and multiple unit and campaign awards. Dr. States, the microphone is yours. Thank you, Dr. Michelide. It's always great to see you. Good afternoon, everyone. It's an absolute pleasure to serve as a moderator for today's webinar. I'll be brief because Colby and I were discussing this at length earlier, but I think we can all agree that there's inherent good that can be realized from the innovations and rapid adoption that we're seeing across health IT, health tech, and data analytics. But at the same time, there are some pitfalls and things that we do not wanna fall into that could further exacerbate and worsen outcomes disparities in a variety of other things that have already been addressed as systemic underlying issues that are driving outcomes for Americans and global population. On that note, I think Dr. Uptegraft is really going to bring some unique perspectives from his current work at DHA around MHS Genesis, how he's applying his skillset as not just a clinician, but within his ability to fuel and drive and be a leader for change within that organization. And just a brief word on Dr. Uptegraft, or should I say major? He is a preventive medicine physician, a flight surgeon in the US Air Force, and clinical informatician at the DHA in Falls Church, Virginia. He completed medical school at Vanderbilt University, an internship at the University of California, Davis, residency in public health and preventive medicine at the Uniformed Services University and fellowship in clinical informatics at Boston Children's. He's double board certified in clinical informatics and general preventive medicine and holds two master's degrees, one in public health, again, from Uniformed Services and one in biomedical informatics from Harvard Medical School. He's authored multiple peer reviewed publications, invited lectures, and over two dozen presentations at national and international conferences with a recent focus on leveraging health information technology to optimize provider efficiency and care delivery. Currently, Dr. Uptegraft is the solution owner for both forms and management and clinical documentation in MHS Genesis, the new electronic health record for both the Departments of Defense and Veterans Affairs and the US Coast Guard. And I have found out that he is the sole owner of these things and the buck does stop with him. So he is wise beyond his years. Excited to hear from him. Major Uptegraft, the floor is yours. Dr. States, thank you for that overly generous introduction. I have big shoes to fill now with my presentation. Let me, if you could transfer the ownership to me, thank you. Great. All right. Again, thank you. I'm humbled to be here and to present to you on the line of some different areas of innovation within preventive medicine that I am passionate about or that I've been directly involved in. We're just gonna focus on a few areas. You could talk for hours or days on end about all of the amazing technology coming forward here, but I wanna focus on a couple areas that I think that I'm most passionate about and I think that could truly change some key areas within preventive medicine. I am employed by the Department of Defense, the Air Force specifically. However, I'm presenting this as a mere civilian and all these opinions are my own and don't represent those of the United States Air Force, Department of Defense or Defense Health Agency. I have no conflicts of interest to disclose. So for today, as I mentioned, we're just gonna be focusing on a few areas within preventive medicine that I am most, technology within preventive medicine, I am most passionate about or have been directly involved in and they're what's called smart on fire, a large area of EHR usage data and digital contact tracing. I'm gonna leave the audience with just some breadcrumbs here with digital contact tracing and some work we did up at Boston Children's Hospital. And really my goal for this presentation is I'm not going to get into the, but really the weeds of how all the details of all this works or some key studies we've done or really just provide some head scratching ideas of what may be coming down the road. I'm not gonna focus too much on a lot of the potential drawbacks or why there are current limitations here. I think that'd be some great questions to ask at the end of this presentation. But we'll be focusing and biased towards some of the promises that these areas can bring to medicine and preventive medicine as a whole. So just a little bit about me. So originally from Hickory, North Carolina, went to Davidson College. There for the key years of Stephen Curry, for those who are basketball fans, med school, Vanderbilt. And this is where I really got involved in clinical informatics and had really been plotting my course ever since my time at Vanderbilt. And as Dr. States went into with my bio, I've bounced around all over the US with training internship in California. And there was a practicing flight doc down at Kiesler, residency in Bethesda, Uniformed Services University, fellowship up in Boston. And then now a clinical informatician for the military health system at the Defense Health Agency. And so really been, and I've been involved in projects all along my years, really starting back in 2012, 2013 with my final year in medical school. The first area that I wanna talk about is SMART-on-FIRE, which as you can surmise are two acronyms into one here, two separate technologies that are often just linked together. Here SMART-on-FIRE. And so I wanna go over and why I think this is a key area that we should be focused on with the potential of how it can really impact preventive medicine. To quote it very succinctly, this is from John Halamka. He was the CMO at Beth Israel up in Boston and then became president of Mayo Clinic Platform. But FIRE is the HTML of healthcare. It's really sort of the HTTP of healthcare, but the point is well taken. It's essentially trying to define appropriate data models for healthcare interoperability to provide a platform for sharing data and for building EHR agnostic applications. So I like to think of it as, if you imagine your iPhone in your hand and the operating system on that iPhone, you could consider it as the EHR. So the iOS is the EHR and all the different applications run on that operating system. And Apple makes essentially APIs and the ability for developers to easily build applications. Well SMART-on-FIRE is essentially the same analogy for SMART-on-FIRE. And of course I'm gonna go into much more detail in on that, but that's sort of how I view it. And it's not quite the perfect analogy, but it's I think close enough to drive the point home of what it's trying to do. I promise this is the most boring slide you will see in this entire presentation deck. But FIRE, in case you're wondering and I haven't said it yet, stands for Fast Healthcare Interoperability Resources. Not important, really just came to be known as FIRE, I think because it's a fun pun to use, which I think is probably part of its popularity. But it's created and maintained by a group called a non-profit group, HL7 Health Level 7. They've defined a lot of the common exchange standards used within healthcare. You've probably heard of HL7v2. That's a really common standard for how medical devices transfer information from let's say a blood pressure cuff, how it gets into the electronic healthcare record. And then its two core components are these resources and then an exchange standard. So what is a resource? Resource is essentially a type of healthcare data we'll talk about. It's like an observation. So a time a laboratory test is taken or height is measured or weight is taken. And then the exchange standard of how that data is passed back and forth. Don't worry if this is a little muddy. This is, I said, it's the most boring slide. We're gonna get into what actually this means. And it uses these common web standards. So I mentioned HTTP, Hypertext Transfer Protocol of how the data is moved back and forth between location A, location B. It offers to a human readable component and it's pretty fast to learn, develop and implement which is key to actually getting developers and vendors to start using this technology here. So what do I actually mean? Well, a lot of that was just confusing. What does all this mean exactly? So we'll provide you with an example of what this means. So on the screen here, you see the logos for the common web browsers that most people use. Chrome, Internet Explorer, Firefox, Safari. If you go into any one of those applications and you type in amazon.com, where's it gonna take you? Well, right, it's gonna take you to amazon.com no matter which application you use. It's because they all use the same internet protocol for accessing this information that's stored on a server somewhere. Now I want you to imagine this same scenario but instead of these web browsers, think of them as the different commercial EHRs, Epic, Cern or Allscripts, Meditech. And then instead of we're going to a website, we're trying to access patient data or some data level. But instead of a web address, this is still a web address. It's still a URL of how we can access that. So that's essentially what FHIR is trying to do of making medical data easily accessible and within a common format. So developers can build apps that just pull this data in in any way, shape or form that they think users would benefit from. Of course there has to be security and protocols in place to make sure the appropriate people and profiles are accessing that data. But this is what FHIR is doing, is building this model of where this data can be stored in a common format data model. And just to try to drive the point home, I'm sure many people on the line have used a kayak price line, any of these travel booking sites, right? You go in, you type in your origination and your destination and the time you're going and it spits back a lot of flight information. Well, how does it do this? It's pulling in Frontier, United Airlines here, many other airlines. How does it get this information? It gets it through, because all the airlines adopted a uniform API or application programming interface that allows developers to pull in this data, to display it in any way they see fit. And this is the same analogy with FHIR. So instead of airline information, it's patient and healthcare information. That's what FHIR is really trying to do. And this is just to dive a little bit deeper. So how does it do this? How does FHIR really do this? Well, it represents data and again, a common format. So it's, and this is a JSON, JavaScript object notation here. And these are just name value pairs. So resource type, patient, active, true. And you can sort of surmise what it's trying to represent here. Just basic patient information, name, gender and birth date. But then now apply this to all the other data within healthcare. And I mentioned before, there are two acronyms here. So FHIR does the data model and representation. And what about SMART? So SMART was developed out of Boston Children's Hospital of a way to actually make use of FHIR. So, okay, so we got the data model, how do we make sure the right people are accessing it? And how do we actually build usable applications from it? And that's where SMART comes in. And you see on the left is a picture of health records from an iPhone. And that's what Apple used to build their health app. And so if there might be some people on the line, but Apple has partnered with, I think several hundred hospital systems of where you can log in through your patient portal, which validates your credentials in order to pull in certain data elements into your iPhone. So you can have a personal health record in your pocket. And that's what SMART enables. So SMART's enabling that authorization workflow to take place. And it also does some stuff behind the scenes to standardize some of the FHIR elements. But the main thing it's really trying to do is that authorization piece to make sure the right people are accessing that data. In this case, you have to log in through your patient portal. And you may not realize it, but we're already using this same technology all over the place. You've probably used it already today or several times this week. So I'm sure many people have been presented with this screen or a similar screen when they go to log in to many different websites. So you can hear trying to log into Etsy, but you can log in with your Google credentials or you can log in with your Facebook credentials. And this is using the same technology behind SMART called OAuth2 to do this, where it uses a third party credentials to validate a person in order to log in to a particular website or to create a profile, in this case, Etsy. So just strike out Etsy here, any SMART on FHIR app, and instead of patient portal, excuse me, instead of Google or Facebook, you're using patient portal credentials or your EHR credentials to log in or to use a particular application to access healthcare data for a patient. And to put it all together, SMART on FHIR, how all of this works, I'm not gonna go into too many of the details here. This is the overall schematic, but essentially hospital systems have all their different silos of data. And then what has to happen is there's a FHIR API that essentially has to be mapped to the FHIR server. So mapping all these data elements with the FHIR-I to a separate FHIR server. And using this FHIR server, SMART on FHIR applications can be built to then display that data accordingly. On the right here, this is a growth chart application that was developed up at Boston Children's Hospital. And it doesn't have to be just applications that are embedded within the EHR. They can be separate applications, as I mentioned with the Apple Healthcare app. And so there's basically the sky's the limit of the context in which it can be used, but I think a lot of people view it as these tertiary applications that are built directly within the EHR. So you can have, as I mentioned, an EHR-based launch. So say you're seeing a patient and it looks like a seamless component within the healthcare record, but it's actually a completely separate application that is just being run inside the healthcare record. And or a standalone app launch with your own credentials that you've established. And you can even then do bulk views of multiple patients if you're a case manager, for instance, and have multiple patients to keep track of here. And so one of the challenges though with FHIR is all the vendors here on the right utilize FHIR differently. They all have their own API for application programming interface that uses FHIR, but is not necessarily the same across them because they can implement in their own way. So this creates some challenges and hopefully these challenges are slowly overcome with time and we'll get into that more at the end, again, if there are questions about it. So for instance, on the screen here, this is a little bit outdated. This compares some of the major healthcare vendors on how they're leveraging the FHIR API. And they've each named it something different between them. Cerner, for instance, is called the Ignite API. Usually there's some related pun on FHIR, but so Cerner uses Ignite, but you can see they utilize it differently. So Cerner, you can read, there's a resource called Contract, but none of the other vendors can, versus some vendors allow both read and write capabilities versus only some can read. So what I mean by read and write, so that means that developers can pull information into their apps so they can pull in, patient's height, weight, laboratory vitals, but no data could be then written back to the database, to the database behind leveraging that's using that healthcare system, the healthcare system is using. So that's where it creates some difficulties. And then there's some difficulties too, of where do you store this information if it's not directly entered with the healthcare record? Those are some glossing over some of the current challenges with this. And then if you do want to learn more about FHIR, smart on FHIR, I've presented at several conferences in the past. One of my colleagues from Boston Children's, Josh Harrigan, and I built a tutorial. Usually it takes about two to three hours to run through the whole workshop and tutorial, but you can see the link here. Essentially, if you Google my name and FHIR GitHub, it should take you to my GitHub profile where you can download instructions on how you can learn how to build your own smart on FHIR applications. Very starter applications. There's a BMI calculator and a Framingham risk score calculator that are applications, mainly just to familiarize users with some of the inner workings of smart on FHIR. And just so you can see it and use it, because I firmly believe if you're not actively using it, you don't probably understand it that well. And so essentially forces users to use it in order to understand the technology behind it a little bit more. So again, Google my name, GitHub, you can probably find that tutorial. And next, so we can go circle back at the end if there's time for questions. Next, I wanted to talk about a rather large area, but I think it has a lot of room for improvement, particularly in just about actually every area of patient care, of improving patient outcomes and improving burnout from providers. And that's EHR usage data. And what do I really mean by this? And so again, the same vendors here on the left representing all EHR vendors are for the most part, the new vendors capture everything. Everything that you can imagine that you're doing in the chart from where you hover the mouse, from the keystrokes that you're entering, they are capturing that data. It's truly breathtaking how much is captured behind the scenes. Of course, it's probably not surprising as articles are released every day about commercial systems that capture all of our data, but it truly is, they really do capture everything you can possibly imagine within the system that we don't really leverage quite yet to its full potential to improve how we use the EHR and also to improve how we take care of patients. And I bring this up because I first learned about A-B testing years ago. I forget the context of which it was, but for those who aren't familiar with this term or practice, it's essentially, we're subject to it every day again by the big Amazons and Googles who want to tweak their interface to get the outcomes that they want for you to happen. So on Amazon, for instance, people use Amazon, there's a button that appeared, forget how many years ago now, the Buy Now button. And so this was trialed out as A-B testing. So for a certain subset of users, a very small percentage of users, they put this Buy Now in there and they tested to see if those users actually bought more than other users looking at the same items. And so it's essentially a way to quickly do a lot of these, you quote, randomized controlled trials, if you will, in an operational setting to quickly test ideas to see if you can cause the behavior that you're wanting. So in this case, buying toilet paper on Amazon. And so we don't really do this with commercial EHRs, even though there's a huge potential for potentially doing so. And we have the data to do it. And this is one of my favorite books by Richard Thaler and Cass Sunstein. I consider it a mandatory reading for just about any clinical informatician in the audience nudge. And these are two of the pioneers of behavioral economics, Richard Thaler won a Nobel Prize in economics. Cass Sunstein's got a lot of great books out and is an expert in the field. But how do we, it's essentially, how do we make the right thing easy to do? So how do we put in clinical practice guidelines or the best evidence-based care for certain conditions that guides users to doing the right thing? It's hard to, we can't force them because we can't always know 100% of the time what the right thing is to do, but we can enlarge and by probabilities, guide users down to the right action. That's essentially what behavioral economics is all about. And that's what A-B testing is really all about. How do we leverage these interfaces to get users to do the right thing and take care of patients? I'm gonna present a couple of examples that from essentially from a less complicated to more complicated of current ways that we're doing this. And then some ideas for how it could be improved going forward. And A lot of people are working on this but there's just so much room for improvement here. This is one example, Boston Children's Hospital from one of my colleagues up there, but this is just a simple alert. Now I say alert and alarm bells go off in a provider's minds, but there are, because of alert fatigue, but there are cases where alerts are appropriate. Many times they are not, but there are cases. This was an alert for Massachusetts that patients above a certain age required to check this Massachusetts prescription awareness tool, MassPAP. This alert was fired prior to signing prescriptions, as you can see on the screen there. And so what did this actually do? It actually decreased the rate at which opioids were prescribed, as you can see on the screen here. So again, getting the behavior that was actually partially intended with this alert. Ideally, they're checking this MassPAP tool, and then that's what's guiding them to not prescribe opioids in this case. So again, a very simple, this is a very simple, this is just alert. This isn't any complicated machine learning or AI put in place to guide behavior, but very simple things can be done to do this. And the opioid alert is that line down the screen, which you likely surmised. Another is just an order set of how we group and word orders. And this is what I think is so much fun about being in clinical informatics, of being able to make these small little tweaks, and seeing it trickle down to the masses that use the records to improve outcomes and improve how they use the system. So on the top here of the screen is an order set of transfusing platelets. And it's not really clear of which line on the right goes to which order on the left. And so there were a decent rate of errors when ordering platelets for transfusion. And so the simple change was, okay, let's just put the text directly to the right, and then have the reference text up at the top, which you can see at the bottom. And this just simple change here pretty drastically decreased at least the relative rate of errors for ordering platelets. So it went from a mean rate of around 3% to about a half a percent. So absolute reduction, not a ton, but a relative rate, a pretty significant decrease there. And these are two pretty simple, those prior examples were pretty simple. So I wanted to dive into some more complicated things now we can start to be able to do with machine learning and AI, taking some of these lessons. So this is a study that I directed here. So the problem was, how do we display electronic forms in a commercial healthcare record to all the positions, 123 positions in this case, that use these forms? So if there's 352 unique forms that users use, and 123 positions, how do we actually display this in a way that reduces the number of clicks to get to the area that they want to use them in? And so what we did was, we did an unsupervised machine learning methodology here to essentially let user behavior guide the configuration of these forms. So first, we broke out all the the data of form usage. So across the top, you have the name of the form. Across the left, down the left, you have the name of the position and the number of times that they charted each of those forms. So we're trying to find similar patterns of form utilization, so we can group those forms and positions together into common configuration settings to make the forms that those positions use easier to find. That was essentially the goal. And so we took all this utilization data and essentially did three different analyses to find the optimal way using an unsupervised machine learning technique called k-means clustering. And then there was some manual interpretation, as there usually is in this, and some consolidation. But the behind-the-scenes and heavy lifting was really done through the k-means clustering. I won't get into much detail unless there's questions later on about the exact different sensitivity analyses here and finding the optimal approach. But by and large, this is a within-cluster sum-of-squares graph to find the optimal number of clusters, essentially number of groups of these forms. You can sort of view it in the same way you would view a ROC curve with a sort of an inverse ROC curve. You want to find that elbow closest to this corner versus the top left, where ROC is sort of the bottom left. So we actually came up with seven different clusters of these forms. And you can see here on this screen, this is one quick analysis. You can see how they sort of make sense, so these clusters go together. All these nurses and techs are in one cluster, pastor in his own cluster, referral management, farm net, et cetera, occ health, OB. And we did some consolidation afterwards. But it did a remarkably good job of grouping like positions together into their utilization patterns. And that eventually led to the common configuration of these different form folders, of all the forms that were utilized by these unique groups of positions. So it was just determined by how they were already using them, but putting them in a way that made them quicker to find. And then this last group is for a database coordinator, so you can ignore this one. But really, the four on the left and these top three are the ones that are important for end users. And this, we're certainly not unique, and this was a fairly simple compared to a lot of other work that's been done over the past several years. And just a few graphs and a graph and a table from a study done by Dr. Overidge and McAuley, it was published in Animals Internal Medicine in 2020, of looking how different specialties spend their time within the healthcare record. Let's see, preventive medicine over here. You can see the percentage of time that we are doing certain activities within the chart, chart review, documentation, orders, message center. And this was largely descriptive study and not looking at any type of particular intervention of how to decrease time spent doing these activities. So this is sort of a stepping stone to further research. But this is one example of what we're able to pull. And then the question is, okay, how do we now decrease this time so we can spend more time actually on patient care? And another study published a little while ago in 2013, American Journal of Emergency Medicine. It was really popularized because of the title, 4,000 clicks, productivity analysis in electronic medical records. So this looked at how many clicks does it actually take, at least one aspect of the study, how many clicks does it actually take to do certain things in the chart? Now, our job as clinical informaticians should be to reduce these number of clicks. For instance, to completed EMR, right upper quadrant abdominal pain discharge. So number of clicks it takes to essentially, that patient go from A to Z for upper quadrant abdominal pain, or just order an aspirin, six clicks. So we have this data to start looking at behavior, how long it takes to do stuff, but we haven't really started leveraging it in order to improve these data here. And going back to the A-B testing and focusing on, there's so much room that we could be doing, focusing on these different, really from a task-based approach of how do we decrease time to order aspirin? How do we decrease the time to actually write a note? And I think we're just on the cusp of that now of really diving deep in order to do this in these commercial EHR systems. And my last area that I wanted to talk about is digital contact tracing. Very pertinent now with the ongoing pandemic, and it builds on EHR usage data as well as some other technologies. I actually helped design a study up in Boston Children's Hospital. We're still working on it being published, but just to provide some background of what we're doing here with digital contact tracing. So this is not a unique concept. There are several studies that are published in the literature of how to utilize EHR data to detect potential contacts for infectious disease purposes. So one study, the first study up here at the top, was tracking a TB infection in oncology world. It was done at Memorial Sloan-Kettering Cancer Center. And then Johns Hopkins performed a different study looking at healthcare workers as vectors for VRE using EHR data, and lo and behold, found that having a connection to a VRE-positive patient via healthcare worker did indefinitely increase the chance of acquiring VRE. It's probably not rocket science there, but they did have some physical significance with their study. And then out of Stanford, Stanford modeled social networks in hospitals to see how hospital-acquired infections could circulate. And then lastly, Children's Hospital of Philadelphia used EHR data to capture real-life provider-patient interactions for residents. Now, primary purpose of the study was for GME-related purposes, but they did validate EHR data as a proxy for in-person exposure with follow-up surveys. So it's not necessarily a novel thing to use EHR data as a proxy for in-person interaction. And so we had the idea of, now can we do this for COVID at Boston Children's Hospital? Can we use this EHR data as a proxy for COVID exposure in the hospital? And so we took, this is sort of a Cerner lingo, but there are certain, I'll say, activities called clinical events. So we took vital signs, documentation, direct assessment, line-tube grain assessment, and then order actions. So orders entered on a patient or recognized, acknowledged, and medication administration to see if this could augment current existing methodologies at Boston Children's for contact tracing. And these are some of our results here. The current process that was in place at Boston Children's Hospital, highlighted on the left column, the overlap between the digital technique that's briefly described in the middle and then unique staff that were identified with just this digital contact tracing method and patient-staff pairs on the right. So essentially, one patient, of course, may have many staff that come into the room, and so this was identifying those different pairs, so unique patient-staff pairs there. So it did identify 20% additional staff and about 44% additional pairs with this methodology, looking at those clinical events and those order action items. Then we stratified those to look at particular roles, so nurses, physicians, and advanced practice providers, other clinicians, non-clinical staff, and support staff, just to look at the breakdown of how the tool was potentially performing, pink being the overlap between the two, red being just the current contact tracing process, and just the digital-only process in the blue on the right. We did note the system support staff who actually didn't use the EHR, not surprisingly, did not have any identified by the digital process using the EHR data. And what was, I think people may have heard about on the line about some similar methodologies, not necessarily using EHR data, but there's, I guess I should go back and just talk briefly about some of the key limitations with this. So we don't know, of course, who is actually 100% exposed unless we followed up with who actually got COVID, of course, and so our main takeaway from this, without doing follow-up studies, there's, I think, some obvious follow-up studies that should be done with this, but our key takeaway is this can likely just improve the sensitivity of the current manual process. Now, we cannot speak for the specificity of this whatsoever, and you have to have, of course, follow-up studies to confirm who is actually considered exposed to COVID, but as a 30,000-foot view, we're certainly increasing the size of the net to find these potential exposures. And again, this is just scratching the surface of what could be done, and there's a lot of room for improvement and, most importantly, validation of this in the future. So going back, sorry, to this slide, so we just used EHR data here. I mean, this is just one different, one source of data. There's many others, and people have probably been aware in the news of Google and Apple creating an API to allow developers to leverage their back-end tools for contact tracing has not really had any uptake, much uptake in the U.S. Some other countries have had better luck, but still, there are massive privacy concerns with this. But when you combine EHR data, we actually briefly looked at some Wi-Fi and Bluetooth data, did not end up using it, and it's very complicated. We did not have the technological resources to appropriately process that data, and there was privacy concerns, so that was not leveraged in any way. But with Bluetooth, with Wi-Fi, RFID, GPS, and EHR data, they're the tools for actually tracking these contacts. Now, granted, if you have to have a smartphone in your pocket, clearly a limitation, but you can also do it with general badges that hospital employees would wear or patients would wear, too, to actually track those types of interactions. And so, the sky's the limit here of what actually could be done with this area of digital contact tracing, but I think the main really impediments are, okay, what are some of the privacy concerns of doing this here? And that is, of course, to be determined. And so, we're approaching the end here, so I will just wrap up with a quick cliché picture of the fake Photoshopped iceberg that many of you have seen in presentations, but we're essentially just scratching the surface with a lot of the three technologies that I went over, smart on fire, EHR usage data, and digital contact tracing. There's so much more that could be done. And again, to go back to my agenda slide, really the purpose of this was to just provide some hmm, some head scratching. This sounds really interesting. I'd like to potentially get more involved in this or look at designing a study around this of how we can actually improve this, or how can I build an application with smart on fire? So, that was really the goal of this, and I am now happy to answer any questions about what you've heard so far. I think it's my turn to pop back in. Colby, thank you for that excellent presentation. I think, you know, speaking for myself and hopefully for others, my head scratching and the hmm effect is in play. It's always nice to get a bit of a look at the landscape of what is and what could be, especially from someone that is boots on the ground. So, I appreciate you bringing that to that space, and we have about 11 minutes here, it looks like, or probably five or six, based on what Dr. Michelide will let us get away with. So, transitioning to a bit of discussion and taking questions from the audience. If you do have questions, please enter those into the chat. ACPN is going to go ahead and scrub those and get those to me, and I'll read those off. But just to get things started and to help things roll forward, obviously, you know, there's so much potential, and we see the idea of it's too good to be true coming into a play with a lot of these, that there's some devil in the details or some nefarious actors going to come in and make things complicated. So, where is the catch? And then, on that same note, why aren't these applications being used? And I think, you know, and then, on that same note, why aren't these applications more widespread, even outside of healthcare and to other areas of life? Yeah, that's a great question. You know, I talked a little bit about the healthcare vendors, and they're unique, in this case, the FHIR API. And one of the major concerns is getting the vendors to play ball. So, the healthcare systems that are homegrown EHR, they still exist, but they are slowly dying. They're slowly buying these commercial EHRs, because of the promises that they do hold. And so, it's really getting these vendors to open their doors to data. And the 21st Century Cures Act, which you're probably much more familiar with than I am, starts to open this crack of, okay, vendors, you have to make this API available. You know, and, you know, I think the goals of meaningful use were really just to get, okay, everyone just needs to adopt healthcare records, and we're going to, you know, eventually penalize you if you don't. Now, we need, though, to start focusing on interoperability. So, now that a lot of people are using these healthcare records, now the focus is, okay, let's make them interoperable. And so, the first step was just to get people using digital healthcare records. You know, I have some other presentations I did with graphs of the dramatic uptick in healthcare records that happened over the past decade, digital healthcare records, that were spurred by meaningful use. So, that's sort of step one. And then, you know, step two is now to get the vendors to play ball. Some of them are more willing than others. You know, for instance, Epic, Epic CEO, got a lot of Epic hospitals to sign a letter protesting, you know, this open door. Cerner has been a little bit more on board, and they partnered with Amazon. And, you know, I think they're a little bit more forward thinking. I can't speak for the other vendors I'm not familiar with. There's so many of them out there. But I think that's one of the big impediments, is just to get the vendors to play ball. And I think, you know, we may end up having to, you know, force them a little bit or incentivize them correctly to do so. And then, it's getting access to the data is one thing. And the second thing is putting space within the EHR to allow them to operate smoothly. And so, FHIR's great, but it's only as great as people that develop the applications, just like there are apps on your iPhone that you never use, or that are poorly or have bugs in them. The same thing can be said for these applications. So, at least the few apps that I've used, there's just been a few things wrong with them, and then people don't like using them anymore. But, you know, we're at the very, we're at like day one, day two of the Apple App Store, I would say, with, you know, with these applications. And, you know, give it another five to 10 years with some proper adjustment for how innovation is a little bit slower in medicine. And, you know, I think we could be there. But I think it's just going to take some time and a little maybe more prodding to get it going. All fair points. And I think that you've acknowledged a few elephants in the room that certainly do need to come to the table. So, we've got a more granular question here from one of the attendees. It says, what does the 80% solution in your second or third slide refer to? Could you please be more specific or provide any examples or insights about it? Yeah, that's a great, that's a great question. Yeah, it's the slide I mentioned being the most boring slide. I should have included one more slide and ended up not doing it that expanded a little bit more about what I meant there. So, I mentioned the body HL7 is the one behind FHIR. So, prior to FHIR, they came out with HL7v3. And no one uses HL7v3. Well, probably that's probably a little bit of hyperbole, but almost no one uses HL7v3 because it is so specific. It was designed to be the 100% solution. You have to do this. There is no flexibility whatsoever. And so, FHIR took this lesson learned and said, okay, we're going to provide the 80% solution and then allow these extensions to come into place and allow for some customization. However, in order to do that customization, you have to essentially, when you build the FHIR resources, you have to build it in a way that properly articulates what that extension is to sort of like an accepting app developer or healthcare system allows them to process that extension effectively. So, for instance, within the FHIR model for the patient resource, there is no mandatory input level, input for ethnicity, for instance. Of course, a lot of healthcare institutions are going to want ethnicity, right? And so, that would actually have to be something that you act directly right for. And so, that's an example of that 80% solution. So, they found the 100% solution was too prescriptive and did not have uptake, at least the prior lesson learned with V3. And so, FHIR took a little step back, okay, 80% solution will follow the Pareto rule, and then you can have build extensions within it when needed. No, that's perfect. I think, you know, it's playing in the realm of reality as opposed to the theory of what the ideal is. It's good to get the small win as opposed to moving nowhere. We do have one more from an attendee here, which I'll read off. How widely implemented is ADT notification? And if it is not widely implemented, what is preventing that? So, ADT, does it mean Admit Dispo Transfer? What's the, can you specify? ADT? Yep, I'm not getting any further clarification on what ADT refers to. Yes. So, yeah, I'm not actually familiar with what this is specifically I'm referring to of just like a notification that someone has been, you know, admitted, disposed, or transferred. I imagine it's very different on probably even within healthcare institutions, but especially different across healthcare institutions and vendors of how this notification appears, you know, and I can speak for Cerner, EHRs, you know, this would be a discern alert potentially to, that's activated on a particular position logging into their floor for the first time to say, you know, a new patient is, you know, awaiting transfer or waiting admission or something along those lines. I can't speak for the specifics of that or how widely that's particularly adopted. So, I apologize for my ignorance on that question. I think I'm looking at the time and Dr. McIlyde has come back on to screen. So, I'm going to assume that means that we are to wrap it up. Thank you for everyone who provided questions and I'll hand it over to Dr. McIlyde and thank you again, Dr. Uptegraff. Yes, thank you for the opportunity and thank you Dr. States, Dr. McIlyde. What a fascinating session that we had today. Thank you so much, Dr. Uptegraff and Dr. States for speaking and moderating and I'm sure our colleagues will follow up with you if they have additional questions. We'd like to invite you to join our next ACPM webinar on colorectal cancer advocacy with an organization called Fight CRC who have been working at the grassroots level and in states to try to modify legislation around payment for colorectal cancer screenings. That will occur on September 29th at one o'clock eastern time. So, I hope you can log on to the website and sign up to join us. Also, please be on the lookout for the event survey and I invite all of our listeners to log on to acpm.org education and events and CME because we have more than 200 courses within our learning management system for your personal edification and to learn to earn your CME MOC credits. So, please look to that if you are interested in learning more. So, we thank you very much and we'll be signing off. Have a good day. Bye everyone. Thank you.

preventive medicine

SMART on FIRE

EHR usage data

digital contact tracing

healthcare data sharing

EHR-agnostic applications

patient outcomes

provider burnout

infectious diseases