Proving Hospital AI Is Secure

Chris Hutchins (00:19) Every AI vendor says its system is secure. A hospital has to answer a harder question though. Can you prove it? Can you show what data entered the system, what changed, which controls ran, who approved the release, and whether the model that reached production is the model that you evaluated. And healthcare trust is not a slogan. It has to survive an incident, an audit, and a regulator. and I'm excited to come to you today with a fantastic guest. His name is Vasanth Mudavatu, a senior principal software engineer working across generative AI, machine learning, and application security products at Dell Technologies. He's joining us in his personal capacity, and the views he shares are his own. Vasanth writes about building security and compliance evidence into the delivery pipeline itself. And today we're translating that across enterprise security and really trying to answer the questions that health systems actually do have to answer. But how can a health system prove that clinical AI can be trusted with patient data and high consequences where workflows are absolutely critical? Vasanth, welcome to the Signal Room.

Vasanth Mudavatu (01:25) Thank you so much Chris. It was nice meeting you.

Chris Hutchins (01:27) So tell me a little bit about yourself and what kind of led you down the pathway to now you're dealing with AI in the healthcare space and why is it healthcare?

Vasanth Mudavatu (01:35) Absolutely. so I've been in the IT industry for about 20 years now. So I worked for Pfizer, Pfizer pharmaceutical company. So I've been there for a few number of years there. So I can understand what it goes through behind the scenes, right? in terms of I was involved in healthcare company migration, It's a ChapStick, I believe. I think it's still around. So Pfizer got that ChapStick. and I that's how I got into that project. So I'm using Pfizer, but I'm not representing Pfizer at the moment. but that's my experience working in the healthcare industry. I was there for about six, seven years now. and on top of it, I've been with many Fortune 500 companies. But my current focus is on developing and deploying high impactful AI solutions, which are primarily aimed at safeguarding and preempting the Gen AI or machine learning applications from potential threats. So I focus a lot on enhancing data quality, data integrity, and how can you maximize the efficiency of the systems and eventually improve the return on the investment.

Chris Hutchins (02:55) How does the question can we trust this system change? And what evidence should a the health system demand before allowing an AI tool near PHI?

Vasanth Mudavatu (03:04) yeah, absolutely. I mean, this is definitely a burning problem. How can you trust AI? But especially in terms of the PHI, right? It's even more critical. So most health systems they secure the pipeline, right? but to leave the engine unguarded. Right. So what I mean is the pipeline is the infrastructure. Right. So most people they get confused between the infrastructure security versus the AI security. The AI security is more focused on the model security itself. Right. so the clinical AI security must govern data inside the inference loop itself. So the what do you mean by inference loop is that's where the patient context, the reasoning of clinical decisions. and the raw PHI data, they come together. So you need to implement the security and governance around that data. You protect the pipeline, which is requesting prompt engineering requesting a prompt and then response, that isn't no longer enough. So you need to focus on the model safety the most. so most clinicians they they're already using some of the AI tools, right, to draft notes or I know, but the PHI, the information is could be actively leaking outside the perimeter, right? So while we focus on the infrastructure, the PHI could be leaking through the models, and data poisoning and all that we can cover in detail. so it's already there. it could be happening. so when somebody says my systems are safe, my question would be, is your model safe? Your system is safe, I get it. Your system doesn't break, I get it. But the data that you're working with, you're letting the model play with the data and you're letting the model help you make the decisions. So that is where the governance and security must be in place.

Chris Hutchins (05:03) So I think traditionally, at least at a high level, people understand that the concept of row level security, privileged access, things like that. Maybe talk a little bit about how what that difference looks like in terms of you know practically what are some things that you have to do that are just different.

Vasanth Mudavatu (05:19) No, That's true. So having access to data is one aspect of it, but think about this where it's as you work with the data, the AI will get smarter and smarter. And the smartness of AI is on how your quality of data is improving. Right, so that's the area of concern. Now I can work with an AI, I can train the model to give an unsafe clinical response. Right, so I can always do that. So having access to the system is one aspect of it, but it's very important to understand who is training the model, who has access to the data, and who is training the model. So that's where the data poisoning will come into picture. Now that an insider could be doing it, or an attacker from outside who has access to this could be doing it. So I can give an example as well. So let's say there is a malicious insider who has access to the patient records. Every time you interact with the model, like the person can inject a hidden text. into the record. And that hidden text could alter could or for it to be to take an example, it could suppress an allergy warning. Right? So whoever the clinician is doing it, they look at the output, but in that output you will not see the allergy information brought over by the AI. So that's something that's called data poisoning. So that's something that can be done. And and the other thing is from outside, I can, if I'm interacting with the model, I can do a prompt injection. Right? So I can upload a file. It looks like a file, but it has some hidden instructions that could manipulate the data itself. so that's where the zero trust coming, zero trust security come into play. But end of the day, the goal should always be. to sanitize both input and the output layers.

