🦄 Making great presentations more accessible. This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Reclaiming Clinical Time: How Veradigm Uses AI to Transform Workflows (IND208)

In this video, AWS Healthcare AI team and Veradigm discuss reducing clinician administrative burden through AI-powered solutions. Himanshu Joshi presents AWS HealthScribe, a clinical documentation service that generates notes from patient-clinician conversations with real-time transcription, AI safety guardrails, and source attribution. New 2025 features include patient context integration, 18+ specialty support, and five new note templates (SOAP, GIRP, BIRP, SIRP). Ken Sheppard demonstrates Practice Fusion EHR’s HealthScribe integration, reporting providers save two hours daily with 65% requiring no training. Mirza Baig explains AWS HealthLake’s FHIR-based data foundation, offering subsecond latency and scalable architecture for AI agents. Veradigm chose HealthLake for its five-times cost reduction, managed scalability, and compliance support. The session emphasizes combining secure data foundations with purpose-built AI agents for seamless point-of-care experiences.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The Administrative Burden Crisis: Clinicians Drowning in Paperwork

Welcome, everyone. Good morning, and happy Friday as well. Welcome to our session today. I’m Himanshu Joshi. I’m a product leader on the AWS Healthcare AI team. We are a team within AWS focused on building purpose-built services for healthcare and life sciences customers. Today we’re going to discuss something which every clinician wishes they had more of. No guesses there: more time. Not more time on the keyboard or on more apps, but more time to face the patients and spend more time with their families.

So I’m pleased to have Mirza and Ken with me today to talk about how AWS and Veradigm are partnering to truly transform the point of care experiences for clinicians through autonomous AI scribing, as well as through secure data foundations. By the end of the session, you’ll get a deep understanding of how a combination of data foundations, purpose-built AI agents, and a great user experience at point of care can truly transform the clinician experience.

Okay, so let’s talk about the problem we are trying to solve here. It’s not news to anyone today: clinicians are literally drowning in paperwork. This is not what they went to med school for, right? Today, they spend an inordinate amount of time filling forms, chasing clinical documentation requirements, as well as conversing with various stakeholders in their own clinic or outside to deliver the care. It leads to burnout, with them spending more time on tasks versus truly facing the patient.

As per a very famous study on Forbes, for every one hour which the clinician spends with the patient, they spend two hours on clinical documentation and administrative tasks. It leads to a lot of burnout for these clinicians where even after going back to their homes, they have to spend time writing notes or even answering the messages from patients, and that leads to burnout, also known as pajama time in healthcare. So I think the big question for us is, what can we do to really solve this pain for clinicians and help them spend more time with the patients as well as with their own families?

Let’s briefly talk about what are these kinds of admin tasks at the point of care. If you look at this gamut of tasks, they happen across the life cycle. They start with even before the visit: clinicians have to go through a multitude of PDFs. If you see the infinite scroll on the right-hand side of the EHR to truly get the true longitudinal picture of a patient, they have to sometimes reconcile medication lists in case the patient visited a specialist and they again came back to the primary care provider.

At the point of care, they have to take shorthand notes while conversing with their patient, which sometimes does not lead to such a great experience for the patient. And even after the visit is over, they have to fill forms for prior authorization, converse with the medical and billing teams, and so on and so forth. So today, generative AI does provide a great opportunity to transform this experience for providers. And let’s talk about the how.

AWS’s Three-Layer Innovation Stack for Healthcare AI

We at AWS truly believe that solving this administrative task burden problem for clinicians is not just about the AI layer, right? There is no AI wand you typically just wave, and all of these administrative challenges for clinicians go away. We believe it’s a combination of an AI data foundation so that all the agents which are deployed at point of care truly have the entire patient context. Then on top of this secure data foundation, we have healthcare-specific agents, which are really purpose-built for doing a particular task well. It could be clinical documentation, it could be previous insights, it could be medical coding and so on and so forth, but really healthcare-specific agents.

And on top of it, these agents along with the data foundation have to be delivered at the point of care for the clinicians to use, right? Because if the end user experience for clinicians is not seamless, if they have to change multiple apps to get to use the right agent, again, there’ll be adoption challenges, right? But what are the challenges typically in doing stuff around the stack? The patient context is not easy to get in a singular format. It’s sometimes present in EHR in multiple different systems, PDFs, often not synthesized in discrete data format.

When you talk about generating notes at the point of care, the challenges around multi-speaker, multilingual, there’s code switching between

languages, such as English and Spanish, commonly known as Spanglish, and multi-specialty scenarios. There needs to be a lot of AI guardrails to ensure that whatever agents are developed and deployed at the point of care are highly secure and earn the trust of clinicians. Finally, integrating these agents seamlessly into the clinician workflow is essential so that clinicians have a super seamless experience deploying them.

