Software-Driven Devices: Cybersecurity and Patient Data Documentation in the UAE

1. Key takeaways

Medical devices containing software must pass two gates in the UAE: the first is complete insert and labelling information under subparagraph (g) of Article 6(1), and the second is the constraint of Federal Law No. 2 of 2019 on the Use of Information and Communication Technology in the Health Field on the processing of patient data. Our judgment is that rejections of software products rarely stem from the code itself; they stem from documentation that cannot answer three questions — how software versions are identified, how security updates are delivered, and where patient data is stored. The answers to these three questions must appear in both the submission file and the labelling.

• Software-containing devices face two gates: Article 6(1)(g) labelling duties and Federal Law No. 2 of 2019.
• Rejections rarely stem from the code; they stem from documentation that cannot answer three questions.
• The three questions are version identification, security update delivery, and patient data storage location.
• Version naming rules and the security update process deserve their own dedicated sections.
• Obligations under Federal Law No. 2 of 2019 run in parallel with device compliance and cannot be absorbed by it.
• Version naming rules should be matched across the application form, the label, and the software interface.
• The patient data flow statement is submitted as a separate volume from the device technical documentation.
• Cross-border transfer conditions should be confirmed in writing with the competent authority while the Executive Regulations remain incomplete.
• Safety notices in the electronic insert or the software interface must match the Arabic label text.

2. Legal basis

The regulatory basis combines Federal Law No. 2 of 2019 on health-sector ICT with subparagraphs of Article 6(1) of Federal Decree-Law No. 38 of 2024. The table below reproduces the instruments cited in the source material and their key points.

3. Expert insights

Insight 1: The role of the software lifecycle documentation is traceability, not bulk. Our judgment is that EDE review needs to see a closed loop from requirements through design, verification, release, and maintenance, and in particular how version changes are controlled. In terms of organization, presenting the version naming rules and the security update process in dedicated sections is more effective than attaching the entire development process document unchanged. Within the 45 working days review timeline, this directly affects whether the submission passes on the first attempt.

Insight 2: Cybersecurity evidence should reach the level of how updates are delivered. Software products will inevitably be updated during the 5 years of validity; if the update mechanism is not explained at submission, the change questions under Article 15 may later be triggered. Our recommendation is to distinguish explicitly in the submission between defect fixes that do not affect safety and effectiveness and functional changes that require reassessment, and to state the handling path for each.

Insight 3: Federal Law No. 2 of 2019 imposes parallel obligations that device compliance cannot cover. As long as the product processes patient data, it falls within the scope of that law at the same time. Our practice is to issue a separate data flow statement covering the data storage location, cross-border transfer situations, and access control measures, submitted as a separate volume from the device technical documentation so reviewers with different mandates can use each independently. The Executive Regulations have not all been issued, and the specific conditions for cross-border transfer should be confirmed in writing with the competent authority.

4. Practical recommendations

• Organize the software lifecycle documentation in five stages — requirements, design, verification, release, and maintenance — with the version naming rules in a dedicated section.
• Explain in the submission file the security update delivery mechanism and the way users are notified.
• Distinguish explicitly between defect fixes and functional changes, and state the corresponding change handling path for each.
• Issue a separate patient data flow statement recording the storage location, cross-border transfer situations, and access control measures.
• Keep the safety notices in the electronic insert or the software interface consistent with the Arabic label text.
• For Executive Regulations reserved matters such as cross-border data transfer, obtain written confirmation from EDE and the competent authority rather than presuming from industry practice.

5. Verification checklist

• □ The software lifecycle documentation covers the five stages of requirements, design, verification, release, and maintenance
• □ The software version naming rules are documented and can be matched across the application form, the label, and the software interface
• □ The cybersecurity update delivery mechanism and the user notification method are stated in writing
• □ The patient data flow statement forms a separate volume, containing the storage location and cross-border transfer situations
• □ The obligations under Federal Law No. 2 of 2019 have been mapped separately from the Article 6 obligations, with no omissions
• □ The criteria for judging defect fixes versus functional changes and their handling paths are clearly defined

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the United Arab Emirates. Our team prepares MOHAP-compliant dossiers, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com