We have been on the market since 2015 under the brand name Data Management 365 and earlier as a division of Flex Databases. All the time we have been an innovative company as the world of clinical trials is constantly developing and the way to success combines reactive and mostly proactive approaches. So, when we first heard about LOINC, we said to ourselves: “Oh, that’s going to be a new challenge! Cool.”
What we started from, was extensive reading:
LOINC publications to learn the new standard prospectively required in FDA data submission;
CDM community publications to see what others plan to do about that (not much information from there though).
What questions we raised with ourselves, as a software provider for DM:
how to build LOINC into the process of data collection;
how to merge LOINC coding with SDTM configuration;
where to start from (find the right application point in EDC);
what to offer to our EDC clients as a most convenient tool for LOINC implementation their end;
many other questions from a seemingly endless list…
We took all of them into analysis and spent hours on grooming this part of our product backlog.
Just an example of the forks on our path to the decision (the one related to lab data processing):
most obvious and easy way was to map the LOINC code over the appropriate LB variable by derivation – well, extensive reading (see above) helped us avoid this mistake;
then, based on the working group recommendation to apply the LOINC code during the creation of the raw data, our CDM experts advised that the code must be incorporated into eCRF at the stage of forms build – this was doable and consistent with MainEDCTM Lab Wizard that helps effectively handle the variety of local lab tests, analysers, units and reference ranges by age groups and gender, so you only would have to add one more parameter;
having given it a little more thought, we’ve realized that it might have been too early as at that stage we would rarely have understanding of which sites and local labs were going to participate in the study, with even less understanding of what assays they would use;
so, the logical conclusion led us to the idea that LOINC codes must be chosen from the source at the time of uploading the local lab data with all its analysers parameters to EDC on production, at the first release of the eCRF and then at each update of the local lab reference ranges. This was the correct application point, to our understanding.
We’ve walked it through to the working model:
just like we deal with MedDRA and WHODrug dictionaries (as DM 365 is the official software partner of the both), we can upload LOINC source files twice a year, when a new version is available;
at the time of obtaining the local lab parameters we confirm the assay method and other details with the lab responsible person;
we link each lab test to the appropriate LOINC code at the time of the local lab data upload or update;
when the Investigator chooses the applicable test name and units from the drop-down list in the eCRF field, it is already linked to the correct LOINC code;
when we configure the LB and supportive domains in EDC, there is no need for derivation at all as the variable is being mapped directly;
we have already tried this in two ongoing studies;
needless to say that where a central lab is used in a study, all this process becomes very straightforward, due to uniformity of the lab data and quality management at the lab side that ensures smooth and robust cooperation with DM, resulting in valid datasets production with less effort.