Chris Hutchins (07:18) let's kind of shift a little bit to where you have to be able to produce evidence And I know you talk a little bit about cryptographic attestation in plain English, but maybe help us understand a conceptually what is that? what does it look like? What's being attested to, who's attesting?

Vasanth Mudavatu (07:36) so the two things, right? So one is the every interaction with to with the model has to be safeguarded, right? So you need to put guardrails in place. Now you can when you say cryptographic attestation, whose point of view are you talking about? Is it from the system point of view or from a an auditor or somebody?

Chris Hutchins (07:59) there's the technological piece of it, but then also in plain English, how are you explaining it and who's the person who's gonna be able to sign off on it? 'Cause I think when you're talking about having to produce evidence, you know, who's going to attest to it? I as a chief data officer, I might be on the hook for it, but right now I don't think I understand it enough to

Vasanth Mudavatu (08:16) correct. So so it's definitely a challenge. to attest the data is definitely a challenge because the rate at which the data is being produced is beyond that's why people are people are creating so many data centers around the world. No data is useless. So they'll have to grab as much data as possible, and they'll also have to make sure that they use the digital signatures. I think that's what the attestation is more about. So use the digital signature to prove your identity and an authenticity of the data. so it's definitely a challenge because having a cleaner data is absolutely essential, but at the same time, the rate at which the data is being produced, and so that's where the policies come into the picture. So what we have what I have done for one of the systems is to set up those policies in place. Anything that comes in must go through these checklists. And that checklist has after talking to Our internal compliances, compliance team, auditing team, and any other external compliance that we need to meet. So all those requirements have to be taken, have to be considered, and then you approve that particular data set to get into it. so that's serious job is not an easy job. I know it's going to change the heart of everything that's going to be built on top of it. So yeah.

Chris Hutchins (09:45) I just think about how different it is between having a typical software development lifecycle versus having a model that's evolving like AI is going to do. What are some of the elements that actually can that are carried in that help you to be able to discern the level of accuracy and security that you've got in place that maybe are a little bit different from the typical things that people are would be accustomed to.

Vasanth Mudavatu (10:11) Yeah, it's definitely a challenge that every organization is dealing with. we need to establish that role-based access control. So you have to protect your systems from insiders and outsiders at the same time. Unfortunately, that's how things are. so outsiders is a different problem altogether, but insiders, you need to make sure that proper role-based policies are in put in place. So you need to identify the systems first. And then identify the roles that you would want the users to have. A role could be like I am a I'm a leader, right? I want to see everything. That's fine, you can see everything, but he cannot do anything. He can only see the data. Now, like auditor, I can only see the data. Now I am owner of certain portions of data, then I can I can have read and write access to the data. So we need to establish those roles beforehand and make sure you go through proper leadership, approval chain, and get it approved, and then start implementing your systems. And then you need to find the users who are qualified to for each of those roles, assign them, and then implement the systems to find the users and then get them access. So when someone some user is trying to access the system, system should be smart enough to figure out, okay, who is this person and what level of access person has and only show that data. Don't show anything else beyond that.

Chris Hutchins (11:40) talk a little bit about what your experience has been, you know, working with leaders and you know, there's a tendency if they get a certain level of information that they just get they want to trust, which is fantastic in some senses, but where are some things that you see could be problematic 'cause they might get a false sense of security before they really should.