So we at AWS are innovating across the entire stack to deliver this truly differentiated experience in partnership with our end customers such as Veradigm and other EHRs. If you look at this diagram, there are three typical layers which correspond to my previous point on innovating across three layers. AWS offers customers a secure healthcare AI data foundation through which they can store data from disparate formats into purpose-built data stores, which are AWS HealthLake, Health Imaging, and HealthOmics, depending on the type of data. If it’s clinical data, you can securely store it in HealthLake. If it’s imaging data, you can use Health Imaging, and for genomics, HealthOmics. All these services operate at petabyte scale and are used by tier one AWS customers and follow all the tight security and regulatory grade compliance for healthcare data and AI.

Then on top of it, we offer customers a suite of intelligent tools and agents. A case in point being AWS HealthScribe, which we’re going to go deeper into in today’s session. HealthScribe is a clinical documentation service purpose-built for generating clinical notes at the point of care. Our customers can also use a combination of AWS Bedrock and Agent Core to create custom agents to simplify the life of clinicians at the point of care. Finally, all these tools are available via APIs and SDKs which can be integrated by EHR and healthcare applications at the point of care to deliver a truly seamless experience for the end user, which are clinicians.

AWS HealthScribe: Real-Time Clinical Documentation with AI Safety Guardrails

So today, we’re going to go deeper into two of these services and talk about how Veradigm EHR has seamlessly integrated them into their workflow to deliver an experience for clinicians. Let’s go deeper into HealthScribe first. HealthScribe is, in very simple terms, a generative AI-based service which creates clinical notes from patient-clinician conversations. An easy way to understand what HealthScribe does is if HealthScribe is integrated at the point of care or within an EHR for a customer, clinicians can typically just tap on the mic and turn it on when the visit starts with the patient. HealthScribe’s ambient capabilities listen to this conversation, and by the time the visit is over, generate a very precise note for the clinician depending on their specialty or the visit type and so on and so forth.

I want to highlight three key specialties which HealthScribe provides to the end customers. First, it’s real-time clinical documentation. So the moment the clinician starts speaking with the patient, HealthScribe generates real-time transcripts which clinicians can keep verifying on the screen. Within a few seconds of the visit being over, it generates a precise note available at the point of care which clinicians can easily review and submit in the EHR. With HealthScribe, we have AI safety guardrails built in. For us, AI safety and guardrails is not an option. It is a mandatory capability for any AI agent which the healthcare team develops.

To go more deeper into it, every note generated by HealthScribe is grounded in the source data. For example, let’s say we go to the subjective section of the clinical note which HealthScribe generates. It will have reference to the original transcript or the conversation between patient and clinician, which the clinician can easily verify and get assurance that there are limited hallucinations and the notes are highly complete. The last part is the point of care SDK. This is something super important. We truly believe that the best experience for clinicians is where they don’t have to switch applications or make changes in their workflow. With our APIs and SDKs, HealthScribe can be easily integrated into any application, whether it’s an EHR or an ISV-based application, so that the clinicians can simply click on a button to turn on the mic and start speaking with HealthScribe.

Now, talking about what we are doing with HealthScribe, what are the new innovations we are building in 2025. Our end vision with HealthScribe is truly an experience where clinicians don’t have to make any edits to the note. The moment they speak with HealthScribe, they can keep on facing their patient, have an absolutely hands-free conversation, and towards the end, a note gets generated. They can simply review it with limited or no edits and submit it. We’ve been doing a bunch of innovations to make it possible, and I’m going to talk about a few now.

The first one is the patient context integration. Oftentimes, there are sections in the note which already have discrete data available in the EHR. Let’s say patient’s demographics and pronouns, and even let’s say problem list and so on and so forth. With a new launch of patient context integration, at the time of a new HealthScribe note being generated, customers can simply add patient context from the EHR or from their application, and we will seamlessly weave that in the note itself. The benefit to the end user is that they don’t have to repeat the same information which is already present in the EHR, such as demographics, let’s say certain allergies, or pronouns, etc. So it really makes that journey towards a no-edit-based experience a reality.

The next thing which we are super excited about is we have in 2025 also launched a new purpose-built AI model. We have fine-tuned a model purely for point-of-care clinical conversations. What that allows us is really highly precise note generation controls so that we can control the verbosity, completeness, and other aspects such as hallucinations in the note, really at a note and aligned level.

The third super exciting feature is we’ve launched five new note templates and tasks. Our customers across specialties in physical health and behavioral health keep on asking that, hey, could we already have pre-generated templates within HealthScribe? And when the final note appears, they don’t have to edit the note and adjust it to the format they required. This year we have launched five new integrated note templates including SOAP, GIRP, BIRP, and SIRP. These are note templates for behavioral health specialties and to truly make an experience where these clinicians do not have to edit the note at all.

