CDIbase Docs

CDIbase runs almost anywhere Python web applications go. However, deploying a web application requires some technical sophistication. Not comfortable setting up CDIbase yourself? Contact us and we may be able to help!

Anyway, the hardest parts of getting CDIbase setup are often regulatory and not technical. So, please check security, privacy, ethical, and related standards for your appropriate regulatory bodies as CDIbase cannot guarantee compliance with IRB and other institutional standards given the specifics of individual studies. Still, this guide can offer best practices and initial guidance given lessons from past installations of CDIbase.

• Know some key points of institutional policy

  While many institutions will not provide guidance or policies for most or all of these points, this guide suggests checking if your research institution has:

  • Policies regarding electronic storage and web applications for private / confidential data.
  • Policies regarding the use of cloud services for research data.
  • Policies regarding encryption of "at rest" data.
  • Policies regarding encryption of "in motion" data.
  • In deciding where to host the application, we suggest checking for
    • Existing services provided by your institution for hosting Python web applications.
    • Policies for purchasing external domains or obtaining sub-domains / URLs under your institution's own domain name.
    • Policies for obtaining externally accessible (public Internet facing) IP addresses / URLs.
    • Policies for self-hosting email servers or obtaining access to your institution's existing SMTP services. CDIbase only requires access to outbound mail services without attachments.
    • Policies around and availability of security auditing.
    • Policies around and availability of SSL certificates issued through your institution.

• Pip and Python

  Even if using a cloud service, download a recent copy of Pip and Python. It makes the rest of this easier.

  • Guide for Linux
  • Guide for Mac OS X

• Option 1: Cloud services

  Due to regulatory, privacy, and ethical obligations, many institutions and regulatory bodies require self-hosting of research data. However, for lucky labs whose policies allow for safe use of cloud services, this guide advises against self-hosting for increased security, redundancy, convenience, and cost-effectiveness. For those electing to use cloud services:

  • Grab a copy of CDIbase by following the environment setup instructions in the project README.
  • Choose a cloud service and deploy...
    • This guide strongly suggests Heroku (deploying Python apps on Heroku).
    • Amazon's Elastic Beanstalk makes a good second (suggested guide for deploying Python apps to Elastic Beanstalk).
    • PythonAnywhere, Microsoft Azure (Azure Python Docs or unofficial Python azure guide), and App Fog (App Fog Docs) would likely work well too.
    • Individual labs need to make some modifications to the code if choosing to use Google App Engine. Let us know and we will try our best to help you make that migration.
  • Future plans for the project aim to make this easier but, if not using SQLite, switch the DB adapter in prog_code/util/db_util.py. Use any DB API 2.0 compliant adapter like psycopg for PostgreSQL. Sorry... this inconvenience arose due to historical reasons and at rest data security considerations (see Securing Data at Rest).
  • Get access to an outbound SMTP server. Many unrelated commercial solutions exist like Mandrill and SendGrid. Make sure to update flask_config.cfg.
  
  

  Note that the application does need to take file uploads. If you are looking to use S3 or blobstore, let us know and we can provide an adapter. We hope to have that rolled into the regular CDIbase release early 2015.

  
  
