VA Informatics and Computing Infrastructure- 19 -Department of Veterans Affairs   July 31, 2012

**Department of Veterans Affairs**

**VA Informatics and Computing Infrastructure**

**Code-free natural language processing / case finding using the Automated Retrieval Console (ARC)**

**Presenters: Leonard D'Avolio, PhD & Thien Nguyen**

**July 31, 2012**

53.25 p15

Molly:  As we are now at the top of the hour, I would like to introduce our two presenters for today.  Today we have Leonard D'Avolio.  He is the Director of Biomedical Informatics for the VA's Massachusetts Veterans Epidemiology Research and Information Center known as MAVERIC and faculty at Harvard Medical School.  Dr. D'Avolio is responsible for several initiatives, including the development of the infrastructure for the Million Veteran Program and Genomic Scientific Infrastructure and the VA's Point of Care Research Initiative using technology to enable new models of science, including the incorporation of clinical trials into electronic medical record systems.  Dr. D'Avolio is an investigator on several VA and MAH-funded projects focusing on using technology to improve medicine.

Joining him today is Thien Nguyen.  He is the lead developer on MAVERIC's informatics research and development team.  He is responsible for the software development aspects of several initiatives, including projects sponsored by HSR&D's Consortium for Healthcare Informatics and Research known as CHIR.  Thien is the lead developer on ARC and is responsible for reducing the complex processes of NLP and machine learning to a few simple button clicks.

I'd like to thank our presenters and audience members for joining us today, and at this time, Thien and Lenny, are you ready to show your screen?

Mr. Nguyen:  Yeah.  Actually I guess I'll say a little bit about ARC first.  So yeah, it's this Java tool.  We don't do some, I guess, cohort identification and document retrieval.  I'm actually delaying for Lenny for a second here.  I guess, yeah, as Molly said, thank you, I'm the lead developer for ARC, and we've been working on this for just a few years now.  And so it's exciting to be able to present it to a lot more people in the VA and hopefully, at the end of this and if people start to use it, get a lot of great feedback and further ideas on how to improve it so that kind of helps move along research.

Molly:  Thien, I have ...

Mr. Nguyen:  I guess I'll just go ahead and Lenny will have to jump in here in a few minutes.

Molly:  Okay.  I do have a few more announcements if you'd like me to make them real quick.

Mr. Nguyen:  Yeah, that would be great, thank you.

Molly:  I do see that people are still joining us and I just want to let you know that you did receive a reminder email a few hours ago with a hyperlink to view live captioning and also to a PDF of today's slides.  And on your screen at this time is a tiny URL which you can type into your web browser and you will also be able to access a PDF print out of today's presentation slides.

And just so you are aware, the first portion of today's talk will be a PowerPoint presentation and then the second portion will actually be a live demonstration of ARC, and then we will be taking all questions and answers at the end of today's presentation.  As I am not a VINCI or coding expert, I ask that you please write in your questions and comments using complete sentences and grammar and try and avoid acronyms if at all possible.  This will help me to moderate the Q&A in a much more efficient manner and get your question answered as quickly as possible.

And with that, since we are a few minutes after the top of the hour, I just want to make one more comment.  We are streaming the audio through your computer.  You have a few options.  You can turn up the speakers on your computer and listen that way.  You can also plug in a headset.  Or you can call into the toll number that is located in the reminder email you received.  If you still have technical difficulties with the audio, you can email cyberseminar@va.gov.  Finally, if the GoToWebinar dashboard is in your viewing screen, you can go ahead and click the orange arrow in the upper left-hand corner and that will minimize it out of your full view.

And with that, I guess we will go ahead and get started, and I'll turn it over to you, Thien.

Mr. Nguyen:  Okay, thank you.  So yeah, I'll just go ahead and get started here.  So first of all, thanks, everyone, for coming here or joining this meeting and listening to us talk about ARC and how it might be able to help some researchers out there do good work.  So I guess first thing we wanted to point out is this is an old picture of Lenny and a really old picture of me, and I didn't feel like it presented us well so we wanted to show you guys a much more updated image of us doing our Olympic activity right here.  That's why we're busy doing some Olympic games.

So I'm the lead developer here at ARC, and I work for MAVERIC which is the Massachusetts Veterans Epidemiology Research and Information Center.  We're in the Boston VA.  There are about 140 people here, and we do a lot of different research activities, clinical trial work, epidemiology with ERIC.  We have a bio specimen blood repository and the growing informatics group which I'm a part of.  And a lot of my work when I first got here was to support the clinical trials and FTE researchers do their work in using the VA's Vista and CPRS and CDW much more efficiently, and that's how our work in the informatics group grew from that and then also expanded into, as Molly said, the MVP project and several other initiatives.

So GenISIS is the recruitment, enrollment, and tracking of the blood samples for the bio specimen repository for the Million Veteran Program, and we also have a big point of care clinical trials program that's being deployed to support a couple of research projects.

So the background on why we started going down this road with the automated retrieval console was this idea that the EMR is such a great resource for research and it can be used to support a lot of secondary uses.  You see on the screen quality measurement initiatives, comparative effectiveness studies, evidence-based medicine support, doing bio-surveillance at the hospitals, and for (inaudible) research, definitely building cohorts and building registries of different patients and diseases.  And as we go into doing MVP and other personalized medicine and genomic analysis goals, the historical data that's contained in the EMR will help support and build out the patient models that are needed to actually get down to providing direct care to specific patients.

So the challenge with the electronic medical record system that we have at the VA, though, is – it's a great thing.  It's designed for one-on-one action between doctors, nurses, and other people giving direct care to patients.  But because of its design, there's a lot of standards that are all over the place along the different hospitals.  The quality of some of the documents can be questionable due to changes over time and lessons learned.  And a lot of it's just free text and so there's been estimated about 70 percent of the information is contained in this free text which is hard to pull out, and I'm sure everyone has experience in trying to get out information from the free text to do their research and studies.