Finally, we are starting to integrate tasks with HealthScribe. One of the tasks which clinicians typically have to do after a visit is write a patient-facing summary, which goes to the patient via an email or a printout and so on and so forth. Oftentimes what we’ve seen is the patient-facing summary for the end patient is maybe highly medical or technical in nature. They’re not easily able to understand it. So what we’re doing with HealthScribe is, if customers set a particular transaction or conversation as generate a patient-facing summary, we generate a patient summary which is super easy for patients to understand. It clearly talks about their medication, follow-ups, and all the steps so that the clinicians don’t have to write the patient-facing summary, and two, it is super easy for the patients to understand the next steps in the care journey.

And lastly, we have launched support for 18 plus new specialties to really go towards the vision of having a no-edit-based note. There are customers who have multiple specialties being supported across the practice, large group provider practices. In that case, now they love the experience where through single ambient AI service they can service the various specialties they offer. And finally, the specialist needs notes which are tailored to their specialty. For example, if you look at the way a cardiologist versus a dermatologist would write a note, they’ll be quite different. Now, all these specialty-specific nuances are already taken care of in HealthScribe.

Veradigm and Practice Fusion: Meeting the Overwhelming Demand for Ambient Scribe Technology

Okay, so I’m now going to invite Ken on stage, really talk about how they’ve been using HealthScribe in Practice Fusion EHR and talk about the delightful clinician experience which we’re offering. Thank you, Ken. So, my name is Ken Sheppard. I’m from Veradigm. My background is as a software engineer. Today we’re going to talk some tech, some products, some strategy, so kind of all those things. I’ll tell you a little about Veradigm. We have three teams.

We have the provider team where we have solutions for healthcare providers and patients. So that’s electronic health records, practice management systems, billing systems, and patient engagement systems. So everything a practice needs to run their business. We have a payer team, so they’re engaged with healthcare payers like Blue Cross Blue Shield, Medicare, and Medicaid, doing things like retrieving charts so they can adjudicate claims or creating point of care alerts for our practices so they can participate in value-based care. And then we have a life sciences business, so they take all of our data and they deliver real world data, real world evidence, and try to improve health outcomes through clinical trials. So that’s all about Veradigm.

And then we’re going to talk more specifically about our largest EHR today. It’s called Practice Fusion, and what Practice Fusion is doing with HealthScribe and HealthLake. Practice Fusion is targeted at small independent ambulatory providers. It’s not used in hospitals. It is used by some large practices, but the sweet spot is really kind of the one to three provider space. So it’s designed to be modern and accessible. It’s 100% running in AWS. Our mantra is live in five, so anybody right now could go to www.practicefusion.com, get a free trial, put in your credit card, start a subscription, and you have a real EHR. You send us your medical credentials, we enable you for e-prescribing, lab ordering, and you’re off to the races.

And that’s really important to reduce the administrative burden so that people can use our product and be supported easily. Again, because these practices are small and independent, they don’t have teams of people to train them, so it’s designed to be very streamlined, very simple, and very accessible. And the Practice Fusion platform is a pretty large footprint. There are five million patient visits on that platform a month, 660 million a year. While we’re talking, there’s going to be tens of thousands of people that are being seen on the platform getting e-prescriptions and charting happening.

Okay, next. So as Himanshu said, for every one hour a clinician spends taking care of patients, they spend two more hours on administrative tasks. A bulk of that is charting, but it could be all the other things, like prior authorizations and such. And I think we’ve all seen that the exam room computer is really a barrier to patient care. We’ve all been sitting on the table where our healthcare provider is pecking away on the computer. That’s clearly not, and that’s been going on for 20 or 30 years, that is not the best way to take care of patients.

So then, what we’ve heard from our customers over the last two years in our user survey, and the most recent one was just a few months ago, was the number one feature request is ambient scribe technology. I’ve been working in EHRs for over 10 years. I don’t remember a time where providers were actually asking for a new technology. Many of them would prefer to still be on paper, so this is a sea change. And 60% of our users are reporting using some form of ambient technology, which is staggering. That was not anywhere near that. We didn’t ask that question even two years ago. We asked a little different about dictation and such, but it was nowhere near that two years ago. So huge demand from our users.

And from a return on investment, ambient scribe is like all of the things. It saves providers time. It helps them produce better notes. If they produce better notes, they get better reimbursements. And ultimately it’s going to lead to better patient care. You’re going to be able to find clinical trials for patients, all these sorts of things. So tremendous ROI for ambient scribe.

