Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
          • 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
          • ignore-this
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard

REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard

Category​

Functional

Source​

  • Taig Mac Carthy, Design & Development Manager

INTERNAL SYSTEM INPUTS AND OUTPUTSINTERFACES DATABASE AND DATA DEFINITIONREGULATORY FUNCTIONAL AND CAPACITY ARCHITECTURE

Activities generated​

  • MDS-449

Causes failure modes​

  • Data not formatted according to FHIR specifications, leading to interoperability issues.
  • Omitting mandatory fields specified by the FHIR standard, resulting in incomplete data.
  • Using incorrect data types for certain fields that constitute the FHIR resources.
  • Inadequate validation of incoming and outgoing data against FHIR standards, allowing non-compliant data to pass through.
  • Errors in the validation logic that incorrectly flag compliant data as non-compliant or vice versa.
  • Differences in FHIR versions between the sending and receiving systems causing compatibility issues.
  • Errors in mapping internal data structures to FHIR-compliant structures, leading to incorrect or incomplete data representation.
  • Users entering data that does not comply with FHIR standards, leading to rejection or errors.
  • Insufficient documentation on how to use and integrate FHIR standards within the system.

Related risks​

    1. The endpoints of the device are not compatible with the user's software
    1. Incompatibility in classification systems: the name of the classes in the device does not match the user's system
    1. Misrepresentation of magnitude returned by the device
    1. Misinterpretation of data returned by the device
    1. Data transmission failure from care provider's system: the care provider's system cannot connect to the device to send data
    1. Data input failure: the device can't receive data from the user
    1. Data accessibility failure: the user can't receive data from the device
    1. Data transmission failure: the device can't send data to the user
    1. Non-compliance with the General Safety & Performance Requirements (GSPR)
    1. Medical device input requirements are not defined to users for its proper operation
    1. Inadequate specification of the product's intended purpose
    1. System incompatibility: integration of our device is not compatible with the user platform
    1. Integration failure or errors: the user lacks the knowledge required to integrate the product in their system

User Requirement, Software Requirement Specification, Design Requirement and Regulatory Requirement​

  • User Requirement 6.1: Users should be able to send and receive data adhering to FHIR healthcare interoperability standards.
  • Software Requirement Specification 6.2: Implement FHIR data standards in device's data processing, ensuring all inputs and outputs comply with this standard.
  • Design Requirement 6.3: Device responses and requests shall be structured according to the FHIR standard, utilizing standardized healthcare data objects and attributes.
  • Regulatory Requirement 6.4: The device shall be compliant with MDR 2017/745, Annex I, point 14.5.

Description​

Comprehending the dynamic interplay between individuals and the Legit.Health medical device is fundamental for its effective use. The core of any operational system relies on the seamless exchange of information. Hence, adhering to established industry norms plays a pivotal role in attaining this goal. The most used and accepted standard in healthcare is the FHIR healthcare interoperability standard. FHIR is designed to improve interoperability among healthcare systems.

Features of FHIR​

  • Resource-Based: FHIR is resource-based, meaning it breaks down data into discrete chunks called "resources." These resources can represent a patient, a device, an encounter, a clinical observation, and more.
  • Extensibility: FHIR is designed to be extended and adapted. With FHIR, developers can create extensions to represent additional data elements required to support use cases not covered by the base standard.
  • Standardization: FHIR promotes the use of standard terminologies (like SNOMED CT, LOINC, ICD, etc.) to represent clinical concepts, increasing the interoperability between systems.
  • Security: FHIR provides specifications for the secure exchange of healthcare information, with support for modern web-based security protocols such as OAuth.

Benefits of FHIR​

  • Interoperability: FHIR promotes interoperability, which means different healthcare systems can communicate and exchange data with each other seamlessly.
  • Data Access: With FHIR, patients can access their health information more easily, and healthcare providers can access and share patient information more efficiently.
  • Real-time Data Exchange: FHIR supports real-time exchange of health data, improving the speed and efficiency of healthcare delivery.

Success metrics​

GoalMetric
Users understand how to send dataInput data follows the FHIR healthcare interoperability standard
Users understand how data is receivedOutput data follows the FHIR healthcare interoperability standard

Previous related requirements​

  • REQ_005

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:

  • Tester: JD-017, JD-009, JD-005, JD-004
  • Approver: JD-003
Previous
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
Next
REQ_007 If something does not work, the API returns meaningful information about the error
  • Category
  • Source
  • Activities generated
  • Causes failure modes
  • Related risks
  • User Requirement, Software Requirement Specification, Design Requirement and Regulatory Requirement
  • Description
    • Features of FHIR
    • Benefits of FHIR
  • Success metrics
  • Previous related requirements
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.)