Hello, so hi, I'm Steve Siegel. I'm here with Matt Farnero. We're from the embedded systems team at Cruise. For those of you who don't know, Cruise is an autonomous vehicle developer. We're going to talk a little bit today about how we use Linux in what is really a large distributed computing system. Quick side note, when the slides are imported into their system, there might have been a few spacing issues and visual artifacts, so please bear with us. First, I'm going to talk about us. I'm going to talk about the vehicle. I'm going to talk about the challenges that we faced, the challenges that we face as building and getting Linux onto a device such as this. I'm going to talk a little bit about, or Matt's going to talk a little bit about BuildRoot. We'll talk a little bit about how we boot, and then we'll do a little bit of talking about device management. So first, about Cruise. So Cruise, we are a majority-owned subsidiary of General Motors. We're also backed by Honda and some other investors like SoftBank and T-Roll Price. We are based in San Francisco. We also test our vehicles on the streets of San Francisco. You can see this is a picture of one of our vehicles in San Francisco's Mission District. Our goal is to design and operate autonomous vehicles in a ridesharing service. And this is what we're ultimately building. So this is the Cruise Origin. It's an all-new, totally electric vehicle. It's designed to ground up for autonomous ridesharing, designed for long life, modular components so that we don't have to replace the entire vehicle as technology improves or if we want to change out sensors or something. And this is basically intended to deliver autonomous ridesharing at scale. So embedded systems. So we're the lowest level of software in the autonomous driving system. So we provide the interface from the rest of the stack, from the stack to the rest of the vehicle. This includes, we bring up all our custom hardware. We provide Linux OS images. We develop the application software for the edge devices. Or more succinctly, we figure out how to get a supercomputer into a car, which is, I mean, that's a gross oversimplification because we also have a really, really great hardware team and lots of really great people who work on the non-software aspects of this. But when I first started to cruise, I needed a way to explain to my mother what I did for a living. And this is what I came up with. So the vehicle, right? This is our current, our third generation vehicle. It's originally based on the Chevy Bolt. But we made a lot of changes to it. This kind of shows all the changes that we made to the Bolt to enable the autonomous driving case. Much of this hardware is custom built specifically for our vehicles. So this includes sensors like cameras, lidars, lots of other sensors, the in-car networking infrastructure, telematics, a core compute that runs the actual autonomy stack. And this kind of makes our vehicle a little bit more like a roaming data center than a typical passenger car, right? And many of these components, they don't exist commercially, right? We have to develop and they are developed by our hardware team. So our hardware team, they source these parts in various places. Traditional automotive tier one suppliers, they have a lot of experience of building traditional automotive parts. And in situations where we just need minor variants of these, they can do this very efficiently. But we're basically, like I said before, a data center on wheels, right? And this requires us to design IT parts that had never been put into a car before. And so sometimes we work with non-automotive IT suppliers. We do a lot of our own internal designs. This is because sometimes it's easier to teach an IT supplier how to make automotive parts than it is to teach an automotive supplier to make IT equipment. We also use a lot, there's also a ton of parts in the car that are not related to the autonomy stack. And these are typically sourced by our OEM partners, especially General Motors. But we developed the software for all the autonomy components, all the components related to autonomy. We developed that largely in-house. A lot of these tier one suppliers are used to delivering an entirely functional component. Basically, you hand them a spec and they come back and they deliver to you a functioning board with software and everything. But in our case, we work on the software internally so that we can iterate quickly and ensure consistently see between all the different boards that go into our vehicle. So some challenges. You can imagine, this brings lots of challenges, right? So here's a brief overview. So like I said before, tier one automotive suppliers, they have very little experience with Linux. They're normally used to working with Autostar, other kinds of RTOSs like QNX or FreeRTOS for certain cases. They're not used to developing hardware for a customer-developed operating system, Linux operating system. Basically, a lot of the parts that we use, they don't even provide Linux drivers for support. Typically, in the automotive world, automotive systems on chip are typically designed for part, for infotainment systems. So if we go to a Silicon vendor and we say we want an automotive grade part and we want to put Linux on it, they'll usually push us to their devices that are designed for infotainment. And then a lot of the peripherals we need, they might not, there might only be one for an automotive style bus. There might only be one or two peripheral vendors and they don't provide Linux drivers at all because they're previous customers that have never asked for it. So autonomous vehicles, they represent a globally unsolved problem, right? We need to build devices that nobody has ever conceived of before using automotive qualified parts that don't actually exist. This involves some creativity, right? We often have to use components like systems on chip for different purposes than they were originally intended. And also, because we have so many new things to invent. It's very important for us to reduce our development time and risk to use proven solutions when possible. So our devices, we have everything from large high-performance computers to small constrained devices. We, the components where performance is the primary consideration like the core compute use x86 parts. Most of our other components are ARM based. Many of the ARM systems on chip designed for automotive applications typically have like an additional microcontroller core for functional safety or other real-time operations. And then again, like I said before that the traditional electronic control units that you would find in a typical vehicle are developed by our OEM partners. So ultimately, right? We want to support a large number of diverse devices. We have a huge number of devices that are all could be very different from each other whether we might have a camera and we might have like I said like networking infrastructure for a car or again our core compute like these are all very, very different. And yet they all have to work together. The new devices that we may have to build we don't always know what they're gonna be, right? We don't know, this is again this is a globally unsolved problem which means that we have to be able to iterate quickly and be able to bring up new devices or new components for our vehicle as we determine that we need them. We also need to be able to guarantee reliability and security for our devices. So how do we do this? Well, we need to enforce consistency where we can, right? How do we make all our devices look as similar as possible and make sure that diverges or divergences are deliberate and they're not accidental. How do we want to use existing solutions when we can but we also wanna maximize flexibility because the range of devices that we may be asked to develop in the future is very, very large. So now I'm gonna turn it over to Matt who's gonna talk a little bit about how we use BuildRoot. Hey folks. So the first step in kind of enforcing this consistency and building up this common development environment for us was thinking about what is our build system and we landed on BuildRoot. So we did so for a handful of reasons. So first of all, our goal here is to build a firmware image, not go build our own custom Linux distribution. We were looking for a tool that was relatively simple so that we could easily onboard new developers as our team grows and it has quite a bit. We're also looking for speed, right? So we value being able to do a high performance and kind of rapid loop around clean builds. So building everything from scratch but doing so in a relatively quick and repeatable way. We value also the sustainability of it, right? So being able to go do things like have internal package mirrors and build up kind of a mono repo for our edge components wrapped around our build system. And of course with any build system that we choose we must have extensibility, right? We need to be able to customize it for our use case and enable it to scale as our scope and our team scales. So for us, BuildRoot kind of was the right build system that ticked all of those boxes. So why do we need to extend BuildRoot, right? So for those of you that are familiar with BuildRoot, right, it is a K config based system. So it has a really wonderful support for going and kind of building a def config and quickly regenerating your target. So we need to go a little bit beyond that, right? So we have, if we look across all of the work that we're doing, as Steve identified there are many, many things that are very different but there's a core set that we by design want to be very similar. So to enable this in BuildRoot we've taken a config layering approach, right? Which we'll go into a bit more to basically ensure that the stuff that is constant we define it exactly once and the stuff that is board specific is isolated and captured well. This has some other really nice properties. It's kind of the foundational tenant that allows our developers to rapidly switch between boards, right? So maybe today you're working on that networking component and tomorrow you're working on a camera. We want that developer experience to be very similar between the two. And then we want to be able to go and further extend BuildRoot to support some kind of development best practices, right? So automated test execution as part of our continuous integration environment, both in kind of the traditional unit tests and extending out to integration tests like a hardware in the loop environment. So this is a quick snapshot of our repository itself and what you'll be able to see here is that at the core of it we have kind of a BuildRoot folder which is BuildRoot as a sub module. And then we've built up some additional content that wraps around it to do that configuration layering to support our locally developed applications. So for things that don't warrant a standalone repository of their own to build make files, right? To manage kind of easier to use top level targets, right? Or extended targets both for our end developers as well as our build system. And then some just nice to have features, right? A common place for out of tree kernel modules so that we can write those once and share those across different kernel trees whether they're mainline or the SOC vendor forks that we can't seem to quite get away from. And then a common place for output files, right? So that a developer could have multiple different boards on their local system and they don't conflict with each other. If we dive into the BR2 external folder so BuildRoot has a kind of a built-in piece of functionality called BR2 external which allows you to extend the tool. And so we try to follow this as closely as we possibly can. And this allows us to go define our own boards, our own packages, as well as a few kind of dirty little hacks to get the build system to conform to our use case. We try to isolate those and kind of minimize them as much as possible. But we generally see that as like the lesser of two evils versus doing deeper surgery in BuildRoot and having to maintain that out of tree for things that just don't make sense to upstream. We talked about this earlier but this is the configuration layering approach, right? So we've taken, as I mentioned before, BuildRoot is a K config based system. So every board that you may want to define has a def config. But the K config and the def config, the default configs don't lend themselves well to layering. So we've taken a trick out of the kernel build process, what they do for device trees, we do for our def config files. And we essentially run our kind of partial def configs through the C preprocessor. And that allows us to use some of the nice kind of if def language as well as the include language to go and build a modular system, a layered system. So as I mentioned before, the other major area that we look to extend is testing. So we went and extended our kind of concept of the BuildRoot packages so that we can go and define per target or per package steps that allow us to run tests, right? So this allows just like a package might define a set of build commands or a set of install commands. We can now have a per package set of test commands. So this lets us do some pretty nice things, right? So by enabling this and by defining those test commands for packages, we can then guarantee that if we are building the package for the target, we are also building the tests. And we can automate our CI system or our continuous integration system to ensure that for each board, we are actually executing each of the tests that are defined for any of the packages, right? So any of the configuration options that package has or that board has selected will be reflected in the environment and we get really consistent and automated testing. Today we're using this for unit tests that run on our build machines, but we're looking to further extend this to go run tests on the emulated version of a target and QEMU as well as to tie into our existing hardware in the loop system so that we can further automate that process. And this is just a quick snapshot of our continuous integration pipeline, right? So one of the first things that we did when building up our wrappers around build route was to go and automate the builds, right? So when we're building for dozens of different kind of board and configuration targets, we want to be able to make changes to common areas and actually be able to test them, right? And we certainly don't want a human to have to go through and run two dozen builds. So one of the first things we built was this continuous integration pipeline where for as a pre-merge gate for every change in our repository, we go and compile every board, every configuration. We run all of the defined unit tests and where applicable will actually go and run integration tests in a hardware in the loop system, right? Where we're actually taking that new firmware, downloading it to the target and running tests against that device. So I'll hand it back over to Steve from here. So I'm going to talk a little bit about how we boot and how our boot loaders look like. So one of our goals is to maintain consistency among platforms. So boot loaders are inherently board specific, right? So consistency is definitely a challenge here. Still, there are ways to make this happen. We have lots of very different boards to manage. As Matt said, the same team manages all these boards and we need them to be conceptually similar for to have a consistent developer experience. So first we need to decide like what can we reasonably make common? So a cruise like this could be secure boot, hardware support for this is a hard requirement at cruise. We have redundant OS images, which Matt's going to talk about in a little bit and also like initial flashing procedure. How do we enable these boards to be de-flashed in the factory or at manufacturing time in a similar way? So you boot is kind of the de facto standard boot loader for embedded ARM systems. It's well known and supported. It's extremely configurable, but SOC vendors almost always forth and customize it. Sometimes vendors will continue development on their private forks for years, right? We could go to a vendor and they'll be saying, like, oh, you need a boot loader? We'll just use this modified UBOOT from 2016. This might support all of UBOOT's features. It might support a subset based on the vendor, what the vendor prioritizes and their interests, which is often what most of their customers ask for. But we're often very different from a lot of their previous customers. And so the features we need may not necessarily be what they prioritize. In any case, this makes sharing code between different devices very difficult because they may have radically different UBOOT treats. So yeah, reusing code in UBOOT can be a bit of a challenge, but we want to enforce a few things. We want to keep the files we add to UBOOT to a minimum so that we can easily carry those additional files and patches through vendor version updates. And ideally, if they could apply to multiple forks if necessary, that'd be great. We want consistency. We want, again, we want common standards of all our boards. We want them to all have roughly similar feature sets and operate in similar ways. And yet we also need flexibility, right? Because we want to be able to reuse our code as much as possible, even when we can't even necessarily conceive of the boards that we're gonna have to develop. So we can't require all vendors to work from the same tree, right? But we can enforce requirements, right? As part of procurement. So we can say we have, between image signing, network access on at least one defined interface, these we can basically put as hard requirements in our procurement process to ensure that vendors provide at least this minimum level of support. And for peripherals, some may be required, some may be nice to have. We have some flexibility there, depending on what the part of what it needs to do and what needs to be accessible at boot. But we still have the ability to kind of enforce as part of that process, of a part selection that we get the support we need. So best way to enforce common alien eBoot is just to get as much out of the source code as possible. This means device trees, gets device description into a portable format. This is standard eBoot practice now, although sometimes we still encounter vendors that might be using old eBoot or have never converted their devices to be device tree based. So we can kind of like make this part of our vendor requirements when we go to market. Additionally, a common eBoot script helps get a lot of the business logic out of the eBoot source code, right? Scripts are eBoot best practice. They can be signed for security. So you can store your script in another location. You don't have to store it with your eBoot. You have to store it embedded in your eBoot image and yet you can have eBoot check a signature on it to ensure that it's secure. And you can generate them from a template, right? So that you can have a common and board specific functionality in the same script. So this is a short excerpt of a script. Relative, this kind of shows a situation where we are attempting to net boot is kind of like a emergency recovery mechanism. So what you can see here is basically we just try to net boot three times. If it fails, we move on, right? And it's a fairly simple script, but by putting this into a common place then all our boards immediately have this functionality, and then they can all recover in the same way so that we can depend on this functionality existing in all of our edge devices. And again, for this particular case, we can work with our vendors to ensure that we have the necessary network access in eBoot. So we can ensure that say they provide drivers or provide support for doing this kind of network access on their device. And scripts can't handle everything, right? Sometimes you still have to go in and write C code. But we try to keep this as minimal as possible. UBoot does have normal customization methods for this and we try to stay in those and not patch extraneous parts of UBoot simply because those become very unmaintainable. And especially if they're board specific things that don't really make sense to upstream, then they become a patch you have to carry, which is not something we wanna keep those patches as small as possible. Okay, I'm gonna turn it back over to Matt for device management. Yeah, so building on top of what Steve just presented, right? Now that we have this common bootloader layer, right? With our core expected functionality captured in a script, we want to go build some kind of business features on top of that, right? So if we look at the autonomous vehicle as a whole and specifically the autonomous components of it, we can really visualize it as kind of a large distributed computer system. And so that means that if we want to apply an update, right? If we have a release of our software, we want every node in that system to be in a well-defined state, right? So that means we are actually applying a software update to potentially every node in the system when we update to a release. And so in order to enable kind of our small team to tackle this sort of a problem, right? Once again, consistency is very fundamental, right? So if we can come up with a similar update mechanism that we can share across all of our components, all the components in the system or at least the ones that we develop in-house, we make the update process much simpler and far more reliable. So to do that, we've chosen the SW update tool to kind of manage our system updates and we're able to use some broadly common configurations across the board. So update, and actually there's a really great talk from Jan Kiska that happened this morning that goes into much more detail on a system that is rather profoundly similar to ours. So I encourage folks to go take a look at that. But around this software update tool, we've actually gone and built some outward facing REST APIs, right? So we've kind of said that this is a kind of an easy, least common denominator interface to expose outside of our system. It's something that we can make use of in development and in debugging, and it's a thing that we can secure for production. So we've gone and taken the underlying software update tool and then wrapped it in some REST APIs that we develop to automate things such as querying versions, that first-time flash step that Steve talked about, that kind of provisioning, as well as updates in the field. And given this REST API, we can then go and build easy-to-use client tools for all of our different use cases. So when we look at actually deploying a release to our system, we have kind of a fairly nice one-way graph, right? We can, we have our core compute, right? The brain of our vehicle, which itself runs the same kind of operating system that we've built here that we've described here and can of course update itself via that same tool. It can then act as the orchestrating element for talking to all of our edge components. It can query the version, determine if it matches whatever is in the release manifest. And if it doesn't match, go and apply that update. As Steve identified, we also have built-in through our scripts, this nice fallback mechanism of a TFTP boot. So the core compute can act as that TFTP server of last resort in that case as well, right? So we can have, again, very consistent, both kind of happy path updates as well as failure recovery. And so if we're going and updating all of these components, right, possibly frequently, certainly in development, very frequently, we need this to be extremely reliable. As Steve identified, many of the components in our system might be buried somewhere deep in our vehicle that would take a tremendous amount of effort to go and expose more than an ethernet interface if we make a mistake or if we lose power, or something goes wrong during applying the update. So to solve this, we try to use redundant copies of everything that we possibly can. So this is an example kind of memory or storage layout. And this is illustrative, this is not the actual storage layout on our devices. But essentially we try to have these blue and green copies of almost everything. If we can do it for the bootloader, we do so. That ends up being very SOC vendor specific depending on what sort of capabilities are in their ROM. But where possible, we do this. And then certainly all of the layers beyond the bootloader, we protect with redundant updates. So that means we're having these two images stored on the device. And when we are running on one, we can update the other. And this plays really nicely with secure boot. We can still sign and verify all of these different image stages and maintain our root of trust. And it gives us nice fallback mechanisms where fallbacks could be triggered for a variety of reasons, right? Maybe storage is corrupt. Maybe we released a bug. Maybe there was just a power failure. In all of these cases, we are nicely resilient and we can recover the system and reattempt the update. So with that, I'll hand back to Steve to wrap up. So in summary, ultimately we need to be able to rapidly innovate a completely new hardware, right? And to do that, as we described, we want to use common, well-known flexible tools. We want to define common components and configurations so that we can drive reuse across our system. And yeah, we don't want to reinvent the wheel, right? We have plenty of other parts of the car to reinvent and we really don't want to, we want to minimize our risk by reusing solutions that already work for, that are already effective. So for more information, I included some links to some blog posts where we've talked about some related topics. You can download the slides off of Sked and click on these at your leisure. One of them talks about how we source and design hardware. Vehicle security, I didn't really cover security in this talk because we have a separate team of crews that focuses specifically on vehicle security. And so this is a great overview of how they think about this. And also we wanted to go to the shout out to a talk by Jan Moore and I may be totally mispronouncing his name at ELC Europe in 2017, mainly because it was a large inspiration for how we built our system and we felt we'd be remiss if we didn't mention it. And with that, now we can start looking at some of the questions. Thank you for participating. So I think there's like a nice little cluster of questions around using, sorry, can you folks hear me? Okay, so I think there's a nice cluster of questions around using mainline U-boot. So in some boards, we are able to do so. So when that is feasible, we absolutely want to do that. The patches that we actually need to author for U-boot are usually fairly well-contained to the truly board-specific initialization content, right? So not something that is of tremendous benefit to the broader community, but where possible, we do try to use mainline. We have a handful of vendors that have some more bespoke content in their U-boot tree that have diverged rather heavily from mainline. And so for those cases, we find it to be lower effort for our team to simply use the vendor fork, rather than essentially do the SSE vendor's job of maintaining their patch set on top of mainline. So the nice thing about the script-based solution is that I'd say 95% of the logic that we care about is actually contained in that U-boot script. And that's a thing that is highly portable from board to board. So I think, again, to kind of address the mainline. One thing I'll add to that is I definitely... Go ahead, Steve. We, apparently, Matt, there's a minute or second delay, like a minute and a half delay between you and me, which is really awkward. But what I was going to say was that I've definitely experienced in my career where I've worked with a vendor U-boot or I've used a mainline U-boot and then some processor orata that they fix, they fix on their branch and don't tell anybody. And then you spend weeks trying to diagnose an issue that turns out was actually already fixed. So that is not an experience I really like to repeat. But I think that the solution is that for these things is to really just have the vendors aggressively merge this stuff as they find it and to upstream them as they do. At least that's my experience. And just to quickly address, I tried to put this in the chat, but I have no idea if this is working or not. The talk that I referenced from earlier this morning that goes into much more detail on a kind of edge device, embedded device update system is secure boot and over-the-air updates. That's simple, no, from Jan Kiska. So definitely take a look at that. I think that the PDF will be posted if it's not already up there. Just scrolling down the list of questions, we have a question, are you using any RTOS or how do you meet real-time constraints? Great question. So what we've focused on for this chat was our use of Linux and some kind of standard open source boot loaders and other tools. Our system is heterogeneous. We do have parts of the system that have much harder real-time constraints. We have other parts of the system that have far looser constraints. And so our general approach here is to look at the requirements for the system and when that can be well-served by a kind of nicely tuned embedded Linux system, we will pursue that because it gives us some major benefits in terms of our speed of development. Certainly for other parts of the system, we have to use different approaches. So we have another question. I can talk a little bit about, there's talking there about the partitioning scheme. This is a strange layout. Why is the reason of such a layout? So the fit image is not stored in the root FS. The fit image is actually, is the kernel, right? And so we load the kernel from one location and then it will go and mount the, the root FS from a different one. So that is the reason for that format. Yeah, so essentially that's the slide here. This is illustrative. This is not an actual flash layout. We're simply showing the logical elements that exist in kind of linked together copies. So essentially we have a fit image which includes our kernel and device tree. And then we have a root FS and those two are kind of locked together as a configuration. So there was a question on, how long does the CI loop take to run against individual changes? Sorry folks, we're dealing with a little latency on the audio here. So for the CI loop, we've, it really depends on the complexity of the target. So some of our less complex targets, we can do a clean build in CI in about 30 minutes or so for our more complex ones they can take on the order of an hour. And that includes both the build time, the test time for our unit tests and some of the preliminary work to go and test against like emulated targets, right? So doing some of our integration tests against like a QEMU based target. So we find that that's a pretty nice balance of developer efficiency combined with local builds that are much faster for iterative changes, right? So build route has some nice tools in it that allow you to only rebuild the changes that you've made, reconstruct the image, test it on the target or on emulated hardware and do that verification locally, rather than being exclusively reliant on like a cloud build from a clean slate. I think there's a question about what Linux kernel do we use? Right now, I mean, in general we try to stay on LTS releases. I think most of our boards are now using 4.19. I believe that's true. And the idea is that we would move forward over time. So yes, we would eventually move forward to a 5.4 release or then so on and so forth. Yeah, so the kernel is certainly easier to go and leverage like a mainline kind of tree. And again, we do that for many of our boards where we can for other boards that have larger amounts of content in a vendor fork that we again, like don't want to sign our team up for doing the Silicon vendor's work of mainlining that. We will in some cases go and use a vendor fork. We try to make sure that the development that we are doing like any of our novel drivers are done in such a way that they could be mainlined when there is some common content that is useful for that or that they are at least easily portable that they work against the mainline kernel so that we can freely move between versions. So we have a couple of questions related to SW update. So one question is does the core compute utilize SW update to send updates to other devices? And a related question, are your REST API extensions for SW update available to look at? So essentially, I can kind of address both of those questions. The REST API is part of kind of a more generic device configuration and control framework that we've written. And under the hood, it simply automates the SW update command line tool. So SW update has some built-in tools for like running a server or for talking over a more programmatic API. But for our use case, we found it easier to simply automate the command line tool. So the REST API is not really an extension to SW update. It's more of a generic kind of device control framework that we've written for our devices that exposes a few endpoints related to performing updates. So under the hood, we're simply calling that SW update command line executable with switches that are populated by the REST API. And so we don't directly use the SW update tool to push out updates. We instead would call into that REST API from the core compute to the edge devices, which would cause them to run the update process locally. So we have a question, is there a reason why you didn't go down the AGL route? Yeah, and the answer for that is I think it ties back to some of Steve's earlier content. Much of the devices that we're building on were not envisioned as automotive grade components, right? So if we go look at what support we can get from a silicon vendor, they have in many, many cases not standardized around AGL. So it's certainly something that we're tracking and something that we want to be able to leverage if possible, but it's simply not feasible or I shouldn't say not feasible. It would be a too large of an effort for our team to try to standardize on that across all of our different SOCs and silicon platforms at this stage. So there's a question about firmware upgrades. Any situation that prevents some security risks, upgrades we have by driving. So yeah, so the situation is we just don't do upgrades while driving. So the upgrades pretty much only happen when the car is in a quiescent state. So we, to cruise, we'll operate these vehicles and the result is so we can control when they get upgraded. And so yeah, there's no over the air, there's no over the air update. You will not be riding in a car and have it suddenly decide to upgrade. All the upgrades would happen when the car is quiescent. Yeah, and just to address the security aspect of that. Again, the nice thing about this platform is that it is a fully enumerated system. We know exactly all of the components that are in the system, all the network elements of the system at when we launch kind of the overall software release. So we can take some extra steps to ensure that the only traffic kind of flowing through our system and the only things talking to those REST APIs are coming from known and trusted sources. So a combination of some simple policy and some security techniques to ensure that there won't be updates occurring while we're driving. So the next question, how many different SOC systems on ship and vendors do you use? I don't know the exact number, but it's several. It's enough that it becomes a management challenge, right? And there's a lot of reasons for that, right? Like we don't want to have all the parts in our system. We don't want to be a single source, right? We want to have a vendor diversity, but yeah, that does introduce some of the challenges you see. And also because like we're making something that hasn't been built before. And so the result is there isn't really one vendor that's going to provide everything that we need, right? We have to constantly go out and find the best tool for the job. And the best tool for the job might be taking a tool that's designed for something else and using it for what we want to do. So yeah, we use a large variety, but I don't know offhand what the exact number is. So we have a question here just related to our kind of storage devices. What about the disk systems, EMMC, NAND, NOR, reliability on failures like power fails, et cetera, what kind of file systems are you using for to ensure corruptions? Great question. So essentially we use a variety of flash technologies but quite a bit of EMMC and NOR flash and we use those in different places depending on the density of storage that we require. Secure boot actually provides us with some really nice guarantees around the integrity of our system, right? So by verifying each of the stages cryptographically, we can ensure that each step in that chain is both from a trusted source but it also has not been corrupted. And we can use a similar tool. Again, I think fortunately if you want more details on this, Jan Kiska talks quite a bit about this in his talk, but using something like DM Verity to verify the integrity of our RudaFest, right? Which is a read-only system. So we can actually cryptographically verify that as well. For our configuration data, right? This other data area here, we have really intentionally designed our system to be resilient to any failures there, right? So while we take steps to try to ensure that we are, using file systems that are resilient to corruptions to power failures, we take steps to try to ensure that we quiet all users of that file system before going through a planned reboot or power cycle. We've also taken steps to ensure that if that partition or file system becomes corrupt, we can seamlessly recover it, right? And with no harm or no kind of indeterminate state for our system to be in. We have about one more minute here. So maybe I can take another related question. So are both images identical, one for backup or some sort of previous version, current version? The scheme we're looking at right now does a kind of previous and current, right? And this is what we use across almost all of our systems. We have some that might take a similar approach with like a golden image and then an active image, right? Or other systems where if we simply don't have enough storage, maybe due to mechanical constraints, we simply rely on that kind of TFTP based recovery mechanism to ensure that we can get back to a known state. But nominally, we're looking at using a kind of current and previous, so toggling from A to B or from blue to green and then back. I think that puts us out of time, but if you're always welcome to find us on Slack, any other questions, there's a number of questions we didn't get to. So if you want to reach out to us on Slack, we'll be happy to try to answer them.