Strategic Partnership: Why Veradigm Chose AWS HealthScribe for Product Fit and Rapid Deployment

Let’s go to the next one. So we chose to partner with AWS and deploy an ambient scribe solution backed by HealthScribe. And I’m going to spend a few minutes talking about kind of the strategy and our thinking on why we did that around product fit. So we think ambient scribe is here to stay. We think it needs to be an organic integral part of the EHR. We also think that the charting experience is going to evolve with AI, and ambient scribe is kind of the stepping off point for that

to connect lots of other AI capabilities. We needed something where we had a trusted partner that could deliver the foundations and then we could innovate on, versus in some places in our portfolio where we just bring in a partner and they offer it to our users. We are still, full stop, we still have scribe partners on our platform. We’re going to continue to have scribe platforms on our platform. But we think we can deliver an 80/20 solution. We think we can deliver a solution that meets their note quality expectations, getting to that zero edit in its place, that’s very simple, that’s at the right price. So that’s how we looked at the need for this hybrid build, buy, and partnership strategy.

The other challenge with product fit here is it’s generative AI, so it costs real money to run. It’s not a SaaS application where you’re probably not thinking a whole lot about how much compute you’re going to use or what your infrastructure cost is going to be. We determined the only way we could get market fit and build an economic model is to actually ship something. So we had to see how people were using it. With HealthScribe, it’s one API call, so we were able to have a very small team, smaller than a typical product team, build a safe, reliable scribe solution that we could go to market with to start to get this feedback, to build the economic model, and understand how long are the encounters they describe, how many encounters they describe, what’s their satisfaction with the note output, and all these other features.

That was very easy. We’re also able to build it on our platform using APIs versus embedding it deeply in our platform initially as a way to go faster, which has worked really well. We release every two weeks on the Practice Fusion platform, and because the scribe was built on the platform, it releases even more frequently. AWS gives us constant tempo of updates. We meet every week, we give them a long list of feedback from our users, and we get those updates. I think we recently added the pronoun support, and some of the stuff on Himanshu’s roadmap you’ll see in the product shortly.

The final thing that accelerated this process of going to market was what AWS has done with responsible AI. We’re in healthcare, so we have to be careful. There are real patient safety concerns if you have inaccuracies. There are bias and discrimination concerns. There’s government regulation from the ONC around predictive decision support intervention, which requires you to have a risk management program in place and model cards and a lot of documentation to make sure that it’s safe, to make sure it’s not biased or whatnot. AWS accelerated that because they had that in place, and that kind of got us 80% of the way there.

Additionally with AI, HealthScribe provides source attribution. You’ll see it in the demo, but all the transcription is shown, or we chose to show it side by side with the note and link it, and that gives our providers trust that it’s accurate and kind of crosses that technology adoption chasm because they see this is what you said and this is what the note said. We’ve gotten a lot of good feedback about that. At the end of this, this is really about us and why we chose HealthScribe. We were able to build the economic model, understand the usage, understand how we can go to market, get tons of feature feedback, and keep deploying it.

Transformative Outcomes: Two Hours Saved Per Day and Zero Training Required

Most important is what were the outcomes for our providers. Number one is they saved a tremendous amount of time. This is almost unbelievable. They estimate two hours per day saved per provider. This is a combination of surveys and us looking at analytics from providers that are using the system extensively. If they use it for one encounter a day, no, they don’t save two hours.

But there’s lots of published data that scribes can do this type of thing, and so we love that. It was very easy to adopt.

So 65% of our users needed no training, and I don’t mean human training, I mean watching the videos or whatever. Most of them could literally click to launch, hit record, understand what’s happening, hit pause when you’re done, and hit save. That’s it, so that’s great and it goes to our ethos of self-service. We saw a lot of good qualitative feedback about patient focus. So 4.6 out of 5, scribe has reduced charting time while with my patients. I have some quotes on that too. I mean that’s where we really want to get. We really want providers to be able to focus more on their patients, and lots of other data out there too around how patient satisfaction increases when you’re using scribes because of that personal attention, I think.

And then we learned a lot about note preferences in our providers who gave us a lot of feedback. There was a lot of satisfaction with note thoroughness. In some areas providers have very diverse preferences. Some people want bullets, some people want narratives, some people want short narratives, some people want long narratives. Some people want the pronoun of the sex of the patients, some people want the pronoun that’s stored in the EHR, some people want to call them they, some people probably want them called patient. So there’s all these preferences that we’ve been working with the AWS team for AWS HealthScribe to support, and we’ve deployed many of those.