So in the past 40 years there's been a lot of work on the computer science side to do natural language processing solutions in developing systems to help pull out data from the free text and manage electronic medical records.  But the issue is a lot of these are one offs and designed for very specific medical systems.  And so you have great developers and great people working on awesome technology, but it never makes it out of the institution that they're designed and developed.  And part of this is just because it's sometimes hard to generalize this stuff, and a study by Stanfill, et al. in 2010 found 113 studies that produced systems that could not be generalized and were stuck in the environment they were built in.

So this, like I mentioned a little bit.  So a lot of the implemented systems, they're specialized and they're tweaked to very specific needs, and it's hard to move those tweaks and very specific design decisions outside of the institution that they were built for originally.  And a lot of times it's dependent on the people who built the system to stay there and continue to maintain it and improve it, and as soon as they maybe move on or get busy doing other work, these systems end up in a static state.  And there are several very good reasons for that.  It's hard to do this stuff.  You have a lot of intricacies in the medical record.  There's a lot of different things you have to do to massage the data, but you also have to have a lot of domain knowledge and a lot of processes to handle the type of information and move it into useful systems and make it usable for the clinicians or the researchers.  And so because of that, there's a lot of customer requests and you end up doing a lot of customization.  And the economics of research and publishing papers and getting your name out there, a lot of times its spending the time to build up a new and unique system but you don't get a lot of return by maintaining it so you end up trying to chase new ideas all the time instead of moving an existing system into another domain or into another institution or facility.

So that led us to the idea of how we wanted to create a system to move into the idea of more of a software-oriented world and tackle some of those issues of locking into a single institution and make some of these systems more generalizable.  So we wanted to change the workflow so that researchers aren't dependent on the software developers to continuously provide them with tools or fixes or maintenance.  We wanted to move away from these rule-based systems that are specifically tweaked for a certain data set and take advantage of a lot of computer science and medical informatics research that has been done the past 20 years.  And a lot of people have done a lot of great tooling and very cool systems that have been open sourced, they're just hard to use for anyone who's not a developer.  And so there's been a lot of science and mathematics applied to this area for a while.

So we wanted to take those stuff and then use these existing NLP, natural language processing frameworks and build on top of that so that we could allow developers to extend and modify the tool while providing a base package that is already useful.  And all this is to reach what we call the 90/90 goal where we have a generalized approach that works for – that is 90 percent accurate for 90 percent of the problems.  And there's no denying that there's a lot of very specialized problems out there, but if we could tackle a lot of the more generalizable problems that can be solved, then more effort can be done to top off the ten percent there that's hard.  And so it frees up everyone to actually work on the hardest problems instead of redoing the easy ones over and over again.

So this is the idea of the whole changing how the workflow is done.  You see how it's currently done, you have the software developers doing a lot of work in building up the system, dealing with the documents, building schemas, training their tools, developing algorithms.  And in the time where the domain experts, the end users, the doctors and researchers, all they do is they annotate and then they review results and then they wait around for the developer again.  And that's a lot of time that is spent on the developer end when we'd like to move to this other side where both the developer can focus on the actual algorithms, the hard part, and the tooling allows the clinicians to move at their own pace in creating the annotations and reviewing results, and the computers then will actually do all the grunt work of maintaining documents and running machine learning and evaluating algorithms and just spitting out values for the researchers to accept or improve on.

So how this works at a very high level is there's – like I was saying there's a lot of research that's been done in this area, and not just in the medical side but in general computer science.  And Google and all these different large software companies out there have done a lot of work in machine learning and this field.  So we have a lot of people out there who are working on tools doing natural language processing so we want to take advantage so we want to take advantage of those pipelines that kind of take apart documents and provide structure around them and combine them with these well-researched machine learning algorithms that have proven to be useful in a lot of different domains outside the medical field and then wrap that around this whole idea of a better workflow for clinicians and researchers.  And we call that the easy button.

And so ARC already does this by importing annotations from eHOST which is an annotation package out of Salt Lake City and the more older Knowtator which is a plug in for Protégé so we can import annotations from those into ARC.  We're trying to use NLP pipelines that people have already developed instead of doing our own so we're using cTAKES which originally came out of the Mayo Clinic but is also being developed by people at Partners and several people around the U.S.  And we're using a machine learning package out of UMass Boston called MALLET and it has an algorithm called conditional random fields that works pretty well for a generalized approach.  And then our work on this is to provide the workflow and tools to take advantage of these systems that have a lot of people putting a lot of time and effort into making them solid for their needs, but we can extend on that.

Dr. D'Avolio:  Hi, this is Len.  I'm literally winded from running from a fire that I just had to put out.  My apologies for being late, but Thien actually does a better job at this than I do anyway.  So I'll continue to spectate.

Mr. Nguyen:  Okay, so here are some of the results we had on projects we're currently working on and past projects where we used ARC.  We did a lot of work around the research science part of this, but then to run ARC, we just kind of pop data in and it does the a lot of the computational work for us.  And for the most part we do pretty well without any customization for any of these projects.  The same ARC that we used for this is the same ARC that everyone gets to download and use.  We're hitting on 90 percent on average around a lot of these, and then there are some harder cases such as imaging reports.  But if you look at the CAPA for the ones that are harder, we reach about the CAPA score.

Dr. D'Avolio:  Yeah, well, one quick note that we're pretty excited about is with the PTSD work, that may become part of a national program to better understand the types of PTSD care that are being delivered.  I don't know if Brian Shiner or Vince Watts, both of White River Junction, have joined the call, but they're leading that project, and what they've been able to show is that using ICD-9 codes or other types of structure data alone pretty badly over estimates the type of care, the combined behavioral therapy and prolonged exposure therapy, that we claim to be delivering in the VA.  And so we've shown here that using these tools, you get a more accurate understanding of what's going.