Vasanth Mudavatu (11:58) Yeah, so that's another common pitfall. since AI is producing data so rapidly and our analytical systems are getting so advanced day to day, right? So data that you see now is not going to be the same in next five minutes. It's going to change. the assessment of AI is going to change. The assessment is a non-deterministic approach. So there might be a new parameter that that's thrown in into the model and it could change the whole analysis altogether. So that's something that takes a lot of effort for us to put the guardrails in place and make sure the model's response is always in standard format. And not have multiple places for the leaders to go and look for data. They should come to one central location. And that should be the source of truth. The moment you look at multiple locations and data is going to be mismatched, maybe by 5-10%, that might cause a big issue later. Again, we don't know. so we avoid having duplicate points, viewpoints for the leaders. Come to one central location, consume the data from there, and then make whatever decisions you need to make.

Chris Hutchins (13:12) just because we get to a point where we're comfortable on day one, that doesn't mean it's gonna be stay safe. And I kinda wanna go back to a concept you've already mentioned, which you know, the data poisoning and prompt injection. Maybe just if help a CISO and a CMIO understand what you're talking about there and in what does that actually mean and what do they need to know?

Vasanth Mudavatu (13:31) Yeah, so data poisoning happens when the data set. So as AI models become better and better, you're saying it becomes better and better, but they become better when they have a better quality data, right? So and you may have the whole world in front of you, but you may not need the whole world, right? You just need a portion of that data. So that's where the data sets come into play. So you pick the data set that suits your use case, and then you train the model. Now you train the model today, and tomorrow you will get a new or more improved data, and you have to keep training the model to keep revisiting the decisions that were made. And then so that the fine-tuning of that data set or that model that is the place where the data can be poisoned. Right. So when I'm trying to train my data set, I can inject something and that could cause an issue. so I was giving an example earlier. So if an I can in an attacker can inject an hidden text in the file, which could alter a clinical decision, right? Which would completely ignore the allergy warnings for that patient. And the clinician will never know, they will never have access to the data because the AI has processed so much data, all of the patient's records, which is impossible for one clinician to go through it and figure out, okay, he had an he or she had an allergy warnings a couple of years ago. And if that warning is missed, then the decision, the clinical decision is going to be completely different. And that could cause some serious problems. So that's where the data poisoning comes into picture. Then the prompt injections it happens when whoever is accessing or talking to the system, right? I can inject in my prompt. Let's say I want to see I'm a clinician, I want to see your data. Then I can simply ask okay, give me Chris's data, plus I can add some more to it, which is absolutely. Rubbish, it doesn't make any sense for us. If you read it, it doesn't make any sense. But for model, it needs to interpret, it needs to understand. Okay, there is a legitimate question, plus there is an extra text. The model is not going to ignore it, it's going to consider it. And if that says that extra text is telling the model to do something else, it might do it. So that's the injecting. So you it's just a prompt injection. So You're asking the right question plus more. But model does not stop at just the questions. It's going to read the whole input. So that's the prompt injection. Again, this is a direct prompt injection, and there is an indirect prompt injection that can also be done where I can send some hidden instructions, you know, to manipulate the patient history itself. So it's a completely unintentional, but the model can interpret in such a way and then And then it can cause problems. So that's where the zero trust for prompts come into picture. So every prompt that the user is submitting must be validated before going to the model. And every response coming from the model has to be validated. and the response and the request must be paired together and again validated. So, because the response can be true, but the prompt is something else. Right? So, you cannot validate them in silo. You have to pair them and validate that okay, the user is asking for somebody's records. Is the user authenticated? Is he or she authorized to request for those details? All that role-based access control and pairing up with what was asked and what is model responding. Together, these are the guardrails that must be put in picture. So the CISOs should be focusing on creating that proxy layer or a gateway to monitor all the whatever all the transactions that are coming in and out of the model.

Chris Hutchins (17:38) what are some of the things that you would tell people they should be thinking about to reduce those risks as much as you can? particularly the because the systems can actually retrieve records and write back to workflows, trigger other things. it's much more real time than maybe we're used to.

Vasanth Mudavatu (17:53) Okay, right. So that's where the prompt engineering comes into picture. basically it's all it means is the prompt is the question to the model. Make sure it is very clear. There is no scope for ambiguity there. You know, exactly you should ask exactly what you want. Okay. If you leave it open, then be prepared to be surprised, right? The model can hallucinate. It doesn't fully understand the scope of your question. So make sure. So we need to train folks on prompt engineering how to request for exact information. So that's definitely a key. And then every time you get a response from the model, since it's a human interaction now, the expectation is you need to validate the response. Did the model give you what you asked for? If not, then give some feedback to the model that this is not the response that you're getting. And if the model gives more than what you want, then still you need to give them the feedback. So if there is no user feedback, then model is not going to learn from your interaction. and it could be giving much more details to some other user, which is not at all required. And that's how the data leak will happen. that's the data leakage. you might get your records, plus you'll also be getting my records, my information. It all depends on who is asking and what. So we need to educate the users definitely on how to ask the question and how to validate a response and how do you provide the feedback to improve the model.

