aminalam/meddev-agent-skills

Provide implementation guidance for electronic records/signatures (ER/ES) compliance: access control, audit trails, data integrity, and validation expectations in medical device software and supporting tools. Use when working on 21 cfr part 11 in medical device software.

Define governance for AI/LLM-assisted software development (e.g., Cursor, Copilot, Claude): human review expectations, evidence that generated code is covered by requirements-based tests, tool validation for GxP-adjacent workflows, and alignment with Computer Software Assurance (CSA) principles (risk-based, critical thinking) without replacing your SOPs. Use when working on ai assisted development governance in medical device software.

Address machine learning inside the regulated product (not LLM coding assistants): Good Machine Learning Practice (GMLP), training/validation data integrity, Predetermined Change Control Plans (PCCP) where applicable, drift monitoring, and linking models to ISO 14971 and software lifecycle controls. Use when working on ai ml medical device software in medical device software.

Define what and how to log for medical devices: security/safety events, integrity, protection, and retention of logs for compliance and forensics. Use when working on audit logging in medical device software.

Define secure user/device authentication, session management, and RBAC suitable for medical device risk profiles. Use when working on authentication in medical device software.

Define how to automate tests (unit, integration, system/HIL where feasible) in CI/CD pipelines for medical devices with gating and evidence capture. Use when working on automated testing in medical device software.

Guide secure, reliable BLE implementation for medical devices handling PHI/therapy control: services, pairing/bonding, LE Secure Connections, privacy, and performance. Use when working on ble medical in medical device software.

Define controlled change-request workflow for software: impact analysis, approvals, verification scope, and regulatory submission flags. Configuration identification and baselines are in DOC-SCM (IEC 62304 Clause 8.1, 8.3); approved implementation and re-verification align with 8.2. Use when working on change control in medical device software.

Provide conventions for code comments that support traceability to requirements, risks, and tests, while maintaining clarity and brevity. Use when working on code comments in medical device software.

Measure and enforce coverage appropriate to safety class: statement/branch and MC/DC where applicable, with documented exclusions. Use when working on code coverage in medical device software.

Ensure integrity of data in storage and transmission using checksums/CRCs/ECC, validation, and redundancy where needed for medical devices. Use when working on data integrity in medical device software.

Apply defensive coding techniques to prevent, detect, and safely handle abnormal conditions in safety-relevant software. Use when working on defensive design in medical device software.

Guide creation and maintenance of Software Architecture (SAD) and Design Descriptions (SDD) that support safety, traceability, and compliance. Use when working on design docs in medical device software.

Detect runtime defects (memory, concurrency, timing, performance, power) via dynamic tools and instrumentation in medical device software. Use when working on dynamic analysis in medical device software.

Define C coding practices aligned with MISRA C and medical device safety needs: type safety, control flow, memory management, interrupts, and static analysis. Use when working on embedded c in medical device software.

Define a constrained C++ subset suitable for medical device firmware, aligned to MISRA C++ guidance: safe types, RAII, limited dynamic features, and predictable behavior. Use when working on embedded cpp in medical device software.

Guide selection and use of cryptography for medical devices: algorithms, key derivation, data at rest/in transit, library choice, and FIPS considerations. Use when working on encryption in medical device software.

Provide actionable guidance for software under EU MDR, focusing on classification (Rule 11), technical documentation expectations, UDI for software, PMS/PMCF needs, and alignment with MDCG guidance. Use when working on eu mdr in medical device software.

Provide patterns for detecting, containing, and recovering from faults in medical device software, scaled to safety class. Use when working on fault tolerance in medical device software.

Map 21 CFR Part 820 Subpart C — Design Controls to software lifecycle work: design planning, inputs, outputs, review, verification, validation, transfer, and DHF/DMR links, including how software validation (intended use / risk controls) complements verification (requirements and specs). Includes a concise ISO 13485:2016 slice where it overlaps QMS expectations for design and risk (interpretation; align with your notified-body MDSAP scope for EU). Use when working on fda 820 design controls in medical device software.

