Product Requirement Specification (PRS)
| Code | Name | Description | Stakeholder |
|---|---|---|---|
| PRS-8QJ | Generate an interpretative probability distribution of possible ICD categories by analysing images | p:last-child]:mb-0> 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. | User |
| PRS-2ZB | Measure severity by combining image analysis and user-reported values in scoring systems | p:last-child]:mb-0> The device shall use of each dermatological visible sign detected in an image set:
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. | User |
| PRS-7XK | Assess image adequacy on ingestion | p:last-child]:mb-0> Upon ingestion, the device shall automatically evaluate every incoming image against a predefined and version-controlled set of adequacy criteria. | User |
| PRS-1V6 | Expose the deviceâs functionality through a versioned, network-accessible API | p:last-child]:mb-0> 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. 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. | User |
| PRS-4QW | Comprehensive monitoring & observability of runtime operations | p:last-child]:mb-0> 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. | User |
| PRS-9F2 | Cybersecurity & continuous threat detection | p:last-child]:mb-0> 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. | Patient |
| PRS-5LJ | Support health data interoperability using the HL7 FHIR standard | p:last-child]:mb-0> 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. | Patient |
| PRS-0MC | Comprehensive secure audit trails for user interactions | p:last-child]:mb-0> 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. | User |
| PRS-3YH | Compliance with MDR | p:last-child]:mb-0> The device shall be developed in compliance with the MDR. | Regulatory |
| PRS-6DP | Compliance with FDA | p:last-child]:mb-0> The device shall be developed in compliance with the FDA. | Regulatory |
| PRS-8R4 | Compliance with ANVISA | p:last-child]:mb-0> The device shall be developed in compliance with ANVISA. | Regulatory |
| PRS-2KQ | Compliance with GDPR | p:last-child]:mb-0> The device shall provide optimal security for the personal data it manages in compliance with the General Data Protection Regulation (GDPR). | Regulatory and Patient |
| PRS-7Z8 | Compliance with HIPAA | p:last-child]:mb-0> 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). | Regulatory and Patient |
| PRS-1XU | Compliance with Applicable Standards | p:last-child]:mb-0> The device shall be developed in accordance with the international standards to which it is deemed compliantâsee:
| Regulatory |
| PRS-4E7 | Compliance with EU Artificial Intelligence Act | p:last-child]:mb-0> 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. | Regulatory |
| PRS-9J5 | Compliance with all applicable national laws and regulations in each of the intended target markets | p:last-child]:mb-0> 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. | Company |