Two patients with the same diagnosis often need different drugs, doses or follow-up, and the evidence for which one rarely sits in one place at the moment of choice. Agnotic Technologies builds treatment personalization software that puts a reviewable suggestion in front of the clinician, who keeps every decision.
Trusted by global innovators
Artificial intelligence treatment personalization is software that suggests how to choose or adjust a treatment for one patient, by predicting response to therapy options, estimating a dose from the patient's own data or adapting a digital program as the patient responds. Agnotic Technologies builds it for clinical teams, and the treating clinician reviews every suggestion.
It is not a diagnostic model and not a pharmacogenomic alert. Both have their own pages, linked at the end. This page covers the decision after the diagnosis: which treatment, at what dose, and what to change when the patient's response comes in.
The hard part is rarely the model. It is showing the clinician enough of the basis to disagree with it, and proving the model works for the patients in front of them, not only on average.
Original decision table
Most requests fall into one of three types. Each needs different data, shows the clinician something different and carries a different regulatory question.
| Type | Input data | What the clinician sees | Non-device CDS question | Subgroup checks before release |
|---|---|---|---|---|
| Response prediction for therapy options | Diagnoses, prior therapies and their outcomes, labs, demographics and, where the program uses them, biomarkers | Each option with its predicted response, the range around it and the patient factors behind it | Often designed to meet all four criteria, because the clinician compares options and can review the basis | Performance by age band, sex, race and ethnicity where recorded, care site and line of therapy |
| Model-informed dosing | Weight, kidney and liver function, drug levels, prior doses and their timing | A suggested dose or interval, the inputs used and how a change in each input would move it | Needs care: time-critical dosing, or a calculation the clinician cannot practically check, weighs against criterion four | Patients at the edges of the input range, such as very low body weight or reduced kidney function |
| Adaptive digital intervention | Patient-reported symptoms, adherence, device readings and use of the program | The next step in the program, why it changed and the rule or model that changed it | Depends on who acts: a suggestion to a clinician differs from a change delivered straight to the patient | Groups by language, device type and level of use, so the program does not adapt only for the most active users |
Whether a function meets the criteria is a regulatory decision for your team and counsel. We build the display, the intended use statement and the test evidence that decision relies on.
Non-device CDS
Section 520(o)(1)(E) of the FD&C Act sets four criteria. A treatment suggestion is shaped to meet each one from the first design review, not argued afterwards.
Example: The model reads structured chart data such as labs, medications and diagnoses, not images, waveforms or signals from a device.
Approach: We keep image and signal processing out of the treatment function, or say early that it brings device rules into scope.
Example: Patient data, published studies and clinical practice guidelines are shown next to the suggestion.
Approach: Each suggestion links to the patient values it used and the evidence the model was built on.
Example: The output goes to a clinician who decides, not to the patient as an instruction.
Approach: Suggestions sit in the clinician's workflow and need an accept, edit or reject before anything is ordered.
Example: The clinician can see why the software suggested this treatment and is not meant to rely on it primarily.
Approach: We show the inputs, the intended use, known limits and the groups the model was tested on, in plain language.
Each part can ship on its own. Many teams start with the option panel and outcome capture, because outcomes are what every later model needs.
Therapy options side by side with predicted response, the range and the factors behind each estimate.
A suggested dose or interval with every input and the calculation shown, so a pharmacist can check it.
Rules and models that change the next step of a digital program, with each change logged and explained.
Response, side effects and dose changes recorded in the workflow, so the model can be checked against what happened.
Error and calibration by patient group, reviewed by clinical leads before each release.
Every model version with its data window, test results and approval, ready for audit.
From data to the clinic
Six stages, with a named clinical owner signing off at each one.
One treatment decision, the patients it applies to, who sees the output and what they may do with it, written before any data is pulled.
Past treatments, doses and outcomes for that decision, with outcome definitions agreed with clinicians and data recorded after the decision point left out.
Performance on patients the model never saw, by time period and by subgroup, compared with current practice.
The model scores live patients without showing results, so its suggestions can be compared with what clinicians actually chose.
The first visible release ships with a written plan for retraining, the tests each new version must pass and how to roll back.
Outcomes are matched to suggestions each month, and a shift in inputs or error by group opens a review.
Failure points
These are the failures we design against. Most come from the data and the display, not the algorithm.
Challenge
The model learns past prescribing habits instead of treatment response
Agnotic approach
Outcomes are defined with clinicians, and the study design accounts for why each patient got the treatment they got before any response claim is made.
Challenge
It works on average and fails for one group
Agnotic approach
A subgroup report is a release gate. A group with too few patients to test is listed as outside the intended use rather than silently included.
Challenge
Clinicians cannot see why it suggested a treatment
Agnotic approach
Every suggestion shows its inputs and main factors. If the basis cannot be shown, the function is redesigned or treated as a device question.
Challenge
Retraining quietly changes the suggestions
Agnotic approach
Each new version is compared with the current one on a frozen test set, and clinicians see a change note before it goes live.
Challenge
Outcome data never comes back
Agnotic approach
Outcome capture is built into the follow-up workflow, so response and side effects are recorded where staff already work.
Challenge
The suggestion arrives after the decision is made
Agnotic approach
The panel appears where the choice happens, such as order entry, visit preparation or a treatment planning meeting.
If the function is a device, section 515C of the FD&C Act lets FDA approve or clear a predetermined change control plan, so changes described in it need no new submission. We apply the same discipline to non-device functions.
Which parts may change, such as retraining on newer data or adding an input, and which may not change without a new review.
The data, metrics and subgroup thresholds each new version must meet, agreed before the first release.
What changed, why, and how suggestions moved on the test set, shared before the new version goes live.
The previous version stays ready to restore, and every release decision is recorded with its approver under a BAA.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Scope drivers
We size the work on a scoping call rather than quote a price. These factors move effort the most.
Whether treatment response is already recorded in a usable form, or must be defined and captured first.
Response prediction, dosing and adaptive programs each need different data, tests and display work.
A function designed as non-device CDS needs less submission work than one that will be a device, but both need the evidence.
An EHR-launched app, a pharmacy tool or a patient app each adds its own integration and review.
Each treatment decision is its own model, dataset and validation, so one decision first keeps scope clear.
A product sold to many providers needs per-site validation and tenant separation from the start.
Where it applies
Decisions with recorded outcomes and a clear point where the clinician chooses.
Options compared for a tumor board or clinic visit, with the patient factors behind each estimate.
Dose or interval suggestions with the calculation shown for pharmacist review.
Interval adjustments based on kidney function and drug levels, checked by the pharmacy team.
Next-step suggestions from symptom scores, reviewed by the treating clinician.
Programs that adapt content and pace to patient-reported response, with clinician oversight.
Treatment support products that need evidence, subgroup reports and change control from day one.
Three stages, starting with one treatment decision.
We pick one decision, check the outcome data available and agree who signs off the intended use.
Dataset, model, subgroup report and a silent run, with the clinician panel built and tested on synthetic patients.
Visible release, outcome monitoring and retraining under the agreed change plan, then the next decision.
Short facts we design around, each linked to its primary source.
Section 520(o)(1)(E) of the FD&C Act excludes from the device definition software that does not analyze a medical image or device signal, displays or analyzes medical information, supports or provides recommendations to a health care professional about prevention, diagnosis or treatment, and lets that professional independently review the basis for the recommendation.
Source: 21 U.S.C. 360j(o)(1)(E) (govinfo, U.S. Code 2023 edition)Before FDA can treat such a function as a device again, it must find the function reasonably likely to have serious adverse health consequences, and in that finding it must consider the likelihood and severity of patient harm and whether a health care professional can review the basis of the treatment recommendation.
Source: 21 U.S.C. 360j(o)(3) (govinfo, U.S. Code 2023 edition)Section 515C of the FD&C Act, added in December 2022, lets FDA approve or clear a predetermined change control plan, so planned device changes that are consistent with the plan need no new supplemental application or premarket notification.
Source: 21 U.S.C. 360e-4 (govinfo, U.S. Code 2023 edition)NIST released the AI Risk Management Framework (AI RMF 1.0) on 26 January 2023 for voluntary use, to help organizations build trustworthiness into the design, development, use and evaluation of AI products, services and systems.
Source: NIST AI Risk Management Framework
