The end of the eCRF in local language? Workflows for meeting local and global demands in your non-interventional study (NIS)
Today, in our highly interconnected, digitalized society, everyone speaks English, or at least we in clinical research like to think so. But let’s face it: we cannot expect every doctor or nurse in every European country to be proficient in English.
This is especially true in the non-interventional setting, where sites’ experience with study conduct may be limited in some fields. In a non-interventional study (NIS) you want to capture the real world data, so you may also use the “real world language” of the respective country. Especially with increasing complexity of non-interventional studies, forcing sites to use English whether they are comfortable with it or not, can prove a real problem. If the site personnel are not comfortable with documentation in a foreign language, compliance and data quality are in jeopardy. To avoid this, language specific adaptations are usually a good solution.
However, what aspects do you need to consider when planning a multi-lingual eCRF? And are regulatory requirements effective 22 November 2017 a cut-off date for the future of eCRFs in local language?
What ways are there to help sites with language issues?
The “easy” (or rather cheapest) option is to have an English eCRF and to provide the sites with annotated translations of the eCRF as part of the user manual. Bear in mind that this option works well for categorical data collection but as soon as you have free-text entries, you may encounter either ambiguous translations or simply local language entries.
Consider that in the non-interventional setting you are asking the sites to integrate the data documentation in their everyday routine. Therefore, the effort associated with data documentation should be as limited as possible. When you ask the site for a lot of data, the annotated translation may be perceived as user-unfriendly and the site’s motivation may rapidly decline with such a solution.
Therefore, the best option (especially for large, complex eCRFs) is the provision of country (language) specific adaptations of the eCRF. This means that your entire eCRF (including help texts, error messages and choice options in drop down menus) is translated in the respective local language. At best, if you can, give the sites a choice of language for their preference. Ensure that the translation really reflects the English master eCRF to avoid misunderstandings due to false translations.
While this option is certainly user-friendly, there are several issues related to a eCRF in local language, especially in terms of pharmacovigilance.
Points to consider with local language eCRF entries
Regardless whether you use the full local language eCRF approach or the annotated translation manual, you will have to work with free-text entries in local language.
For data cleaning and analysis purposes, your study team will need to review these data and, therefore, require translations of local language entries into English. In addition, when you assume that English fluency might be a problem, you should work out a process for the translation of data management queries into local language. In turn, the sites’ query answers require a translation into English as well.
Accordingly, you need to adapt your internal (local and/or global) workflows in medical surveillance, centralized monitoring and pharmacovigilance when implementing local language into the eCRF. Unless the study team members are fluent in the respective local language (e.g. German CRO and/or monitors working on an eCRF where sites may document in German), listings and data for central monitoring and data review are subject of a translation workflow. The same concerns respective queries.
Special case: pharmacovigilance
While performing translations in regular intervals might be acceptable for certain constellations, it may be insufficient for pharmacovigilance related screening purposes. Most market authorization holders (MAH) define their date of awareness as the date when the site has entered data into the eCRF (see also Choosing the right safety reporting workflow, Data review for pharmacovigilance purposes). Under this definition, the regulatory clock for event reporting starts the minute the site enters the data.
Data constellations that would require expedited reporting to regulatory agencies therefore would need implementing an expedited translation loop, in order to meet regulatory time lines.
The same might be true when there are many data sets to review, e.g. in the context of adverse drug reaction (ADR) screening. As of 22 November 2017, all non-serious ADRs have to be reported to the EudraVigilance database every 90 days.
Therefore, you might want to choose a regular review of pharmacovigilance related data (e.g. adverse event entries) and screen for unreported ADRs (see also Data review for pharmacovigilance purposes). However, in order to do so, all local data entries must be translated into English.
To allow for sufficient time for pharmacovigilance related screening and queries, you may need to implement stringent and time-effective consolidated translation workflows.
So then, is this the end of the local language eCRF?
No! Of course, the entire process is much easier if all involved parties literally speak and use the same language. However, it is also possible to conduct studies in local language (with sites feeling comfortable with the system, understanding queries, and thus, providing solid data), while pharmacovigilance (and other time-sensitive tasks) are not in jeopardy. It just takes more efforts in terms of planning of the respective workflows and getting local and global processes in line.
For instance, delegate the translation, processing and query management around adverse event (AE) reports or pharmacovigilance related screening activities to personnel or organization units who are proficient in the respective language – this may be within or outside the MAH organization. Accordingly, consider the capacity of internal and external resources in this process a priori, preferably in the course of internal budget planning.
There may be steps that can be handled by local monitors, while others still require personnel commitment within the local or global organization (or respective outsourcing). For instance, a big international non-interventional study may be easy to handle for the pharmacovigilance departments of big country affiliates, but might be rather challenging for smaller country organizations.
Therefore, identifying the needs of all involved countries and defining the respective workflows is the main determinant whether you can offer your sites the benefit of a local language eCRF within your individual project.