Kathy, would you like to introduce our speakers? Yep. So we're really delighted to begin with the integration of genomics and cancer paper, and the two authors who were predominantly responsible for that paper are joining us today. And the first is Dr. Erica Santos, and she's actually joining us from São Paulo, Brazil, and is currently working at the Hospital AC Carmago in their oncology and hereditary colorectal cancer program there. And in addition to that facility, she's also the supervisor for their graduate program, and she teaches oncology nursing. Erica is very active in the International Society of Nurses and Genetics and is the editor of the newsletter, and she's been the editor for several years now. And then Dr. Debra McDonald is also joining us. She'll speak second in this particular presentation, and since January, Debra's been working with me here at the National Cancer Institute in the Center for Cancer Research in the Genetics Branch. Prior to that, she's had an illustrious career in cancer genetics, first at Massachusetts General Hospital, and then for many years now at the City of Health Comprehensive Cancer Center, in their clinical cancer genetics program that she helped develop there with the team. She's been a longstanding member of ISONG and also was a former president of the International Society of Nurses and Genetics. So I'm going to turn it over to the both of them. Hello to all. My name is Erica Santos. Debra McDonald and I will talk in the next 20 minutes about integration of genomics in cancer care. On behalf of all the authors in this paper, we'd like to thank NIH for this opportunity to talk with you about this issue. Next please. Next slide. So the aim is to introduce how genetics and genomics are integrated into cancer care from prevention to treatment. Next. So the presentation will cover five topics, etiology of cancer, cancer risk assessment, tumor profiling, pharmacogenomics, and target cancer therapy. Next. So we decided to use a cancer study approach. So Mr. J is a 41-years-old European ancestry. His biopsy showed right side column cancer and two polyps. He had no prior cancer history and his medical history was unremarkable. Next. This is Mr. J Pedigree. So we can see here that he had column cancer at age of 41 and two polyps. His father had column cancer at age of 41, 50. His father had, his aunt had uterine cancer at age of 43. And his grandmother had column cancer at age of 52. So we will discuss the implication of his personal cancer history and his familial cancer history later on. But first of all, I would like to talk with you about the etiology of cancer. And cancer is as a genetic disease. Next. So cancer is a genetic disease is multifactorial and infection and chemical products and radiation alters DNA structure. So genetic and genomic factors underlie the etiology of all cancers. Next. So it's important that we know the etiology of cancer and all risk factors that are related to the cancer development because this is important for cancer risk assessment. So there are different risk factors that are related to the cancer development. Nurses must recognize those risk factors and the radiation chemical, biological and one of the important risk factors are genetic susceptibility. Next. So if we, according to cancer history, family history, tumors can be classified as sporadic, familial and hereditary. This has very important implications for the development of strategies for monitoring individuals and also at risk family members. Next. Sporadic tumors account for 75% of all cancers and usually occurs at an age of one set that is expected for this kind of cancer that we are talking about. For example, column cancer at age of 65. They are related to somatic mutations in a specific tissue. For example, breast or column cancer, for example. Next. On the other hand, if sometimes we can see the same time of cancer occurring at the expect age but in more than one close relative on the same side of the family. For example, two siblings with column cancer after the age of 60 or two sisters with breast cancer with age of 65. And sometimes this is referred as familial cancer. And this accounts for 10 to 15% of all cancers. And this is likely the combination of environmental and dynamic influences that are shared by close relatives or low penetrant genes for SNPs. Next. And 5 to 10% of all cancers are hereditary and they are due to a single gene mutation in the germline that predispose an individual to developing certain cancers. The hallmark is an early age at onset that normally the expected for a particular cancer, for example, column cancer at age of 30 or breast cancer at age of 30. And this is, as I said, a germline mutation that is usually related to this kind of cancer. Next. So most germline mutations are transmitted to the offspring by the mother or the father during conception. And somatic mutations, on the other hand, are not transmittable. And they occur into somatic tissues. Next. So how important is to recognize the difference among acquired and heritable genetic mutation? This is very important because it's the key to appropriate referral and further evaluation. And how can we achieve that? Next. One of the tools is cancer risk assessment. Cancer risk assessment is used to define cancer risk for the clients and family members. And this is used through the collection with personal health and family history. Through cancer risk assessment, we can identify individuals who might benefit from genetic and genomic testing. And also we can provide cancer screening strategies for those individuals. And cancer risk assessment is a very important tool to access psychosocial and cultural implications for cancer risk assessment. And one of the most important things is to provide education, counseling, and to facilitate informed decision making. But when we consider the cancer risk assessment, of course, it's not possible to refer all patients to cancer risk assessment. So we need to identify those individuals who should benefit with this strategy. So we have the red flags. So red flags are features on personal or family history of cancer that draw attention to suspect familial or hereditary cancer. So these are the red flags. They are only an indication for investigation.  So if we, next, if now we come back to our case, I'll petrify. Next, we can see now if you come back to our case study of the pedigree of Mr. J, we can check some red flags here. So we have age at diagnosis earlier than expected, more than column cancer, three cases of column cancer, which is not expected here. So we have three cases of column cancer. And we have also a constellation of a syndrome, which is ovarian cancer and column cancer, which is characteristic of a syndrome. So based on these characteristics, Mr. J was referred for evaluation and molecular investigation and discuss it with the patient. So now, Deborah will continue with the presentation. Okay, so thank you, Erica. Now, turning to tumor profiling, this is the evaluation of genomic factors, not just individual genes, but the study of one's entire genetic makeup, proteomics, the study of the structure and function of proteins, and epigenetics, or factors that can change the expression of a gene, or the physical, physiologic, or biochemical characteristics of an individual that are not due to a change in the DNA. So here if we take our example of tumor profiling by a process known as immunohistochemistry, or IHC, in Mr. J's case, this test is performed in the pathology lab on tumor tissue to screen for lymph syndrome by examining the protein expression of the four primary mismetry peer genes that are associated with the syndrome. And as you can see, there is very little expression of MLH1 here, protein product, as compared to the expression of the other three genes, suggesting that the MLH1 gene could be mutated. This helps to guide genetic testing by targeting testing to this specific gene, rather than testing for all four genes, and thus it's a more effective and a less costly strategy. So microsatellite instability testing, or MSI, is another laboratory test that when microsatellite instability is found, it suggests that the individual has lymph syndrome. However, about 10 to 15 percent of microsatellite instability is present in various sporadic cancers. So this is a clue, as is IHC, that there could be an underlying genetic susceptibility to colon cancer, specifically here, lymph syndrome. MSI testing requires tumor tissue, as well as non-cancerous tissue, as seen here. We've got the normal tissue and the tumor tissue, and the normal tissue could be that from a surgical specimen or a blood sample. So the tumor is classified as unstable when there are short, repetitive sequences of the DNA base in at least 30 percent of five or more markers analyzed. Here it's shown as repeats of CICACA, or cytosine and adenosine, two of the four chemical bases that make up DNA. MSI testing is also used in early-stage colorectal cancer to guide choice of chemotherapy since microsatellite unstable tumors are resistant to 5FU. This is an example of an algorithm for evaluating a colorectal cancer case. The algorithms such as that updated yearly in the U.S. by the National Comprehensive Cancer Network, the NCCN, are also available to guide genetic and genomic testing. And nowadays it's becoming much more commonplace, at least in the United States, to initiate tumor testing for lymph syndrome with IHC and or MSI at the time of initial diagnosis of a colon cancer. And in a case where there is less suspicion of lymph syndrome, for instance, some institutions might be performing BRAF testing when MLH1 is deficient on IHC. And the BRAF testing can be used to rule out lymph syndrome quickly and less costly than going to genetic testing by sequencing. The common V600E mutation in BRAF is present is evidence of sporadic versus hereditary colorectal cancer. This here shows the DNA sequencing output for Mr. J. As we discussed, his tumor revealed absence of the MLH1 protein, so the next step then is the targeted sequencing of the MLH1 gene. This testing identified a DNA change at position 1975. You can see that the normal sequence, CGA, and arginine was changed to TGA, so a thymine in place of a cytosine resulting in what should have been the amino acid arginine being changed to a stop codon, which terminates translation of the gene. And this particular mutation is a well-known pathogenic mutation in the United States, the United Kingdom, and Finland. Here this shows microarray, which is a means of looking at the DNA expression of multiple genes simultaneously using a chip or other platform. Shown here we use fluorescent dyes to identify gene expression. A commonly used microarray in early stage breast and colon cancers to help in deciding whether or not to undergo chemotherapy is the Oncotype DX test, which gives a score of the likelihood of cancer recurrence. So a low score would indicate a low chance of recurrence and thus that the individual would likely receive little benefit from chemotherapy, whereas a high score would indicate a higher risk of recurrence and greater chemo benefit. Turning to SNPs or single nucleotide polymorphisms, or that is relatively common changes found in a population, here we want to point out that four new SNPs associated with colorectal cancer were identified via microwave analysis, which when taken together with 10 previously identified SNPs may account for about 6% of familial colorectal cancer. Other SNPs have been identified that are associated with prognosis and morbidity. For example, SNPs have been found that are associated with lymphedema and breast cancer, and this knowledge can help nurses to educate women about means to reduce the likelihood or severity of lymphedema. Pharmacogenetics examines how genes influence drug actions, including metabolism response and toxicity or side effects. For example, as much as 20% of drug metabolism has been attributed to the P450-CYP2D6 enzyme, including response to tamoxifen and response to commonly used antidepressants, trade names Prozac and Paxil, which are also sometimes used to decrease hot flashes, so certain variants in CYP2D6 are associated with diminished response to these drugs, and thus the benefit would be nil or suboptimal. Many SNPs have been identified through GWAS or genome-wide association studies, as was discussed by Dr. Yvette Conley in the February 19th webinar. The therapy is another example of personalized medicine based on molecular features of a patient's tumor, so drugs such as Trastuzumab, trade name Herceptin, the first targeted medicine which was approved by the United States Food and Drug Administration in 1998, are used in human epidermal receptor 2 or 2 positive breast cancers to block cancer growth by binding to the receptor site on the breast cancer cells, since the advent of Herceptin bone marrow or stem cell transfer for breast cancers pretty much become obsolete. Bevisizumab or vestin is another monoclonal antibody it's used to inhibit the growth of new blood vessels in several cancers. This slide, which is in our article, shows how different drugs are used based on one's genes and how they influence drug response. So nurses could use this to explain to patients who may wonder why they are not getting the same treatment as someone they know who has the same cancer. Back to Mr. Jay here, tumor testing for microsatellite instability helped guide the choice of chemotherapy and immunohistochemistry helped to determine the specific gene that was involved in his developing colon cancer and this provided very important information for the patient in terms of his current care as well as guiding future cancer surveillance for him since he would need more frequent colonoscopy as well as other tests for the Lynch syndrome associated cancers than with someone without this syndrome. And this also provided important information for determining cancer risk in guiding, screening and early detection strategies for his family as summed up in the next slide including for his sister, his paternal aunt and her adult children and for his own daughter when she reaches adulthood and the age at which she would be at risk and need to have strategies initiated if she carries the same mutation. So in conclusion then, we've given you a glimpse into how genomics is changing cancer care today and as such informed nurses can educate and support patients in how genetics and genomics impacts the continuum of cancer care as well as risk management and the treatment they receive, a table two in our article lists clinical resources to familiarize and keep nurses up to date regarding genetics and genomics and clearly genetics and genomics is changing the way cancer care is practiced and nurses play a key role in helping patients and families understand these new developments and how they impact cancer in many other areas of healthcare. And thank you for listening to our presentation summarizing the article titled integration of genetics and cancer care in the first quarter of 2013 issue of the Journal of Nursing Scholarship dedicated to advances in genomics impacting cancer care and nursing practice. We have a few minutes I believe before Dr. Siebert's presentation on caring for individuals with genetic skin diseases to answer any questions. So I've opened the microphones for Dr. McDonald and Dr. Santos to be able to answer any questions that come up. Did you have a question please type them in? How important do you think that cancer genomics is for the care of cancer patients at this point in time? Either of you want to answer that? Sure. Well I think as we've shown certainly in breast cancer and in colon cancer we didn't give any other examples, but in lung cancer, melanoma, other cancers we're beginning to use personalized care in genomics in guiding the care as we've shown and how patients will respond to certain therapies so that we could change the therapy if the genetic makeup shows that they don't respond to that therapy or in other ways such as that. Erica, did you want to add anything? No I think as we advance we are going to use this even more in our daily practice so every time that we have a patient with cancer we are going to have this more and more and this is our daily, we use this genetic testing in our daily basis at least and in my practice I use this and target therapies is reality of course that I live in Brazil we still have some issues about covering issues as covering and because target therapies are very expensive and sometimes we have this kind of problem and also genetic testing is a problem and sometimes because of insurance so we are having some debates here about that but genetics and genomics is a reality but we are still discussing the coverage issues because it's very important thing to debate also so this is the debate is an ethical debate for us here also so this is a problem. Thank you Erica. The next question is how can we get more education and training regarding SNP and the clinical utility and it says is testing available throughout the country and what are the cost insurance coverage that's available and I think Erica addressed this for Brazil Deborah do you want to say something about it for the United States? Sure, sure well there are certain tests now that are covered by most of the insurers and I think that's as Erica said it's evolving and now we are looking at panels of testing for instance in families where you may suspect there is a hereditary predisposition but not due to the most common genes that we typically test for such as BRCA1 or BRCA2 there are now multi gene panels that look at several genes involved in the development of breast cancer. Insurance coverage for those tests is just beginning to come into play with I think that individual case would probably need to be argued for at this point as to why that might be necessary and perhaps a more cost effective approach than going through analyzing one gene after the next after the next. So we're on the forefront of all of this and in terms of learning more about it I think just keeping up with the literature going to format such as the G3C case presentations that we are working on and have several available already up on the website www.g-c-g-c.org and just keeping up with the literature because this is really evolving area and speaking to your whoever is the person in your area who may be more involved in this practice at the current time advanced practice nursing working in genetics or genetic counselor for instance. Well thank you both very much for a very informative talk and just to reiterate these talks are videotaped and audio taped so they will be recorded and archived on the genome.gov website and at the end of Dr. Cybert's presentation the listing of the website specifically on genome.gov will be provided. So I'm going to open up the microphone for Dr. Calzone to introduce Diane Cybert and as I change the presenter over to Diane she'll be introduced. Thank you very much Erica and Deborah. So I'm delighted to introduce Dr. Diane Cybert. Dr. Cybert is actually a practicing women's health nurse practitioner and she's certified in that capacity as well or current practices at the Walter Reed National Military Medical Center formally known as the National Naval Medical Center. She is a prolific writer and is a professor and director of the Family Nurse Practitioner Program at the Uniform Service Dish University of the Health Sciences here in Bethesda, Maryland. And so she is going to talk to you about the genetics of skin disease. Well good afternoon everyone I'm delighted to be part of this part of this group it's been fun to listen to the talks over the last few weeks and I'm glad to be part of this little this edition for the Journal of Nursing Scholarship. I am as Kathy said a women's health and adult nurse practitioner so the geno dermatoses the genetics of skin disease wasn't something that I was all that familiar with until a couple years ago when I partnered with Tom Darling my co-author on this paper and he and I published an article in the Annals of Internal Medicine with an interesting population of his over at NIH women adult women with tuberous sclerosis who did not seem to have the classic TSC triad of features of facial angio fibromas seizure disorder and mental retardation and those pictures on this particular slide show various features of this particular skin and inherited skin disease. And so I became interested in this topic and I realized I hadn't really read a whole lot about the genome dermatoses in the nursing literature so I thought that I would like to tackle this topic. So I'll take you with me on a journey as I kind of tried to figure out how to bring this topic to a larger audience. So physical psychological and ethical issues in caring for individuals with genetic skin disease is what I decided to call this paper. So just a bit of background the skin is of course the first line of defense between our internal and external environments and if you have healthy skin it guards against pathogen invasion protects against water loss it helps you regulate your temperature you feel sensations it's part of our haptic sensation in terms of balance and and it helps us synthesize vitamins there's been some really interesting work done related to maternal vitamin D exposure and type for example type 1 diabetes development in an offspring so it's very interesting things related to skin. So the genome dermatoses which in fact was a word I didn't really know anything I didn't know that word existed until about a year ago these are mutations that alter the way normal skin works. Interestingly and probably one of the things that Dr. Darling my co-author said when I first approached him about helping me or co-authoring this paper with me he said you know genotermatosis are interesting in when you think of all genetic disease and that this particular set of mutations don't normally shorten lifespan not there are some of them that do but most of them do not affect lifespan but they have significant impacts on social quality of life and social stigma because of the the skin is so visible to others and managing these dual disorders can be very complex you first have to treat what's happening on the skin you have to educate the patients and their families about this disease but you also have to address the stigma and again this is there's many places where nurses play roles in this if you think about all of these pieces and parts you need to treat and screen for the non-skin manifestations as I said you know when I was talking about tuberous sclerosis complex it's the facial angio fibromas which are the skin pieces but the seizure disorder and mental cognitive impacts are significant for these diseases but recognize that there's lung tumors and also renal tumors as well so the population that Tom and I were working with NIH that we wrote the paper on were adult women who had had very they had the disease but it was not not very expressive in them for whatever reason and they were they had transitioned into adulthood without a diagnosis and many of them had very severe pulmonary disease and were at high risk for lethal rupture of renal tumors so the the recognition of the skin manifestations they lead to lead you to a more potentially more important diagnosis of some internal structural problem that you can help prevent a bad outcome. We also need to make appropriate referrals and that can be complicated in these disorders because again there are several variety of organ systems that may be involved so they may require a team approach or several different referrals to different people. When managing these diseases the roadblocks are pretty pretty common and until recently deciding what the actual diagnosis was was rather difficult and well as we go into the talk a little bit further you'll see I'll get highlights and examples of that. There were very few effective treatments for some of these disorders there wasn't much research particularly in a rather rare some of these rare recessive disorders and as a result and because they're rare there are a few other affected people in your community that you could talk to and with the advent of the internet that's changing pretty dramatically in helping this population of patients too. So diagnosis of these some of these rare conditions is now possible that we have gene sequencing and we know what genes to look for the internet is as I kind of mentioned people are able to look outside their communities and local communities for people that might also have these relatively rare disorders and the internet is helping them find support groups and here are several that I that I ran into as I was putting together this paper talk against genodermatosis very powerful really robust sites, psoriasis, albinism incontinence, chepigmatae and an eczema support group so just an example lots of things happening out there on the internet now. So a little bit about the genetics I was stunned really to realize that there are over 500 genetic mutations that look like they cause somewhere in the neighborhood of 560 or 70 distinct skin disorders 400 of which can be traced to a specific gene but it's interesting because there's significant overlap between the disorders in terms of how they manifest on the skin so categorizing has been rather a nightmare and if you go back into history and look at textbooks of skin diseases you'll find authors you know here's a dry skin disorder to be left with these other dry skin disorders and so lots of confusion in the community about what categorize you know what category these disorders belong in but as we have become better understand the physiology and path of physiology of these skin diseases and the genetics of these diseases they're settling on the genetic the dermatology community has begun settling on classification systems and there are about 12 of these categories based on the type of skin lesion and then they are further subdivided based on their inheritance pattern. Some of these disorders may surprise you osteogenesis imperfecta I think most of us recognize that as a fracture bony fracture but there are also skin manifestations with that. Cowden's syndrome is considered a cancer syndrome but there are skin features specifically with that hypertrecholoceridemias okay that's cholesterol but skin shows up there and hemochromatosis, iron overload again there are skin features for all of these diseases and so sometimes just highlighting or having clinicians recognize the met the external manifestations get you faster to a diagnosis for some of these. Basically every inheritance pattern is represented in the genodermatosis with their autosomal dominant ones, recessive ones there's x-linked both dominant and recessive there's mosaic there are complex conditions lots of those where there's several genes plus an environmental trigger and then or an environmental a chronic environmental insults and then there's significant heterogeneity as well modifier genes are playing a role here for some of these and it's certainly environmental factors exposure to sunlight dry dry climates or human climates etc. So I the chapter is divided into you know I was working with inheritance patterns and here's the complex disorders I started there because it was the most common things atopic dermatitis and psoriasis. So about 15 percent of kids living in industrialized countries have atopic dermatitis that's a pretty high number and you realize that I put that word industrialized countries in there that's an environmental exposure that seems to be triggering some of this skin disease. Symptoms most people usually have symptoms that manifest in childhood and maybe make them absolutely miserable hospitalized etc. But many of them, many of these individuals get better as they as they age so the skin seems to become a little bit different with age. The mutations appear to be largely centered in this filigren gene there are four other genes that they're working with as well the mutation appears to cause an abnormal enzyme which prematurely disables these corneodecimones and that causes an impaired barrier skin. So things like irritants soap detergents etc. damage this fragile skin it's not built very well the allergens can get in and then you have this inflammatory cascade. So atopic dermatitis really is a model for the gene environment interaction and highlights the differences in expressivity because not all severely affected people have these flg mutations and not all people with flg mutations develop enzyme. So and then this whole idea that the older you get the less disease you have is interested complex process too. The next one I thought I'd talk about this psoriasis about up to 10% of people worldwide and you notice that there's no industrial piece in here so it seems that there's less of a role with industrialized communities or or chemicals perhaps playing a role here this is an autoimmune T cell disorder there's an environmental trigger and a genetic susceptibility so both of these two pieces have to be present. The symptoms very widely between people and it's different than the atopic dermatitis and that in psoriasis there's a very rapid skin maturation so the skin cells don't have this very nice paste growth they accelerate the growth rapidly the cells pile up on top of each other that the immune the immune system is not happy with that big callus type formation and so the immune system comes in to clean that up. So when you have very severe psoriasis and many of you may have seen patients with really it's on the sort of the external surface areas atopic dermatitis tends to be in folds and bends and psoriasis tends to be on external the outsides of elbows and knees that kind of stuff and the severe disease they've done some studies to show that quality of life scores for these patients similar to that of patients with other chronic diseases like hypertension and depression and CHF and type 2 diabetes so this can be a very debilitating disease. There's candidate genes but recognize that these genes are not necessarily skin as skin genes these are immune genes like that you'll find in the HLA complex of genes particularly HLA this particular one HLA CW those six oh two and then interleukin genes seem to be involved these guys are also involved in immune modulation so this is an immune mutation disorder interesting so here are some of the monogenic or single gene disorders that I thought were prevalent enough and interesting enough that that you might see them or be a kind of the interest or their markers for model disorders I guess for other skin diseases so the autosomal dominant one I thought I'd talk about is putziagres then a recessive will talk about albinism and then we'll talk about one x-linked disorder, contention pigment so putziagres or PJs is an autosomal dominant cancer syndrome that picture up there shows you some of the skin findings inside someone's mouth the it's the stick an LKB1 tumor suppressor gene if that gene is broken their life this individual's lifetime risk for developing cancers is very very high 93% in childhood these individuals often have skin lesions these dark blue or brown macules on fingers faces perennial areas if you see these in any of your patients in childhood you need to begin cancer screening or should at least consider this putziagres diagnosis it also comes at because it is a cancer syndrome this is a tumor suppressor gene that's broken you'll see some other manifestations hamartometis gastrointestinal polyps stomach small intestine large bowel nasal passages albeit although these are rarely cancerous they do get large and they do bleed so anemia is a possibility as well as bowel obstruction and intestine seption and usually younger children and then epithelio cancers colorectal gastric pancreatic breast and ovarian so this is a pretty serious mutation and that if the skin can be the first thing that someone recognizes and starts early screening and intervention you may have really gone a long way to improve someone's overall survival and quality of life the genetics are as I mentioned it was in this this stick 11 and LKB1 genes but the still not really clear how this genetics all works with putziagres because there are a number of de novo mutations and it appears to be also heterogenic where multiple genes are involved so not everyone has the same genetic they may look phenotypically the same but they don't have the same genetic picture so when you find somebody has a clinical feature as you counsel as you would for other osteomal dominant disorders and tell the family that the inheritance risk is about 50 percent and that if the mutation is known prenatal testing is available for putziagres albinism it's an autosomal recessive disorder and it involves melanin defects either the synthesis and or the transport of melanin in the skin in the incidence around the world is about one in 17,000 individuals but there's pockets around the globe where the incidence is much higher than that in sub-saharan Africa one in 4,000 Zimbabweans and almost one in 1400 Tanzanians so these communities have a lot of consanguinity a lot of intermarriages or even close marriages across neighboring communities and maybe not very much awareness of how this is actually inherited the most prevalent form is this ocular cutaneous albinism or OCA and there's four sub types and it depends on how what the mutations are like and if they're completely broken and make no melanin at all or whether they produce still a little bit of melanin really really kind of drives how this patient is going to appear externally and how many manifestations they're going to have because melanin is interesting it's critical not only for the skin color but it's also important for eye development obviously you can see the picture on the top right a lot of solar damage so skin cancer is very common in this population and the eye it's not only just the fact that there's no pigment in the eye but also eye muscles so they have poor eye movement poor visual acuity and these children also then have difficulty reading and chat and school challenges they not only look different now they actually have some some intellectual not not cognitively challenged but acquiring information is difficult they have again high prevalence of skin cancer and that that in this in this culture in the united states it may not be so unusual to see little kids at the beach or in the long sleep things now they're starting to do a lot of that but in in sub-saharan africa it would be pretty unusual and probably these people would be a bit shunt if they start wearing long sleeves and hats and things they need to protect their skin so social stigma for these for these children in particular can be very very profound they have very pale skin pink eyes they struggle in school they often stay inside they wear unusual clothes in the clothing and this is an extreme example of a social stigma but in some South African albino communities there are body hunters that are actually looking for albino people they kill them or they dismember them and make their body parts into good luck charms so very scary these communities that there are children that actually flee to this quote unquote safety of larger anonymous urban communities trying to to stay alive basically which increases their isolation and their marginalization so this is a big a big problem and so again it's that the the skin mutation if you can protect their skin and help them with their learning needs it doesn't really affect longevity but if the social stigma is so severe that they have to find themselves in a lonely community isolated it can be a very debilitating disease incontinentia pigmenta is a very rare disorder it's excellent dominant what's interesting about this is I really learned more about excellent most of the excellent disorders that I had really thought about before were really recessive disorders this one is dominant so if you have one mutation you're affected and so that means that girls are affected if you are a male and you only have one x and that one happens to be affected you usually don't get out of embryogenesis here or your if you make it to term pregnancy you often die very early in your life so the people affected by incontinentia pigmenta are women there's only about 700 women around the world it's because it's lethal and virtually all men you're not going to see it in boys the diagnosis is interesting because again it's it's a clinical diagnosis confirmed by skin biopsy or now by gene testing and the expression varies really widely they have this very interesting development of skin lesions from birth into adulthood they have this very severe blistering and that's this picture that I put up here just really represent some of the pictures if you go to a google images and do a search on this you'll see some severe skin manifestations but blistering till about four months of age then this wart like rash that appears for several months then they have hyperpigmentation for the rest of their lives and they have these very interesting brown and slate gray lines wavy lines again you'll see some of those if you go do a google search on it and then they also have very interesting other features like the alopecia strange teeth formation of teeth dystrophic nails cataracts so again more eye features retinal detachment severe vision loss again cognitive delay and intellectual disability and then some some various potentially really severe skeletal abnormalities hemivirtebrae scoliosis spina bifida syndacty and a congenital absence of the hands all of which caused by an excellent mutation so what's the role of nursing hopefully as as I went through this kind of again quickly you could think of ways in which you might interact with some of these patients we are basically everywhere in healthcare we're engaged with people in virtually every life event from birth to death to every place in between we're present in all healthcare settings we work with all populations and the public expects us to understand how genetic conditions are inherited again those communities in Africa that need more education about albinism they need they expect us to understand how common conditions are inherited including things like skin diseases like atopic dermatitis they want us to help them navigate some of the social and ethical issues recognizing that children with albinism have visual challenges as well as and helping them access those resources just understanding the relationship between the the eyes and social outcomes is important they also expect us to help them navigate some of these physical and emotional and social consequences of some of the disorders that they they have they want us to help them get access to some reputable resources there's lots of stuff on the internet and again as I was searching around looking for things to bring to you you run into interesting and very unhelpful or misleading pieces of information they want this stuff rapidly so that your your being facile with the computer really helps your patients and then offering suggestions about coping how to cope with some of the some of the funny looks or the fact that no one will shake your hand or laugh at you at the way your that your hair or eyes are colored etc so our job in terms of pairing nurses my job here at the university is to be aware of what it is that that nurses need to know and I think hopefully all of you are familiar with the two guidelines now that have been published related to what all nurses need to know the essentials of genetic enjoyment nursing competencies with the outcome indicators from 2008 and then the new essential and genetic general competencies for nurses to prepare at the graduate level that was published last year so in conclusion really nurses need to be familiar with the germic geno dermatoses more commonly seen in your communities need to be prepared to develop individualized care plans for patients and families with genetic concerns and be able to discuss the ethical issues that surround genetic testing which includes incidental findings there's been some new work ACMG released a new paper recently about how to an approach at least incidental findings so skin diseases affect millions around the world it's accompanied by significant morbidity which includes quality of life issues social stigma isolation it's we're still learning about the genome dermatoses many people don't understand them very well the ethical legal and social implications are similar to those patients that have other genetic diseases including all the issues around genetic testing and nurses are important because we can link the science of genetics with the human experience of health and illness and we can make an important positive difference in the lives of our patients of all of our patients but in this context patients with hereditary scan disease so um I think I will stop there and see if there are any questions or comments hopefully I can answer something like I said I'm not a particular expert so Diane there was a question um from an attendee who says I had a patient with a sclerosis fibroma of the nose the dermatologist recommended p10 testing is this lesion part of the p10 spectrum that is a good question and I don't have a good answer for that I would have to I'd have to do a literature search to find that answer myself I don't know if Deborah or Erica or you're either you or Kathy have an answer for that so I've opened up the microphones does anybody else want to address the p10 discussion about the fibrosis of the nose what was it in the nose I didn't quite get it let me read it it says fibroma a sclerosed fibroma of the nose and the dermatologist recommended p10 testing is this lesion part of the p10 spectrum well there are um sporadic fibromas that can be seen in carbon syndrome so um it it could be a cutaneous marker of the disease uh I've not come across it myself so I'd have to do a little more I'd have to look look it up a bit and see if it if it actually meets criteria for testing but but it is a marker of uh that has been found in Calvin's disease before so Dr. Calzone you want to tell them a little bit about the PDQ database where some of this information might be located so PDQ at cancer.gov actually maintains evidence-based reviews of hereditary cancer syndromes and other associated variables if you go to cancer.gov you can look at an individual topic and in um Houdens for example it falls under the genetics of breast and ovarian cancer because it's a syndrome that is associated with breast cancer as well as other cancers um and when you click on breast cancer at cancer.gov you just scroll down to the genetic section and there'll be a whole section on the current evidence associated with Caldons and the clinical criteria associated with the um you know indications for testing for uh mutations in P10. Thank you um any other questions that people want to submit go ahead and do so and um Diane could you move to the next slide which also shows the next webinar coming up if you have that available so while we wait for the last few questions um just a reminder that the next webinar is April 26th and it will be on autism as well as an update of childhood genetic disorders so if you have colleagues that are interested in pediatric conditions um please tell them about how to register for this webinar for April 26th so I don't see any other questions so I'm going to open up the microphones to our presenters just to have one last word before we close out the day. Deborah any other parting comments? Well actually I did have a question um Diane that was an excellent presentation thank you so much and um I certainly learned a lot. I have a question about Pute Shaker testing I think you mentioned that there was prenatal testing available and how would this be uh useful or is there some intervention that would be initiated that would um uh justify prenatal testing or is this something where people might even choose to terminate? Well that's a really good question I think that that comes up with a lot of the more the more we know about um genetics the more the attempting it is to do things uh preconceptually or conceptually so if you know what the family mutation is of course you can screen for it you could do it pregestationally with a PGD pregestational diagnostic testing or you could test for it prenatally that's a discussion that that again these patients should in my view these conversations should occur prior to conception certainly um what are you going to do with this information um but the fact the fact is that it would that it does exist and so um hopefully you're not first diagnosing something like a cancer syndrome in um early in pregnancy and have to then make a decision about whether you're going to do prenatal testing ideally you do that before you ever got pregnant and it's going to it's going to raise it's going to raise a lot of issues over the next decade or so the cell-free DNA even increases potentially increases the sensitivity decreasing the risk for normal fetuses too Erica any last comment well thank you for joining us from Brazil and I know that is very difficult to make sure all these connections work so thank you and Kathy any last comments no none here we hope that you'll join us and for the next set of webinars that's coming up at the end of the month so thank you Diane and Debra and Erica any other comment Diane no I don't think so I enjoyed it thank you I think it was a good pairing of these two talks together I appreciated the I really had learned a lot from the cancer one too so thank you thank you very much this is Debra so I'd just like to say that you know I think that we're we're in a very rapidly developing ELA that is changing healthcare quite dramatically and will continue to do so so that webinars and publications such as in the Journal of Nursing Scholarship um are really necessary for nurses to be kept current about what's what's going on in these awareness and and to be able to not only use this information with their own patients and families but also in even with other healthcare providers including physicians and others who may not be aware of the latest developments well thank you all and have a wonderful afternoon thanks