And then also worth mentioning with that, pneumonia imaging report, that's part of an active project out of Baltimore.  And so VA running that has demonstrated that this tool can be used to help do bio-surveillance for pneumonia outbreak.

The breast cancer one is – actually I think that number's a bit inflated.  I think it's closer to 70 hospitals, but that's a collaboration with 70 community hospitals where we're trying to understand the types of care being delivered to young women with breast cancer.

And what this side is basically saying – so we put this thing in a bake off.  There's an organization called i2b2 that partnered with the VA to do an NLP challenge.  They do these annually.  And so basically folks have a few months to take the data and tweak their systems to get the best possible performance.  Our goal wasn't to beat them but to see just how good we did with no fine tuning.  So in other words we took that training set and clicked a button and then got our results.  And with no fine tuning and five minutes of manual labor per task, we were able to basically I think we were one point behind the average score on F-measure and in some cases tied with the score with F-measure.  So we were able to find all the problems, all the treatments, and all the tests listed in a corpus of medical documents that were taken from three different hospital systems.

And again, our emphasis is not to push up that hundredth of a percentage.  Our goal is to do well enough across enough tasks, minimizing the amount of work done by the non-technical researcher.  And the bake off is a big deal for us because it showed that we could do that.

And so here's what we learned.  This slide is up here for people who want to use this system, and obviously the listserv and communications with us and others will help you out too.  But if you're thinking about using a tool like this, it works best for find more cases like these type problems.  So if you can use structure data to narrow down what your target is, in other words for PTSD work, well, let's start with everyone who's being seen in a PTSD clinic so now you're not working off millions of patients.  You've narrowed it down at the hospital level and at the department level.  And so sometimes we've combined it with ICD-9s or prescriptions, etc.  Then you use ARC to go from the potentially 10,000 to the 1,000 that really matter, really have the disease, really got a specific treatment, etc.

Although we've made this non-technical, I think what we've learned from giving it to other folks is that you still have to understand how this stuff looks.  You got to know what a training set is, what a test set is, and what these performance measures mean.  So recall precision F-measure somewhat akin to sensitivity, specificity, and (inaudible) ROC.  Its like SAS.  It's a wonderful tool, but if you don't understand what logistic regression is, you're probably not going to be incredibly successful in applying it.

And the other thing for our NLP projects, understand what is good enough before you get started.  Because if you really want 99 percent accuracy, forget it.  I mean, don't even start doing this kind of work because you're not going to hit it.  And that is contextual.  For some projects, you need to be spot on.  For others, you'll accept some degradation of performance because you plan on doing a chart review after, etc.  So I think you have to understand the context of the problem you're getting into first and also the prevalence.  If what you're going after only exists in one every 10,000 records, because this is machine learning and supervised machine learning driven, you're going to need some kind of training of both positives and negatives.  So if your prevalence is super low, probably not the right tool for the job.

Okay, drive a demo.

Mr. Nguyen:  Okay.  So I'm going to switch out to a demo how to use ARC.  Okay, so this is ...

Dr. D'Avolio:  Yeah, a quick overview.  Ignore those two red buttons for now.  Take a look across the board.  And this is sort of the process here.  You need to be able to create a project.  You need to be able to judge what's in that project.  That little bomb icon is where we apply a ton of algorithms and a ton of combinations because the system itself figures out which is the best combination for your task.  And that's really important.  That's how we move away from customization per task.  We allow the system to do the work over and over again.  And then if you sort of have a taste for this NLP stuff and you want to tweak, you do that in this little lab icon here.  And that's where you can custom design different combinations and experiments, etc.

And then the last one is that little dog head.  That's retrieve.  So if you like what you've done so far and you want to turn it loose on a larger collection, then that's where you do that.  And so now look back over at those two do it yourself buttons.  After we figured out how to do those other applications and I walk through the other individual steps of using NLP, then we try to take it a step further by creating these do it yourself buttons and that just wraps up the whole process in four clicks really.

So here's the whole process in a nutshell.  If you've already done your annotation, this is where you import that, and you can do your annotation in Knowtator.  That's open source software.  You can do it in eHOST which is open source and hosted in VINCI  believe.  You could use a CSV file, just a comma separated value file.  So you do your judging somewhere else or you can do it in ARC, and we'll show you how to do that.  It's just a very simple annotator.  But if you need something a little bit more robust, you can do it outside of the application.

So the first thing you do is simply your select your annotated file which is where you've already told the system this is what I'm looking for.  So we'll just drag in one that we have on file here.  And this is from the demonstration data.  There's mock nonsense data that we allow folks to download, and all the tutorials are designed to use that mock data.  So you bring in your project file and you bring in your document folder, and that's where the documents live.  Is that in screen, Thien, so people can see where the documents live?

Mr. Nguyen:  (Inaudible).

Dr. D'Avolio:  So these are just text documents so these are copied straight out of – well, they would be copied straight out of a medical record system.  Again, in our case there are all mock documents.  They're not real.

And so that's the first step.  The second step is – so you see how it reads bone fracture there.  That's because in the annotator it knows that there's such a thing called bone fracture because when we created the annotation, we said, look, we're looking for bone fracture.  That could be anything that you're annotating for.  It could be pneumonia, it could be combined behavioral therapy for PTSD, etc.  So you select your target, in this case bone fracture, and then you click do it yourself down bottom.  And so that's ...

Mr. Nguyen:  I'm not going to click that one.

Dr. D'Avolio:  You're not going to click it because it would take too – yeah, this is like a cooking show.  We put it in the oven here and because it takes a while to try all different iterations, we're just going to fast forward to the other oven that has the cooked turkey.  And here's what that looks like.

