ShieldingCalculator
Shielding Calculator
Shielding Calculator — Radiation Shielding Calculation (NCRP 147/151)
ℹ️ The utility calculates required thickness of shielding barrier (concrete, lead, drywall) or verifies compliance of existing shielding.
ℹ️ Uses Transmission Factor method based on Workload (W), Distance (d), Use (U) and Occupancy (T) factors.
ℹ️ Processing: only the FIRST record in input.csv file.
⚠️ Critical for facility commissioning! Shielding calculation errors lead to exceeding dose limits for staff and public.
Usage:
ShieldingCalculator.exe → demo mode
ShieldingCalculator.exe input.csv output.json → calculate data (first record only)
Input format:
RoomID,BarrierType,WorkloadGyPerWeek,UseFactor,OccupancyFactor,DistanceM,DesignDoseSvPerWeek,ExistingThicknessCm,HVL_Cm,TVL_Cm
Example (CT secondary barrier, concrete):
CT-Room-01_Barrier_North,Secondary,100.0,1.0,0.2,3.5,0.0001,20.0,2.5,8.3
— WHY IS THIS NEEDED?
When designing X-ray rooms, CT, PET centers, and RT bunkers, one must guarantee dose behind wall does not exceed limits (typically 0.1 mSv/week for public, 1.0 mSv/week for staff).
• Formula accounts for inverse square law and material attenuation.
• Allows quick check of "weak points" (doors, mazes, slab joints).
• Independent verification of architects' and engineers' design.
⚠️ CRITICAL:
• Workload (W) must be realistic (peak), not average.
• Occupancy factor (T) for corridors often 1/5 or 1/20, for adjacent offices — 1.
• TVL/HVL depend on tube voltage (kV) or nuclide type. Using wrong values is fatal.
• Safety margin typically ≥ 1 TVL or fixed value (e.g., 1-2 cm concrete).
Critical parameters:
• Design Dose (P): 0.1 mSv/week (public), 1.0 mSv/week (staff)
• TVL (Tenth Value Layer): thickness attenuating beam by factor of 10
• Shielding Margin: Required vs Existing
⚠️ Note: Utility automatically calculates required thickness and compares with existing. If shielding deficit found, issues FAIL status with requirement to reinforce barrier. Result includes status and bilingual recommendation (RU/EN).
input.csv
RoomID,BarrierType,WorkloadGyPerWeek,UseFactor,OccupancyFactor,DistanceM,DesignDoseSvPerWeek,ExistingThicknessCm,HVL_Cm,TVL_Cm CT-Room-01_Barrier_North,Secondary,100.0,1.0,0.2,3.5,0.0001,20.0,2.5,8.3
URS & FS — user requirements and functional specification
This document defines user requirements and functional specification for the quality-control utility. It supports deployment discussion, IQ/OQ preparation and QC workflow integration.
1. Scope
The Shielding Calculator utility is used for Shielding Calculator. The actual input.csv is the source of truth for the input structure; control criteria are defined by the executable and the domain description.
The utility does not use machine learning; decisions are produced by deterministic rules.
Categories: Radiation physics
Tags: activity, brachytherapy, dosimetry, source calibration, TG-43
2. Execution modes
ShieldingCalculator.exe → demo mode ShieldingCalculator.exe input.csv output.json → calculate data (first record only)
3. Key controlled areas
- activity, decay and radiochemical purity
4. Domain limits and critical parameters
- ⚠️ Critical for facility commissioning! Shielding calculation errors lead to exceeding dose limits for staff and public.
- ⚠️ CRITICAL:
- Workload (W) must be realistic (peak), not average.
- Occupancy factor (T) for corridors often 1/5 or 1/20, for adjacent offices — 1.
- TVL/HVL depend on tube voltage (kV) or nuclide type. Using wrong values is fatal.
- Safety margin typically ≥ 1 TVL or fixed value (e.g., 1-2 cm concrete).
- Critical parameters:
- Design Dose (P): 0.1 mSv/week (public), 1.0 mSv/week (staff)
- TVL (Tenth Value Layer): thickness attenuating beam by factor of 10
- Shielding Margin: Required vs Existing
- ⚠️ Note: Utility automatically calculates required thickness and compares with existing. If shielding deficit found, issues FAIL status with requirement to reinforce barrier. Result includes status and bilingual recommendation (RU/EN).
5. URS — user requirements
| ID | Requirement | Criticality | Acceptance criterion |
|---|---|---|---|
| URS-001 | The system shall accept an input.csv file for Shielding Calculator with the exact columns listed in the “Input data contract” section. | High | A file with the correct header is processed without manual editing; missing mandatory columns produce FAIL/import error. |
| URS-002 | The system shall support execution without arguments in demo mode and execution with input.csv output.json for user data. | Medium | Both execution scenarios produce a predictable result or clear diagnostic error. |
| URS-003 | The system shall perform rule-based controls for: activity, decay and radiochemical purity. | High | Each controlled parameter receives a status and message; the result does not depend on hidden Excel formulas or ML. |
| URS-004 | The system shall preserve traceability between batch/lot, source values, applied rules and final verdict. | High | Output includes batch identifier, source values, parameter statuses and critical findings. |
| URS-005 | The system shall generate machine-readable output.json for LIMS/ELN/MES, batch record and QA/QC review. | High | JSON contains overall status, check array, warnings, failures and source-file reference. |
| URS-006 | The system shall support use in the client validation package: URS/FS, IQ/OQ preparation, installation and operational scenario checks. | High | The document, test scenarios and reproducible CSV/JSON flow are suitable for audit and internal approval. |
| URS-007 | The system shall clearly separate technical data errors from specification nonconformities. | Medium | Schema/type errors are not mixed with pharmacopoeial deviations and are reported separately. |
6. input.csv data contract
The source of truth for the input schema is the actual input.csv header. Column names are technical identifiers and are not translated.
| # | Column | Type | Unit | Description | Sample | Control rule |
|---|---|---|---|---|---|---|
| 1 | RoomID | text | as specified | Room ID | CT-Room-01_Barrier_North | mandatory value; format and acceptability are checked by the utility |
| 2 | BarrierType | text | as specified | Barrier Type | Secondary | mandatory value; format and acceptability are checked by the utility |
| 3 | WorkloadGyPerWeek | decimal | as specified | Workload Gy per Week | 100.0 | mandatory numeric value; rule comparison is performed by the utility |
| 4 | UseFactor | decimal | as specified | Use Factor | 1.0 | mandatory numeric value; rule comparison is performed by the utility |
| 5 | OccupancyFactor | decimal | as specified | Occupancy Factor | 0.2 | mandatory numeric value; rule comparison is performed by the utility |
| 6 | DistanceM | decimal | as specified | Distance M | 3.5 | mandatory numeric value; rule comparison is performed by the utility |
| 7 | DesignDoseSvPerWeek | decimal | as specified | Design Dose Sv per Week | 0.0001 | mandatory numeric value; rule comparison is performed by the utility |
| 8 | ExistingThicknessCm | decimal | as specified | Existing Thickness Cm | 20.0 | mandatory numeric value; rule comparison is performed by the utility |
| 9 | HVL_Cm | decimal | as specified | HVL Cm | 2.5 | mandatory numeric value; rule comparison is performed by the utility |
| 10 | TVL_Cm | decimal | as specified | TVL Cm | 8.3 | mandatory numeric value; rule comparison is performed by the utility |
CSV example
RoomID,BarrierType,WorkloadGyPerWeek,UseFactor,OccupancyFactor,DistanceM,DesignDoseSvPerWeek,ExistingThicknessCm,HVL_Cm,TVL_Cm CT-Room-01_Barrier_North,Secondary,100.0,1.0,0.2,3.5,0.0001,20.0,2.5,8.3
7. FS — functional specification
| ID | Function | Implementation description |
|---|---|---|
| FS-001 | CLI entry point | The executable ShieldingCalculator.exe supports demo mode and input.csv output.json processing mode. |
| FS-002 | CSV parser | The import module reads CSV, validates header, column presence/order, value count and encoding. Decimal values are expected with a dot separator. |
| FS-003 | Field conversion | Each column is converted to the expected type: identifier, text, decimal number, date/time or boolean flag. |
| FS-004 | Domain rule engine | For Shielding Calculator, explicit rules are applied: range, minimum, maximum, absence of prohibited flag, data completeness or calculation-based check. |
| FS-005 | Criticality handling | Critical violations produce FAIL; non-critical deviations and incomplete data produce WARNING; full conformance produces PASS. |
| FS-006 | JSON writer | output.json stores overall status, per-parameter results, source values, warnings, failures and diagnostic messages. |
| FS-007 | Integration contract | The CSV → JSON format is stable for invocation from LIMS/ELN/MES, scheduled task or wrapper service. |
| FS-008 | Error handling | Schema error, missing file, non-numeric value or JSON write failure returns diagnosable error without silent PASS. |
8. output.json contract
The output file must be suitable for automated processing, audit review and correlation with the source input.csv row.
{
"utility": "ShieldingCalculator",
"api": "Shielding Calculator",
"batchNumber": "",
"overallStatus": "PASS|WARNING|FAIL",
"checkedAtUtc": "2026-05-18T00:00:00Z",
"checks": [
{
"parameter": "RoomID",
"value": "CT-Room-01_Barrier_North",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "BarrierType",
"value": "Secondary",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "WorkloadGyPerWeek",
"value": "100.0",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "UseFactor",
"value": "1.0",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "OccupancyFactor",
"value": "0.2",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "DistanceM",
"value": "3.5",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "DesignDoseSvPerWeek",
"value": "0.0001",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
},
{
"parameter": "ExistingThicknessCm",
"value": "20.0",
"unit": "as specified",
"status": "PASS|WARNING|FAIL",
"message": "Rule-based check result"
}
],
"criticalFindings": [],
"sourceFile": "input.csv"
}9. OQ/PQ test scenarios
| ID | Scenario | Expected result |
|---|---|---|
| TC-001 | Valid CSV with expected header and sample row | All rows are processed; output contains PASS/WARNING/FAIL and parameter-level detail. |
| TC-002 | A mandatory input.csv column is missing | Import is rejected or the row receives FAIL with schema reference. |
| TC-003 | A numeric field contains text or a blank value | Type conversion error is recorded; the result is not hidden as PASS. |
| TC-004 | A parameter is outside specification or critical limit | Critical parameters produce FAIL; non-critical deviations produce WARNING according to the rule. |
10. QA/QC, CSV and change control
- Before production use, the client records executable version, checksum, specification/monograph version, test CSV, expected JSON and IQ/OQ results.
- Column names must not be changed without updating the validator and test scenarios.
- The source CSV, output.json and utility version should be stored together as an evidence package.
- Any change in control rules must go through change control and repeated OQ scenario verification.
Included in packages
Radiation Physics QC Suite
Utilities for activity, dosimetry, brachytherapy sources, small-field corrections and TG-43 parameters.
OpenRadiology QC Suite
QC package for radiology and diagnostic imaging: radiopharmaceuticals, PET/SPECT, contrast media, iodinated and gadolinium products, plus particle, sterility and endotoxin checks.
OpenRPH organ/system: bone and musculoskeletal
Bone scintigraphy, MDP/PYP, marrow, bone-pain palliation, skeletal metastases and radiosynovectomy.
OpenRPH use case: PET scanner state, gamma camera and radiation physics
The linked medical-device/radiation-physics layer: PET detector QC, normalization, AC map, cross-calibration, TOF, gamma-camera uniformity, source strength and staff dose.
OpenRPH workflow: dosimetry and therapy planning
Activity planning, absorbed dose, organ dose, lung shunt, preplanning and therapy verification.
OpenRPH workflow: instruments, devices and radiation safety
PET/gamma-camera state, calibration, detector QC, energy window, TOF, shielding and radiation safety.
Open