AI/ML, Software as a Medical Device, Real-World Evidence
Real-World Evidence
Submission
Device
Sponsor
RWD Sources
RWE Use Summary
Key Tags
K183282 · Aug 15, 2019
Biovitals Analytics Engine
Biofourmis Singapore Pte., Ltd.
Emergency department patient medical records/clinical data
The study used retrospective clinical data from 50 emergency department patients to compute expected within-subject variability for the Biovitals Index and to validate the index performance against physician assessments of patient vital sign relationships.
50 emergency department patients deemed appropriate for home monitoring; Sample Size: 50
Panel of three physicians
Correlation of Biovitals Index (BI) to changes in vital sign relationships; Positive Percent Agreement (PPA)
AI Performance
Output
Algorithm
Acceptance
Observed
Dev DS
Dev Readers
Test DS
Test Readers
Biovitals Index
—
lower bound of 95% confidence interval of PPA > 0.7
lower bound of 95% confidence interval of PPA > 0.7
—
—
Clinical study of 50 emergency department patients
3 (physicians)
Indications for Use
The Biovitals Analytic Engine (BA Engine) is intended to be used with continuous biometric data from already cleared sensors measuring heart rate, respiratory rate, and activity in ambulatory patients being monitored in a healthcare facility or at home, during periods of minimal activity. The device learns the correlation between multiple vital signs during the patient's daily activity and builds an individualized biometric signature which is dynamically updated based on incoming data. The device computes a time series Biovitals Index (BI), which reflects changes in the patient's measured vital signs from their measured baseline, which is derived from the individualized biometric signature of the patient. The BA Engine is a cloud-based software engine, intended to be an adjunct to and is not intended to replace vital signs monitoring. The BI is intended for daily intermittent, retrospective review by a qualified practitioner. The BA Engine is intended to provide additional information for use during routine patient monitoring. The BL is not intended for making clinical decisions regarding patient treatment or for diagnostic purposes.
Device Story
Cloud-based software engine; processes continuous biometric data (heart rate, respiratory rate, activity) from cleared sensors; builds individualized biometric signature via proprietary algorithm; dynamically updates baseline; computes time-series Biovitals Index (BI) (0-1 scale) reflecting vital sign relationship changes; output stored in cloud database; accessed via web API; visualized on dashboard for qualified practitioner; intended for daily intermittent, retrospective review; adjunct to routine monitoring; provides additional information; does not replace vital signs monitoring; not for diagnostic or clinical decision-making; benefits include longitudinal monitoring of patient physiological trends.
Clinical Evidence
Clinical study of 50 emergency department patients deemed appropriate for home monitoring. Performance of Biovitals Index (BI) compared against a panel of three physicians evaluating changes in vital sign relationships. Results showed BI correlated with physician assessment; lower bound of 95% CI for positive percent agreement (PPA) > 0.7.
Technological Characteristics
Cloud-based software engine; no physical hardware. Proprietary algorithm for biometric signature generation and BI calculation. Connectivity via secure API. Software developed per IEC 62304:2015; usability per IEC 62366-1:2015. Moderate level of concern.
Indications for Use
Indicated for adult ambulatory patients monitored in healthcare facilities or at home during periods of minimal activity. Used with continuous biometric data (heart rate, respiratory rate, activity) from cleared sensors. Not for diagnostic use or clinical treatment decisions.
Regulatory Classification
Identification
A cardiac monitor (including cardiotachometer and rate alarm) is a device used to measure the heart rate from an analog signal produced by an electrocardiograph, vectorcardiograph, or blood pressure monitor. This device may sound an alarm when the heart rate falls outside preset upper and lower limits.
{0}------------------------------------------------
Image /page/0/Picture/0 description: The image shows the logos of the Department of Health & Human Services and the Food and Drug Administration (FDA). The Department of Health & Human Services logo is on the left, and the FDA logo is on the right. The FDA logo includes the letters "FDA" in a blue box, followed by the words "U.S. FOOD & DRUG ADMINISTRATION" in blue text.
August 15, 2019
Biofourmis Singapore Pte. Ltd % Rakesh Lal Consultant Rakesh Lal 7 Courtyard Pl Lexington, Massachusetts 02420
Re: K183282
Trade/Device Name: Biovitals Analytics Engine Regulation Number: 21 CFR 870.2300 Regulation Name: Cardiac Monitor (Including Cardiotachometer And Rate Alarm) Regulatory Class: Class II Product Code: PLB Dated: July 18, 2019 Received: July 19, 2019
Dear Rakesh Lal:
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. Although this letter refers to your product as a device, please be aware that some cleared products may instead be combination products. The 510(k) Premarket Notification Database located at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpmn/pmn.cfm identifies combination product submissions. 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. Please note: CDRH does not evaluate information related to contract liability warranties. We remind you, however, that device labeling must be truthful and not misleading.
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
{1}------------------------------------------------
requirements, including, but not limited to: registration and listing (21 CFR Part 807); labeling (21 CFR Part 801); medical device reporting of medical device-related adverse events) (21 CFR 803) for devices or postmarketing safety reporting (21 CFR 4, Subpart B) for combination products (see https://www.fda.gov/combination-products/guidance-regulatory-information/postmarketing-safety-reportingcombination-products); good manufacturing practice requirements as set forth in the quality systems (OS) regulation (21 CFR Part 820) for devices or current good manufacturing practices (21 CFR 4, Subpart A) for combination products; and, if applicable, the electronic product radiation control provisions (Sections 531-542 of the Act); 21 CFR 1000-1050.
Also, please note the regulation entitled, "Misbranding by reference to premarket notification" (21 CFR Part 807.97). For questions regarding the reporting of adverse events under the MDR regulation (21 CFR Part 803), please go to https://www.fda.gov/medical-device-safety/medical-device-reportingmdr-how-report-medical-device-problems.
For comprehensive regulatory information about medical devices and radiation-emitting products, including information about labeling regulations, please see Device Advice (https://www.fda.gov/medicaldevices/device-advice-comprehensive-regulatory-assistance) and CDRH Learn (https://www.fda.gov/training-and-continuing-education/cdrh-learn). Additionally, you may contact the Division of Industry and Consumer Education (DICE) to ask a question about a specific regulatory topic. See the DICE website (https://www.fda.gov/medical-device-advice-comprehensive-regulatoryassistance/contact-us-division-industry-and-consumer-education-dice) for more information or contact DICE by email (DICE@fda.hhs.gov) or phone (1-800-638-2041 or 301-796-7100).
Sincerely,
Stephen Browning Acting Assistant Director Division of Cardiac Electrophysiology, Diagnostics and Monitoring Devices Office of Cardiovascular Devices Office of Product Evaluation and Ouality Center for Devices and Radiological Health
Enclosure
{2}------------------------------------------------
# Indications for Use
510(k) Number (if known) K183282
Device Name Biovitals Analytics Engine
#### Indications for Use (Describe)
The Biovitals Analytic Engine (BA Engine) is intended to be used with continuous biometric data from already cleared sensors measuring heart rate, respiratory rate, and activity in ambulatory patients being monitored in a healthcare facility or at home, during periods of minimal activity. The device learns the correlation between multiple vital signs during the patient's daily activity and builds an individualized biometric signature which is dynamically updated based on incoming data. The device computes a time series Biovitals Index (BI), which reflects changes in the patient's measured vital signs from their measured baseline, which is derived from the individualized biometric signature of the patient.
The BA Engine is a cloud-based software engine, intended to be an adjunct to and is not intended to replace vital signs monitoring. The BI is intended for daily intermittent, retrospective review by a qualified practitioner. The BA Engine is intended to provide additional information for use during routine patient monitoring. The BL is not intended for making clinical decisions regarding patient treatment or for diagnostic purposes.
The device is intended for an adult population.
| Type of Use ( <i>Select one or both, as applicable</i> ) |
|----------------------------------------------------------|
|----------------------------------------------------------|
| <div> <span> ☑ Prescription Use (Part 21 CFR 801 Subpart D) </span> </div> |
|-----------------------------------------------------------------------------------|
| <div> <span> ☐ Over-The-Counter Use (21 CFR 801 Subpart C) </span> </div> |
#### CONTINUE ON A SEPARATE PAGE IF NEEDED.
This section applies only to requirements of the Paperwork Reduction Act of 1995.
#### *DO NOT SEND YOUR COMPLETED FORM TO THE PRA STAFF EMAIL ADDRESS BELOW.*
The burden time for this collection of information is estimated to average 79 hours per response, including the time to review instructions, search existing data sources, gather and maintain the data needed and complete and review the collection of information. Send comments regarding this burden estimate or any other aspect of this information collection, including suggestions for reducing this burden, to:
> Department of Health and Human Services Food and Drug Administration Office of Chief Information Officer Paperwork Reduction Act (PRA) Staff PRAStaff(@fda.hhs.gov
"An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB number."
{3}------------------------------------------------
# Premarket Notification 510(k) Summary
This summary of 510(k) safety and effectiveness information is submitted in accordance with the requirements of SMDA 1990 and 21 CFR 807.92.
#### Applicant Information:
| Date Prepared: | July 16, 2019 |
|-----------------|----------------------------------------------------------------|
| Name: | Biofourmis Singapore Pte. Ltd. |
| Address: | Vision Exchange, #07-15<br>2 Venture Drive<br>Singapore 608526 |
| Contact Person: | Rakesh M. Lal, Consultant<br>rakesh.m.lal@gmail.com |
| Phone: | (817) 734-8303 |
#### Device Information:
| Trade Name: | Biovitals Analytics Engine |
|---------------------------|----------------------------|
| Common Names: | BA Engine |
| Classification Name(s): | Cardiovascular |
| Product Code/ Regulation: | PLB/21 CFR 870.2300 |
| Classification: | Class II |
#### Predicate Device:
- PhysIQ PPA Engine - K142512
#### Device Description:
Biovitals Analytics Engine consists of:
- An automated proprietary algorithm to analyze data and generate Biovitals Index. ●
- A cloud-based database to store the input, intermedium output and the final output ●
- A web application programming interface (API) which handle the continuous physiology data.
- A web application programming interface (API) query the databases and get output.
- A web dashboard to render the BA Engine output in a continuous graph format, which can ● help intended users to monitor a patient's Biovitals Index.
Biovitals Analytics Engine works in the following sequence:
- Accept input data via secure API;
- Analyze the input data using Biovitals Analytics Engine proprietary algorithm, which ● generate Biovitals Index:
{4}------------------------------------------------
- Personal physiology signature data base initialization (at the early stage on the о algorithm when the engine learns the patients and builds the personal baseline)
- Biovitals Index calculation o
- Biovitals Analytics engine generates the Biovitals Index which is a time series scalar value from 0 to 1.
- The output of BA Engine is stored in a cloud-based database.
- The output API queries the databases and gets the output, and the output shall be reviewed by the qualified practitioner via a dashboard.
# Interpretation of Biovitals Index:
The BA Engine computes a time series Biovitals Index (BI), which reflects changes in the patient's measured vital signs from their measured baseline, which is derived from the individualized biometric signature of the patient. The BI is displayed in 30-minute segments and ranges from 0 to 1. The BI is intended for daily intermittent, retrospective review by a qualified practitioner.
A BI closer to 0 indicates that the relationships among the patient's vital signs are similar to the baseline. A BI value closer to 1 indicates that the relationships among the patient's vital signs are different from the baseline is initially established using data from the first 24 hours and updated periodically as new data is received. The initial baseline comprises 3 to 13 hours of data and the updated baseline usually comprises the last 9 to 45 hours of data with low change in the relationship among the vital signs, depending on the monitoring duration.
To aid in understanding the magnitude of changes in the relationship among the patient's vital signs as compared to the baseline, the BI is divided into three categories. A BI less than or equal to 0.3 indicates that there has been little or no change in the relationship among the patient's vital signs as compared to baseline. A BI value greater than 0.3 and less than or equal to 0.7 reflects moderate change, and a BI value greater than 0.7 reflects significant change in the relationship among the patient's vital signs as compared to baseline.
The expected within-subject variability for each of the three ranges of the BI are shown in the table below.
| BI Category | Expected within-subject variability |
|------------------------------|-------------------------------------|
| Low (BI ≤ 0.3) | 0.11 |
| Moderate (0.3 < BI ≤<br>0.7) | 0.27 |
| Significant (BI > 0.7) | 0.17 |
The expected within-subject variability was computed using data from a clinical study involving 50 emergency department patients that were deemed appropriate for home monitoring.
{5}------------------------------------------------
#### Indications for Use:
The Biovitals Analytic Engine (BA Engine) is intended to be used with continuous biometric data from already cleared sensors measuring heart rate, respiratory rate, and activity in ambulatory patients being monitored in a healthcare facility or at home, during periods of minimal activity. The device learns the correlation between multiple vital signs during the patient's daily activity and builds an individualized biometric signature which is dynamically updated based on incoming data. The device computes a time series Biovitals Index (BI), which reflects changes in the patient's measured vital signs from their measured baseline, which is derived from the individualized biometric signature of the patient.
The BA Engine is a cloud-based software engine, intended to be an adjunct to and is not intended to replace vital signs monitoring. The BI is intended for daily intermittent, retrospective review by a qualified practitioner. The BA Engine is intended to provide additional information for use during routine patient monitoring. The BI is not intended for making clinical decisions regarding patient treatment or for diagnostic purposes.
The device is intended for an adult population.
### Summary Comparison to Predicate:
The following tables provide a summary of substantial equivalence between the subject device and the cited predicate. The subject device has the same intended use and substantially equivalent characteristics that do not raise different questions of safety or effectiveness.
### Comparison to Predicate Device:
The following table provides a comparison of the detection features of Biovitals Analytics Engine and the predicate device:
| Features | Biofourmis<br>Biovitals Analytics<br>Engine | PhysIQ<br>PPA Engine<br>(K142512) | Comparison |
|----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| General Characteristics | | | |
| Classification | Class II, 21 CFR 870.2300 | Class II, 21 CFR 870.2300 | Equivalent |
| Product Code | PLB | PLB | Equivalent |
| Intended Use | Patient Monitor (without<br>alarms) | Patient Monitor (without<br>alarms) | Equivalent |
| Indications for<br>Use | The Biovitals Analytic<br>Engine (BA Engine) is<br>intended to be used with<br>continuous biometric data<br>from already cleared<br>sensors measuring heart | The Personalized<br>Physiology Engine (PPA<br>Engine) is intended to be<br>used with data from<br>already cleared sensors<br>measuring physiological | Equivalent – both devices<br>are intended to provide an<br>index to a physician based<br>a patient's on vital signs,<br>to provide additional<br>information during routine |
| Features | Biofourmis | PhysIQ | Comparison |
| | Biovitals Analytics<br>Engine | PPA Engine<br>(K142512) | |
| | rate, respiratory rate, and<br>activity in ambulatory<br>patients being monitored<br>in a healthcare facility or<br>at home, during periods of<br>minimal activity. The<br>device learns the<br>correlation between<br>multiple vital signs during<br>the patient's daily activity<br>and builds an<br>individualized biometric<br>signature which is<br>dynamically updated<br>based on incoming data.<br>The device computes a<br>time series Biovitals Index<br>(BI), which reflects<br>changes in the patient's<br>measured vital signs from<br>their measured baseline,<br>which is derived from the<br>individualized biometric<br>signature of the patient. | parameters, including<br>heart rate, respiratory rate,<br>and activity in ambulatory<br>patients being monitored<br>in a healthcare facility or<br>at home. The device<br>provides a time series<br>Multivariate Change Index<br>(MCI) which indicates<br>whether the relationships<br>among the patient's<br>monitored vital signs<br>change from those<br>measured at baseline,<br>which has been derived<br>from measurements<br>previously obtained during<br>routine activities of daily<br>living. The MCI is based<br>on an integrated<br>computation evaluating<br>changes in the parameters<br>and their relationships to<br>each other. | patient monitoring.<br>Neither device is intended<br>to replace vital signs<br>monitoring, nor is either<br>device intended to provide<br>a diagnosis to the<br>physician. |
| | The BA Engine is a cloud-<br>based software engine,<br>intended to be an adjunct<br>to and is not intended to<br>replace vital signs<br>monitoring. The BI is<br>intended for daily<br>intermittent, retrospective<br>review by a qualified<br>practitioner. The BA<br>Engine is intended to<br>provide additional<br>information for use during<br>routine patient monitoring.<br>The BI is not intended for<br>making clinical decisions<br>regarding patient treatment<br>or for diagnostic purposes.<br>The device is intended for<br>an adult population. | The PPA Engine is an<br>adjunct to and is not<br>intended to replace vital<br>signs monitoring. The<br>MCI is intended for daily<br>intermittent, retrospective<br>review by a qualified<br>practitioner. The PPA<br>Engine is intended to<br>provide additional<br>information for use during<br>routine patient monitoring.<br>The MCI is not intended<br>for making clinical<br>decisions regarding patient<br>treatment or for diagnostic<br>purposes. | |
| Features | Biofourmis<br>Biovitals Analytics<br>Engine | PhysIQ<br>PPA Engine<br>(K142512) | Comparison |
| Patient<br>Population &<br>Environment | Ambulatory Non-<br>pediatric | Ambulatory Non-<br>pediatric | Equivalent |
| Technological Characteristics | | | |
| Components | Cloud-based Software<br>only | Software only | Equivalent - the only<br>differences arise with<br>regard to the specific<br>implementation (software<br>architecture, programming<br>languages, etc.). These<br>minor differences do not<br>raise new questions of<br>safety and effectiveness. |
| Index<br>Produced | Non-linear combination of<br>vital parameters | Non-linear combination of<br>vital parameters | Equivalent - while the<br>specific combination of<br>the index may be different,<br>the general approach,<br>meaning of the index and<br>use of baseline<br>information are the same. |
| Index Meaning | Index represents how<br>different the relationships<br>among the patient's vital<br>signs are with respect to<br>normality.<br>A BI less than or equal to<br>0.3 indicates that there has<br>been little or no change in<br>the relationship among the<br>patient's vital signs as<br>compared to baseline. A<br>BI value greater than 0.3<br>and less than or equal to<br>0.7 reflects moderate<br>change, and a BI value<br>greater than 0.7 reflects<br>significant change in the<br>relationship among the<br>patient's vital signs as<br>compared to baseline. | Index represents how<br>different the relationships<br>among the patient's vital<br>signs are with respect to<br>normality.<br>An MCI value closer to<br>zero (0) indicates that the<br>monitored relationships<br>among the vital signs are<br>similar to the learned<br>baseline. An MCI value<br>closer to one (1) indicates<br>that the patient's<br>monitored relationships<br>among the vital signs are<br>likely to be different from<br>the learned baseline. | Equivalent - the devices<br>have a different<br>interpretation of the index<br>specific to its software<br>implementation, but the<br>interpretation is<br>conceptually similar, and<br>this difference does not<br>raise new questions of<br>safety and effectiveness. |
| Index<br>Algorithm<br>Normality | Normality is defined as the<br>patient's own baseline.<br>The baseline is initially<br>established using data<br>from the first 24 hours and | Normality is defined as the<br>patient's own baseline | Equivalent - the subject<br>device's baseline is<br>periodically updated but<br>still reflects the same<br>relationship among vital |
| Features | Biofourmis<br>Biovitals Analytics<br>Engine | PhysIQ<br>PPA Engine<br>(K142512) | Comparison |
| | updated periodically as<br>new data is received. | | signs as initially<br>established in the first 24<br>hours. This difference does<br>not raise new questions of<br>safety and effectiveness. |
| Index Display | Single numeric value of<br>latest index | Single numeric value of<br>latest index | Equivalent - specific<br>differences in the user<br>interface do not raise<br>different questions of<br>safety and effectiveness. |
| | Trend graphs | Trend graphs<br>Table | |
| Vital Signs<br>Data Source | FDA cleared Patient<br>Monitors and Clinical<br>Information Systems | Clinical Information<br>Systems | Equivalent - the subject<br>device enables use of data<br>captured directly from<br>FDA cleared patient<br>monitors. The predicate<br>device also uses data from<br>FDA cleared devices but<br>obtains the data through<br>integration with Clinical<br>Information Systems.<br>Since the actual sensor<br>data is the same, this<br>difference does not raise<br>new questions of safety<br>and effectiveness. |
| Alarm System | No | No | Equivalent |
{6}------------------------------------------------
{7}------------------------------------------------
{8}------------------------------------------------
#### Summary of Performance Testing
Tests have been performed in compliance with the appropriate recognized consensus standards. Testing described in this 510(k) consisted of verification of all design input requirements and product specifications. No residual anomalies appeared during verification and software validation tests. General usability tests, analyzing the users' ability to login, upload, review and download were performed and met all requirements. All software validation testing was completed successfully and met all requirements.
# Summary of Clinical Testing
Clinical testing was performed with the BA Engine to evaluate the performance of the Biovitals Index. The testing was performed on a total of 50 subjects presenting at an Emergency Department,
#### K183282
{9}------------------------------------------------
who were deemed appropriate for home monitoring, and compared the performance of the BI against a panel of three physicians evaluating the changes in the relationship among the patients' vital sign parameters. The testing showed that the BI was correlated to the changes in relationship among vital sign parameters, with a lower bound of the 95% confidence interval of the positive percent agreement (PPA) greater than 0.7.
#### Software
Biofourmis followed IEC 62304:2015 and the FDA Guidance Document, "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (January, 2002) with respect to software development and validation. The Biofourmis software is classified as a "moderate level of concern" per the FDA guidance document.
### Verification and validation testing were completed in compliance with the following standards and guidance documents:
- AAMI ANSI IEC 62304:2015, Medical device software Software life cycle processes ●
- General Principles of Software Validation; Final Guidance for Industry and FDA Staff" ● (January 2002)
- IEC 62366-1 Edition 1.0 2015-02 Medical devices Application of usability engineering . to medical devices
### Conclusion
Based upon the intended use, product technical information, clinical and non-clinical testing and standards compliance provided in this premarket notification, Biovitals Analytics Engine has been shown to be substantially equivalent to the legally-marketed predicate.
Predicate graph will load when search results are available.
Embedding visualization will load when search results are available.
PDF viewer will load when search results are available.
Loading panels...
Select an item from Submissions
Click any panel, subpart, regulation, product code, or device to see details here.
Section Matches
Results will appear here.
Product Code Matches
Results will appear here.
Special Control Matches
Results will appear here.
Loading collections...
Loading
My Alerts
You will receive email notifications based on the filters and frequency you set for each alert.
Sort by:
Create Alert
Search Filters
Agent Token
Create a read-only bearer token for Claude, ChatGPT, or other agents that can call HTTP APIs.
Copy this now. It will not be shown again.
Connected apps
Apps you authorized through browser sign-in. Disconnecting revokes their access immediately.
Learn the FDA Browser
Two short videos show you everything — or skip straight to the written tutorial if you'd rather read. You can reopen this any time from the Tutorial button in the top bar.
Part 1 — Search, results, and everyday workflows 16 min
Part 2 — Embeddings: the galaxy map 3 min
1. Search: exact and fuzzy
Type a phrase like "coronary artery calcification" into the search box. You get two kinds of results. Exact results match the literal phrase — prefix searches work ("coronary artery calcificati") but suffix searches do not. Fuzzy results match on the meaning and intent of your phrase rather than the exact words, and are sorted by relevance score. Hover over the Exact or Fuzzy badge on any row to see exactly why it matched.
Use the checkboxes above the results to narrow: SaMD keeps only software-only devices, AI / ML keeps only devices with AI.
Exact vs. fuzzy search: what's the difference?
Exact matches on the literal phrase (prefix search works, suffix does not). Fuzzy matches on the meaning and intent of the phrase rather than the exact words. Hover over the badge on any row to see why it matched.
You search "coronary artery calcification" and want only software devices with AI. What two filters do you apply?
Narrow by SaMD (software-only devices), then narrow by AI/ML (devices with AI).
2. The results table
Scroll right in the results table. The intended use is extracted for you — no need to open the PDF. The device story gives a high-level snapshot of what the device does and how it's used. The AI Performance sub-table shows each output name, acceptance criteria, observed values, and development/test dataset descriptions — the same format Innolitics uses for regulatory strategy outputs, and the fastest high-level fingerprint of an AI device. It is AI-generated but has been very reliable in practice.
Where do you find a device's intended use without opening the PDF?
Scroll right in the search results table. The intended use column is extracted for you; no need to dig into the 510(k) summary PDF.
What does the AI Performance sub-table show, and why is it useful?
Output name, acceptance criteria, observed values, development dataset description, and test dataset description. It's the same format we use for regulatory strategy output and Fast 510(k) input, and the fastest high-level fingerprint of an AI device. AI-generated but reliable in practice.
3. Judging fuzzy relevance
Fuzzy results trail off in relevance as you scroll. Use three signals to decide how far down to go: the fuzzy badge explanations, the intended use column, and whether your target output (e.g., Cobb angle) still appears in the AI Performance sub-table. Once it stops appearing, you're past the relevant zone. A top hit with a low score (~0.4) and a stretched explanation is a hint the closest predicates are far away — the project may be headed for De Novo. Note the fuzzy search is a pattern match: it doesn't handle negation ("not") well, and hardware devices can appear — filter by SaMD/AI ML to cut them.
How do you judge how far down fuzzy search results to go?
Use the relevancy signals: the fuzzy badge explanations, the intended use column, and whether the target output (e.g., Cobb angle) still appears in the AI Performance sub-table. Once it stops appearing, results are trailing off in relevancy.
4. Device detail page: chat and citations
Click a device name to open its detail page: device facts on the left, a chat window on the right. Ask something like "Describe the training data". The answer carries little citation bubbles — click one to jump to the highlighted passage in the source PDF, so you can verify every AI answer against the document. There's also a Download PDF button for sharing.
How do you verify an AI chat answer on the device detail page?
Click the citation bubbles to jump to the relevant highlight in the source document.
Reading rule for every project: how many summaries do you read in full?
At least the three most relevant 510(k) or De Novo summaries, in full. After that, use targeted chat questions to confirm your memory quickly. The tool supports this professional habit — it doesn't replace it.
5. Side-by-side comparison
Select multiple rows in the results table (aim for under ~10), then open the PDF Viewer tab. Ask one question — it goes to all selected devices in parallel, each with citations. This is the fastest way to compare and contrast devices: training data, PCCP scope, how they handled adding new scanners, and so on.
What does the side-by-side PDF viewer mode do?
Select multiple devices, open the PDF viewer tab, and ask one question (e.g., "Describe the training data"). It queries all selected devices simultaneously with citations, so you can compare and contrast quickly.
6. Collections
With rows selected, go to the Collections tab and create a labeled collection (e.g., "Cobb Angle Project"). Reload that selection any time — before a client call, pull up the collection and ask questions across all of its devices at once.
How do you save a set of selected devices for later use?
Select the rows, go to the Collections tab, and create a labeled collection (e.g., "Cobb Angle Project"). You can reload the selection anytime and carry it into the PDF viewer and other tabs that support selections.
7. Product codes and the regulations tree
Click a product code in the results to jump to it in the regulations tree — identification text, sibling product codes, and devices you can open in a PDF viewer on the right. Click a regulation number to see its identification, special controls, and related product codes. You can also search by product code or regulation number at the top of the tree. Always read the special controls if any exist for your device — it broadens your search and sharpens pre-kickoff research.
What can you do from the regulations tree view?
Browse product codes and regulation numbers, read the identification text and special controls, browse sibling product codes, open device PDFs on the right, and search by product code or regulation number at the top of the tree.
8. Chart view
Click Show Chart and segment by regulation number (or product code) to see which regulations dominate your result set. Clicking a regulation takes you into the regulations tree. Great for spotting that most matches are, say, hardware laparoscopic devices — a cue to go back and filter.
How do you see which regulations dominate a search result set?
Click "Show Chart" and segment by Regulation Number. Clicking a regulation takes you to the regulations tree.
9. The predicate graph
Open the Predicates tab for a family-tree view of predicate relationships. Click a node to trace its parents and children; selections from search carry over pre-selected. Commonly predicated devices are worth reading — a lot of people predicated them for a reason. The visual lineage is also handy on client calls, e.g. to show how a predicate family evolved and justify why your predicate still holds.
In the predicate graph, why are commonly predicated devices worth reading?
A lot of people predicated them for a reason. Clicking a node traces parents and children, and selections from search carry over pre-selected.
10. Embeddings: the galaxy map
The Embeddings tab plots every matching document in a 2-D "galaxy map" where semantically similar devices cluster together. Hover or click clusters to explore, and let AI label the clusters for you. Embeddings beat product codes for grouping: two devices can carry different product codes (LLZ vs. QIH) yet do the same thing — the embedding captures the meaning of the intended use and device story. This is also exactly how retrieval-augmented generation (RAG) works under the hood, and it makes a great visual on client calls.
Try it yourself
Head to the search page and work through a few of these AI/ML fuzzy searches to build intuition: perivascular fat on CT · aortic valve calcification opportunistic screening on noncontrast CT · breast cancer prediction on digital pathology slides · autism detection · gestational age prediction · a hearing aid that can also detect a pulse · foundation model based analysis of ECG · large language models · penetration test. Watch how the relevance scores, intended use, and AI Performance tables tell you when results stop being meaningful.