Welcome, I'm Nancy Vential Underwirt and I'm co-presenting with Brian about successes in agile and medical devices. I'll just kick off by saying welcome and we wrote our book that we'll be speaking about some case studies from a book we've just created. And, you know, it's really about, I think the real stories are better and more interesting than anything a person could create as a novel or something of that nature. And there's twists and turns and things you just wouldn't expect and creative approaches to using agile. So that was inspiring to us. So I'm gonna give Brian a chance to go through some introductory slides and then we'll each talk. So just to give you a sense of who we are, I'm actually originally an analytical chemist, although I've done some tinkering around with some programming, I do not consider myself an expert developer. I've worked for 15 years in the area of clinical diagnostics. For that I mean the development of the tests that are used to measure this, that or the other thing in somebody's blood sample or in some other kind of a sample. I was supporting that kind of work with doing chemical analysis that I would end up actually developing assays. And then I ended up validating the software that was embedded on the instruments. So I did that, there was 15 years with that collection of stuff. And then another six years as a software quality manager, most of that in the clinical trial data management software. And I'll talk a little bit more about that in the first of the examples that we cover. I've been working independently as a validation consultant for medical regulated companies, those regulated by the Food and Drug Administration. Most of them are medical device, but some of the work has been in the clinical trial data management area. So the kinds of things that I work with or software validation evaluation of the plans people have for fulfilling the requirements of the part 11, 21 CFR part 11, the electronic records and signatures, regulation. I also help people set up their sell up or tweak their quality systems for developing software or take part in the audits that they have to undergo and do some training. So Nancy. Okay. I'm Nancy Vinci showing the work. I worked originally as a designer of electronics and doing software. And this was for industry applications originally flight simulations for commercial and military aircraft. I've also worked in factory automation and medical devices and some defense work too. So for over 15 years, I've worked in safety critical applications that involved hardware and software both. So I got to use both parts of my background. In late 1990s, early 2000s, a lot of the agile practices were beginning to surface before agile had a name. And I began using those with teams that I worked with and I was really impressed with how effective they are for both hardware and software. So I had a good four or five years experience by the time agile started getting talked about. Anyway, around about 2002, 03, I just decided that I wasn't gonna use one of all practices anymore, but there weren't any companies using agile. So I decided I would try to make that happen along with enough other people. And ever since then, I've been coaching agile teams and their managers. I have something of a specialty you might say with hardware and with medical devices when I team up with Brian especially. And that's pretty much it. Back to you, Brian. So what we wanna talk about in this session is that working from first principle, it's not just copying somebody else's methods, allows groups that work in the regulated medical industry to adopt agile methods while they still fulfill the mandates that they have from their regulatory bodies. So we'll take, and this is based on the set of examples that we wrote up in a book that we published recently where we agile methods for safety critical systems, case studies of medical product companies. And you see here the link for checking out the information about that book. Now, what prompted putting the book together was two key things. On the one hand, there's this belief in the quality and regulatory world that still seems to persist that agile's not allowed, that agile is a thing that, no, no, no, no, you can't go there. And the other is the management mentality that says, yep, if it's a process, plug it in, make everybody follow it and check off all the boxes. On the one hand, in concerning agile being allowed, the association for the advancement of medical instrumentation, Amy, put out a technical information report, TIR number 45, back in 2012. Putting together that report involved people from the agile community, people from the regulatory area, there were a couple of FDA people involved, and people from the medical device industry who all collaborated to explain how an agile approach can in fact be used in the regulated environment, how the two sides really can be reconciled with each other. But even despite that technical information report, there's still some quality assurance people say, yeah, yeah, yeah, I've heard of this TIR 45, but I really don't see what they're gonna be doing with that. So that is still persisting. Gradually, some people are starting to see the light. I mean, I saw this a number of years ago when Nancy and a couple of colleagues of hers first showed me a test-driven development approach using a development board. What I had been thinking for so long that the testing of a piece of software was something that was tacked on at the end. And if a schedule was being compressed and the managers would always cut the quality process, I realized that building the quality process in made much more sense. And that's why Nancy and I have been collaborating all this time. Too often in the check the boxes mentality, somebody says, yeah, yeah, write the SOP, you're done. Then everybody will follow it. And they impressed the process as a top-down thing. And we know better than that in the Agile community. So here are the people that we talk to to put together examples. A company called Open Clinica in the Boston area where I used to live that started up providing data for managing clinical trial data or software for managing clinical trial data as an open source tool. Some amount of their stuff is still open source. In PECO, an Italian company that does automations for large clinical laboratories where they actually run the tests that determine the concentrations of this, that of the other thing in blood samples and others. Sanity that I did some consulting with for several years. A medical device group within a large multinational pharmaceutical company. Neurometrics and atomic object working together on a pain relief device. And Blue Fruit Software, a contract software development company in Cornwall, England that does a lot of work in the embedded systems area and has moved into the medical device embedded software field. We're only gonna talk about two of the seven examples that are in our book in this session. And the key thing about all of the examples that we described is that although they applied Agile and Lean principles in different ways, certain basics were common among all of them. So we'll start off by looking at my friends at Open Clinica. I did, I helped them set up their quality system and have off and on worked with them over the last 10 or more years. A clinical trial is the set of experiments that people do in order to determine whether a drug or a medical device or a vaccine is both safe and effective for use in humans. So they have to have volunteer subjects who agree to be treated by the drug or the vaccine or the whatever. And they have to have a particular structure so that they check the volunteer on periodic basis and determine how well the person is responding. Every trial has a different structure. There's a certain flow of events, there's things like skip logic, end points, there are checks that have to take place to make sure the data are valid. You don't wanna have somebody in the database being a classed as male and yet in another place in the database being listed as being pregnant. That kind of stuff, those are some, that's one of the more obvious checks that needs to take place. New features are being added all the time in the open clinical product because data managers say, well, I need to be able to do this or I need to be able to do that. And in most cases, people have used the software in a hosted environment. There's a heavy emphasis on the design of the software for usability. So open clinical takes a very flexible approach to planning out what they're gonna do. They, on a regular basis meet, they take their product owner gets input from the various data managers that are handling that, that are actually doing the clinical trials, managing the data from clinical trials and they get together internally between their client services, their software quality assurance people and their developers and say, well, what are the kinds of things people are asking for? Then look through them, analyze them, break things down and come up with a list of feature requests and then rank those on a roadmap. And notice this is a process that goes on a regular basis so that roadmap gets adjusted. From that roadmap then, they have a plan. They say, okay, over the next three months, we're gonna work on these minimum-releasable features. And so the regular cycles take place. There's the cycle of the development and the internal cycles of the sprints that result in minimum-releasable features that are composed of a series of stories where each story has its own acceptance criteria. And those things are linked in JIRAs. Now they're stored in JIRA linked via the Cucumber tool. The company went through a training and practice process several years ago wherein they set up a behavior-driven development process and the Cucumber tool so that when they create their stories, they set them up using the gherkin given when then expression, which not only gives them the story, but also the tests and test everything via the Cucumber tool. What that gives them is documentation that comes out of that as a natural outcome. They have a report that's a list of stories, which are basically the same idea as software requirements. Those stories are linked to their respective tests, so they are producing their traceability matrix. So there's a couple of key parts of their regulatory required documentation that come out just as a natural consequence of their BDD process. And oh, by the way, because the tool is highly configurable, they can set up automated testing through their BDD structure so that they can test lots of different permutations and combinations. The company is committed to a continuous improvement process. Remember, that's one of the key things about a quality process that you're always looking for ways to improve and make things better. They never used to estimate their stories, but by doing so now in the last few years, they improve that process and are more able to predict when they'll have certain kinds of things finished in their development process, because they have story sizes. When they run retrospectives, CAPA stands for Corrective and Preventive Action. That's actually a required part of a quality process within the regulated industry. Corrective and Preventive Action says, okay, we're gonna say, we need to do something about this thing because either a problem occurred or we can see that there could be a problem. That's the preventive part. When they do a retrospective, they'll take a couple of the most important needs improvement areas and say, put them into their CAPA process. So right there, the regular rituals of the agile process feed their regulatory required process. Autonomation, automation with a human touch. The automation that they achieve by using their BDD process with the automated testing that comes out of the CAPA process allows them to cover many, many more permutations than they would otherwise do if they were doing these things manually. And oh, by the way, because their customers have to audit them for their quality processes, their auditors have been impressed with the requirements, the tests and the traceability that have been generated by these processes. So as a quick sum up, there's a flexible planning process baked in, the automation with a human touch allows them to test things much more thoroughly because it's a highly configurable product. Their BDD and cucumber have given them auditable documentation and their retrospectives have fed their required quality processes. So over to Nancy. Okay. Next, we're going to talk about leading through quality how Blue Fruit Software entered the medical device market. And first off, I'll say something about who they are. They're a group of embedded software specialists. They are based in Cornelon, England, around 70 employees now. Their client base tends to be in the automotive and industrial spaces so far, for the most part. And they've more recently started getting into medical device work. Their founder, Paul Massey, was a software developer who had been doing contract software work. And he was looking for a more positive environment for developers to work in, especially developers like himself, who really wanted to do high quality software. And he had a strong commitment that quality needs to be driven from the bottom up, you know, by the hands-on people and for the right reasons. The company recently became employee owned. And I'll say a little bit more about that as we go further. But one of my favorite topics about real stories is when there are surprise benefits. So we'll talk about those two. But back to the origin of the company. They've been growing about 50% per year, ever since their founding 20 years ago. And they have very low employee turnover, only about 4%, where the norm for their type of company is more like 10 to 13%. And before I get into telling the story, I need to set the stage a little bit by explaining what certifications are. And basically, I'm going to talk a little bit more about the company. And I'm going to talk a little bit more about the company. What certifications are. And basically, these are standards that are based in laws and so forth, or various companies. They're standards that are issued by regulatory bodies. And they can, and companies are audited on the basis of what these standards call for. I'll just point out a couple of them here. These are some very common ones that are encountered over at the left in this chart. You see there's IEC 62304. That has to do with software development life cycle. And Brian alluded to it a little bit earlier when he said that, you know, there's a myth that agile is not really permitted or is frowned upon. That's just not true. If you're actually reading the standard, agile is a better fit in many ways than waterfall. For what the standards looking for. And there are others. There's usability. There's risk management. You see over at the right hand edge of the screen. 21 CFR part 11. That one's actually a law, but that has to do with electronic signatures and electronic documentation, something that's playing a role in all companies now. Well, maybe not all, but you know, it's getting much more wide use than before. Just so that. Sorry. Go ahead. Many of you are probably familiar with ISO 9000, the quality regulation. The one shown here that says ISO 13485 is simply the medical device version of ISO 9000. Sorry, Nancy. Okay. Well, that was a good point to make. Anyway, another one, another thing to mention is that these certifications often make reference to having a quality management system. And if we could go to the next slide, a quality management system is something that companies need to have in place. Your software needs to have been created within the context of a quality management system. And I actually like that concept because it, I think it fits well with that job. And I'm going to ask Brian to say a few words about it because this is squarely in his area of expertise. You know, Brian, why don't you give us the definition of a QMS and why the regulate regulatory bodies insist on it. This is in fact why the comparison with the ISO 13485, ISO 9000 is apt in this circumstance because the quality management system sets out kind of your ground rules. Here's how we're going to go about these things. Here's what we expect. Here are the outputs we want to see created when you do something like a software development. Here's what you're going to do to make sure that you provide proper service and document the proper service when there's something that needs to be serviced at a customer's site or supported in some way. Here's how your management is going to check to make sure all the quality processes are working well and what things need to be improved. So all of those things together make up the quality management system. The key thing to remember in the eyes of any of the regulatory bodies or the notified bodies that do the reviewing and auditing, if it isn't documented, it wasn't done. So there's a documentation element as well as a practice element. Yeah. So thanks, Brian. So moving right along here. As Blue Fruit managers were thinking about maybe getting into medical device work because after all they were very committed to high quality work and lots of medical devices are embedded systems. And they gave some thought to getting involved in this. And the idea is, well, they felt a little hesitation because they thought, well, if we have some expert design a QMS for us that's compliant to the regs, they were called. You can bring somebody in. They can tell you what to do and then they can help guide you so that within a few months time you'll have what certifications you were aiming for. The feeling was, well, if we get some outside designed thing into our company, that's going to break empowerment or it could. The idea being that we want to have our engineers doing the right thing because they're committed to it and because they have a clear line of sight between what it is they're doing and how it serves the overall quality of the product. Empowerment is really core value at the company.  He said it means avoiding creating situations where management has to overrule teams in order to safeguard a larger or longer term interest. For instance, gaining a certificate. And that's, so Paul has a bit more philosophy in this nature too. Next slide, please, Brian. Here we go. Paul had this to say about empowerment and I really think it embodies good agile management. He said if it's my project, if it's something that I'm championing, whether part 11 or in the past it's been BDD or TDD, I've always said to myself that if the team doesn't buy in, then we're not doing it. It's not happening and I'm absolutely committed to that. The onus is on me to get that buy in. And what he really means here is he's got to sell the idea on the merits to the developers, get them to honestly buy in, not just order them to go through the motions. There's a big difference. Yeah, so anyway, so as the story goes on, it happened that they were approached by a company who needed to get their software redeveloped. Let me give you a little backstory about that. They were approached by a company because of their reputation for quality. Now this other company, this potential client, they had a product that they had created. They were somewhat new to the medical device field, so they didn't understand the whole QMS idea. And they had been advised by, you know, business people that they knew that they were going to have a hard time with the FDA because of the way their software had been developed in a, you know, traditional waterfall type of environment. And they'd been told that there's no way their software would pass an audit because there were too many telltale signs that it had not been created within a quality management system. For example, that anybody looking at the documentation would have been able to see that the unit tests were not created, contemporary to the code, what design reviews they had weren't really actually about people planning the behaviors of the software. So there were enough signs like this in the documentation, and they were told that they would just have to, it would be better to just redevelop the software. And in case, now what I want to do is pause just for a second here and let Brian give us a little more background and explanation about why this happens. And is this really common? Have you seen this before? Brian, you want to take a minute and give us a little explanation on this. Being forced to go back and rewrite the software completely is a little unusual. However, there are plenty of circumstances where a developer, there's too many opportunities when you're writing things down to falsify stuff. And there's too much temptation to write stuff down that may or may not have ever properly happened. So there's a lot of, there are rules around your documentation that needs to be attributable. That is, you know who put that information down, the legible, consistent and coherent, captured at the contemporaneous, captured at the time you actually did the work. And there's several other criteria along the way. So in a case like this, apparently, the documentation just did not fulfill the so-called ALCOA, the attributable legible contemporaneous, et cetera, et cetera, full criteria. It was too obvious that something was wrong and that maybe the documentation was correct, maybe not, there were too many big questions about it. So that's why this kind of stuff takes place. As I say, this is a pretty unusual one to have to go back and completely rewrite, but it's not impossible for that sort of thing to happen. Okay, thanks, Brian. And so, you know, you can, by what Brian just gave us as an explanation, you can almost see why Agile, when it's done properly, is really going to fit all these needs that the regulators have. This is one reason why I think Agile is a perfect fit. But anyway, let's go on with the story. So this client, they found blue fruit because they made inquiries around, you know, they started inquiring what sort of processes companies had internally, the companies that they were considering to rewrite their software. And now, since they had learned in the School of Hard Knocks, so to speak, what they had been missing, they were extra, how do I say, they really had their antenna up for noticing what things would pass regulatory scrutiny. So the use of BDD and TDD, those are highly documented actions and auditable pair programming as a way of reviewing code. You know, in short loops, blue fruit also had a blind hiring process that I haven't said anything about yet, but their hiring process screened first through online exercises, screened first for a person's ability to problem solve and to, you know, code. And so, you know, in other words, all of this was documented and could be, there was evidence contemporaneous to all these actions, you know, as somebody went through the hiring process, blue fruit could demonstrate. So all of these things served to show that blue fruit had a genuine bottom-up quality management system that could easily pass regulatory scrutiny. Next slide. Yeah, we go. But blue fruit then had another little hesitation of their own. They started to pull back a little bit. They started to think, well, geez, you know, if we get into this industry, do we really feel ready?  So how confident are we really? So they started to have this little feeling. And, but then they started looking at the code. The company showed them the code, you know, as part of their process of engaging with someone. And this is a quote from Paul. As they were looking at the code, he said, it kind of drew our team in. And so rather than feel anxious about that kind of responsibility, making sure that people couldn't come to harm if we get this wrong. It was more like, if we don't help these folks up, they're going to come to harm. Because they could see that, you know, there were issues with the code that just wouldn't happen when you're using test-driven development. Just wouldn't happen when you're using the various cucumber kind of tools and such. So in a funny way, it turned around their, their anxiety. They also had some concerns about getting into an industry that's known for being bureaucratic and slow and, you know, just lots of paperwork. But those issues melted away the more they got drawn in, as, you know, as the quote says here. So the teams felt they started to feel even more confident in their agile coding by looking at the contrast with what, you know, they would be replacing. And so they were pretty excited because they could really see what additional value they could create in this situation. So this was a boost for the morale. And, and I mentioned earlier, surprise benefits, one of my favorite topics. You know, another thing happening alongside of all this was their move to employee ownership. And of course they did a lot of looking ahead and a lot of, you know, testing the waters before they went. But it's funny how there are sometimes benefits no one expected. They just pop up anyway. And there were two of those. One of them is there being less chance that a competitor will buy a blue fruit software due to legal barriers to sell. You might ask, wait a minute, what's this? How is this a benefit? Well, let me say first how it works. Becoming an employee owned company. First of all, a decision to sell the company isn't just up to one person anymore, one owner. It's up to more than one person. So that's a little bit puts the brakes on a company being sold suddenly. Another reason is there are tax breaks in the way the legal system works in the UK. A company gets tax breaks when they go employee owned. And if they go private again, which you can do that, but you would have to pay back some amount of those tax breaks. So those things all turn to damp. They tend to dampen down the possibility of company will be sold. So why does that matter? Why is it a benefit to customers? Well, think about it. Let's say I'm a medical device company and I use blue fruit to build a couple of my products or their software. I might be hesitating to give blue fruit too big a chunk of my work because maybe they'll get sold to my competitor. And then all of a sudden I'll be heavily dependent on a competitor. So I might have been holding back. But now that I see they've gone employee owned and it's likely they're ever going to get bought. I might feel more free to give them a bigger chunk of work that I could give to them. And there's less chance of that competitor ceasing any support of the software that they've already developed for you. Yeah. And the other thing too is there without having outside shareholders, it means they don't need to build in an extra layer of costs that are there in order essentially to make sure that they don't have to build in an extra layer of money, dividends and profits to people who really aren't involved in generating value for the company. So those are a couple of benefits. They hadn't even anticipated and summing up here. Okay. I'm impressed by how this story has two principles of Agile really working in harmony, quality and empowerment. The company would was founded in order to do high quality work. It turned out very quickly that the best way to keep on doing high quality work is to keep empowerment. Alive every step of the way as the company grows and becomes more complex structurally just because it has to. This is part of the story that comes out in the case study as we tell in the book and we're telling today a tiny fraction of the story. So there's much more, but at every step of the growth, they needed to do things to really fight for and keep empowerment alive each step of the way. And so quality empowerment kept on this duality. All right, Brian, you want to sum up some more. So one of the key points that we've agreed upon and that that the book really shows is that blind copying was not any kind of a way to get to achieve an Agile process, rather use of basic principles. So the principles that we like to bring out about our different examples are collaboration based on trust. So many of the of the presentations at this conference have talked about various kinds of collaboration. Flexible planning. You saw in the open clinic, a case how they revisit their plan on a regular basis. Feedback loops. This this team, the group at this conference should should know all about feedback loops. And then the automation, the automation being monitored by a human to make sure that things are going right and that if something is wrong, that the line can be stopped. So our takeaways, each of the two cases we're talking about here have got some key takeaways. Open Clinica use a flexible planning approach to continuously update their roadmap. Their automation gave them both the multiple benefits not only of much more thorough testing of their multiple configurations, but also auditable documentation resulting naturally from the process and that their Agile process fed into fed information right into their expected quality processes like their corrective and preventive action. In the case of blue fruit software, their focus on quality really is what attracted the customers to them from the founding of the company doing high quality work in a positive environment. Their Agile practices all fit the quality management system concept. So it was easy for their clients to say, yeah, we can rely on these people. And even though they don't know what to do, they may not have gone through the whole process of getting the ISO 13-485 that ticket to hang from the wall, their quality process has attracted the clients whose non-conforming software had to be rewritten. That focus, as Nancy was just talking about, empowerment was absolutely baked into the overall culture of the company. And then becoming employee-owned pretty quickly because that's what we're talking about right now. We're talking about the fact that the company had to be baked into the overall culture of the company and then becoming employee-owned to preserve their Agile culture in the bottom-up commitment and that they had surprise benefits. I've been involved in cases where people had to... You want to say something? I just want to interject one more thing here. Blue fruit never did end up going and getting to be the certificate holder. And that makes those companies responsible to the regulatory bodies to make sure that any software they subcontract is also in line with the demands of the certifications. So they still are operating in that way. Just let me give a quick update. Well taken point in the regulated medical industry. Anybody who outsources parts of their work is responsible to review the quality processes of their vendors to make sure their vendors are doing quality work. So that was an important point. And the item about long-term support of code, I've been involved in cases where people had actually decided to escrow force the supplier to escrow the code being... That was developed in case that company that did the development ever went out of business or was bought and the software was not going to be supported any longer. In Blue Fruit's case, because their employee owned, there's a lot less chance of just the company disappearing tomorrow. So summing all of these things up is that understanding the principles is important but not sufficient. Understanding the context, how what's being developed and who's being served is important but not sufficient. That the practices that are being chosen have to realize a particular principle in a particular context. I like to use the image of choosing the right tool for the job, Ergo, the illustration here. You support a particular principle in a particular situation. So here's our services. We overlap but do different kinds of things. And distance is really not an issue for the people that we work with. And here's our contact information. So we'd be happy to take any questions at this point. Could you please give an example of a user story?  Nancy, you want to try that one? Sure. I mean, in embedded systems, a lot of times the user stories are very down in the tech. So as you're just starting to get going with some things that are down in the electronics, they can look like any other embedded system, things like bringing up flash memory or bringing up a display panel on a circuit board, things of that nature are possible, but things that are more customer facing might be things like verify patient identification, a screen for that, you know, or various types of screens that a practitioner would use as they're working with a device. You'll have stories around those things as development proceeds a little further. So we tend not to write stories that are whole giant features because they're just too big.  Some people say, no, no, you shouldn't have those. But I mean, you do have to have an overall concept, but I tend not to get people wrapped up in writing stories that are very large features that I know are going to only emerge over quite a few sprints. And in the case of the folks at OpenClinica, their kinds of user stories might read, given trial, thus and such and so forth, has been set up and that the patient is in the second visit of the sequence and that certain other edit checks are in place when I enter the such and such piece of information given when then the system shall skip over the following question because the question is not relevant. That's the kind of user story that, and they may have a given with a whole bunch of ads attached to it because the situation can be very, very specific. But that's why using the Gherkin notation is very, very powerful for them because they can specify right down to the exact thing that they want to have happen. Yeah, did that answer your question? Let's see if I can see what's going on in the chat. Hope that it, oh, okay, he says yes. Thank you. I'm glad that answered your question. Thank you, Nancy and by Nadine. Okay, super.


