Don’t be data poor — Anuj Iravane, Anterior

0:01 [music] >> Hello everyone. Welcome to Don't Be Data Poor. My name's Anuj. I I lead AI at Anterior. Um just a bit about Anterior, we are a

0:22 clinician-led AI company um built for health plans backed by Sequoia and NEA. Um and what we do is we run AI transformations for health plans. Um as part of which we build agents for

0:35 several high-stakes healthcare administrative workflows in production. Um things like prior authorization, payment integrity, HEDIS measures, etc. Um it's it's okay if you're not familiar

0:45 with any of these workflows um because a lot of the work that we do can actually be summarized in in the same way. It's uh policy-guided decision-making over

0:55 highly unstructured data. And the unstructured data looks something like this, right? You have uh you have these scanned fax bundles containing medical records full of

1:05 patient information. Um a not-so-fun fact is that I think around 70% of medical communication still happens via fax. Um and fortunately or unfortunately,

1:15 this is the data that we end up working with the most. Um it is a very rich and information-dense data that we see here. Um the data distribution here is it

1:27 comes from a very long tail of rare um cases with a nuanced scenarios. Uh it models an entire clinical trajectory for a patient. Uh and every single person's journey is very different.

1:38 Uh it also presents itself in various formats. So, you have like things like bad handwriting, tables, checkboxes, um key-value pairs, images, um a lot of stuff here to deal with.

1:50 But I personally think it's a very fascinating source of data that we see here. Like it's it's it's like sort of like an observation through a very fuzzy lens

1:57 over an entire person's lifespan. It's really unique. And I'm sure you must have heard this like enough times today already, but in healthcare

2:07 the the baselines for accuracy are just exceptionally high. 95% is not good enough. Um And at Anterior, this is why we invest very deeply in datasets and emails.

2:18 And these unstructured medical records are a staple source of data for these emails. And we we work with this kind of data in almost every workflow that we try to

2:27 automate. But the problem is we can't really keep this data. It's PHI, it's highly protected. We can't retain it, we can't reuse it, we can't even derive

2:36 information from it. And most of our contracts prohibit us from from doing anything like that. Um even things like redacting it, anonymizing it, and keeping derivative

2:45 copies like is a strict no-no, completely off the table. So, nothing really survives in any sort of dataset that we want to persist over a period of time.

2:54 >> [snorts] >> So, so what this talk is about is like what do you do when the dataset you most need is also the data you're least allowed to keep.

3:05 And the and the bet that we the answer that we put our bets on is that we can kind of synthetically generate this data ourselves. There's been a lot of focus on synthetic

3:15 data recently. You have like Frontier Labs striving to generate synthetic data for continued pre-training, for RL, for computer use, for agents.

3:23 So, it's it's it's a hot topic and it's it's a hot topic on our minds as well. And the moment you say generate, like the first thing that comes to mind is, okay, can we can we try to use an LLM to

3:32 generate synthetic data? And I think you can. I personally believe LLMs are a fantastic tool to generate synthetic data. And several teams have already demonstrated

3:42 this already. There's been some papers in the healthcare space, outside the healthcare space, people have successfully used LLMs to generate synthetic data for for different

3:51 purposes. There are some known challenges in trying to use these elements to create data especially when you're trying to one shot the whole process.

3:59 Uh it's really hard to generate diverse realistic looking synthetic records. And this is even more of a problem when you're trying to do when you're trying to do this at scale.

4:08 So, uh often times these medical records are over 300 pages long and it's like imagining if you wouldn't ask an LLM to write a novel for you in one shot,

4:17 right? So, it's the same reason why you wouldn't use an LLM to just one shot a synthetic record for you. Um and LLMs seem to suffer from this very strange mode collapse problem when

4:26 it comes to generating like diverse uh data, creative data. And I think there's two main reasons for it. Uh the first one is uh like I just mentioned in the talk

4:35 earlier, there's very little exposure to this data source in the pre-training data corpus. Um and today's objectives for pre-training and post-training are are

4:44 largely uh they're only they're not incentivized for creativity or diversity really. They're incentivized to be helpful systems.

4:53 So, with these challenges in mind, uh I'll walk you through like one of our approaches in how we uh managed to build a pipeline to generate synthetic data. Um earlier I mentioned our forward tasks

5:03 look something like this, right? So, you have workflows and tasks that uh start with some unstructured data and a policy. Um

5:10 and you execute your policy against that data. You follow this reasoning trace through it uh and you arrive at some sort of an outcome, which is your label. So, this

5:18 is our forward task. Uh and the idea we had was to try and reverse this process. Uh can we actually start by sampling a random label, uh

5:30 figuring out a a reasoning trace for that label, and then trying to generate data backwards from that? Uh the idea here being that if you can actually uh sample these two things uh

5:39 with enough diversity, uh we will have we will be able to generate data that's conditioned on diverse set of inputs, allowing us to kind of

5:47 circumvent the diversity problem a little bit. Uh so just a quick aside on policies. We've talked about policies a bit, but uh let me just clarify what these really

5:55 mean, right? So, this is an example policy we have for for a CPAP device for patients. Uh this particular one is for a medical necessity review workflow. Uh and it it sort of outlines all these

6:06 diverse set of conditions uh that a patient might have um in which a CPAP device should be approved or or rejected. Um so and this policy, as well as many

6:16 other policies, uh you can think of these as uh essentially decision trees that outline all these sorts of conditions um

6:23 um that that dictate how some outcomes are met. And at Antheir, actually, we we spend a lot of time and energy in trying to model these policies explicitly as

6:31 decision trees. Um uh we work with uh symbolic representation uh similar to decision trees, uh and it helps us achieve a better accuracy uh

6:40 and consistency score when executing them in LLM-based workflow. And and the reason why I'm bringing this up is that uh by having this sort of symbolic representation of a policy, you

6:51 actually have uh a way to kind of deterministically sample different reasoning traces for a given outcome. So, back to our idea of like reversing the process, right? Uh this this

7:02 sampling of reasoning traces from the policies uh what helps us get that diverse conditioning input to then generate medical records from. Uh

7:10 and the key idea here is that the distribution here uh that we sample from is is a much more uniform uh and effective prior distribution than what you'd normally get from an LLM.

7:19 Uh one added benefit of sampling this way is that, in theory, you're able to test uh for far more scenarios than you would likely get from production data sources.

7:27 So, what I mean by that is like say you get a sample of uh 200 cases from your customer uh um and and and and you try to like have an

7:35 eval that measures performance against that, and you get a 95% score. Uh it doesn't really tell you about uh what you what your performance would be in those rare edge cases that are not in

7:44 that data set. There'll always be rare edge cases uh that are outside the distribution just because of the fact that our data is so uh highly variant. So, uh for those for those family with

7:54 Cynthia, like uh they follow a similar pattern uh of sampling scenarios from a symbolic causal state representation. There's a few of the folks in the space who are uh working with these symbolic

8:03 representations to uh to generate diversity in synthetic data generation. So, let me walk you through the rest of the pipeline. All right? So, uh once we have this diverse set of samples as a

8:15 conditioning input, what we did was we built an LLM-based pipeline that uh follows uh a coarse-to-fine pattern to progressively uh uh build up a medical record layer by

8:25 layer. So, here we first start with creating some patient invariants like the biological sex, the birth date, the blood group.

8:33 Uh we use that along with a recent trace uh with an LLM again to produce an ordered list of uh events and provider that a patient might have had, and we call this the patient journey. So, this

8:44 is a high-level uh you can think of it as a high-level uh overview of what a patient might have gone through in their lifespan um

8:50 uh captured by a list of events on a high uh in natural language. And in the real world, it is actually only during these uh uh encounters provider encounters that documentation

9:02 is really generated. At least for the data that we get uh uh most of our data source data is generated during these provider encounters. So, we model exactly that in our pipeline.

9:12 Uh we first generate a document plan for each encounter, and then based on that and the preceding history of the uh of the patient, we

9:19 uh we fan out into generating the actual documents uh um to hydrate them with actual synthetic information. Uh and this coarse-to-fine layering uh

9:28 is actually what allows us to keep uh uh the different prompt payloads in the pipeline uh very token efficient uh from both input and output perspective. While also enabling

9:38 this also helps us enable the scale across longer patient journey. So, you can scale this pipeline. You can have a much longer patient journey and you can just fan out and generate

9:47 documents that way without overloading the context windows of your LLMs. Finally, we have the sort of refinement loop in the end that we that uses a set of emails to

9:58 provide feedback to improve specific parts of the generated documents. For example, one of the emails we have is an LLM based check for consistency

10:07 between all documents. So, this makes sure that there's no contradictions or inaccuracies or conflicting information between two documents that are generated. This is important because we

10:18 we have a parallel fan out process that is used to generate these documents independently. And because we started with the labels for this particular pipeline run,

10:29 uh what we actually also have is an ability to kind of use those labels run and and and compare those against the generated medical records to see if

10:40 the tasks that we originally used actually matches the data is in accordance with the task inputs and outputs. So, we can do this sort of round trip check to ensure that