So here’s a quote. This is what we kind of like to see. Scribe allowed me to complete 95% of my notes immediately after seeing the patient, even more so than other AI ambient scribes I’ve tried. Again, the goal here, and I think everyone’s going to get there, is zero edits. Whether it’s this month or next year, I think every scribe, AWS HealthScribe is going to get to zero edits, and which would then allow us to just expand the AI capabilities of the platform. So another quote, scribe is making me more efficient. They’re called the HPI section and plan or verbal things. I’m not typing those out anymore. Scribe is capturing them well. I’m putting them in my note. Otherwise, when I’m in the room, I’m typing to keep up with them. All I have to do now is just go back and read the note from Scribe. So this is what we like to hear. And again, this is where we think we’re going to get to, you know, 100%.

Live Demo and Future Roadmap: Analytics, Patient Context, and the Path to Zero Edits

OK, so I’m going to do a demo. This demo is a little rough, I’ll be transparent. EHR is very information dense. This is information dense. We kind of blew it up to full screen. What you’re going to see in a second is just a short video of us launching the scribe in the full screen so you can see it, an encounter being transcribed, so you see the transcription and the evidence, or sorry, yeah, the transcription is the evidence, but the transcription and the note. And then you’ll see the actual generated note, and then you’ll see it get saved so it populates in the actual encounter for the patient, so if I just click, let this go.

Oh it’s playing. OK, it’s playing. Yay. So yeah, on the left you can see the transcript. So this is already started. They just hit save. It takes a few seconds to generate the note, so on the left you see the transcript with the evidence, and then this is the actual note it generated, and then they can save it to Practice Fusion.

So a couple things we built it again, we want to iterate fast so we built it to be dead simple. We get a lot of good feedback about that. We also built it, this is the first time we’ve built something in the EHR in a separate window. We thought that was suboptimal, but we’re actually getting a lot of good feedback that because our provider, a big use case for the scribe is you put it on your phone and use that as a microphone in the office, right. So having it as a separate window is working well for us now. As more AI capabilities come online, things like coding and agents and such, it will get built more deeply in the EHR.

You can see not a lot of real estate, so we have gotten actually good feedback about the separate window. So let’s go to the next one.

Okay, so what’s next? We’re working with AWS to develop analytics to compare the scribe-generated note to the final note. To me this is super cool and super exciting. There are not that many features where you can get this kind of quantitative data, so we will be able to measure how many edits did they make, how long did those edits take, did they change a drug name because we got it wrong, did they convert a paragraph to bullets. And we can do that on every note, so near real-time feedback about is it meeting the provider expectations. Also a good risk mitigation for safety, and we can have a big party when we start seeing a lot of zero edits, right, because that’s where we want to go.

So we’re working with AWS to create this pipeline and eventually we think the data will be really good about the time savings and how few edits there are. We’ll see. As I said, we’re going to continue with deeper integration in the EHR. We’re rolling it out the way it is now. It’s working well and taking on new features, and then at some point, hopefully soon, we will GA to all of our users. Right now we’re limiting who has access to it so we can iterate on these features.

As an AWS HealthScribe partner, our intent is to release new features as they come out from HealthScribe, so they give them to us in beta. We test them, make sure they work for our use cases, and release them. And then I think what’s next is coming, which is the amount you mentioned is pretty exciting, is patient context, because to be really specific, certain visits don’t work without patient context. So if you have a very brief follow-up visit and the doctor’s like, how are you doing, and you’re like, oh, I’m great, they’re like, okay, well, you know, give me a call if you have a problem, HealthScribe doesn’t work. I mean it doesn’t work. It doesn’t have context.

But with us being on the path to inject context into that encounter, it will know, oh, you’re here for a follow-up visit for your shoulder surgery and be able to generate an appropriate note. So it’ll also, I think, ultimately make better decisions because it has context, whether it’s demographics or problems or whatnot. So super excited about that and that it is coming. Okay, so I’m going to hand it back to Mirza and talk about HealthLake.

Breaking Down Data Silos: FHIR as the Common Data Model for Patient Context

Thank you, Ken. Everybody hear me okay? Excellent. So my name is Mirza Baig. I’m part of the Healthcare AI team, same team as Himanshu who was speaking earlier on the stage. So the last point that Ken mentioned was around patient context. And patient context obviously is embedded in a variety of different documents and different silos, and that’s essentially preventing the true potential of all the AI agents that are in play.

So one of the things about data silos is that in this particular instance anyway, data is in multiple tables, right, 500 plus tables that are perhaps in an EHR or some relational database. Additionally, you have the data present in a variety of different formats either in terms of storage or in terms of exposition or whenever that data is particularly shared. So you may have, for instance, CCDAs that are being shared or the fact that the data is in relational and then as a CSV is being spit out. So you have that piece of it, but you also have the ontology piece of it which also complicates, adds an additional layer of complication on top of it, right.