Hey everybody, thank you for coming today to the Talk About Security Champions, the what, why, and how. I'm Ann Marie Fred. I'm a Senior Principal Software Engineer at Red Hat, and I have a little bit of information about myself to start. I have more than 20 years of software development experience, more than 10 years of working in a DevOps field. I was a DevOps Days Raleigh Conference Co-Organizer for three years. I'm also active in the Linux Foundation and CD Foundation, a couple open source projects. I was HR Manager for three years, and for the last four years I've been acting as a security focal. And you also see I was at IBM until a year ago, so some of the stories are from there. Brief disclaimer, these are my experiences, not the official position of my current or former employer. So according to former FBI Director Robert Mueller, there are only two types of companies. Those that have been hacked and those that will be. In fact, according to the Sonatype DevSecOps Community Survey, 24% of organizations either suspected or had verified a security breach in the past 12 months. And most of those breaches target data. And data breaches are very expensive. For one, GDPR and other privacy regulations hold companies liable for security breaches. Stop working, yeah, just stop working. Ignorance is not a defense. Yeah, sorry, the microphone broke. Is that better? Okay, all right, so ignorance is not a defense from liability and this can cause major damage to a company's reputation if you think about high profile data breaches at places like Facebook, Equifax, LinkedIn, Anthem. Was anybody here affected by any of those data breaches? A couple, yeah, a couple, I was too. Really obnoxious. In fact, on average, a data breach, according to IBM's 2021 cost of a data breach report, costs $4.24 million to repair. And in 2021, there were over 18,000 CVE vulnerabilities disclosed and at least 66 zero-day vulnerabilities. So on average, more than one every week. More bad news, the time between a vulnerability being announced and the exploits appearing in the wild used to be 45 days and that is compressed by 93% over the last decade to only three days and that's according to research by Sonotype and Derek Weeks. Which means it's a race and the only way to win it is that we need continuous security. And what if we're cloud native? Well, in cloud native computing, generally you're going to expose your services via APIs as soon as possible. But that means we need to secure them from day one because if your service is on the internet, it's exposed to attackers as well. A big part of securing things from day one is knowing how to scan the software and then interpret the results of the scans and then fix it using static application security testing, dynamic application security testing and so on and so forth. For example, cross-site scripting vulnerabilities are very common. They're easily detected by scanning tools and they're easy to fix if you know what to look for. Another thing about CICD is that that moves the bottleneck from the release schedule to the developers. If you can release a fix within a couple of days, now it's the developers who are slowing you down all of a sudden. And what if we're using open source software? Well, open source is great because it accelerates development but it also brings with it a host of publicly disclosed known vulnerabilities. And security researchers are using their automated scanning and detection tools to scan those open source packages and report the vulnerabilities. But bad actors have the same tools and they can find them as well. Maybe before they're fixed. In fact, comparing 2020 versus 2019, which is the last time this research came out, there were 50% more vulnerabilities that year than the prior year and we've seen this trend continue. The log for J log for shell vulnerability is a great example and a typical example of an open source vulnerability. So log for J was a trusted open source library. Nobody had any reason to suspect that it would be a problem. It's used by most Java code. It's used in hundreds of millions of devices. In 60% of the software projects, it's used indirectly. So if you have your package list, you won't see log for J there. It'll be a dependency of one of your dependencies. And this log for shell vulnerability is allows arbitrary code execution exploited over the internet without authentication which makes it the holy grail of exploits. But so how have we done with fixing this, right? Well, if you look at that graph, you'll see like there's some blue lines that dropped on quickly. Those are the companies that were on top of it and they fixed things quickly. But if you see the red chunk there, 33% of Maven downloads are still vulnerable versions of log for J. That's horrible. So 33% of things that are being actively built and deployed are still vulnerable. How does this happen? Well, according to Tony Irvine and secure delivery, for every 100 developers, there's only one security professional. And because of this, security is often neglected. It's treated as a last minute gate. So maybe two months before you try to ship something for the first time. You'll do some threat models. You'll do some manual penetration testing. The software development teams will have a couple of weeks to fix vulnerabilities. They probably won't fix all of them. And then because you have a committed delivery, they ship it. That's what happens. So the fact is that a tiny cybersecurity team can't find and fix vulnerabilities within three days. They need help. And to move faster while being more secure, we have to up our game. We have to make our technical teams more self-sufficient with respect to cybersecurity. And that means we need to scale up the number of application security subject matter experts from about 1% to about 10% of our technical population. And these are people who are gonna be qualified to dig into the details of security reports and security tool findings. So what do I mean by security champions? What I mean is one person, one management designated person per small team or squad. It's roughly a 25% time commitment. Some weeks it might be an hour or two. Some weeks like during threat modeling, it might be full time. It's at least one-tenth of your development population and there I'm including developers, architects, testers, SREs. You wanna have champions across these disciplines. And we're gonna give them maybe 10 or 15 hours of additional application security training.  Why do we need them? One professional per 100 developers leaves those cybersecurity professionals spread too thin. And the people closest to the code are the ones who are best equipped to keep it secure if they have some basic security trainings like classic shift left. It's also a great way to promote a DevSecOps culture where the developers have control and responsibility for their own application security. There's a playbook for how to start a security champions program. First of all, you're gonna need a small working group. We're talking maybe three to five people, just a handful. You can ask for volunteers, people who are excited about learning more and bringing more security knowledge into the organization.  And then you can use that description to shop it around to management and executives and get their buy-in so they know what they're signing up for. Your group will also need to choose a training plan and pay for it and set a due date for the training. And then you're gonna have to have the managers appoint a designated security champion for each of your small teams or squads. And then your working group can also set up communications channels like instant messaging and email and meetings. And finally kick off the program. I have more details and backup slides, by the way, this is the short version, right? But yeah, it's about 10 to 15 hours of training that we want. We're gonna make sure that we've covered cybersecurity basics, which really everyone in the company should be getting, like how to have good passwords and how to store them securely. Security and privacy for developers 101, security and privacy by design. You're gonna wanna definitely include OWASP, top 10, SAMS 25, top 25, training maybe four or five hours on how to recognize and find and fix the vulnerabilities. And I also like to include an hour or two on the basics of threat modeling. It's not enough for these people to go run threat modeling exercises like a qualified security architect would do, but it's enough for them to help a security architect do a better job. And it's enough for them to help keep the threat model up to date over time. And I have some examples of ones that are good in the backups as well. Also it's important to have an interlock meeting. So we set up a secure engineering guild and we expect our security champions and security focals to attend or at least watch the recording if they can't make it. Obviously you wanna have a good agenda in minutes. And some topics we've included recently are like status, corporate initiatives and security alerts, security tools and how people are doing with adoption, tips and tricks for that, pen testing and remediation and how that's going. Interesting security stories in the news and when we can five or 10 minutes of education on something very timely. Like right now my group is filling out new security surveys. So we've walked through these surveys together so people could ask questions. So what does it look like when this works? Well at IBM Digital, after 12 months of this program we did have 10% of our developers who finished the training program and became subject matter experts. We also saw that critical security alerts if we call CISO overrides were often able to be handled within one to three days. And that's from the time that corporate cybersecurity sends the alert to the security focals. They fan it out to the champions. They go to their applications and see if they can find the problem. They report back, they fix it if there's a patch available and they report the status all the way back up the chain. So accomplishing that within one to three days is pretty great. Importantly to me, I knew that no teams were following through the cracks. So in my organization of like, I don't know, a dozen-ish teams, we had like 130 applications and two dozen security champions. And I knew that when I sent out alert all those were being covered. We also had far fewer security reports that were marked as false alert or could not reproduce, which is developer speak for, I don't know what to do with this. Our developers also uncover new vulnerabilities on their own. So as they're going through the training classes, they're thinking in their head, oh, I think my application might have this use case.  We saw broader adoption of threat modeling. Our teams are reaching out to the security architects asking to run threat models and teams are thinking about security every week. And just three months in, at Red Hat Developer Tools, already we have the secure engineering guild meeting every week. We have a dozen security champions that cover 16 small teams and we're working on pulling in the other half. We have our training funded. We're about to kick it off. They've already done five threat models. They got two more in progress and several more scheduled in the next month. And they've updated dozens of security assessments and data privacy assessments in the last two months. So key takeaways. Security champions program is straightforward and repeatable. You can do it. But you're gonna need management support. You're gonna need a few dedicated, excited people, few months to get the program started. You'll need that funding for the online training or if you already have a corporate training program, you might already have modules in there that you can chain together into a plan. That's what I was able to do at IBM. And at Red Hat we already had a program. I just had to get more funding for another year. Of course you're gonna need your management to designate that one security champion per team. And you'll need one or two secure engineering guild leads per org. Usually this is more like a security architect or a security focal. Somebody to keep that cadence going with the team. Thank you. It's a lightning talk, very fast. But if you'd like, you can reach out to me on Twitter or LinkedIn here. And I'm also have a moment for questions if anybody wants to ask one. Okay, question? Yeah. I think everybody can know enough about security to handle their sphere, right? So a small team is usually what? Five to 10 developers. And they know their application really well. So they just get enough security training to recognize the potential holes in their own code and fix them. Become a security expert. Is a special mindset, a special background education, or what do you think? I think it's mostly curiosity. So in fact, usually we don't ask them to be technically as necessarily, because those people get pulled into meetings all the time and sometimes they just want to write code. So ideally it's somebody who volunteers for the team and it can actually be a more junior member of the team as long as they're interested in doing that training program and learning about it. We also find that people will continue, so some percentage of the people will do more than that 10 or 15 hours and they'll keep going. Right, so you're like that one in 100, right? I'm teaching students and I went for this time with more than three natural dollars. I think, so in our org, I think we had like 75ish developers each time, right? We got a dozen or well 10 to 20 people identified as security champions. Of those maybe four or five will be super excited, but that's enough to keep the program alive and functioning, so thank you.


