Hello everyone. My name is Qatar. Today I wanna show you how we can build healthcare AI systems that are both powerful and private. My promise to you is that this will not be just theory or passwords. By the time we are done, you'll have a clear picture of how blockchain federated learning. And modern privacy engineering can be combined to make production great platforms that regulate us trust. Deploy. Developers can easily deploy and patients can rely on. So I'll walk you through some real technical issues and give you the same insights I've developed from research and independent study. Think of this, talk less as a presentation and more as a workshop where we are looking under the hood to. Since I mentioned examples, everything I share in this session represents my own views and learning. Nothing here is from any of my current or past employers. The slides are based on public references such as OAS Top 20 open Academic Research and my IEEE and MIT work. This is a personal presentation effort where I share insights and practices I've developed through study and experience to compare notes with the community. All right, so with that, let's dive deep into slide one. The healthcare AI privacy paradox, AI and healthcare is full of promise. As we all know, whether it's imaging drug discovery, or personalized treatments, these models get better as their training data gets richer. But here lies the paradox, right? The richest data sets are locked behind regulations and competitive boundaries. HIPAA and GDPR prevent direct sharing and even anonymization often fails because modern models can reconstruct or infer sensitive details. I've started cases where supposedly anonymized DICOM scans or clinical notes. Could still be linked back to patients through auxiliary data. Of course centralizing data may look convenient, but it creates single breach point and invites inference attacks. The way forward is not to move data at all. Instead, we need to bring computation and proofs to where the data lives while guaranteeing to all stakeholders that their privacy and compliance obligations remain intact. Let's look at this problem even further. I call it the distributed nature of healthcare data. So healthcare data is not just distributed, but it is fragmented across incompatible systems, EHRs, or electronic health records. They sit inside of Epic or Cerner as an example. Imaging probably managed by pax. Genomic data sets live in research silos. Clinical trials sit with pharma. Each uses its own schema vocabulary and security protocols. I've seen many technical reviews described this as a data integration problem, but in reality, to me, it's also a compliance and trust problem as a security professional. The mistake is often to build massive central extractors to normalize everything, and outcome is brittle pipelines and exposure risks. A better pattern is to build thin, standardized adapters that run locally. Inside each institution, these adapters translate into local formats. The minimal features required for training enforce local policy and generate cryptographic groups. So by tolerating heterogeneity instead of erasing it, we can actually create a system resilient to schema drift, and local governance differences, right with that, right with the problem outlined clearly. Let me bring in blockchain as a trust foundation. When I say blockchain, I don't mean public chains or cryptocurrencies. A localized version of it, which most people call it a permission ledge that acts as a shared source of truth between institutions. Okay. No PHI ever touches this chain. By the way, since we're talking about a chain, since we're talking about institutions with an S you wanna make sure that no PHI ever touches this chain. Then what are we gonna use blockchain for? What goes on the chain are trust events, which site trained when under which, the consent policy allows with what differential privacy budget, and what model lineage was used. So when auditors ask me to prove that a model was never trained on disallowed cohorts, the ledger provides tamper evident evidence or tamper proof evidence. Call it. The ledger is the bridge where compliance meets technology. This requires discipline design. Only store hashes and references, rotate keys with hardware backed identities and ensure that smart contracts encode regulatory gates like consent versions or privacy budgets when done correctly. Blockchain is not a hype. It is a compliance backbone. It's not an extra expense, but a long term saving. Let's look at. And the next piece of it, which is federated learning. Now, federated learning turns the traditional model on its head. What does that mean? Instead of exporting data to external model, we export the model to the data. Hospitals train locally and send updates back. But here's the problem. Knife, federal learning, nicks. You know what a learning leak is. Most people call it knife federated. Learning leaks also is, if that's the word that you're familiar with. Raw gradients can reveal training examples. Malicious clients can poison the model or plant factors. I've seen and I've seen of course in, in test environments. Mostly since this is all new I've seen demonstrations in academic research where attackers reconstructed sensitive features just from update streams. The right implementation requires secure aggregation, differential privacy at the edge, and robust aggregation at the server. It also means validating and attesting the training binaries. So we know each participant is running the approved code. So without these measures. Federated learning is a false sense of security with them. It becomes a practical way to unlock collaboration. I also talk about the architecture a little bit and not just stick to theory. Like we all agreed in the first slide, right? Like a real feder federated platform must honors. So inside each institution's boundary okay there, because it remain there remains PHI. There remains consent checks and local computation outside the boundary or RY orchestration policies and cryptographic proofs. I would say abstraction layers allow each side to connect despite of different stacks. So multi-tenancy is crucial because the same hospital may participate in several collaborations simultaneously. Workflow orchestration must respect real world constraints. Hospitals have maintenance windows. Bandwidths and bottlenecks and competing schedules. Think of it like an SRE system. We need retries in the important jobs, metrics and back pressure controls, which is an important, this is where a, proof of concept either scales or fails by addressing not just algorithms, but the operational realities of healthcare. It let's see. Let's talk about blockchain infrastructure for healthcare here. Infrastructure, design choices matter, right? And as most of the security professionals would tell you that security should always begin at the time of the design when things are layer up. Anything that is done during implementation and not during design is expensive. And counterproductive, of course. So consensus mechanisms should fit healthcare's needs. We usually have tens of participants, so you know, PBFT style consensus with, strong IL is ideal, right? We're talking about blockchain terminologies now, and smart contracts like should enforce policies. Such as no model update is accepted. If a site's differential, privacy budget is exhausted, block structures must strike a balance, right? So enough transparency to support audits, but not so much metadata that it can be de anonymized. So it's always about the balance, right? You log enough to make sure that you have a context in place. To track what is being changed, but then you also don't start logging PHI into it, so it's similar. And blockchain isn't really different from that perspective, but hospitals operate with firewalls, intermittent connections and strict change controls. I've seen projects described in research lit. Literature fail because they always assumed on connectivity or open networking, the right topology, tolerates intermittent links, encrypts channels, and achieve leisure state for the long retention cycles that healthcare regulators demand. Let's bring in. Privacy engineering integration to this equation. Now, as we saw the problems of blockchain we also saw how federation would come into picture and then how all of this pieces in together in a integration of sorts, with privacy engineer. So privacy technology is not. One silver bullet, but toolbox rather. Why I say that is because differentially a private training gives us provable limits on what leaks from models. Secure aggregation ensures that the server never sees individual updates. And again, a ZTA right, which also converts in privacy to. Zero knowledge proofs, if you have heard, that can demonstrate that a site respected a consent rule without revealing raw counts, call it the homomorphic encryption. So homo market encryption allows computations directly on cipher text, though it is still expensive, right? But secure multi-party computation enables collaborative statistics without input sharing. So I have a lot of examples and you can easily find, companies and vendors that are specializing in this. And I see that it's not that expensive with. The amount of time that is, that it's being in the market. The art I think is knowing when to use which tool. That keeps your cost down. For example, I often recommended starting with a DP plus secure aggregation for most workflows and layering in zero knowledge proofs where. Regulators or the security condition in itself, or the risk demands higher assurances, let's say if it is a PHI workflow versus a payments workflow versus a regular PII workflow versus an anonymized data workflow, right? Where, which control should be applied? Risk-based control is what I call it. So what matters is tracking and enforcing privacy budgets. Exposing them in dashboards and ensuring that cryptographically try to training receipts without these practices, privacy promises become marketing lines with them. They just become enforceable guarantees. And since we touched on that part, I would like to move straight into regulatory compliances. DevOps integration now. So since we looked at the privacy integration already, I wanna quickly move to the complete holistic whole picture which talks about the DevOps integration and how regulatory compliance at such affects it. So too often compliance is bottled on at the end, and that doesn't works in healthcare. Why? I say, compliance must be baked into DevOps, just like. How we discussed about Secure by Designer. You input security, right? When you. Crafter design, right? Every code change and every model training run must be automatically checked for HIPAA and GDPR safeguards. So scrubbing is one example. And it's not the scrubbing that happens when the data is stored. It's actually a middleware that has come into the picture, a new idea into the architecture that scrubs data on both sides, even when the input is captured, as well as when the output is supposed to be displayed, whether it's for a service or a human. Doesn't matter, right? So the pipeline itself should enforce differential privacy budgets, generate documentation, and fail the build if something is out of bounds, right? So model cards and lineage should be produced automatically, not written months later for operators. So in my academic and independent research projects have insisted that if a training run produces an artifact that violates policy, the run fails. Period, right? This discipline that by the time you're in front of an auditor, your evidence package is already generated from immutable logs and receipts, so this is what I call about compliance becoming a byproduct of engineering, not a blocker. Now this might just work well if you're just a single hospital Right. Or a single institution, but when the scale grows, right? And when you're talking about multinational healthcare institutions or, even like something that is truly. National which is present throughout the country or a major part of the country. Then you face different set of scaling challenges and I call them multi-institutional scaling challenges. When you work up across multiple hospitals, the hardest problems are not technical. They're human and organizational. So just like any other industry some institutions have data science teams, others barely have it staff, right? Some have GPU clusters, other can only contribute via managed notes. Scheduling conflicts, cultural differences, and data quality issues are the norm. So research pilots have collapsed because smaller hospitals felt excluded, or because validation threshold weren't shared transparently, the solution is to design for unevenness, right? You can't just expect a perfect response for a system that is designed right. What I mean by that is provide turnkey edge no for resource for sites, right? Validate schemas per site to catch data drift and create incentive structure so every participant sees benefit. If you don't solve the human and governance side, no amount of cryptography will save your rollout. And with that, of course the emphasis should be that, how good this is working. And since I mentioned that. The next slide is very important. Platform monitoring and observability. Observability in this context means you're seeing enough to ensure safety without exposing sensitive details. So you can't log raw patient patches or stream identifier. Instead, you need privacy preserving telemetry, noise metrics, RA sweeps, aggregate statistics. At the same time, you must detect adversarial behavior. That means monitoring update magnitudes to catch poisoning attempts tracking distribution swift shifts to spot drift and enforcing consent policies in real time. So an example would be an alert must trigger automated quarantine actions, for example, right? If isolation of a site that sends. Am LS updates, right? Because human triage at two M isn't enough good. Monitoring here is both about patient safety and system integrity, right? So I think we discussed a lot of things. We started with, the basic concepts. We saw the challenges and we saw how. The three concepts of, blockchain federation and smart integration can help things here. So I just to map it out clearly, I wanna make sure that we see the implementation roadmap also, right? How do we implement it is always the question. And since we are not just gonna do this as an academic study. Try to turn it into a workshop. Rolling this out is not a single launch. I think that's the most important insight that one needs to understand. When you're working with a multi scaled healthcare platform, it's a phase journey. Phase one establishes the foundation, which is a permission ledger. Basic privacy adapters and pilot integrations. That's pretty simple, is how I would set up phase one. Phase two pilot's, a non-critical workflow. You say a readmission protection with limited risk. That's when everybody's happy, you've done all your security checks, your privacy checks, your compliance check. Legal's happy. Phase three expands to more sites and more robust application. Then you do your stress testing with governance and scaling. And then comes phase four, right where you move to high stakes clinical applications. With PHI. With PII, right with PCI, with full monitoring and regulatory sign off at each stage, success means not just technical performance, but. Evidences, receipts, compliance artifacts, or clinical validation. By treating this as a stage deployment with clear gates, we build confidence and reduce the risk of catastrophic failures. So even though as security you are just a reviewer, you're just a responder to something that is given to you. As I said, you when these initial meetings happen, when kickoffs happen for such projects this is exactly. The success metric or the success criteria that you should share, that this needs to be a phased approach. And that's when security can, support this project to the maximum. Finally, like I said, as an industry again, this is a, an honest attempt that I want to share some of these best practices that, again I've learned throughout the years through my research, through my study, through my affiliations with academic institutions and through my. And the real point of this is to transform healthcare through privacy. So privacy is for healthcare, right? You cannot have the horse before the card sort of thing. So the real point is privacy and progress are not opposites. Privacy is what unlocks progress. As they say. Privacy lets you. Work and play in a connected environment, right? So without trust, institutions won't share without collaboration. AI models would stagnate by embedding serenity proof and compliance into the fabric of a system. We create a platform where hospitals, researchers, and pharma can work together. We stop asking people to trust our intentions and start showing them cryptographic evidence. And blockchain is definitely the answer. The result is not. Better ai but faster breakthroughs, safer clinical tools, and of course stronger patient trust. That is what I mean when I say privacy first. AI patient trust is all I mean by that. Thank you for, spending this session with me. If you take away one idea, let it be this. I would say in healthcare ai, more computation improves not data. That simple shift preserves patient trust, satisfy, satisfies, regulators, and accelerates medical innovation. I'd be glad to dive deeper into specific controls, governance and rollout patterns. During q and a. First has my email address and I would love to. Get comments, feedback questions from the folks from the industry. I thank you and have a good rest of the day.