Jenya is a co-founder and VP Clinical at Flaskdata.io. Jenya has a masters degree in biotechnology from the Hebrew University and is a doctoral candidate at Tel Aviv in medical science. She is GCP and CRA certified and leads FlaskData.io customer operations with super-human devotion to customer delivery. Jenya has 2 children – Adam and Adel.
Back to basics
In this post, I want to get back to the basics when designing and EDC system. Here are 2 mistakes that you do not want to make in your next clinical trial – bad data model design, and bad UI.
A successful clinical trial starts with successful fundamentals.
FlaskData.io is an Israeli tech startup that provides “Automated detection and response “. Automated detection and response is based on unified clinical trial data management platform – a single platform that unifies online data collection and real-time monitoring and detects anomalous events and visualizes them so that medical device and biotech clinical teams can take action in real time and dramatically improve the effectiveness of their monitoring activities and shorten their time to market by eliminating avoidable rework.
By unifying data collection and monitoring in the cloud – we completely eliminate interfaces, eliminate data export and imports for offline analysis and improve and simplify data security.
However – with all due respect to marketing superlatives and innovative Israeli clinical cloud technology, successful medical device clinical trials start with successful fundamentals.
Today, I want to talk about two things – Subject identification and the importance of User Interface. I will explain and illustrate each point with examples.
Subject identification – Databases are not paper
In the days of paper CRF (case report files) it was common practice to code the Subject ID as a site identifier and a running sequence number like JH-001 and KP-001 where JH and KP are hospital identifiers and 001 refers to the first subject in each site. However, when we move to a relational database, this practice is not only unnecessary it is incorrect. One of the first rules of designing a robust data model is to separate data attributes from keys and to use global unique identifiers for entities like subjects. The reason for this is simple. Using the old paper CRF scheme of Site+Number, if a patient was mistakenly entered into the wrong site, you have to delete the record, record the mistake and then re-enter the record and all the associated CRF data into the new site. This is a colossal pain in the neck which usually results in a cascade of additional errors.
In addition, if you use a Central Lab and the Site+Number method; the Central Lab can easily enter the wrong data for the Subject since Subjects have the same Number. Again we get a cascade of deleting, annotating and re-entering the data to the correct subject and another colossal pain in the neck and cascade of errors and perhaps incur additional costs from our CRO.
The correct solution is to global unique identifiers for subjects and rely on the EDC database to retrieve the Site ID (a perfectly trivial task for a relational database). Using a data model of global unique identifiers for subjects, it is trivial to update the Site identifier and by using global unique identifiers for subjects, it is impossible for a Central lab to make a mistake like entering Histology results for patient 001 in site JH when patient 001 really belongs to site KP.
The importance of a Consistent User Interface.
The second story I want to tell is about Consistent User Interface. The most important person, your biggest friend and critical success factor to clinical data collection is not the technology, the EDC software, GCP or ICH quality standards. It is the person who enters the data – the CRC (Clinical research coordinator) or the subject himself (for patient reported outcomes).
Since it is a person entering data – the importance of a Consistent User Interface cannot be underestimated. If you have to enter a blood pressure reading – it should be simple and always look exactly the same. Here is an example of an ambiguous and problematic User Interface in a histology CRF:
In this above form B and C should be equal to A. However A is physically far from B and C (the human eye loses context and content with the Histology reference value) and worst of all – the values in the radio buttons of A are not consistent with the values for Fat reported in B and C. In NAS and SAS/FLIP – 1 means less than 6-33% and in the Histology Data – 1 means 0-5%.
How confusing can you get! No wonder – the Central Lab in this study refused to use the form!
However – there are additional consequences for not using a consistent UI and coding scheme:
- Additional non-value added data validation queries are generated, creating more work for the site and the study monitors.
- Confusion and lack of consistency for the study bio-statistician who has to understand when parsing a SAS export file that in one case 0 means no data and in another case 0 means 0-5% fat
Here is a better solution with a consistent UI where A (Histology Data) and B (NAS) and C (SAF/FLIP) have the same look and feel and same set of values.
In summary:
By using modern insights for data model and UI design, we can make an online clinical data management system much easier to use, much more accurate and significantly reduce the amount of noise due to user data entry mistakes.
Read more here and here about the importance of a robust data model for your clinical trial and here about how to design and implement and here about the importance of collecting dates.