When President Biden took office, the deficit over the next 10 years was expected to be about $12.2 trillion thanks to a boatload of new spending approved during Biden's first year that's climbed to $14.5 trillion. One way or another that shortfall has to be accounted for by cutting spending, raising taxes, or printing money. So what does the new Inflation Reduction Act do to address the problem? It doesn't cut unnecessary spending or wasteful government programs, it raises taxes. And those tax increases will only reduce the deficit by about $300 billion, or 2% of planned borrowing over the next 10 years. In other words, even assuming no new spending, we'd still need about 50 more bills just like this one to not add any more debt in the next decade. And the bill doesn't do anything to reduce the $30 trillion in debt we've already accumulated.


Attention five points residents. This is a community notification of a new sexually violent predator in your area. Please stay tuned to the following short program for more information. Hi I'm technician Ron Hackett with the Denver Police Department. The sex offender registration and compliance unit at DPD is responsible for the registration monitoring and tracking of all registered sex offenders and sexually violent predators who live in the city and county of Denver. Here's a brief history of sex offender legislation in Colorado. Our state laws trickle down from federal government mandates. In 1994 we had the Jacob Wetterling Act which mandated that states would establish a sex offender list. Megan's law of 1996 said that the public would have access to those sex offender registration lists. The Pam Litchner Act of 1996 stated that some offenders might have to have lifetime registrations and the Adam Walsh Act of 2006 unified sex offender laws across the country. In Colorado the legislature has determined that sexually violent predators by definition pose a higher risk to the community at large and therefore mandated that upon their release from the Department of Corrections the community must be notified. Sex offender notification in Colorado happens in two ways. The first is passive and ongoing through the sex offender registration process which is a list maintained by local police departments. The second way is active via community notification for those offenders determined to be sexually violent predators by the courts or by the parole board. Most sex offenders in Colorado are supervised by the criminal justice system in our communities. Most sex offenders engage in crossover behavior which means they may have been arrested for one type of crime but be apt to commit another.  There is no typical sex offender but all tend to be deceptive, manipulative and secretive. 80 to 93% of sex offenses are committed by someone known to the victim. Sexual deviancy begins in mid to late adolescence. Sex offenses are not impulsive.  The community has a vested interest in helping offenders to be successfully managed in the community. Sex offenders have the same need for housing and employment as any other citizen.  There are approximately 16,500 registered sex offenders in the state of Colorado. About 65% of convicted sex offenders are placed in the community on probation. The remainder are in the Department of Corrections or Community Corrections. Offenders may be caught for one type of offense but be at a high risk to commit another type. Crime of conviction is only one indicator of risk.  The offender's residents must be verified quarterly by the Denver Police Department. The full sex offender registration list is available by calling the Denver Police Department Identification Bureau at<PHONE_NUMBER>. Convicted felons and those with multiple convictions are posted online at denvergov.org slash police.   Now, here's a look at the newest sexually violent predator living in Denver. Here's an overview of the registered sex offenders currently living in Denver. There are 2,388 total living within city limits. In Denver Police District 6, there are 410. Precinct 612 has 142 registered sex offenders. Of those, 113 have felony convictions and 29 have misdemeanor convictions. Tommy Corral Mendoza is a sexually violent predator currently living in Denver. He's 57 years old and was born on July 8, 1965. He's a Hispanic male five feet eight inches tall, 230 pounds with gray hair and brown eyes. He's currently living as a transient in the 1900 block of 29th Street and the Five Points neighborhood of Denver. Schools located within one mile of this offender include University Prep School at 2409 Arapahoe Street, Coal Arts and Science Academy at 3240 Humboldt Street, Gilliam School at 2844 Downing Street, Coal Middle School at 1350 East 33rd Avenue, Garden Place Academy at 4425 Lincoln Street, Gilpin Montessori at 2949 California Street, Annunciation Catholic School at 3536 Lafayette Street, Montessori Academy of Colorado at 2500 Curtis Street. Parks located within one mile of this offender include Globeville Landing Park, Curtis Park, Morrison Park, Williams Park, Ciencio Park, Columbus Park, Franco Park, Community Plaza Park, Highland Gateway Park, Sonny Lawson Park, Denver Skate Park, Cuernavaca Park, Stout Street Children's Park, Myastas Park, Commons Park, St. Patrick's Neighborhood Park, St. Charles Place Park, Quick Park. Recreation centers located within one mile of this offender include Globeville Rec Center at 4496 Grant Street, St. Charles Rec Center at 3777 Lafayette Street, Glenarm Rec Center at 2800 Glenarm Place, 20th Street Rec Center at 1011 20th Street. Bus routes located within one mile of this offender include Route 48 Broadway and Lawrence, Route 12 64th and Washington, Route 44 44th and Kipling.  He's currently on parole and registered with the Denver Police Department on April 18th 2023 as a transient living in the 1900 block of 29th Street in the Five Points neighborhood of Denver.  Tommy Corral Mendoza has been determined a sexually violent predator after meeting the following criteria. Criteria one, age 18 or older on the date of the offense or under 18 and tried as an adult. The offender was age 19 at the time of the offense. Criteria two, the crime must have been committed honor after July 1st 1997 and convicted honor after July 1st 1999.  The offender was convicted on June 6th 2008 for attempted sexual assault on a child. Criteria three, the relationship to the victim was one of the following. Victim was a stranger to the offender or the offender established or promoted a relationship with the victim primarily for the purpose of sexual victimization. The victim was a 13 year old female. The offender was known to the victim. Criteria four, positive results or the passing of a risk assessment instrument administered by probation parole staff and a qualified treatment evaluator. Positive results include an assessment for the presence of a mental abnormality, a level of denial regarding the offense, treatment appropriateness and motivation, presence of sexual deviant interests.