Chris Hutchins (19:28) So but if you don't mind, could you say a little bit more about this, the prompt engineering and the importance of making sure that you're providing training to team members?

Vasanth Mudavatu (19:36) yeah. Absolutely. I mean, vibe coding is a thing. that's a term. Vibe coding, you just prompt and it's gonna give you a bunch of code, bunch of code, and you can spin up an application in a few minutes or a few hours. So I would say creating or developing is no longer the niche skill. Right, you need to fully understand what you're developing and what's the problem that you're trying to solve and understand the data that you're going to work on. If you have access to a confidential information like in the medical industry, then you have to make sure that say all the guardrails are put in place. So you need to understand the security principles, you need to understand what shift-left security is. It means security is not an afterthought. It has to be imbibed in the design, starting from the design. So you need to sit that's this concept called secure by design, SBD. So you need to design your system first. The AI will develop what it thinks the best. But you need to know what exactly, you need to tell AI what exactly it should do. So that's where the design comes into picture. You design first, but before you need to understand the security fundamentals, understand the security first, design it, include all the principles in it, and then feed that to AI, then AI will give you a system. But you also need to develop test scripts to ensure there is no data leakage and make sure your prompt. So prompt engineering comes into play once you have the design in place. then the prompt engineering will come to develop the application. Now if you're asking AI to design, which most people do, which is absolutely fine, but if you don't understand what the design is, then rest assured it's going to be a mess. It might look good, but when it comes to functionality it's going to be a mess. So understand the security By design and understand the Prompt, how can you engineer the prompt so you will always get accurate response from the model and validate the response from the model. Do not accept blindly, do not trust the model response blindly, validate it and test it yourself. So make sure all the policies and guardrails are in place so that way you can limit the attack surface. All we are trying to do is limiting the attack surface. After all the guardrails, still there could be a data leakage happening, still somebody could attack your system. All you're trying to do is reducing the attack surface.

Chris Hutchins (22:18) Now you've got to be able to defend how the system is governed, which gets to the whole governance conversation, which is no longer going to be just an academic exercise. may we talk a little bit about, you know, what kind of governance we're talking about that can survive and audit compared to the kinds of governance that we're used to where it may not be so tight and we're just looking at a policy, but we're not actually looking at how it's being implemented operationally.

Vasanth Mudavatu (22:45) right. So two points here, right? So one is the compliance auditing and how do you ensure your systems are guarded. So things are slightly changing, not slightly, they have changed a lot in the sense that most compliance and auditing are post activities. But now with AI being so powerful, everything is near real time. Every response and every prompt, the auditors can see it. Right. Anybody can see what was a prompt, what was a response, and everything. So the security operations are significant, highly critical, I would say. so you need to put in the AI security gateway. That's what I've been talking about between the model and the user. So you must have that architecture in place. you need to inspect the inbound requests and outbound responses to make sure that only authorized people are receiving the information and that in the information that they are receiving is going through all the policies. all the compliance or auditing policies that are put in place. So to define those policies, it might take a while for folks to for the policies to mature because it's completely new for everybody. So the faster they put it in place, the more trustworthy the AI systems will start becoming If there is a human in the loop, then we have to be aware of the fatigue. The fatigue in terms of if you don't trust the system and if you're asking a human to review the clinician, for example, in one hour that person will receive 1000 assessments from the AI. Right. So you will not have time to go through all that. So that's another fatigue that we need to be aware of. So as systems become more and more secure and mature, the human in the loop will have the burden will be reduced.

Chris Hutchins (24:43) who is authorized to raise the flag and say, hey, time out. we can't proceed we have to solve some problems. But how do you get to that point and what are some of the things that you see that have been affecting to get an organization prepared?