By ontologies, I mean the ICD-10 code. So for instance, if HbA1c is referenced and there’s a 7.1 figure there, is it in milligrams, is it in, right, what’s the unit value, for instance? Was it done via a lab, right? Was it a lab that had a specific CPT code versus a home device, for instance, which has a different CPT code, right? Was it type 1 diabetes or was it type 2, right? There’s an ICD-10 association with that. So all of these various things are sort of additional layers on top of the multiple formats and also the ontologies that complicate the collation of data for analysis and are making it available from an agentic perspective. So you have that layer as well. And then as you all know, right, majority of the data is actually in unstructured format.

It’s embedded in notes with both Himanshu and Ken talking about note generation. Ultimately, the next time the patient visits, the context that was generated in the note has to be brought in as the patient encounter is going to happen the next time. Plus, all the various encounters that happened in the past as well. You may have hundreds or thousands of pages of notes that are essentially unmined, and not just unmined, but you also have the various ontologies that perhaps are not clear enough for it to be taken as a nugget of information from an insight perspective. So you have all these various complications and various silos.

I want you to concentrate on the middle part of the screen and not on the left-hand part of the screen. What we have decided from a tech stack perspective is to hone in on a common data model. That common data model is FHIR. It’s not AWS’s. It’s an open source. There’s a community aspect to it that basically creates this particular common data model, and that common data model has an overall RESTful API architecture. What that means is, for instance, if you say that you have a FHIR API endpoint, I know in order for me to get, let’s say, the first name or the last name of a patient, there is a specific URL search string that I need to employ in order to fetch that information. It could be like base URL slash patient or patient question mark, if you’re fetching my information. It’s consistent across the board. You’re not reinventing the wheel.

So it’s a standardized data format that makes it all available, not just in terms of how the data persists, but how that data is also exposed back through APIs, through search parameters, and so on. One of the key things that I want you to understand is that this is all referential, it’s not relational. What this means is that, for instance, let’s say in the encounter, there’s an observation. That observation is related to an encounter. That encounter is related to, let’s say, a condition, and the condition is related to a patient. The patient has a relationship with a practitioner. The practitioner has a relationship with an organization that he or she belongs to. So you have these, you can almost walk the graph in terms of creating this particular referential dots, these connections across the board. So that makes it much easier for you to be able to provide context.

Ultimately, it’s not just about the patient data or the condition, of course it’s about that as well, but it’s also about the healthcare system, the healthcare provision system that makes it happen, and that is all part and parcel of the various references that are available in this common data model. So the healthcare-specific context and, of course, the schema part of it as well is fairly prescriptive. Meaning, for instance, if I want to store a LOINC code associated with checking for my HbA1C, for instance, there is a code system and a value set that is referenced when that assertion is made. Meaning I’m not simply, the doctor may simply say or obviously put in the EHR that do this particular test, but that test has a reference in terms of what that value means. There’s a LOINC code that has a specific CPT assertion to it that then combines, and then that particular test is done.

And when the results are reconsumed back, that reference back to that order vis-à-vis the code systems and the value sets, plus the unit value that came out as an outcome for that particular result, are all stored in this particular schema, which is ripe and available for you to be able to pull that nugget out without the model or the agent having to think about or take a guess on what that means. So all of that overall is part of the overall standardized healthcare resources. On the left-hand side, obviously, you have all these various use cases. HealthScribe can plug into that. You have multiple agents, could be proprietary, could be first party, could be third party. So you have all of those various things.

AWS HealthLake Architecture: Subsecond Latency and Analytics at Scale

This particular slide essentially puts it in a different sort of lens because I am not talking about the data model here. I am actually talking about how that overall environment actually works symbiotically and seamlessly together. So on the left-hand side, I’ve described to you all the various different sources, and there are more. I’m sure you are experienced with them as well. In the middle ribbon,

you have the various formats, and then there is a translation layer with data transformation agents, with partners and conversion that needs to happen. But that data eventually gets into HealthLake, and HealthLake then also has an integration with an MCP server, which then allows you to do queries and searches and summarizations as well for your overall patient context.

Again, context is important. The fact that Mirza has a heart condition, let’s say cardiomyopathy, that has meaning from a patient encounter perspective that the doctor and everybody else has to be aware of whenever that encounter is happening. So summarization and bringing that nugget forward as a sort of key piece of information, and then all of that being consumed at this top layer, which is these use case specific AI agents. So I’ve spoken about first the model. The second slide was essentially around how that model fits in this overall reference architecture, and this particular slide is speaking about the actual service itself.

The service I’m talking about is HealthLake in terms of the fact that there is subsecond latency, which is extremely important in the case of Veradigm, for instance, because ultimately it’s about patient care. Physicians and providers do not want to wait even a minute. The latency is extremely important for it to be responsive and for adoption perspective as well. You all know this, so it’s built for performance, it’s built for scale, hundreds of terabytes of data.

Ken mentioned, for instance, that there are 60 million encounters annually on that particular Practice Fusion platform. That’s a hell of a lot of encounters. There’s a lot of data that gets created based on those encounters, and you need to be able to do it whether you’re doing it for 10 gigabytes of data or 100 terabytes of data. That subsecond latency is extremely important, so performance, AWS built for scale and performance. And then of course analytics is part of it, meaning that same data can now be analyzed in an Iceberg table because as a managed service, HealthLake has this component where that data is also then transformed into an Iceberg table for you to be able to analyze.

You use Redshift, Athena, bring in your third party as well, Databricks, Snowflake, etc., so that way you can actually go ahead and analyze that data, that resultant data, and also make that available to your AI agents as well. So with that, what I’d like to do is actually bring back Ken for the next couple of slides. Thank you. Yeah, I’m going to talk a little about HealthLake, make a little commentary on the unstructured data problem.

You know, healthcare providers are really busy and getting squeezed on reimbursements and such. They don’t have, you would imagine as an engineer they would want to put all the structured data in there possible for some future use case. It doesn’t tend to be what they do. They’re busy, they put free text notes, so obviously AI is unlocking that, is now turning those NLP notes into structured data, but that continues to be a huge challenge.

Veradigm’s HealthLake Migration: Five Times Cost Reduction and AI-Enabled Data Infrastructure

So I want to start with a little history about why EHRs and why Practice Fusion is using FHIR and FHIR servers, because I’m sure everyone understands the ecosystem here. You know, to be a certified EHR means that you can use that product and get reimbursements from the government, Medicare, Medicaid, ONC, Tricare, whatever, largest payer. They, just like any business would, they have requirements on the technology that gets used, and those are called being a certified EHR. So every year or so we have to recertify to new requirements that the government puts on EHRs because they’re trying to control costs, improve health outcomes, all makes sense.

One of the requirements from 2023 was to offer a full set of FHIR APIs to app developers. So it’s a documented API, it’s FHIR, it’s JSON, has several OAuth flows, a patient flow, provider flow, pretty modern. So in 2023, you know, to meet that requirement, we deployed our first FHIR server using a partner. I don’t think 99% of our Practice Fusion users had heard of FHIR, could spell FHIR.

So we did a very small investment to meet our requirements because our users wanted us to work on other stuff. Now fast forward two years later, these FHIR servers are getting used extensively. There are many thousands of practices that signed up. There are hundreds of apps, and 60% of the apps in our marketplace have some kind of AI hook, so we’re seeing more load, unpredictable load. We’re seeing, unfortunately, our current capabilities limit what AI can do because we have to rate limit things and such.

For all those reasons, our current solution is expensive, so we looked at HealthLake. HealthLake is about five times cheaper than our current solution. HealthLake is fully managed, so it’s really a black box in a good way. We have to build some software around it, but it does what it’s supposed to do. It’s there, it’s available, it scales, and it meets its uptime, availability, and performance SLAs. Again, it’s scalable, so our practices can onboard themselves, they can onboard clients, apps, and API clients. We can use HealthLake as an additional read, eventually assisting read load for internal workloads and take them off of our legacy systems, so the scalability is fantastic.

Another thing that’s important to us is compliance. This is driven by or was driven by the government. We have to maintain our compliance. Currently we’re at FHIR R4 US Core 6, I think, but every year there will be changes. Maybe there’s FHIR R5 or FHIR R6 next year, and AWS is committed to supporting that. So we know we can maintain our certification. We’re not going to have to do schema migrations or deploy new hardware, so that is a great place to be for us.

Again, for completeness, I will say it’s not just the government now. FHIR has become the absolute interoperability standard. It’s a standard for AI interoperability. It’s here. And then leaning in and looking ahead, I think Himanshu mentioned AI enabling data is hard. AI enabling EHR data is very hard. It’s unstructured, it’s deeply nested, there’s all these relationships. You can imagine ETLing into other data stores and putting it into vector stores and graph RAG and all this heavy lifting, keeping it up to date. It’s hard, but we think HealthLake is going to make it a lot easier.

So first thing, get the data in one place, right? If we can get all of our healthcare data in one place, that is a boon. And some of the stuff you saw on the previous roadmap and some of the stuff we imagine coming with agents and MCP and such will allow AI to more easily consume that data, which is great because otherwise someone’s got to pull the FHIR data, put it in another data store, put it in vector stores, all the heavy lifting, right? So we expect that HealthLake will enable AI innovations for us.

And then leaning in a little more, we’ve been talking about reading data, well, HealthLake is a great place to land AI generated data, AI inferences. So an EHR with its relational schema, no one really thought about AI inferences. Relational schemas are slow to work on, risky, whereas with HealthLake, if I infer a condition or an observation, that’s the HTTP PUT or POST of that JSON element. I can mark that it’s AI generated, and it can become the source of record for that inference that then the EHR can read or other AI consumers or APIs can read. So that’s longer term, our intent to start allowing AI data to be written there.

Anything else I want to say here? So this is very much why we chose it. Here’s a very simplified architecture of what we’re doing, kind of hello world, but we have the EHR on the left. It has its relational database. It has DynamoDB and S3 and Redis, lots of other stuff too, but the big hitters are relational, and it’s going to stream its data into HealthLake.

On the right, we have AI clients, interoperability clients, and our bespoke APIs. All of those can now read off of AWS HealthLake without worrying about scale, which is a nice place to be. This gets loads off of DynamoDB and other systems. In the long run, we would like these AI clients to be able to write their inferences back to AWS HealthLake. So whether it’s a third-party solution, whether it’s AWS HealthScribe generating more and more inferences, codes, or whatever, or our own Amazon Bedrock-based AI solutions, those can all write to AWS HealthLake, and it can become the source of record for that data.

Then the EHR can make a choice. It can say, well, I’ll just render it from AWS HealthLake because it performs well. It’s called the lake, but it’s really like a document database in terms of performance. The EHR can make a choice: Do I want to ingest that data? Do I want to incorporate it? What do I want to do with it? We like this vision of the future architecture as a way to AI-enable our data and provide more AI solutions to our customers.

What else? Okay, so what’s next? We are migrating our clients to AWS HealthLake, so we have our legacy solution and we have AWS HealthLake running in production. We’re migrating our clients, managing bubble costs and all that. We intend to enable AI clients to use AWS HealthLake as their primary read store, so it’s enabled, it’s encouraged. Let’s increase rate limits, all that sort of thing, so they know they can really win on our platform and provide AI solutions to our customers.

We intend to migrate additional workloads to AWS HealthLake. I mentioned we have a payer business. The payer business delivers FHIR bundles and CCDAs to payers. Let’s get them from here because this is actually super pristine data. It also has all the security tagging and restricted disclosure rules. Those are all embedded in FHIR, so you can deliver data in a compliant way. Then leaning into it again, we’re not doing this now, but we intend to let AI clients use AWS HealthLake to store those inferences because I think that would be tremendously agile.

Okay, that’s what I have. So back to Mirza there. Yeah, thank you. Please go ahead and just stay on the stage. We have two more slides. So one is just to encourage you all to start building with AWS HealthLake, not just with AWS HealthLake but also with AWS HealthScribe as well. AWS HealthLake, obviously, just a quick note: you can basically spin up a data store by going to the AWS console in less than 30 minutes, and you will have one ready to go from a testing or development perspective.

Similarly with AWS HealthScribe, you can also go to the console. You can basically mimic a conversation, and it will then go ahead and create a note for you so you can start testing out. There’s an SDK that’s also available that you can leverage as well. But the point of it is to basically give you the tools for you to be able to start not just capturing pristine, accurate, relevant notes, but also then enabling that note with a wider contextual setup on a common data model, which is basically the combination of AWS HealthLake and AWS HealthScribe, which is what we’re basically proposing here and what Ken was speaking to about Veradigm as well.

So common data model, enterprise-grade FHIR resources, security, and performance, along with the controls that we had talked about with AWS HealthScribe as well in terms of responsible AI guardrails. All of those are both managed services, meaning you’re not having to do the stitching of all the various different components in the backend. You’re literally just leveraging the APIs, and off you go, because then you can focus more on the higher-value propositions that you and your teams are essentially building. So that’s the key takeaway that we want you to walk out with.

And then, of course, build transformative healthcare experiences as well by bringing in natural language querying interfaces and the fact that all of that data is available for you to be able to then trigger additional workloads that perhaps are also potentially calling other agents that you may be leveraging as well. So with that, we have two QR codes in case you want to capture those. If you don’t happen to capture them, just go to AWS.com/healthlake or AWS.com/healthscribe, and you would be ready to go because the product pages would essentially lead you to the console and any other information that you may need to start testing and using.

Any last words, Ken, Himanshu? I’d better answer your questions before we wrap up. Yeah, yeah, so I think we are available for a few minutes post the session. Happy to engage, as Ken was mentioning. Thank you so much.

---

; This article is entirely auto-generated using Amazon Bedrock.