Which requirements apply, when software is a medical device and how we classify our own development.
Software in the medical field is subject to very different requirements depending on its intended purpose. If it is used for diagnosis or therapy, it is a medical device under EU Regulation 2017/745 and requires a confor...
Read answerAs soon as the manufacturer designates it for a medical purpose – diagnosis, monitoring, treatment, or alleviation of diseases. Rule 11 of the MDR classifies software that provides decisions for diagnostic or therapeutic...
Read answerHealth data may only be processed under strict conditions according to Article 9 of the GDPR – in practice, usually based on the treatment itself. Encryption, a role and rights concept, comprehensive logging of access, a...
Read answerThrough KIM – Communication in the Medical Sector – the secure email service within the telematics infrastructure. This allows encrypted exchange of medical letters, findings, and billing documents. Additionally, there i...
Read answerFocus on data transfer and retention obligations. Patient data must be fully transferred or remain readable for the entire retention period – typically ten years for treatment documentation. Clarify the export in writing...
Read answerMore than just a privacy policy: a record of processing activities, contracts with all service providers with data access, a roles and rights concept, access logging, a deletion concept, and the obligation of all parties...
Read answerIn principle, yes, under strict conditions: data processing agreement, separate obligation under § 203 StGB, processing preferably within the EU, encryption, and a role concept. For certain areas of statutory health insu...
Read answerThe MDR class is determined not by the technology or distribution method, but by intended purpose and potential impact of erroneous software information. For many medical software products, Rule 11 of Annex VIII is relev...
Read answerISO 14971:2019 requires a documented risk management process throughout the entire product lifecycle: identify hazards, assess risks, implement controls, evaluate residual risks, and incorporate insights from production...
Read answerIEC 62366-1:2015 with Amendment 1:2020 requires a safety-related usability engineering process. Manufacturers must determine the context of use, user groups, critical user actions, and hazard-related usage scenarios, ite...
Read answerThe technical documentation must compile the intended purpose, product description, development, risk controls, and all verification and validation evidence in a traceable manner according to MDR Annex II; Annex III supp...
Read answerThe clinical evaluation is a planned, ongoing process according to Article 61 and Annex XIV of the MDR. For medical software, intended purpose and clinical claims are translated into verifiable endpoints; subsequently, v...
Read answerIEC 62304:2006+A1:2015 structures the development and maintenance of medical software into traceable lifecycle processes. Verification checks step by step whether requirements, architecture, modules, and the integrated s...
Read answerEvery update requires a documented change assessment that considers purpose, MDR qualification and class, risks, clinical evidence, usability, cybersecurity, testing, and UDI impacts. Whether a change is 'significant' de...
Read answerThe MDR requires cybersecurity as part of safety and performance throughout the entire lifecycle. Annex I number 17.2 mandates software development according to the state of the art, incorporating risk management, inform...
Read answerHL7 refers to a family of interoperability standards; FHIR is a modern standard within this family. While HL7 Version 2 often transmits event-driven messages between clinical applications, FHIR represents information as...
Read answerA potential security incident must be immediately technically secured and assessed from a regulatory perspective. For manufacturers, the MDR Article 87 stipulates graduated maximum deadlines: generally 15 calendar days f...
Read answerISO 13485 sets requirements for a quality management system for the development of medical software. This includes documentation of processes, risk management, validation and verification of the software, as well as comp...
Read answerThe purpose of medical software clearly and precisely describes what the software was developed for and what specific functions it fulfills. It should include the intended use, target audience, and medical indications. A...
Read answerA health app is not classified as a medical device if it does not pursue medical purposes or does not have diagnostic, therapeutic, or preventive functions. Apps that merely provide general health information or promote...
Read answerThe CE marking of medical software requires several steps to ensure that the product complies with European directives. First, the software must be classified to determine the relevant requirements. Then, a risk assessme...
Read answerA Notified Body must be involved when medical devices or medical software are classified into higher risk categories. In particular, products of classes IIa, IIb, and III require an assessment by a Notified Body to confi...
Read answerThe UDI (Unique Device Identification) is relevant for medical software classified as a medical device. Manufacturers must create a UDI for their products and register it in the EUDAMED database. EUDAMED serves as a cent...
Read answerPost-Market Surveillance (PMS) for software requires systematic planning to continuously ensure the safety and performance of the product. First, clear objectives and methods for data collection should be defined, includ...
Read answerClinical post-market surveillance for software is required when the software is classified as a medical device and poses potential risks to patients or users. This is particularly true for software used in the diagnosis,...
Read answerThe documentation of deviations, causes, and corrective actions is typically carried out in a structured format that allows for the identification, analysis, and tracking of these elements. First, the deviation is descri...
Read answerIEC 62304 treats open-source components and Software of Unknown Provenance (SOUP) as potential risks in the software lifecycle. Careful risk assessment is required when using such components to ensure the safety and effe...
Read answerIEC 62304 defines three software safety classes: Class A, B, and C, based on the risk posed by the software. Class A includes software whose failure has no negative impact on the safety of the medical device. Class B ref...
Read answerA Software Bill of Materials (SBOM) is essential for medical software to ensure transparency regarding the software components used. It enables better traceability and management of dependencies, which is particularly im...
Read answerOrganizing vulnerability reports and security updates requires a structured approach throughout the entire product lifecycle. First, clear processes for identifying and reporting vulnerabilities should be established. Ne...
Read answerA Data Protection Impact Assessment (DPIA) is required when health software processes personal data that poses a high risk to the rights and freedoms of the affected individuals. This is particularly the case when sensit...
Read answerThe processing of health data is regulated by the General Data Protection Regulation (GDPR). In particular, Article 9 of the GDPR makes it clear that the processing of such data is generally prohibited unless one of the...
Read answerThe design of roles, access rights, and logs for patient data is crucial for data protection and data security. Clear roles should be defined to regulate access to patient data, allowing only authorized individuals to ga...
Read answerMedical software should use strong encryption methods for both data storage and transmission. AES (Advanced Encryption Standard) with a key length of at least 256 bits is often recommended for data storage. For transmiss...
Read answerThe restart times of backup and emergency concepts in clinical operations are crucial for maintaining patient care. These times vary depending on the type of systems and the specific requirements of the facility. General...
Read answerThe validation of a DICOM interface involves several steps to ensure that the implementation complies with DICOM standards. First, a conformity check against the DICOM specifications should be performed, followed by test...
Read answerThe validation of FHIR interfaces against profiles and terminologies occurs in several steps. First, the conformity of the interface with the defined FHIR profiles is checked, which specify requirements for data structur...
Read answerThe requirements for AI functions in medical software are diverse and encompass both technical and regulatory aspects. Key requirements include ensuring the safety, effectiveness, and traceability of AI algorithms. Addit...
Read answerMedical software can be approved as a Digital Health Application (DiGA) if it meets the requirements of German health law. This includes demonstrating the medical purpose, safety, and effectiveness of the application. Ad...
Read answerThe registration of medical software with Swissmedic occurs in several steps. First, the software must be classified into the correct risk class, which is crucial for the subsequent registration process. Then, the requir...
Read answerValidating cloud services and external software suppliers in quality management requires a systematic approach. First, a risk assessment must be conducted to identify potential risks. Next, the requirements for the softw...
Read answerTo verify that no patient data is missing or altered after a data migration, several steps are necessary. First, a comprehensive data mapping between the source and target systems should be created. Next, data integrity...
Read answerFree initial consultation - no sales pressure, just clear answers.
