The MedApps 2.0 - Remote Patient Monitoring System consists of a patient device, MedApps HealthPAL, which is a mobile Over-The-Counter wireless communication hub that connects to commercially available wireless and tethered Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters. The HealthPAL stores and displays the information on the OLED screen, and transmits the information to the MedApps secure host server called "HealthCOM" using off the shelf FCC approved wireless / cellular connectivity (including, but not limited to GSM, CDMA and WiMax). Healthcare professionals can review the transmitted information within the MedApps HealthCOM system, set thresholds to flag readings based on specific thresholds being exceeded. In addition, the MedApps Interactive Voice Response (IVR) has the ability to contact the patient remotely and use pre-approved ("canned") educational or reminder messages. ("Your nurse would like to talk to you, can I connect you now", "We haven't received a reading from you today, please send us your readings").

The MedApps 2.0 - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. The data is made available to the patients when time-critical care is not required. The device is contraindicated for patients requiring direct medical supervision or emergency intervention.

Device Description

The MedApps 2.0 - Remote Patient Monitoring System uses MedApps Accessories that help the patient in usability of the product, including HealthLINK which docks the HealthPAL, and HealthPOD which connects to off the shelf medical devices via their data port to transmit data via wireless or RF technology (including, but not limited to bluetooth, zigbee, ANT, ULP, etc.).

The MedApps 2.0 - Remote Patient Monitoring System consists of:
(1) MedApps HealthPAL hardware:
The physical component of the MedApps HealthPAL is an electronic device contained in a plastic enclosure with an OLED screen, built-in M2M cellular chip, speaker, smart cable connection, smart cables, wireless, LED Lights to indicate activity, timer button to remind the patient to take their reading in X minutes, last reading button, volume up and down buttons.
(2) MedApps HealthPAL software application:
The software application captures, stores and transmits information to the MedApps HealthCOM server, via the embedded communication chip / platform.
The software application takes in additional information via the embedded wireless module from other medical devices that are wireless enabled, and that have been paired to the MedApps HealthPAL.
The software application has many additional functions including:

Download of the users profile from the server to configure the HealthPAL remotely.
Ability to "talk" to the patient with verbal acknowledgments of readings from all attached medical devices, time settings, volume control, educational content and reminders, in any language that is loaded to the device.
Timer set that was activated by the user at a set timeframe to do whatever they wanted to be reminded to do.
Control the OLED screen to show certain information including, battery status, volume level, transmission status, message waiting indicator, medical device last reading, activity icons / messages and more as it pertains to provide ease of use and easier adoption for the patient.
Battery charging, isolation circuits, and interfaces to individual medical devices / protocols via the smart cables.
(3) MedApps HealthLINK hardware / software:
The HealthLINK hardware / software plugs into off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, and transmit the data via wireless to a receiver that it is already paired with.
(4) MedApps HealthPOD hardware / software:
The HealthPOD hardware / software is an extension of the HealthPAL functionality that is outlined in this submission. HealthPOD acts as a "docking" station for the HealthPAL in order to recharge batteries, take in additional connections to off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, via smart cables (per validated in HealthPAL software), add a backup communication method via phone line (POTS line), and communicate via wireless to HealthPAL or additional HealthPODs.
(5) MedApps HealthCOM software application:
The software application allows caregivers to set thresholds and review patient data on the secure HealthCOM website.
The HealthCOM software also allows the patient to establish an account and to direct / authorize their data to be directed to an outside, validated Personal Health Record (PHR), Electronic Health Record (EHR or EMR).
(6) MedApps IVR software application:
The software application calls the patient on any phone that is designated in their user profile, and executes an approved ("canned") script to gather information. ("Your nurse would like to talk to you, can I connect you now", "We haven't received a reading from you today, please send us your readings").
In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and many other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on parameters / thresholds set in the HealthCOM system.

AI/ML Overview

The provided document is a 510(k) summary for the MedApps 2.0 - Remote Patient Monitoring System. It describes the device, its intended use, and compares it to predicate devices. However, this document does not contain acceptance criteria, nor does it describe a study proving the device meets specific performance criteria related to diagnostic accuracy or clinical effectiveness.

