Good afternoon, everyone. Welcome back after the quick launch and break. We're going to end the recording today. We're going to switch gears a little bit and move on from all the excellent comprehensive lectures that we've been watching over the next over yesterday and today, we're going to move on to the point of care ultrasound, incorporating both transtheraistic modalities and the incentives of the deal, and focusing not only on the heart, but also other organs that can help in the overall perioperative care of these patients, and not only in the operating room, but also in critical care units, recovery, even the words. So for this section, Dr. Marcus Alvator is going to be the moderator, and myself is the curator, and then I have the president here, and I'm a cardiologist in perioperative echo at Sonnybrook Hospital, where we also run for a point of care ultrasound fellowship program. So I'll leave it up to you, Marcus. So thanks very much, Pablo. So thank you everyone for your attention and participation over the past two days, and congratulations to Dr. Vegas for putting together another incredible conference. The amount of work that Annette and her team have put in over the past year cannot be overstated, as evidenced by the quality of the talks and discussion we've seen over the weekend. My name is Dr. Marcus Alvator, and I'm an anesthesiologist and CVSU attending here at Toronto General Hospital, and it is my honor to moderate the final session of this conference focusing on the utility and practicality of point of care ultrasound in and out of the operating room. This session was curated by my good friend and mentor, Dr. Pablo Perez-Demper, who you just met, a cardiovascular anesthesiologist at Sonnybrook Health Sciences Center here in Toronto, where he continuously champions and innovates the use of point of care ultrasound and trauma, cardiac arrest, and emergency non-cardiac surgery. He has put together an extremely impressive multidisciplinary roster of speakers from across Canada and the United States, and we will hear about POCUS from the perspective of not only the cardiac anesthesiologist, but also the disciplines of internal and emergency medicine. Our first speaker of the afternoon is Dr. Katie Wiskar, a general internist at Vancouver General Hospital. She completed a POCUS fellowship at Western University in London, Ontario, and she now leads UBC's general internal medicine POCUS fellowship program, one of only two such fellowships in the country. She currently splits her clinical time between attending on the clinical teaching unit and running the VGH internal medicine POCUS service, a clinical team which provides hospital-wide diagnostic and procedural POCUS consultations. Her POCUS passions include VEXIS and POCUS evaluations of volume status, all things echocardiography, and clinical integration of ultrasound findings. As with all prior talks, please post any questions in the Q&A and we will discuss them all during the panel discussion involving the afternoon speakers. Alright, hi everyone. My name is Katie Wiskar, and I'm really thrilled to be here today speaking to you about VEXIS for fluid tolerance. So I have no conflicts to disclose. My only disclosure as such is that I admit to feeling a little bit starstruck. VEXIS is something that I'm really passionate about, and I spend a lot of my time thinking about and reading about. But I noticed that two of the faculty member on the conference today who are actually speaking on different topics are actually two of sort of the real godfathers of VEXIS, whose work has helped really push this forward. Drs. André De Neau and William Beaubien Soulinghi. So I will say that I'm very grateful to them, to their work and to the work of others that have helped push this topic forward and allowed me to be here speaking to you today. So our objectives today, we'll talk a little bit first about the idea of fluid tolerance and how we look for this with ultrasound. We'll talk about the VEXIS exam, a little bit about how to do it, and some of the evidence behind it. And then we'll finish by talking about what the knowledge gaps are. What do we not yet know about, you know, the evidence base, the technique and how to put this into practice. So let's start off by talking about fluid tolerance. So fluid responsiveness has been talked about ad nauseam. This is a very familiar topic to everybody. Enumerable publications are written on the topic, so, you know, will someone's cardiac output increase in response to a fluid bolus? And for a long time, this was kind of a main focus when we thought about fluid therapy and hemodynamics and volume status, really this focus on the left side, the mean arterial pressure fluid responsiveness. And this is not unimportant, obviously, but I think recently we've begun to recognize that there is another side of that coin, just as important as fluid responsiveness. So might the patient benefit from fluid is this idea of fluid tolerance. So might the patient be harmed by fluid. And we all recognize the increasingly the harms of excessive fluid administration and fluid overload in multiple organ systems. So, you know, to name only a few pulmonary edema, hepatic congestion, congestive nephropathy, congestive encephalopathy, tissue edema, the list goes on. And I think, you know, for a long time we believed or we hoped that patients were essentially fluid responsive and fluid tolerant to a point, and thereafter became fluid unresponsive and fluid intolerant. And what we realize increasingly is that these are really two separate concepts that can occur at different points in the trajectory in a patient's illness and those points can actually even move as a patient moves through their illness course. And so increasingly, you know, we really want to think about these separately. And, you know, despite the fact whether or not a patient's cardiac output may or may not improve with fluid, the kind of flip side to this that we really have to think about is, is there evidence that they may be harmed by additional fluid. So this is the other piece to that kind of volume status question. So, how do we look for this with ultrasound, this is an ultrasound conference after all. So obviously we'll look at the heart, we'll look at the left heart at LVEF at diastology if that's something you're comfortable with to see if there's signs that you know the left heart may not handle this well. We'll look at the right heart obviously for signs of RV dilation pulmonary hypertension RV dysfunction etc. To look for left sided congestion. We can again look at the lungs if you look for pulmonary edema be lines plural effusions. But when it comes to looking for right sided venous congestion up until recently we didn't have a lot of tools so you know we could look at the IVC in the JVP. But, you know, we've long recognized that these are imperfect measures. They are sensitive but not specific for deleterious venous congestion. Many patients, especially patients with chronic pathology will always live at a plethora IVC. And so, you know, really, we lacked a lot of tools to help us detect this right sided congestion this venous congestion. And so this is where the idea of vexes comes about. So vexes stands for venous access ultrasound score. And again, the principle behind this is, can we take a step back farther away from the right atrium farther away from the IVC and look at other inter abdominal vessels with ultrasound to find further evidence more specific evidence perhaps of deleterious venous congestion. And it turns out so so the vexes is quite a recent concept this paper this is a seminal paper on vexes that I've shown you a graphic from is from 2020. But people have actually been looking at these waveforms in isolation for decades in some cases so this is not a new concept. But what this group did doctors Bobi Assoulini and his colleagues is put these together so they said, can we look at several of these inter abdominal vessels so namely the hepatic vein, the portal vein and the inter renal veins and use them to help us paint a picture of venous congestion. Because we know that each of these vessels has a characteristic Doppler profile with pulsemaid Doppler under normal physiologic conditions, and that profile changes predictably with increasing venous congestion. And so again what we can do is look for signs of congestion in multiple waveforms because each waveform has sort of its nuances and its pitfalls. But if we see evidence of congestion in several waveforms that paints a strong picture really suggestive of organ damaging venous congestion. So I won't go through the details of how to do this in the interest of time, but very briefly this is sort of what this looks like. So your first point is always the IVC the IVC is your entry point to congestion. If you don't have a congested IVC do not do not pass go do not collect $200 you know you stop there. The other thing I'll say about examining the IVC is in the paper they used a diameter cutoff of two centimeters. And I know because I've spoken to several of the authors about this in person that they actually wish they'd also been able to include some data on the short axis of the IVC. So there's some evidence to support the fact that a really spherical round plethoric IVC is actually a better correlate, rather than the diameter or the or the collapsibility alone. So adding a short axis can help here, help you detect whether or not an IVC is truly plethoric. If you find a plethoric IVC you're going to go ahead and examine the intropodominal vessels where possible. So starting with the hepatic vein. This is usually easy to identify in B mode, either in a subzyphoid view or in a trans hepatic lateral approach, either with a phased array probe or a curvilinear probe. You'll see it in 2d you'll see it draining into the IVC, you can throw color on to confirm that you have a nice Doppler signal.  And then I won't go into too many of the details of this, but the waveform I've shown you here is abnormal so normally a hepatic vein should have two primary components that are below the baseline, indicating blood flow down the hepatic vein towards the heart that s and a d wave insistently and diastole. And as you get increasing and especially severe congestion we can actually see reversal of that s wave above the baseline as is demonstrated here. Next you'll go ahead and find the portal vein. So again looking in the liver typically from a trans hepatic lateral approach. The portal vein is usually quite easily identified it has bright hypercoic walls in 2d and with color Doppler you should see that nice red pathopetal flow. Again with pulse wave Doppler, you'll get a spectral waveform, which normally should be continuous low grade flow. And here I've shown you an abnormal waveform that we see as quite pulsatile with a lot of variability. Finally you can look at the kidneys. The kidneys are always the toughest. The vessels are very small because you're looking for the intra renal vessels. Ideally a vessel that is actually in the renal cortex or at the cortico medullary junction. So color is really necessary here to help you pick up those vessels.  Sometimes you'll actually see the arterial waveform above the baseline and the venous waveform below the baseline. Here we just see a venous waveform which is abnormal. Again normal flow is continuous low grade flow and here we have highly abnormal what's called monophasic flow present only in diastole. So that's kind of the gist of how you do it. Coming back to the original Vexus paper very briefly this is sort of what they looked at. So this was a cardiac surgery, a post cardiac surgery population. And what they did is they took patients on admission to the CVICU did a Vexus score on them and then look to see did their Vexus score correlate with subsequent development of acute kidney injury. Now in the table on the left here, you can see a lot of different grading so you have Vexus A, B, C, which is somewhat irrelevant. Essentially the authors were playing with different permutations that made up the Vexus grading system. The one that was sort of settled on is this Vexus 3 grading system, which means severe abnormalities in more than two waveforms. I'll also say here that increasingly so many of us use this in our practice without actually using sort of a numerical Vexus score on a daily basis but rather by examining the waveforms and describing quantitatively or qualitatively what we see. Because this allows you to use these waveforms even if all of them aren't available, which can often be the case and sometimes gives a bit more nuance. But regardless we can see that here in this paper what they found is that patients with severe congestion so a Vexus of three severe congestion had a higher incidence of developing acute kidney injury compared to those who didn't. What we see here in the leaf plot on the right is actually that a positive Vexus score so again a Vexus considered consistent with severe congestion as shown in in graph a made a much more significant change in the post test probability of developing aki compared to an elevated CVP which is what you see in graph B. So this was a useful correlate for the development of adverse kidney outcomes in this population. So that was kind of the the initial seminal work again recognizing that a lot of background work had been done over many years on each of these individual waveforms. Now I'm not going to review the evidence in detail because that would be both excruciating and very long, but I'll highlight a few studies here in a couple different populations to try to give you a sense of where we're at right now in terms of the evidence base for this. So, obviously a cardiac surgery population has been studied the work of Dr. Dino and others other than that the bulk of the literature really is in heart failure populations this is where we see a lot of this work especially a lot of the background work looking at these waveforms individually. This was a really interesting quite recent study that looked at patients admitted with acute decompensated heart failure. They had a vexus score done on admission and they look to see which components of this in particular correlated with adverse outcomes and they were actually looking at death during hospitalization so a pretty significant outcome. And they found that a very abnormal intra renal venous flow IRVF so a monophasic IRVF is your most abnormal waveform was quite significantly correlated with the death during hospitalization a pretty impressive area under the curve there. Now again this is this is all correlation not causation, but some interesting food for thought. The next population here is Asia so acute coronary syndrome. This is a group where there hasn't been a lot of work yet but we're starting to see a few papers. So again, they took people coming in with acute coronary syndrome, they had a vexus score done on admission, and they look to see whether this correlated with the development of acute kidney injury during their stay. And again, they did find an association here. One thing that's interesting is that in the previous groups and generally in the heart failure population we see that it's the people with really severe congestion of vexus of three where you see that correlation. Whereas in an ACS population we actually see the association with anything more than a vexus of one so that's really any mildly abnormal waveform. And there's a few possible reasons for this. My theory is that you know in your heart failure population as we'll talk about a bit later. There's a lot of patients with really chronic pathology who probably never live at a normal vexus score right they probably always have a degree of congestion, given their chronic pathology. Whereas in an ACS population you know we do see more people come in potentially who are younger with less chronicity. And really the development of their AKI is going to be secondary to that very acute change in their myocardial contractility. So this may be why we're seeing some of an association at a lower vexus grade in this population. Finally the last paper to tell you about is this paper that was done in a general ICU population so there's been a few studies recently looking at the general critically ill population. This was the AKI vex study. It's probably the closest thing we have to sort of a randomized interventional trial in this field. So what they did is they took all commerce to an ICU. Everybody had a vexus score at admission. And then anyone who had a vexus of more than one had diuretics suggested to them. And then as an outcome they separated their groups into those whose vexus score improved during their admission versus those in whom it did not. And basically what they found is the people who improved their vexus score from that initial scan had more had better renal outcomes so more days free of renal replacement therapy than those who did not. And this you know again this is correlation this is not causation and in some ways this is perhaps unsurprising by saying okay the people who had such severe disease that we couldn't improve their congestion did worse in terms of their renal outcomes. The other thing that's interesting to point out about this population is that there's actually been some other studies that have not shown in association between vexus evidence of congestion and AKI. My theory into that is that you know in contrast to maybe hard failure or ACS populations where congestion and hemodynamics are such a big driver of their AKI. In a generalized view population you have so many other potential factors right people may have, you know they may be in hemorrhagic shock they may have ATM they may have sepsis induced micro vascular dysfunction, toxin mediate interferopathy a whole host of things. So I wonder if that's why in some of the papers that we've seen we haven't really seen as much of a correlation in those patients. So as a summary to all of that this table is not really meant to be read this table for those who are interested is from a recent very comprehensive review that basically looked at all of the evidence behind each of the individual waveforms and the vexus score. And you can sort of see which populations these were in and what was shown. But to summarize the evidence still the bulk of this, you know dating back is still for individual waveforms, although we're seeing more and more evidence for kind of this combination. Most of this is still in heart failure populations, although as I've tried to highlight we are starting to see evidence in different patient populations. And most of this is related to renal outcomes. Although we are starting to see things again things like mortality things like delirium in one when one population. So we're seeing other outcomes but most consistently, it's renal outcomes that have been looked at with this. And then probably lastly the biggest thing to highlight is as of yet we still don't have any prospective randomized controlled study of this to guide treatment so we have no study yet that says, if we take people coming in and they get a vexus compared to those who don't compare to those who just get usual care. They do better they have better renal outcomes they have better mortality better length of stay what have you that does not exist yet. Alright so finishing off with what do we still what do we still not know in this in this population in this field. So in terms of technique. Again I haven't gone into too many of the details of techniques. This is an advanced technique. You know it can be taught and we got residents on our ultrasound rotation and by the end of a month. Most of them can can reasonably get sort of a portal vein in particular, but it is a tricky technique. A lot of the evidence and things that we the papers we've talked about today are performed by a small number of expert scanners and doing all of the scanning. So it's kind of yet to be seen how this would perform in a more sort of widespread population with more widespread adoption. The availability of Doppler ultrasound especially in handheld is still varying although I think that's increasing. In terms of the evidence so many populations are still unstudied as I mentioned most of this is still in heart failure although we are starting to branch out. There's also some populations that have been almost systematically excluded from a lot of studies so especially things like cirrhosis pulmonary hypertension sometimes valve disease sometimes evidence of increased intribdominal pressure. There's a few populations where we really don't have a lot of evidence for this technique yet. And finally the biggest thing as I've just pointed out is that, again, we don't yet have any good interventional data to say that this technique results in a difference compared to the standard of care. And now this is this is an opinion and this is my opinion and clearly I'm biased because I'm here talking about vexus. But I don't think this is a reason not to use this because I think it's worth thinking about what the alternative is right. The alternative for detecting this kind of right sided venous congestion is not great. We can look at the JVP, we can look at the IVC, we can squeeze the legs for pulmonary edema. We can look at labs for congestive hepatopathy or congestive nephropathy. But it's not great we don't have a lot of other great tools to find this and so I think, you know, as this evidence base grows will will see more that perhaps will lend more comfort to using this but to me, this is a reason to not yet adopt this. Okay, and finally the clinical integration and translation to practice what are the unknowns here. So, as we talked about at the beginning you know I think the we are we are increasingly recognizing the importance of venous congestion of this fluid tolerance concept. I think that that is becoming increasingly accepted but but that is still growing. The evidence base is still an evolution there will there will always be those who don't want to jump in and adopt a new technique until there is more evidence there is sort of interventional studies. I've already I've already said my piece about my bias but I think this can be a reasonable addition at our present state of evidence. So what do you do with this information in practice so there is this very natural vexus for osmide reflex it's been dubbed so this natural tendency to want to diaries everybody who has an abnormal vexus or, you know, waveform suggestive of congestion. And for one, you know diuretics are not always the answer. So depending on the cause of their venous congestion of their elevated central venous pressures, sometimes things like, you know, treatment of pulmonary hypertension inhaled vasodilators treatment of PE, titration of ventilator settings, those other things may be the answer rather than diuretics so it is always patient specific. And then the other the bigger question I run into this all the time in my daily practice is how to manage these people with chronic pathology. So the patients with chronic heart failure left sided failure, right sided failure and pulmonary hypertension especially valve disease. These patients are really challenging because many of them will not necessarily live at a vexus zero right at their at their dry weight, their their chronic disease is such that they always live at a degree of congestion. And so the goal for these patients can't be to diaries them to, you know, a normal portal vein. And when we're seeing these patients, you know, once or twice, it can be really hard to determine where in their personal sort of disease spectrum they lie. And that's always a puzzle and, you know, I think that integrating with the rest of your data and examining these patients serially can help but those patients are really a challenge still. All right, so what's the bottom line here. Again, clearly I'm biased because I'm here giving you this talk, but I think that this technique can be a really valuable addition and kind of lends more specificity to this search for venous congestion because again we don't have a lot of great tools, even with ultrasound. So this can be a really valuable piece. You know, and I mentioned these waveforms can be challenging. This can be a difficult technique for me increasingly in my practice, I use the portal vein alone often when the hepatic is difficult to interpret and the renails are hard to get. So even some of this technique can be a useful addition to your practice. The evidence base as I mentioned is still growing in an in evolution and I expect we'll see a lot more in the coming years. And then finally, like all things with ultrasound and like all things with medicine right this is not the single answer in terms of how to manage patients. The last thing you want to do is is to do a vexa score or get a portal vein profile and use that to guide all your decisions to the to the ignorance of everything else right that is not the goal, especially in your complex chronic patients. Really you have to incorporate this into everything else that's going on their, their history their physical exam their labs the rest of their hemodynamic data to help you make decisions. All right, that's all I have for today. Thank you so much for having me and I think we have some time for questions at the end. Thank you again. Thanks very much, Dr. Whisker. I'm looking forward to hearing the q amp a regarding back sisters people get used to this new idea and modality of assessing volume status was something that we all struggle with, especially in the ICU population.


