We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit https://register.gotowebinar.com/register/2882170018956684555

open source CTMS?

Hi all,
I wonder if there's an open source CTMS package out there. Googling hasn't produced anything meaningful about such quest so far.
Thanks in advance.
Don
«1

Comments

  • isartwisartw Posts: 22
    There is no open source CTMS to my best knowledge.
    May I ask you, what specific features are you looking for? There are bunch of affordable CTMS on the market, so you may take one of them.
    Arthur Isaenko
    [email protected]
    On Feb 20, 2014, at 3:03 PM, Don Chunshen Li wrote:
    > > Hi all,
    > >
    > > I wonder if there's an open source CTMS package out there. Googling hasn't produced anything meaningful about such quest so far.
    > >
    > > Thanks in advance.
    > >
    > > Don
    > >
  • cra360cra360 Posts: 56
    Arthur,
    We're interested in knowing if there's any PD (Protocol Deviation) at a site, Safety Reporting, SAEs etc. And I'm not sure if OC has built-in support for them.
    Thanks.
    Don
  • LizRLizR Posts: 60
    Why, precisely, do you want a separate storage for SAE data? I know that it's a thing that people do, but no one's been able to give me a compelling reason for it.
    Regards,
    Liz
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    Hi Don,
    I've looked in to this before as well. The main problems seem to be that clinical trials is relatively a niche area for software, and the requirements for trials tend to have a wide but shallow scope (e.g. I might need to do a little bit of invoicing but do I need full-blown accounting?), so the easy answer tends to be to make another spreadsheet.
    Maybe you could consider repurposing something flexible like OpenERP, SugarCRM, Dolibarr, etc as a CTMS. These open source CRM/ERPs tend to have modules for things like project management, invoicing, warehouse management, and so on.
    Although since you're only after Safety Reporting and Protocol Deviations, could you do SRs with a CRF and PDs with discrepancy notes or a hidden CRF?
    Best regards,
    Lindsay
    On 21 February 2014 08:41, Liz Robertson wrote:
    Why, precisely, do you want a separate storage for SAE data? I know that it's a thing that people do, but no one's been able to give me a compelling reason for it.
    Regards,
    Liz
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
  • tdpurnattdpurnat Posts: 126
    I use a protocol deviations CRF and all SAEs also go into a separate event per subject.
    I haven't found the best way to manage them in OC -- some protocol deviations relate to all patients/site/general issue, so our solution was to make a dummy "all patients" subject that records such deviations.
    The SAE is difficult, depending on the workflow and the requirements of the SAE reconciliation process. SAE data in studies I work with tends to be edited relatively lot after first report (again, depending on context). My studies have tirned on administrative editing with enforced reason for change (study-level enforcement, not per event or CRF), and the pharmacovigilance people I work with really don't like this on their CRFs, because they are used to writing updates and comments into notes fields in the actual form. This also faciltiates when the CRF is printed - if all updates went into DNs, they would not have a complete record of the case by just printing the CRF.
    So I've tried making a separate dummy study for SAEs to which only pharamcovigilance people have access to, and set our own study settings, but that has drawbacks too.
    Tina
    -------------
    Skype: tdpurnat | Office: +49 89 38 03 89 67 | Mobile: +49 151 29 17 99 64
    Why are my emails so terse? emailcharter.org [TED blog]
    2014-02-21 1:40 GMT+01:00 Lindsay Stevens :
    Hi Don,
    I've looked in to this before as well. The main problems seem to be that clinical trials is relatively a niche area for software, and the requirements for trials tend to have a wide but shallow scope (e.g. I might need to do a little bit of invoicing but do I need full-blown accounting?), so the easy answer tends to be to make another spreadsheet.
    Maybe you could consider repurposing something flexible like OpenERP, SugarCRM, Dolibarr, etc as a CTMS. These open source CRM/ERPs tend to have modules for things like project management, invoicing, warehouse management, and so on.
    Although since you're only after Safety Reporting and Protocol Deviations, could you do SRs with a CRF and PDs with discrepancy notes or a hidden CRF?
    Best regards,
    Lindsay
    On 21 February 2014 08:41, Liz Robertson wrote:
    Why, precisely, do you want a separate storage for SAE data? I know that it's a thing that people do, but no one's been able to give me a compelling reason for it.
    Regards,
    Liz
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
  • cra360cra360 Posts: 56
    As mentioned I'm fairly new to OC and to this industry in general, so, l'm learning...
    Yes, I would think it would be so much better if all the key data are stored and managed by one system such as OC.
    For key data, I'm talking about, study/trial info, trial subject data, discrepancies and queries, SDV, CRFs, events etc, and possibly critical communication data as well if possible. Hence, if we want to, we might be able to know a site's overall performance status and key personnel performance as well...
    Now, quick question, how and where is AE, especially SAEs are stored with OC? I've looked at the study_event table, and don't think it's tied to AE or SAE.
    Thanks.
    Don
    Don
    Chunshen Li
    Chief Technology Officer
    Seahawk Innovation Fund
  • tdpurnattdpurnat Posts: 126
    Hi Don,
    Make a CRF for AE and SAE, upload, link to an event and there you go...
    Tina
    -------------
    Skype: tdpurnat | Office: +49 89 38 03 89 67 | Mobile: +49 151 29 17 99 64
    Why are my emails so terse? emailcharter.org [TED blog]
    2014-02-21 16:13 GMT+01:00 Don Chunshen Li :
    As mentioned I'm fairly new to OC and to this industry in general, so, l'm learning...
    Yes, I would think it would be so much better if all the key data are stored and managed by one system such as OC.
    For key data, I'm talking about, study/trial info, trial subject data, discrepancies and queries, SDV, CRFs, events etc, and possibly critical communication data as well if possible. Hence, if we want to, we might be able to know a site's overall performance status and key personnel performance as well...
    Now, quick question, how and where is AE, especially SAEs are stored with OC? I've looked at the study_event table, and don't think it's tied to AE or SAE.
    Thanks.
    Don
    Don
    Chunshen Li
    Chief Technology Officer
    Seahawk Innovation Fund
  • cra360cra360 Posts: 56
    Ahe, I took back the AE question, study_event_definition table would tell us what type of event an event is. Thanks.
  • LizRLizR Posts: 60
    We catch our SAEs on the same CRF pages where we put the AEs. They're handled differently as soon as someone checks the box indicating that the event is an adverse event. The information in the CRF is the bare minimum necessary for reporting, and the narrative stuff is all done outside OC, although if you wanted to give them forms for that in OC, you certainly could. Somehow, it seems like if you're going to get supplemental data that might accidentally identify a patient, it seems to want to happen when there's an SAE, so I don't really want a lot of extraneous stuff in the clinical database. It's never, ever seemed like a good idea to me to permit the keeping of a separate AE database precisely because reconciling it against the clinical database is a great way to lose data integrity, not to mention really **** everybody off. Not doing that saves time, money, and gains goodwill from sites.
    We work exclusively in cancer, which means deviations are a hellish nightmare. The patients are just so sick that you can't count on anything happening when it's supposed to. If I had simple protocols where things largely went according to plan (I've never seen such a thing, but people tell me they exist), then I would handle my deviations entirely through the notes and discrepancies. Issue a query, confirm deviation, put in a specific bit of text in the closing note of the thread, and when you output your notes and discrepancies, find the ones with that bit of text. Et voila, a trail of all your deviations and the conversation about them, tidily hooked into the data that's impacted.
    In fact, our data managers, study managers, and pharmacovigilance folks fight through multiple discrepancy threads, have long talks in email with sites and monitors and medical monitors, consult various oracles under specific phases of the moon (okay, that one's an exaggeration), and then keep the results in a space in Confluence, which is what we use to track all sorts of things I don't want in the clinical database, and finally report them out in the end of the study. It's brutal, but you can't fix people problems with software.
    We set about building up our processes a couple years ago with this idea that we needed a CTMS, an SAE database, all these things we'd just gotten used to, and then when we really sat down and thought about it, it turned out that we just didn't get that much utility out of it, certainly not for the money and effort. We simplified, we've been happier. Our data is more reliable, the more direct our methods are, the less spread out it is. As we grow, it still seems better to keep our tool set leaner and sharper, to work efficiently with what we have, rather than build out into a sprawl of infrastructure that's not really adding that much value.
    So, if you're coming from that same kind of place where it's just what everyone else has been doing, I encourage you to pause and think very clearly about your actual user requirements. Post 'em up, let's see what everybody's doing, it'd be good for all of us.
    Kind regards,
    Liz
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
  • pbaumpbaum Posts: 2
    Regarding the question of an open sourced CTMS, the NCI developed various CTMS modules for subject registration, patient schedule management, and SAE reporting. The SAE module, caAERS (pronounced "cares") is still actively supported by the NCI and has recently had numerous service interfaces developed to support integration with various NCI systems, including the NCI CDMS. These interfaces could be used to support integration of AE data collected in OpenClinica and then sent to caAERS for SAE reporting (including electronic submissions, queries, etc). There is an OpenClinica blog post from 2008 regarding potential OC and caAERS integrations. Additionally, the NCI-CTEP has announced that on March 1, 2014 they are replacing their current SAE system (AdEERS) with a modified version of caAERS, re-branded as CTEP-AERS.
    I'd be happy to address any questions.
    Best Regards,
    Paul
    --
    Paul Baumgartner
    Sr. Project Manager
    SemanticBits, LLC
    703.787.9656 x 221 (O)
    [email protected]
    On Fri, Feb 21, 2014 at 1:00 PM, Liz Robertson wrote:
    We catch our SAEs on the same CRF pages where we put the AEs. They're handled differently as soon as someone checks the box indicating that the event is an adverse event. The information in the CRF is the bare minimum necessary for reporting, and the narrative stuff is all done outside OC, although if you wanted to give them forms for that in OC, you certainly could. Somehow, it seems like if you're going to get supplemental data that might accidentally identify a patient, it seems to want to happen when there's an SAE, so I don't really want a lot of extraneous stuff in the clinical database. It's never, ever seemed like a good idea to me to permit the keeping of a separate AE database precisely because reconciling it against the clinical database is a great way to lose data integrity, not to mention really **** everybody off. Not doing that saves time, money, and gains goodwill from sites.
    We work exclusively in cancer, which means deviations are a hellish nightmare. The patients are just so sick that you can't count on anything happening when it's supposed to. If I had simple protocols where things largely went according to plan (I've never seen such a thing, but people tell me they exist), then I would handle my deviations entirely through the notes and discrepancies. Issue a query, confirm deviation, put in a specific bit of text in the closing note of the thread, and when you output your notes and discrepancies, find the ones with that bit of text. Et voila, a trail of all your deviations and the conversation about them, tidily hooked into the data that's impacted.
    In fact, our data managers, study managers, and pharmacovigilance folks fight through multiple discrepancy threads, have long talks in email with sites and monitors and medical monitors, consult various oracles under specific phases of the moon (okay, that one's an exaggeration), and then keep the results in a space in Confluence, which is what we use to track all sorts of things I don't want in the clinical database, and finally report them out in the end of the study. It's brutal, but you can't fix people problems with software.
    We set about building up our processes a couple years ago with this idea that we needed a CTMS, an SAE database, all these things we'd just gotten used to, and then when we really sat down and thought about it, it turned out that we just didn't get that much utility out of it, certainly not for the money and effort. We simplified, we've been happier. Our data is more reliable, the more direct our methods are, the less spread out it is. As we grow, it still seems better to keep our tool set leaner and sharper, to work efficiently with what we have, rather than build out into a sprawl of infrastructure that's not really adding that much value.
    So, if you're coming from that same kind of place where it's just what everyone else has been doing, I encourage you to pause and think very clearly about your actual user requirements. Post 'em up, let's see what everybody's doing, it'd be good for all of us.
    Kind regards,
    Liz
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
This discussion has been closed.