Instead, the document focuses on demonstrating substantial equivalence to previously cleared predicate devices based on technological characteristics and functional similarities. The "performance data" mentioned refers to non-clinical verification and validation testing, ensuring the system functions as designed and meets its requirements.

Therefore, for many of your requested points, the information is not available in the provided text.

Here's a breakdown based on the information that is available:

1. Table of Acceptance Criteria and Reported Device Performance

This information is not provided in the document. The document primarily focuses on demonstrating substantial equivalence based on technological characteristics rather than specific performance metrics (e.g., sensitivity, specificity, accuracy) against a set of predefined acceptance criteria in a clinical context.

2. Sample size used for the test set and the data provenance

This information is not provided in the document. The "Alpha validation testing" involved "testing of all executable code and functionality" and "exhaustive validation scripts of all Detail Design Specifications (DDS)." This refers to system and software testing, not a clinical test set with patient data.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts

This information is not provided. The testing described is non-clinical verification and validation of software functionality and system requirements.

4. Adjudication method for the test set

This information is not provided.

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

This information is not applicable/provided. The device is a remote patient monitoring system for collecting and transmitting physiological data, not an AI-powered diagnostic tool requiring MRMC studies for human reader improvement. The document explicitly states: "The MedApps 2.0 - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data."

6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done

A standalone performance in the sense of diagnostic accuracy is not applicable. The "performance data" described refers to the non-clinical verification and validation of the system's ability to capture, store, transmit, and display data, and to execute functions as per its design specifications. It's a functional performance assessment, not a clinical performance assessment of an algorithm's diagnostic capability. The document states:

"Alpha validation testing included testing of all executable code and functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP."
"Alpha validation activities included exhaustive validation scripts of all Detail Design Specifications (DDS)..."
"The output of these two performance data records documents that MedApps 2.0 - Remote Patient Monitoring System met its required requirements and design specifications as intended."

7. The type of ground truth used

For the non-clinical testing, the "ground truth" was essentially the design specifications and requirements (Detail Design Specifications (DDS) and System Requirements Specifications (FDA-SRS-8009)). The testing confirmed that the device met these predefined functional and technical requirements.

8. The sample size for the training set

This information is not provided and is not applicable, as this device does not describe an AI/ML algorithm that requires a training set in the conventional sense for diagnostic tasks.

9. How the ground truth for the training set was established

This information is not provided and is not applicable, as this device does not describe an AI/ML algorithm that requires a training set in the conventional sense for diagnostic tasks.

Summary of available information regarding claimed "study":

The "study" referenced in the document is a non-clinical verification and validation testing process, not a clinical trial or comparative effectiveness study.

Acceptance Criteria (Implied): The device met its "required requirements and design specifications as intended" during specific Alpha validation activities. These requirements and specifications (detailed in Exhibit 08 - System Requirements Specifications (FDA-SRS-8009) which is not provided but referenced) served as the implicit acceptance criteria for functional performance.
Reported Device Performance: The "output of these two performance data records documents that MedApps 2.0 - Remote Patient Monitoring System met its required requirements and design specifications as intended."
Study Design/Methodology:
- Non-Clinical Testing: "significant verification and validation testing, Alpha validation testing included testing of all executable code and functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP."
- Alpha Validation Activities: "exhaustive validation scripts of all Detail Design Specifications (DDS), which was summarized and discussed to provide a preliminary record of performance data. Additionally, the submitter duplicated the operational environment of a sophisticated user and provided the complete record of those executed scripts as operational performance data."
Conclusion: The device "does not rely on an assessment of clinical performance data. The device conforms to FDA's recognized consensus standards and relies on its conformity to demonstrate its safety and efficacy. The device introduces no new questions concering the safety or efficacy and is, therefore, substantially equivalent to the predicate devices."

The document clearly states that "The MedApps 2.0 - Remote Patient Monitoring System does not rely on an assessment of clinical performance data." This means it did not undergo studies focused on clinical outcomes or diagnostic accuracy against a ground truth from patient data. Its clearance was based on demonstrating substantial equivalence to predicate devices through technical comparisons and non-clinical functional testing.

