Product requirement specification (PRS)
PRS-001: Generate an interpretative probability distribution of possible ICD categories by analysing images
The device shall analyse dermatological images and produce a ranked interpretative probability distribution across the relevant ICD classes , ensuring that the probabilities sum to 100%. For every class listed, the system must simultaneously generate explainability mechanisms to allow users to supervise its operation, including—but not limited to—pixel-level attention indicators such as heat maps or saliency masks that highlight the image regions most influential to each category.
Stakeholder: User
PRS-002: Measure severity by combining image analysis and user-reported symptoms in scoring systems
The device shall use of each dermatological visible sign detected in an image set:
- the two-dimensional surface-area coverage of detected lesions,
- the absolute count of discrete lesions or manifestations,
- the quantitative grade of the intensity
and user-reported data, such as subjective symptoms and answers to qualitative questions, to compute a validated composite severity indices, such as PASI, SCORAD, IGA, and IHS4 scores. Each score shall include: input components, output range, clinical interpretation band (e.g., mild/moderate/severe). The output may also contain a clinical set of generated images for helping to interpretate the results.
Stakeholder: User
PRS-003: Assess image adequacy on ingestion
Upon ingestion, the device shall automatically evaluate every incoming image against a predefined and version-controlled set of adequacy criteria.
Stakeholder: User
PRS-004: Interface-agnostic input validation and actionable error reporting
Every data element accepted by the device must undergo a centralized, independent validation pipeline to detect missing, out-of-range, or malformed values before further processing. Whenever a validation failure occurs, the system shall surface an actionable error report that at least combines a human-readable message, a unique traceable code, and a concise remediation hint (e.g.,“Invalid JSON syntax—remove trailing comma and ensure keys are double-quoted,” or “Field ‘bodySite’ missing—add string value from defined enumeration.”) to enable quick correction by clinicians or integrators. Error messages presented to end users shall use non-technical language, and avoid Protected Health Information (PHI) exposure.
Stakeholder: User
PRS-005: Expose the device’s functionality through a versioned, network-accessible API
The device shall expose its medical features through a secure, version-controlled API that can be accessed over a network. Each published API version will carry a clear semantic identifier (e.g., v1.0, v2.1) and will remain stable for its designated support window, allowing customers to upgrade on their own schedules without service interruption. The API must maintain deterministic response formats and latency suitable for point-of-care use, with graceful error handling and informative status messages to facilitate rapid troubleshooting.
Stakeholder: User
PRS-006: Comprehensive monitoring & observability of runtime operations
The device shall embed a unified monitoring and observability layer that continuously captures key runtime signals—performance metrics, structured logs, error rates, hardware resource utilisation, data-flow timings, algorithm confidence scores, and user-initiated events—across all device’s services. Real-time thresholds shall trigger configurable alerts whenever behaviour deviates from validated baselines, enabling rapid triage of anomalies such as model drift, image-processing bottlenecks, or network outages.
Stakeholder: User
PRS-007: Cybersecurity & continuous threat detection
The device shall maintain a defence-in-depth security posture that safeguards patient data, intellectual property, and clinical functionality throughout the device lifecycle by enforcing secure boot, cryptographically signed updates, authentication and role-based access controls, and end-to-end encryption for data in transit and at rest. A built-in continuous-threat-detection service shall ingest vulnerability feeds, and run host- and network-level anomaly detection to flag malware, privilege-escalation attempts, or unauthorized API calls within seconds.
Stakeholder: Patient
PRS-008: Support health data interoperability using the HL7 FHIR standard
The device shall exchange healthcare information with other clinical systems through the HL7 Fast Healthcare Interoperability Resources (FHIR) standard. It mandates that key data be packaged as structured FHIR Resources that electronic health-record (EHR) platforms, hospital information systems, and research registries can consume without custom adapters. The device must expose a standards-conformant interface that lets authorised systems retrieve, store, and query those resources, using the current normative FHIR release at the time of market launch and clear version tagging to preserve backward compatibility.
Stakeholder: Patient
PRS-009: Comprehensive secure audit trails for user interactions
The device shall automatically create and keep an auditable record of all actions, whether initiated by a user or the system, performed via any interface. Each entry must capture the actor’s verified identity and role, event type, precise timestamp traceable to a trusted time source, system response (if applicable), and relevant contextual data, while never exposing patient information in clear text. Audit files are to be write-once, tamper-evident, and cryptographically sealed so that any attempt at alteration or deletion is immediately detectable and traceable.
Stakeholder: User
PRS-010: Compliance with MDR
The device shall be developed in compliance with the MDR.
Stakeholder: Regulatory
PRS-011: Compliance with FDA
The device shall be developed in compliance with the FDA.
Stakeholder: Regulatory
PRS-012: Compliance with ANVISA
The device shall be developed in compliance with ANVISA.
Stakeholder: Regulatory
PRS-013: Compliance with GDPR
The device shall provide optimal security for the personal data it manages in compliance with the General Data Protection Regulation (GDPR).
Stakeholder: Regulatory and Patient
PRS-014: Compliance with HIPAA
The device shall provide optimal security for the Protected Health Information (PHI) it manages, in compliance with the Health Insurance Portability and Accountability Act (HIPAA).
Stakeholder: Regulatory and Patient
PRS-015: Compliance with Applicable Standards
The device shall be developed in accordance with the international standards to which it is deemed compliant–see:
- ISO 13485:2016 (Medical devices - Quality management system)
- IEC 62304:2006 + A1:2015 (Medical device software - Software life cycle processes [Including Amendment 1 (2015)])
- ISO 14971:2019 (Medical devices - Risk management applications for medical devices)
- IEC 62366:2015 (Medical devices - Application of usability engineering to medical devices [Including CORRIGENDUM 1 (2016)])
- IEC 62443-4-2:2019 (Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components)
- IEC 82304-1:2017 Health Software - Part 1. General requirements for product safety
Stakeholder: Regulatory
PRS-016: Compliance with EU Artificial Intelligence Act
This product requirement ensures compliance with the EU Artificial Intelligence Act for high-risk AI systems embedded in medical devices. It defines obligations around transparency, traceability, and human oversight throughout the AI lifecycle.
Stakeholder: Regulatory
PRS-017: Compliance with all applicable national laws and regulations in each of the intended target markets
The device may be placed in Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden in compliance with national regulations.
Stakeholder: Company