 Good morning. I'd like to welcome you out to my talk, Capacity Analysis, Mapping How Interventions to the Spread of COVID-19 Improve Healthcare Providers' Ability to Meet Patient Demand. Sorry that was a bit of a mouthful, but by way of introduction, my name is Christian Echinus. I'm a product engineer at Esri and I work on the ArcJS API for JavaScript. Let's go ahead and dive right into this. If there's any lesson that the pandemic has taught us, it's that geography matters and that spatial thinking matters more now than ever before, and that will be an overriding theme throughout this talk. Ultimately, this came down to one goal. We wanted to build an application, a web app that properly communicates how interventions to the spread of COVID-19, such as physical distancing, reduce hospital stress for a particular area of interest. But before diving in, I want to take a quick minute to describe the work that Esri does and the work that I do to put it all into context. Esri builds GIS software. That's short for geographic information systems and that's just a fancy way of saying that we build mapping software and we build a variety of spatial analysis tools for desktop, mobile, and web clients. We also provide dozens of APIs for developers to extend our software and to build their own customized applications. So this chart here on this particular slide is a little overly simplistic. We do build all of these apps, but we expose a variety of APIs for developer community. But I specifically work on ArcGIS API for JavaScript. This is a powerful API that allows us to build web applications, specifically for mapping. And I'm particularly, particularly involved in many of the projects that you see here on the slide and they're related to data visualization. We do everything from 3D mapping to multivariate mapping, predominance, and particularly what I'm most interested in, which is exploratory mapping. And that's going to play a heavy role in my talk today. But I also want to mention this fast performance with WebGL. We have a WebGL rendering engine, which allows us to build highly interactive applications in conjunction with this client-side query engine that we have within the JavaScript API So I'll touch on that a little bit later, but I just want to note that this is all about exploring data. Some apps that are built with the JavaScript API include configurable applications that Esri openly provides to customers. And these include dashboards such as this one. This is one that you're probably familiar with or may have seen in the news. This is Johns Hopkins University's Coronavirus Resource Center. It's the most up-to-date tracking app of the virus out there today. And so they basically built this using a configurable template that's built on top of the JavaScript API. But before going into the hospital capacity question, I want to give a brief overview of just a small portion of our APIs to set up the work that we did there. The ArcGIS API for JavaScript isn't about just showing where things are located, but it's more about what is there, how much of it exists, and doing that in a meaningful way. And there's many ways to do that, and I'm just going to touch on a couple of techniques, and those are size and color. So if we look at this particular map on this slide, we're looking at the total number of positive test results by a particular date. So this, I believe, was displayed for June 1st of this year. And the way that we created this visualization is using the renderer property of our layer. The layer is U.S. counties, and we represent them as icons or circles, those pink circles in the centroids of the county. Where the data-driven aspect comes into play is with visual variables. The visual variables just simply allow us to override a property of the symbol. It could be size, it could be color, it could be rotation or even opacity, and we override it based on a data value. So in this case, we specify a field, so the number of infections on June 1st, 2020, and then we'll indicate what size the icon should be based on the value of that data. So in New York, we have a value of over 200,000, which would give the size 20 pixels, whereas other places in the Midwest and West would be much smaller. So we think that this is a very simple, intuitive API that allows you to create dynamic visualizations that allow you to understand what's happening. You can also look at color, such as here, we're using a fill symbol instead of an icon, and we're changing the fill of the color based on a data value, and you can see those color steps down in that blue highlighted region below. What's different here is we're actually using what we call arcade expressions or value expressions. Arcade is an expression language developed internally at Esri that allows us to calculate new values client-side. So when we don't have access to an attribute or a column in our table or database, then we can calculate that on the fly client-side. So in this case, we want to look at the rate of infections per 100,000 people, and so we use an expression to do that, and you can see that there. Now, when we talk about data exploration, there's a couple of ways you can look at it. There's a way of exploring data using filtering, that's just simply removing the features that don't conform to a particular expression. It's a very common way of looking at where things are high or low, or you can actually modify the style or the renderer itself, so the color stops. I want to change the color stops to see where the most infections are occurring, perhaps it's the highest rate. But when we update the color stops, it's simply updating those stop values or even the colors themselves, not the data itself. And that's important because when we get into the multivariate or multidimensional data exploration, it becomes more about modifying the data value itself. So in that previous example, we're just changing the colors, seeing, okay, these are areas of higher or low, but that's only based off one field. It's that number of infections up to May 31st. And what if we want to see the number of infections or the rate of infection over time? That would require a constant set of stops here, and then updating this value up here. So that's something we can do using a technique called multidimensional data exploration. And that's simply taking, you know, a few dimensions, such as the location, and then the variable and this GIF we're looking at temperature in the ocean. And then we can explore it with another dimension. It could be time, it could be an agent cohort or income brackets for demographic data, or perhaps Z values, like depth and elevation. That's actually the third dimension that's being used in this particular application here. But when it comes to mapping COVID-19, the most obvious case is or dimension to use is time. So we want to look at not just what is happening, but when is it happening? Let's build an app that allows us to explore COVID-19 data through time. And so that comes from a number of different questions you might ask, like how many people are currently sick? How many new test reports or results were reported today? Or how many people have been infected or who have died to date? Those have been the predominant questions that have been asked, and you've seen that with hundreds, even thousands, of mapping applications that show that, such as this dashboard, where you can see how many cases have been reported per day by geography. Okay, here I've opened up my browser to show, conceptually, another way you could look at the past data as a time series. I've just taken the Johns Hopkins data. I've added a time slider, which is out-of-the-box widget in the ArcGIS API for JavaScript. And when you hit play, you can see how the number of infections grows per county in the U.S. So it's no longer just about a static display of what's happening today. It's about what's happening over time, so you can interact with that. This is not a time filter. I'm not filtering out different counties. I'm actually just updating that visualization, and I'll show you that in just a bit. You can also use Arcade to create more complex visualizations, such as doubling time. So I see the total number of infections, but then I can use color to indicate how fast those infections are growing. So I can see that in the Midwest on this particular date, May 7th, that they were still doubling at seven days or less. And you see that in Chicago, too, right there. So you can create some pretty cool applications using this multi-dimensional approach. So if you look at this CSV data up to the right, this is the Johns Hopkins CSV that I was talking about just a second ago. Basically, they add a new column every day with the total account for the infections up to that date. So it's up to date, and you can work with it seamlessly. So if I want to map that, I just create the render like I did before, and I reference one of those fields. So I'm referencing April 1st, 2020, and then I can map it in my view there. And if I want to change my visualization, rather than copying all my features and then rendering it based on a different field, I can simply update that field each time the slider position changes, and that will allow me to see how it changes over time. We're able to do that because we bring all that data down to the GPU. And so when the renderer updates, we actually have access to that data already. It's in a lookup table, so we can just point to that field. It's already part of the geometry, so we can update the style of it. We don't have to discard the geometries and re-render them like we used to. This allows us for highly interactive applications. All right, now let's talk about the future. So not just who's been sick or how many people have been sick up to this date, but we want to look at, are we prepared to handle a novel coronavirus and how many people might require admission to a hospital? And that all depends on modeling, authoritative modeling, and forecasting that because we can't obviously predict the future. And this is a chart that from the CDC that we're probably all familiar with, and that compares two different curves. It shows the number of cases over time if no intervention is taken during a pandemic outbreak. That's the purple one. If you look at the smaller curve, that indicates the number of cases over time if intervention takes place. And that's important for two reasons. One is that it reduces the overall number of cases, so we save more people. And two, it helps our hospitals out because they only have a certain number of beds, a certain number of ventilators to help treat people for a disease like this. And so by intervening and flattening the curve, we can help them out so they can treat an appropriate number of people. So but looking at this chart, there's no numbers on it. It's all conceptual. So we need models with real numbers to help us truly understand which interventions will work and what needs to happen in order to help us in this scenario. And so various things are proposed such as social or physical distancing, wearing of masks, shelter in place guidelines. But that also prompts people to ask, well, how much does that actually help? And when can I get back to normal? Does the phased approach to reopening actually work? And how much does that improve versus reopening everything now? And so what we do is we can run various outputs of models as what-if scenarios. This allows us to understand which policies will work. That'll allow us to properly allocate hospital resources to areas that are in more need and to know where test facilities should be located. Ultimately, an application like this that I'll show in just a second will allow us to transparently communicate results to the public and to the people who are making these decisions. Now when we talk about forecasting using models, there's two authoritative models that we at Esri have looked at as helping us in this effort. There's the CHI model, which was developed by Penn Medicine and the CDC's COVID-19 surge model. They both look at similar parameters, such as the number of cases in an area, the number of hospitalizations, the total number of hospital resources, and susceptible populations. The differences are that the CHI model looks at social distancing as a parameter, so you can indicate the percentage of the population that complies with it and how that affects the number of hospitalizations as well. Then the COVID-19 surge model looks at a stage intervention approach and how well that actually will help reduce the number of hospitalizations. In our particular applications, we want to look at three variables. How does variations in these parameters affect the number of required hospital beds versus ICU beds versus the number of ventilators needed? Our spatial stats team at Esri developed these two two geo-processing tools based on these models. That allows us to hand the tool to the experts, the epidemiologists, the health experts, so that they can put in their own authoritative data and run hypothetical scenarios, such as what happens if 30% of the population complies with social distancing, and what happens if we reopen businesses in three phases versus no phases. I was not involved in that part, but where I became involved was in developing this web application called Capacity Analysis, and that allows us to understand how impactful a particular policy can be, and that the fundamental idea behind it is comparing two what-ifs and running them side-by-side, so you can see how well the curve flattens for the overall data set and also for a particular geography. So I'm going to open up this application here in my web browser. Here I've opened the kind of a default view of of this Capacity Analysis app, and now I'm comparing the two two different outputs of the CHI model. The view on the left shows what happens if 29% of the population social distances, the view on the right indicates what happens when 50% of the population social distances. This is a really simple app when it comes down to it. There's three attributes that the user has control over. They can look at the number of hospitalizations, number of expected ICU patients or ventilators used, and then they have this time slider down here at the bottom, which allows them to animate through time to see what they can expect will happen based on these different parameters. So if we look at May 31st, we can actually see that 29% social distancing, people are much worse off than if 50% social distance. Our hospitals will be only up to 27% capacity. Now you'll note that that's not necessarily true across the board. That's the benefit of using maps. If we actually look at our map legend, this will help describe our methodology for the visualization. We actually use two visual variables. There's the color variable that indicates the capacity, so the hospital stress. If you're under capacity, or if a county's hospitals are under capacity, they'll be rendered with a small icon and they'll be gray, or maybe an orangish-peachish color. Once you hit capacity, that color will change to orange and then get a deeper red as you get worse above that. And then that's when the size kicks in. The size does not indicate the total number of patients. It only indicates the number of patients above the hospital's capacity. So the idea is to show not only are you at capacity because that's the critical variable, but how worse off are you? So you can see these metro areas such as Orlando and Miami and Tampa being much worse off in this case of lower social distancing numbers than when there is. So having the side-by-side views is, it's an easy way to see, wow, this actually will help our hospitals out a whole lot more if people, more people comply to this order or to this recommendation. We looked at other ways of visualizing it, like displaying both layers in the same view, or maybe calculating a difference between the two, but they don't effectively communicate it like this does, and this allows us to also associate them with this chart below. So if I click on feature such as here you can see the chart update specifically for that county. Now what went into building this application? So the outputs of that model that or both of those models that I described do not follow the same format that I showed with the Johns Hopkins data. The Johns Hopkins data was outputting a new counts with a new field every single day. That was not practical for this particular case because we have three attributes that we're looking at, the hospital beds, ICU beds, ventilators, and if we created three new fields per day we'd have a huge table that would be hard to manage and we actually run into technical limitations with our feature services once you hit a certain number. So we decided to basically generate these numbers and then provide them in a single field as pipe separated values. So when the user selects an attribute such as hospitalizations they can then move the slider to a particular position and then using the same technique that you saw before with parsing of the arcade attribute we can actually use arcade to parse that value out and then map it in both views. So this is actually happening two times in the same app with each slider change. As the slider changes this is what's happening. We take the position of the slider and then the variable selected by the user and pass it to a function called update renderers. What that function does is it creates new visual variables, a color variable, and a size variable. The color is what's indicating that percent capacity that you saw in the app itself and then the size indicates the number of patients over capacity that a hospital will be at. That has to be calculated with an arcade expression because we're just looking at raw counts in the actual data set. And so those functions for generating the arcade basically will create these expressions that you see below and the important bits are highlighted there in yellow. So we look at the total number of hospitalized people. That's how we parse it out in arcade. It looks similar to what you might do in JavaScript. Obviously these are custom functions that we've developed but we get the number of hospitalizations based on this field and then we just grab the the count for a particular day indicated by the slider and then we do a simple normalization and percentage calculation. And then with the overages exact same line of code here and then we just calculate the difference between hospitalized versus capacity. If you're under capacity you're great. If you're over capacity then that's when things become a problem and we need to visualize it appropriately. In conclusion the goal was to make an application to put into the hands of the experts. So we converted this into a configurable app template. That allows experts and their development team to download the application and then run the models themselves and then they can deploy it on their own terms. So it's not us at Esri saying this is what's going to happen or this is what we predict will happen. We built the software, we deploy it, and we allow the experts to take over and communicate their own results. We wanted this to be interactive. We wanted it to be clear, understandable, and personable and easy to use. As you know there's only two controls and it's side by side. It's easy for people to understand that one method will may substantially reduce the number of hospitalizations versus another. So with that I'd like to thank you for joining me for this talk. Again I'm Christian Ekinness. If you would like to continue this discussion or if you have any questions or comments or feedback I encourage you to reach out. There's my email address. You can also reach out on Twitter and perhaps you could even visit my GitHub and see some of the projects that I've worked on there. And once again thank you for listening.