Summary

{0}------------------------------------------------

MedApps, Inc. 510(k) SUMMARY

. K083862
P.1/7
PREMARKET NOTIFICATION 510(k) SUMMARY

As required by 21 CFR §807.92(c)

Submitter

510(k) Owner: MedApps, Inc. Owner / Operator: 10027842 Registration : 3005916763 7975 North Hayden Road, Suite A-200, Scottsdale, AZ 85258 Address: Telephone: 480-305-6323 480-393-1892 Fax Number: Contact Person: Kent Dicks Contact Person Title: President / CEO December 23, 2008 Date Prepared:

Device Information

Trade Name:	MedApps 2.0 - Remote Patient Monitoring System
Common Name:	Remote Patient Monitoring System
Classification Status:	Class II per regulations 870.2910
Classification Name:	Transmitters and Receivers, Physiological Signal, Radiofrequency (21 CFR 870.2910. Product Code DRG)

LEGALLY MARKETED PREDICATE DEVICE A.

Legally marketed predicate device are: Intel Health Guide PHS6000 K080798 K072698 Confidant 2.5 MedApps Remote Patient Monitoring System (D-PAL) K062377

B. DEVICE DESCRIPTION

{1}------------------------------------------------

K083862 p. 2/7

The HealthCOM system allows the patient to login and create a personal account. The patient can specify / authorize which Personal Health Record (PHR) or Electronic Health Record (EHR / EMR) they would like to send / view their data within, outside of the HealthCOM system.

The MedApps 2.0 - Remote Patient Monitoring System consists of:

(1) MedApps HealthPAL hardware:

The physical component of the MedApps HealthPAL is an electronic device contained in a plastic enclosure with an OLED screen, built-in M2M cellular chip, speaker, smart cable connection, smart cables, wireless, LED Lights to indicate activity, timer button to remind the patient to take their reading in X minutes, last reading button, volume up and down buttons.

(2) MedApps HealthPAL software application:
The software application captures, stores and transmits information to the MedApps HealthCOM server, via the embedded communication chip / platform.

The software application takes in additional information via the embedded wireless module from other medical devices that are wireless enabled, and that have been paired to the MedApps HealthPAL.

The software application has many additional functions including:

Download of the users profile from the server to configure the . HealthPAL remotely. .
Ability to "talk" to the patient with verbal acknowledgments of . readings from all attached medical devices, time settings, volume control, educational content and reminders, in any language that is loaded to the device.
Timer set that was activated by the user at a set timeframe to ● do whatever they wanted to be reminded to do.
Control the OLED screen to show certain information including, . battery status, volume level, transmission status, message waiting indicator, medical device last reading, activity icons / messages and more as it pertains to provide ease of use and easier adoption for the patient.
Battery charging, isolation circuits, and interfaces to individual . medical devices / protocols via the smart cables.

{2}------------------------------------------------

MedApps, Inc. 510(k) SUMMARY

K083862 p.3/7

. For complete comparison of predicate devices see paragraph D - TECHNOLOGICAL CHARACTERISTICS SUMMARY table below. please reference Exhibit 08 - System Additionally, Requirements Specifications (FDA-SRS-8009) document for complete software / system functionality.
(3) MedApps HealthLINK hardware / software:

The HealthLINK hardware / software plugs into off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, and transmit the data via wireless to a receiver that it is already paired with. This functionality was cleared in the MedApps D-PAL submission K062377 in July 2007.

(4) MedApps HealthPOD hardware / software:
The HealthPOD hardware / software is an extension of the HealthPAL functionality that is outlined in this submission. HealthPOD acts as a "docking" station for the HealthPAL in order to recharge batteries, take in additional connections to off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, via smart cables (per validated in HealthPAL software), add a backup communication method via phone line (POTS line), and communicate via wireless to HealthPAL or additional HealthPODs.
(5) MedApps HealthCOM software application:
The software application allows caregivers to set thresholds and review patient data on the secure HealthCOM website.

