488e91e / tag baseline).
Overview
Health Yourself collects questionnaire answers and blood results in your intake UX (see the Input Data Preparation Guide). Before calling Idunox, your backend maps that data into canonical Type A JSON — a structuredsubject block, a flat markers[] blood panel, optional sourceMetadata, and options.
Top-level fields
* At least one of
markers or reportDocuments must be non-empty. Health Yourself always sends the 14-marker panel in markers.
Numeric sentinel (-1)
Optional integer and number fields on smoking and family history accept -1 as “not applicable” (TYPE_A_NOT_APPLICABLE in the platform). The server treats -1 like a missing value for branch rules (e.g. stopAge is not considered “set” when -1).
- Prefer omitting a key when the intake branch does not collect that field.
- Use
-1only when your serializer must send a number but the UI path is “Not applicable”. - Do not use
-1on bloodmarkers[].value— values must be finite numbers within range.
Questionnaire → canonical mapping
Map intake labels to canonical enum values (lowercase snake_case). Omit keys that do not apply; do not sendnull for optional numbers unless your serializer requires it.
Demographics and measurements
Optional demographics:
ethnicity (string), educationYears (integer 0..40).
Smoking (subject.history.smoking)
status (required when smoking is sent): never, former, current, prefer_not_to_say
pastFrequency / currentFrequency (when allowed): none, light, moderate, heavy, unknown
Current smokers: provide
currentCigsPerDay and/or currentFrequency (not unknown) so intensity is defined.
Never / prefer not to say: send only status (or omit the whole smoking object for never-only paths); all other smoking keys must be omitted.
Former smoker example (canonical)
Former smoker example (canonical)
currentFrequency or currentCigsPerDay.Conditions and medications
Family history (subject.familyHistory)
Each parent (father, mother) uses aliveStatus, optional ages, and conditions[].
All allowed
conditions[] codes: diabetes_mellitus, cardiovascular_disease, cerebrovascular_disease, dementia, alzheimer_disease, kidney_disease, lung_cancer, other_malignancy, hypertension, none_known, unknown.
Blood markers → markers[]
Use canonical marker codes in markers[].code (not B### guide ids in the JSON body). Submit exactly 14 rows — one per code, no duplicates. Aliases resolve to the same canonical code (e.g. ALB → ALBUMIN, HBA1C → HBA1C_MMOL_MOL with mmol/mol unit).
*When
sourceMetadata.markerRanges.{CODE} is present for a marker, validation uses your lowerBound..upperBound instead of the preset analytical range. µ / μ in units normalize to the same value as u for comparison.
Accepted code aliases (non-exhaustive): ALB, CA, TCHOL / TOTAL_CHOLESTEROL, CYSTATIN, HDL_CHOLESTEROL, C_REACTIVE_PROTEIN, LDL_DIRECT, PHOS, UA, HBA1C (with mmol/mol unit only).
Each array element:
valuemust be a finite number (JSON number preferred).- Optional per-marker
observedAt(ISO-8601); otherwise usesourceMetadata.sourceTimestampfor the panel.
Lab reference ranges (sourceMetadata.markerRanges)
Provide structured bounds keyed by marker code:
lowerBoundmust be ≤upperBound.unitmust match the preset unit for that code (after normalization).- When a code is listed, value validation uses your bounds instead of the default analytical preset.
- Unknown keys in
markerRangesfail validation. - Omit
markerRangesentirely to use server preset analytical ranges only (still validates units, panel size, and duplicates).
Options
Public outcome ids match
GET /v1/results → outcomes[].outcomeId.
Validation errors
See Errors for examples.
Further reading
- Create Submissions — full request example
- Input Data Preparation Guide — intake UX tables (Q### / B###)
- OpenAPI specification — machine-readable contract synced from the platform repo