From michael.joseph at sickkids.ca Tue Apr 4 13:31:26 2017 From: michael.joseph at sickkids.ca (Michael Joseph) Date: Tue, 4 Apr 2017 17:31:26 +0000 Subject: [Loris-dev] Project customization and minc insertion Message-ID: Hi LORIS dev community, Our group is interested in using LORIS to store both raw and processed neuroimaging data (ie. image registration). We would also be working solely with minc files. I have a couple questions regarding the project customization steps and minc insertion scripts for this kind of setup. Because we aren't working with dicoms, I'm assuming we'd skip the dicom archiving step (dicomTar.pl). The headers in the minc files are mapped differently compared to dicoms. Would I need to modify the mapDicomParameters function in the NeuroDB::MRI module to account for this? Also, to insert the raw scans, would I use registerFile.pl or minc_insertion.pl? Some of the processed data we would be storing includes nonlinear registration images. In order to insert these into LORIS, would I use register_processed_data.pl? Thanks, Michael ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macfarlane2 at mcgill.ca Tue Apr 4 14:18:40 2017 From: david.macfarlane2 at mcgill.ca (David MacFarlane, Mr) Date: Tue, 4 Apr 2017 18:18:40 +0000 Subject: [Loris-dev] Project customization and minc insertion In-Reply-To: References: Message-ID: hi Michael, Even if you're only working with MINCs, I would still recommend starting from the DICOMs for LORIS in order to have the raw data for provenance. The dicomTar script puts it into a consistent format that the LORIS imaging scripts can process, and the LORIS imaging scripts will automatically convert it to MINC as well performing checks on the protocol, and mapping the scan type of the file to the LORIS mri_scan_types table. The minc_insertion.pl script is what the LORIS tarchive pipeline uses under the hood and would probably be the best place to start if you need to start from the MINCs, but isn't generally intended to be directly run from users, so you'd most likely have to look up how the other scripts are calling it to see how it should be used. ________________________________ From: loris-dev-bounces at bic.mni.mcgill.ca on behalf of Michael Joseph Sent: April 4, 2017 1:31:26 PM To: loris-dev at bic.mni.mcgill.ca Subject: [Loris-dev] Project customization and minc insertion Hi LORIS dev community, Our group is interested in using LORIS to store both raw and processed neuroimaging data (ie. image registration). We would also be working solely with minc files. I have a couple questions regarding the project customization steps and minc insertion scripts for this kind of setup. Because we aren't working with dicoms, I'm assuming we'd skip the dicom archiving step (dicomTar.pl). The headers in the minc files are mapped differently compared to dicoms. Would I need to modify the mapDicomParameters function in the NeuroDB::MRI module to account for this? Also, to insert the raw scans, would I use registerFile.pl or minc_insertion.pl? Some of the processed data we would be storing includes nonlinear registration images. In order to insert these into LORIS, would I use register_processed_data.pl? Thanks, Michael ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanthraov9 at gmail.com Wed Apr 5 06:08:34 2017 From: srikanthraov9 at gmail.com (Sreekanth V) Date: Wed, 5 Apr 2017 15:38:34 +0530 Subject: [Loris-dev] Request In-Reply-To: <5312A01E-FE5A-44D9-8B9C-201694F4513A@mail.mcgill.ca> References: <5312A01E-FE5A-44D9-8B9C-201694F4513A@mail.mcgill.ca> Message-ID: Thanks Jordan, On Tue, Mar 21, 2017 at 11:42 PM, Jordan Stirling, Mr < jordan.stirling at mail.mcgill.ca> wrote: > Hi Srikanth, > > Thanks for you interest in LORIS. Currently at this point in time there is > no development on a mobile application of LORIS, or in the capabilities of > offline data capture. If you were interested in developing a specific > application to be able to capture data offline is two either use native web > technologies such as local storage and app manifest or use our API to be > the bridge between LORIS and a mobile application. Here's a link to our API > documentation (https://github.com/aces/Loris/blob/17.1-dev/docs/API/ > LorisRESTAPI.md). > > As for your second question, I'm not quite sure what you mean. Are you > looking on how to host a LORIS instance online? If that's the case you > could use a service such as Amazon Web Service to host your instance. > > About your last question, are you looking to develop an application for > offline data capture, or for developing for the LORIS code base? If the > latter, I can go into more detail about our github pull request protocol. > > Hope this answers your question, if no feel free to send any follow up > questions you'd like. > > Thanks, > > Jordan > > Sent from my iPhone > > On Mar 17, 2017, at 12:11 PM, Sreekanth V wrote: > > Hi, > > My self srikanth and i am working as Project Lead while going > through some requirement i understand that Loris is suitable for my > requirement but i have some queries can you please help me out. > 1. Is there mobile app development, as per requirement survey is > done in rural areas and data will be stored in offline when he comes to > online it will fetch to server. > 2. How to deploy the web application in the cloud? > 3.can any share how to develop application > > Thanks&Regards, > V.Srikanth, > +91-9962677939. > > _______________________________________________ > Loris-dev mailing list > Loris-dev at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukhan at ualberta.ca Tue Apr 11 16:03:56 2017 From: mukhan at ualberta.ca (Muhammad Khan) Date: Tue, 11 Apr 2017 14:03:56 -0600 Subject: [Loris-dev] Behavioral Database Workflow Message-ID: Hi LORIS dev community, I had a couple of questions regarding the behavioral database: i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I go about utilizing this feature? ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that is displayed in the *My Tasks panel* only considers an incomplete form if it is 'In Progress'. If a visit stage is started, the instruments that are populated are not considered to be 'In Progress' until they are opened. So the number displayed on the dashboard excludes unopened instruments. However, in the Data Team Helper module, and the Statistics page, an unopened instrument is considered to be incomplete. Would it not be more appropriate to have the number of *Incomplete Forms* reflect both unopened, and 'In Progress' forms to keep it consistent with the other modules? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukhan at ualberta.ca Tue Apr 11 16:08:50 2017 From: mukhan at ualberta.ca (Muhammad Khan) Date: Tue, 11 Apr 2017 14:08:50 -0600 Subject: [Loris-dev] Behavioral Database Workflow In-Reply-To: References: Message-ID: Hi again, Sorry, I forgot to include this in my previous email: iii.) After a visit has been sent to DCC for approval, is there a way for the study coordinator (admin) to be notified that that visit needs to be verified and approved? Thanks! Muhammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.joseph at sickkids.ca Wed Apr 19 16:03:01 2017 From: michael.joseph at sickkids.ca (Michael Joseph) Date: Wed, 19 Apr 2017 20:03:01 +0000 Subject: [Loris-dev] Create DCCID and Organizing CIVET outputs Message-ID: Hi Loris dev community, I have 2 questions: 1) Is there a way to register new candidates into Loris from the back-end without a DCCID? Essentially, I'd like to add candidates and sessions while running the tarchiveLoader script. I noticed that the prod file has a createCandidates variable. Is there anything else that needs to be modified? 2) How are CIVET outputs typically organized in Loris? I noticed that in the mri_scan_type table, there are labels like "white_matter", "pve", "tal_msk". I'm assuming the most of the files from CIVET would get registered using these labels. Also, is there a good way of linking to the htmls from the CIVET QC pipeline? Thanks, Michael ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukhan at ualberta.ca Wed Apr 19 18:58:55 2017 From: mukhan at ualberta.ca (Muhammad Khan) Date: Wed, 19 Apr 2017 16:58:55 -0600 Subject: [Loris-dev] Behavioural Statistics Message-ID: Hi, I have created a few users for the sites involved with our study with the Data Entry permission. This enables them to view the statistics module. However, when they click on the Behavioural Statistics tab, and look at the "Per Instrument Stats" for any site, users can view incomplete forms from other sites (although they cannot edit them), even though they do not have the 'access_all_profiles' permission. So if an instrument hasn't been flagged as 'Complete', but data has been entered, users from other sites are able to access that information through the Statistics module. Is it possible to prevent users from viewing the instruments of candidates that belong to other sites, unless they have the 'access_all_profiles' permission ? Thanks, Muhammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From waveflux at gmail.com Fri Apr 21 15:40:36 2017 From: waveflux at gmail.com (Tom Beaudry) Date: Fri, 21 Apr 2017 15:40:36 -0400 Subject: [Loris-dev] simplexml error Message-ID: Hi Everyone, I am installing LORIS on a new VM that i got yesterday and I have run into the following error in my apache log when trying to load main.php: [Fri Apr 21 14:53:10.572880 2017] [:error] [pid 21258] [client 10.210.128.16:52788] PHP Warning: simplexml_load_file(): I/O warning : failed to load external entity "" in /var/www/loris/php/libraries/NDB_Config.class.inc on line 108 [Fri Apr 21 14:53:10.572949 2017] [:error] [pid 21258] [client 10.210.128.16:52788] PHP Fatal error: Uncaught Exception: Could not load Loris config file in /var/www/loris/php/libraries/NDB_Config.class.inc:111\nStack trace:\n#0 /var/www/loris/php/libraries/NDB_Config.class.inc(92): NDB_Config->load(NULL)\n#1 /var/www/loris/php/libraries/NDB_Factory.class.inc(118): NDB_Config::singleton(NULL)\n#2 /var/www/loris/php/libraries/NDB_Client.class.inc(54): NDB_Factory->config(NULL)\n#3 /var/www/loris/htdocs/main.php(29): NDB_Client->initialize()\n#4 {main}\n thrown in /var/www/loris/php/libraries/NDB_Config.class.inc on line 111 Has anyone one come across this before? Thanks! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.rogers at mcgill.ca Wed Apr 26 18:28:16 2017 From: christine.rogers at mcgill.ca (Christine Rogers) Date: Wed, 26 Apr 2017 18:28:16 -0400 Subject: [Loris-dev] Behavioural Statistics In-Reply-To: References: Message-ID: Hi Muhammad, the Behavioural Statistics tab, and look at the "Per Instrument Stats" for > any site, users can view incomplete forms from other sites (although they > cannot edit them), even though they do not have the 'access_all_profiles' > permission. So if an instrument hasn't been flagged as 'Complete', but data > has been entered, users from other sites are able to access that > information through the Statistics module. Thanks for reporting this issue to us. I've logged it in our GitHub Issues page, the team will discuss and address. (The solution should be to apply/verify against access_all_sites permission before retrieving/displaying/linking other sites' data for this page.) Christine On Wed, Apr 19, 2017 at 6:58 PM, Muhammad Khan wrote: > Hi, > > I have created a few users for the sites involved with our study with the > Data Entry permission. This enables them to view the statistics module. > However, when they click on the Behavioural Statistics tab, and look at the > "Per Instrument Stats" for any site, users can view incomplete forms from > other sites (although they cannot edit them), even though they do not have > the 'access_all_profiles' permission. So if an instrument hasn't been > flagged as 'Complete', but data has been entered, users from other sites > are able to access that information through the Statistics module. > > Is it possible to prevent users from viewing the instruments of candidates > that belong to other sites, unless they have the 'access_all_profiles' > permission ? > > Thanks, > Muhammad > > > > > -- christine.rogers at mcgill.ca LORIS data systems | loris.ca McGill Centre for Integrative Neuroscience | MCIN.ca McConnell Brain Imaging Centre Montreal Neurological Institute McGill University | Montreal | Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.rogers at mcgill.ca Wed Apr 26 18:33:56 2017 From: christine.rogers at mcgill.ca (Christine Rogers) Date: Wed, 26 Apr 2017 18:33:56 -0400 Subject: [Loris-dev] Behavioral Database Workflow In-Reply-To: References: Message-ID: HI Muhammed, Thanks for your questions; we'll log these as issues/requests for discussion with the team. i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I go > about utilizing this feature? BVL QC and BVL Exclusion are columns that appear in the Timepoint List page, drawn by the Timepoint class from columns in the session table . *BVL QC* can be set for a given timepoint by clicking on the timepoint in the table, and in the control panel (left sidebar) selecting Visual or Hardcopy under "BVL QC Type", and then selecting "Complete" under "BVL QC Status". Projects can use this to mark if/when all completed instruments for a visit have been inspected against paper originals (hardcopy), or against digital or scoring sources ('visual'). Once both these flags are set within the timepoint, you should see the value (visual or hardcopy) in the Timepoint List table, BVL QC column. *BVL Exclusion* can be used by custom code or scripts to flag excluded datasets (e.g. due to candidate disqualification or data quality insufficiency etc), but is not currently set via Loris' front end. ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that > is displayed in the *My Tasks panel* only considers an incomplete form if > it is 'In Progress'. If a visit stage is started, the instruments that are > populated are not considered to be 'In Progress' until they are opened. So > the number displayed on the dashboard excludes unopened instruments. > However, in the Data Team Helper module, and the Statistics page, an > unopened instrument is considered to be incomplete. Would it not be more > appropriate to have the number of *Incomplete Forms* reflect both > unopened, and 'In Progress' forms to keep it consistent with the other > modules? Thanks for reporting this -- this count should be consistent across modules and should include unopened as well as In Progress. iii.) After a visit has been sent to DCC for approval, is there a way for > the study coordinator (admin) to be notified that that visit needs to be > verified and approved? This notification would be a good feature to add, and could also appear as a notification on the dashboard upon login, e.g. configurable for the site coordinator and visible only for their site visits. Best, Christine On Tue, Apr 11, 2017 at 4:03 PM, Muhammad Khan wrote: > Hi LORIS dev community, > > I had a couple of questions regarding the behavioral database: > > i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I > go about utilizing this feature? > > ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that > is displayed in the *My Tasks panel* only considers an incomplete form if > it is 'In Progress'. If a visit stage is started, the instruments that are > populated are not considered to be 'In Progress' until they are opened. So > the number displayed on the dashboard excludes unopened instruments. > However, in the Data Team Helper module, and the Statistics page, an > unopened instrument is considered to be incomplete. Would it not be more > appropriate to have the number of *Incomplete Forms* reflect both > unopened, and 'In Progress' forms to keep it consistent with the other > modules? > > > > > > _______________________________________________ > Loris-dev mailing list > Loris-dev at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev > > -- christine.rogers at mcgill.ca LORIS data systems | loris.ca McGill Centre for Integrative Neuroscience | MCIN.ca McConnell Brain Imaging Centre Montreal Neurological Institute McGill University | Montreal | Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukhan at ualberta.ca Wed Apr 26 19:03:06 2017 From: mukhan at ualberta.ca (Muhammad Khan) Date: Wed, 26 Apr 2017 17:03:06 -0600 Subject: [Loris-dev] Behavioral Database Workflow In-Reply-To: References: Message-ID: Hey Christine, Thanks for clarifying the BVL QC columns. To fix the issue of users being able to access instruments through the statistics module, even though they do not have the access_all_profiles permission, I copied the following hasAccess function into all the instruments that I had coded: function _hasAccess() > { > // create user object > $user =& User::singleton(); > $timePoint =& TimePoint::singleton($_REQUEST['sessionID']); > $candID = $timePoint->getCandID(); > $candidate =& Candidate::singleton($candID); > // check user permissions > return ($user->hasPermission('access_all_profiles') || > $user->getData('CenterID') == $candidate->getData('CenterID') || > $user->getData('CenterID') == $timePoint->getData('CenterID')); > } If the user does not have the access_all_profiles permission and they do not belong to the participant's center, then they will see the "You do not have access to this page" error. On Wed, Apr 26, 2017 at 4:33 PM, Christine Rogers < christine.rogers at mcgill.ca> wrote: > HI Muhammed, > Thanks for your questions; we'll log these as issues/requests for > discussion with the team. > > i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I >> go about utilizing this feature? > > > BVL QC and BVL Exclusion are columns that appear in the Timepoint List > page, drawn by the Timepoint class from columns in the session table > . > > > *BVL QC* can be set for a given timepoint by clicking on the timepoint in > the table, and in the control panel (left sidebar) selecting Visual or > Hardcopy under "BVL QC Type", and then selecting "Complete" under "BVL QC > Status". > Projects can use this to mark if/when all completed instruments for a > visit have been inspected against paper originals (hardcopy), or against > digital or scoring sources ('visual'). > Once both these flags are set within the timepoint, you should see the > value (visual or hardcopy) in the Timepoint List table, BVL QC column. > *BVL Exclusion* can be used by custom code or scripts to flag excluded > datasets (e.g. due to candidate disqualification or data quality > insufficiency etc), but is not currently set via Loris' front end. > > ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that >> is displayed in the *My Tasks panel* only considers an incomplete form >> if it is 'In Progress'. If a visit stage is started, the instruments that >> are populated are not considered to be 'In Progress' until they are opened. >> So the number displayed on the dashboard excludes unopened instruments. >> However, in the Data Team Helper module, and the Statistics page, an >> unopened instrument is considered to be incomplete. Would it not be more >> appropriate to have the number of *Incomplete Forms* reflect both >> unopened, and 'In Progress' forms to keep it consistent with the other >> modules? > > > Thanks for reporting this -- this count should be consistent across > modules and should include unopened as well as In Progress. > > iii.) After a visit has been sent to DCC for approval, is there a way for >> the study coordinator (admin) to be notified that that visit needs to be >> verified and approved? > > > This notification would be a good feature to add, and could also appear as > a notification on the dashboard upon login, e.g. configurable for the site > coordinator and visible only for their site visits. > > Best, > Christine > > > On Tue, Apr 11, 2017 at 4:03 PM, Muhammad Khan wrote: > >> Hi LORIS dev community, >> >> I had a couple of questions regarding the behavioral database: >> >> i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I >> go about utilizing this feature? >> >> ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that >> is displayed in the *My Tasks panel* only considers an incomplete form >> if it is 'In Progress'. If a visit stage is started, the instruments that >> are populated are not considered to be 'In Progress' until they are opened. >> So the number displayed on the dashboard excludes unopened instruments. >> However, in the Data Team Helper module, and the Statistics page, an >> unopened instrument is considered to be incomplete. Would it not be more >> appropriate to have the number of *Incomplete Forms* reflect both >> unopened, and 'In Progress' forms to keep it consistent with the other >> modules? >> >> >> >> >> >> _______________________________________________ >> Loris-dev mailing list >> Loris-dev at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev >> >> > > > -- > > christine.rogers at mcgill.ca > LORIS data systems | loris.ca > McGill Centre for Integrative Neuroscience | MCIN.ca > McConnell Brain Imaging Centre > Montreal Neurological Institute > McGill University | Montreal | Canada > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.rogers at mcgill.ca Thu Apr 27 12:36:15 2017 From: christine.rogers at mcgill.ca (Christine Rogers) Date: Thu, 27 Apr 2017 12:36:15 -0400 Subject: [Loris-dev] Behavioral Database Workflow In-Reply-To: References: Message-ID: Hi Muhammad, Thanks for posting this solution for checking permissions on instruments. We'll look into it and should issue a pull request soon. Best, Christine On Wed, Apr 26, 2017 at 7:03 PM, Muhammad Khan wrote: > > Hey Christine, > > Thanks for clarifying the BVL QC columns. > To fix the issue of users being able to access instruments through the > statistics module, even though they do not have the access_all_profiles > permission, I copied the following hasAccess function into all the > instruments that I had coded: > > function _hasAccess() >> { >> // create user object >> $user =& User::singleton(); >> $timePoint =& TimePoint::singleton($_REQUEST['sessionID']); >> $candID = $timePoint->getCandID(); >> $candidate =& Candidate::singleton($candID); >> // check user permissions >> return ($user->hasPermission('access_all_profiles') || >> $user->getData('CenterID') == $candidate->getData('CenterID') || >> $user->getData('CenterID') == $timePoint->getData('CenterID')); >> } > > > If the user does not have the access_all_profiles permission and they do > not belong to the participant's center, then they will see the "You do not > have access to this page" error. > > On Wed, Apr 26, 2017 at 4:33 PM, Christine Rogers < > christine.rogers at mcgill.ca> wrote: > >> HI Muhammed, >> Thanks for your questions; we'll log these as issues/requests for >> discussion with the team. >> >> i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I >>> go about utilizing this feature? >> >> >> BVL QC and BVL Exclusion are columns that appear in the Timepoint List >> page, drawn by the Timepoint class from columns in the session table >> . >> >> >> *BVL QC* can be set for a given timepoint by clicking on the timepoint >> in the table, and in the control panel (left sidebar) selecting Visual or >> Hardcopy under "BVL QC Type", and then selecting "Complete" under "BVL QC >> Status". >> Projects can use this to mark if/when all completed instruments for a >> visit have been inspected against paper originals (hardcopy), or against >> digital or scoring sources ('visual'). >> Once both these flags are set within the timepoint, you should see the >> value (visual or hardcopy) in the Timepoint List table, BVL QC column. >> *BVL Exclusion* can be used by custom code or scripts to flag excluded >> datasets (e.g. due to candidate disqualification or data quality >> insufficiency etc), but is not currently set via Loris' front end. >> >> ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that >>> is displayed in the *My Tasks panel* only considers an incomplete form >>> if it is 'In Progress'. If a visit stage is started, the instruments that >>> are populated are not considered to be 'In Progress' until they are opened. >>> So the number displayed on the dashboard excludes unopened instruments. >>> However, in the Data Team Helper module, and the Statistics page, an >>> unopened instrument is considered to be incomplete. Would it not be more >>> appropriate to have the number of *Incomplete Forms* reflect both >>> unopened, and 'In Progress' forms to keep it consistent with the other >>> modules? >> >> >> Thanks for reporting this -- this count should be consistent across >> modules and should include unopened as well as In Progress. >> >> iii.) After a visit has been sent to DCC for approval, is there a way for >>> the study coordinator (admin) to be notified that that visit needs to be >>> verified and approved? >> >> >> This notification would be a good feature to add, and could also appear >> as a notification on the dashboard upon login, e.g. configurable for the >> site coordinator and visible only for their site visits. >> >> Best, >> Christine >> >> >> On Tue, Apr 11, 2017 at 4:03 PM, Muhammad Khan >> wrote: >> >>> Hi LORIS dev community, >>> >>> I had a couple of questions regarding the behavioral database: >>> >>> i.) What is the purpose of the *BVL QC *& *BVL Exclusion*, and how do I >>> go about utilizing this feature? >>> >>> ii.) On the dashboard, I noticed that the number of *Incomplete Forms *that >>> is displayed in the *My Tasks panel* only considers an incomplete form >>> if it is 'In Progress'. If a visit stage is started, the instruments that >>> are populated are not considered to be 'In Progress' until they are opened. >>> So the number displayed on the dashboard excludes unopened instruments. >>> However, in the Data Team Helper module, and the Statistics page, an >>> unopened instrument is considered to be incomplete. Would it not be more >>> appropriate to have the number of *Incomplete Forms* reflect both >>> unopened, and 'In Progress' forms to keep it consistent with the other >>> modules? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Loris-dev mailing list >>> Loris-dev at bic.mni.mcgill.ca >>> http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev >>> >>> >> >> >> -- >> >> christine.rogers at mcgill.ca >> LORIS data systems | loris.ca >> McGill Centre for Integrative Neuroscience | MCIN.ca >> McConnell Brain Imaging Centre >> Montreal Neurological Institute >> McGill University | Montreal | Canada >> > > > _______________________________________________ > Loris-dev mailing list > Loris-dev at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev > > -- christine.rogers at mcgill.ca LORIS data systems | loris.ca McGill Centre for Integrative Neuroscience | MCIN.ca McConnell Brain Imaging Centre Montreal Neurological Institute McGill University | Montreal | Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From mouna.safi-harb at mail.mcgill.ca Thu Apr 27 14:06:58 2017 From: mouna.safi-harb at mail.mcgill.ca (Mouna Safi-Harab) Date: Thu, 27 Apr 2017 18:06:58 +0000 Subject: [Loris-dev] Create DCCID and Organizing CIVET outputs In-Reply-To: References: Message-ID: Hi Michael, Here are my answers to your questions: 1) Setting createCandidates to 1 in the prod file does indeed allow for creation of the candidate from the MRI pipeline. You will need to make sure that 1) the PatientName header is anonymized properly in the DICOM files, and 2) getSubjectIDs() function in this prod file is a) splitting the PatientName header information in a way that is consistent with the anonymization and your project DCCID/PSCID/VisitLabel convention, and b) has the $subjectID{'createVisitLabel'} option set to 1 as you will also likely need the MRI pipeline to create the visit for that candidate as well. However, projects using the Imaging Uploader GUI unfortunately does not allow for this option. If you want a way to make it work for now, you can disable the check on Lines 378-395 in NDB_Menu_Filter_imaging_uploader.class.inc (which sole purpose is to check if the CandID is registered in the database). We can look at this from our end, and make sure the option createCandidate is propagated to the Imaging Uploader GUI as well in a seamless manner to the user (will discuss this at our internal meeting). 2) Loris-MRI codebase provides an example of how to insert files from another processing pipeline into the database. Check the DTIPrep/ directory for an example you can follow. Essentially, inserting processed files into LORIS is a two-step process: you will need a 1) wrapper script that "understands" or "knows" how/where the processed files are stored (this step is processing pipeline dependent), and then 2) have that wrapper script call a generic file called uploadNeuroDB/register_processed_data.pl. The register_processed_data.pl file would take in many required arguments, some of which are the full path of the file you are going to register. Other parameters are the acquisition protocol ID. So yes, the"white_matter", "pve", "tal_mask" were initially created to allow for CIVET outputs to be registered with the correct acquisition protocol. Other required parameters are the sourceFileID which would be the ID of the initial file you sent to CIVET for processing. The second step should be processing pipeline independent. I hope the above answers your questions, or at least, gives you a starting point. - Mouna ________________________________ From: loris-dev-bounces at bic.mni.mcgill.ca on behalf of Michael Joseph Sent: Wednesday, April 19, 2017 4:03 PM To: loris-dev at bic.mni.mcgill.ca Subject: [Loris-dev] Create DCCID and Organizing CIVET outputs Hi Loris dev community, I have 2 questions: 1) Is there a way to register new candidates into Loris from the back-end without a DCCID? Essentially, I'd like to add candidates and sessions while running the tarchiveLoader script. I noticed that the prod file has a createCandidates variable. Is there anything else that needs to be modified? 2) How are CIVET outputs typically organized in Loris? I noticed that in the mri_scan_type table, there are labels like "white_matter", "pve", "tal_msk". I'm assuming the most of the files from CIVET would get registered using these labels. Also, is there a good way of linking to the htmls from the CIVET QC pipeline? Thanks, Michael ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.joseph at sickkids.ca Fri Apr 28 12:49:50 2017 From: michael.joseph at sickkids.ca (Michael Joseph) Date: Fri, 28 Apr 2017 16:49:50 +0000 Subject: [Loris-dev] Create DCCID and Organizing CIVET outputs In-Reply-To: References: , Message-ID: Hi Mouna, Thank you for your reply. Your answers certainly help. For our images, the PatientName header is labeled as PSCID-VisitLabel. I've modified the regex in the prod file to parse this out. I didn't want to modify the header to also include a DCCID because there are other groups sharing the images. I was wondering if there's another way to create a DCCID when images are uploaded (similar to how the scanner is registered). The Imaging Uploader GUI isn't as important to us as we'll be relying on the Perl scripts to upload all our images. Thank you for directing me to the DTIPrep directory. It definitely helps as an example for registering processed data. Michael ________________________________ From: Mouna Safi-Harab Sent: April 27, 2017 2:06:58 PM To: Michael Joseph; loris-dev at bic.mni.mcgill.ca Subject: Re: Create DCCID and Organizing CIVET outputs Hi Michael, Here are my answers to your questions: 1) Setting createCandidates to 1 in the prod file does indeed allow for creation of the candidate from the MRI pipeline. You will need to make sure that 1) the PatientName header is anonymized properly in the DICOM files, and 2) getSubjectIDs() function in this prod file is a) splitting the PatientName header information in a way that is consistent with the anonymization and your project DCCID/PSCID/VisitLabel convention, and b) has the $subjectID{'createVisitLabel'} option set to 1 as you will also likely need the MRI pipeline to create the visit for that candidate as well. However, projects using the Imaging Uploader GUI unfortunately does not allow for this option. If you want a way to make it work for now, you can disable the check on Lines 378-395 in NDB_Menu_Filter_imaging_uploader.class.inc (which sole purpose is to check if the CandID is registered in the database). We can look at this from our end, and make sure the option createCandidate is propagated to the Imaging Uploader GUI as well in a seamless manner to the user (will discuss this at our internal meeting). 2) Loris-MRI codebase provides an example of how to insert files from another processing pipeline into the database. Check the DTIPrep/ directory for an example you can follow. Essentially, inserting processed files into LORIS is a two-step process: you will need a 1) wrapper script that "understands" or "knows" how/where the processed files are stored (this step is processing pipeline dependent), and then 2) have that wrapper script call a generic file called uploadNeuroDB/register_processed_data.pl. The register_processed_data.pl file would take in many required arguments, some of which are the full path of the file you are going to register. Other parameters are the acquisition protocol ID. So yes, the"white_matter", "pve", "tal_mask" were initially created to allow for CIVET outputs to be registered with the correct acquisition protocol. Other required parameters are the sourceFileID which would be the ID of the initial file you sent to CIVET for processing. The second step should be processing pipeline independent. I hope the above answers your questions, or at least, gives you a starting point. - Mouna ________________________________ From: loris-dev-bounces at bic.mni.mcgill.ca on behalf of Michael Joseph Sent: Wednesday, April 19, 2017 4:03 PM To: loris-dev at bic.mni.mcgill.ca Subject: [Loris-dev] Create DCCID and Organizing CIVET outputs Hi Loris dev community, I have 2 questions: 1) Is there a way to register new candidates into Loris from the back-end without a DCCID? Essentially, I'd like to add candidates and sessions while running the tarchiveLoader script. I noticed that the prod file has a createCandidates variable. Is there anything else that needs to be modified? 2) How are CIVET outputs typically organized in Loris? I noticed that in the mri_scan_type table, there are labels like "white_matter", "pve", "tal_msk". I'm assuming the most of the files from CIVET would get registered using these labels. Also, is there a good way of linking to the htmls from the CIVET QC pipeline? Thanks, Michael ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: