Clinical trials are hard. Even starting can be a challenge, when protocols need to be written, optimized, and agreed upon so they will fairly compare the therapies in an ethical way. However, in many ways, once the protocol is written, then even more arduous work begins. Now, the protocol must be turned into an actual, working trial!
An often overlooked, but difficult, step right in the beginning – to fulfill the protocol, what data do we collect, and how can make sure it’s right? To do this, we define and use a “Case Report Form” (CRF). Think of a CRF as a literal form! It’s all the data that’s entered for each patient, at each step of the protocol – for each visit to the clinic, labs that might be collected, demographics, etc. The goal is to find each field in the protocol that needs to be captured and then add (and configure) that field in the electronic data capture system (EDC). The flow is essentially, (1) find the field, (2) define how to capture that field (is it a list to pick from or a question to answer?), (3) add that field to the EDC, and (4) configure that field to make sure the edit checks are defined (e.g., the rules for correctness). As an added bonus, there might be rules across fields which could also indicate incorrect values.
This is clearly an onerous and manual step, especially as protocols continue to be written out, by hand, into ever larger PDF documents. As an AI company in the clinical trial space, a challenge was posed to us: Can you automate the process of turning a protocol into a data model? (e.g., the fields, edit checks, and multi-field rules for medical monitoring). By doing so, it would begin to automate the construction of the CRF and the “study building” period of a trial.
Being technologists, we said “of course” and then proceeded to figure it out (usually people say, “let me check…”). However, we knew that our AI-based knowledge base already contained thousands of fields that it understands. For instance it knows an “Age” cannot be negative, a “Total Billirubin” should not exceed 20.0 mg/dL, and that if “Systolic Blood Pressure” is less than 70 mmHG, then “Diastolic” should not exceed 100 mmHG.
So the challenge for us was to create an AI agent that will identify the fields in a protocol, given a PDF document, and then a second agent to map those found fields to our knowledge base. Doing so solves a number of steps: not only can we begin to define the CRF, using the fields extracted from the document, by mapping them to the knowledge base, we get both the configured edit checks (such as Age) and the medical monitoring rules as well (such as Systolic and Diastolic checks, which could be fine on their own, but problematic together).
This is exactly what we see in the screenshot above. The first AI agent takes the text and identifies the fields – complete with page and sentence for provenance (transparency is key for us to maintain our 21 CFR part 11 compliance, as well as a crucial component to maintaining trust with our users). The second agent them maps those fields to the knowledge base to configure the data integrity. The final step is the integration directly with the EDC to “build” the study, and we’re off.
While the full CRF isn’t yet implemented (for instance, there might be fields added, removed or even missed by the AI), this is a powerful start. We’d love an opportunity to demonstrate this capability live, so please, feel free to reach out!