Vasanth Mudavatu (24:55) absolutely. I mean this is critical. If you're talking about large businesses, then they have multiple business lines and it's going to be a mess. You it's hard to find one person who is a master of all the business lines. so what we have seen is they form this AI governance board where you'll have you'll nominate somebody from your business line to be on the board, and that's where the collective decisions are will be made. And of course, on that board, we'll have technical representations who are running the AI platform, building AI systems, and then you have business folks coming in from each business line, and then you'll have compliance, your auditor, your legal. legal plays a crucial role. So everybody will be placed on that. And that's where the all the big decisions are will be made around how do we govern the data? How do we protect the data? And how do we bring in new models? What are the guardrails that we need to put in place? And how quickly we can switch a model from another tomorrow, a model the model that we are using for one year might have a serious vulnerability. Right. So that was found out many months later. So how fast can we switch that model to something more secure? So all those decisions they'll have to be made by a collective team. we call it as AI Governance Board. and those are the guidelines that will trickle down to the rest of the teams and they'll make decisions accordingly.

Chris Hutchins (26:26) one of the things I know that you urge leaders to do is to plan for the complete data loss. Maybe talk a little bit about you know what you talk you're trying to get organizations to think about from a leadership standpoint, getting into the right posture for a hospital that can't afford to go dark, but These risks do exist and maybe are a little bit more heightened now with the technologies we're talking.

Vasanth Mudavatu (26:48) Yeah, absolutely. I mean that is another serious concern. So the models can go rogue. It's hard to predict, right? And when leaders are budgeting for model costs, compute or infrastructure or licenses, what we have noticed is there is a underestimation of headcount that is required to continue the oversight. Right. So in a hospital industry, they cannot simply go offline. Right. If there is a data loss, it doesn't mean that hospital is going to go. I cannot go offline. So they need more of a graceful degradation for a fallback mechanism that is put in place. And it could be going back to your older way of doing it, the manual workflows, but that process should be in place all the time. And which was already tested, right? It's been tested for so many years. We're trying to transform now, but the current workflows are have been tested. So they have tested, they're time tested, and they are working. now we have to make sure that it still stays there as a fallback option when something goes wrong and which is out of our control. And the other thing would be the impact radius. Right, so health systems they must map exactly which workflows are depending on which models. Right. So a single safety issue doesn't take down the entire operations itself. Right. So as long as we have that map in place so we know which model went dark and we can quickly substitute with it or we can quickly fall back to human in the loop mechanism. I think that that would be essential. And those decisions, I mean, as you said, it's a disaster recovery basically. They're all disaster recovery drills. So that must be in place for any system that is using AI. So it's a mandatory. You s you cannot go live or go to production or release a system without a DR plan in place. that cannot be happening. And the leaders must be made aware that to run this system with AI infrastructure plus your fallback mechanisms, this is how much it's going to cost and they need to plan accordingly.

Chris Hutchins (29:15) but there's this clinical continuity piece of it becomes a little bit more significant when you're dealing with restarting after something like that. Just because we're talking about models and in the sequence where things are processing becomes even, I think, a little bit more significant. Am I right?

Vasanth Mudavatu (29:32) No, it's absolutely. I mean, the sequence in which you start is going to change. the key point here is data. The data is not going to change. Only the model is going to change. This is the model is how we interact with the data. So it's the middle layer that's broken. so that the fallback option should consider this as well. Right. So now you have access to the data. The data is not going to go anywhere. Like data again, data you have data replications and all that DR for the data itself. That's another process. So you should have all those in place. So even if model goes out of the picture tomorrow, you still have access to the latest and greatest data. And you fall back to your older ways of manual workflows. They'll have access to the data and everything. So they'll have to continue. to leverage how they used to do before.

Chris Hutchins (30:24) from your experience, what are some of the things that leaders should be looking for and essentially just demanding some evidence before they make a commitment. what are some of the things that you would tell them to, you know, to kind of pressure test the vendor security or, you know, whatever governance claims they might make.

