Medical Device Skills skills

Define structure and content for test plans, protocols, and reports that support regulatory submissions and internal verification.

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.

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

Implement safe USB device connectivity: class selection, enumeration handling, data validation, electrical and safety considerations.

Establish a root of trust and verify firmware integrity/authenticity from reset through handoff, including anti-rollback and recovery.

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

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.

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.

Apply defensive coding techniques to prevent, detect, and safely handle abnormal conditions in safety-relevant software.

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.

Define controlled release process for medical device software: versioning, branching, verification, approvals, documentation, and post-release monitoring.

Identify and handle PHI in software to enforce minimum necessary use, encryption, access control, and retention/deletion policies.

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

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

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.

Enable safe and standards-aligned interoperability: HL7 FHIR/IHE profiles, data formats, terminology mapping, and API design for medical data exchange.

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

Guide selection and use of cryptography for medical devices: algorithms, key derivation, data at rest/in transit, library choice, and FIPS considerations.

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

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

Ensure OTA updates are authenticated, integrity-checked, atomic, and safely recoverable, with regulatory considerations for software changes.

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.

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.

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.