So it shows you under models the different combinations that it tried and how well they did.  And so in the very top one here you can see that it took word tokens and punctuation tokens and it combined those to get a recall of .833, precision of .7857, and an F-measure of .76.  You can take that performance, copy it right into your paper, and then over on the right it explains all of the different settings for the models that it used.  So again, you can take that information and write up how exactly you got these results.  So we're trying to shed a little light on the black box of supervised machine learning or at least the different combinations and parameters for the models that are created.

Don't pay attention to the actual scores here because this is a 20-document set and each of those documents has like two lines of code.  So sometimes that performance is great, sometimes it's horrible.  It's a mock data set.

What else you want to show, Thien?

Mr. Nguyen:  I just want to show actually creating a project.

Dr. D'Avolio:  Yeah, we'll show creating a project real quick.  There's a lot here so, if possible, and I don't know if Molly's hosting this, we can open it for questions.

Molly:  Yeah, and there are some questions that have come in if you'd like to take a moment and get things set up.  So first question is maybe you can explain all of the elements on this slide about document retrieval.  So this came in fairly early on.

Dr. D'Avolio:  Sure.  Yeah, we'll pull that up real quick.  So I guess question is which slide is it.  Is it this slide here?

Molly:  I'm going to have to wait for the person to write in and clarify.  We can move on to the next question until they do clarify.  Does F-measure equal the same thing as CAPA.  Thien mentioned CAPA.

Dr. D'Avolio:  No.  So CAPA is a measure – well, you could use a CAPA to measure the agreement between a machine and a human, but CAPA is an agreement score.  F-measure is sort of like an agreement score.  It's how accurately you classify something.  It's an average, more or less, between your recall and your precision.  If you think about casting a net, if you throw a big net out there and there are, let's say, five targets that you really want, but think of in terms of web retrieval.  So you do a Google search and you get that 20 hits.  If only five of them are what you want, then your precision for the most part is five out of 20, close to 20 percent.  You didn't do so great.

Recall, on the other hand, is if there are only five out there in the universe and you happen to pull all five, then your recall is a thousand or a score of one.  And so recall is of all of them that live in the universe, how many did you pull back.  Precision is of all the ones you pulled back, how many were actually the ones you were looking for.  And F-measure is a combination of the two.

So this go towards understanding the process.  When you're doing annotation, a lot of times you want to understand, if you have two annotators, whether or not they agree with one another, and that's when we use a CAPA score.  If the agreement is really high, we'll send our annotators off in two different directions and they can each have an independent set.  If it's a little wonky, we might have those two annotators continue through the entire training set and maybe even a third party judge, an adjudicator, in that case.

Molly:  Thank you for that reply.  The next question we have, when documents are not retrieved by ARC (false negatives), are they systematically different in any way?  For example, are the documents retrieved a truly generalizable and unbiased sample?

Dr. D'Avolio:  That's a great question.  So the documents retrieved, are they truly – so I guess it depends on the problem.  So if you're working with rules, just straight rules, and you do not code in a rule that represents some of the documents you're looking for, then the miss is truly deterministic.  Right?  You did not enumerate all possible options, and as a result, you didn't get back consistently one type of document.

With a probabilistic approach or a machine learning based approach which is based on thousands potentially of features, then it's typically not so deterministic because it's using a probability and it's using so many different variables.  So I think the appropriate answer is it should not be deterministic unless your sample is not truly representative of the population.  And that's why we argue that you need to understand your prevalence in advance also.

And a real danger in this field is the creation of idealized test sets where you do some moves before you start your training and your testing on that set that you can't recreate in the real world.  And so I could talk more about that if folks like.  That's more a study design using NLP stuff.  Without really diving into study design, I guess I'll leave it at that for now and hope that covers it but encourage you to send me an email if you'd like to keep that conversation going.

Molly:  Thank you for that response.  The person did write back in, and they said the slide they were referencing might be 11 or 12.  And let me go back up to the original question, maybe you can explain all the elements on this slide regarding document retrieval.

Dr. D'Avolio:  This one here?

Mr. Nguyen:  Well, I guess we didn't really explain what ARC is doing for each of these things.

Dr. D'Avolio:  Well, is that question, what ARC is actually doing or just what's reported here?

Molly:  Well, he also followed up by saying that he doesn't need a lesson in statistics, but what they are grabbing and what it means at the 40,000 level, more examples of why and how to use this tool would be helpful.

Dr. D'Avolio:  Yeah, sure, happy to do that.  Okay, so if you go out to this website, MAVERIC.org, so there you can get use cases and it describes in a bit more detail what was done for each of those studies.  And I think we made those use cases to help answer the question how should I use ARC.

So now I'm going to go up a little bit to this here, and each of these – so with the prostate cancer path reports, what we were asked to find is is this pathology report truly related to a patient that had prostate cancer.  And I had an oncologist friend who bet me her career that my numbers were wrong when it came to the true representation of the ICD-9 codes.  And the reason for that is because using ICD-9 codes and the pathology report of the patient that had that ICD-9 code, we were getting a really low concordance as far as this path report actually being related to prostate cancer.  We had the same thing happen with lung cancer and with colorectal cancer.  And so the ICD-9 code plus the pathology report was only in something like 30 percent of the time actually related to the disease of interest.

And because she bet me her career, I had to go back and double check that, and it was the case that the ICD-9 code plus the pathology report was not truly representative of the disease of interest.  And so what we did was we used ARC, or actually he did, we sort of supported him in it, to figure out if these pathology reports were really representing a patient with prostate cancer.  And then further I think we also classified them as being biopsy related versus post-operative because the information both for registry and for research purposes is different.  So post-operative we're far more likely to trust a tumor stage or a Gleason score versus pre-operative where it's estimated based on biopsy.

And so we did the same type of work for prostate, colorectal, and lung.  For PTSD it was here's a stack of mental health notes, please find prolonged exposure therapy versus combined behavioral therapy because both are considered to be standards of care, and we were able to help identify those more accurately.  From breast cancer pathology reports, there was actually a number of things we did in there.  First, we had to identify clinic notes versus other types of notes and path reports versus other types of notes because those weren't reliably reported.  There wasn't structure that would help determine the note type.  But then further we had to secondarily classify them as to whether or not the breast cancer occurred.  For pneumonia imaging reports it was does this truly represent pneumonia or not, and that was combined with some other structured elements.  And so Thien can speak to that better than I could, but there were able to tell you whether or not the imaging report was really related to pneumonia.

So the lesson here is if you want to find more cases like this, if you want to go from what you believe to be a huge number of pathology reports to only those that matter or a huge number of treatments to only those that matter, almost all of these efforts are really cohort building exercises where the investigators weren't really able to do the studies and the volume they wanted unless they did extensive chart review, and we basically automated the chart review for them.

Molly:  Thank you for that response.

Dr. D'Avolio:  I hope that covers it.

Molly:  Can I also ask you to please go back up into full screen mode so we can see the side larger.

Dr. D'Avolio:  Oh, okay.

Molly:  Thank you very much.  And if you want, you can put it back on your final slide with the contact info.  Either way's fine.  The next question, are there any documents, for example, PDF, of the underlying statistical algorithms utilized in ARC which attendees can access to better understand the "guts" of ARC?

Dr. D'Avolio:  Yeah.  So on this website are the published papers that we've written that describe in more detail exactly what ARC is doing.  And for obvious reasons, we didn't want to spend a lot of time going into all of the – I tried to design this talk to teach you enough so that if you want to go learn more and potentially to use this tool, you would know where to go.  But if you go out to that website, you'll see all of our publications and those get into the guts.

Mr. Nguyen:  Also, the mailing list we have here, this link here, feel free to ask questions there.  And generally I try to answer questions pretty quickly, and if there's anything I can take from those questions and put them into the documentation, I generally do that.  So people who have asked questions before, hopefully I've helped answer that for everybody on the documentation at the website.  But if you don't find anything there you're looking for, feel free to send out a mail to the mailing list and we'll try to help you out.

Molly:  Thank you for that follow-up information for our attendees.  I'm sure they will take you up on it.  We do have a comment that just came in.  The MAVERIC website listed, the first one is not responding.  I'm sure we can address that when we're not in the live session, and we will get back to the attendee having issues with that.

Mr. Nguyen:  The website, MAVERIC.org, is not responding?

Dr. D'Avolio:  We have that up on another screen.  We'll work on that right now.

Molly:  Sounds good.  Thanks.  The next question that came in, when using the words precision and the F-measure, can you briefly describe these measures of accuracy a little bit better?

Dr. D'Avolio:  Did that just come in?  Because I just explained that.  I'm happy to do it again, but I don't want to ...

Molly:  It came in actually quite a while ago so I'm sure you did just cover it.  And if not, the person can write in for further clarification.  The next question, how do we get access to this software?  Would it be possible to get a hands-on class?

Dr. D'Avolio:  I'd be happy to do a class if there was enough interest.  I teach the NLP tutorial at AMIA every year, and ARC will be a very small part of it.  But I would love to do one for the VA if there was enough interest.

How you get your hands on it is these websites and also on iDASH which is hosted at UCSD.  And now it's on VINCI as well.  And that's very important because if you're going to be using VA data, you want to be able to do this in a hosted environment.  And actually I have slides right here, and Scott Duval is probably on this call somewhere and he was kind enough to send these over.

One of the stipulations for this presentation is that this not be a, hey, look at this cool tool that we created that no one else can use type of a demonstration and that this be hosted and accessible on VINCI.  And we've had a couple users access it on VINCI.  I'd love to hear of their experiences.  But here's where you go.  Let's see, is there a website on there or is it just a picture?  Well, there's an email address and a service desk number.  And so they can set you up with a work space that has the latest version of ARC on it, and hopefully you can also download all the video tutorials and the demonstrations.  And if you have trouble with those, there's nothing secure or sensitive about that so you could just go out to those other websites that we have listed and work with the demo version and the tutorials and all that.  There are some video tutorials there too, right, Thien?

Yeah, video and html, and they're all tied in with the same dummy set.  And we also have had a good number of questions and answers on the listserv that you could search.  And it's a Google group so it's pretty easy to search.

Molly:  Thank you for those responses.  Also, Scott Duval is on the call and said that you're doing a great job.

Dr. D'Avolio:  Thank you, Scott.

Molly:  Okay, the next question – oh, regarding the F-measure and precision, he did type it in right before you answered it so we're all set there.  The next question, how do we get access to this software – oh, I'm sorry, we just covered that as well.  How many learning documents are needed?

Dr. D'Avolio:  It really depends.  So one of the things we encourage folks to do is get a [power] estimate as to just how many documents you'll need.  And the way you could do this is really you just calculate based on a confidence interval and so you can figure out in advance if you have an estimated prevalence of the target, so let's say you want to – you estimate that the prevalence of these patients actually having PTSD within this population of documents is five in a hundred.  You can use that estimated prevalence to calculate the power you would need to go ahead and create the sample size.

Now, that's not going to be spot on because it's an estimated prevalence.  You don't know exactly what the prevalence is.  And the other thing that that doesn't tell you is just how heterogeneous the documents are.  But it's a start.  If you don't want to do any of that or you don't have a statistician readily available, then we sort of force the folks that we're working with to do about 300, just give us about 300 to get started with.  The good thing about the way we've designed this software is if you start with a training and test set of 300 and you annotate your way through those, then you click a button and it will tell you how well it did against those 300 using cross-fold validation.  So in other words, you can specify the percentage.

