Search Results
Found 3 results
510(k) Data Aggregation
(137 days)
Intel-GE Care Innovations Connect RCM is intended to collect vital sign measurements from physiological measurement devices intended for use in the home. Patients can review the stored vital sign measurement information and receive educational and motivational content from caregivers. Patients can also engage in videoconferences with caregivers and answer the caregivers' questions by participating in surveys.
Care Innovations Connect RCM is not interpretive, nor is it intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. It is made available to patients when time-critical care is not required.
Care Innovations Connect RCM is contraindicated for patients requiring direct medical supervision or emergency intervention. It is intended for patients who are willing and capable of managing its use. Clinical judgment and experience by a caregiver are required to check and interpret the information delivered.
Care Innovations Connect RCM will be available for over the counter use.
Care Innovations™ Connect RCM is a software application for use with measurement devices commercially available for home use. The software executes on a web server and is accessed via a browser from the patient's COTS personal computing device. A small validated software application known as Device Connector runs on patients' home COTS platforms. Off the Shelf (OTS) software is also used with the internally developed software to provide functionality such as: setting & receiving email and text-based notifications, creating & editing calendar entries, playing Learn More videos, and holding a video conference with a clinician.
Care Innovations™ Connect RCM is a software application for use with measurement devices commercially available for home use. Connect RCM provides the same client capabilities of collecting and transmitting patient data to the clinician database system as the predicate devices, and uses the existing clinician database system in the Intel-GE Care Innovations 10 Guide (K130290). No changes were required to the existing clinician database system to support the new client software.
Patients can also enter measurement data manually entered data is stored in the backend clinician database as well as the Personal Health Data Record. It is flagged as manually entered data.
The provided document, K130821, states that the "Connect RCM does not rely on an assessment of clinical performance data." It asserts that "The device will conform to FDA 's recognized consensus standards and relies on its conformity to demonstrate the safety and efficacy." Therefore, there is no study described that proves the device meets specific acceptance criteria based on clinical performance.
Instead, the submission relies on demonstrating substantial equivalence to predicate devices and conformity to recognized consensus standards for safety and efficacy.
Given this, I cannot fill out the requested table or answer most of the follow-up questions because the submission explicitly states that clinical performance data was not used.
Here's what I can provide based on the document:
1. A table of acceptance criteria and the reported device performance
The document does not provide a table of acceptance criteria and reported device performance in the context of clinical studies. The "acceptance criteria" for this device appear to be its conformity to FDA recognized consensus standards and its substantial equivalence to predicate devices.
Acceptance Criteria (Implied) | Reported Device Performance |
---|---|
Conformity to AAMI/ANSI/IEC ES 60601-1 (Software Safety Standard) | Device "will conform" to this standard. |
Functional equivalence to Intel-GE Care Innovations Guide (K130290) | Device has "the same functionality" as the predicate. |
Does not introduce new questions concerning safety or efficacy | Device "introduces no new questions" on safety/efficacy. |
Collection of vital sign measurements from home physiological devices | Intended to "collect vital sign measurements." |
Review of stored vital sign measurement information by patients | Patients "can review the stored vital sign measurement." |
Receive educational and motivational content from caregivers | Patients "receive educational and motivational content." |
Engage in videoconferences with caregivers | Patients "can engage in videoconferences." |
Respond to caregiver questions via surveys | Patients "answer the caregivers' questions by participating in surveys." |
2. Sample size used for the test set and the data provenance
Not applicable. The device does not rely on clinical performance data for its 510(k) submission.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts
Not applicable. No clinical test set described.
4. Adjudication method
Not applicable. No clinical test set described.
5. If a multi reader multi case (MRMC) comparative effectiveness study was done, If so, what was the effect size of how much human readers improve with AI vs without AI assistance
Not applicable. The device is a remote patient monitoring system, not an AI-assisted diagnostic tool, and no such study was performed or described.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
Not applicable. The device is software for collecting and displaying patient data, not an algorithm for standalone performance evaluation in a clinical sense.
7. The type of ground truth used
Not applicable. No clinical performance data was used for the 510(k) submission. The "ground truth" for regulatory approval appears to be the documented functionality of the predicate device and the adherence to safety standards.
8. The sample size for the training set
Not applicable. No machine learning model or training set is described in the context of clinical performance for this 510(k).
9. How the ground truth for the training set was established
Not applicable. No training set is described.
Ask a specific question about this device
(95 days)
The Intel® Health Guide Express is intended to collect vital sign measurements from physiological measurement devices intended for use in the home. Patients can review the stored vital sign measurement information and receive educational and motivational content from caregivers. Patients can also engage in video conferences with caregivers and answer the caregivers' questions by participating in surveys.
The Intel® Health Care Management Suite allows the caregiver to review patient data and initiate video conferencing with patients, or select and send educational and motivational content to patients.
The Intel® Health Guide Express is not interpretive, nor is it intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. It is made available to patients when time-critical care is not required.
The Intel® Health Guide Express is contraindicated for patients requiring direct medical supervision or emergency intervention. It is intended for patients who are willing and capable of managing its use. Clinical judgment and experience by a caregiver are required to check and interpret the information delivered.
The Intel® Health Guide Express is a communication tool that allows caregivers to remotely access vital sign measurements of patients at home. The Intel® Health Guide Express is a software application running on a Commercial Off The Shelf (COTS) Personal Computer (PC). It collects measurements captured on commercially available wireless or tethered medical devices which are designed for home use and connection to a COTS PC. It displays the collected measurement on the PC, and securely stores the collected information locally on a memory device installed in the PC. The Intel® Health Guide Express also stores the information remotely on a host server, where the caregiver can view the measurement via the host server once synchronization between the host server and Intel® Health Guide Express has been completed. The Intel® Health Guide Express can be used to display educational and motivational content from the caregiver and can facilitate communication between the caregiver and patient via health wellness surveys and optional video conferencing.
The Intel® Health Guide Express is not interpretive, nor is it intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. It is made available to patients when time-critical care is not required. It is contraindicated for patients requiring direct medical supervision or emergency intervention. It is intended for patients who are willing and capable of managing its use. Clinical judgment and experience by a caregiver are required to check and interpret the information delivered.
The Intel® Health Guide PHS Express system consists of the:
- Intel® Health Guide Express software application: (1)
The software application captures, stores, displays and transmits information to a secure database on a host server running the Intel® Health Care Management Suite software via a standard telephone line or internet connection. The Intel® Health Guide Express software runs on a Commercial Off The Shelf (COTS) Personal Computer (PC).
Intel® Health Care Management Suite software application: (2)
The software application runs on a host server and allows caregivers to review patient vital signs on the secure website. The Intel® Health Care Management Suite allows for predefining upper and lower limits and, when either limit is exceeded, the system emails and/or pages the caregiver.
The Intel® Health Guide Express is a remote patient monitoring system. The provided text is a 510(k) summary, which focuses on demonstrating substantial equivalence to a predicate device rather than detailing specific acceptance criteria and a study to prove meeting them in the way clinical studies for diagnostic accuracy often do.
Here's an analysis based on the provided document:
1. Table of Acceptance Criteria and Reported Device Performance
The document does not explicitly state "acceptance criteria" and "reported device performance" in the context of diagnostic accuracy or a specific performance study. Instead, it demonstrates substantial equivalence to a predicate device (Intel® Health Guide PHS6000) based on technological characteristics and functional similarities. The key performance aspect is the ability to collect, store, display, and transmit vital sign measurements, and this is compared to the predicate device's capabilities and compatibility with various peripherals.
Acceptance Criteria (Implied by Substantial Equivalence Claim) | Reported Device Performance (as presented in K103276) |
---|---|
Software Functionality: Capture, store, display, and transmit information to a secure database. | The Intel® Health Guide Express software application captures, stores, displays, and transmits information to a secure database on a host server. |
Operating System: Compatible with standard PC operating system. | Compatible with Microsoft Windows 7 (32-bit versions). Predicate used Microsoft Windows XP embedded. |
Communication Method: Standard telephone line or internet connection. | Uses standard telephone line or internet connection for transmission. |
Sensor Interface: Ability to interface with commercially available wireless or tethered medical devices. | Interfaces with listed medical devices for Blood Pressure, Weight, Blood Glucose Level, Oxygen Saturation, and FEV/PEF. |
Data Collection Implementation: Similar method to predicate device. | Claimed substantially equivalent to predicate in implementation method of collecting data from sensors. |
Connectivity/Communication Protocol/Power Source/Display Method: Similar to predicate device. | Claimed substantially equivalent to predicate in these aspects. |
Hardware Compatibility (COTS PC): Meets minimum specified hardware requirements. | Requires a COTS PC with minimum specifications for OS, CPU, Memory, Storage, Ports, Display, etc. (Table 2). |
Safety Standard Compliance: Complies with relevant safety standards. | The device relies on conformity to FDA's recognized consensus standards to demonstrate safety and efficacy. COTS PC safety standard: UL 60950-1:2007. Predicate safety standard: ES60601-1:2005. Differences analyzed in risk analysis. |
Patient Leakage Current: Within acceptable limits for a COTS PC. | For COTS PC, patient leakage current (from patient connection to earth) is 3.5mA (compared to 100μA for predicate, with differences covered in risk analysis). |
Essentially, the "acceptance criteria" here are that the new device performs its intended functions (collecting and transmitting data) and is at least as safe and effective as the predicate device, given its specific use case as a communication tool and not a diagnostic device.
2. Sample Size Used for the Test Set and Data Provenance
The document does not describe a specific "test set" or a study involving patient data for performance evaluation in the context of diagnostic accuracy or a similar clinical measurement. The device is a "Remote Patient Monitoring System" that collects data from other commercially available medical devices.
The assessment is primarily a technical comparison and declaration of substantial equivalence to a predicate, not a clinical trial evaluating the performance on a patient cohort or a specific dataset. There is no mention of data provenance (country of origin, retrospective/prospective).
3. Number of Experts Used to Establish Ground Truth for the Test Set and Qualifications
This information is not applicable as there is no mention of a "test set" requiring ground truth established by experts for performance evaluation. The device's function is data capture and transmission, not interpretation or diagnosis.
4. Adjudication Method for the Test Set
This information is not applicable for the same reason as point 3. No test set requiring expert adjudication for ground truth establishing is described.
5. If a Multi Reader Multi Case (MRMC) Comparative Effectiveness Study was done
No, a MRMC comparative effectiveness study was not done. The device is a data collection and communication tool, and its primary purpose is not to assist human readers in interpretation or diagnosis. Therefore, a study of improved human reader performance with AI assistance is not relevant to this type of device.
6. If a Standalone Study (i.e. algorithm only without human-in-the-loop performance) was done
No, a standalone study in the context of algorithmic performance for diagnosis/interpretation was not described. The device is a software application running on a COTS PC that interacts with other medical devices. Its performance is assessed in terms of its ability to correctly capture, store, transmit data, and its compatibility with hardware, rather than standalone diagnostic accuracy. The safety and efficacy claims "do not rely on an assessment of clinical performance data" but on conformity to recognized consensus standards.
7. The Type of Ground Truth Used
Not applicable. As stated earlier, the submission focuses on substantial equivalence based on technological characteristics and safety standards, not on evaluating diagnostic accuracy against a ground truth. The device itself is "not interpretive, nor is it intended for diagnosis."
8. The Sample Size for the Training Set
Not applicable. This device is a remote patient monitoring software system. There is no mention of a "training set" for an AI algorithm in the context of diagnosis or prediction.
9. How the Ground Truth for the Training Set was Established
Not applicable. For the same reasons as point 8, there is no mention of a training set or ground truth establishment relevant to an AI model's training.
Ask a specific question about this device
(322 days)
The MedApps Wellness System is intended for use in non-clinical settings to collect and transmit historical data to healthcare professionals to help support effective management of patients.
The System is not intended to provide automated treatment decisions, nor is it to be used as a substitute for a professional healthcare judgment. All patient medical diagnosis and treatment are performed under the supervision and oversight of an appropriate healthcare professional.
The MedApps Wellness System model D-PAL acts as an accessory to FDA cleared devices, which collects and transmits stored patient data via wireless connections from medical devices to a cellular phone (Hub) and forwards to a central server for review of historical data about a patient over time to benefit the Healthcare Practitioner.
The following medical devices and measuring systems are fully validated for this intended use at this time:
- . LifeScan OneTouch ® Ultra® Blood Glucose Monitoring System (K024194 / K043197)
- . Polytel PWR-08-03 Remote Module (K070559 pending clearance)
The MedApps Wellness System is not intended to provide automated treatment decisions or to be used as a substitute for professional healthcare judgment. All patient medical diagnoses and treatment are to be performed under the supervision and oversight of an appropriate healthcare professional.
The MedApps Wellness System is not intended for emergency calls, and may not be used for transmission or indication of any real-time alarms or time-critical data.
Clinical judgment and experience are required to check and interpret the measurements collected and transmitted.
This device is not for use in systems which substitute for medical care.
This device is not intended for patients requiring direct medical supervision or emergency intervention.
The MedApps Wellness System ("System") is designed to be used by patients to send their data from the LifeScan OneTouch Ultra glucometer to a central server for subsequent storage and display.
The System is comprised of a "Hub" (cell phone software) and the MedApps Engine, which runs on a central server.
The Hub is a software program that runs on a cell phone and takes in data from the OneTouch Ultra and then transmits it to the central server for storage and processing.
The MedApps Engine is a software program that runs on a common Web / Internet secure server platform. The MedApps Engine picks up the stored data sent to it by the Hub and through a set of business rules set by the healthcare providers, determines if a follow-up Interactive Voice Response (IVR) call is required to be made to the patient to collect additional Behavioral information from the patient.
Once all the data is collected, then it is stored in a repository for access by the healthcare provider,
The Hub will utilize the OneTouch Ultra integrated Short-range low power wireless transmission (Bluetooth V1.2) or a FDA approved accessory to the medical devices that to transmits the medical device data via Bluetooth to a compatible cellular telephone, such as the Nokia 6620, or other /compatible cellular phones.
The provided 510(k) summary for the MedApps™ Remote Patient Monitoring System does not contain the specific details about "acceptance criteria" for performance metrics like sensitivity, specificity, or image quality, nor does it detail a clinical study with such explicit criteria and outcomes for direct comparison.
However, based on the non-clinical performance data testing and review, and the nature of the device as a data transmission system, we can infer the acceptance criteria and the study's approach to proving substantial equivalence.
Here's an interpretation of the requested information, drawing inferences where explicit details are not present.
Acceptance Criteria and Device Performance
Since the MedApps system is primarily a data collection and transmission device, its performance criteria are centered on its ability to accurately and reliably transfer data. The document does not provide quantitative metrics for accuracy, latency, or data integrity in the form of a table. However, the section on "Non-Clinical Performance Data Testing and Review" implies that the acceptance criteria were based on meeting Software Design Specifications (SDS) and demonstrating functional equivalence to predicate devices.
Inferred Acceptance Criteria Table:
Acceptance Criteria Category | Specific Criteria (Inferred) | Reported Device Performance (Inferred) |
---|---|---|
Data Transmission: | Accuracy/Integrity: Data transmitted from glucometer to Hub and then to central server must be identical to source data. | The Alpha validation testing "included testing of all executable code and functionality" and confirmed that the system "met its required requirements and design specifications as intended," which would encompass accurate data transmission. |
Reliability/Completeness: All intended data points are successfully transmitted without loss. | The "exhaustive validation scripts of all Software Design Specifications (SDS)" and the "complete record of those executed scripts as operational performance data" suggest that all data points were reliably transmitted as per design. | |
System Functionality: | Interoperability: Successful connection and data transfer with specified FDA-cleared devices (LifeScan OneTouch Ultra). | The system is "fully validated for this intended use" with the LifeScan OneTouch ® Ultra® Blood Glucose Monitoring System, implying successful interoperability. |
User Interface: Software (Hub and MedApps Engine) functions as designed, providing appropriate data display and IVR triggers. | Alpha validation "included testing of all executable code and functionality" and demonstrated the system "met its required requirements and design specifications as intended," which would cover user interface and backend functionality related to IVR and data display. | |
Security: | Data Security: Data transmission and storage are secure. | While not explicitly detailed as an acceptance criterion in this section, the mention of "secure server platform" and the overall nature of medical device software validation imply security measures were tested to meet design specifications. |
Hazard Mitigation: | All identified software hazards are adequately addressed. | Alpha validation included "confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP." This indicates that hazard mitigation was a key acceptance criterion and was met during testing. |
Study Details:
-
A table of acceptance criteria and the reported device performance:
- (Provided above)
-
Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):
- Sample Size: Not explicitly stated. The document refers to "exhaustive validation scripts" and a "complete record of those executed scripts as operational performance data." This suggests a comprehensive test suite rather than a traditional "sample size" in clinical study terms.
- Data Provenance: Not specified. Given the nature of the device as a software system for data transmission, the "data" being tested would be synthetic or simulated data generated during the validation process to represent real-world glucometer readings. The testing appears to be prospective in the sense that the validation scripts were executed to test the device's functionality. There is no indication of patient-derived data or geographical origin.
-
Number of experts used to establish the ground truth for the test set and the qualifications of those experts (e.g. radiologist with 10 years of experience):
- This question is not applicable in the traditional sense. The "ground truth" for a data transmission system is the source data itself. The validation tests would verify that the transmitted data perfectly matches the input data. There is no 언급 of external experts or clinical judgment being used to establish a "ground truth" for the test set, as is common in diagnostic device studies. The "ground truth" here is the expected behavior and output based on the device's design specifications.
-
Adjudication method (e.g. 2+1, 3+1, none) for the test set:
- Not applicable. Adjudication methods like 2+1 (two readers agree, third is tie-breaker) are used in studies involving human interpretation (e.g., radiology reads). For a software device that transmits data, the "test set" verification would involve automated or direct comparison of transmitted data against source data, or verification of functional execution against design specifications. No human adjudication is mentioned or implied.
-
If a multi-reader multi-case (MRMC) comparative effectiveness study was done, If so, what was the effect size of how much human readers improve with AI vs without AI assistance:
- No MRMC comparative effectiveness study was done or is applicable. This device is a data transmission system, not an AI-powered diagnostic tool that assists human readers. Its purpose is to present historical data to healthcare professionals, not to interpret or augment human diagnostic capabilities with AI.
-
If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:
- Yes, implicitly. The "Alpha validation testing" and "exhaustive validation scripts" evaluated the MedApps Wellness System (software algorithm) in isolation to ensure it met its "required requirements and design specifications." This testing focuses on the system's ability to accurately collect, transmit, store, and process data according to its programmed logic, without direct human intervention in the data flow or processing steps. The output data is then presented for human review, but the performance of the transmission system itself is standalone.
-
The type of ground truth used (expert consensus, pathology, outcomes data, etc):
- The "ground truth" for this device's performance testing was its Software Design Specifications (SDS) and the source data (simulated glucometer readings). The validation aimed to confirm that the device accurately processed and transmitted the input data according to its predefined functional requirements and met all specified design parameters.
-
The sample size for the training set:
- Not applicable. The MedApps Wellness System is not an AI/ML device that requires a "training set" to learn or optimize its performance. It is a rule-based software system that performs predefined tasks (data collection, transmission, storage, and IVR triggering).
-
How the ground truth for the training set was established:
- Not applicable, as there is no training set for this type of device.
Ask a specific question about this device
Page 1 of 1