Skip to content

5_monitor.md

Latest commit

 

History

History
165 lines (122 loc) · 9.71 KB

5_monitor.md

File metadata and controls

165 lines (122 loc) · 9.71 KB
hide
navigation

5. Operationalization and Lifecycle Monitoring

5.1 Preparation and Documentation

Comprehensive documentation

Comprehensive documentation bridges the gap between development, deployment, and real-world use. Documentation should be generated both for internal usage (to ensure safe, ethical, and effective implementation within the local care system) and external publishing (to foster transparency, reproducibility, and collaboration).

Some best practices to keep in mind for both internal and external documentation include: (1) generating plain language summaries for accessibility to non-technical stakeholders; (2) ensuring all documentation aligns with FAIR principles (Findable, Accessible, Interoperable, and Reusable)66 when publishing; and (3) including a revision history of any updates and improvements to the AI-solution.

Below are some recommendations for documentation for internal usage and external publishing:

Internal Documentation:

  1. Model Development and Technical Specifications
    1. Model Overview:
      1. Objectives and intended use cases.
      2. Description of the problem the AI addresses.
    2. Model Architecture: 3. Detailed explanation of algorithms, architecture, and training pipeline. 4. Hyperparameters and optimization techniques.
    3. Data Sources and Preprocessing: 5. Description of datasets used for training, validation, and testing. 6. Details on data cleaning, augmentation, and handling missing values. 7. Consider use of Data Labels67
    4. Fairness, Equity and Performance Metrics: 8. Intended equity objective(s) and utilized fairness metric(s) 9. Performance evaluation metrics (e.g., accuracy, precision, recall, AUC-ROC). 10. Comparison with baseline methods.
    5. Ethics and Bias: 11. Description of steps taken to minimize bias and promote fairness. 12. Description of known biases and inequities in AI-Solution.
    6. Versioning: 13. Model version history and updates.
  2. Deployment Documentation 7. System Integration: 14. How the AI integrates with existing healthcare infrastructure (including e.g. what data sources are accessed, who the primary end-users are, etc). 8. Operational Guidelines: 15. Deployment process, runtime environment, and maintenance requirements. 9. Interfaces: 16. User interface guides for clinicians or administrators.
  3. Regulatory and Compliance Documentation 10. Data Privacy and Security: 17. Compliance with regulations like GDPR, HIPAA, or equivalent. 18. Explanation of data storage, access controls, and encryption methods. 11. Risk Management: 19. Identified risks and mitigation strategies.
  4. Monitoring and Post-Deployment Validation 12. Performance Monitoring Plans: 20. Procedures for tracking model performance in real-world settings. 13. Update and Retraining Guidelines: 21. When and how the model should be updated or retrained. 14. Audit Logs: 22. Documentation of decision-making processes for accountability.

External Documentation (For Publishing to Journals or Open Access Repositories):

The TRIPOD+AI68 statement is an excellent resource that should be followed for external publishing of an AI-Solution. As a starting point, we recommend the following sections for inclusion in any external publication:

  1. Research and Model Development
    1. Introduction and Background:
      1. Problem statement, clinical relevance, and literature review.
    2. Methods: 2. Detailed description of the AI development process, including: 1. Model architecture and algorithms. 2. Training pipeline and dataset descriptions. 3. Statistical methods used for validation. 4. Explanation of fairness assessments and steps to mitigate bias
    3. Results: 3. Intended equity objective and utilized fairness metric 4. Evaluation metrics (e.g., accuracy, precision, recall, AUC-ROC), statistical significance tests, and comparative analysis.. 5. Comparison with baseline methods or alternatives. 6. Visualization of results (e.g., confusion matrices, ROC curves).
    4. Discussion: 7. Interpretation of findings, limitations, and implications for clinical practice. 8. Intended users 9. Known limitations
  2. Dataset Documentation (if sharing data) 5. Data Description: 10. Features, data sources, and collection methods. 6. Data Preprocessing Steps: 11. Cleaning, normalization, and other transformations. 7. Data Dictionary: 12. Definitions of variables and labels. 8. Ethical and Legal Considerations: 13. How patient privacy was protected. 14. Any restrictions on dataset usage.
  3. Open Access Repositories 9. Code Repository (e.g., GitHub, GitLab): 15. Source code with comprehensive comments and clear organization. 16. Instructions for reproducing results (e.g., environment setup, dependencies). 10. Model Repository (e.g., Hugging Face, Zenodo): 17. Pre-trained models with detailed usage instructions. 18. Associated metadata for easy reference.
  4. FAQs: 11. Common questions from reviewers, researchers, or practitioners.