But in the case of just using the do it yourself, it'll do ten-fold cross validation.  So for a hundred documents, it'll set aside ten for training and then use the other 90 for tests.  And it will do this – I guess the other way around.  It will do this over and over again and calculate performance at each interval.  And then from that you would know how well you did for that set.  And if it did poorly, you can consider adding more to the training and test set.

Molly:  Thank you for that response.  With regard to the person who was having difficulty accessing the website, Scott Duval was kind enough to write in.  It is vaww.vinci.med.va.gov.

Dr. D'Avolio:  So that's the website for getting into VINCI.

Molly:  Okay, I'm sorry, it's not the MAVERIC one.

Dr. D'Avolio:  We're actually confirming that our host is down right now.

Mr. Nguyen:  Yeah, our host is down.  So it should be back up at some point if he still has issues.

Molly:  Thank you.  Okay, we do have several more pending questions, and it looks like we're doing quite good in time so we should be able to address all these.  What is the assumption about the format of the documents ARC can work with, how it handles spelling, grammar, and abbreviations?

Dr. D'Avolio:  Why don't you take format and I'll talk about spelling and abbreviation?

Mr. Nguyen:  Okay.  Yeah, so I guess there's a couple questions there. So format, for importing to ARC, it's all plain text files.  We do have a tool to help import from XML and – pretty just XML and maybe a couple other formats.  But generally it's probably easiest if you dump the files as just text files into a folder on a secure server or wherever you're allowed to store your medical records and then importing into ARC that way.  And also because a lot of the annotation tools just use text files as well, it makes it probably easier to work with.  But for the kind of NLP part, Lenny's going to answer that.

Dr. D'Avolio:  Yeah, and so if you want that tool, that import tool, we use it here locally.  We haven't released it because it doesn't – is it out there?

Mr. Nguyen:  It's part of ARC.

Dr. D'Avolio:  Is it really?

Mr. Nguyen:  Yeah, (inaudible) it's a data source.

Dr. D'Avolio:  Oh.  Cool.  I guess at least we don't draw attention to it because you have to be a bit more technical, but I guess if you're working with XML, you can probably figure this out.  And if not, just post some questions to the listserv and we'll walk you through it.

As far as the spelling mistakes and the grammar and all that, so this is the reason why we wanted to move away from a rules-based system.  Especially with document level classification, it'll take that entire document as it exists.  It'll run it through an NLP pipeline.  And we use cTAKES by default because it's open source and it's pretty darn good.  If one were to have spelling correction and that sort of thing in their pipeline, then it will consider those as features.  But what we do instead is we rely on big datasets of probabilities.  And so if we're looking to figure out if a patient has prostate cancer or not, our assumption is if there are some spelling mistakes in the collection, well, they're still just features.  And we rely on large numbers to say, well, let's hope that that spelling mistake is not the only feature of import or, if it is, let's hope that there are enough of those spelling mistakes that, still, it'll sort of wash out in the model and you'll find what you're looking for.

That's a very different approach than trying to find these two words that represent this disease and all of the very specific variants on those two words in a rules-based approach.  We take the entire document, run it through the pipeline.  That produces another ten-fold number of features to consider, and then we crunch all different variations of features and we let the system do the math using cross validation.  So at the end of a day or two of running, it'll tell you I tried all of these combinations and these are the ones that worked best.  Spelling mistakes, grammar, whatever, it's all in the mix and we just assume it washes out.

If you're going after a very specific concept, this is probably not the tool for you.  So for example, if you want to find a blood pressure and you think it's going to be BP equals and then some combination of numbers, you really want to write a regular expression which is a different approach.  It's just a simple pattern.  That's not what this is good for.  This is more for finding cases like these.

Molly:  Great.  Thank you for that response.  The next question is somewhat related.  Do you have a published study that demonstrates how accurate ARC is versus actual chart review in order to convince clinicians how great your tool is versus their brains?

Dr. D'Avolio:  Yeah.  So it's also dangerous to accuse software of being better than a brain, and so one does have to publish any success in this area.  So that website has our published studies, and there are a couple more coming out.  And the nice thing now is that we're not doing these studies anymore.  People are doing these studies using our tool.

But in every application of this tool, there has to be an empirical evaluation with the human providing the gold standard.  And if I can go up a little bit here, all these numbers are – the gold standard provided by a human.  Now that doesn't say that we're better or worse than the human.  This is how close we get to the human gold standard.  So maybe that's a slightly different thing.  It's really tough to come up with a gold standard.  The human provides the gold standard, and the best we can do is ask, in most cases, two judges and a third party to be the real gold standard.  I haven't been involved in a study in which you say that one human is really the gold standard and the either should be competitive to the system.  Usually you go up against the human-created gold standard and you try to control that as carefully as possible by having a few people involved.

And if there are any follow-on questions, feel free to send them.  These are great questions and they're not so simple, and I want to be sure that I'm addressing them accurately.  We did try to leave enough time to do that.

Molly:  Have no fear.  People are writing in that they want individual help.  In fact, the next person wrote "In how can we learn how to use this tool?  I need more than just a demo."

Dr. D'Avolio:  Well, that's all you're going to get.  So we have designed this tool so that it can be used by non-technical folks.  You do have to understand the process.  We did create the listserv, and that's pretty actively used.  This project was funded, and we're very grateful for that, by CHIR, the Consortium for Healthcare Informatics Research.  There was talk of part of the hand off to VINCI providing some additional level of support and training, but you'd have to harass the VINCI folks for that.

For obvious reasons, we try not to take on too many individual projects.  The whole idea was to create this so that others would use it.  But if you send us an email with what you want to do, we've yet to really leave anyone hanging.  I just want to be up front that we don't at this point commit to partnering throughout a larger project just to apply this tool.  I think that that has been probably one of the greater weaknesses of the field up to this point is that there's great job security in it, but we're moving on and we're hoping to create a tool that allows people to apply this and get their answers.  So we give a good amount of support, but we sort of draw the line at becoming heavily involved in projects.  Some of my collaborators can chime in and tell me if I'm a liar or what.

Molly:  That sounds reasonable.  I also do want to direct our audience members to our previous – I apologize for that delay.  My phone was going to continue ringing until I muted it.  I just want to let everybody know that we do have a cyber seminar catalog which has an entire history of VINCI sessions, CHIR sessions, and other sessions on NLP.  So please just go to the cyber seminar web page and you can look in the archive catalog and ...

Dr. D'Avolio:  And if folks wanted to send – I don't know, Molly said to send VINCI folks an email or me.  I'm happy to take them if you want to have a cyber seminar which is sort of a tutorial where we could spend more time just with more interaction and a hands-on tutorial type thing.  I'm happy to do that if there are enough folks who want it.  I think that would be great.  So just let us know.

Mr. Nguyen:  Yeah, and the documentation online also has like a walkthrough of each of the different things you can do in ARC.  And if you actually go to the Google code site, there is an alternative link for the MAVERIC website.  Or not the MAVERIC website actually, just the ARC website.  And then hopefully we can get the MAVERIC website back up at some point with our host.

Dr. D'Avolio:  So everything you can do in ARC is explained in a step-by-step tutorial, and that's a great place to start.

Molly:  Thank you very much.

Dr. D'Avolio:  We've had non-programmers using this, clinical collaborators, and it works out.  There's no question there's room for improvement and we really benefit from hearing how to improve it, but so far it's proven to be do-able.

Molly:  Great.  Thank you.  The next question is can this tool be used on data SQL databases.

Mr. Nguyen:  So currently no.  If you have text documents you want to work on in SQL, it's best to export it.  That is something I heard from a couple other people that asked me that before.  I'm not sure what our plan is.  If you're a coder, you can actually do it and I've done it for something very small before.  But right now there's no user interface for importing directly from a database.  So if you have some skills to export out of the database, that's probably the easiest way to do it now.  And this is open source so if anyone out there who's a coder would love to put that in, I'd be happy to have their help.

Molly:  Thank you for that reply.  We do have more questions.  Is there a recommended sample size/power calculation for the number of records clinicians review or annotate?

Dr. D'Avolio:  So I think I answered that one.  I'll do it again quickly.  We start with 300.  That is in no way scientifically based.  The proper way to do it is to calculate an appropriate sample size based on an estimated prevalence.  And so we've done both.  I'm probably guilty of doing more of the whole give me 300 and see how it goes approach, but really the appropriate way to do it is estimate the prevalence and then do a power calculation.

Molly:  Thank you for that reply.  We are getting towards the end of our questions.  Okay, can you describe what is involved in annotating?  What is the level of detail needed?

Dr. D'Avolio:  So that depends on the problem, and there's probably a seminar in there about annotation.  It depends on what you're looking for.  Thien, why don't you pull up the document annotator while I'm talking.  So for document level classification, which is really what this works best at, you would basically create a project and you would describe the number of targets.  So right here when you go to create a project that says, okay, how many classes and what are they called, if you look across the top, you have not relevant and bone fracture.  That's about as basic as it gets.  These are binary classifications on documents.

And then you'd work your way through this document list by just clicking bone fracture and not relevant.  And in fact, we have shortcut keys on the keyboard, and we've been able to do 500 annotations in 90 minutes by having doctors – and those are complete pathology and imaging reports.  If you haven't done your annotation in another one of those open source packages and it's a document level project, you can import them here and you just click your way through it at sort of high speed and you just basically assign a label to the document.

Now if you're doing concept level classification, that's a whole other thing and – he'll love me for doing this – but I'd recommend you give Brett South a call.  He's in the Global Address List.  It's south like the direction.  He's the annotation master and he's created a really cool tool that does concept level annotation.  It's very robust.  You'd want to partner with him to go down that road.

Mr. Nguyen:  And also one thing is so here we only have two, but you can actually define a lot more labels if they're all separate types of documents.  So but just for the demo, we only have these two annotations, but we've done some with like six or like the psychotherapy, there's like six or so different types of documents in that.  So the clinician has the option of choosing from one of several labels for the document.

Dr. D'Avolio:  And you can also in here set up the number of judges, etc. so it sort of runs the annotation for you if it's document level.  And there's a tutorial on that.

Molly:  Thank you very much.  In fact, we did just have somebody write in saying they understand one-on-one training is not available, but they would like a user manual for ARC or a captured tutorial.  So I mentioned that they should contact the centers directly and investigate more into that matter.

Dr. D'Avolio:  Well, yeah, if everyone that wants a whole seminar on how to use this emails me, just send it to me and then I'll do something either through VINCI or whatever.  The idea is to get this into folks' hands and have them use it to solve problems.  As far as tutorials, that's all on the website and, others can correct me, I think it's been pretty useful paired with the videos and the demo documents.

Molly:  Thank you.  And as the cyber seminar coordinator, I too am happy to work with MAVERIC and VINCI to set up another cyber seminar.  I'm sure there is a lot of interest in this field.  And we are almost through all the questions.  Do you gentlemen have a few minutes to stay on and answer the remaining ones?

Dr. D'Avolio:  I think I can.  I have a three o'clock.  Yeah, I can for a couple minutes but Thien is – like I said, this is his baby.  He worked very hard on it and there's no question you could ask that he couldn't answer.

