xBxBio Clinical Safety & Human Oversight Policy
Effective Date: October 5, 2026
Last Updated: October 5, 2026
1. Purpose and Public Assurance
This policy establishes xBxBio's public-facing principles for clinical safety, human oversight, responsible clinical decision support, patient-centered use, and safety governance across the xBxBio ecosystem. Its purpose is to provide patients, clinicians, caregivers, healthcare organizations, laboratories, research organizations, customers, partners, regulators, and other authorized parties with assurance that xBxBio approaches clinically relevant software and AI-enabled functionality as
governed support for human decision-making rather than as an unrestricted substitute for qualified clinical judgment.
2. Public Disclosure Boundary
This is a governance and assurance policy, not an engineering specification. Public disclosure is intentionally limited to clinical, safety, quality, ethical, privacy, security, interoperability, and governance principles. Detailed technical, operational, model, security, and customer-specific implementation information is maintained separately under appropriate controls and is outside the scope of this public policy.
3. Scope
This policy applies, as appropriate, to current and future xBxBio modules, submodules, services, interfaces, analytical functions, AI-enabled functions, Virtual Heart functions, dashboards, alerts, reports, patient-facing or clinician-facing outputs, research functions, validation environments, production environments, and authorized third-party services used by or on behalf of xBxBio.
4. Technology-Neutral and Future-Capability Scope
The absence of a specific model class, vendor, device, modality, interface, disease state, care setting, deployment pattern, technology type, or jurisdiction from an illustrative list does not by itself exclude that capability from this policy where the capability falls within the defined scope.
5. Clinical Safety Objectives
xBxBio seeks to support safer, more informed clinical and scientific work by preserving human accountability, relevant patient context, source evidence, data quality, provenance, uncertainty, reviewability, and appropriate escalation. Safety controls should be proportionate to intended use, patient impact, reasonably foreseeable misuse, and applicable legal or regulatory requirements.
6. Definitions and Interpretation
Clinical safety refers to the reduction and control of risks that could contribute to patient harm, inappropriate delay, misleading interpretation, unsafe action, or loss of clinically important context. Human oversight refers to meaningful review, judgment, intervention, confirmation, override, escalation, or other accountable human participation appropriate to the intended use.
7. Governance
Clinical-safety activities should be subject to defined governance, assigned ownership, documented decision authority, review, escalation, and appropriate quality oversight. Governance should distinguish research, development, validation, demonstration, evaluation, and any authorized clinical use.
8. Accountability
Human accountability is retained for clinical interpretation, diagnosis, treatment, patient management, escalation, exception approval, risk acceptance, and other decisions that require professional judgment or organizational authority.
9. Human Clinical Authority
xBxBio outputs are intended to support qualified users and should not be represented as having independent clinical authority. Responsibility for clinical decisions remains with appropriately authorized healthcare professionals and organizations, subject to applicable law, professional standards, and institutional policies.
10. Intended Use
Each clinically relevant capability should have a defined intended purpose, intended users, intended population, relevant care setting, expected inputs, output type, known limitations, and appropriate use boundaries before being relied upon for a regulated or patient-care function.
11. Non-Autonomous Use Principle
Unless a capability has been specifically developed, evaluated, authorized, and governed for a permitted autonomous function, xBxBio should not be used as an autonomous replacement for clinician judgment, diagnosis, treatment selection, emergency response, or patient-management decisions.
12. Clinician Review of Outputs
Clinically relevant outputs should be presented so that qualified users can review the information, context, evidence, limitations, and other available factors needed to make their own professional assessment rather than relying uncritically on a software output.
13. Patient-Specific Context
Clinical interpretation should account for the individual patient's relevant history, current condition, medications, procedures, devices, comorbidities, demographics where appropriate, longitudinal trajectory, and other available context. A technically correct observation may still be clinically misleading when interpreted outside the patient's context.
14. Source Evidence Visibility
Where appropriate, users should be able to identify the source evidence, source type, acquisition time, relevant provenance, or other context supporting a clinically meaningful output. Derived information should not be presented as though it were indistinguishable from directly observed source data.
15. Uncertainty Communication
Uncertainty, ambiguity, missing information, data-quality limitations, conflicts, and conditions that may reduce reliability should be communicated in a manner appropriate to the user, intended use, and potential clinical consequence.
16. Benefit-Risk Consideration
Clinical-safety decisions should consider reasonably foreseeable benefits and harms, including harm from incorrect output, omitted output, delayed output, inappropriate confidence, workflow interruption, alert fatigue, misuse, overreliance, or failure to recognize important limitations.
17. Risk Classification
Clinically relevant functions should be assessed according to the potential severity and likelihood of harm, degree of human oversight, reversibility of action, detectability of error, user expertise, use environment, and other factors relevant to the intended function.
18. Hazard Identification
Safety review should identify reasonably foreseeable hazards arising from incorrect data, missing data, wrong-patient association, timing errors, conflicting evidence, inappropriate interpretation, software failure, interface failure, misuse, automation bias, cybersecurity events, or other relevant conditions.
19. Risk Controls
Risk controls should be selected and maintained in proportion to the identified risk. Controls may include limitations on intended use, human review requirements, warnings, data-quality checks, authorization controls, workflow constraints, escalation, verification, monitoring, or other appropriate safeguards.
20. Residual Risk
Residual risk should be evaluated after relevant controls are considered. Where residual risk is not acceptable for an intended use, the function should not be represented, deployed, or relied upon for that use until appropriate action is taken.
21. Safety Evidence
Safety-related claims should be supported by evidence appropriate to the function, development stage, risk, and intended use. Evidence may include requirements, verification, validation, clinical evaluation where applicable, usability evaluation, testing, monitoring, documented limitations, and review records.
22. Data Quality
Clinical and analytical data should be evaluated, as appropriate, for accuracy, completeness, consistency, validity, timeliness, uniqueness, representativeness, provenance, and fitness for intended use.
23. Data Provenance
Clinically important information should preserve appropriate provenance, including relevant source, acquisition, transformation, version, timing, and processing context where needed to support interpretation, review, traceability, or reconciliation.
24. Patient Identity and Association
Controls should reduce the risk that information, studies, signals, documents, or derived outputs are associated with the wrong patient, encounter, episode, study, or longitudinal record. Ambiguous identity or association should be handled conservatively.
25. Temporal Integrity
Clinical interpretation should preserve or appropriately reconstruct timing, sequence, duration, recurrence, and temporal relationships among observations, interventions, procedures, therapies, device events, and outcomes where those relationships affect meaning.
26. Completeness and Missing Data
Missing, unavailable, delayed, filtered, inaccessible, or incomplete information should not be silently treated as normal or negative evidence when that assumption could materially alter clinical interpretation.
27. Source and Device Status
Where relevant, information about source status, device status, acquisition quality, connectivity, synchronization, calibration state, or other factors that can affect data suitability should be considered before clinically meaningful use.
28. Data Freshness
Clinically relevant information should be evaluated for timeliness. Older information may remain important but should not be represented as current when the age of the information could affect interpretation or action.
29. Conflicting Evidence
When clinically relevant sources disagree, the conflict should be preserved or surfaced rather than silently resolved in a
manner that could create false certainty. Resolution should use appropriate human review and source context.
30. Normalization and Harmonization
Data normalization and harmonization should preserve clinically meaningful distinctions and should not convert unlike concepts, units, measurements, or observations into an apparently equivalent form without appropriate controls.
31. Clinical Terminology
Clinical terminology, coding, units, reference ranges, labels, and semantic mappings should be used and maintained in a way that supports accurate interpretation and avoids avoidable ambiguity.
32. Imaging Information
Imaging-derived information should retain appropriate study, acquisition, modality, timing, and interpretation context. Derived measurements or findings should not be represented as replacing qualified image review where such review is required.
33. Waveforms and ECG Information
Waveform and ECG information should preserve appropriate signal, lead, timing, sampling, artifact, quality, and acquisition context where those factors can affect interpretation. Automated findings should remain subject to appropriate review.
34. Laboratory Information
Laboratory information should preserve relevant specimen, collection, result, units, reference range, status, timing, and source context where available and clinically important. Critical or unexpected results require appropriate workflow and human review.
35. Medication and Therapy Information
Medication and therapy information should be interpreted with relevant dose, route, schedule, timing, status, indication, interactions, allergies, contraindications, and patient context where available. Software output should not independently authorize medication changes unless specifically permitted and governed.
36. Genetic and Genomic Information
Genetic and genomic information should be used with appropriate consideration of test validity, interpretation limits, ancestry or population context where relevant, phenotype, family history, consent, privacy, and qualified professional review.
37. Device, Wearable, and Remote Data
Data from medical devices, wearables, home monitoring, implantable devices, or remote sensors should be considered in light of device status, intended purpose, acquisition conditions, signal quality, patient association, connectivity, and other factors that can affect clinical meaning.
38. Patient-Reported Information
Patient-reported symptoms, measurements, observations, preferences, or other information may provide important context but should be distinguished from clinician-observed, device-generated, or laboratory-derived information where that distinction matters.
39. Virtual Heart Functions
Patient-specific Virtual Heart functions are intended to support governed representation, analysis, research, longitudinal comparison, and clinician-guided assessment. A Virtual Heart should not be represented as an infallible replica of a patient or as an autonomous authority for diagnosis, treatment, or prognosis.
40. AI-Enabled Functionality
AI-enabled functionality should be subject to appropriate governance across design, development, evaluation, deployment, monitoring, modification, and retirement. Human oversight, intended-use controls, evidence, uncertainty, and safety considerations should be proportionate to clinical risk.
41. Model Output Labeling
AI- or model-derived outputs should be labeled or presented in a manner that reduces the risk that users confuse predictions, estimates, classifications, reconstructions, inferences, or recommendations with directly observed clinical facts.
42. Predictions and Forecasts
Predictions and forecasts should communicate relevant time horizon, uncertainty, assumptions, data limitations, and intended use. Forecasts should not be represented as guaranteed outcomes.
43. Recommendations and Suggestions
Recommendations, suggestions, prioritizations, or other decision-support outputs should be framed as support for qualified human review unless a different role has been specifically authorized and governed.
44. Confidence and Uncertainty
Confidence measures, uncertainty indicators, probability estimates, or related values should be used carefully and should not imply a level of certainty that is unsupported by the underlying evidence or evaluation.
45. Explainability and Reviewability
Clinically relevant outputs should provide a level of explanation, evidence visibility, or reviewability appropriate to the intended user and risk. The form of explanation may vary by function and should not be treated as a substitute for validation or clinical judgment.
46. Automation Bias
Design, labeling, training, and workflow should seek to reduce inappropriate deference to automated outputs. Users should remain able to question, reject, override, or escalate clinically relevant outputs when appropriate.
47. Human Factors and Usability
Clinical interfaces should consider human factors, usability, cognitive workload, visibility of important information, error prevention, error recovery, and the foreseeable conditions under which users may interact with the system.
48. Alert Fatigue
Alerts and notifications should be governed to reduce unnecessary burden, duplication, excessive sensitivity, inappropriate persistence, or other patterns that can contribute to alert fatigue and reduced attention to clinically meaningful events.
49. Critical Alerts and Time-Sensitive Information
Where a function is intended to support time-sensitive or critical information, delivery, acknowledgement, escalation, failure handling, and fallback expectations should be defined and evaluated according to the intended use and applicable organizational requirements.
50. Escalation and Closed-Loop Follow-Up
Clinically important alerts, tasks, findings, or unresolved actions should support appropriate assignment, acknowledgement, escalation, reassignment, and closure where the intended workflow requires closed-loop follow-up.
51. False Positive and False Negative Risk
Safety evaluation should consider the consequences of both false positive and false negative outputs, including unnecessary testing or intervention, missed disease, delayed care, user desensitization, anxiety, and inappropriate reassurance.
52. Abnormal and Critical Result Handling
Abnormal, unexpected, critical, or potentially urgent information should be handled according to the intended workflow, source system responsibilities, applicable clinical policies, and human review requirements. Presentation alone should not be assumed to complete a clinical communication obligation.
53. Emergency and Urgent-Care Boundary
Unless specifically developed, authorized, and deployed for an emergency function, xBxBio should not be relied upon as the sole means of emergency assessment, emergency communication, emergency dispatch, or urgent clinical response.
54. Clinical Workflow Integration
Clinical functionality should account for the surrounding workflow, including how information is entered, reviewed, acknowledged, acted upon, documented, transferred, and reconciled. Safety depends on workflow as well as software behavior.
55. User Roles and Authorization
Access to clinically relevant functions should be appropriate to user role, responsibility, training, contractual scope, and organizational authorization. Visibility of information does not itself confer authority to interpret or act on it.
56. Training and Competence
Users should receive information, training, instructions, or other support appropriate to the complexity, risk, and intended use of the functionality they are expected to use.
57. Supervision and Escalation
Organizations should define appropriate supervision and escalation pathways for users who encounter uncertain, conflicting, unexpected, or potentially unsafe outputs, particularly where the user does not have authority to make the required clinical decision.
58. Use Outside Intended Context
Clinically relevant functionality should not be assumed safe or valid when used outside its evaluated population, care
setting, workflow, data environment, disease context, modality, or other intended-use boundaries.
59. Overrides and Professional Disagreement
Qualified users should be able to document or act on professional disagreement with clinically relevant software output where appropriate. Override behavior
60. Clinical Documentation
Where clinically relevant outputs or actions become part of a patient-care workflow, documentation expectations should be defined so that important decisions, source information, review, overrides, limitations, and follow-up can be understood as appropriate.
61. Auditability and Traceability
Appropriate records should support reconstruction of clinically important events, including relevant user actions, data versions, output versions, acknowledgements, overrides, configuration state, and timing where required for safety, quality, investigation, or regulatory purposes.
62. Change Management
Changes that can affect clinical behavior, safety, interpretation, data meaning, workflow, user interaction, or performance should be evaluated under appropriate change control before release or use.
63. Software Updates
Software updates should be assessed for potential effects on clinically relevant behavior, compatibility, workflow, data interpretation, safety controls, and previously established evidence.
64. Model Changes
Changes to AI or analytical models that can affect clinically relevant outputs should be evaluated proportionately before use, including consideration of performance, limitations, data compatibility, monitoring, and intended-use impact.
65. Data and Terminology Changes
Changes to data definitions, reference data, units, terminology, mappings, coding systems, normal ranges, or other semantic elements should be assessed for their potential to change clinical meaning or system behavior.
66. Configuration Changes
Configuration changes that can affect clinical display, alerts, thresholds established by authorized users, routing, workflow, permissions, or other safety-relevant behavior should be governed and reviewed appropriately.
67. Interface Changes
Changes to interfaces, source systems, message formats, device connections, or data exchange should be evaluated for effects on identity, timing, completeness, units, semantics, provenance, and other clinically relevant characteristics.
68. Third-Party Changes
Changes in third-party services, models, devices, software, terminology, infrastructure, or data sources should be assessed for potential effects on intended function, safety, availability, performance, and data interpretation.
69. Pre-deployment Evaluation
Clinically relevant capabilities should undergo evaluation appropriate to their intended use, risk, development stage, user population, data environment, and deployment context before they are relied upon in a patient-care workflow.
70. Verification and Validation
Verification and validation activities should provide evidence that applicable requirements are implemented and that the system performs as intended within defined conditions and limitations. Technical verification should not be treated as equivalent to clinical validation when clinical validation is required.
71. Performance Assessment
Performance assessment should use measures appropriate to the function and clinical consequence. A single aggregate metric may be insufficient to characterize safety or usefulness across different populations, conditions, sites, or workflows.
72. Representative Evaluation
Evaluation data should be reasonably relevant to the intended population, disease states, sites, devices, modalities, workflows, and operating conditions. Limitations in representativeness should be identified and considered.
73. Subgroup Performance
Where clinically relevant and feasible, evaluation should examine whether performance differs materially across patient subgroups, settings, data sources, or other factors that could affect safe and equitable use.
74. Bias and Fairness
Clinical-safety governance should consider reasonably foreseeable bias, disparate performance, inappropriate exclusion, and inequitable impact while recognizing that appropriate fairness measures depend on the use case, population, outcome, and clinical context.
75. Calibration and Reliability
Where probability or risk estimates are presented, evaluation should consider whether those estimates are appropriately calibrated for the intended use and whether changes in population, prevalence, site, or workflow can affect reliability.
76. Robustness
Clinically relevant functions should be evaluated, as appropriate, for reasonably foreseeable variations in data quality, missingness, artifacts, device differences, interface conditions, connectivity, workflow conditions, and other factors that may affect performance.
77. Performance Drift
Where performance can change over time because of data, population, workflow, model, device, software, or environmental changes, appropriate monitoring and review should be used to identify clinically meaningful drift.
78. External Validity
Evidence generated in one site, population, device environment, workflow, or research setting should not automatically be assumed to establish safe performance in materially different settings.
79. Site-Specific Assessment
Healthcare organizations may need to assess local workflow, population, interfaces, devices, staffing, policies, data quality, and other local conditions before relying on clinically relevant functionality.
80. Prospective and Real-World Monitoring
Where clinically appropriate, post-deployment monitoring should evaluate safety-related performance, unexpected behavior, user feedback, workflow effects, incidents, data changes, and other evidence that may affect continued suitability.
81. Safety Incident Detection
xBxBio should maintain mechanisms appropriate to its role and development stage for identifying, receiving, triaging, documenting, and escalating suspected safety-related events or potentially harmful system behavior.
82. Safety Incident Reporting
Safety-related events should be reported internally and, where required, to customers, healthcare organizations, authorities, or other responsible parties in accordance with applicable obligations, contractual roles, and documented procedures.
83. Complaint Handling
Complaints relating to clinically relevant functionality should be documented, assessed, investigated, and trended as appropriate to determine whether they indicate a safety, quality, usability, performance, security, or regulatory issue.
84. Adverse Event Reporting
Where xBxBio has an applicable legal or regulatory obligation relating to adverse events, serious incidents, or similar reportable events, those obligations should be addressed through the appropriate quality and regulatory processes. This public policy does not define jurisdiction-specific reporting thresholds.
85. Corrective and Preventive Action
Safety-related findings should support corrective or preventive action where appropriate. Actions should address the identified issue, underlying cause, affected scope, risk, verification of effectiveness, and need for broader review.
86. Root Cause and Post-Event Review
Material clinical-safety events should be reviewed to understand contributing technical, workflow, human, data, organizational, or external factors. Review should avoid assuming that a visible user action is the sole cause without examining the broader system context.
87. Cybersecurity and Clinical Safety
Cybersecurity events can create clinical-safety risks through loss of availability, integrity, confidentiality, identity assurance, device communication, or trustworthy information. Safety and security governance should therefore be coordinated where an event can affect patient care.
88. Privacy and Clinical Safety
Privacy controls should support appropriate clinical access while reducing unauthorized use or disclosure. Safety and privacy decisions should consider both the harm from inappropriate exposure and the harm that can arise when authorized clinicians cannot access necessary information.
89. Business Continuity and Clinical Safety
Business continuity and disaster recovery should account for patient-care impact, clinical workflow dependencies, data integrity, communication, degraded-mode operation, recovery priorities, and post-recovery reconciliation where clinically relevant.
90. Downtime and Degraded Mode
Clinically relevant functions should have appropriate expectations for planned downtime, unplanned downtime, partial availability, delayed data, degraded performance, communication failure, or other conditions in which normal operation is unavailable.
91. Recovery and Reconciliation
After interruption or recovery, clinically important information should be reconciled as appropriate to reduce loss, duplication, misordering, wrong-patient association, inconsistent state, or incorrect interpretation of events that occurred during the disruption.
92. Third-Party and Supplier Safety
Third-party products and services that can materially affect clinically relevant functionality should be evaluated and governed according to their role, risk, data access, performance impact, availability, change behavior, and contractual responsibilities.
93. Interoperability Safety
Interoperability should preserve patient identity, semantic meaning, units, timing, status, provenance, completeness, and other clinically important context. Successful message transmission alone does not establish that exchanged information is clinically correct or fit for use.
94. Translation and Multilingual Use
Translated text, speech, labels, instructions, or patient-facing communication should be treated as clinically relevant when translation can affect meaning or action. Translation limitations, ambiguity, dialect, terminology, and need for qualified interpretation should be considered.
95. Accessibility and Inclusive Use
User interfaces and communications should support accessibility and inclusive use to the extent appropriate to the intended users and setting. Accessibility should not be treated as separate from safety when inability to perceive, understand, or operate a function could affect clinical outcomes.
96. Telemedicine and Remote Use
Remote and telemedicine workflows should consider limitations arising from connectivity, data latency, camera or audio quality, device availability, patient location, emergency response, identity, consent, and the reduced ability to perform direct physical examination.
97. Patient Communication and Transparency
Where patients or caregivers receive clinically relevant information from xBxBio, communications should distinguish informational or decision-support content from professional medical advice and should provide appropriate direction for questions, urgent concerns, or follow-up.
98. Research and Investigational Use
Research, investigational, demonstration, prototype, or development-stage functionality should be clearly distinguished from functionality authorized for routine clinical use. Research outputs should not be represented as established clinical conclusions merely because they are patient-specific or technically sophisticated.
99. Regulatory Status and Public Claims
xBxBio is a research-stage, pre-commercial development platform. Public descriptions of clinical functionality should not imply regulatory clearance, approval, certification, clinical validation, or authorization that has not actually been obtained for the specific function, intended use, and jurisdiction.
100. Public Information Boundary
This public policy describes principles, responsibilities, safety expectations, and governance boundaries. It is not intended to disclose confidential technical implementation information, security-sensitive information, customer-specific information, or other nonpublic development documentation.
101. Global Legal, Regulatory, and Standards Alignment
This policy is intended to operate alongside applicable laws, regulations, guidance, contractual obligations, quality-system requirements, and recognized standards in the jurisdictions and contexts in which xBxBio lawfully operates. Depending on intended use and jurisdiction, relevant frameworks may include U.S. FDA medical-device and clinical decision-support requirements and guidance; HIPAA and related U.S. privacy and security obligations; EU medical-device, AI, and data-protection requirements; UK medical-device and data-protection requirements; Canadian medical-device and privacy requirements; Japanese medical-device and privacy requirements; and recognized risk-management, software-lifecycle, usability, quality, security, and data-governance standards. Applicability depends on the specific product, role, intended use, deployment, customer, and jurisdiction.
102. Country and Jurisdiction Applicability
Where national or regional requirements differ, the applicable legal and regulatory requirements for the relevant activity and jurisdiction should govern. A country or territory does not need to be individually named in this public policy for applicable obligations or the xBxBio safety baseline to apply.
103. Records and Document Control
Policies, plans, requirements, safety assessments, evaluation records, incidents, complaints, changes, approvals, exceptions, training records, and corrective actions should be maintained under document and record controls appropriate to their purpose, sensitivity, retention requirement, and regulatory relevance.
104. Policy Review
This policy should be reviewed periodically and following significant changes in xBxBio clinical functions, AI-enabled capabilities, intended uses, deployment models, patient populations, interfaces, regulations, standards, safety evidence, material incidents, or organizational responsibilities.
105. Global Protection Statement
No country, territory, customer configuration, deployment model, facility, technical environment, interface, vendor, model, or contractual arrangement is intended to eliminate xBxBio's fundamental requirements for patient protection, human accountability, authorized access, information integrity, provenance, quality, privacy, security, responsible AI use, and appropriate clinical-safety governance. A country or territory does not need to be individually named in this public policy for the global baseline to apply where xBxBio lawfully conducts relevant activities.
END OF XBXBIO CLINICAL SAFETY & HUMAN OVERSIGHT POLICY