The HealthCOM software also allows the patient to establish an account and to direct / authorize their data to be directed to an outside, validated Personal Health Record (PHR), Electronic Health Record (EHR or EMR).

(6) MedApps IVR software application:
The software application calls the patient on any phone that is designated in their user profile, and executes an approved ("canned") script to gather information. ("Your nurse would like to talk to you, can I connect you now", "We haven't received a reading from you today, please send us your readings").

In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and many other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on parameters / thresholds set in the HealthCOM system.

{3}------------------------------------------------

K083862 p. 4/7

INDICATIONS FOR USE C.

Feature	Intel HealthGuide PHS6000K080798	Confidant 2.5K072698	MedAppsSubmissionK083862
Indications ofUse	Enables healthcareproviders tomonitor andmanage chronicconditions ofpatients remotely	Same	Same
Intended Use	TelemedicineSystem	Same	Same
Intended Users	Home users andHealthcareproviders	Same	Same
Site of Use	Home (HealthPAL),Clinic (HealthCOM)	Same	Same
Data CollectionSoftware	Intel CareManagement SuiteSoftware	The HermesProprietarySoftware	MedAppsProprietarySoftware
SUMMARY			K083862
Feature	Intel HealthGuide PHS6000	Confidant 2.5	MedAppsSubmission
	K080798	K072698	K083862
Data CollectionSoftwareFunctionality	Transmit data fromSensor devices toCentral Database	Same	Same
Communicationmethod of hubwith CentralServer	Via DSL or PhoneLine Connection	Via Cellular Phone	Via EmbeddedCellularTechnology
Types of sensorswhich can beinterfaced (wiredor wirelessly) toreceiver hub	Medical Devicesdesigned forHome:GlucoseScaleBlood PressurePulse OxPeak Flow	Medical Devicesdesigned forHome:GlucoseScaleBlood Pressure	Medical Devicesdesigned forHome:GlucoseScaleBlood PressurePulse Ox
Maximumnumber and typeof measurementdevices that canbe connected tothe devices	Determined byvital sign devicesthat are designedfor Home use, andhave a data port.(Wireless or Wired)	Same	Same
Maximum datathroughputunder worst caseconditions	Multiple readingsare stored on themedical devicesand act as abackup if dataneeds to be re-sentto the server	Same	Same
Time Delay in theprocessing ofdata collectedand transmitted	Readings stored inthe medicaldevices can be sentup to the serverwhen theconnection isrestored.	Same	Same
Implementationmethod ofcollecting datafrom sensors	Short range radiosystem usingBluetooth andWired (tethered)cables.	Short range radiosystem usingBluetooth	Short range radiosystem usingBluetooth andWired (tethered)cables.
Sensor Software	Sensor Softwareunchanged	Same	Same
Connectivity	Short range radiosystem usingBluetooth andWired (tethered)cables.	Short range radiosystem usingBluetooth	Short range radiosystem usingBluetooth andWired (tethered)cables.
Communicationmethod of hubwith devices	Short range radiosystem usingBluetooth andWired (tethered)cables.	Short range radiosystem usingBluetooth	Short range radiosystem usingBluetooth andWired (tethered)cables.
SUMMARY
Feature	Intel HealthGuide PHS6000K080798	Confidant 2.5K072698	MedAppsSubmissionK083862
CommunicationsProtocol	Bluetooth V2.0 andWired (Tethered)	Bluetooth V2.0	Bluetooth V2.0 andWired (Tethered)
CommunicationFrequency	Bluetooth : 2.402to 2.480 GHz	Bluetooth : 2.402to 2.480 GHzGSM: 850 / 900 /1800 / 1950 Mhz	Bluetooth : 2.402to 2.480 GHzGSM: 850 / 900 /1800 / 1950 Mhz
Power Source	Wall power plug(120 VAC/50-60)	Wall power plug(120 VAC/50-60)and RechargeableBatteries in Device	Wall power plug(120 VAC/50-60)and RechargeableBatteries in Device
Display	On devices andhub, and monitorsconnected tocentral server	Same	Same
Communicationwith Patients	On screen display	Same	On screen displayof Readings, VoiceOutput andInteractive VoiceResponse (IVR)
Use ofThresholds /Algorithms fordetermining howThresholds areset and changed	Thresholds are setby Healthcareprofessionals inServer Software	Same	Same
Informationpresented to theuser, if it isdifferent fromthat presentedby themeasurementdevices	On screen display	Same	On screen displayof Readings, VoiceOutput andInteractive VoiceResponse (IVR)
Messages andInstructions thatcan be sent tothe User.	On screen display	Same	On screen displayof Readings, VoiceOutput andInteractive VoiceResponse (IVR)

TECHNOLOGICAL CHARACTERISTICS SUMMARY - as required by D. 807.92(a)(6)

{4}------------------------------------------------

、

・

、

. . . . . . .

EXHIBIT 02

{5}------------------------------------------------

Data Collection:

The 2 predicates and the MedApps solution connect to medical devices (designed for home use) via either through wired (cable) or wireless (bluetooth). The data is collected from the devices and sent up to the central server via various communication methods.

Telecommunication Platform to Central Server:

Intel Health uses DSL connectivity (wired point of care), Confidant uses an off the shelf Cell Phone (Cellular), and MedApps uses an embedded Machine to Machine (M2M) module that transmits the data via cellular connectivity.

{6}------------------------------------------------

EXHIBIT 02

K083862 p.7/7

Patient Feedback Technology:

On the 2 predicates and MedApps, data and messages are displayed on a screen for the patient to read and acknowledge. The MedApps solution also uses an Interactive Voice Response (IVR) system in order to call up the patient and ask them a question, or remind them to take their readings.

Backend Data Storage:

All systems (2 predicates and MedApps), have a backend system that allows data to be stored, and for Healthcare professionals to have the ability to monitor the patients data.

NON-CLINICAL PERFORMANCE DATA TESTING AND REVIEW - as E. required by 807.92(b)(1)

Non-Clinical Testing

The submitted device has undergone significant verification and validation testing, Alpha validation testing included testing of all executable code and functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP.

Alpha validation activities included exhaustive validation scripts of all Detail Design Specifications (DDS), which was summarized and discussed to provide a preliminary record of performance data. Additionally, the submitter duplicated the operational environment of a sophisticated user and provided the complete record of those executed scripts as operational performance data. The output of these two performance data records documents that MedApps 2.0 - Remote Patient Monitoring System met its required requirements and design specifications as intended.

F. SUBSTANTIAL EQUIVALENT

The MedApps Remote Patient Monitoring System 2.0 is substantially equivalent to the predicate devices in terms of data collection software functionality, operating system for the patient device, communication method of patient device with central server, types of sensors which can be interfaced to the patient device, implementation method of collecting data from sensors, sensor software, connectivity, communication protocol, power source and display method.

G. SAFETY AND EFFICACY

The MedApps Remote Patient Monitoring System 2.0 does not rely on an assessment of clinical performance data. The device conforms to FDA's recognized consensus standards and relies on its conformity to demonstrate its safety and efficacy. The device introduces no new questions concerning the safety or efficacy and is, therefore, substantially equivalent to the predicate devices.

{7}------------------------------------------------

DEPARTMENT OF HEALTH & HUMAN SERVICES

Image /page/7/Picture/1 description: The image shows the logo for the U.S. Department of Health & Human Services. The logo features a stylized eagle with its wings spread, and the words "DEPARTMENT OF HEALTH & HUMAN SERVICES. USA" are arranged in a circular pattern around the eagle. The eagle is black, and the text is also black. The background is white.

Public Health Service

Food and Drug Administration 9200 Corporate Boulevard Rockville MD 20850 ..

JUN ~ 5 2009

MedApps, Inc. c/o Mr. Kent Dicks President & CEO 7975 North Hayden Road, Suite A-200 Scottsdale, AZ 85258

Re: K083862

Trade/Device Name: MedApps 2.0 Remote Patient Monitoring System Regulation Number: 21 CFR 870.2910 Regulation Name: Radiofrequency physiological signal transmitter and receiver Regulatory Class: Class II Product Code: DRG Dated: March 31, 2009 Received: April 1, 2009

Dear Mr. Dicks:

We have reviewed your Section 510(k) premarket notification of intent to market the device referenced above and have determined the device is substantially equivalent (for the indications for use stated in the enclosure) to legally marketed predicate devices marketed in interstate commerce prior to May 28, 1976, the enactment date of the Medical Device Amendments, or to devices that have been reclassified in accordance with the provisions of the Federal Food, Drug, and Cosmetic Act (Act) that do not require approval of a premarket approval application (PMA). You may, therefore, market the device, subject to the general controls provisions of the Act. The general controls provisions of the Act include requirements for annual registration, listing of devices, good manufacturing practice, labeling, and prohibitions against misbranding and adulteration.

If your device is classified (see above) into either class II (Special Controls) or class III (PMA), it may be subject to additional controls. Existing major regulations affecting your device can be found in the Code of Federal Regulations, Title 21, Parts 800 to 898. In addition, FDA may publish further announcements concerning your device in the Federal Register.

Please be advised that FDA's issuance of a substantial equivalence determination does not mean that FDA has made a determination that your device complies with other requirements of the Act or any Federal statutes and regulations administered by other Federal agencies. You must comply with all the Act's requirements, including, but not limited to: registration and listing (21 CFR Part 807); labeling (21 CFR Part 801); medical device reporting (reporting of medical

{8}------------------------------------------------

Page 2 - Mr. Kent Dicks

device-related adverse events) (21 CFR 803); good manufacturing practice requirements as set forth in the quality systems (QS) regulation (21 CFR Part 820); and if applicable, the electronic product radiation control provisions (Sections 531-542 of the Act); 21 CFR 1000-1050.

If you desire specific advice for your device on our labeling regulation (21 CFR Part 801), please go to http://www.fda.gov/AboutFDA/CentersOffices/CDRH/CDRHOffices/ucm115809.htm for the Center for Devices and Radiological Health's (CDRH's) Office of Compliance. Also, please note the regulation entitled, "Misbranding by reference to premarket notification" (21CFR Part 807.97). For questions regarding the reporting of adverse events under the MDR regulation (21 CFR Part 803), please go to http://www.fda.gov/cdrh/mdr/ for the CDRH's Office of Surveillance and Biometrics/Division of Postmarket Surveillance.

You may obtain other general information on your responsibilities under the Act from the Division of Small Manufacturers, International and Consumer Assistance at its toll-free number (800) 638-2041 or (240) 276-3150 or at its Internet address http://www.fda.gov/cdrh/industry/support/index.html.

Sincerely yours,

Dina R. Rohner

Bram D. Zuckerman, M.D. Director Division of Cardiovascular Devices Office of Device Evaluation Center for Devices and Radiological Health

Enclosure

{9}------------------------------------------------

MedApps, Inc.
STATEMENT OF INDICATIONS FOR USE

510(k) Number: _K083862

Preparation Date:

December 23, 2008

Device Name:

MedApps 2.0 - Remote Patient Monitoring System

Indications For Use:

The MedApps 2.0 - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. The data is made available to the patients when time-critical care is not required. . The device is contraindicated for patients requiring direct medical supervision or emergency intervention.

(PLEASE DO NOT WRITE BELOW THIS LINE - CONTINUE ON ANOTHER PAGE IF NEEDED)

Concurrence of CDRH, Office of Device Evaluation (ODE)

Prescription Use (Per 21 CFR 801.109) OR Over-The-Counter Use

Dunia R. James

Division of Cardiovascular Devices

510(k) Number K083862

Regulation Number and Section

§ 870.2910 Radiofrequency physiological signal transmitter and receiver.

(a)
Identification. A radiofrequency physiological signal transmitter and receiver is a device used to condition a physiological signal so that it can be transmitted via radiofrequency from one location to another, e.g., a central monitoring station. The received signal is reconditioned by the device into its original format so that it can be displayed.(b)
Classification. Class II (performance standards).