5.2. Communication and Education

Modifying trial educational materials

Well-designed educational materials help build confidence, trust and engagement across all stakeholders, enabling a smooth clinical integration of the AI-Solution. During this step the education materials made during the Clinical Trial should be modified for a broader audience. Some recommended additions to the above section on education materials (section 4.3) include:

  1. end-users:
    1. User Manuals and Quick Start Guides:
      1. Expand to explain system functionalities, workflows and common troubleshooting steps.
    2. Clinical Workflow Integration Training: 2. Provide interactive sessions or videos on how to use the AI-Solution.
    3. FAQ and Troubleshooting Tips: 3. Address common concerns and technical issues.
  2. For Organizational Stakeholders (e.g. administrators, IT): 4. Implementation Guides: 4. Highlight infrastructure, security, and resource requirements. 5. Compliance and Governance Briefs: 5. Outline regulatory, ethical, and operational responsibilities.

Communication plan

The communication plan should assure that the team has the following information readily available, complete and free from reporting bias:

  1. Equity objectives
  2. Fairness metrics
  3. Model performance across defined subgroups
  4. Information about non-technical components of AI-solution
  5. Contact information of solution management team
  6. Educational material to avoid automation bias
  7. Educational material on system usage

Communication plans should encompass dissemination of regular reports and audits, patient and end-user educational materials, and adverse event reporting. Plans should also be generated in advance for events such as AI-solution update, AI-solution failure, and AI-solution decommissioning.

5.3. AI-solution Rollout and Monitoring

Regular monitoring and reporting

The metrics that should be monitored and reported on will depend on the final AI-solution. However, it is recommended that the AI-solution monitoring focuses on performance, safety, compliance and operational impact. As examples: (1) model performance and data quality could be monitored by looking at error rates (false positives and false negatives), drift detection (in both data and model performance), and statistical metrics; (2) Clinical outcomes could be monitored by looking at workflow integration and adverse events, such as patient safety issues; (3) Operational metrics, security and privacy can be monitored by looking at uptime and response times, as well as usage metrics, data breaches and access logs; (4) finally, periodic revalidation of the AI-solution may be beneficial using updated data or in the case of a system update that impacts the software and hardware used by the AI-solution.

Utilizing the developed communication plan, regularly report on the AI-Solution’s impact and performance, as determined by audits (section 4.2), feedback from end-users and patients, and regular monitoring metrics. These regular reports should be comprehensive and include disparities in AI-Solution performance, current clinical adoption and impact, as well as any adverse events that have occurred.

5.4. Updating or Decommissioning of AI-solution

If at any point an AI-solution if failing to meet the set objectives and requirements (i.e. fairness and performance metrics are worsening, institutional requirements are no longer being met, or end-users and/or patients are no longer seeing benefit from the solution), the cross-functional team should be consulted. During this consultation there are three possible next steps: Pausing the AI-Solution, Updating the AI-Solution, or Decommissioning the AI-Solution.

Each of these steps will look different depending on the institution and AI-Solution. Broadly speaking, it should be determined what each of these steps would look like from a clinical and regulatory perspective and who should be informed. Additionally, depending on the decided step, the results and/or changes will need to be communicated.