Guide preparation of FDA premarket submission software documentation (510(k), De Novo, PMA), including documentation depth determination, required documents, cybersecurity, SBOM, interoperability, and post-market commitments. Use when working on fda premarket in medical device software.

Uncover robustness and security issues by fuzzing inputs/protocols relevant to medical devices (parsers, IPC, network/BLE/USB). Use when working on fuzz testing in medical device software.

Provide patterns for HAL design that enable testability, portability, and safety: clear interfaces, separation from application logic, and mockability. Use when working on hardware abstraction in medical device software.

Validate software with real or representative hardware, sensors, actuators, and timing, to uncover integration and safety issues not visible in simulation. Use when working on hardware in loop in medical device software.

Provide actionable guidance to implement IEC 62304:2006+A1:2015 lifecycle processes—development, maintenance, software risk management, configuration management, and problem resolution—with rigor scaled by safety class (A/B/C). This hub skill indexes clause obligations; load child skills for depth. Use when working on iec 62304 in medical device software.

Guide use of the legacy software pathway (IEC 62304:2006+A1:2015, 4.4) when device software was legally marketed before full lifecycle evidence existed—balancing continued use with gap analysis, risk management, and targeted closure activities instead of re-running all of Clauses 5–9 from scratch. Use when working on iec 62304 legacy software in medical device software.

Guide implementation of the software-specific risk management process (IEC 62304:2006+A1:2015, Clause 7) alongside ISO 14971:2019—identifying how software items contribute to hazardous situations, defining and verifying software risk controls, and re-analysing risk when software changes. Use when working on iec 62304 software risk in medical device software.

Implement IEC 62366-1 usability engineering for software: identify use-related risks, iterate UI with formative evaluation, confirm risk controls with summative testing, and trace results to ISO 14971 and design/verification records. Use when working on iec 62366 usability in medical device software.

Apply IEC 62443 concepts (secure development lifecycle, component requirements, security levels) to networked medical devices, ensuring threat-aware design, implementation, and verification of cybersecurity controls. Use when working on iec 62443 in medical device software.

Provide concise, high-value inline documentation practices (comments and short docblocks) that improve safety, maintainability, and traceability without cluttering code. Use when working on inline docs in medical device software.

Validate interactions between software components and hardware interfaces, ensuring interfaces, protocols, and data flows behave correctly in realistic configurations. Use when working on integration testing in medical device software.

Enable safe and standards-aligned interoperability: HL7 FHIR/IHE profiles, data formats, terminology mapping, and API design for medical data exchange. Use when working on interoperability in medical device software.

Define safe interrupt design: short ISRs, deferred work, priority assignment, critical section management, and testing strategies. Use when working on interrupt handling in medical device software.

Integrate ISO 14971:2019 device risk management into software development: hazard identification, risk evaluation, control implementation, verification, and residual risk documentation. For IEC 62304 Clause 7 software-specific risk activities, also load REG-IEC62304-SWRM. Use when working on iso 14971 in medical device software.

Define generation, storage, rotation, revocation, and provisioning of cryptographic keys for medical devices, supporting secure boot, OTA, and comms. Use when working on key management in medical device software.

Ensure deterministic and safe memory usage: static allocation, pools, stack sizing, MPU usage, and corruption detection for medical device firmware. Use when working on memory management in medical device software.

Identify and handle PHI in software to enforce minimum necessary use, encryption, access control, and retention/deletion policies. Use when working on phi handling in medical device software.

Define regulated-friendly CI/CD pipelines with compliance checks, artifact management, and auditability for medical device software. Use when working on pipeline design in medical device software.

Connect post-market processes to software: complaints, vigilance / MDR reporting, recalls and field corrections, cybersecurity coordinated disclosure touchpoints, and labeling / IFU (including on-device strings, UDI display, and versioned patient/clinician instructions) so maintenance (IEC 62304 §6) and QMS CAPA stay coherent. Use when working on postmarket labeling ifu in medical device software.

