Medical Device Skills skills

Define what and how to log for medical devices: security/safety events, integrity, protection, and retention of logs for compliance and forensics.

Guide creation and maintenance of Software Architecture (SAD) and Design Descriptions (SDD) that support safety, traceability, and compliance.

Ensure integrity of data in storage and transmission using checksums/CRCs/ECC, validation, and redundancy where needed for medical devices.

Establish patterns for unit tests that verify software units against requirements with safety-class-appropriate rigor.

Define architectural partitioning to contain failures, simplify verification, and align safety classes with appropriate isolation.

Secure and robust WiFi connectivity for medical devices: WPA3/enterprise auth, certificate management, coexistence, resilience, and hospital network integration.

Define explicit, testable state machines with safe states, controlled transitions, and error handling suited to medical device safety classes.

Validate interactions between software components and hardware interfaces, ensuring interfaces, protocols, and data flows behave correctly in realistic configurations.

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.

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).

Provide patterns for HAL design that enable testability, portability, and safety: clear interfaces, separation from application logic, and mockability.

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.

Apply defensive coding techniques to prevent, detect, and safely handle abnormal conditions in safety-relevant 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.

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.

Define C coding practices aligned with MISRA C and medical device safety needs: type safety, control flow, memory management, interrupts, and static analysis.

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

Define safe interrupt design: short ISRs, deferred work, priority assignment, critical section management, and testing strategies.

Guide secure, reliable BLE implementation for medical devices handling PHI/therapy control: services, pairing/bonding, LE Secure Connections, privacy, and performance.

Ensure bidirectional traceability between requirements, hazards/risks, design, code, tests, and anomalies for 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.

Define how to automate tests (unit, integration, system/HIL where feasible) in CI/CD pipelines for medical devices with gating and evidence capture.

Provide concise, high-value inline documentation practices (comments and short docblocks) that improve safety, maintainability, and traceability without cluttering code.

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.