Morrison COU1 — CPB hemolysis credibility assessment
V&V 40 credibility assessment for CFD hemolysis prediction of the FDA generic centrifugal blood pump under cardiopulmonary bypass (CPB) conditions. COU1 evaluates whether the computational model can identify worst-case hemolysis operating conditions for a Class II CPB device at Model Risk Level 2. Full 13-factor assessment: 7 factors assessed (all meeting required levels), 6 factors not assessed (acceptable at MRL 2).
69% of all factors evidenced; 2 factors required at Level 2 still need evidence (listed below); 4 high-severity concerns remain open before this is review-ready.
Indicative summary, not a formal acceptance decision. Gate checks below are structural validity and completeness; they are not a judgment of whether to accept the model.
| Factor | What it means | Status |
|---|---|---|
| Does the model match the test results | Whether the model's predictions were compared against physical test measurements, and how closely they agreed. | Not stated |
| Does the test evidence match the real use | Whether the validation testing reflects the specific way the model is relied on for this decision. | Not stated |
| Is the mesh fine enough | Whether the model's grid or time steps are fine enough that making them finer would not meaningfully change the answer. | Evidenced |
| Do the model and the test share the same inputs | Whether the model and the physical test were driven by matching inputs, so the comparison between them is fair. | Evidenced |
| Is the model built right for this use | Whether the physics and assumptions in the model match how the model is actually relied on in this decision. | Evidenced |
| Are the inputs justified | Whether the values fed into the model, such as materials, loads, and boundary conditions, are appropriate and supported by evidence. | Evidenced |
| Does the code solve the math correctly | Whether the software has been checked to solve its underlying equations correctly, separate from whether those equations match reality. | Evidenced |
| Does it measure what matters | Whether the quantities the model predicts are the ones that actually matter for the decision being made. | Evidenced |
| Was the software built and managed properly | Whether the simulation software was developed, tested, and version-controlled with disciplined engineering practices. | Evidenced |
| Were the tests run under relevant conditions | Whether the physical tests were performed under conditions close to how the model is used in the real decision. | Evidenced |
| Were enough real samples tested | Whether the physical test data used to check the model came from enough specimens to be representative. | Evidenced |
| Did the solver converge cleanly | Whether the numerical solution settled to a stable answer rather than being skewed by solver settings or incomplete convergence. | Not applicable |
| Was the tool used correctly | Whether the model was set up and operated correctly by the people running it, without mistakes that would skew the result. | Not applicable |
Ask the submitter to provide evidence for:
Status: Unverified (demo)
This evidence was assessed in an unsigned demo, so identity and tamper-evidence were not verified. A formally issued assurance package would carry a content hash and a cryptographic signature, shown here for a reviewer (or a technical colleague) to re-verify.
A technical colleague can re-verify a signed package with:
uofa check <package>.jsonld