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

Parameterized links: What’s your use case?

agoodwinagoodwin Posts: 131 admin

Parameterized links: What’s your use case?

So we’re working on building what we’re calling “parameterized links” which I’ll explain in a bit. There is a lot of potential for people to use these links in different ways and I’d like to hear about how you think this could be used!

When designing a CRF, you can incorporate HTML into text fields to create a (static) URL. What we are working on is a way of incorporating study objects as variables into a URL. This way you could use a substitution variable for things like Study Subject ID.

Let’s say, for example, you have an external imaging system and depending on which subject the user is entering data for, when they click a link, the URL that is generated will use their Study Subject ID.

When designing my CRF, I would create a URL that looks like this (for example):

https://www.ocimagedatabase.com/${StudyName}/${Event}/${StudySubect}

In the rendered form, each of these variables will be a substitution token, so clicking on the link would open a new window with (for example)?

https://www.ocimagedatabase.com/TestStudy/Visit2/SS100

The exciting thing is that these are substitution tokens that can be used in Left Item Text, Right Item Text, Headers and Subheaders . We imagine that folks can incorporate these into jQuery and other things.

How do you think you might want to use this?

Comments

  • toskriptoskrip Posts: 279 ✭✭✭
    I think that usage scenarios are clear in this case. It will allow people to redirect to other web application (PACS, LIMS, ...), or call external web service. I could also imagine the scenario for a subject randomisation. I have to say that something similar is already possible to accomplish with a little bit of javascript and embedded HTML into CRF (if the parameters which should be part of URL are CRF field elements). However having direct access to these tokens would make it easier. I hope you are considering to have a complete range of tokens (especially ID fields of study, event, subject also person ID etc.).
  • agoodwinagoodwin Posts: 131 admin
    via Email
    Hello,
    Thanks for the response. This is the view in Jira for the stories that
    we're going to be working on at first:
    https://jira.openclinica.com/secure/RapidBoard.jspa?rapidView=15&view=planning.nodetail&selectedIssue=OC-5230&versions=visible&selectedEpic=OC-4942

    The tokens for this are:
    StudyName
    Event /Event Ordinal
    CRF
    Item / Item Data
    Study Subject

    You can read more detail in the 'Epic' and individual stories. Do you think
    Person ID would be an important token? Any other feedback is useful as
    well.

    thanks,
    Alicia
  • toskriptoskrip Posts: 279 ✭✭✭
    I consider PersonID to be very important. E.g. in our environment we have another external system which is responsible for subject pseudonymisation (and storage of patient identity data into a separate database). It creates unique pseudonym from patient identifiable data and we use this pseudonym as PersonID during the subject enrolment into a study. Other systems within the environment are also using pseudonym to refer to the patient. So when we would like to open patient record in different system directly from OpenClinica the PersonID is the linking parameter.

    Tomas
  • agoodwinagoodwin Posts: 131 admin
    via Email
    Hi Tomas,

    I've created a story for it here:
    https://jira.openclinica.com/browse/OC-5262
    I added your feedback to the ticket as well. Any other ways you envision
    these tokens could be used?
    I want to be sure we're considering potential future use cases as we are
    starting implementation ...

    Thanks
    Alicia
  • toskriptoskrip Posts: 279 ✭✭✭
    Hi,

    in general I think that it is a good idea to have tokens for IDs, OIDs, unique identifiers. These are informations which enable communication of other systems with OpenClinica.

    Currently I can imagine one more scenario. Lets say that you have external system, which you want to access directly from OC eCRF. Then you want to do something in this external system (calculate something, obtain new value, ...) and you want to save one or more results to eCRF from where you have navigated to the external system. Lets say that you system is configured to work with OC SOAP services. Than in order to import something into eCRF, the system has to call data service and provide ODM formatted data for import. So it will need at least StudyOID, StudyEventDefOID, FormDefOID, ItemGroupDefOID and ItemDefOID. It would be nice if you could sent these info to external system via the parametrised URL.

    Tomas
  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    would it be possible to provide the json/xml clinicaldata tree for the crf
    in the html somewhere (head or something)?

    that already has all relevant info, and I would assume anyone interested in
    building an integration with a param link would be comfortable with
    including some js in the crf to build a link from that data. this is
    possible at the moment except that the input etc. ids are db ids.

    leaving it as a custom solution also means that those inclined can add
    whatever conditions on building that they want.
  • toskriptoskrip Posts: 279 ✭✭✭
    one way of getting json/xml clinical data would be via the new REST URLs in OpenClinica. Basically you can have javascript in CRF which will access to OC REST URL and than parse the result to get whatever you want.

    anyhow, even for invoking REST URL minimum is to have a token for StudyOID and SubjectOID.
This discussion has been closed.