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?

2»

Comments

  • LizRLizR Posts: 60
    Paul, just because it's NCI developed, that doesn't make it indication-specific, right?
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Friday, February 21, 2014 1:02 PM
    To: [email protected]
    Subject: Re: [Users] open source CTMS?
    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
  • isartwisartw Posts: 22
    I’ve seen caBIG integration code now is removed from OC CE. Not sure if this is existing in EE.
    Arthur Isaenko
    [email protected]
    On Feb 21, 2014, at 4:02 PM, Paul Baumgartner wrote:
    > 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)
    > pau[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
    >
    >
  • cra360cra360 Posts: 56
    Liz,
    Great thoughts and observation. Thanks for sharing. I agree simplifying tends to deliver more value than excessive "integration".
    Specifics.
    Regarding AEs and SAEs,
    a) "and the narrative stuff is all done outside OC", I'd appreciate it if you could elaborate a bit on the "Outside OC" part. Confluence? Maybe...
    b), it would be very nice to have a field that could mark an AE as SAE, instead of non-systematic notes on such a case. Maybe it's already doable in current OC but my lack of deep knowledge of OC prompts the question...
    Protocol Deviation (PD)
    Interesting to note, to tie it to Notes and Discrepancies (ND). Again, it would seem very desirable to have a field or some similar mechanism to mark a note/discrepancy about such a situation, hence, it would leave less room for semantic misunderstanding, new clinical staff such as CRA may need extra training to understand how PD is mapped to ND.
    Use of Confluence by your company ("keep the results in a space in Confluence")
    It seems Confluence is a team collaboration tool. On the onset, it looks like a beef-up version of email package... interested in learning what's so unique and valuable it is to clinical trial, and how are "messages' stored? A back-end database? If so what?
    On simplifying processes and systems
    Right on, can't agree more.
    Pertaining to our requirements
    I'll send you a private email in a day or two.
    Best regards,
    Don
    Don
    Chunshen Li
    CTO
    Seahawk Innovation Funds
  • pbaumpbaum Posts: 2
    Liz,
    Correct, it is not indication specific.
    Best,
    Paul
    On Fri, Feb 21, 2014 at 5:04 PM, Liz Robertson wrote:
    Paul, just because it's NCI developed, that doesn't make it indication-specific, right?
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Friday, February 21, 2014 1:02 PM
    To: [email protected]
    Subject: Re: [Users] open source CTMS?
    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
  • wsonbolwsonbol Posts: 4
    I recently published an open source CTMS. Feel free to review and download from github.com/trialmanager/voxce

    It is J2EE solution
  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    Thanks for sharing this.

    Just in case anyone is interested, here is what I found from looking at the
    repo for a few minutes:

    There is a pptx (voxce_demo.pptx) with some screen shots in the repo. It
    looks like there are a lot of good ideas in there, covering most trial
    management areas. Not clear whether the CRF parts can receive data or of it
    is only for tracking.

    Some bits that might need some work:
    - passwords are md5 only (usersdao.java)
    - reset password seems to send new random password but not require change
    at login
    - email has hard coded details (mail.java)
    - sometimes sql parameters are set with string concatenation instead of
    parameterised queries

    I couldn't see the stack requirements written out but it looks like at
    least mysql (hibernate.cfg.xml) / tomcat7 / java6 (.classpath).
  • wsonbolwsonbol Posts: 4
    @lindsay.stevens - you are correct.

    The email information can actually be configured through the database.
  • rkrennrkrenn Posts: 5
    edited June 2015
    One might take a look at the Phoenix CTMS as well. Another successful approach using JEE technology, with emphasis on various aspects of trials. A detailed description can be found here:

    https://www.researchgate.net/publication/263412137_Design_and_Development_of_a_Web-Based_Clinical_Trial_Management_System

    Upon interest, the preparation of a github release could be considered.


  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    Hi René

    I had a look at your thesis, very impressive and the system sounds
    excellent. I am interested in seeing the open source release!

    I have a couple of questions:

    - will the release include the automated test suite?

    - will the release include the UAT plan that is mentioned in the conclusion
    (although not undertaken, maybe it was planned out)?

    - are you planning to release the future enhancements mentioned in the
    conclusion, e.g. once released do you plan to maintain the source in public?

    Thanks for sharing this,

    Lindsay
  • rkrennrkrenn Posts: 5
    - will the release include the automated test suite
    unit test stubs are generated at built time and cover the service and dao layer completely, but not UI. final unit tests are however implemented to a minimal extend only. instead there is a demodataprovider, which allows to simulate trials and represents a joint integration test of all risk-related modules. it was also used for load testing.

    - will the release include the UAT plan that is mentioned in the conclusion
    The system is successfully running in production since over two years now.

    - are you planning to release the future enhancements mentioned ...
    The university desires to use it in the long-term and it is therefore actively maintained, currently v1.2.9 with app. 300 tracked improvements (also major ones such as LDAP interconnections) since its launch. The github release will of course only make sense with these changes upstreamed.

    The open source release was planned from the beginning, but became interesting with the system's maturity now. We already have rhel, debian and amazon e2c images prepared for quick start. Additional info can be found here.
This discussion has been closed.