Everybody forced here ripping 2022. I Mac UFC hobby five bucks. Hey's number one here on release day This is a random card style break. Everybody in the break is gonna get a random card So 30 spots 30 cards Sean will type in these names with a hundred percent accuracy as we go along here And I'll do the random at the end and if any of them are wrong Sam Sam's gonna 360 windmill dunk on him. Good luck. So you open everything up random at the ends Here we go. Let's go Shane. I'm all over this No, do it right Oh, you got him Carl. That's awesome, man. Yeah, that's pretty solid box. Here we go y'all little sky blue color Six card per box one parallel the rest are hit so there are five parallels five base parallels in the case everything else is a hit Should get three autos and two men and then one base parallel. That's how it should be They're gonna start with a fun one.  I'll tell you that right now So the first one is an Israel Adesanya numbered 16 of 25 Fitting because I chose him for the thumbnail today Israel Adesanya Numbered 16 of 25 and you're gonna have to be descriptive since there's base parallels You know what I mean? So you could just put name and number for these everything else has to be like relic or like You know what I'm saying? Yeah Israel Adesanya, I'm just gonna say Next up is Michael Chandler that I'm Matt. Nope. It is a Fighter worn jer- er relic 99 of 99 Michael Chandler relic 99 of 99. That's gonna be your favorite word is relic Keep it easy. That's probably the easiest name. You'll get today to Michael Chandler 99 of 99 Next dude, that's disgusting Gloves relic. No way Five of eight Jack Hermanson That is nasty official fight glove Fighter worn Jack Hermanson five of eight. How much would Jack Hermanson glove five of eight?  Good luck on that one you guys. Oh, this is disgusting too Prime patch auto Robfont 4 of 10. I lied. That's the easiest name. Nice Robfont Dude good box in the first one here Robfont patch auto 410 prime patch or premier patch whichever where they use Just his prime auto next up is a redemption. Who is redemption in this? Marks of greatness BJ Penn BJ Penn redemption This stuff is stacked And we're gonna we got a dual auto the first box has been crazy TJ Dillishaw and Cody Garbrant 10 of 25 Cody Garbrant to 25 10 of 25 Keep putting Q for relic. There we go Crazy crazy. I Dillishaw is a beast They were proud. I would imagine a lot of these people are not sitting together at the same time when they're signing these Sean is having a good time typing all these in Dude, there's a BJ Penn redemption. Look at the glove. Look at the glove Even the Robfont like first box is really good He gets the top load and type in all these He's got nice ship Saturday So Next up there is Sayid Nurmagomedov. Good luck with that one Sayid Nurmagomedov 27 to 49 Get good at typing that name because there's a few Nurmagomedovs. There's a few of them No You said that's not his name He said Oh God Raphael Fiziav canvas Raphael Fiziav canvas number to five of 40. Oh my god This is the best part of breaking this shot has type all these names in we should switch I'll type you break next time Jim Miller canvas 15 of 65 For those I would just like canvas for the relic. Oh an on-card On-card auto is Amanda rebus 22 or 23 of 99 marks of greatness That's our second on card. I think I really too so far Nice Amanda rebus How you doing? I'm good. I'm good Just make sure it's like organized.  Maybe have like a bin and then when you're done put it in the bin. You don't even have maybe we're about top loading later Yeah, just focus on names All right prime relic auto Edmund Shabazian 33 of 99. Is that how you say that Howie? What Shabazian is that how you say it? Oh, are you fc expert? No, I know I know I know Oh, no Relic auto there So Yeah, you're gonna have to keep these organized. We can go back through if something happens Adesanya Michael Chandler glove relic font Pan dual auto When The nirvana office in there. You see what you did.  Oh So that's where the syed goes Hang on guys Do the do the syed again. That's the one I got so that because I kept the vets for these Then it was Jim Miller And then redemption on the back Nice dual auto colby covington or hey masvidal that'll be nasty once you get that Good luck on this one y'all Covington and masvidal dual auto. That's a big For duals, you could probably just put last names. There's not a whole lot of I don't think there's any duplicate last names in the separately So we're gonna hear right Yeah Dual auto covington masvidal. That'll be awesome, man. All of the next one.  All right first card of box three is a colby covington numbered 8 o 49 Colby covington numbered 8 o 49 Next up relic paul craig rookie paul craig 6 of 25 Next up is jumbo relic max holloway 67 of 99 jumbo relic max holloway 67 of 99 Shadowbox signatures is not a shadowbox Is pager munoz 30 of 99? It just says shadowbox Pedro munoz auto 30 of 99 Another rookie auto here this time is grant dawson 95 and 99 And oh wow Memorabilia auto colby covington 18 of 99 Good stuff on card covington We fight or warn relic auto Yes Colby lot of colby in this in this case. That's like the third card. All right two more boxes I always start stacking once you're done with them. I would just stack in order So if you just go back to me too Yeah, there's no shadowbox. It's just it's not it We've got a tie to evasa 39 o 49 ti is tie tie to evasa 39 o 49 Next up rookie relic grant dawson 8 of 25 Grant dawson rookie relic 8 of 25 Got jumbo relic kumaru or kumaru uzman 16 of 99. I'll say kumaru kumaru uzman 16 of 99 jumbo relic Nina nuñez relic auto 16 of 25 Nina nuñez Dude, this is nasty right here acetate Derek louis relic auto 5 of 8 sick louis the acetate to 8 was hoping we'd see one of these Yeah, congrats on whoever gets this one too Derek louis relic auto 5 of 8 And on the rookie relic auto rafael fazeev 4 of 99 rookie relic auto rafael fazeev 4 of 99 Keep stuff there too. Yeah, it's been a really good case overall And into the last one we got a random And guys we have two more cases of this tonight same style random card Random card style you can check the home page right rookie Oh boy Get ready for this one, Sean. Shavkat Rachmanov 19 of 49 Yep, in stock for personals guys in stock for personals personals done after group breaks Shavkat Rachmanov 1949 I'll have to give Sean a minute to type that one in I'll give you a personals link while he does that Personal boxes will break later on tonight 399 at 99 free shipping worldwide All right, Nina Nunez 4 of 99 relic card Nina Nunez Relic 4 of 99 Next up another relic here this time is Karla Esparza 16 of 25 Karla Esparza 16 of 25 relic redemption Daniel Rodriguez rookie memorabilia autographs gold That will be numbered to 10 This has been a really good overall case so far Daniel Rodriguez rookie memorabilia autograph gold redemption. So just You put Daniel Rodriguez gold redemption if you wanted to I think it's our first legend if I remember correctly I mean, there's some legends that we pulled that are current but legend legend here Antonio Rodrigo Rodrigo Neguera 45 of 49 legends auto Antonio Rodrigo Rodrigo November On the legends auto 45 of 49 Oh, man, we're finished with a big one here That is that's gorgeous gorgeous card coming up y'all immaculate celebrations auto Sean O'Malley 74 of 99 What a beautiful card Wow, wow, wow good luck on that one everybody Sugar Sean Celebrations auto Holy cow To 99 that is that is an awesome design. I love this. Hope we see a lot of these today 74 of 99 Sean O'Malley really great look there. Holy cow, right? Is he a field pass? Sean O'Malley S-E-A-N Long way as a Sean over here would say the irish way, I guess All right, I'm just gonna double check a few things here Just to make sure like there's relics and autos that are That's all I'm checking for is to make sure that okay. It's good to me Damn Sweat hardest work Sean's done Since he's since he's got here. Yeah, all right random time everybody again 30 names all 30 hits We're gonna randomize each same amount of times put them side by side. Let's see who gets what some big cards in there It's a good case especially overall. Here we go We'll go six times on everything five and one Yeah, Sean is killing it over here Name six times and the hits one two three four five and six mark d Down to steve r and then six times on the hits now. Good luck um, so again the base So like it'll just it won't have so everything will have relic or auto unless it's a base like the uh The rock one off here just says like rookie to 49 or like the autos on yet at 25 Like that's how it's just everything else will have relic or auto or whatever All the hits will have something that says that it's a hit Just fyi like all the relics and autos six times one two three four five and six uh rock one off down to uh, covington relic auto So we're a few covingtons I spoke everything over and then read it read them all off Thanks for filling these up today everybody. There's some more tonight Go 14 and just scroll down.  We'll get these results posted to the site Thanks again everybody another one of these up next


Well, it's going on everyone Sam here with Leighton sports cards, and I'm ripping one bar or two boxes for John M These include one twenty twenty one twenty two Penini recon basketball and one twenty twenty one or twenty twenty two can you select UFC hobby? So good luck here John. Give me one sec. I got to do something here Let's do it good luck start off with the recon Yeah, not gonna sleeve everything they all will get sleeved Eventually the Haliburton, Jeremiah Robinson Earl Jalen Suggs base rookie And like this will get sleeved. I owe to sumu on the red to 199 bowls a little bit of color match there Nice and maneuvers tray got first auto is my brother will Barton 29 out of 99 for the nuggets. I gotta pick up an auto piss. I want to get a jersey of his My last name's Barton. So I think that would be pretty funny. I got Cody Barton in the NFL I got will Barton in the NBA Colin Sexton recon Paul George rock the rim Brendan Boston jr. Got nice Steve Nash.  Don't worry Just not gonna do it right now for the sake of time Zion on the silver all systems go Luca on the short print love these right here. So nice Yeah, future legends are really cool. I like the skies the limit and the closing statements. Those are cool as well Want to scone Anderson down O'Banton and maneuvers Cade. I'll sleep the Cade right now two packs to go Still looking for an auto here me in this pack. We've got I have to soon move nice On the recon rookie not numbered. There you go. Grats on that one John very solid hit very solid Got Patrick Williams. Let's see Stibald. Oh 100% agree with that KJ 100% Moses moody rookie nice Franz Wagner bronze rookie 299 been a really good boxer recon No, like numbered card wise rock the rim and bead All right, so that'll do it for Recons do some select UFC Let's pull another big auto out of this full zebra or something maybe I Wish he was my brother Had to be nice Gonna have to work anymore. Just leech off the pin Got see what we got here Phil Hawes got Jeff Molina on the tricolor rookie not numbered Got that is Claudio Puellis on the bronze rookie to 175 Nice one there. Nice. I like what I see here. I got tie-dye coming up Sean Brady got wow Oh Yeah, dude Let's go. That's so nasty. We'll man that one for you. How about a tie-dye octagon side? Tom Aspinall rookie man.   Let's go silver Nate Diaz another nice hit Man, this isn't fire tonight so far. We've been hitting some nice stuff out of UFC These got Brandon Roy Val on the silver Sounds good Gucci you zero Ghana got Pedro Munoz on the scope not numbered Let's go dude. That could be got me height Too bad.  So still looking for another auto too Supposed to have another fire auto. It'd be so sick Los Anios Got uh, Angela hill on the blue Blue is to 199 127 out of 199. Nice one there It looks like our auto in this one. We've got uh Edmund Shahbazian on the octagon action signature is nice Nice one there And try colors Rashad Evans behind that Then mess my pile up over here the try color Couple packs left here. Let's see some nice color to end it off as well Got try color of Alexander Pentoya Pentoya popcorn every day Johnny Walker, Adrian Yanez got silver of uh, Khabib not Khabib, but Khabib's family And last pack. Good luck here Licon of Gilbert Burns and billy quarantine That is red 52 out of 99 That'll do it for your break there. Uh, John congrats on all the hits. We'll get them right out to you Thanks again, buddy