Hi. My, name is Patrick Ling and I'm an engineering manager on, the healthcare. And life sciences team, here at Google cloud our. Mission, is to organize, the world's healthcare, information and to make it accessible secure. And useful, to, improve the health and health care of people in communities globally. Today. We're going to talk about our offering in the medical imaging space, first. We'll hear from Homer kawar who, is the VP of engineering at AI digital his, company built a innovative. Teleradiology, solution. On top of Google cloud platform. Afterwards. We'll hear from my colleague Sascha vesicular, he'll, be walking us through the cloud. Architecture, of the system and then finally I'll be back up here and I'll be talking about the platform underpinning, all of this which is the cloud healthcare of API and with. That I'll hand it over to Omer thanks. Patrick hi. Everybody thanks, for coming I know it's the last day and people. Probably have flights and things that they want to get back to so I appreciate, the the, people that did come we. Have a lot of exciting things to talk about today. At, I didn't. Is. To, essentially deliver better patient, outcomes through, the application, of advanced. Technology. When. Our founders sat down, they. Looked at the entire healthcare sector and determined. That the. The, area. Of the, industry that was most ripe for, this kind of benefit. Was. In fact radiology. And. Specifically. Teleradiology. So. They. Thought about the problems, that they're trying to solve. There. Over 35,000. Radiologists. Less. Than 3 percent of them are networked. There's. No common platform, and. A. Decided. Lack of technical, technological, advancement. This. Market is very large it's 5 billion dollars but. It's a highly fragmented mix of solutions and so, what we're running into, is. Essentially. Two major areas, of challenge in. The market itself. We've. Got radiologist. Burnout happening now. There's a couple of factors that are feeding into this one. Is that. Radiologists. Are being asked, to, read. More and more so, the volumes are increasing. Also. Radiologists. Are being asked to do it faster. Oftentimes. There are patient expectations, you. Know I'd like my reading back fast. There are also clinical, concerns, if. There are emergent indications. That. Things, need to be turned around rapidly. So. Whilst the volumes going up and people, are asked to do their work faster, the, technology, hasn't been able to keep up. In. Addition, another trend, that's worrying is that, coming. Out of medical. Programs, we're having fewer and fewer people actually opted, to do radiology. So. There's, all, these factors, are driving, radiologists. Individually, to try to do a lot lot more on the. Same platforms, and systems that they've been using for decades. We. Looked. At some market surveys and and found that satisfaction. Amongst. The users and users the radiologist, is down. At the 40% level and. For a 5 billion market to be down that low and just. To be clear that 40%. Satisfaction. Is with any of the solutions that exist it wasn't their particular solution, so. They're essentially saying there's nothing there that that. Really helps, me execute. My work rapidly, and achieve, those patient. Outcomes that, we're looking for and finally. With. The trend in fewer. And fewer radiologists. And. The increasing, cost of healthcare that everybody's, aware of, we're. Finding, that we get very poor rural coverage, and. Institutionally. Also there are challenges in delivering. Radiological. Care on. The. Technology, side we've. Got a, lot. Of problems, we've, got cumbersome, data exchange so. With any industry with any technology, that has been around for few decades what, we're finding is we've got a lot of different systems. They. All speak. A little bit differently and so we've got all of these point-to-point integrations, going on, and. That's in the radiology workflow, so from end to end you know they could touch four or five different systems provided, by four, or five different vendors and as. Those vendors have software, that gets released, you know we've we. Essentially have problems. In those integrations, that's.
Leading To low reliability so. It. Is not uncommon and you, know people that are not in the field may, be shocked by this but it's not uncommon for AD ologist to essentially show up to work and not. Be able to work their. Platform. That, allows them to do teleradiology. Just. Is not available for hours at a time. And finally little innovation so I mentioned that before, with. The. Legacy, systems that are in place and the technology, that exists what, we're finding is it's very hard to get. Some of the cutting-edge technologies, specifically, machine. Learning models, and artificial. Intelligence to be applied, people. Are working very hard, some, of you are in the room on on these, technologies, and they're, running into real challenges. In delivering that, into, the workflow. For radiology. I. Mean I was, talking to one vendor that has to actually I mean they're a team of data scientists, and they have to take, VMs, and put, them in sites in order to deliver that you. Know this this is really these these, high roadblocks are causing. Causing. People, just not to use the technology, and then, finally scalability, so, all, of the things I talked about from a fragmentation. Perspective. From. A technology perspective. Are. Leading, to. Are. Leading to an inability to scale any of the individual, solutions that are on the market today. Across. The country. So. Our, solution. So. What we looked, at was, to. Create. A cloud native zero. Footprint teleradiology, solution. The. Entire solution is built on the cloud including. That. DICOM store so for. Those of you not, in the industry that's essentially, the images, from. The various modalities. So. Those are on the cloud which is. Believe. It or not a significant, step. There's, an embedded die computer so that also is in the cloud and, so, you. Know that's important, to, reduce the multiple vendor approach that currently, exists today and. Then both risen packs capabilities. Are built into the platform. From. A machine learning and AI support, perspective you know the step one was to create a platform and, then start to drive, in the capability, to add machine, learning and AI. From. From, cloud solutions that exists today. Embedded. Voice support is an important. Important. Work, enabler, for radiologists. And then. Streamlined, integration, with facilities so those of you that don't work in the space may. Not understand, how difficult it is to actually connect. To facilities. Whether that's a hospital, or, an urgent care center, in. Some rural area but, after. We went live as VP of engineering those are all my problems and. So. It. Was great to get some of the experience, on our team. You know decades. Of experience, doing. This at the beginning so, that we could build into our solution capabilities. That actually, make, that faster. You. Know it see it seems seems, like the the simplest, thing to do but, it's actually, being the hardest to, achieve and in practice. So. Now. I'll talk about the platform itself so those capabilities, can, be broken down into technical building blocks, later. On we'll go through this in detail so, I'm not going to spend too much time on this slide going, through every bullet but I. Do think it's important to kind of have some context, for the capabilities. That are there. Data. Ingest so as I said many, many many points, this. Is all HIPAA data so it contains patient information the. Images themselves need, to be secured so we needed to make sure it was both secure, and scalable and, scalable to thousands of points and so. You'll see that in in our solution today later on. The. Platform, itself so this essentially is the work management, it's the workhorse of the the platform and that's, doing all of the management, of the work that's coming in assigning. That out to radiologists, managing, access, all. Of those things that you would expect from a work manager. This. Is also where, we would introduce. Clinical. AI, based, decision, making. The. Image viewer it's, already on the cloud our images, are on the cloud we have very low latency in image fetch which again is a challenge based, on what I've described today, and. Messaging. So, again. We'll talk about this in detail why, we went this route but it, was important to have the, scalability, within the system to pass information back, and forth. And. Mobile. So I I, think I referred to earlier kind of a lack of access from an institutional, perspective so. We made a mobile tool. Set that allows essentially. Mobile radiology. To. Be enabled essentially. These are technicians. That drive around with. A mobile unit and they can visit, institutions, such as jails or hospitals, elder. Care centers, and.
Our, Platform enables, that workflow also, seamlessly. And. Finally. Machine learning so, you, know that that's really the, the I, think the point of making, a new platform is to enable that and we'll. Talk in detail about how we did that and and, what, the capabilities, are to to, essentially, create that continuous, loop of learning. And. Then. Underneath, this all a data store so. It was important that the data be very, close to the application, the, latency that that. Users. Experience today is very, much related to where the, data is where are the images where's, the patient data and so, it was very important to bring that close and on. The same platform. So. Why do we pick Google for this solution. Well. As you, can see on the left side all cloud services, provide, you, know a set of capabilities, and so. What distinguished, google for us was really that. They, had created and, were. In. Alpha, with a HIPAA, compliant, data store and that was the crux of the, decision. They're. Also. The seamless scalability, that we get with kubernetes. Multi-region. Networking. And then. The. Rapid. Ml tools that some of you have seen today and, additions. To those that were announced at the conference. So. So, what, does that mean from an engineering perspective well, it meant that I could work with our. Design teams our. Smees. In the space and essentially. Use these tools sets and accelerate. The delivery of the platform itself I don't need to sit there and redesign, everything from scratch my. Engineers don't need to go in and make all of these things I can leverage the services, and capabilities that Google has and later, on we'll talk about specifically, which ones. So. What did we learn working, with Google well. We. Found them to be a very active partner as. We, went, and designed, our solution, there, was a very much a conversation, with them about the, approach we would take how. We would, solve various problems we ran into and I. Can't speak, enough about the healthcare team, you. Know they, were awesome. Throughout the process. In. Addition. We. Worked with zazz make our engineering, partner and they, were critical to in in, getting to market fast. So. Again. Some, of the cloud services, I mentioned that accelerated, our time to market and we'll go through those in detail. So. Technical. Lessons learned. Going. Through this process of making this platform from scratch cloud native there. Were a couple things we learned that are pertinent in healthcare so. Number one resource. Matching, was a key activity, so. What what do I mean by that essentially. As we found. These pieces of data coming from various, sources. Getting. That data associated, with both the and the, order that was going on was critical and to be able to do that at scale so we're talking petabytes, of information, that. Needs to needs, to hook together and be related. At the. Point that the radiology, is trying to perform their tasks. Association. Of DICOM based studies with orders has many edge cases so, those, of you that have tried. To use this standard. Will understand, the standard is not standard. And. Every. Vendor has, interpreted, it, their. Way and then. Finally. Scaling. We. Needed to scale we, needed to scale fast and we, needed to scale without affecting, our production. Clients. So. We solved this in, the. First case with micro services and pub/sub and in. The second case by. Introducing. And accommodating. The flexibility, that exists. In DICOM and on. The third with. Gke, and. We're. Looking at sto and service mesh there was announcement at the conference on, service, mesh, also. That we're very interested in so we'll continue to work with Google and. With our engineering partners to to. Achieve those so, next Sasha is going to come up and talk about the, architecture in detail. Thank. You Omar. Appreciate. Everybody being here I'm very grateful. To be on this stage and talking to you all about this very interesting solution a little, bit about myself before joining Google I was, director of medical informatics at Columbia University, for many, many many years many. More years than I'd like to admit, and. It's. From that background and learning that I have an appreciation for, many. Of these technical, challenges, that, organizations. Are trying to solve large, and small, ultimately. To drive better, patient, outcomes. So. What we're going to do today is. Talk through the specific, architecture, that we put in place for. With. I digital. To. Help facilitate, this. Zero. On Prem footprint.
Entirely. Cloud-based solution. I'll. Just highlight a couple of the steps, right. Now some, of the key things that. I think everybody should be focused, on networking. So networking is critically. Important, of course as. Soon as you start talking about moving. To the cloud how. Are you going to facilitate that so the network connectivity is absolutely. Critical. From. That we move deeper into the stack we talk about how. Google. Cloud platform. Organizes. Its, internal. Structures. Around, the concept of a project. Mllp. And DICOM those, are two, critical. Legacy. Protocols. That, are ubiquitous, in the healthcare space and, any. Organization looking, to, move. Into this kind of. Method. Of working in the cloud needs, to understand. The, limitations. Of email both mllp and DICOM and how you can overcome those limitations and we'll talk about that in a little bit more detail, from. There I want to point out obviously the healthcare API the healthcare API is really. Pivotal and central to the entire conversation of the architecture, what, it allows you to do. The, kind of capabilities, it provides the. Kind of systems and services you can build around it and then, ultimately, the, healthcare API go into even further detail with with Patrick when he speaks in the third act. You. Know Omar picked, up on something very quickly which was I. Like. To think of it as liberating, data so. Right now to facilitate. Day-to-day. Transactional. Operations, between providers. And patients. Those. Data systems, are siloed. They're isolated, within the on-prem environment, as. We. Move into the future the, question becomes how do we leverage, that data to, provide better service, again. Ultimately driving, better patient outcomes servicing, more patients. And. Really meeting the challenges, that all organizations, are facing today in healthcare so, by, bringing, the data to the cloud you get to take advantage of, all, kinds of functionality. That's present. In the cloud in, particular. We'll talk about bigquery. Underpinning. The whole exercise of course is security. How. Do you ensure that you are in, compliance. With, very. Stringent, HIPPA regulation. Regime. So, obviously. HIPAA is, is the law of the land in the United States of. Course we are you know we have global presence so we'll, talk about HIPAA today but. This. Same conversation plays, internationally. All. Kinds of jurisdictions, are introducing, data. Protection related. Regulation. In. General, and also in health, care so, as an, organization that's. Looking to take advantage of these products. And functionalities, you obviously. Need to make sure that you're doing it in a very secure and regulated, fashion. So. Let's talk about the. Network connectivity. What. Are we trying to do here ultimately we're, looking to bring. Data from where it's being generated, into.
The Cloud and, in. Order to do that you. Have to have good network connectivity if you, think about teleradiology. The. Way that those providers, access. This information. Is that. They have to get that information from where it's stored and traditionally. That information, is stored on premises. Where. It's been generated, so. Think about all of the networking activity issues that a specific. Physical, facility. May have. Now. Let's turn it around though think about. What. The networking opportunities and capabilities are of. Google. So. We have a. Major. Major of networking presence. Globally. With. Tremendous options. Up. And down the, stack, specifically. Dedicated to networking. Particularly. In this solution. We're. Looking at our. Cloud VPN, solution and this is what really enables you to do a fully. Zero footprint, installation. Ultimately. The. Key thing that the physical. Facility, needs to enable is the. VPN termination, if. They can enable, that VPN termination, in their networking, stack. Connected. To, its, endpoint. In the cloud that's. Basically all you have to do. Yes. There are other solutions you, can look at various interconnect. Solutions, for, higher, degrees of bandwidth, you can look at even. Point-to-point. Secure. Tunnel. Those. Are a little bit higher up the stack you, go from zero footprint to maybe 99 percent no, footprint so. Cloud, VPN was really, our our first. Intent. And our first interest to facilitate. This. Technology. The. The. Key. Consideration, here is that the. VPN, will route the traffic, to, the appropriate, IP address. Not. Just externally, but, also internally. As we continue. The conversation we look at kubernetes etc, we'll see how those all those IP. Considerations. Come into play. Project. So. I spent. A little bit of time earlier talking about this, in. Google. Cloud platform the, kind, of one, of the major areas of abstraction, in the system is what, we call the project and, if. For any of you who have worked with Google cloud platform platform. Previously, you'll, be familiar with this concept the, project, is where you, put all the things so, all, of your networking, resources, all of your, virtual, machines your kubernetes, clusters, etc. Etc they. All exist inside, of projects. In. Why. Should we consider projects. As a major, boundary, for the architecture, of the application. Data. Isolation. Obviously. As as, a technical. Provider technical, services provider I digital. Is looking to onboard many, many customers, we. Want to ensure that their, data is completely, isolated from any, of the other customers in the system, specifically. The the. Hard data the DICOM images themselves. Also. The project is where. Billing. Happens, so, when you create a project you create an Associated. Billing account and all, of the resources, and consumption of those resources within that project are, then charged into that billing account so, for.
An Organization, that's looking to onboard. Many. Many customers, you, want to have a very very close. Accounting. Of. What. Those underlying resources, are costing, so. This by, isolating, at the project, level you're, able to have a very very fine-grained, control or insight. Into, what. All of the resources are costing on a customer, by customer basis. Again. Due, to the fact that the project is the kind of base level of abstraction, all. Of the things that are in the project, healthcare. API. Google. Cloud buckets, of Google. Cloud Storage buckets. Virtual. Machines. Allocation. Of reserved external, IP addresses, etc, etc. All. Of those items, have quotas, associated, with them so. Quote. Management, is hat is handled, on a project-by-project, basis. So again, this is how you are able to isolate. Various. Customers, from, clobbering. Other. Customers, etc etc and they maintain, their entire individual. Ecosystem. And. Then finally security. Projects. Again not. Just data isolation, but access. To projects, are controlled via I am, GCP, I am which is identity, and access management and. You. Can have very very fine-grained, control over which, systems, which people, which accounts, which services, can access, all of the things within the project, so. For this particular implementation. Use, case without digital we. Have many projects, at play here we. Have production. Development. Demo. Where, I digital is able to spin, up a completely. De-identified. System and demo, it to prospective, customers, etc. What. You'll see is and. We'll, talk about it in particular. Logging. Again, cloud. Audit logging. Stack. Drive, these. Are all very. Important, pieces of the overall. Conversation. And what. We in health care and life sciences group within Google, Cloud recommend, as a HIPAA best practice. All. Of the projects. All of the independent. Projects in the system can outbound. Their logs, to. A audit. And logging, dedicated. Project, that. Can be staffed, specifically. By. Compliance. Compliance. Organization. Separate. Group of people no, bleed, anything. Like that a. Project. Per customer talked. About that a little bit and, finally. All of these pieces. Can. Be automated, and this, is this is one of the pieces of the word scale how, do you scale this solution to, accommodate. You. Know hopefully. You're going to do a good business you want to accommodate lots. And lots of customers. How. Do you as an organization. Enable, the onboarding, of all of these customers, and managing. Of all of these scenarios, it. Has to be automated so everything, we're going to talk about today can. Be automated, through cloud. Deployment, manager, g-cloud. Cube. Control. Kubernetes. Kubernetes. Is kind. Of the, base. Layer of, scaleable. Abstraction, from, a computational perspective and this. Particular, use. Case calls, for using kubernetes, to, scale both the MLP. And DICOM adapters, and. The, application. Specific, services. The. Key part here is that is, the networking so. The kubernetes, cluster itself, controls, the. Ingress. Networking. From. Your external on-prem, customers. To. Their, specific. MLP. And DICOM adapters. Of. Course, everything, in the kubernetes cluster is, connected. To the entire, logging, infrastructure, and. What. Kubernetes really brings to the tables as, I said the, ability to scale.
The Computation. But. On watch on which, ty mentioned do you scale how, do you determine when. You should scale. There's. New. Developments, of course always coming new developments, so GK enables, you to scale. On custom, metrics. So. For example MLP, is. Lightweight. From a data perspective it's, high message volume, DICOM. Is a little bit heavier because it's the actual image so. They. Have different scaling dimensions and, by. Integrating with custom, metrics for scaling they can scale independently. MLP. And DICOM adapters. This. Is really a lot of the meat, of the. Architecture. Google. Publishes. Open. Source, MLP. And document. Actors and, the. Way that you should think about them is as. A bridge on. One side. They. Receive. Legacy. MLP. And icon protocol, communication. On the. Other side, they. Egress. Healthcare. API. Protocol. So. This. Is the real workhorse here, this is what enables you to bridge. The. Legacy, on-prem, environment. The. Ubiquitous, presence. Of, these protocols in virtually. All hospital. Oriented, systems, around. The world, -. Your. Cloud-based solution. And. Again as I mentioned these, services, are exposed. Via. Private. Internal. Load. Balancer, IP addresses, those. Addresses, in turn are routed. Through the VPN. We. W know the kubernetes cluster basically. Plays double. Duty, in. Addition. To the hosting, the MLP and document actors we're also hosting, services. So. The classic service oriented architecture. Micro. Services. Pulling. Together a. Specific. Set of business logic to accommodate. A particular business task into, a specific. Process and. These. Processes. Do. Various things for example in, in this use case we're. Creating, orders, so as messages, come into the system, they. They, emit, notifications. Into cloud pub/sub we'll talk more about that in particular and, these. Services, listen, for those notifications, and, when they get those notifications they, do specific. Things so for example they might, listen. For a DICOM message and then. Create the Associated or M hl7, message. They. Might listen, for the RM angel 7 message and then create. An order. In the transactional, cloud sequel database in the I digital, application, itself. Resource. Matching, Omar was mentioned, that briefly how. Do you match an hl7 message. -. Its DICOM. Study how. Do you do all these things so and then, finally billing we highlight. Billing as well of course major. Component. Of the system. You. Want to think about how, those bills they need to be delivered to, those organizations. Healthcare. API, all. Kinds, of interesting things happening, here that. Patrick. Will talk about in specific, detail but some of the things that I wanted to highlight in particular for, this, use case and implementation, are. The. Data store architecture, design. So. We. We have highlighted, here in the application in the in the architecture, three. Different data stores one, for our M's and our use so that's requests. For, reports and then the report. Reply. Dfts. Detailed. Financial transaction, or in detailed. Financial transaction, hl7, messages and, then. Of course DICOM messages, so, or. Mor, you are in one data store dfts, are in another data store die, coms are in their own data store and we, had an interesting design this design decision to determine well, do we need one for real-time and do we need one for priors or.
For, Those not in the in the business the archive, of all of the, previous. Images that were done and. Due. To how different micro services we've architected. Various, micro services in the system, we. Decided to put them all together in one DICOM store. Each. Of those data. Stores then, output, into, their own cloud, pub/sub topic, and these, topics, of course are critical this, is where the micro, services listen, for various pieces of information put. In new, pieces of information. And. There. Are many ways to interact with these pub/sub stores the. Takeaway, for these, is that it's completely integrated, so, this is completely. Managed by, Google, cloud. Platform there's. All kinds of capabilities to interact with the queues to. Act or, acknowledge. Messages, from the queue or not, acknowledge, messages from the queue ensuring. That they get picked up at a later date, configurable. Retention, the messages stay around until they're processed, etc, etc. Bigquery. This, is really interesting part of the conversation, and I. Spoke a little bit about it at the intro omer mentioned it. Going. To the cloud shouldn't, be an apples, to apples conversation, it should be an apples, to fruit, basket, basket conversation. You, get all the things because, going to the cloud unlocks, all of, the other opportunities. In the cloud in, particular. Here we're highlighting bigquery, so bigquery is Google's. Data. Warehouse system. And. Once. You get data into bigquery you, can do all kinds of interesting things you. Can enable analytics. You can enable, more advanced, analytics, we, love to call machine learning sprink a little bit of machine learning on everything and everything's, better right. But. You got to get the data there first it has to get there. The. Way that we've designed the healthcare API is that it easily. Can. Export data into bigquery and. Cannot. Underestimate. Easy, easy, is incredibly. Important. Big queries got all the goodies it's scalable, it's fully managed. Auditable. Again. Integrates. With external. Reporting, tools like looker and our data studio tableau. Accessible. Via standard. Ansi sequel so, for those of you in the audience who have. A sequel background this is fantastic. A unity, viewer the unity viewer is the. DICOM. Viewer, itself, so this is a commercially. Available product, from. From. Another company we, integrated, it integrates, directly with, the healthcare API it's. Specifically, designed to have, various. Pieces of functionality, segmented. So, we have a front-end. Web. Application, we, have a data cache proxy, we. Also have a, computational. Engine. That, just executes. 3d. Volumetrics. And the. Key takeaway here is that because. It's. Delineated. You. Can execute. Civic fine-grained, access. Controls. The. I digital application, itself runs it's in its own project and it, has many. Different components. Running. In virtual, machines, using. Cloud sequel, storing, all its data in the transactional, database. Has. Its own access control for front end users and. Ultimately. Again. Is. Separated. From the. Services. That, access, various parts of the system so this is security. Isolation, and, reducing. That, footprint. That, might cause challenges. From a security perspective. Talked. A lot about the logging, separate. Project for logging, specifically. An, opportunity. To. Segment. All logs, and make them only available to your compliance organization. Again. HIPAA best practice. Isolation. Ability. To. Transfer. These logs into bigquery similar. To the clinical data do, all kinds of advanced, analytics, anomaly. Detection. Do we have problems or the, wrong people accessing this data etc. Etc. Finally. Because. This system is so. Flexible, you. Have the opportunity, to send. Your data to various billing providers, and the billing providers, of course. Like everybody else, don't. Really share standards, so. You need to be able to speak. To the, specific, billing provider that. Your, customer, has a contract, with and what are their capabilities, native, ap is. Being. Able to send specific billing, D of T's the, batching, CSVs. This. Again ties into the. Service. Micro. Service architecture, being, able to create. The right. Materialization. Of your billing log. And, get that sent to the provide to the billing provider in, the way that they can consume it. And. Again, it's the the, system here is delineated. Within, its own micro service architecture, so. With, that, just. A quick recap. This was a really very fast walkthrough of a complete, end-to-end architecture. With, zero on-prem footprint. Completely. In the cloud. Everything. Is operating the cloud using many different GCP function a pieces, of functionality everything, is automated everything, I talked about here, can.
Be Automated and we're working continuously, to do that to create the automation scripts, with. I digital cloud, deployment manager G cloud cube control, finally. We. Leverage many different, components of the cloud so. It's not just healthcare API you got to bring all the other pieces together. Networking. Security, bigquery. And, ultimately. The healthcare API itself is storing this very, critical healthcare data and with, that I want, to pass. The baton to, my colleague Patrick who will tell us more about the healthcare API. Thank. You Sasha so, so, what is the healthcare pie we've heard a lot about it in Sasha's architecture, so fundamentally. The way we think of it is it's a managed. Scalable. And secure platform for, your healthcare data so. We, built, the health KPI to be interoperable, so, it that means it can talk to your existing, systems, in the healthcare space and, it also supports industry, standards, that we encounter, in the healthcare space we've. Designed, it to be developer. Friendly and easy to use for our customers, of course. Security. And compliance are very, important concerns in the healthcare area so, we built the health KPI with robust security and compliance features, in mind. Finally. The health KPI is designed, to allow customers to really unlock the value of the data that they saw in it for. Example this is done by integrating, with powerful analytics, and machine learning solutions. So. As, we heard earlier in the talk, most. Customers, in the healthcare space today have data stored in a variety of different on-premise. Systems typically. Those are fairly fragmented. Or siloed, so you'll have separate. Data systems, for different types of data different, systems may be for different geographical. Locations you. Might have different systems, in different parts of a healthcare organization, and, it's very difficult for data to kind of like travel from one of those systems to another, so what, we've done with the health KPI, is we. Are aiming, to allow our customers to bring all their data together in a single place the. Way we've done that is by, integrating. With existing system so this includes packs. And VNA system so those are systems that customers use to manage their imaging data today and also, integrating, with EHR systems, which have structured, healthcare records. We. Heard a little bit about this earlier we support, natively. A number, of kind, of the most common, formats. That we encounter, in the healthcare area so, on the imaging side this is primarily, DICOM so DICOM is a format for storing medical images, and also the metadata pertaining, to those images on. The electronic, health records side we support, fire an hl7. We. Heard a little bit about the adapters, also so these are some open source components, that we've put out there to make it easier to interact, with what, we think of as the legacy protocols of exchanging, those types of data notably DICOM timsy as well, as mllp. So. What do we mean when we say the health K API is developer, friendly well. Like, most GCP, api's, it's, a modern, restful, api built, on top of HTTP. And gr pcs so the goal for us really was to allow customers, and developers, to focus on their business logic, while Google would worry about things, like backups, configuring.
VMs, And setting up databases, the. Health, KPI is a fully serverless. API so, so that means all scaling. And serving infrastructure, is all handled by Google's infrastructure. We. Integrated, the health KPI with Google Cloud console, so this provides our customers with a graphical, user interface, for easily managing, the, resources, stored in the API, cloud. Pub/sub I think we heard about it in Sasha's. Diagrams, this. Is just a very powerful, versatile. Mechanism, for plugging any kind of like custom, processing. Logic. Into, your healthcare workflow so we think of it as almost the Swiss Army knife of. Integrating. With our API. Healthcare. Data is probably. One of the most sensitive, types of data out there and I'm sure most of you will know that, the. Privacy is heavily, regulated in the healthcare space. So, that's. Why we designed the health KPI from the ground up with a very robust, set of security. And compliance features, built right in. Like. All of Google Cloud the health KPI is built, on top of Google's trusted, infrastructure, so it benefits, from the same multi-layered. Security. We. Have built in fine-grained. Access control, so this allows customers, to use cloud I am and specify. Exactly who gets access to what parts of their data and. Then they can also go to cloud audit logging, where they can verify who's actually looking at what and. Maybe detect any anomalies, that that, might have occurred. HIPAA, compliance, is, table, stakes when handling health. Care data with personal, information in it so we. Built the health, KPI to be to. Support HIPAA compliance, and we regularly sign, BAA. Agreements. With our customers, in the space which is a which is a legal requirement. We. Have also built the health KPI to support. Data locality so what this means is a customer, can specify where. In the world they want their data to be stored, this, is important, for health care customers in many jurisdictions where, there are data residency, requirements, that they have to comply with. One. Of the key benefits of using the cloud health KPI, is that it allows customers to bring all the health care data from where it resides today, and assemble. It in a single place where they can reason about it holistically, and finally, we also have some mechanisms. In the cloud health KPI that allows customers to then take those models and actually deploy them into a clinical, workflow. So. For. The remainder of the talk I'd like to walk you through three, key scenarios, or. Three key use cases that we've encountered, when. Working in this space so first of all I'd like to describe how. We can support research. And clinical viewing, of medical, images using the cloud healthcare pie, next.
I'll Talk a little bit about high, performance analytics. Using, bigquery and finally, I'll get into machine learning and how to train and deploy models, there, so. The. Health KPI is a is, a flexible, platform for, viewing medical, imaging data. Images. Can be ingested, into the healthcare pie either. From a PAC system directly, so this is kind of sim to what we saw in in some of the architecture, diagrams, previously, so where we have images, traveling, from from a non-parent pack system into the health ka P I may, be using one of our adapters, but, we also support bulk. Import from Google Cloud storage, and the nice thing about the bulk import piece is that it actually enables customers to use things like the transfer, appliance, so this is a tool that allows customers to do. Bulk loads of very large amounts of data that would maybe take a very long time to send over the network with, the transfer appliance we can bypass that and get it into the health K API more quickly, we. Have then worked with a number of partners, to build healthcare, API support, into medical medical imaging, viewers so we already heard about one of them unity there's. Another commercial, view. Or IMS that's also supporting, the cloud healthcare a P I but. We've also worked with a number of open source projects, so we asked this and ohef are a couple of open source viewers that that also can talk to the health KPI directly, so for all of these they can fetch the images directly from the API so it's a truly serverless end-to-end, viewing, experience. On. The, analytics, side of the story we rely heavily on bigquery. So bigquery is Google's, petabytes. Scale high, performance, analytics, engine it's something we built originally, for our own internal. Use at Google to understand, user behavior, on some of our consumer, facing products, so. Via, the cloud health KPI, we're, making this powerful tool available to our customers, in the healthcare space by allowing customers to load their healthcare data into, bigquery once. Their data is in bigquery becomes, very easy to join across, different, data modalities, join, in additional, datasets maybe, join in some public datasets we have some of those available like, the rxnorm, data. Set which is a prescription, drug database so. You can maybe come by and your healthcare records data your imaging metadata, and maybe some genomics, data and then you can sort of really start to reason about those so, there, is a, nearly, endless lists, of use, cases for this so I'm kind of highlighting, three of them here so we've got some customers, that are using bigquery to, identify. And select cohorts. To include in research, studies so, select. A list of patients for instance and then maybe materialize, their data de-identified, and hand it over to researchers. We've. Also seen customers using bigquery for clinical decision support, so this is an example where maybe. We want to find similar. Patients to the one that a provider, is currently looking at and finally. Because. Bigquery, is fast it allows fast turnaround, on queries so it's it's a very useful tool for iterating, on things like quality, and performance metrics. Where we want to start measuring things in the healthcare enterprise that very.
Hard To do in the existing, on-prem silos. Finally. Let's talk a little bit about machine, learning so, one. Of the key benefits of the cloud health KPI is that it can bring your health care data to, advanced machine, learning solutions. So these machine learning solutions, again can take advantage of the full spectrum of healthcare data it can healthcare. Records imaging, data genomics, data you name it, we, integrate with some powerful labeling. Tools so those can be used by customers to. Curate. High. Quality training datasets, for their machine learning use cases and then we can make those data and labels available, to cloud. Machine learning engine and auto ml which are some of the advanced, machine. Learning tools built into cloud built, into Google cloud platform so, cloud machine learning engine you can think of it as our hosted version of tensorflow so, this is something that allows serverless, training, of machine, learning models, Auto, ml is a tool that sort of specialized, for customers, that may not have a lot of data science the machine learning expertise, at their disposal and. And it's a powerful tool that it, can allow customers, to train, models even in those contexts. Finally, once the customers trained a model the health KPI can also help them deploy thus model back into their workflow so for example, if I have a model, that can help me understand, an x-ray image I can use the cloud health KPI to bring, the prediction from that model back into the existing, pack sphere so radiologists. Can view the model prediction, alongside, the images when they're doing their read. So. One. Thing I would like to announce is that the cloud health Kay API as of last week is actually available in public beta so that this means it's something that's now available to all Google cloud customers, to use, we. Also have some public, datasets but some public imaging data sets available hosted. On the cloud healthcare, API already, so this can be a great. Place for you to start playing with some of our viewer integrations. And maybe start trying out some of the some.
Of The tools that we discussed today so notably hi the NIH chest x-ray data set on there and we also have the cancer imaging archive on there, alright, so with that I'd like to thank you all for your attention.
2019-04-18