Skip to content

Read study_id as the study identifier and expose the number as study_nr - #220

Merged
headmeister merged 2 commits into
isi-nmr:masterfrom
gdevenyi:fix/study-id-identifier
Aug 24, 2026
Merged

Read study_id as the study identifier and expose the number as study_nr#220
headmeister merged 2 commits into
isi-nmr:masterfrom
gdevenyi:fix/study-id-identifier

Conversation

@gdevenyi

@gdevenyi gdevenyi commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #216 (the study_id question raised there) — stacked on #219, the first commit here is that PR's; merge #219 first.

Every dataset type defined study_id as the study numberstr(#VisuStudyNumber) for 2dseq, str(#SUBJECT_study_nr) for fid/rawdata/traj/fid_proc — while ParaVision's study identifier is a different parameter: VisuStudyId / SUBJECT_study_name, the user-given string set during study registration (PV6 D02 §2.4.11.5). On the PV5.1 Zenodo data that is TEST_IO against a number of 2 (data_io/2 on PV6, API_TEST/1 on PV7).

Change

Same pattern as subj_id in #219, in all five properties_*_custom.json:

"study_id": [{"cmd": "#VisuStudyId", "conditions": []}, {"cmd": "''", "conditions": []}],
"study_nr": [{"cmd": "#VisuStudyNumber", "conditions": []}, {"cmd": "''", "conditions": []}],

(#SUBJECT_study_name / #SUBJECT_study_nr for the raw types.) study_nr is the integer the parameter is, not a string.

id keeps composing from the number (@study_nr): it is what ParaVision keys the study directory by (the trailing _<session>_<study number> of its name, FILE_FORMAT.md §1.1 — note the number is unique within a session, so two sessions of one subject can repeat it, as before), whereas a user-given identifier need not be unique. So no dataset id, no report() output and no test/config reference changes. Neither property shows up in to_dict()/report(): study_id was already on the exclusion list and study_nr joins it, like the other id components — un-hiding the identifier is a one-line follow-up if you want it reported.

Test

test_study_id_is_the_study_identifier_and_study_nr_the_number — a synthetic study with a 2dseq and a fid, VisuStudyId/SUBJECT_study_name = TEST_IO, number 1; asserts study_id, study_nr, and that both ids are unchanged. Fails on master. (study_id is excluded from reports, so the corpus test_properties cannot see a typo in the raw-type recipes — that is why the fid is in the test.) test_traj_custom_properties_define_a_stable_id updated for the new key and the id recipe.

Suite: 2252 passed, 4 skipped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NHhfFXMNZKMuPm3ppdzFXe

gdevenyi and others added 2 commits August 21, 2026 20:05
Dataset.subj_id meant two different things depending on the dataset type.
For fid, rawdata and traj it is SUBJECT_id, the subject identifier. For 2dseq
it was VisuSubjectName, the subject's name, which ParaVision documents as a
separate field (PV6 D02 2.4.11.4: VisuSubjectName is the name of the subject
in DICOM format, VisuSubjectId the subject identification / registration
string). The identifier exists in visu_pars as VisuSubjectId and was never
read.

On the public PV5.1 data (Zenodo 4048286, 0.2H2) the same scan gave
subj_id == 'LEGO_PHANTOM' as a 2dseq and '0' as a fid. On PV360 the two
diverge even when the user typed the same text in both fields, because
VisuSubjectName is written in DICOM patient-name format: the 360 standard
dataset gives 'std_PV360_3.6^^^^' for a 2dseq where VisuSubjectId is
'std_PV360_3.6' -- and, since id is composed from subj_id, carets inside a
dataset identifier.

Read VisuSubjectId, the Visu counterpart of SUBJECT_id (ParaVision derives
one from the other), so subj_id means the same thing for every dataset type.
The name stays available as metadata["visu_subject"]["name"].

This changes the 2dseq id string, which report() prints and which keys the
property references: 2DSEQ_2_1_LEGO_PHANTOM_2 becomes 2DSEQ_2_1_0_2. The
test/config references are renamed in place; no other property changes.

study_id is left alone: all four recipes read the study *number*
(VisuStudyNumber / SUBJECT_study_nr) where ParaVision's identifier is
VisuStudyId / SUBJECT_study_name. That is consistent across types, so it is
a naming decision for the maintainers rather than a defect.

Closes isi-nmr#216

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NHhfFXMNZKMuPm3ppdzFXe
Every dataset type defined study_id as the study number -- str(VisuStudyNumber)
for 2dseq, str(SUBJECT_study_nr) for fid, rawdata, traj and fid_proc -- while
ParaVision's study identifier is a different parameter: VisuStudyId /
SUBJECT_study_name, the user-given string set during study registration
(PV6 D02 2.4.11.5). On the PV5.1 Zenodo data that is 'TEST_IO' against a
number of 2. This was raised in isi-nmr#216 as a naming question; the answer is to
follow the same pattern as subj_id.

study_id now reads VisuStudyId / SUBJECT_study_name; the number moves to a
new study_nr property, read as the integer it is. id keeps composing from the
number -- it is what ParaVision keys the study directory by (the trailing
_<session>_<study number> of its name, FILE_FORMAT.md 1.1), whereas a
user-given identifier need not be unique -- so no dataset id, report or
property reference changes. Neither property appears in to_dict()/report() output: study_id was
already on the exclusion list and study_nr joins it, like the other id
components.

Builds on isi-nmr#219, which makes the 2dseq subj_id the subject identifier.

Refs isi-nmr#216

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NHhfFXMNZKMuPm3ppdzFXe
@gdevenyi
gdevenyi force-pushed the fix/study-id-identifier branch from f080d42 to ba2bae7 Compare August 22, 2026 02:29
@headmeister
headmeister merged commit 14b64d3 into isi-nmr:master Aug 24, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants