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.

Device Description

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.

AI/ML Overview

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.

Summary

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

PREMARKET NOTIFICATION 510(k) SUMMARY As required by §807.92

Device Name - as required by 807.92(a)(2):

510(k) Number:	K062377
Trade Name:	MedApps™ Remote Patient Monitoring System
Common/Classification Name:	Transmitters and Receivers, Physiological Signal,Radiofrequency
Classification Regulation:	870.2910
Device Class:	Class II
Product Code (Procode):	DRG
Premarket Notification submitter:Company Name:Company Address:	MedApps, Inc.7975 North Hayden Road,Suite B-200, Scottsdale, AZ 85258
Contact:	Kent E. Dicks, President and CEO
Preparation Date:Revision Date:	August 14, 2006April 3, 2007

A. LEGALLY MARKETED PREDICATE DEVICE – as required by 807.92(a)(3)

Legally marketed predicate device are: K061328 Think Positive (t+) Diabetes Management System The Hermes System K050929

The submitted device is intended to be an accessory device to the OneTouch® Ultra® Blood Glucose Monitoring System LifeScan (K024194/K043197).

DEVICE DESCRIPTION - as required by 807.92(a)(4) B.

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.

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

Once all the data is collected, then it is stored in a repository for access by the healthcare provider,

C. INTENDED USE - as required by 807.92(a)(5)

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.

D. INDICATIONS FOR USE

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 for emergency calls, and may not be used for transmission or indication of any real-time alarms or time-critical data.

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

MedApps, Inc. 510(k) SUMMARY

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.

E. LEVEL OF CONCERN - as requested by recent FDA guidance

The FDA guidance document "Guidance For The Content of Premarket Submissions For Software Contained In Medical Devices," May 11, 2005, clearly identifies that all manufacturers of software devices are responsible for determining a Level of Concern for their device(s).

MedApps, Inc. believes that this device, because of its functional characteristics and intended uses, has a MODERATE LEVEL OF CONCERN. See Exhibit 4, Level of Concern.

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

Feature	Think PositiveK061328	The HermesK050929	MedApps(SubmissionDevice)
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, Clinic	Same	Same
Data CollectionSoftware	Think PositiveProprietarySoftware	The HermesProprietarySoftware	MedAppsProprietarySoftware
Data CollectionSoftwareFunctionality	Transmit data fromSensor devices toCentral Database	Same	Same
Communicationmethod of hubwith CentralServer	Via Cellular Phone	Same	Same
Feature	Think PositiveK061328	The HermesK050929	MedApps(SubmissionDevice)
Types of sensorswhich can beinterfaced (wiredor wirelessly) toreceiver hub	Glucose Levels	Same	Same
Implementationmethod ofcollecting datafrom sensors	Short range radiosystem usingBluetooth andCellular technology	Same	Same
Sensor Software	Sensor Softwareunchanged	Same	Same
Connectivity	Short range radiosystem usingBluetooth andCellular technology	Same	Same
Communicationmethod of hubwith devices	Short range radiosystem usingBluetooth andCellular technology	Same	Same
CommunicationsProtocol	Bluetooth V1.2	Same	Same
CommunicationFrequency	2.402 to 2.480GHz	Same	Same
Power Source	Wall power plug forhub (120 VAC/50-60) and batteriesin devices	Same	Same
Display	On devices andhub, and monitorsconnected tocentral server	Same	Same
Communicationwith Patients	On screen display	Same	On screen displayof Readings andInteractive VoiceResponse (IVR)

000005

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

MedApps, Inc.

510(k) SUMMARY

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

NON-CLINICAL PERFORMANCE DATA TESTING AND REVIEW - as G. 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 Software Design Specifications (SDS), 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 Wellness System met its required requirements and design specifications as intended.

H. SUBSTANTIAL EQUIVALENCE SUMMARY

The submitted device, MedApps Wellness System, has the same indications for use as the predicate devices, Think Positive (t+) Diabetes Management System and The Hermes System.

I. CONCLUSIONS

The performance and usability testing and validation studies document that MedApps Wellness System is substantially equivalent to the predicate Think Positive (t+) Diabetes Management System and The Hermes System.

000007

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

DEPARTMENT OF HEALTH & HUMAN SERVICES

Image /page/5/Picture/1 description: The image shows the logo for the U.S. Department of Health & Human Services. The logo consists of a stylized eagle with its wings spread, and three horizontal lines below the eagle. The text "DEPARTMENT OF HEALTH & HUMAN SERVICES - USA" is arranged in a circular pattern around the eagle.

Food and Drug Administration 2098 Gaither Road Rockville MD 20850

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

JUL - 3 2007

Re: K062377

Trade/Device Name: MedApps™ Remote Patient Monitoring System Regulation Number: 21 CFR 862.1345 Regulation Name: Glucose test system Regulatory Class: Class II Product Code: NBW Dated: June 26, 2007 Received: June 27, 2007

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 such additional controls. Existing major regulations affecting your device can be found in Title 21, Code of Federal Regulations (CFR), Parts 800 to 895. 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 Parts 801 and 809); and good manufacturing practice requirements as set forth in the quality systems (QS) regulation (21 CFR Part 820).

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

This letter will allow you to begin marketing your device as described in your Section 510(k) premarket notification. The FDA finding of substantial equivalence of your device to 10(a) marketed predicate device results in a classification for your device on thus, server to your device to proceed to the market.

If you desire specific information about the application of labeling requirements to your device, or questions on the promotion and advertising of your device, please contact the Office of In Vitro Diagnostic Device Evaluation and Safety at (240) 276-0490. Also, please onte the regulation entitled, "Misbranding by reference to premarket notification" (21CFR Part 807.97). You may obtain other general information on your responsibilities under the Act from the Division of Small Manufacturers, International and Consumer Assistance at its tolloh inc (800) 638-2041 or (240) 276-3150 or at its Internet address at http://www.fda.gov/cdrh/industry/support/index.html.

Sincerely vours.

Jean M. Cooper, M.S., D.V.M.

Sean M. Cooper, M.S., D.V.M. Director Division of Chemistry and Toxicology Office of In Vitro Diagnostic Device Evaluation and Safety Center for Devices and Radiological Health

Enclosure

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

Indication for Use

510(k) Number (if known): K062377

Device Name: MedApps™ Remote Patient Monitoring System

Indication For Use:

The MedApps Remote Patient Monitoring 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)

The MedApps Remote Patient Monitoring 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 Remote Patient Monitoring System is not intended for emergency calls, and may not be used for transmission or indication of any real-time alarms or timecritical 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.

Prescription Use (21 CFR Part 801 Subpart D) And/Or

Over the Counter Use X (21 CFR Part 801 Subpart C)

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

Concurrence of CDRH, Office of In Vitro Diagnostic Device Evaluation and Safety (OIVD)

Carol Benson
Division Sign-Off

Office of In Vitro Diagnostic Device Evaluation and Safety

K062377

Page 1 of 1

Regulation Number and Section

§ 862.1345 Glucose test system.

(a)
Identification. A glucose test system is a device intended to measure glucose quantitatively in blood and other body fluids. Glucose measurements are used in the diagnosis and treatment of carbohydrate metabolism disorders including diabetes mellitus, neonatal hypoglycemia, and idiopathic hypoglycemia, and of pancreatic islet cell carcinoma.(b)
Classification. Class II (special controls). The device, when it is solely intended for use as a drink to test glucose tolerance, is exempt from the premarket notification procedures in subpart E of part 807 of this chapter subject to the limitations in § 862.9.