10:48 our data is actually in sync and by default get the correct labels by construction. So, in theory, this is a very nice property to have.

10:56 Like you can basically skip the ground truth and expensive ground truth in process you need for for data for fair data.

11:04 One thing to clarify here is that so far all the generation has been happening just in plain text and markdown text. It is possible to go from that to a

11:14 rendered PDF. But we don't really see much value in doing that because we have state of the art PDF parsers today available to everyone and they just

11:24 allow you to convert any sort of complex PDF into a nice markdown representation. So, all of this synthetic generation Um, evaluation happens in the text domain. So, this is just an example of like a

11:35 pipeline that we created from scratch and it's it's very easy to build. It's largely fully LM based. Um, but but who came up with this, right? Like who who am I to

11:44 uh know anything about what a good medical record looks like? Uh So, how do we know if this is any good? And uh I think this has been mentioned a

11:53 few times today already, but like you really don't. Like uh no way AI engineer would ever would. Like you want your domain experts to be the ones telling you what's good, what's not good. Um,

12:03 and which is why we believe that uh it is of great value to empower your domain experts to own your whole data pipeline. And specifically, we uh we do this in two ways, right? Uh we enable our

12:17 clinicians to kind of interject at each point uh in the generation process with a human-in-the-loop mechanism. So, at any

12:24 point, a clinician can steer the generation process to make uh a medical record in the way they want it. Uh we often see our clinicians use this uh to to first look at cases that happen in

12:34 production, get some interesting ideas, and then use that use those ideas along with this uh steering in this pipeline to make uh cases that look similar to what we might see in production or

12:44 they've seen in production. And this is what makes the data generated from this really useful, right? Like you can actually model your uh your failure cases um beforehand or

12:53 even after they after you see them in production. And secondly, I think most importantly, we let our clinicians also own the whole logic of the pipeline.

13:03 Um, we do this by modeling the whole pipeline as a skills-based workflow running on a generic uh agent harness that we built internally. So, every every uh kind of section here

13:14 you see uh all the way from the patient journey to the document generation to the document enrichment to the evals, all of these things are skills uh that run on our agent harness.

13:27 As an example, if a clinician wanted to uh say maybe add support for a new document type, let's say for a new customer, they wanted their intake forms to look a certain way,

13:37 they could easily just make a new skill file for it, attach it to the pipeline, and and and voila, there there wouldn't be any engineering changes required. So, it's completely clinician owned from

13:45 that perspective. And just in a side generally, I feel like skills are really an amazing interface between AI engineers and domain experts, especially in vertical

13:54 AI. We see this being we see this being modeled in several of our other workflows both for internal use cases and in production as well.

14:07 So, some results from this, right? So, even though we only really use synthetic data for evaluation at the moment, there's already a lot of merits that we get from it.

14:17 Roughly 90% of our data sets are already made of synthetic data. This helps us maintain a very high production accuracy score um for across many customer deployments.

14:29 The pipelines that we just showed you already we are able to achieve a a very high fidelity on this generated data. In a blind review, clinicians were not able were only able to distinguish

14:40 synthetic from real about 60% of the time. So, room for improvement, but but it's but it's it's close. And I'm I'm quite quite it's a quite promising avenue for us to invest more

14:51 more here. And and the the the the fact that is the most interesting to me and what I'm really what I'm really excited about is that all of these data sets well, most of our data sets today then

15:01 are created just in time for these customer deployments, right? You can you when you have the ability to like create data from scratch so quickly, you can kind of

15:09 you don't need to depend on on on waiting for data from your customer. You can kind of just model all your edge cases, simulate them, and test your workflows before you go live with the

15:17 production go live in production. So, some takeaways if you're looking to build your own synthetic data pipeline in healthcare or even another domain,

15:29 try reversing your inference workflow. Diversity should always be sampled from a from an appropriate distribution for your use case. Try to emulate the process in which

15:42 data was actually generated. So, like I showed you, we were trying to sort of like we were using LLMs we're trying to emulate how our medical records might actually be

15:51 generated during patient encounters. So, and I I would highly recommend you try doing that. And the fourth most important thing I think is when you're when you're making a data pipeline like

16:01 this, it's really important to give your domain experts the keys because these are the people who know about your data and and and they will help you

16:08 drive towards a recursive self-improvement and not the AI engineers. Cool. So, you don't need a PHI problem for this anywhere.

16:18 The data you need is ephemeral, sensitive, or even expensive to label. You can think about generating data yourself and hopefully you won't be data poor.

16:27 Thank you, everyone. >> [music]