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

User masquerade and other ideas

lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
I'd suggest reconsidering the idea of one site per subject before ruling it
out. That's probably the most viable route to using OpenClinica for this
use case with minimal customisations, since sites and studies are the only
built in mechanisms for restricting interactive access to subject data
(besides Participate, but that's a separate app).

The software you might need to work on then is a tool to automate the task
of creating one site per participant user account. This could be something
that works directly with the database, or something that automates
interaction with the web app via a browser (selenium).

For non-password authentication, there is LDAP but it won't save any effort
if the LDAP account isn't used for anything else. Many months ago there was
a pull request / contribution on GitHub which implemented SAML
authentication. It wasn't merged, but you might find a use for it.

It looks like delegated authentication is on the horizon for OpenClinica 4
anyway. Either you could trawl through Jira and GitHub for clues, or maybe
Krikor will talk about it at the next API design advisory meeting (not sure
when that is).

Lastly, this kind of thing may be suited to RedCap. It's designed for
longitudinal surveys, completed either by staff or participants. I haven't
watched it too closely but it may be at or approaching the point where it's
usable as a clinical research EDC.


  • kristiakkristiak Posts: 1,339 ✭✭✭
    Hi Lindsay
    Could you possibly elaborate how this would work using Selenium with OC


  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    Haha, so most of my recent email replies to threads are disappearing
    because they're creating new threads in general discussion! This one is
    actually a reply to a thread started by @rogeroge at

    Anyway, Krister - about selenium. The concept is that every time you do
    something in the browser, data is being sent back and forth, and the
    browser deals with it to present you with a HTML web page. When you click a
    button or a link it's usually acting by sending a request to a URL.

    With selenium, you inspect the HTML for data that relates to your task.
    That could mean finding the URL associated with the button to add a site,
    or the finding the field to edit a site configuration, and so on. This data
    is then used to make requests. Many of these tasks are chained together and
    the result is an automated workflow.

    Many of the OpenClinica workflows are already implemented for automation in
    this fashion. Since selenium is actually a testing tool, this code is part
    of the closed-source test suite that underpins Enterprise validation for
    the regulatory support package product. So it may be easier to try to
    negotiate purchasing and adapting this code from OpenClinica LLC than
    writing it.

    Or if you have a programmer available, selenium is easy to use and is
    compatible with most general purpose languages: Python, Java, Ruby, etc.
    The final code would essentially take your new site / user info as input,
    use selenium to find data in the HTML, send the relevant requests to make
    the user and site, and let you know the outcome.
  • kristiakkristiak Posts: 1,339 ✭✭✭
    Thanks for the detailed explanation! :)
  • rogerogerogeroge Posts: 16

    Thank you for your reply - I too was confused by the actions of the thread poltergeist.

    The selenium option is a possibility although the setup overhead is 'immense' requiring both a site to be set up, then an account and finally a role/account association just for a single patient to see their own casebook [for example]. I think we are over-stretching the architecture here and whilst I appreciate OC is designed for the paradigm of the paternalistic clinician looking after a group of patients our paradigm is quite different. Also are numbers are big [10,000-100,000] which will stretch the OC site model into a place I guess it is not expecting to go

    [We looked at selenium earlier and had some concerns over the robustness and reliability of the solution, it is a solution which is getting better all the time].

    Sadly Redcap has similar embedded thinking. It has made good progress on having an off-line client for android and IOS but sadly the display, capability and user management remains locked to the 'mothership' study which is limited by the paradigms of 'green screen computing'.

    I always cite a discussion I had in the University, when we implemented GoogleMail for the students when someone asked about who would run the help desk? After a moments thought you realised that Google do not have a help desk for their services. It is the same issue here we need to start the thinking at a very different point - secure access without an embedded internal user role system: there are options used in other spheres such as One Time Passwords which rely on external identity verification and a 2 way communication protocol.

    As you will also recall from our discussion on xForms this separation of responsibilities [with OC as the hub system for data provenance management] is where we are and where we want to go. Our communities have embraced data use away from modality of the doctor behind a desk with a 'green screen' terminal. This will be an element of the eco-system but not the only thing.

    We have 2 major investigations at the moment: the extent to which xForms are indeed standard and exchangeable between systems and similarly the use of ODM-XML to shift studies and CRFs between different system [such as OC, Redcap, ODK]. So far the work is not encouraging it seems everyone is using a 'super-sub-set' of the standard. But we have only just begun

Sign In or Register to comment.