• Option 2: Self-hosting

  Previous successful deployments have favored the nginx engine on a *nix system (just use Mac or Linux) with Gunicorn and Supervisor.

  • Some universities offer internal web application hosting services that automate the following steps. Check with your IT department.
  • Get a server set up. This one is all up to you but, if lacking initial direction, this guide suggests Ubuntu.
  • Get a copy of CDIbase by following the environment setup instructions in the project README.
  • Set up an HTTP server. This guide strongly suggests nginx, Gunicorn, and Supervisor but Apache with mod_python / mod_wsgi could also work. If electing for nginx, check out some helpful external guides to get a good start:
    • Relevant guide for Debian derivatives (like Ubuntu). Make sure to follow instructions in all three blog posts.
    • Relevant guide for Red Hat Linux derivatives (CentOS, Fedora). Note that CDIbase uses Flask not Django
    • Relevant guides for Mac OS X servers
      • nginx on Mavericks
      • Gunicorn official docs
      • Guide for Supervisor
    • Get a web address. Some universities provide subdomains for free internally. Check with your IT department.
    • Some institutions have restrictions on externally accessible IP addresses. To access CDIbase outside of your institution's internal intranet / VPN, you may need to consult with your IT department. This is also necessary for collecting CDI forms from parents online.
    • Get access to an outbound SMTP server. Some institutions allow self hosting of local mail servers while others require coordination with an IT department. Either way, make sure to update flask_config.cfg.
      • Local mail server instructions for Ubuntu and most Debian derivatives.
      • Local mail server instructions for CentOS and most Red Hat derivatives.
      • Postfix instructions for Mac OS X
  • For historical reasons and concerns about securing data at rest, the application uses SQLite by default. Future high priority plans for the project aim to make this easier but, if not using SQLite, switch the DB adapter in prog_code/util/db_util.py. Any DB API 2.0 compliant adapter like psycopg for PostgreSQL will work.
  • Some institutions will suggest security audits and environment harding through iptables or equivalent. If running multiple applications on the same server or other environments where resources on the same machine could be compromising, chrooting may also help. Finally, CDIbase does not have integrated functionality for data backup. Depending on your database, the appropriate back up techniques will vary. For low traffic deployments with SQLite, this could simply be a nightly snapshot.
  
  

  Note that the application does need to take file uploads containing non-sensitive configuration data. Please be sure to set the permissions on the uploads directory accordingly or let us know if you would like to target S3 or blobstore and we can provide an adapter. We hope to have that adapter rolled into the regular CDIbase release early 2015.

  
  
• Security / Regulation: Securing Data in Motion (SSL Certs)

  Some institutions and regulatory bodies may require encrypting data in motion (moving between server and users' computers). Regardless, as an ethical and security obligation, this guide very strongly suggests installing SSL certificates and encrypting data moving between sever and users using TLS. If labs have encryption requirements for data in motion, this may likely satisfy their responsibilities. However, this guide / project cannot guarantee compliance. Anyway...

  • If using Heroku, Elastic Beanstalk, and most other cloud providers, check if the URL for your application has https:// in front and, if not, try accessing your application simply by switching http for https. If your application loads without warnings, your cloud provider provides this encryption for you. If not, please consult their documentation for SSL certificates.
  • If self-hosting...
    • Some institutions have SSL certificates installed by default (particularly if using an internally provided hosting solution). Try putting https:// instead of http:// at the front of the address of your application. If the website loads without error / warning, your institution already encrypts your data in motion.
    • Obtain an SSL certificate. Many university IT departments will give these out for applications on their own domain. However, private companies also sell them.
    • Install the SSL certificate. These external guides can help most users but the entire process though a small number of installations / certificates may require additional steps...
      • Nginx guide
      • Apache guide
• Security / Regulation: Securing Data at Rest

  Some institutions and regulatory bodies may require encrypting data at rest (data while on the server or cached on the client). Labs may need additional security affordances depending on the specifics of the corresponding policies but this guide suggests sqlcipher as a possible transparent method for encrypting data server-side. If using SQLite, maybe consider using the DB API 2.0-compliant pysqlcipher. Regardless, labs can integrate pysqlchipher or alternative DB API 2.0-compliant database drivers by modifying the DB adapter in prog_code/util/db_util.py

• Some encouragement and a brief disclaimer

  Privacy and security standards exist to protect institutions, researchers, and study participants. These important standards and regulations take some time to manage but, historically, CDIbase has enjoyed excellent case studies of increasing productivity / efficiency and decreasing costs for its users after deployment. So, in our biased opinion, we believe in the benefits resulting from overcoming those upfront regulatory hurdles. :) Again, in case of trouble, contact us and we might be able to help.

  With that, now for our obligatory disclaimer... This guide and CDIbase's larger community cannot provide legal advice and labs must ultimately make their own technical decisions for which this community / guide / project cannot be held responsible. As modern application hosting and research standards just involve too many variables, this purely informational documentation serves only as an initial reference guide for the community. Moreover, in linking to multiple external resources, this guide / community / project cannot guarantee or be held responsible for that external content in its current or future iterations. Finally, this guide emphasizes that individual labs must decide hosting strategies for themselves within their regulatory obligations and this guide only offers initial direction.

