Hi myself. S I do have 10 plus experience in healthcare integration world. Currently I'm working for Henry Ford Health. Today I would like to start with my topic as in a building t healthcare modality platforms for the engineering epic ride share integration at a scale. And simply saying that basically we have an epic EHR systems I would like to integrate with ride share platform with the integration for the patient. So this is about the topic. About the topic. So I would like to explain here are the few agenda items that I would like to cover in this topic, is that technical architecture, overview engineering challenges and microservices implementation and security observability and machine learning ops in healthcare. So these are the agenda items I would like to cover in the topic. Now beginning about the how this Epic integration platform works like an, I want to give an example how the real world example, it'll gain a better explanation about in terms of that. So let me begin with the problem that affects a millions of patients in the United States. One in five patients either misses or delays, delays. Simply because they don't have any reliable transportation. Now imagine this is not in just on a regular checkup. Think if you, if any dialysis patient or if any patient, or if a cancer patient are attending a chemotherapy even missing in a one appointment, that could be in a life threatening for the patient. So it can, it may to have serious health consequences. More our hospital visits and even shorten the life expectancy. And also it would create an additional burden to the patient on the like if, on the insurance as well, because if the patient doesn't show at the insurance, the hospital that the provider gonna put as a no-show, and that would even charge also for the patient. So without. Go without attending to any kind of, any treatment or not seeing an appointment. Either way the patient might be lost. So the thing is that the challenge is very clear here. We would like to tell how the solution is, like healthcare isn't just about what happens inside the hospital. It is also a board making sure patients can actually get there. Our visions our vision is straightforward that we want to bridge Epic EHR record system to the hospital, already used to manage appointments, the patient data with the everyday ride share platform with Uber and Lyft. The goal for every patient, reliable in complete and timely way to reach their care and to the hospital and get the better patient outcome. In terms of platform, the if you see about the numbers the daily, like 6.5 million daily patients, record exchange the process secured across the systems and 2,400 plus health system connected through the platform. Moving to another another topic here, how this entire epic ride share integration challenges, like how it is integrated. There are some core components that been involved in this Epic integration platform. So Epic Smart Fire, which is like in a standard, it's fire, is a fast resources, which is now a trend in healthcare basically where you will get the patient access the data within a. Using rest API. Earlier we used to have an HL seven version two Dox and three dox. Now with the file value, it can be, it is in a set of data standard using a json with an XML content that can be used to exchange for this platform. And, in terms of an architecture, when you talk in terms of technical side epic smart and five set standards like in a grammar for healthcare, basically it would be like in a. Communication language easily. We thought it would be a doctor's patient's systems, all speaking different languages. Now, ride share a p is like an uber relief warrant built for healthcare platform. So they were designed for a consumer nce. So quick pickup is that estimated arrival time, but they don't have a built in compliance, the protection to send to medical data. So that is where there the integration layer comes. Here, this layer acts as in a bridge. Basically it's like a translator with a security guard combined. It makes sure the data flow correctly, quickly, and securely between Epic and the ride share system platform like either Uber, other Lyft. And moving to the second agenda topic, is one core engineering challenges, basically. So in the core engineering challenges, we have a bidirectional API flow management system and fall tolerance implementation. So now let's talk about the core engineering challenges. The first bidirectional API flow, which Epic needs to share an appointment detail and a patient can text of the ride share information that needs to be. Single things like a driver location, estimated arrival, and a drop of confirmation on the both sides. They need to be constantly sync between I pick and the patient. And at the same time, the app also need to be aware. So the second the the fault tolerance implementation is that. What if the lift goes down, like the system needs to instantly switch to another provider, like in a Uber or without any patient even noticing. It's like in a, just in a GPS rerouting you instantly, when a road is closed, automatically you'll get in a reroute option. A the estimated arrival is like five minutes. So you can choose this particular map and you go, where the care must be also continue without any interruption. When Lyft goes down, automatically Uber picks up. So that kinda platform that we need to switch based upon that. And there is a third that most important is that the HIPAA compliant data problems, so every single ride request involves more than 47. Sensitive variables like a patient name like entire PHI, which comes as an patient name, appointment type and pick up type. Pick up an address, notes, and put all the mobility needs. Each one must be an encrypted logged and auditable and nothing can. Slip through the cracks, basically. When in terms of these hip up compliance, these are abstract challenges. They're directly impact whether the patient makes its dialysis today or in a cancer, or a cancer treatment. So the, any difference can make a line between good health and serious complications. So this is why engineering isn't just about a clever code, its about the patient lives, depending upon the system that we design. So moving to the next topic is like an overall how this, entire platform was like in a core microservice architecture. There are like in a, some of the core components like epic integrations and transport orchestrators and provider gateway and patient profile compliance and age, and there are event bus Kafka. We have an in the Kafka, where's an accounting platform system basically for a Kafka realtime events where you'll get and transportation request state changes, appointment updates from Epic. Driver locations and ET updates and even the compliance related to the audit trail as well. And another component is a PostgreSQL for transactions, where it gives a complete registry and billing reconciliation data and compliance and documentation and configuration management. So read of performance like patient transportation profiles. Here the data to make this work reliable. The microservices and event driven approach with the Kafka, we can stream events the patient books when a driver updates their status. Our ears gives an instant hookup, such as whether the patient needs a wheelchair access or that, that gives, that helps the patient basically. And this is in a, this is like an separation. A powerful where instant, one giant system trying to. To do everything, each microservices like in a specialized hospital wing, one wing for emergency care and another for lab test, and another for surgery, and another for radiology oncology, each has its own team and its operates on own services, but apart from that, they're all connected base secure hallways. This design means each services can scale and independently suddenly for more patient need rides. During a flu season, the ride matching services can scale up without slowing down everything else. So it's not just an elegant, that architecture of micro, it's a, it's always a board, ensures that patients can depend on these rights and every time, no matter what it is. So moving to another agenda. Topic here is that Kubernetes orchestrations and SRE practices. So here we come categorize as a four components, like in a multi region deployment, auto scaling, and automated failover, and can already deployments. So our system runs on multi regions on AWS deployment. Think it, we have a backup hospitals in different cities if one goes offline and patients are automatically routed to another. Okay. So care continues without a delay. We also use a predictive autoscaling. This means. Which this means we study historical clinic loads. For example, flu season brings more patients, so the system at medically scales capacity in advance. For example, in the COVID we might see this, if you have more number of patients, that's also, you can take in a COVID real world example that auto scales. If you have more patients affected with COVID-19 and. That is one of the best example to explain for auto scaling. So not only flu season then there is an active cluster. Meaning to our more systems run at the same time, even if one fails and automatically another node pick ups like continuously. If another node fails, there would be another backup node. So when we roll out few, when we roll out few new features, we don't push them to every one at once. We use canary deployments and just like in a hospital might. Test a new procedure with a small group of patients, making it as a standards practice together. So these approaches, like 99 point, whatever, these approaches, like four approaches, which gives 99.9% as an uptime. But in healthcare uptime is, uptime, isn't about convenience. It's about saving lives. Moving to another agenda topic. So security engineering and zero trust architecture. So in this also we cover like the four major components like data. Protection and authentication and authorization and network security. So when dealing with the patient data, the security. Security isn't an optional, so it's in a foundation for a patient. Healthcare, when we use a zero trust. Security, which means that every request must prove itself no matter where it comes from. So like checking every visit at the hospital door, even the various staff badge or anything. So no matter what endpoint that we are getting, so either internal or external application that is hinted heating the application. So we always interest based. Rotator based tokens encrypt all the data with a S 2 56 encryption for all the data transit in force or two and PKC. On the network side, we secured the traffic with TLS and web application firewalls. But beyond security observability, it's just a critical, we need a visibility of both technical and clinical access. If the API slows down, that's an it's an ID problem, but if dialysis right is late, that's an a clinical problem. It could harm a patient. So our monitoring separates this signals so the right team response quickly. So if we even measure a custom SLM metrics that tides timelines directly due, timelines directly to medical schedule because in one of the system performance is about and just number just number and a board. It's about the patient getting a care what they need and on time. So I would like to move to another topic. The machine learning ops with the challenges in healthcare, transportation. This is the other topic that we are gonna cover in this Also, there are some of the core components in order for this thing, like data collection. Future engineering and model deployment and con compliant deployment and continuous monitoring. So now as a boom of AI and machine learning also plays a role improving the healthcare mobility. Our pipeline moves from data collection into a feature engineering. Model development and deployment, and finally monitoring. But healthcare brings a unique challenge. Patient data is often in incomplete, and transparency in critical, and clinicians need to understand why the AI system is made as a recommendation despite these challenges, the impact significant in our deployments. AI help to reduce the patient no-show by 42%. Here is in a simple example, I suppose the system learns that Mr. John Doe often cancels the rates on Monday morning. A can proactively schedule a backup for that ride and send a reminder reducing, risk mis care. So in healthcare mobility, every predictive or step A takes a sense of one more patient, get there an appointment on time leading to a better outcome. So if you see here the plat, the platform what are the graph that you would use in the successful, 10 x graph spikes during the weather emergencies and processing 15 million transportation even in monthly and reduce 42% I was discussing in the previously. So moving to, oh the design the design on the platform. So let me share the real case study on this platform reliability metrics and engineering impact. At a midsize hospital in Chicago, about 40% of dialysis patients are missing an appointment each month. Because of un reliability transport, that's the nearly half of the patient unable to get a life saving treatment. We implemented this platform integrating with Epic scheduling directly with Lyft, API Patient needs like an wheelchair access for care. Notes we are mapped automatically into a right request during a Midwest Tom in Chicago. So the system held a strong thanks to multi-region failover, even in harsh conditions as well. So the patients still got their own appointments and the results were dramatic, and NoShow has been dropped almost like 40%. If you calculate in with just 15% in six months the patients reported higher satisfaction. When we integrated this epic rates side platform, clinicians also received about 20 hours each month because they no longer had manually coordinated the transport. And also the insurance companies, which are the, whatever the providers charge for the insurance for. If you don't show as a no show that may be also charged, right? So that also reduces a little bit dropped as well. So moving to another topic here the key takeaways of the platform engineering. Here we have four components like design API, clinical workforce and manage sensitive data across the systems and implement healthcare compliant in CICD pipeline. And also align monitoring with the clinical requirements as well. So for an engineer, there are like whatever the four topics and the big lessons here. First, API in healthcare must be designed around a patient care, not just in a data exchange. Every call impacts that real lives. Second appliance, isn't this something you. TAG or later, CRCD pipelines must automate approvals and audits from the beginning. The third is that governance of sensitive data is critical. Every piece of a patient information must be addressable. I end to end basically. And finally, the observability needs to be served on both IT and clinicians. Team, it's not enough to know if the system is fast. We need to know if the patient actually got their own appointment in end time. So these day, these four takeaways. That shows that building of in healthcare means thinking beyond the code. It's about designing the system that protects scale and heal for this entire platform. So moving to another topic that I would like to end with the entire my topic. It's an end basically I would like to put my closing statement about this Epic integration platform with Uber or Lyft or whatever. So we are not just solving a technology problem here, we are just addressing healthcare equity problem. Too many patients miss care because of transportation fail. For a platform engineers, the challenges is to embrace compliances and security and reliability. The design drivers not blockers. This is a mindset where. What the system makes like this possible. And here is a moral memorable point that I would like to leave in this entire presentation. So in healthcare uptime isn't just a metric, it's a lifeline, basically. And this system we build don't just move data code, they move the patients, they keep the treatment. And track and they save the lives. And that's why this works matter. And thank you for giving this opportunity. I would like to close my presentation.