Define safe power management patterns: sleep modes, wake sources, power budget, battery monitoring, graceful shutdown, and data preservation. Use when working on power management in medical device software.

Define how to record, investigate, resolve, and trend software problems (defects, anomalies, complaints) per IEC 62304:2006+A1:2015, Clause 9—linking safety evaluation, change control, verification closure, and test documentation. Use when working on problem resolution in medical device software.

Define controlled release process for medical device software: versioning, branching, verification, approvals, documentation, and post-release monitoring. Use when working on release management in medical device software.

Provide safe RTOS usage patterns: task design, priorities, IPC, deadlines, priority inversion avoidance, and timing analysis for medical devices. Use when working on rtos patterns in medical device software.

Define how IEC 62304:2006+A1:2015 safety classification (Class A/B/C per 4.3) influences architecture, segregation, documentation, and testing—ensuring activity rigor scales with harm severity and software items are decomposed with defensible class assignments. Use when working on safety classification in medical device software.

Guide Software as a Medical Device (SaMD) and software in devices for clinical evaluation expectations: intended use, SaMD category (IMDRF framework), evidence of analytical and clinical validity where applicable, and alignment with EU MDR Annex XIV clinical evaluation and FDA premarket clinical/benefit-risk expectations for software-driven diagnostics and monitoring. Use when working on samd clinical evaluation in medical device software.

Establish a root of trust and verify firmware integrity/authenticity from reset through handoff, including anti-rollback and recovery. Use when working on secure boot in medical device software.

Ensure OTA updates are authenticated, integrity-checked, atomic, and safely recoverable, with regulatory considerations for software changes. Use when working on secure ota in medical device software.

Define architectural partitioning to contain failures, simplify verification, and align safety classes with appropriate isolation. Use when working on separation of concerns in medical device software.

Implement identification, change control, and status accounting for software configuration items per IEC 62304:2006+A1:2015, Clause 8—ensuring reproducible baselines, controlled SOUP records, and retrievable history separate from change-request workflow details in DOC-CHANGE-CONTROL. Use when working on software configuration management in medical device software.

Guide post-release software maintenance per IEC 62304:2006+A1:2015, Clause 6—planning feedback handling, evaluating problems and changes, re-applying development activities when needed, and re-releasing under the same controls as initial release (5.8). Use when working on software maintenance in medical device software.

Guide creation, verification, and maintenance of software system requirements derived from system needs (IEC 62304:2006+A1:2015, 5.2)—with content appropriate to the device, risk controls embedded for Class B/C, and evidence that requirements are testable and traceable. Use when working on software requirements in medical device software.

Define explicit, testable state machines with safe states, controlled transitions, and error handling suited to medical device safety classes. Use when working on state machines in medical device software.

Use static analysis (SAST) to detect defects and nonconformities (MISRA, CERT) early, with triage and traceability appropriate to safety class. Use when working on static analysis in medical device software.

Define structure and content for test plans, protocols, and reports that support regulatory submissions and internal verification. Use when working on test docs in medical device software.

Identify, prioritize, and mitigate security threats for medical devices, integrating with risk management and informing control selection. Use when working on threat modeling in medical device software.

Ensure bidirectional traceability between requirements, hazards/risks, design, code, tests, and anomalies for medical device software. Use when working on traceability in medical device software.

Establish patterns for unit tests that verify software units against requirements with safety-class-appropriate rigor. Use when working on unit testing in medical device software.

Implement safe USB device connectivity: class selection, enumeration handling, data validation, electrical and safety considerations. Use when working on usb medical in medical device software.

Secure and robust WiFi connectivity for medical devices: WPA3/enterprise auth, certificate management, coexistence, resilience, and hospital network integration. Use when working on wifi medical in medical device software.