CDIbase uses a SQLite database by default though labs can use any DB API 2.0 compliant adapter like psycopg for PostgreSQL.

• Suggested tools

  Obviously familiarity with Python or a similar language can help clean up and transform data. However, we also suggest...

  • OpenRefine can help with manipulating existing CSV and similar existing CDI records.
  • SQLite Studio can help manage SQLite databases.
  • SQLite has built-in CSV import capabilities.
  • LibreOffice or Microsoft Excel can help with the less heavy data lifting, particularly if existing CDI records are in CSV file or spreadsheets.

  Disclaimer: This project and its developers are not responsible for these third party tools.

• Create a new database

  If not done already, create a new database for CDIbase. Using the default engine (SQLite) haven't created the database yet?

  $ cd db
  $ sqlite3 daxlab.db < create_local_db.sql
• Gathering all the required data

  In addition to whether a word was said / signed / known (depending on study) or not, each CDI response should have the following:

  • The lab-wide integer ID for the child.
  • The ID for the child within the study. May be text and may optionally be the same as the lab-wide ID.
  • The name of the study the CDI was part of.
  • The type of CDI used (MacAurthur-Bates, CU Bilingual, etc.).
  • The birthday of the research participant the CDI is for.
  • The date the CDI was taken.
  • The number of prior CDIs for the research participant within the study.
  • The total number of CDIs the research participant is expected to complete within the study.
  • The number of words on the CDI marked as known / said / signed.
  • The gender of the research participant.
  • The age in months of the research participant at the time the CDI was taken.
  • The percentile of the participant given the number of items on the CDI that the participant was reported to have said / signed / known.
  • (optional) The languages the participant reportedly knows for the purposes of the study. Ex: a participant may know both English and Spanish.
  • (optional) The number of languages the participant reportedly knows for the purposes of the study.
  • (optional) Number of extra CDI categories added. If no items were added to the CDI, use 0.
  • (optional) The number of items on the CDI that where not asked of the participant. If all words on the CDI were asked (the full CDI was provided), use 0.
  • (optional) If the research participant is hard of hearing.
• Converting to CDIbase values

  By default, CDIbase uses the following values for CDI responses. Remember, individual researchers can use presentation formats to convert these encodings. So, true needs to be 1 for CDIbase but a researcher could ask CDIbase to generate a CSV with "t" for true instead.

  • True / Yes: 1
  • False / No: 0
  • Male / Boy / Man: 1
  • Female / Girl / Woman: 2
  • Other gender / unisex: 3
  • Dates should be in the format YYYY/MM/DD. Note that all months and days should have two digits zero padded (February 3 => 02/03)
  • Any integer values can be used to report a word as said / signed / known or not said / not signed / not known. It must simply correspond to the values specified in the CDI specification.

  Most labs will not need to use any additional or alternate encodings but, for integrating with other software, the other available encoding values are listed in the Understanding encoding values section.

• Should you use non-standard encodings in the database?

  Don't want to use 1 for male, 2 for female, and 3 for other gender? CDIbase can do that.

  In transitioning to CDIbase, a very tiny number of labs may have a more complex data migration process and will want to have CDIbase use non-standard values for encoding said, not said, true, false, male, female, etc. Unless labs know they require non-standard encoding values (because of a shared SQL database, dataset inconsistencies, etc.), this guide suggests against configuring them. That being said, labs electing for non-standard encoding values should read the understanding encoding values section. Still, remember that individual researchers can use presentation formats to convert these encodings. So, if using the default CDIbase encodings where true needs to be 1, a researcher could still ask CDIbase to generate a CSV with "t" for true instead to integrate with this software / preferences.

• Importing data into the database

  After transforming existing lab data to use the above values or the non-standard encodings custom configured, either write a script to read old lab data into the new database or, if using a SQLite database but missing programming skill, prepare the lab data as a series of CSV files and use SQLite's built in CSV import functionality. Refer to database schema below for additional guidance.