Molly:  All right, these ones we'll get through pretty quickly.  I'm new to this system so just to clarify a question to make sure I'm understanding it.  You give the software a small set of documents which are classified by humans relevant or not relevant, for example, the software tries to determine by itself what it makes relevant or not relevant, and then you give it the full set of documents and it returns the relevant files.  Is that correct?

Dr. D'Avolio:  Yeah, I appreciate it.  That's a much clearer explanation of how this works.  You're spot on.  The only catch there is there's one step in between: the training and then deploying it on the large collection.  And that's that it gives you the opportunity to see how it did and even then to select which model you'd like to use because in some cases you may want to favor recall over precision or sensitivity over specificity.  So that one additional step between give it the small training set and then go to the larger set is review the results and select the appropriate model.

Molly:  Thank you.  The next question ...

Mr. Nguyen:  And in ARC so how you would actually go in a larger collection, you just select your model and then you point at the directory with all the documents that you want it to go through automatically, and it will just read in all those, run the NLP, and try to classify them.  And whatever is the target you want, it'll spit out into another folder.  So if you have just text documents, it works pretty simply.

Molly:  Great.  The next question, is it possible to find cases using multiple sources of data – for example, pathology, imaging, clinical notes – at one time in a hierarchy based on quality of the clinical evidence?

Dr. D'Avolio:  No.  So certainly it's possible to dump all different record types into a single run.  I'm not sure I would advise it unless you had an enormous sample to work with.  And the reason is because it may be better to run small experiments with different clinical document types.  So let's say you're going – I'll just keep using prostate cancer, or let's do pneumonia since it might be in imaging report and in clinical notes and in discharge summaries.

What one could do is either set the whole thing up using all different document types, and you might even want to start with that just to see how it does and then get your results.  But an alternative is if that's introducing too much noise because the phenomena of interest is described too differently in the different types of documents, you could also just set up experiments where you just, one at a time, feed it two experiments based on the specific document type.

And I can tell you that we use ARC to figure out what are the different document types when it's not clearly defined based on a structured value.  So for example, we have all pathology reports, but is it biopsy versus post-op.  So we like to break it into subgroups because we think we get better performance out of the models when we're dealing with a more consistent population.

Molly:  Thank you for that response.  We are down to ...

Dr. D'Avolio:  As far as ranking the clinical evidence and all that, so that's sort of a study design.  So if you were to do this with pathology reports, discharge summaries, and imaging reports and you knew that you placed more value on pathology reports, that's a post-processing thing where you would favor the pathology report result over the other types.

Molly, I want to thank you for putting this together.  I have to run to a three o'clock, but Thien will stay on.  My email address – if it's not up here, Thien, could you just write it – it's on the websites and all that, but Leonard D'Avolio, and I'm in the GAL (Global Address List).  And thank you, everyone, for your attention.  The reason we did this is so folks will use it so please let us know how we can help you toward that.  And again, Thien, will stay on.  Thanks.

Molly:  Thank you for your time and your expertise, Lenny.  And Thien, we do just have two final questions so we can get through these.  The first one, it sounds like "annotation" is just a label as to whether a record is a "case" of interest or whether it is irrelevant.  Is this correct?

Mr. Nguyen:  Yeah, so we do kind of use the term in several ways.  And what we've been showing is just document level so you're annotating/labeling a document as something of interest or not.  But with the concept level annotation, those are actually highlighting pieces of text and saying this piece of text corresponds to a tumor stage or a medical treatment.  So yeah, you can do annotations at multiple levels, and it really depends on what you're trying to accomplish.  So ARC supports both, and when we were talking about the i2b2 challenge, that was a concept level.  So actually ARC was finding segments of text that correspond to a medical treatment or a medical problem while a lot of the other stuff, like this bone fracture demo I have showing, is just labeling the document as a whole.

Molly:  Great.  And the final question we have, I feel like you may have glossed over the time and effort that is often part of the annotation process.  How well does ARC interact with the other programs that facilitate iterative development of annotations so you can enhance the precision and recall of relevant documents?

Mr. Nguyen:  Yeah, so that is completely correct.  Annotation takes up a lot of time, and we've gone through projects where you learn through the annotation process what you're going to be doing and you have to keep building on that.  So we try to take advantage of the tools that are out there, and the one we've just worked on mostly is Knowtator's XML output or its project file which the eHOST tool also works with.  So that has allowed us to just have ARC focus on this NLP and machine learning part, and then the annotation part we try to deal with import from the annotation tools that are out there, although we are only supporting the Knowtator stuff right now and, for document level, just a basic comma separated value list.

And so the iterative approach, right now the way (inaudible) is you re-do the project.  And so it's not quite as easy as you update your annotations and ARC automatically just updates its models.  It's more you update your annotations and you re-import them to ARC and you try again and then you can compare to see how it did versus past performance.

Molly:  Excellent.  Well, I cannot thank you enough for your time and expertise, Thien, and for our attendees for joining us.  Do you have any concluding comments you'd like to make before we wrap up?

Mr. Nguyen:  No, just if people use this, that's awesome, and we're definitely open to suggestions and ideas and improvements in the documentation.  And we try to be available via the mailing list.  And hopefully if there's a lot of interest, we can try to set another thing up.  And thanks, Molly, for setting this one up.  And thanks to all the people who have actually developed the tools that we build off of, and I've tried to mention a lot of them because without them, we wouldn't have been able to just build this layer on top.

Molly:  Thank you.  We do understand the number of time, people, and dollars that have gone into this, and it will be an excellent tool for everyone to use.  So I'd like to thank you you again, thank our attendees, and as you see on our screen, there will be a feedback survey that will pop up as you exit this session.  It may take a second to load, but please do complete it as we do take your suggestions into account.  So thank you, Thien, and to our audience, and this does include today's HSR&D cyber seminar.  Have a wonderful day.

**[End of Recording]**

Cambridge Transcriptionswww.ctran.com