Vasanth Mudavatu (30:39) Yeah, so things are changing rapidly. So earlier we used to have the luxury of time. Now it's not the case because if I test something today, it might become relevant irrelevant tomorrow. That's how fast things are moving. I mean, we talked about the MCP servers and all, they were not there a year ago. They just came in out of nowhere it's normalized now. Everybody's talking about MCPs. Now nobody's talking about MCPs, but they're all using MCPs. And the transition just happened so fast. Right. so that's the point here. Even for the leaders, it's be very challenging for them to time test something. But what we can do is once if your design of your systems are secure at the design level. And you can bring in a new tool. And of course, before you bring in a new tool, you bring in a more a non-production environment, you test it out there, and then you bring it in. But the time that there we used to get before is not being given anymore. It has to be done in days. That you test your system has to be so smart that they stress test the new vendor API or vendor tool, stress test it, security test it, and then push it in and just integrate with your existing architecture and then keep looking on it, keep an eye on it, just keep looking at the vulnerabilities, make sure all your security scanners that are in place are capable to handle this new tool in place. So so those are the things that being considered at the moment.

Chris Hutchins (32:19) So as you're evaluating solutions in vendors in this space, is there a particular dimension that you think is maybe better as a leading indicator or one that's significant enough that if something you know it doesn't check a box in one dimension, it's just not gonna work no matter how many other boxes it checks.

Vasanth Mudavatu (32:41) Yeah, absolutely. so as we talked about earlier, the technology is rapidly advancing. I might need three things from the vendor, and they are only capable to deliver two. And I do compare other vendors. the other vendor might be able to deliver all the three, right? But for me, the decision making is what is your research capability? Are you capable to keep yourself up to date? Do your research on what's happening in industry and keep updating your tool for me. Tomorrow, in a month or so, I may have six more requirements. And if you don't have that capability, the research capability, and then how quickly you can provide me those six, then yeah, I will not go with somebody who has all the features ready now. versus somebody with strong research capabilities plus just few futures available because I have to look current and future. So that was not the case before. Earlier we were just looking at okay, I need three, you got three, all right, you got a deal. But now no it's not the case. I need three, you got two, I'll take it, but show me your research capabilities. So this is the research capabilities and then I'm sold. Yeah.

Chris Hutchins (33:57) It really is the nature of whether you're picking the right partner. if you could identify a safeguard that would be practical for a health system to put in place, you know, this quarter, understanding how the pace is moving, what would you tell them that they should be putting in place now to help them to you know be as proactive and protect well protected as they can be?

Vasanth Mudavatu (34:16) Yeah, absolutely. So the research capabilities of our vendors is extremely crucial. for some, we become the design partners because it's hard to anticipate what's coming next. Right. The best we can do is protect the current systems and keep try to break it ourselves, right? If you can break your system by yourself, then there you go, you found a new vulnerability. Now can your vendor Or somebody do that for you if they are allowed. If they're allowed, they'll do that for you. If not, then you share the results with them and they'll give you a solution or they'll upgrade their tool to identify that. So the desired partnership is extremely crucial. So you find the right partner with the right skill set, you would want to be with that team, right? so every time you have change your vision, you make sure you communicate to the vendor so they are aware. Okay, this is the direction in which this company is trying to move. Now, what all how can we support it? Now, if we don't have the capability, they'll have to get the capability and then continue to be with us throughout and help us achieve our visions.

Chris Hutchins (35:25) Well, a as we kinda land here, if people want to follow up with you and you know just to get to know some of the things that you're passionate about, learn about your writing, where can they find you?

Vasanth Mudavatu (35:35) you can connect me on LinkedIn. you can search my name, Vasanth Mudavatu, you'll find it. or you can comment on one of my articles that I've been publishing in Forbes, Forbes Technology Council, so you can find me there as well.

Chris Hutchins (35:48) Well, thank you so much. And you know, for the audience, I'll make sure they have all the information in the show notes. I learned a ton from you so thank you so much for just coming on the show today and teaching me some things.

Vasanth Mudavatu (35:59) Absolutely, Chris. Thanks so much for your time. And I really wanted to share what my learnings are to with the wider audience, but thank you so much for giving me the opportunity. And I hope next time we talk, we'll talk more on the agents and how agents come into play. Now we talked about the human in the loop, but as we advance, I think it's going to be more and more agents doing a lot of the work. So it'll be interesting to see how things work in the next six months.

Chris Hutchins (36:24) So we could probably talk in a month and have a whole nother set of things to talk about.

Vasanth Mudavatu (36:28) Yes, yeah, absolutely. Awesome.

Chris Hutchins (36:31) Well, for my listeners, thank you all for tuning in. that's gonna do it for this episode of the Signal Room. and I'll see you next time and please stay curious, stay on top of things, keep learning, and I'm out for now. Thank you.