All right, hi everyone. Thank you so much for having me. And today, I'm here to talk about how to build internal R packages to help analyze open data and bring in more aspects of the open source community to internal teamwork. But before we talk about packages, first, I wanted to ask you to think back to the last time that you joined a new team. There was probably so much you needed to learn before you could start contributing. From the frustration of trying to access data, to lost hours, answering the wrong questions until you built up that sort of intuition, and the awkwardness of figuring out team norms. When we joined a new organization, we fortunately only have to go down this learning curve one time. But the off the shelf tools we use don't preserve this context. So every single day is like their first day at work. Now, unlike open source packages, internal packages can embrace institutional knowledge more like a colleague in two really important ways. First, they can target a far more domain-specific and concrete set of problems than open source packages. Second, although narrower in the problem definition themselves, their insight into our organizations allow them to be more holistic in their solutions by incorporating more steps of the necessary workflow to answer that problem, covering areas all the way from pulling data to communicating with our coworkers. Because of these two factors, internal packages can add a lot of value by doing things like interfacing with internal utilities, streamlining our analytical processes, and empowering data scientists and analysts to create high quality outputs. But more than the tasks that a package can do, today I want to focus on how to design such internal packages to be as rich in this institutional context as possible. To do this, I like to think about the popular jobs to be done framework for product development. This asserts that we hire a product to do a job that helps us make progress towards the goal. And to me, it's that notion of progress and truly known the ins and outs of what sorts of progress our users want to make because they're ourselves or our colleagues that really sets internal packages apart. Additionally, these jobs can have functional, social, and emotional aspects. Through the rest of this discussion, I'll tweak this framework just slightly. Let's think about building a team of packages to do jobs that help our organization answer impactful questions with efficient workflows. So what sort of teammates should our packages be? Let's meet a few. First, let me introduce you to the IT guy. Think of a helpful or friendly IT colleague that you may know. They're fantastic at handling the quirks of infrastructure and abstracting away the sorts of things that data analysts don't want to or aren't particularly educated at thinking about like maintaining secure servers. In that abstraction process, they also take on a lot of additional responsibilities to remote good practices, like credential management. Ideally, they help us save time and frustration by navigating organization-specific grid blocks that no amount of searching on Stack Overflow will resolve. So how can we encode these characteristics into an R package? Providing utility functions in a package can help achieve the same abstraction. And in these, we can take an opinionated stance and craft helpful error messages. Let's look at an example. Suppose we wanted to write a function to connect ourselves to a database. We might first start out with rather boilerplate piece of code using the DBI package. We take the username and password, hard code the connection information and return a connection object. Now, let's suppose that our organization has strict rules against putting secure credentials in plain text, as well they probably should. In an open source package, I wouldn't want to presume to force users' hands in how they're doing credential management. However, in this case, I can make strong assumptions based on my knowledge of my organization's rules and norms, and this sort of function can actually incentivize users to do the right thing, like in this case, storing their credentials in environment variables, because that's literally the only way they can get the function to work. Of course, opinionated design is only helpful if we provided a descriptive error message when the user does not have their credentials set this way. Otherwise, they'll get some cryptic warning that DB Pass is missing, and find nothing online when they Google that, because that's a package-specific concept. So we can enhance this function with a custom and prescriptive error message explaining what went wrong and either how to fix it or where they can get more information. Even better than explaining errors is preventing them from occurring at all. We might also know that at our specific organization, non-alternumeric characters are required in passwords, but DB Connect doesn't encode these correctly when passing them to the database. Instead of tripling our users and asking them to change their passwords, we can instead proactively but silently re-encode that information. However, strong opinions in this level of independence don't always make the best teammates. Other times, we might want someone more like a junior analyst or a trainee. They know a good bit about our organization and we can trust them to execute calculations correctly and make reasonable assumptions. At the same time, we want them to be responsive to feedback and willing to test out multiple solutions. So how could we incorporate these jobs in an internal package? We can build in proactive and yet responsive functions with default arguments, reserved keywords, and the ellipsis. To illustrate, imagine a basic visualization function that wraps a ggplot2 code, but allows users to input their preferred x, y and grouping variables to draw cohort curves. This function is fine, but we can probably draw on institutional knowledge to make our junior analyst a little bit more proactive. If we relied on the same opinionated design as the IT guy, we might consider hard coding some of these variables inside of our function. Here though, that isn't a great approach. We might know what the desired x-axis will be 80% of the time, but hard coding is too inflexible, even for internal use. It decreases the usefulness of the whole package for the other 20% of possible applications. Instead, we can put our best guess 80% right name is the default argument in the function header ordered by the decrease in likelihood of the need to overwrite. Then when we do not provide a unique value, the default is used. That was the junior analyst's best guess, but users retain complete control to change it as they see fit. This approach becomes even more powerful if we can identify a small set of incredibly commonly occurring assumed variable names or other values. Then we can define and document the set of reserved keywords that span all of our internal packages. If these are well-known and well-documented, users will get into the habit of shaping their data so it plays nicely with the package ecosystem and saves manual typing. This also incentivizes a level of standardization in naming. They can have other convenient consequences in making data extracts more transparent and more shareable. Finally, one other nice trick in making our functions responsive to feedback is the ellipsis or passing the dots. This allows users to provide any number of additional arbitrary arguments beyond what was specified by the developer and plug them in at a designated place in the function body. This way, users can extend functions based on needs that the developer never could have anticipated like customizing color, size, and line type. So far, we've focused mostly on the first dimension we talked about of internal packages, making our package teammates targeted solving specific internal problems. But there's just as much value in that second dimension. Using internal packages is a way to shift not just calculations, but complete workflows and to share our understanding of how the broader organization operates. To illustrate this, consider our intrepid tech lead or principal investigator. We value this type of teammate because they can draw from a breadth of rich past experience and institutional knowledge to help us weigh trade-offs, learn from collected wisdom, and inspire us to do our best work. So that's a pretty tall order for a package, but conscientious use of vignettes and templates can help us towards this goal. Vignettes in our packages often help introduce the basic functionality with a toy example, as you can see in the deflier vignette. Or alternatively, they may discuss a statistical method that's implemented as done in the survival package. Now vignettes of internal R packages can do more diverse and numerous jobs. These vignettes can accumulate the hard one experience and domain knowledge like an experience tech leads memory and use them to coach anyone currently working on a related analysis. Just as a few examples, you can consider having a completely code-free vignettes that conceptually introduce a common problem your package solves, explain the workflow and key questions you as an analyst should be asking yourself as you go through the data, and even potentially get into some of the procedural weeds, like what you need to do to add a feature or deploy your resulting model. Then after aligning with your users on that conceptual framework, you may introduce the package's functionality and explain how these two overlap. When your package contains functions for many different ways to do a task, you can also compare pros and cons and explain different situations where different options would have proven more effective. Vignettes can also include lessons learned, reflections from past users, and links to references to past examples to help analysts learn about similar projects. In fact, all of that context may be so helpful, even colleagues who are not direct users of your package may seek out its mentorship. In this case, you can use the package down package to automatically create a package website to share these vignettes with anyone who needs to learn about a specific problem space. With a single function call, your package can share its wisdom much more broadly. And unlike their human counterparts, package teammates can always find time on their calendar for another meeting. Now, similar to vignettes, embedded templates take on a more important and distinctive role for internal packages. In open source packages, our markdown templates provide pre-populated file instead of the default. And this is commonly used to demonstrate proper formatting syntax. For example, the Flux dashboard package uses templates to show users how to set up a YAML metadata and the different section headers. Internal packages can use templates to coach users through workflows because they understand the problems users are facing and that progress they hope can achieve. Templates can measure users and structure their work in two different ways. Process walkthroughs can serve as interactive notebooks that coach users through common analyses. As an example, if a type of analysis requires manual data cleaning and curation, a template notebook could guide users to ask their questions of their data and generate common views and summaries that they really need to interrogate. We can also include full and tend analysis outlines, which include placeholder text, commentary and code if the type of analysis that a package supports usually results in a specific report or outcome. Similar to markdown templates, our packages can also include project templates. These templates can provide a boilerplate director's structure and a set of files for each new project to give users the helping hand and drive the kind of consistency across projects that any tech lead would dream of when doing a code review. Now, speaking of that collaboration piece, brings us to the last teammate whose traits we want our packages to vote, the project manager. One of the biggest differences between task doing versus problem solving packages is understanding that whole workflow and helping coordinate projects across many different components. When writing open source packages, we rightly tend to assume that our intended users are in fact, our programmers, but on a true cross-functional team, not everyone will be, so we can intentionally modularize the workflow and think about how to augment our studio's IDE to make sure our tools work well with all of our colleagues. One way to do this is with modularizing the parts of our workflow that do not really require our code. For example, in those templates we just discussed, we could actually make separate templates for components that do and do not require programming. Files that only need plain text commentary could be in vanilla markdown files that a collaborator could edit and any sort of word processor. And the main our markdown file can incorporate these documents using child documents. This approach is made even easier with advances in the RStudio IDE. For one, the Visual Markdown Editor provides a great graphical user interface to support word processing in Markdown. And we can also use the feature of RStudio Add-ins to extend the interface and ship interactive widgets inside of our package. As an example, I here show the Esquiz package, which is a point-and-click plot coding assistant. Add-ins require more investment upfront, but they're much easier to maintain than complete web apps and can help convert our teammates to our users over time. Besides, a good project manager is willing to go that extra mile to support their team. Now, speaking of collaboration, we've talked a lot about what makes an individual package a good team member. Another major opportunity when building a suite of internal tools is that we have a unique opportunity to think about how multiple packages on our team can best work together. We will always want teammates that are clear communicators, have defined responsibilities, and keep their promises. We can help our packages be good teammates with naming conventions, clearly defining scopes, and attention to dependencies and testing. Clear function naming conventions and consistent method signatures help packages effectively communicate with both package and human collaborators. Internally, we can give our suite of packages consistent names that indicate how each function is used. One approach I really like is that each function prefix can denote the type of object that it will eventually return, like viz functions always returning a ggplot2 object. This way, past experience working with any one of our internal packages gives users intuition when working with any other one of them. Another aspect of good team communication is having clearly defined roles and responsibilities. Since we own our whole internal stack, we have more freedom in choosing how to define functionality between packages. Take, for example, the data science workflow as described in the ARF for data science book. Open source packages inevitably have overlapping functionality which forces users to compare alternatives and decide which one is best, which can be timely. But internally, we can use some amount of centralized planning to ensure that each package teammate has very clearly defined role, whether that be to provide a horizontal utility or to enable progress on a specific work stream. When assigning these roles and responsibilities to our team of packages, we can consider how to manage the dependencies between them when different functionality needs to be shared. Packages often have direct dependencies where a function in one package calls function in another package. This isn't bad, but especially with internal packages, which might sometimes have a short shelf life and few developers, this can potentially create a domino effect of failure. If one package is deprecated or decides to graduate, retire, or take a vacation, we don't want the rest of our ecosystem to fail. Alternatively, since we control both packages A and B and are under our control, we can see if we can eliminate explicit dependencies by promoting a clean handle. We might make a co-function in A, produce an output that B can consume instead of calling A directly. Or we can find shared needs in packages A and B and extract them into some building block package C, which might contain something like visualization primitive functions. This way, we can at least have a clear hierarchy of dependencies and can identify a small number of truly critical pieces of infrastructure that can't fail. Regardless of the types of dependencies we end up with, we can use tests to make sure that our packages are reliable teammates who always do what they promised. Typically, if I write a package B that depends on package A, I can only control package B's tests. So I can write tests to see if A continues to produce the results that B is expecting. This is a good safeguard, but it means I'll only detect a problem after it's already been introduced today. Instead, with internal packages, we'd prefer both A and B be conscientious of the promises they've made and stay committed to their collaboration. We can formalize the shared vision with integration tests. That is, we can add tests to both the upstream and the downstream packages to ensure that they continue to check in with each other and inquire if any changes that they're considering making could disrupt the other. Now, just imagine having that rigorous and ongoing communication and prioritization with your actual teammates. In summary, we all know the joy of working with a great team. And I suspect many of the people here today know the pleasure of cracking open a new open source tool. By taking advantage of the unique opportunities of designing internal packages, we can truly achieve the best of both worlds. We can share the fun of working with good tools with the teammates we care about, and we can elevate those same tools to be full-fledged teammates by giving them the skills they need to succeed. Thank you.


