What this model was used for

Morrison COU2 — VAD hemolysis credibility assessment

V&V 40 credibility assessment for CFD hemolysis prediction of the FDA generic centrifugal blood pump under ventricular assist device (VAD) conditions. COU2 evaluates whether the computational model can predict absolute hemolysis levels for a Class III VAD device at Model Risk Level 5. Higher model risk drives stricter credibility requirements; Monte Carlo uncertainty quantification is performed but all credibility factor gaps remain. Full 13-factor assessment: 7 factors assessed (all with achieved levels below required levels), 6 factors not assessed (flagged as epistemic gaps at MRL 5). Decision: Not accepted.

Assessed against: ASME V&V 40
Risk tier: Level 5 (higher levels require stronger evidence)
Device class: Class III

At a glance

Completeness: 38%
Factors evidenced: 5 of 13
Concerns (weakeners): 2 Critical, 2 High, 2 Moderate
Authenticity verified: No (unsigned demo)
Gate checks passed: 1 of 2

38% of all factors evidenced; 8 factors required at Level 5 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.

Credibility factors

Factor	What it means	Status
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.	Not stated
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.	Not stated
Are the inputs justified	Whether the values fed into the model, such as materials, loads, and boundary conditions, are appropriate and supported by evidence.	Not stated
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 stated
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
Were enough real samples tested	Whether the physical test data used to check the model came from enough specimens to be representative.	Not stated
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 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
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

Concerns found

Critical concern (seen 2 times). Critical and High severity weakeners coexist — compounding risk escalation.
Critical concern (seen 7 times). Provenance chain terminates at a node that has no upstream derivation/generation/use edge and is not marked uofa:isFoundationalEvidence=true — chain is incomplete. Relates to: Output comparison.
High concern (seen 6 times). Credibility factor is not assessed but model risk level exceeds 2 — unassessed factors at elevated risk weaken the credibility argument. Relates to: Use error, Test samples, Model form, Equivalency of input parameters, Numerical solver error, Model inputs.
High concern. Context of Use has neither an applicability constraint nor an operating envelope — the COU is declared but its boundary of validity is undocumented. Relates to: Relevance of the validation activities to the COU.
Moderate concern. Uncertainty quantification is reported but no sensitivity analysis is documented — the drivers of uncertainty are uncharacterized.
Moderate concern. UofA conforms to ProfileComplete but declares no SensitivityAnalysis — a Complete profile is structurally expected to document sensitivity analysis alongside uncertainty quantification.

What is still missing

Ask the submitter to provide evidence for:

Did the solver converge cleanly. Whether the numerical solution settled to a stable answer rather than being skewed by solver settings or incomplete convergence.
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.
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.
Are the inputs justified. Whether the values fed into the model, such as materials, loads, and boundary conditions, are appropriate and supported by evidence.
Were enough real samples tested. Whether the physical test data used to check the model came from enough specimens to be representative.
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.
Does the model match the test results. Whether the model's predictions were compared against physical test measurements, and how closely they agreed.
Does the test evidence match the real use. Whether the validation testing reflects the specific way the model is relied on for this decision.

Authenticity

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