Redcap api should expose all field attributes

[gracebrownecodes]

Currently, the section header, branching logic, custom alignment, question number, and matrix name (which are included in default metadata csv exports), are not exposed. Specifically, the section header and branching logic are important for the Almanac.

[bruth]

Out of curiosity how are these additional fields being used in the context of origins?

[gracebrownecodes]

Not sure I understand your question... I'm trying to use origins as the one true source of metadata for the Almanac, and both the section header and branching logic are important for display. The section header needs to be rendered on form views and branching logic is needed to implement some NBSTRN-requested element labelling (they collect multiple disorders in the same project, using branching logic to display the appropriate fields, and want to be able to sort the elements by disorder in the Almanac). Also, generally, I've seen some redcap projects where the elements implicitly reference the section header. So the field label only says "units" and we are expected to see that field in the context of the "medication" section, or something like that. Also, as a reference for analysis of data, the Almanac would do well to inform its end users of when the element in question is not available for data entry under certain cases (which is essentially the use of branching logic).

I'm actually putting together a PR right now, so you can see my suggestions concretely.

[bruth]

Thanks for the explanation. I have no qualms with passing the extract metadata through.

So the field label only says "units" and we are expected to see that field in the context of the "medication" section, or something like that.

The current hierarchy is project → form → field. Do you think it is necessary to add section in between form and field? I am correct that sections are optional?

[gracebrownecodes]

Sections are definitely optional, would there be a way to optionally insert sections between form and field in the hierarchy? Or, you could have a default placeholder section under every form...

[bruth]

Yea, the way to do it would be to add a default section in between the form and fields. There can be direct access from form to fields in the API which is similar to how the PostgreSQL backend works with schemas. By default all tables creates are under the public schema even though we don't explicitly specify it.

The explicit way is to do db.schemas['public'].tables, but because it is common to for working with tables in the public schema, I added support for db.tables. We could have a similar approach for this, e.g. project.forms['demographics'].sections['default'].fields and project.forms['demographics'].fields as the shorthand. The only side effect is that a default section is being inserted into hierarchy which will be visible on export. I personally do not think this is a big deal especially since it's removing ambiguity within REDCap's structure.

[gracebrownecodes]

I personally would find that behavior desirable, especially for the Almanac. I was planning to create sections in the almanac, so having them pre-created in origins would be awesome. You will have to do some foo to get it right, because in all backends, the section header is only defined on the first element of the section, but that section should probably contain all elements until the next section header or the end of the form (making some assumptions there, but making them based on my past experience with user generated projects).

[bruth]

Ok. Yep, I already need to apply the foo in the CSV data dictionary backend; all fields are under the same form/section until the next label is present.

[gracebrownecodes]

tried to associate my pr with this issue after the fact, didn't seem to work...

[bruth]

No problem. The subject line is not parsed for things like fixes #13. It needs to be in the message body.

[bruth]

Thanks for doing this.

[penningtonj]

This is beautiful.