Aloha, Hawaii. I'm Wendy Lo, and I'm your new friend as we journey to take your health back. We are coming to you live from downtown Honolulu, from the studios of Think Tech, Hawaii. Today our topic of discussion will be on powering over diabetes. So let's stop and let's take diabetes back and conquer it together, because together we can. But I'd like to introduce you and welcome Laurence Duenis, or as we know you as LJ. Around town, we call you LJ, it's much easier. He is the director for Hawaii for the American Diabetes Association. Welcome. Thank you. And we'd like to welcome Doug Park. And Doug Park is also with the American Diabetes, but from the volunteer point of view, I believe you're one of the lead volunteers of the American Diabetes Association. And you're also a cyclist extraordinaire. Is that correct? Yes. Yes. Welcome aboard, gentlemen. So let's begin. How does diabetes affect us here in Hawaii? And can you share a few statistics with us? Sure, Wendy. And first of all, thank you for the opportunity to be here and talk to your audience about diabetes. Very good. Thank you. In Hawaii, every day, about 21 people are diagnosed with diabetes. This has become an epidemic. When we look at statistics, about half of our population, or over half of the population, 600,000 to be exact, are affected by prediabetes or diabetes. And when we look at that, that's about one in every two people in our state. But why is that? The ADA is looking at research and results to identify why certain populations in the community are more affected by diabetes or predisposed to the risk factors. When we also look at complications of diabetes, we know that heart disease is and continues to be the number one killer in the United States, as well as in Hawaii. But when you look at diabetes and heart disease, diabetes by itself is the strongest risk factor for heart disease. So if we can control diabetes, we can control heart disease, essentially controlling deaths associated with heart, heart disease and diabetes. Other than heart disease, other complications include kidney disease, a vision loss, stroke, and also lower limb amputations. In fact, 98% of all non-traumatic lower limb amputations is affiliated with diabetes. In addition to all of that, there are economic burdens that people with diabetes are affected by. In our state, we spend about $1.5 billion a year to care for diabetes. It's expensive to have diabetes. We see that many people can afford to pay for their medication and their test strips or other devices used to treat or manage their condition. So if we are able to come together and find ways to prevent what we can prevent and manage what we can manage well, we can definitely bring down the burden that diabetes has put on our community. Wow.  One of two will be diabetic in the state of Hawaii. That's terrible. What kind of cost are we looking at, you know, running, taking care of all the diabetics here in Hawaii? Well, when we look at just insurance cost, a person with diabetes, their cost for medical and other types of insurance-related expenses is about 2.3 times more than a person without diabetes. So that roughly could be estimated about $14,000 a year. And so you look at that and you look at what our employers contribute to insurance coverage. It's a big toll on many of our employer groups in our community, in our Medicaid and Medicare population, and also because there are co-pays involved in these types of insurance claims that many people with diabetes are out. Wow. And that's why we have a lot of different events going around raising monies so that we can raise awareness. And I'd like to draw some attention to Doug. He's number one ADA volunteer extraordinaire. I always say that because wherever there's a diabetes, stop diabetes sign, there's Doug.    I mean, you are the role model of a volunteer. And I just hope that when you go out, others can get contagious with what you give and give as much as you do. So in layman's term, tell us a little bit about what is diabetes? Well, basically, when the diabetes, and I'll just kind of read from a statement here, it covers, of course, the area that bothers or affects a lot of people is the pancreas. It's a major gland. And it's part of both your digestive and endocrine system. It makes digestive enzymes that breaks down foods that you eat. It also makes the hormones insulin and glucagon. I'm using all these terms, of course. But anyway, these help ensure that you get the right amount of sugar in your bloodstream and in your cells. If you don't make any insulin, which is the case for many people who are type one diabetics, your blood sugar levels can be very dangerously high. In type two diabetes, the pancreas usually makes some insulin, but not enough. And there's also a third type, basically, and it's gestational. And it affects women that are who become pregnant. And usually in the second trimester, that's when they're affected. And people, women who are usually with children already, there's usually the second child that's affected. You know, Doug, I know you did have to read it from the paper because you are so experienced with all of this, the symptoms and the effects. I understand that you are a diabetic. Yes, I am. So you have experienced diabetes type two? Yes. Can you share with us today that you were diagnosed with diabetes type two? Well, to be frank, I'll tell you, I can't really fully remember because I'll tell you, I've been a diabetic for 48 years. Wow. And because of that, I can only tell you that vaguely, I can say that my doctor when he first, and this is my third doctor I've already lived through. And he probably told me, well, you got diabetes and, you know, you better start taking care of yourself. But being young, et cetera, I didn't pay very much attention to it until much later in life, unfortunately. But that's basically what happened probably 48 years ago. So that means you're in your teens at that time? Yeah. Well, I wish I could say that. But thank you very much. But unfortunately, I was 28 or 29 at that time. And so Doug, when you were diagnosed, what did you do?  I've got to do this. I've got to do that. What was running through your mind at that time? Well, to be honest, I treated like any other day in my life back then, being a little younger and not as wary of what diabetes has been doing to a lot of people's lives as much as it is today. So I would have to say that, frankly, I took it as another day in my life and just went about living and doing things normally, which in retrospect is not what I should have been doing. But having said all of that, we are where we are today. So is that part of your mission, the ones that are being diagnosed to get them information and huddle around them so that they be more proactive and not let time go by with not addressing the issues? Yes. I think the key word here is education. And that's where many of us are involved with the diabetes programs, that we need to try to educate as many people as we can. And that's the challenge of today in many cases. So from the time you were diagnosed to the time you really were proactive on your lifestyle change, there was a period of time. Did you experience any complications during that time? Yes. I would have to admit that there was a period about 15 years ago when it started to really affect me. And I had to make some drastic changes in my lifestyle. And that woke me up to what I needed to do with my doctor's approval of course and support, medication changes, changing the way I ate and putting the nutrition into my system. And but one thing good about the whole thing that I was doing is that fortunately I was very actively involved, not only in the community but in sports. So that kind of helped me and actually delayed some of the effects that normally most people would be affected by. So it was a benefit by exercising and being out there and training. So that kind of helped delayed it for me. Wow. So you've touched on some very key points, you know, awareness, you know, education, and then being physical, doing something about it. Even unintentionally, you were just living that lifestyle.  Yes, absolutely. And so if you don't mind, what are some complications that you did face related to diabetes? Well, I'm not the normal case. Unfortunately, even more so, although there's a tremendous amount of passion in me to make some changes for a lot in helping a lot of people. But the major changes that affected me is that in changing my lifestyle, I found out that of course nutrition, one of the major areas, I had to make some changes. And that's of course eating the right foods and balancing your meals. I guess portion control is one word comes in mind that many people may not fully understand, but something I live daily, as well as eating three square meals a day, which for a diabetic is very important. And also taking medication. Daily is something that a lot of diabetics forget sometimes that they need to take their medication. They're so busy with their lifestyles that they get wrapped up in doing so many different things. But having said all of that, the major things that affected me were physical also. I had some major operations of a lifestyle that I think relied the fact of what I should be doing. I didn't do. And it affected me that way physically. I had some major operations, as I said. And that changed me also. When I woke up one day after that major operation, I made a promise to myself that I needed to make some changes. And that was to not only my lifestyle, but to do as much as I can to help others with diabetes. Well, you've got a lot of history, 40 years in the making. So when you were diagnosed with diabetes till now, what are the major changes you feel as far as managing your diabetes? Well, number one is education again. And it comes back to not only my beginning to educate myself, and that's what started me on the right track, but educating others, of course. The educational benefits I learned along the way is the outreach programs and being able to speak to doctors who have a lot more knowledge than I did at the time. And based on that, I started to learn a lot more of my condition, what needed to be done. And the fact that diabetes is a recent illness, really, when you look at it was discovered in 1969 only. So that tells you that it's a recent illness when you compare it to the rest of the world as far as history. But all of that comes back down to, again, the word education. It's educating yourself and getting to how to improve your lifestyle and doing so much more for yourself.  So how do you feel? How do you personally feel living with diabetes? I feel really great. I've been, actually, I can't really speak for others, but speaking for myself, my life every day that I wake up is a thankful moment because compared to many others who have challenges more than I do, compared to my age, I am way ahead of the game and very fortunate and very blessed that I'm here today to be able to speak about diabetes even. And that's one of the telling points of my wanting to do as much as I can for others.    I mean, we called you to do this interview with us and you're Johnny on the spot without hesitation because your heart says, I need to get the word out and every opportunity we can, we need to reach the people out there. Absolutely. Yes. So education, the takeaway right now is just again, again and again, education, education, education. And the more that we can get volunteers and staff members of ADA out to share this information, you know what, we're going to beat this. And that's our goal is to find the cure for diabetes. Right. So at this time, we're going to take a short break. And I just want to say thank you, Mahalo, both of you for just sharing your heart and your wealth of knowledge with us. And when we return, we're going to continue on different issues of diabetes. So stay tuned and we'll be right back. Good morning. I'm Andrea Gabriele. I'm the host for Young Talent's Making Way here on Think Tech, Hawaii. We talk every Tuesday at 11 a.m. about things that matters to tech, matter to science, to the people of Hawaii, with some extraordinary guests, the students of our schools who are participating in science field. So Young Talent's Making Way every Tuesday at 11 a.m. only on Think Tech, Hawaii. Mahalo. Aloha, everybody. Here we are at Think Tech, Hawaii. And we're visiting with LJ from the American Diabetes Association and with Doug Park, volunteer extraordinaire. And Doug was just sharing with us his heart of how he, you know, his life was saved through a lot of knowledge. But when he was diagnosed with diabetes, he did an act on it right away. He took a few years in between to proactively work on the quality of life that he enjoys now. And so with that, the takeaway for us is education, education. And then when you receive it, share it out. And that's exactly what both of you are doing right now.  But there's a lot of complications around diabetes. And so with that, I'm going to ask LJ, who is from the American Diabetes Association office. He's our local representative. And by the way, I got to throw a shout out, ADA of Hawaii. As we mentioned earlier in the show, there's about over 600,000 diabetes, diabetics here in Hawaii. And if you go to their office or when you go to their office, there are three live bodies in their office, surrounded with one or two interns and powerful volunteers like Doug. And there are so many in that office that come together. But a shout out to LJ, to Danielle and to Robin and go around interns, but really just mahalo for their love and their commitment to stopping diabetes and just bringing awareness to the people of Hawaii. So LJ, would you like to share with us a little bit about some of the complications around diabetes? Sure. Again, thank you, Wendy, for those kind words. And also, we thank you for all that you do as a volunteer and also as a board member. So thank you. So just to, just to share a little bit about some of the complications, serious complications people with diabetes face, these complications include heart disease, stroke, lower limb amputation, kidney disease, among other things, and including vision loss. Fortunately, though, these complications in recent years has dramatically decreased more so because of ADA's yearly updates on our standards of care. Basically, what this is, it's like a car manual. It tells you what to do if this is what's wrong, giving physicians and other healthcare professionals an algorithm or a system of care approach when working with people with diabetes. And so we've seen dramatic decreases in heart disease, like I said earlier, which is our number one killer in Hawaii and the United States. So it's important that people understand that we not only go out in the community and educate on diabetes, but we're also behind the scenes turning research from science labs into translational medicine where we can share with physicians and other healthcare professionals. And some of the latest and greatest results from research projects across the country and also across the world. It's important that we talk about these complications because our mission is one to prevent and cure diabetes and to improve the lives of all people affected by diabetes. And that's what we do is we work to improve. We work to make sure people can thrive and make sure that they know where to look for support until we are able to find that cure. Of course, the cure right now is prevention, but there are instances where we can't prevent diabetes. That one diabetes cannot be prevented. We don't know what causes it. And so there's research that looks at meal plans or diets, beta cell or eyelid replacements, the artificial pancreas. So these are things that we're invested in, along with other research partners in the diabetes sphere. We find opportunities in challenges. These opportunities are one that there are people with prediabetes. And what this means is that we have an opportunity to educate, reach and turn people with prediabetes into people who had prediabetes. So giving them the resources that they need to be able to make better decisions when they are able to so that they can delay or prevent the onset of type 2 diabetes. You know, I'd like to interject. I honestly, being a local girl from Miley, I didn't have any concept of diabetes. The people around me weren't diabetic, so I wasn't in that world. Mine was more heart related and cancer. But diabetes, I didn't know much about it. When I was asked to sit on the board of directors for ADA, I said, why me? And I scratched my head. I didn't know anything about it. But that was why they chose me, because they could, from scratch, teach me and share with me their heart so my heart would be open to others as I learned and educated myself. Now I'm so passionate about this issue that I'm never going to step from the down from the board unless you kick me off. But you know, just the whole idea and you talk about prediabetes. I mean, myself, I used to own a chocolate factory. So I ate chocolate every day like it was going on a style. And so now, as I'm retired, I make better health choices because of what I learned through dog, through all of you at the office and just being out there at all the different presentations. It does matter. And we can take it into our hands and it can help towards, from prediabetes going to the next level. So I say no to that. So I'm learning and learning and I keep listening to everyone so that I won't be calm. So I thank you for all that knowledge and information, but please share with us how more can the people of Hawaii not, I mean, be more like me prevention and work on that part. Well, you know, just going back to, like I mentioned, we find opportunities in these challenges, right? We also know that many people are interested in diabetes. We have great volunteers like Doug, volunteers from the Hawaii Alliance Club. We have health systems and federally qualified health centers really vested or invested in diabetes and supporting people at risk. We also know that technology in diabetes treatment and management has been amazing in just a few years. You know, I've been a part of the American Diabetes Association. I've seen so many great innovations, including the external artificial pancreas or a continuous glucose monitor that replaces finger sticks. These are ways that we are working to improve the lives of people with diabetes. More so, these are devices that people with type one diabetes would be best candidates for, but there's opportunities here for even people with type two diabetes to benefit from. So, you know, it's a good time to have diabetes because there's so much support out there, but still it's going to be a better time when we find a cure. For sure. And, you know, LJ, what are other initiatives that the ADA leads to combat diabetes? Sure. So, you know, we do a lot in the community. Yes, you do. We work with employer groups to bring health and wellness into the workplace. Reason being is that we have a captive audience and we have support from corporate executives in these types of initiatives. We also know that community involvement in health is important. We partnered with restaurant chains in recent years to provide a healthier option menu for their customers with a restaurant train of 24 stores. That's amazing. Right. You know, that's a great way. And we appreciate all that they step up to support us with. It gives people with diabetes and pre-diabetes the option to choose healthier. We also have a program that is upcoming, which is our Hawaii camp program for kids with type one diabetes. Yes. And so happy to bring that back to Hawaii. We are so excited to hear about that, LJ. So, what it is, is basically the children with diabetes can come together and hang out for a few days in a camp, in a secure, safe environment with all the right physicians around us so that they can come and say, you know, have a good time with each other, versus, why me? Why me? They can say, hey, you too. You know, and let's combat this together. Let's support each other through this journey versus them being all alone one by one. So, tell us more about that, the camp upcoming. Sure. So, we are looking to host the camp from Saturday, or I'm sorry, Friday, November 9th through Sunday, November 11th at the YMCA camp Erdman. Again, it's for children with type one diabetes. And you said it perfectly. It's an opportunity for kids affected by type one diabetes to come together, create lifelong friendships, because the best support that these kids and families will have is each other. So, you know, I know we talked about lifestyle and we talked about all the solutions that are going behind, which is education and all of that. Is there a healthier diet for a diabetic or someone who's just diagnosed with diabetes? You know, I'll let Doug interject in a little bit, but what we, ADA, we focus on sharing with our customers a diet. We don't like to use the word diet. Creating a meal plan that's going to work for you. We see plant-based diet working very well for people with diabetes. We see very low-carb diet working very well for people with diabetes, but also for people without diabetes. And so, it's really in moderation what will work for you and something that's sustainable, because if it's non-sustainable, it's not going to work for you. Doug, would you like to add something in there because you're living it? Well, you know, basically, Wendy, I think in, I guess, follow up with what LJ has said right now. And, you know, it comes down to meal planning. And if a person can set aside during the week looking at their schedule and to see how their shopping will be, the foods that they have to buy for their meals, that in a sense already is a step in the right direction, they're planning ahead. And in doing so, knowing, realizing that we're talking about a couple of areas of importance, which is number one is portion control. And that helps them with their planning already. And of course, making sure that moderation is another keyword that is followed, so that the meals that they plant for themselves are quite balanced. And they don't really have to go on a strict diet. No one really has to go on a strict diet regarding diabetes. But what they need to do is moderate and enjoy the foods they eat well and basically that's healthy for their system. We don't like the word denial, because that really causes a problem for most people. And the other one, of course, is acceptance. Accepting that you need to do certain things besides the food that you eat, of course, is taking your medication during those hours that you should be and with meals. So the nutrition and the medication goes hand in hand. So that's where food comes into play, definitely. All right. So that's, I mean, there's a lot of great takeaways from today. A lot of great takeaways on portion control, eat and moderation, exercise, the right diet for you, and lots of water and sleep, of course. So at this time, and oh, before we stop, I wanted to say, you know, this apple. So like the doctor says, right, in apple day keeps the doctor away. So this is part of your diet, right? You're eating more of this and just making better right choice, diet choices for yourself. So at this time, I just want to say mahalo to both of you for doing such a great job. The people of Hawaii appreciate you that you are here live and present. We have an office here and give us your website and your phone number, LJ. Sure. Our website is diabetes.org slash Hawaii. You can also call us at<PHONE_NUMBER>. So I just want to say mahalo to both of you gentlemen. And you know, we're going to work on this and we're going to, you know, we're going to let's stop diabetes together because together we can and that's the only way we can do it if we all join together and take healthy back. And that's what we want to do. And this is what this show is all about, taking health back into your hands and take health back. So please join us every other Tuesday at two o'clock as we talk about different aspects of health. Health being overall wellness and just being aware of what your body needs and how we can best manage it. And a lot of joy and happiness of course matters. So for now until next week, Tuesday, aloha from ThinkTech Ba'i.