Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • Legit.Health Plus Version 1.1.0.0
    • Index of Technical Documentation or Product File
    • Summary of Technical Documentation (STED)
    • Description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File
      • Requirements
        • User Requirement Specification (URS)
        • Software Requirement Specification (SRS)
          • SRS-001 The device handles user accounts through an internal user registration service
          • SRS-002 The REST API enforces HTTPS for all communications to ensure data security
          • SRS-003 The REST API implements rate limiting to prevent abuse
          • SRS-004 The REST API verifies the access token for every request to secure endpoints
          • SRS-005 Data exchanged with clinical endpoints of the API adhere to the FHIR standard
          • SRS-006 The REST API only accepts and outputs images in Base64 format
          • SRS-007 The diagnosis support service accepts multiple images to deliver more accurate results
          • SRS-008 The user's password is stored in the database as a hashed password
        • REQ_001 The user receives quantifiable data on the intensity of clinical signs
        • REQ_002 The user receives quantifiable data on the count of clinical signs
        • REQ_003 The user receives quantifiable data on the extent of clinical signs
        • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
        • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
        • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
        • REQ_007 If something does not work, the API returns meaningful information about the error
        • REQ_008 Notify the user if the image does not represent a skin structure
        • REQ_009 Notify the user if the quality of the image is insufficient
        • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
        • REQ_011 The user specifies the body site of the skin structure
        • REQ_012 Users can easily integrate the device into their system
        • REQ_013 The user receives the pixel coordinates of possible ICD categories
      • Test plans
      • Test runs
      • Review meetings
      • 🥣 SOUPs
      • REL-001 Version 1.1.0.0
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
    • Usability and Human Factors Engineering
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Legit.Health Plus Version 1.1.0.0
  • Design History File
  • Requirements
  • Software Requirement Specification (SRS)
  • SRS-005 Data exchanged with clinical endpoints of the API adhere to the FHIR standard

SRS-005 Data exchanged with clinical endpoints of the API adhere to the FHIR standard

Category​

  • User Interface
  • Regulatory

Importance​

  • High

Description​

FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare information electronically. It was created by the Health Level Seven International (HL7) organization. FHIR aims to simplify and accelerate the interoperability of healthcare data by using modern web technologies, fostering better collaboration and care coordination across the healthcare ecosystem.

FHIR takes a modular approach, breaking healthcare data into discrete, structured "resources" such as patients, medications, and observations. These resources can be easily shared and understood across different systems. It uses RESTful APIs, which are common in web services, making it straightforward to implement and integrate with existing technologies. FHIR supports multiple data formats, including JSON and XML, making it flexible and adaptable to various technology stacks.

We'll use the JSON format to represent FHIR resources in our API for data exchange. This involves all the JSON documents sent and received in the request and response bodies from the clinical API endpoints.

Rationale​

Adopting the FHIR standard will make it easier for developers to integrate our software with their existing medical records and clinical applications.

Source​

  • Taig Mac Carthy
  • Industry best practices

Tested by software tests​

  • PLAN_010: Validation of request and response data against FHIR schemas

Activities generated​

  • Develop the JSON schemas for requests and responses based on FHIR resource definitions.
  • Implement validation mechanisms to ensure all data exchanged via the API endpoints conform to FHIR standards.
  • Update API documentation to include information about FHIR-compliant data formats.

Implements user needs​

The requirement addresses the need for interoperability with other healthcare systems, enabling users to integrate the software with their existing electronic health record (EHR) systems. This integration enhances data management efficiency and supports better clinical decision-making.

Regulatory requirements​

5.1: The device shall be compliant with MDR 2017/745, Annex I, point 14.5

Causes failure modes​

  • Incorrect implementation of FHIR schemas leading to data exchange errors, and incompatibility with some healthcare systems due to deviations from the standard. These could result from improper validation or incorrect interpretation of FHIR resource definitions.

Implements risk control measures​

  • It mitigates risks related to data inconsistency, misinterpretation of results and incompatibility by enforcing the use of well-defined, standardized data formats.
  • Compliance with FHIR also ensures adherence to regulatory standards, thereby reducing the risk of legal and operational issues.

Acceptance criteria​

  • All JSON requests and responses for the API endpoints are validated against the corresponding FHIR resource schemas.
  • Successful data exchange with external systems that use FHIR standards without errors or data loss.
  • Comprehensive documentation detailing the implementation of FHIR standards in the API.

Constraints​

  • Use FHIR standard version 5.0 or higher.
  • Use only non-experimental FHIR data types and resource types.

Dependencies​

There are no specific dependencies for this requirement. However, it is essential to ensure that the implementation remains up-to-date with any changes or updates to the FHIR standard.

Performance considerations​

Ensure that the validation of JSON documents against FHIR schemas does not significantly impact the response time of the API endpoints.

Additional notes​

Regular training and updates for the development team on FHIR standards and best practices will be necessary to maintain compliance and optimize implementation.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

  • Author: JD-004, JD-005, JD-009, JD-017
  • Approver: JD-003
Previous
SRS-004 The REST API verifies the access token for every request to secure endpoints
Next
SRS-006 The REST API only accepts and outputs images in Base64 format
  • Category
  • Importance
  • Description
  • Rationale
  • Source
  • Tested by software tests
  • Activities generated
  • Implements user needs
  • Regulatory requirements
  • Causes failure modes
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)