Would love your feedback on expanding REST WS calls

Hi Everyone,

There has been discussion around expanding our RESTful web services to include all data for a study or site. We've been giving this some serious consideration and will likely be doing work in this area as soon as March (possibly Q2). Here's what we're thinking:

1. Add the functionality to use * (all) to the REST call for sites and a study (this means you can get all subject data from a site or all subject data across the study)

2. Include in the REST output (XML, JSON, HTML) deleted event CRFs down to the item-level

3. Add a query parameter to the REST call to include removed objects / items / item data. Basically, the way that OpenClinica works now is that if something is removed it is not included in the ODM. By adding a query parameter you could also include removed data.
It might look something like /includeRemoved="y"

These changes would only affect the REST WS (not extract data). I'd love to get feedback from those that are using web services.

Cheers,
Alicia

Comments

  • toskriptoskrip Posts: 252 ✭✭
    Hallo Alicia,

    > 1.
    it would be nice to have this feature, I know that couple of people are already waiting for it

    > 2. and 3.
    I agree with 3. point, include the deleted events but only when specifically addressed with query parameter

    Additionally I would find very useful if we can influence the level of output, e.g.:

    - I need only subjects data
    OpenClinica/rest/clinicaldata/json/view/S_STUDY/*/

    - I want subjects and events data
    OpenClinica/rest/clinicaldata/json/view/S_STUDY/*/*

    - I want a list of studies available for user
    OpenClinica/rest/clinicaldata/json/view/*

    best
    Tomas
  • kristiakkristiak Posts: 1,266 ✭✭✭

    Hi Alicia,

    Tomas summarized it very nicely and I agree with him!


    Regards


    Krister


  • agoodwinagoodwin Posts: 131 admin
    via Email
    Hey,

    Thanks for the feedback.

    Regarding Delete vs. Removed -
    We were thinking that we would always include "deleted" as part of the
    audit (without a query parameter). We got feedback on this as something we
    should do for regulatory purposes. In OC it is only an event CRF (single
    CRF for a subject) that can be deleted - I don't *think *there would be too
    many of these records (perhaps it would not affect the payload
    significantly).

    For removed we think this could have a much more significant impact with
    removed / auto-removed and therefor would put the query parameter.

    Would you agree with this? Or do you think there is more significant use of
    delete?

    Lastly, we are thinking of changing how the "delete" function works. I'll
    probably post to a more general discussion about this, but basically we're
    thinking of making "delete" a "clear" instead. This will be easier to
    retain audit records. It would basically reset all of the values to "" and
    get rid of discrepancy notes.

    There are 2 goals that we have -
    1. Expand use and usability of REST WS
    2. Retain a complete, full, audit / casebook in a clean way; available via
    REST WS

    Best,
    Alicia



    On Wed, Jan 14, 2015 at 11:09 AM, kristiak
  • toskriptoskrip Posts: 252 ✭✭
    Hi,

    > removed/deleted
    In general I agree. We use remove action when some information was collected but is no longer necessary and we what to remove it from export. E.g. two follow-up visit have been scheduled in very short time and only the lastest one should be considered. So removed option for us mean (do not delete the data) but consider them obsolate, so hide them from export (ideally also from REST WS call result - if no explicit parameter is specified).

    on the other hand I see the delete action make sense for me only if a human error occurs, e.g. data entry person accidentally scheduled and filled information for a wrong subject.

    if it is important to keep for regulatory reasons, the other people have to say, as I don't consider myself to be regulatory expert.

    > delete -> clear
    indeed there should be a separate discussion about this topic. If you are planning such change maybe it is not a bad idea to have both options implemented (and user will choose which method of deletion should be used).

    T
This discussion has been closed.