• Specifying CDI formats

  Enter the CDIs in use by your lab. See the non-technical tutorials for more information.

• Specifying presentation formats

  Enter at least a "standard" presentation format. See the non-technical tutorials for more information.

Complete information about database tables and relationships. Note that data migration only needs to manually fill the snapshot_content and snapshots tables.

• Quick vocabulary note

  To disambiguate some concepts, the database uses the following vocabulary:

  • A "CDI" / "CDI format" refers to the properties of and items on the CDI completed by participants.
  • A "snapshot" refers to a single completed CDI.

• Table: snapshots

  Information about a snapshot (completed CDI). Columns include:

  • [Integer] child_id: The lab-wide unique integer ID of the research participant this CDI snapshot is for.
  • [String] study_id: The ID for the child within the study. Repeat the lab-wide ID if the study does not provide a unique ID.
  • [String] study: The name of the study this CDI snapshot is part of.
  • [Integer] gender: Integer constant referring to the gender of the participant this CDI form is for. The constant values for male, female, and other are defined in the encoding values configuration settings.
  • [Float] age: The age of the participant in months at the time of the CDI snapshot.
  • [String] birthday: The date of birth for the participant this snapshot is for. Should be in form YYYY/MM/DD zero padded so that the months and days both have two digits.
  • [String] session_date: The date this snapshot was taken (the day the CDI was completed). Should be in form YYYY/MM/DD zero padded so that the months and days both have two digits.
  • [Integer] session_num: The number of CDIs the participant has completed within this study at the time this snapshot was taken. Equivalent to the number of prior snapshots for this participant plus one.
  • [Integer] total_num_sessions: The total number of CDIs this participant is expected to complete for this study.
  • [Integer] words_spoken: The number of words marked as spoken / signed / known on the CDI excluding extra categories.
  • [Integer] items_excluded: The number of words not inquired about typically included in this CDI type. Provide 0 if the full CDI was completed.
  • [Float] percentile: The percentile achieved by the research participant on this snapshot. This should be calculated given this snapshot participant's age, gender, and number of words said / signed / known. The 99th percentile would be 99.0.
  • [Integer] extra_categories: Flag indicating if this snapshot includes extra items / categories not typically on this CDI type. Should be 0 (or NO_EXTRA_CATEGORIES if custom encoding values set) if the typical CDI was used.
  • [Integer] revision: The number of times this CDI snapshot has been revised. 0 if this CDI has not been manually edited.
  • [String] languages: Comma separated list of languages reportedly known by this participant at the time of the snapshot. A participant speaking / knowing both English and Spanish would be reported as "English,Spanish" without a space after the comma.
  • [Integer] num_languages: The number of languages reportedly known by this participant at the time of the snapshot. A participant reportedly speaking / knowing both English and Spanish would receive a 2 for this column.
  • [String] mcdi_type: The name of the type of CDI form used in creating this snapshot. Examples could incldue "macarthur" or "CU".
  • [Integer] hard_of_hearing: Flag indicating if the research participant is hard of hearing. 0 for false and 1 for true unless overwritten by the application (see encoding values section below).
  • [Integer] deleted: Flag indicating if this CDI has been deleted or not. Use 0 for false and 1 for true. Defaults to 0. This will determine if the CDI should be shown in standard search results or not.
• Table: snapshot_content

  Information about a response to an individual word / item in a snapshot. If a CDI form contains word1 and word2, a snapshot for that CDI type will include 1 snapshot row and 2 snapshot_content rows. A many-to-one relationship exists between snapshot_content and snapshots.

  • [Integer, foreign key] snapshot_id: The ID of the snapshot this snapshot_content is part of.
  • [String] word: The word / item on the CDI this row is for.
  • [Integer] value: The value reported for that word in this snapshot.
  • [Integer] revision: The number of times this CDI snapshot has been revised. 0 if this CDI has not been manually modified.
