We are currently working on the forum. For the short-term, all forum content will be in read-only format. We apologize for the interruption and look forward to collaborating with you shortly. All the best in your research!
Webservice to retrieve CRF data? (version 3.14)
Hi,
dataWsdl is used to fill in CRF data. Could you please let me know which service is used to retrieve all the CRF data?
I mean just like how the studyWsdl give the Metadata of the study, would like to know the webservice to get all the actual data entered in the CRFs.
Thanks,
Ravi.
0
Comments
for retrieval of clinical data from eCRF in CDISC ODM format you should use so called RESTful URLs, see the documentation here:
http://docs.openclinica.com/3.1/technical-documents/openclinica-restful-urls/restful-url-access-openclinica-metadata-and-print-r
These are REST HTTP requests (simpler then SOAP), but you need to keep in mind that they only work within the session of authenticated user. This basically means that before executing the service to load data you need to programatically login user (POST) to obtain authenticated session and use this obtained session for executing REST (GET) request.
You can check this post where it is discuses how to do int using curl command line utility but in similar manner this can be done in any programming language/toolstack:
https://forums.openclinica.com/discussion/15889/rest-call-to-login-to-openclinica#latest
best
Tomas
GET /rest/clinicaldata/json/view/:study/:subject/:event/:form
http://localhost:8080/OpenClinica/rest/clinicaldata/json/view/MyStudyOID/MySubjectOID/MyEventOID/MyFormOID
Thanks,
Ravi.
I am pretty sure it is not implemented until the "form" lvl. Try to retrieve the whole study subject (this should be supported because casebook feature in GUI is using it):
http://localhost:8080/OpenClinica/rest/clinicaldata/json/view/S_DEFAULTS1/SS_01/*/*
if you get HTML (of login page) back instead of JSON, it means that you did not pass the session properly (your request is considered as not authenticated as you are redirected to login page).
P.S.: authentication (POST) and follow up data request (GET) needs to be done with same tools, you cannot do one with curl and the other one with postman. See the forum post above (I just updated it) there is a protection to prevent OC to have one user logged in simultaneously in multiple browsers.
Tomas
curl: (6) Could not resolve host: d
curl: (6) Could not resolve host: j_username=root
Thanks again Tomas ... is there any REST for filling CRF as well (I have been successful in doing that with SOAP however with the help of Gerben)... if REST is there that's much preferred way !!!
Thanks,
Ravi.
Oh ok ... I have read your PS just now.
From PostMan, I did a POST for http://localhost:8080/OpenClinica/j_spring_security_check
by choosing Authorization type as Basic Auth
I couldn't get the Session ID, what could be the mistake I am doing?
Thanks,
Ravi.
yes that was your error, there is no basic auth for those services. You basically have to emulate the GUI like access to OC and that triggers on server site spring authentication. This normally results to session ID that can be also stored in cookie so that it can be kept on client side and used as authentication token for every following request to OC.
> data import
there have been some changes developed in OC4 but in OC3 community I would stick with SOAP for data import. You will also need the event schedule SOAP service because import is only possible for events that have been previously scheduled (not started events are not eligible for data import) or eventually also SOAP for enrolling patients and listing studies to pickup OIDs. When you are importing complex eCRFs data (containing repeating as well as non repeating item groups) be aware that the order in which item groups are listed in ODM XML for import matters. Maybe write me a message and next week I can give you some hints (I don't have my notes on me right now).
best
Tomas
regarding the order of ItemGroups when importing complex eCRF data (my notes):
- first is the un-grouped (not named) ItemGroup (UNGRUPED keyword in OID)
- then named non-repeating ItemGroup(s)
- then repeating ItemGroup(s) (ordered by repeatKey) with less repeating rows
- then repeating ItemGroup(s) (ordered by repeatKey) with more repeating rows
Note: there is no hard rule that would require this but in my testing I was able to create and import some invalid ODM when not following those rules. This means the data was stored in DB and also visible in audit trail but e.g. was not loadable in eCRF (user interface).
The other advice if you are planning to import a lot of data for many subjects you may want to limit the number of subjects that you put in one ODM file. Personally I usually just include one patient into ODM and trigger the import as many times as many patients I need to import.
best
Tomas