What’s the upper limit of normal for luteinizing hormone in men? How about the lower limit of normal for women? Questions like that probably have you thinking, “check the table.” Tables are an intuitive and powerful way to match variable input like gender and age with a corresponding value. The same tried-and-true data structure can associate the key terms of an adverse event with standard categories and codes. OC4 makes it easy to tie tables to your forms. Let us show you how! Join us for a quick 30-minute demo on Tuesday, 4/23 at 10am Eastern. We’ll examine two use cases from the form-filling and form-building side: one on applying lab normal ranges, the other on retrieving term codes and classifications from the CTCAE. We’ll show you how this method generalizes to other uses, too. So whether you’re coding and collecting specimens or not, don’t miss your chance to learn how to put a classic tool to new use.
If the question is difficult to ask, it’s even harder to answer. Ask an actuary. Calculating life expectancy is a complex matter; more complex, at least, then plugging your date of birth and today’s date into a function. An informative life expectancy depends on a host of additional factors, like your sex, current health, and lifestyle habits.
“Multifactorial” calculations like the one above dominate medicine, so it’s no surprise that they should dominate clinical research, too. Take a plasma urea level of 39 mg/dL. Is that above, below, or within the normal range? The question is misconceived, because normal in this case is relative to patient age. A 30-year-old’s “slightly above normal” is a sixty-year-old’s “slightly below normal.”
Age is only one factor. For many ranges, patient gender, ethnicity, and co-morbidities, in addition to age, determine a normal range. Often, researchers can set these factors aside without raising undue safety concerns or undermining the generalizability of their results. But as personalized medicine continues to inform drug discovery and clinical care, researchers will turn to more finely-grained reference data more often. For this reason, data management systems must make it easy for these researchers to apply reference data that’s sensitive to as many factors as they choose.
Of course “easy”, just like “slightly below normal”, is a relative term–for the most part. In no context is a writing a lengthy formula of nested “if, then” clauses easy, e.g.
If the participant is male and Hispanic and between 18 and 25 years old and the test is for ALT, then set the lower limit to 12 U/L and the upper limit to 102 U/L, and if the participant is male and Hispanic and between 26 and 34 years old and the test is for ALT, then set the lower limit to…
Completing the formula above would mean assigning a lower and upper bound to every combination of gender, ethnicity, and age range. The process could easily take hours, just to set the normal limits of ALT. If the study involved a dozen analytes, the data manager would need to devote the better part of a week to programming these constraints. If, at a later date, any one of those constraints changed, he or she would face the unenviable task of modifying (without breaking) the original formula. Too many “modern” EDC systems force the data manager to soldier through this error-prone task. With paper, it’s a non-starter.
How much better, then–for efficiency and quality–to rely on a general constraint; one that leverages a tool that’s easy to build, easy to read, and easy to amend? I’m talking about the humble table.
Yes, the table. For all our advancements in data architecture, the same grid that set us on the path to multiplication in second grade remains an asset today. It’s human readable, it’s intuitive, and it’s powerful.
Powerful? Really? How much can you accomplish with just two axes?
Great question! It’s true that most spreadsheet applications don’t offer more than two axes, at least not through their GUI. But who needs them when you have thousands of rows and hundreds of columns at your disposal?
Suppose I need to assign a unique value to every combination of three hand preferences (left, right, or ambidextrous), four eye colors (blue, green, brown, or hazel), and the eight blood types (O,O-,A+,A-,B+,B-,AB+,AB-). At first blush, it seems a table won’t suffice. I have more dimensions (three) than I do axes (two). But a single axis can accommodate any number of dimensions, because nothing prevents me from treating each combination of values on those dimensions as its own, n-factored value. For example, I can treat each triad of handedness, eye color, and blood type as one of 96 phenotypes.
Laying these combinations along a vertical axis, I can assign a value to each with just two columns.
Maybe I’m partial to a more compact format. If so, I can combine the variables from two dimensions to specify one axis, and let the variables from the third dimension define the other:
Here I make the 96 assignments with 13 rows and 9 columns. (The virtue of this method is fewer total cells.)
In any case, I’m free to work with as many factors as the situation demands, and distribute them between the two axes in any way that makes the most sense to me. Leaning on a familiar format, I’ve made the difficult part of a multifactorial reference much easier. All that remains is to add to the form a simple instruction for “looking up” the values needed. Even if those values change, the form doesn’t need to.
Fair enough. But won’t real use cases require gargantuan tables?
A mere 972 rows (plus one header) accommodates every combination of age, ethnic and racial category, and gender. 80 columns (plus one on the left for analyte names) accommodates the 40 lower and 40 upper limits. The resulting 973 x 81 grid is small potatoes for database applications that power software like OpenClinica’s. Simple formulas in that context can retrieve the value from any coordinate within milliseconds.
Great. But what’s the big deal? I hardly ever need to apply reference data for this many factors at once.
Yes, a heart rate is a heart rate, and while population differences might exist for this measure, they’re hardly a concern on your vitals form. But don’t confuse the frequency of a need with its importance. Take safety. An insignificant drop in a lab value for one patient may portend real danger for another. Even apart from lab interpretation, though, tables can drive efficiency and accuracy. Dosing can vary between countries participating in the same study, due to differences in labeling and regulation. The same goes for eligibility and arm allocation. Whenever we try to account for these variables within our form, we accept programming delays and chances for error that we don’t need to accept. It is possible, of course, to make an error when assembling our table, but those errors are easier to spot and correct within a grid than they are in some extended, conditional formula. The tables themselves are easier to build in the first place, too, as their source data usually comes to us in the form of a spreadsheet. A little re-labeling of our first row and column, some testing, and viola: trusted references values are now a part of our study.
The lesson is simple, then. First, make sure you’re using the right EDC. Your form builder should allow you to specify reference data with tables, and your forms themselves should retrieve values in that table based on user input all but instantly. Second, use your two axes to their full potential: fill those rows and columns with as many dimensions as are relevant by tapping some basic combinatorics. Third, congratulate yourself.
You’ve just used a bit of the time you have left more wisely.
Real-world example: applying lab reference data that’s gender- and age-specific for two analytes
Not every analyte carries with it age- or gender-specific normal ranges. But for those that do, their differences are critical. In this example, I’m concerned with two levels from a blood serum panel: Insulin-like growth factor 1 (IGF-1) and Dehydroepiandrosterone-sulfate (DHEA-S). Both play a key role in several endocrinological disorders, and both have normal ranges that vary by age and gender.
Our example form first asks the user to specify the patient’s sex, patient’s date of birth, and date of sample collection. The form then calculates the patient’s age, in years, at the time of collection.
Next, the user is prompted to enter the value for IGF-1.
As soon as it’s entered, the form compares that value to the upper and lower limits of normal corresponding to the patient’s age and sex, as found on the table below. Note that the user’s selection for gender, together with the calculated age, combine to form a unique key (‘female40’).
The lower limit of normal (igf_ll) for a 40-year-old female is 106 ng/mL. The upper limit (igf_ul) is 267 ng/L. Because the entered value of 145 falls within that range, no query is raised.
The form then prompts the user to enter a DHEA-S level. For this analyte, the user enters 278 ug/DL. That value is outside the range for a 40-year-old female. As a result, an auto-query instantly fires.
The full reference table includes 191 rows…
1 header row
95 rows for men aged 18 to 112
95 rows for women aged 118 to 112
… and 5 columns…
1 column for the gender-age combinations
1 column for IGF-1 lower limit
1 column for IGF-1 upper limit
1 column for DHEA-S upper limit
1 column for DHEA-S lower limit
Introducing racial and ethnicity categories, along with more analytes, would multiply the area of our table. Six racial and ethnic categories combined with two genders and 95 whole-year ages would generate a total of 1,141 rows (6 x 2 x 95 combinations plus 1 header row). Specifying the upper and lower limits for three dozen analyzes would occupy 73 columns (2 limits x 36 analytes + 1 label column). The resulting 1,141 x 73 table would contain 197,393 cells, a total that’s 206 times greater than our original table’s cell count. Should you expect a proportional decrease your form’s response time? Not at all! The “lookup” still happens within milliseconds.
Here in Massachusetts, with the March winds whipping and snow always a threat, a week’s vacation down south is common fantasy. Even if it means a 10-hour car ride, most of us relish the thought.
But suppose our usual set of wheels, a Mini Cooper, say, is in the shop. (Potholes the size of craters are a common reality here.) Instead of foregoing our vacation, we decide to rent a vehicle. Chances are another Mini Cooper won’t rank as our first choice. Sure, a car that size could get us from Boston to the Outer Banks. But at what cost to our comfort and cargo?
We can think of study designs as kinds of road trips, and our eClinical tools as vehicles. Randomized controlled trials (RCTs) and registry studies are only two such journeys, but they’re two of the most frequent we in the research community take. In both cases, most of us rely on electronic data capture (EDC) to help us reach our destination.
How do we choose the EDC “vehicle” that will get us there safely, with minimal delays? Marquee brand names matter less than road-tested features. Consider the relative importance of these EDC features in RCTs versus registries.
Automatic reporting and notification
Important, especially as interim analyses approach
Very important, to maintain desired balance among subgroup sizes and to ensure that sites contact participants at the appropriate intervals
Important, especially for trials that need to consume a high volume of lab and imaging data on a regular basis
Very important, as EHR data can easily account for more than half of a registry data
Very important, to drive data entry timelines, reduce queries, and ensure quality
Critically important, for the reasons listed under RCTs, as well as to minimize collection burden and complement the flow of clinical care
Often irrelevant, otherwise critically important, depending on whether patient-reported outcomes (PRO) are collected
Often critically important, as PRO is a far more common data source for registries
Let’s look briefly at each four of these features in turn.
Automatic reporting and notification
Registries may be observational, but make no mistake: there’s still plenty to do, especially when it comes to ensuring the internal and external validity of the study design. As with RCTs, registries begin that task before the first participant is ever enrolled. Inclusion and exclusion criteria define the patient population from which the study will draw. Enrollment targets and duration parameters are set to deliver the necessary statistical power. Data elements are selected ahead of time, as are relevant outcomes.
But RCTs wield two defenses against bias that registries do not: highly specific eligibility criteria, and randomization itself. The first defense minimizes the role confounding factors can play, while second helps ensure that the influence of confounders is balanced between comparison groups. Registries, on the other hand, because of their greater need to reflect the diversity of the real-world, cast “a wider net” with their eligibility criteria. In doing so, the room for selection bias–and confounder impact–grows. And because oversampled patient types are not randomized to one or more groups in a registry, they can distort findings more powerfully.
The registry data manager, then, is often engaged in a constant battle against selection bias. She has no more powerful weapon than real-time reporting, which can signal when enrollment efforts need to be retargeted.
Typically, criteria for registry enrollment aren’t as selective as they are for RCTs. That kind of wiggle room leaves the door open for selection bias. Regular, visual reporting of subgroup counts (e.g. patients of a certain race, ethnicity, sex, age, or socioeconomic status) are indispensable to maintaining a registry population that is representative of the general population with the disease, exposure, or treatment under study.
That same real-time reporting, directed now at the site, can automatically prompt CRCs to contact participants in a longitudinal study at the right intervals. Why is this important? Missed visits mean missing data, which poses two risks. The first is a failure to collect enough overall data points to achieve the desired statistical power. The second, more subtle risk pertains to whom the missing data belongs. If a certain patient subgroup is disproportionately more likely to miss visits (and therefore leave blank spaces in the final dataset), results become biased toward the subgroups who were compliant with visit schedules.
Missing data is the scourge of registries. Without consistent outreach to all participants from sites, the data collected can easily be skewed by those participants who are proactive in keeping their appointments. Give your sites helpful, regular reminders of upcoming milestones for their participants.
The takeaway? Look for a data management system that allows you to build clear, actionable reports, and to push them out automatically to sites and other stakeholders on a schedule you set.
The life sciences are awash with data, and yet how little of it flows smoothly from tank to tank. My blood type, and yours, is very likely recorded in a database somewhere. Yet, if either of us participates in a study where that blood type is a variable, we are almost certainly looking at a new finger prick.
The situation is poor enough for RCTs, but becomes dire with registries. Registries that don’t easily consume extant secondary data place increased burden on site staff, who are rarely reimbursed well or at all for their contribution. RCTs, on the other hand, often pay per assessment. Also unlike RCTs, registries make more frequent use of this data:
Clearly, the ability to exchange data among multiple sources in a programmatic way (i.e. interoperability) is a must have for the EDC that will power your registry. Of course, unlike data storage capacity, you can’t quantify interoperability with just a number and a unit of measure. Interoperability is a technical trait that depends on more fundamental attributes:
Data standards – Does the system “speak” an open, globally recognized language, such as CDISC?
API services – Does the system offer clear, well-documented processes for accepting (and mapping) data that is pushed to it from external sources?
Security – Will data that enter, leave, and reside within the system remain encrypted at all times?
Before selecting an EDC, press your prospective vendors on the questions above. Then inquire exactly how they’ll ensure safe and reliable integration between their system and all your data sources.
Contributing to clinical research is, for many, its own reward. The prospect of expanding our medical knowledge and, perhaps, improving patient lives, is a powerful incentive. But it’s easy for a clinician or researcher to lose sight of these ideals in the middle of a hectic workday. When the research is long and unpaid, which is more likely to be the case for a registry than an RCT, the will to “get the work done” can quickly trump the will to do it right.
Leaders of registry operations, therefore, have an even greater responsibility than their RCT peers to keep hurdles low. That’s a wide-ranging obligation, but ensuring a frustration-free data capture experience stands at or near its center.
First, a clinical research coordinator (CRC) should meet with no obstacle the tasks of signing in to their EDC and navigating to the right participant. These are the “low bars.” Even so, they can easily trip up thick-client systems, and even web-based systems that aren’t built for performance or designed with UX (user experience) principles always front of mind.
But the most important ease-of-use tests happen in the context of the case report form (eCRF). Recall that a large portion of registry data comes from clinical encounters that occur in the delivery of standard care. Think pulse oximetry, or resting heart rate. Consequently, any eCRF that can’t be completed while in the exam room ought to have you raising an eyebrow. Accept nothing less than forms that render clearly in any browser, on any device (no matter how it’s held). But that’s not all. Fields on the form need to be “smart:” appearing only when they are relevant; capable of showing specific, real-time messages when the entered value is invalid; and hanging on to input even if an internet connection is lost. Finally, these fields should “remember” and calculate for the CRC, instantly pulling in patient data from visits ago to reference in the current form, and effortlessly turning a height and weight into a BMI.
Can’t pull medical history from the EHR? Help your CRC out with fast and responsive autocomplete fields.
In short, contributing to your registry should go hand in hand with delivering excellent patient care and keeping accurate, up-to-date records. The further those drift apart, the more your registry suffers.
What endpoints are to RCTs, outcomes are to registries. And where there’s a concern with outcomes, there is (often) a concern with patient self-reports. Ergo, chances are high that your next registry may rely on patient-reported outcomes (PRO) as one of its data sources.
If we need to keep the barriers to data submission low for researchers, we need to keep them all but invisible to participants–whileensuring data quality. The simple paper form may appear to offer this balance. Historically, it may have done just that. But twenty years of Internet use have changed our expectations when it comes to offering personal information. Without sacrificing one bit (or byte) of security, we want the same ease in reporting aches to a physician as we find in booking a flight. We want instant “help” when we don’t understand a question, and we don’t want to be asked about matters that don’t apply to us.
Given the expectations above, a study that utilizes even a single PRO instrument can benefit from make the conversion to ePRO. Real-time edit checks, for example, re-orient the participant when their input conflicts with field requirements, without risking the influence of a human interpreter. The time and cost of transcription disappears.
When PRO takes the form of a patient diary, paper’s dirty secrets truly come into the light. Provided the paper form isn’t lost or damaged in the first place, it’s virtually impossible to tell whether a patient made daily diary entries as instructed, or retrospectively wrote responses just prior to a study visit, raising data quality concerns.
As a field, we’ve embraced ePRO for the last decade. But too many ePRO solutions don’t offer the ease or convenience they should. Many depend on provisioned devices, difficult to use and prone to malfunction. Web-based ePRO technologies are a step in the right direction. Here, too, though, industry efforts to deliver a effortless experience often fall short. Special software (such a smartphone apps) require storage space, not to mention the know-how and patience for download, installation, and activation. Along with everything else participants need to remember, is it really fair–or feasible–to add a password, browser recommendations, and “virtual check-in times” to the list?
Won’t be getting you your data anytime soon
The answer lies in allowing patients to use their own devices, be it a laptop or smartphone, and to submit their data on the browser with which they’re most comfortable. Form URLs specially encoded for each participant make passwords unnecessary, while auto-scheduled email and SMS messages provide a friendly, “just-in-time” reminder to make their report. And what better way to convey a message of collaboration with the participant than eConsent? While its role in risky, interventional trials may still be unclear, eConsent is tailor made for registries: it can deliver an interactive education on the purpose of the study, ensure comprehension with in-form quizzes, and signal to registry leaders real-time recruitment trends.
As for ePRO data collection itself, layout, question order, and response mechanism can all make the difference between valid, timely data and no data at all. The participant isn’t an amateur researcher, and won’t tolerate the kinds of screens all of us envision when we think of EMRs. Data collection should proceed from the simple to the complex, leveraging skip logic to trigger only those questions that are relevant, and using autocomplete to help with terminology. A single column layout, a conspicuous progress bar and page advance button, autosave–all of these features are crucial to treating patients like the study VIPs that they are.
Chances are you’ve already set personal goals for the new year. But have you set professional ones? If not, let me suggest the most meaningful data management resolution you can make for 2019.
“I will build better forms.”
Of all the aspects of eClinical, why rally around forms? For us, the answer is simple. Of all the tools in your toolbelt, optimized forms offer you the greatest leverage in capturing clean data promptly.
Just think about it. You don’t have control over the buzz of clinical and research activity at your sites. You don’t have control over source documents. And you can’t personally visit all your sites, train all your CRCs, or SDV all the items in your study.
So how do you bring order to the (mostly) controlled chaos of a clinical study? You encourage prompt entry of accurate data with forms that are smart, standardized, and, yes, even appealing. Think about what capable forms deliver at the point of entry and downstream:
Timely data entry from CRCs who are thrilled to use your beautiful eCRFs
More accurate data, thanks to specific, real-time edit check messages
Less missing data, thanks to sensible skip logic and clear instructions
Reduced SDV burden, as more and more of your clean, flexible forms become the source
Reduced time to database lock
Easier analysis, thanks to sophisticated “in form” scoring and calculations
Smoother submission, with CDISC-standardized exports
Don’t get us wrong. Tools that expedite study design and user management, fast and reliable system performance, rock-solid security – these are crucial too. But forms are where you, your CRCs, and your data live, day in and day out. So in terms of overall study success, the “ROI” on perfecting your forms is hard to beat.
That’s why we’ll never take our eyes off this so-called fundamental. In fact, we devoted the last few months of 2018 to assembling the best thinking on forms. Not just our thinking, but yours, and that of experts. You can see what we’ve been up to by reading our blog series on cross-form logic or streaming our two December webinars. And we hope you’ll let us know what (in addition to better forms, of course) will change the clinical research landscape this year. Take the poll below!
Equipped with the right system, data managers today have more tools than ever before to capture high-quality right at its source. But what can the “right system” do? And how should data managers deploy those capabilities to prompt accurate, efficient entry from site staff and participants?
We hosted two webinars this month to answer those questions. Now you can watch them on demand. In Kitchen Sink, you’ll spend an economical 30 minutes understanding how OpenClinica’s form capabilities – from cross-form intelligence to modern, multi-media question types – all work together to serve as the user’s partner in capturing better data, faster. In Good Form, we step back to understand the proper role of these capabilities (not all scales are Likerts!) and climb inside the heads of CRCs and participants to better craft our forms for these study VIP’s.
Click either image below to sign into our on-demand webinar library. Then watch, share, and respond with comments to add your expertise to the conversation.
In just thirty minutes, explore all of OpenClinica’s form capabilities, each doing its part to ensure better data, faster! See how skip logic, autocomplete, clickable image maps, real-time edit checks, autosave and a LOT more all work together on beautiful UX to drive cleaner data from the start.
Starting today, data managers building their studies in OC4 will find a whole new level of control at their fingertips. Our newest release allows data managers to:
Enforce a Participant ID naming convention of their choosing (e.g. [site number]-[participant ordinal])
Restrict users from adding participants once an expected number of participants is reached
Configure roles and permissions
“Clone” and apply a unique name to a pre-defined user role
Grant users of that role, and only such users, access to particular forms
Leverage REST API services to:
add a participant
add participants in bulk
export a list of participant IDs
import data into forms
While role configuration is arguably the keynote of this release, all of these features enable managers to exert fine-grained control when study size, design, or duration require it.
Participant ID Naming Conventions
Consider a large, multi-center study expected to enroll hundreds or even thousands of participants. In these cases especially, data managers, trial managers, and monitors need a compact, informative lexicon to quickly gain insight into study progress, put issues into context, and refer questions to the best source of information. A standardized, meaningful participant ID is a key component of that lexicon.
Enforcing a standardized ID in an OC4 study is simple. Just head to your Settings tab, edit the Participant ID Settings, and select System-generated as your method of ID creation. Then apply or adapt the template provided.
Using simple syntax, data managers can define a convention that makes an ID truly informative. When site users add a participant, the convention is automatically applied. Following the example above, GER002-005 easily translates as the 5th participant enrolled at Site 002 in Germany. If participants GER002-005 and GER007-20 both show a randomization date of today, we can quickly and easily glean some useful information: at least 25 participants have been randomized in at least 2 activated sites in Germany, with Site 007 having randomized 4 times as many patients as Site 002. While users of OpenClinica Insight already have up-to-date metrics like this at their disposal, other users will now have an easier time extracting them from spreadsheets: it’s easy to parse out relevant information from a string in Excel when that information is always in the same place.
Regulatory bodies frequently mandate enrollment caps in high-risk studies. Exceeding that cap then becomes a major compliance hazard. The latest release of OC4 offers a fail-safe to protect against that risk, which can be significant in fast-recruiting, multi-center trials.
When the checkbox below ‘Expected Number of Participants’ is selected, the expected number becomes a hard limit. No user can add a participant, whether at the site or study level, once the number of (non-removed) participants reaches that limit.
Role and permission configuration
Some forms are meant only for properly trained users. Cognitive assessment ratings provide one such example. Administering the MMSE or ADAS-Cog requires more than just knowing what those acronyms stand for. (Curious?) Those scales are only meaningful in the hands of trained cognitive raters. As such, a form including the MMSE or MoCA that’s available to any user with data entry responsibilities jeopardizes data quality and risks protocol deviations. The latest release of OC4 enables data managers to restrict access to these forms.
The first step is to tag those forms you need to restrict. You can customize the color and name.
Once created, you can apply the permission tag to all relevant forms.
Finally, you’ll create a custom role with permissions to access the forms you’ve tagged.
Custom roles are based on standard roles at either the study level (Data Manager, Data Specialist, Data Entry Person, and Monitor) or site level (Investigator, Clinical Research Coordinator, or site-specific Monitor). Customs roles come with the same core permissions as their standard counterpart. However, by allowing access to tagged forms, data managers enable only users with the custom role to access equivalently tagged forms. (These users may also access untagged forms.)
In the example above, only users with the RATER role have access to the MMSE and ADAS-COG forms. Other users will not be permitted to: open the form in edit mode, review-only mode, or read-only mode; view queries on the form; SDV the form; extract the form clinical data in a dataset or participant casebook; or view common event tables for the form on the Participant Details page. However, the clinical data can be piped (e.g. though a cross-form note or calculation) into a form that is readable by users without the RATER tag. In this way, read and write permissions are separable.
REST API services
The capabilities of our REST API continue to expand in this release as well. It’s not easier than ever to…
add a participant
add participants in bulk
extract a list of participants
… through web services. OC4 uses the open source framework Swagger to help our users build and test their APIs. You can find the link on your study’s Administration page.
Last night’s release was the 5th overall since the creation of OC4 last year (not counting interim enhancements). It’s our most ambitious release to date, and in keeping with our mission to let data managers take total control with ease. As always, we welcome your input through the comments section below, and we look forward to continuing our close and successful collaboration with OC4 users. Not using OC4? Let us show you the power that awaits!
We are excited to announce that MIT professor and MacArthur genius grant receipient Dr. Regina Barzilay will deliver OC18’s Tuesday keynote on the clinical applications of deep learning.
From every pixel of their MRI scan to each word in their medical chart, patients bring a wealth of data to their clinical trial or care journey. We can learn from this data? It may not be obvious to human minds, but neural networks trained on historic data and outcomes may be capable of producing models that predict, for new patients, everything from future morbidity to treatment fit.
Regina Barzilay is a Delta Electronics professor in the Department of Electrical Engineering and Computer Science and a member of the Computer Science and Artificial Intelligence Laboratory at the Massachusetts Institute of Technology. Her research interests are in natural language processing and the applications of deep learning to chemistry and oncology. She co-directs the pharmaAI consortium at MIT. She is a recipient of various awards including the NSF Career Award, the MIT Technology Review TR-35 Award, Microsoft Faculty Fellowship and several Best Paper Awards at NAACL and ACL. In 2017, she received a MacArthur fellowship, an ACL fellowship and an AAAI fellowship. She received her Ph.D. in Computer Science from Columbia University, and spent a year as a postdoc at Cornell University.
Would you like to share a case study with fellow power users? Eager to share your domain expertise with other data managers? Submit an abstract for a chance to take the stage at OC18. We love to showcase projects that demonstrate an innovative use of OpenClinica. But if you simply have an original take on the interestion of personalized medicine and data management, we want to hear from you.
We encourage a broad interpretation of this year’s theme.
Have you led or participated in research that delved beyond an indication and eligibility criteria in its participants?
Have you personalized study workflows for your team?
How are you personally motivated by the research you do?