• Table: api_keys

  (This table does not need to be filled during data migration.) The application provides a programmatically accessible interface for outside software to automate tasks in CDIbase. To use the API, users must have an API key. Each of this table's rows contains information about user's API key. Columns:

  • [Integer] user_id: The numerical ID of the user that the row's API key is for.
  • [String] api_key: The randomly generated API key for that user.
• Table: mcdi_formats

  (This table does not need to be filled manually during data migration.) This table contains all of the types of CDIs available to the application. This includes all the CDIs that parents can complete through CDIbase and all of the CDIs for which responses are available through the application. Each of this table's rows contains information about a single CDI type. Columns:

  • [String] human_name: The human-friendly name for this CDI type. Will be used by the application's user interfaces whenever referring to this CDI type. An example may include "MacArthur-Bates Communicative Development Inventory".
  • [String] safe_name: URL-safe name for this CDI type. Will be used by the application's back end / internals (not user interfaces) when referring to this CDI type. An example may include "macarthur_cdi".
  • [String] filename: The name of the YAML specification file with additional information about this CDI type including its words and where CDIbase can find its percentile information. This file should be in the uploads directory.
• Table: parent_forms

  (This table does not need to be filled during data migration.) CDIbase can send CDI forms to parents and older participants to complete online. This table holds information about each form waiting to be completed by a parent / participant. Note that CDIbase removes records from this table as parents / participants complete their electronic CDIs. Columns:

  • [String] form_id: The randomly generated ID for this electronic CDI form.
  • [String] child_name: The name of the research participant the CDI form is intended for. Likely not the participant's full or real name, this helps the parent differentiate between siblings and confirm they received the correct CDI form.
  • [String] mcdi_type: The (safe_name) name of the CDI form type sent.
  • [Integer] child_id: The lab-wide unique integer ID of the research participant this CDI form is for.
  • [String] study_id: The ID of the research participant within the study. Use child_id if the study does not have its own study-specific children IDs.
  • [String] study: The name of the study this CDI form is for.
  • [Integer] gender: Integer constant referring to the gender of the participant this CDI form is for. See encoding values section for values corresponding to male, female, and other.
  • [String] birthday: The birth date of the participant this CDI form is for. Date should be in form of YYYY/MM/DD where months and dates are zero padded to ensure they are two digits.
  • [Integer] items_excluded: The number of items removed from the CDI form sent / the number of words not inquired about. 0 if the full CDI was completed.
  • [Integer] extra_categories: Flag indicating if this form includes extra items / categories not typically on this CDI type. 0 if the typical CDI was completed.
  • [Integer] hard_of_hearing: Flag indicating if the research participant this CDI is intended for is hard of hearing. 0 for false and 1 for true unless overwritten in the encoding values options.
  • [Integer] total_num_sessions: Total number of expected CDI snapshots that the participant will complete for the current study.
• Table: percentile_tables

  (This table does not need to be filled manually during data migration.) This table contains information for all of the CDI percentiles, allowing CDIbase to automatically calculate percentiles for snapshots given the snapshot CDI, the participant's age, the gender of the participant, and the number of words reported as spoken / signed / known. Columns:

  • [String] human_name: The human-friendly name for percentile table. Will be used by the application's user interfaces whenever referring to this set of percentile information.
  • [String] safe_name: URL-safe name for this set of percentile information. Will be used by the application's back end / internals (not user interfaces) when referring to this percentile table. This should match the percentile table name in the CDI YAML specification.
  • [String] filename: The name of the CSV file containing the percentile table. This file can be found in the uploads directory.
• Table: presentation_formats

  (This table does not need to be filled manually during data migration.) Presentation formats allow CDIbase to report the same data with different encodings for common values like said, not said, true, false, male, female, etc. These formats help support legacy software and applications / code in use by individual researchers without needing to keep multiple copies of the CDI database. Columns:

  • [String] human_name: The human-friendly name for presentation format. Will be used by the application's user interfaces whenever referring to this format.
  • [String] safe_name: URL-safe name for this presentation format. Will be used by the application's back end / internals (not user interfaces) when referring to this formatting / encoding information.
  • [String] filename: The name of the YAML file containing the specification for this format. This file can be found in the uploads directory.

Users can define CDI formats through YAML (intro to YAML) specification files (example simple CDI specification, example of complex / multilingual CDI specification). Its components:

• [Object] meta:
  • [String] mcdi_type: The machine / URL safe name for this CDI type. Should match the name that will be used by the rest of this application to refer to this CDI sepcification.
  • [Boolean] has_hard_of_hearing: Flag indicating if this CDI supports / will be used by hard of hearing research participants.
• [Object] percentiles:
  • [String] male: The name of the percentile table to use when calculating percentiles for male respondents to this CDI.
  • [String] female: The name of the percentile table to use when calculating percentiles for female respondents to this CDI.
  • [String] other: The name of the percentile table to use when calculating percentiles for respondents neither considered male or female.
• [List] options: List of options that a respondent can select for a word. Examples include "said" and "not said" for example. Each item has:
  • [String] name: The name / text to display to describe an option. Example could be "said".
  • [Integer] value: The raw value to save to the database when this option is selected. Example could be 1.
• [List] categories: The categories on this CDI where category includes words. Examples include "verbs" and "kitchen items". Each item has:
  • [String] name: The name of the category (like "kitchen items").
  • [String] language: The language the words in this category are written in (like "English").
  • [List] words: List of words in this category. Each item should be a single String containing one word within this category.
• [List] count_as_spoken: The values to count as spoken / signed / known for the purposes of percentile calculation. Each item should be an integer corresponding to a value in the options list above.

Presentation formats provide alternate encoding schemes. Does some lab software use "boy" while the rest uses "male" for gender? CDIbase can not only store multiple types of CDIs across many studies but its presentation formats switch between encodings, allowing individual researchers to choose between values like "true" or "1" without duplicating data.

Examples of presentation format YAML files:

• Presentation format reporting all spoken words at 1's regardless of language.
• Presentation format reporting all spoken words with language information.

Meaning of common fields:

• [String or Integer] explicit_true: Value to use for true. Note that there is an implied_true defined below for use in importing legacy data.
• [String or Integer] explicit_false: The value to use for false. Note that there is an implied_false defined below for use in importing legacy data.
• [String or Integer] male: The value to use to report the gender of a participant as male.
• [String or Integer] female: The value to use to report the gender of a participant as female.
• [String or Integer] explicit_other: The value to report when a CDI field was marked as not other (like none of the above). This is also the value used to show "other" for gender.
• [Integer] no_extra_categories: The value to use to indicate that the CDI had no categories / items added to it that are not normally part of that type of CDI.
• [Integer] extra_categories: The value to use to indicate that the CDI had extra categories / items added to it not normally part of that type of CDI.

A presentation format then has mappings where keys (attributes) are word values from the CDI format to convert and the corresponding values indicate what should be reported in downloads for those word values.

Meaning of uncommon fields (mostly used for legacy data and values from before migration).

• [String or Integer] implied_true: The value to report when a CDI field had a non-standard value parsed as true. For example, if the rest of the dataset had 1 for true and 0 for false when importing legacy data, this would indicate that the value found was a non-standard true value like "t".
• [String or Integer] implied_false: The value to report when a CDI field had a non-standard value parsed as true. For example, if the rest of the dataset had 1 for true and 0 for false when importing legacy data, this would indicate that the value found was a non-standard true value like "f".
• [String or Integer] explicit_none: The value to report when a CDI field was marked as none.
• [String or Integer] explicit_na: The value to report when a CDI field was marked as not applicable.
• [String or Integer] no_data: The value to report when a CDI field had no data.
• [String or Integer] unknown: The value to report when a CDI field had a value of "unknown".
• [String or Integer] possibly_wrongly_rec: The value to report when a CDI field had a value of "possibly wrongly recorded". This is to help in legacy data import.
• [String or Integer] emergency: The value to report when a CDI field had a value of "emergency". This indicates that the CDI was not completed or the session was interrupted for some reason.

Percentiles tables allow CDIbase to automatically calculate percentiles of participants given the number of words said / signed / known at the the time of a CDI. Typically labs will have one percentile per gender per CDI type. The first row has participant ages in months. The first column has percentiles. The remaining cells show the number of words known by the prototypical kid at that age / percentile. The 0,0 cell is ignored (filled with a single % sign by convention). Please see an example of a percentile table. If your lab hopes to use something other than percentile tables, please contact us for help or with much welcome patches.

Send single CDI form to parent by email

POST /api/v0/send_parent_form?api_key={{key}}

All of the following additional query parameters are required:

• &child_name={{child name}} // Note that this is deleted from the DB after the parent completes the CDI.
• &mcdi_type={{type of MCDI form to send}}
• &parent_email={{parent's email address}}
• &format={{data presentation format}} // This indicates what values should be used for true, false, male, female, etc.

At least one of the two is required:

• &database_id={{db id}} // The global database ID for a child.
• &study={{study name}}&study_id={{child ID within study}}

Any of the following can be optionally specified:

• study // String with no quotes.
• gender // Corresponds to encoding values.
• birthday // ISO 8601
• items_excluded // Integer. I suggest 0 if uncertain.
• extra_categories // Integer. I suggest 0 if uncertain.
• languages // period seperated list (not commas because of the second API endpoint)
• hard_of_hearing // Use "1" for true and "0" for false unless the application overwrote encoding values.

If any of these fields are not provided, missing values will be loaded from the most recent MCDI available for the child or, if there are no prior MCDIs available within the DB, the parent will be asked for this information within the form GUI.

Send a CDI form to many parents by email

POST /api/v0/send_parent_form?api_key={{key}}

All of the following additional query parameters are required:

• &child_name={{child name}} // Note that these are deleted after the parent completes the CDI. Should be a comma separated list without quotes.
• &mcdi_type={{type of MCDI form to send}} // Should be a comma separated list without quotes where the first type is for the first child in child_name, the second type is for the second child in child_name and so on.
• &parent_email={{parent's email address}} // Should be a comma separated list without quotes where the first parent email is for the first child in child_name, the second parent email is for the second child in child_name and so on.
• &format={{data presentation format}} // This indicates what values should be used for true, false, male, female, etc. Should be a comma separated list without quotes where the first type is for the first child in child_name, the second type is for the second child in child_name and so on.

At least one of the two is required:

• &database_id={{kelp db id}} // Should be a comma separated list without quotes where the first ID is for the first child in child_name, the second ID is for the second child in child_name and so on.
• &study={{study name}}&study_id={{child ID within study}} // Should be comma separated lists without quotes where the first study and study ID is for the first child in child_name, the second study and study ID is for the second child in child_name and so on.

Any of the following can be optionally specified:

• study // String with no quotes. Should be a comma separated list where the first study is for the first child in child_name, the second study is for the second child in child_name, etc.
• gender // Comma separated list where the first gender is for the first child in child_name, the second gender is for the second child in child_name, etc. Should correspond to encoding values.
• birthday // ISO 8601 dates. Comma separated list where the first birthdate is for the first child in child_name, the second date is for the second child in child_name, etc.
• items_excluded // Integers. Comma separated list where the first value is for the first child in child_name, the second value is for the second child in child_name, etc. Pass 0 if the full CDI is being completed.
• extra_categories // Integers. Comma separated list where the first value is for the first child in child_name, the second value is for the second child in child_name, etc. Pass 0 if the typical CDI is being completed without added sections.
• languages // List of period seperated lists where the lists are separated by commas (sorry). The first list of languages should be for the first child in child_name, the second list for the second child in child_name, etc.
• hard_of_hearing // "1" or "0" for true and false respectively. The first value should be for the first child in child_names, the second element for the second child in child_names, etc.

If any of these fields are not provided, missing values will be loaded from the most recent MCDI available for the child or, if there are no prior MCDIs available within the DB, the parent will be asked for this information within the form GUI.

Great! First, we suggest familiarity with the following:

• Python 2.x (introductory book to Python)
• The Flask micro-framework.
• The Jinja2 templating engine.
• Epydoc

See the project repository for more details on how to get started. Don't forget about our issue tracker. Pull requests welcome!