1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
//! Data structures for building pharmacometric input data.
//!
//! Use this module when you need to describe what happened to each subject:
//! doses, infusions, observations, covariates, and occasion boundaries.
//!
//! This module is the input side of `pharmsol`. It is where you assemble
//! subjects and datasets before simulation, estimation, or NCA. It is not where
//! you define model equations or choose a backend. For those workflows, move to
//! [`crate::simulator`], [`crate::nca`], or the feature-gated `pharmsol::dsl`
//! surface.
//!
//! # Start Here
//!
//! Most users only need three entrypoints first:
//!
//! - [`Subject`] for one individual and their full schedule.
//! - [`Data`] for a dataset containing many subjects.
//! - `Subject::builder` for the smallest fluent API to create doses,
//! observations, and covariates in Rust.
//!
//! The main supporting types are:
//!
//! - [`Occasion`] for repeated periods within one subject.
//! - [`Event`], [`Bolus`], [`Infusion`], and [`Observation`] for explicit
//! event-level control.
//! - [`Covariate`] and [`Covariates`] for time-varying subject characteristics.
//! - [`ErrorModel`], [`ResidualErrorModel`], and [`ObservationError`] for the
//! different error surfaces used by downstream workflows.
//!
//! # Choose A Data Input Path
//!
//! - Use `Subject::builder` when you are authoring a schedule directly in Rust.
//! - Use [`row::DataRow`] and [`row::DataRowBuilder`] when your source data is
//! already row-shaped in memory.
//! - Use [`parser::read_pmetrics`] when you are loading a Pmetrics-style file
//! from disk.
//! - Use [`Event`] variants directly when you already have validated event
//! records and need lower-level control than the builder offers.
//!
//! # Label Semantics
//!
//! Dosing inputs and observation outputs use public labels.
//!
//! - The `input` on [`Bolus`] and [`Infusion`] is the route or input label that
//! will be matched against the model.
//! - The `outeq` on [`Observation`] is the output label that identifies which
//! model output the observation belongs to.
//! - Prefer stable names such as `"depot"`, `"central"`, `"iv"`, or `"cp"`.
//! - If you pass a number, it is still treated as a public label string. Use
//! numeric values only when your model intentionally declares numeric labels.
//!
//! [`Occasion`] indices are different: they are integer period markers used to
//! separate repeated dosing blocks within one subject.
//!
//! # Error Surfaces
//!
//! This module exposes three related but different error families:
//!
//! - [`ErrorModel`] for assay or measurement error driven by the observation
//! value, commonly used in non-parametric workflows.
//! - [`ResidualErrorModel`] for residual unexplained variability driven by the
//! prediction value, commonly used in parametric workflows.
//! - [`ObservationError`] for invalid or insufficient observation data during
//! profile construction and related preprocessing.
//!
//! # Example
//!
//! ```rust
//! use pharmsol::*;
//!
//! let subject = Subject::builder("patient_001")
//! .bolus(0.0, 100.0, "depot")
//! .observation(1.0, 12.3, "cp")
//! .missing_observation(2.0, "cp")
//! .covariate("weight", 0.0, 70.0)
//! .build();
//!
//! let data = Data::new(vec![subject]);
//!
//! assert_eq!(data.subjects().len(), 1);
//! ```
pub use crate;
pub use *;
pub use *;
pub use *;
pub use ObservationError;
pub use *;
pub use ;