Hi, here I'm going to explain how to and why to use Overleaf and Latech for your scientific paper either to contribute to somebody else's paper or to create your own paper. So to get started we would go to Overleaf.com and create an account or log in and you'll find yourself a screen that looks something like this. Or else if somebody sent you an email with a link to access their paper just click on it. Once you click on a paper you'll see a screen which looks something like this. To create your own paper from scratch generally I would suggest going to Google and typing in Overleaf and Template and the kind of thing you're creating such as a preprint. And generally that'll give you an access to their gallery where you can click on the kind of paper you want to create and say Open as Template. So in either case you're going to end up in a screen that looks like this. So this is a different way to creating papers to using something like Microsoft Word which we might be more familiar with. And at first it honestly looks a bit terrifying.  And the trick is basically to ignore all that code, this latex code. Instead just find the bit where it says Begin Document and start typing. So here's a section where it says Begin Abstract and I can start typing in my abstract. And then you can create sections so these are just chapters. And you can start typing in your sections. And then at any point you can see what that's going to look like by clicking on this little arrow and saying Recompile. And what that does is it creates a PDF. And so as you can see it's created a nicely formatted paper for us. Now basically you don't have to do any formatting really yourself in terms of document formatting. You just type in this is the abstract. These are the sections and so forth. And it will automatically format it for you, create your references for you and so forth. So this is one of the big benefits of using latex and Overleaf for doing this is that there's just a lot less time and hassle for you. There's a lot less to think about. You can just focus on typing your paper. There's two ways you can type your paper. One is by typing into this source view which is a bit more scary looking. Or you can type into the rich text view which is a bit less scary looking. Generally speaking pretty much everybody I know spends 99% of their time in the source view. In the end they're both places you just type what you want to type. And yeah I would suggest not looking really at what it looks like too often. Just focus on putting your information, your text, your paper in here. And then yeah just from time to time you can always scooch over and look at the compiled PDF. The only place I tend to sometimes use rich text is if I want to insert one of these things. Bold, italics, a numbered list or a bullet point list. For example as I've done here. Let's create our own one. So here is a bullet list. And then you just hit this first, second. Okay and so that's what it looks like in our rich text view. If you go to the source view you can see it's used some latech code. So another way of creating things like bullet lists is just to copy and paste something that's already there. So if we go and have a look at the compiled latech here you can see a bullet list has appeared. Okay so the main thing you need to know is just type stuff and it will appear. The second thing then to know is how to do citations. So one of the really nice things about doing citations with latech and Overleaf is that you don't have to worry about citation styles or anything like that or keeping your numbers up to date or all of that kind of stuff. That is all done automatically for you. So there are two ways to create a citation. Basically everything in latech which is a command starts with a backslash. And to create a backslash you type backslash site. And then there's two ways you can cite. Either cite inside the text of a paragraph that will be site T. Or in parentheses at the end of a sentence that will be site P. And in either case you then type open curly brace and you'll have a big long list of your citations here. So for example if I click on this one and then if I have a look at my document here this citation has appeared. And you'll see it's appeared here and then if I scroll to the end you'll also see it has appeared here. So where did all those list of possible things to cite come from? They come from a separate file. There's basically two files you care about. The .tech file here is the thing you type into. And then the .bib file here is the thing that contains all your citations. And here they all are. So you can see there's one per line. So here's one citation. Here's one citation. These are in a format called .bib.tech. If somebody has already created your bibliography for you you won't have to worry about creating this. All you need to know is that in general each citation has a name like this. Our one 2020 doctors. Generally speaking if you use the approach I'll describe in a moment. The names of your citations will be the first author's surname. Then the year of the reference. And then the first word of its title. So this is quite handy right? So for example we wanted to cite this thing here. Post-acute COVID-19 syndrome from now Bandion 2021. Then we would just start typing site. And then we'd start typing now Bandion. And here it is 2021 post. And so if we have a look at what that's put into our document. There it is it's added to our reference list. And you can see here it is in the document itself now Bandion. And it creates hyperlinks and all that kind of stuff for you in the PDF. So if you click here it jumps straight to the reference and so forth. So that's all pretty handy. So why would you use site P versus site T? Well the reason why is that here's an example of site T. Site T is something that you would use in the body of your text. So for example half a vowel at our 2021 estimated the full impact etc. So that's site T because it's in the text. And so the format it creates is to show the name and then the year. And then so you could put this straight in the text like this. As opposed to site P which puts it in parentheses. That would go at the end of a sentence like this. Continue the vaccination rollout to 90% throughout the year. Brackets and there's a citation. And notice you can put more than one reference with a comma between. You can put as many as you like. So that's why you see each one here. And again I could click on it and it would jump straight to that reference. Okay so here's actually if you look here I've got the two citation styles in a list. So we can take a look at what they look like. So here are the two citation styles. That's the site T style and that's the site P style. And things like exactly what kind of parentheses or brackets are used and stuff like that will depend on what template you've selected. And that's very easy to change later. So you can just replace the template at any time and your whole document will be updated for that template. So if you change which journal you're submitting to you just stick it into a new template and away you go. Okay so finally how do you add stuff to the bibliography that's not already there. Just add stuff to the bibliography that's not already there. My strong suggestion is to use Google Scholar. So Google Scholar is at scholar.google.com. The first thing you should do is click on these little lines and click settings. And turn on the thing that says show links to import citations into bibtech. Okay and so now that we've done that we can search for a paper. So let's say I want a paper about clams. So I would go like so and say ah yes giant clams that's the paper I want. So if I want to add this to my bibliography I just click import into bibtech. I'm not a robot. And then select that copy and we go back to bibliography and paste it at the end like so. And as you can see it's used that approach I described surname year first word of the title. So if I now want to insert that into my text I could say for example site in the text. What's his name? Yong wrote about giant clams. There we go. And so if you want to see what that's going to look like recompile and here it is. Yong wrote about giant clams and I can click it. And I can see yep here it is in my reference section. Okay so that's basically it. Then finally if you want to download the compiled version of your paper you can go menu download PDF. Or to submit it as latech you can download source and then you could submit it from there. Oh and then I guess the other useful thing to show you is how to work collaboratively. So you can click the share button to share the paper with your collaborators. And you can all edit it at the same time. You'll see each other's edits. And then to add comments or to track changes just click review. And I'll say track changes is on for everybody. And so now if I start typing it focuses on the great barrier reef. And you'll see here it shows that I added it focuses on the great barrier reef. And so other people will see Jeremy Howard added this. And so then anybody can click accept or reject. And then the other thing I could do is I could double click on a word for example and say add comment. What about oysters. And then other people could reply to that and so forth. Okay. So then I can go resolve. Go reject and turn off change tracking. And so this review button just shows the review appears and disappears. And if you click overview it will show you all of the changes and you can go through and check all of them out. Great. I think that's about everything I wanted to show. So hopefully this helps you get started with using latex and an overleaf. And you find this a good way to write papers. Personally I found it really saved me a lot of time. So hopefully it helps you too.


We do, in fact, for the date and month of birth. We got August 21st, which we confirmed with Dr. Taylor. When it comes to the answer of time of dating, three years, pre-disappearance, four if you count the ten months missing. Certainly. I've been a good friend with Dr. Taylor for seven years and that does check well. And we also confirmed the pet name of Bear Bear with Dr. Taylor. And glasses on return. They get quite flustered if they hear anyone else around them when they call each other. She did indeed. Rather cute. Alright, well, in this case, I do believe it is David who we do have in containment. If we can't get those scans done just to make sure there's nothing wrong with them, then we should be able to get them out of containment. Every step forward is a step forward, right? Certainly. If you would like to help with those scans, I believe Agent G.O. has taken the measures to perform them soon. If not, though, I'm sure there are other various members of this side that might need help with various tasks. Appreciate your help. You've been invaluable. Secure Contain Protect. Secure Contain Protect. We'll check in with G.O. after we disprove the 049's lunacy. The virus? Who is this man taking us? No. From David. The explorer. He is unwell. No. No. David is a valiant hero. He's an explorer. He assisted me with my research. He is sick. They seemingly have the scan of David already. 049 is claiming he has the pestilence. 049. I've come to disprove your lunacy. Have you? Thank you. Who is this object for? This is from Dr. Elizabeth Taylor. Indeed. Elizabeth Taylor, you say? No. Magnificent. Elizabeth Taylor is not sick. Take this object back. There is no disproval to be made. You have only brought me an object from one researcher. She is not sick. Perhaps if you bring me something from Danny Taylor with Joseph Williams, there will be a different love. Hmm. We shall see. The pestilence is here. And many are infected. We must identify who. And perhaps together, we can administer the cure to them. Hello, Steve. Hello, Wesley. Hi. Do you want any candy? Candy. I have no interest in candy myself. I'll get you some candy. Dr. Sherman, would you like some candy? I am fine without candy, thank you. Would you like... Whatever you wish, Wesley. That's good for you. Have you met my old friend? Oh, Sherman's really nice to me, yeah. Indeed. Do you know him? Yes, many years ago. I was working at a site. He was also a researcher. We collaborated many times on research projects. Did you care anyone about that site? Indeed, I did. He, in fact, cured my best friend. Dr. Raymond Hamm, yes, what's your name? I'm so sorry. If the plague doctor cured my best friend, I don't know what I'd do with myself. You would be overjoyed, Wesley. No. Or if your best friend were to be served, it would be a terrible challenge. Joseph, he's your best friend. Yes, he's my best friend. And I have terrible news for you, Wesley. This is very sad. If you'll be cured in time. I'm going to go tell Joe. Stay away from him. You'll not touch him, okay? That is the wisest thing I've heard all evening. Thank you. Chat, Joseph is not sick. The plague doctor is insane. Let's go return this pen. Agent Gio. Yes, what can I do for you? Do you have any intelligence on 049 claims that members of this site are infected with his so-called pestilence? I'm very aware that he claims such a thing. I have been made aware that I am one of these people. Is that so? Yes. I have been personally in attendance for some of his previous cures and am not entirely looking forward to the prospect myself. Nor should you. You could... There's no way to... Dissuade him. Dissuade him, but there's any way to throw the scent off of me. I would deeply appreciate it. I'm in enough of it with playing out to this. Do you know of any other members of staff who's claiming this so-called pestilence as a part of? I definitely heard Danielle Taylor and Joe Joseph from RISC. Did you hear anyone else? Not really. Elizabeth Taylor is so-called clean in his eyes, although I don't trust a word that Birdbeak says. Nor should you. Good instincts. He's too old. Old people are weird. I take some offense to that, but I'll carry on. I'm not part of the old people, Ed. But yes, these are what I have been made aware of today. Highly concerning what was all the use of fruits and what not, but this is the day he decides to start a new rage against the pestilence. Long story short, don't believe on-doors lies. If you have any additional information or any plans or suspicious happenings for this video, please let ourselves complain no immediately. We've had issues over the past, and we're not eager to repeat it like this. Indeed. The critical hazard assessment team here has taken a particular interest in the custodian, Wesley. Yes, Wesley Brown. I don't have friends here, but if I did, Wesley would be one of them. I don't have a work in mind anymore. Oh, certainly. He's so clean. Let me know if he says anything suspicious. Yes? The chat would just like to infer as to Wesley's future promotion- Promotionorial? Promotionorial efforts. Well, I'm very pleased to say that the motion application did make it to my desk, and I- it doesn't work. Typical. As for the site head, I think that very budget cuts. It did make its way to my desk, and I did sign off on it. I sent Chris to give it to the site head, and if he signs off, then we are officially in business. I am very pleased to say that I think Wesley has a very bright future with him. Fantastic to hear. I'm sure the critical hazard assessment team will be very pleased. Certainly. Don't go spreading it around to me. I thought so. Off the record. Bitch. You're welcome, chat. Alright, so we don't trust 049 as far as we can throw them. We've confirmed that David Smith is David Smith. The mask had nothing but laughs. Should we check in on Baba Yaga? Should we check in on the researcher under the table? Finish the quest line, finish the quest line. I see what you said. It'll be admin followed by Baba Yaga. Don't mind me, just continue.  Yeah, this is how Gio knows. Oh. Yeah, that one that was already in my mind. Jeez. Stand might have battery. Stand might have battery. Uh, right on the other side.  Good evening. How are you doing? I'm doing well. How about yourself, Doctor? I'm doing quite well. This inspection is going swimmingly so far. Except for the fact that 049 is here, which I was not informed of. Oh. Yes, I am aware that you two have a history. I am not a fan of him myself, nor is Dr. Taylor. Or anyone of sane mind. Exactly. I'm only here due to the critical hazard assessment team here. They have a vested interest in the promotional efforts of one custodian, Wesley. Wesley, yes. Well, Wesley is a very nice girl. I am surprised to hear that she's interested in being part of our security team. Apparently her combat marks via mop or broom are off the charts. I have never experienced them myself. I hope I don't have to. Hallelu. Well, yes. I think if she were to shadow Agent Gio for a couple of weeks, and if she shows promise, then I'm absolutely happy with promoting her. That's good to know. A couple weeks. A couple weeks, right. What else can I help you with? I feel like that's... Well, I mean... Is that really all you're here for? No, no, no. The small talk aside, I'm very worried about that man who came in in a couple of weeks. I'm very worried about that man who came in in a hazard moments ago. Agent Smith. Yes. I am concerned about him as well. He has been missing for 10 months, presumed dead, in a dangerous dimension known as the other world. We don't know too much about it, so we have to kind of check off all of our boxes, make sure he doesn't have any pathogens, make sure he's not a shapeshifter who's trying to kill us all, make sure he's mentally and physically still okay. He's probably going to have to be contained for at least a week. I can attest at the very least that he answered personal questions to a satisfactory level of those that only he himself would know. That is promising. That is promising. I'm worried about the light situation. If we can't see him, what might there be on him? Chris, we are unable to scan for pathogens at the moment, so we should be extremely careful around him. I'm going to take a moment to help you. Go right ahead. Sorry to interrupt. Please. Sir, can I have your attention for a moment? It was my bad. You remembered! Yes! I do my best. Yes, that's so right. I have some important questions for you. All right. Okay, so, what over here if you will, sir? A lot. Thank you for listening.  Please become a patron or visit our merch store at the link in our bio to support our work. Secure. Contain. Protect.