Section 1
Generic CDS is not genomics-aware.
Generic clinical decision support is a mature market. Wolters Kluwer's UpToDate and Lexicomp serve roughly half of US hospital systems at $2 to $10 per provider per month. EHR-native CDS modules (Epic's, Oracle Health's, eClinicalWorks') handle the standard drug-drug interactions, dose-range checks, and allergy flags. For most clinical scenarios that stack is enough.
For oncology, it is not.
None of these systems are genomics-aware. They flag warfarin-amiodarone but they do not know that a patient's CYP2C19 *2/*2 genotype is the actual reason a clopidogrel order should be questioned. They do not see DPYD variants when 5-FU is ordered. They do not trigger on UGT1A1 *28/*28 before irinotecan, on TPMT poor metabolizer status before thiopurines, or on the HLA-B*1502 allele frequencies that matter for carbamazepine in specific Asian patient populations. The pharmacogenomic edges between drug and variant are where modern oncology actually fails closed-loop alerting.
Pharmacogenomics is the easy half of the gap. The harder half is variant-specific therapy selection. A KRAS G12C mutation makes sotorasib or adagrasib first-line options that were not approved when many of the standing CDS rule sets were last updated. An EGFR exon 20 insertion needs a different drug than EGFR L858R or exon 19 deletion. A BRAF V600E in melanoma is treated differently than the same variant in colorectal cancer. The standard CDS layer was not built to reason at this level.
The genomics-aware options that do exist are bundled with single-vendor ecosystems. Tempus One AI surfaces decision support inside Tempus's own oncology platform. Caris+ does the same for Caris-tested patients. Foundation Medicine's vMTB is gated to Foundation reports. These are useful inside their boundaries; they are not a horizontal CDS layer that any health system or software vendor can integrate with.
Engine 2 fills that gap. It is a horizontal API: the same call returns the same answer whether the underlying NGS report came from Foundation Medicine, Tempus, Caris, Guardant, Natera, or a hospital's in-house panel. It is built on Engine 1's data plane, so the variant data is already normalized and curated before the CDS layer reasons over it. And it is exempt from FDA premarket review under the 21st Century Cures Act CDS criteria, which is a real precondition for shipping to health systems and software vendors at scale.
Section 2
Five reasoning categories, one knowledge graph.
Engine 2 sits one layer above Engine 1. The NGS API normalizes vendor reports into structured variant data. The CDS API takes that variant data and turns it into clinical alerts, recommendations, and matches. Same knowledge graph, different output schema. Coverage is organized into five reasoning categories.
- 01
Drug-variant interactions (pharmacogenomics)
The graph encodes CPIC-curated guideline edges between variants and drugs. Most-asked-for in oncology contexts: DPYD variants and 5-fluorouracil / capecitabine toxicity (CPIC Level A); UGT1A1 *28 / *6 and irinotecan dose adjustment (Level A); TPMT activity and thiopurine dosing for AML/ALL (Level A); CYP2C19 *2/*3 and clopidogrel response after stent placement (Level A); HLA-B*1502 and carbamazepine SJS/TEN risk in Asian populations (Level A). Each alert returns the CPIC guideline level, the recommended dose modification or alternative drug, the source citation, and an explanation field intended for HCP eyes.
- 02
Variant-specific therapy options
For each variant in the input, the CDS API returns FDA-approved drugs targeting that variant in the relevant tumor type, with OncoKB evidence levels (1 through 4) and trial-stage drugs flagged separately. EGFR L858R in NSCLC returns osimertinib as Level 1 first-line, with the FLAURA citation. BRAF V600E in melanoma returns dabrafenib + trametinib. KRAS G12C in NSCLC returns sotorasib and adagrasib, with their respective approval contexts.
- 03
Hereditary cancer screening triggers
Variant patterns suggestive of germline syndromes trigger screening recommendations: MLH1 / MSH2 / MSH6 / PMS2 variants for Lynch syndrome, BRCA1 / BRCA2 / PALB2 / CHEK2 / ATM for hereditary breast and ovarian, TP53 for Li-Fraumeni, CDH1 for hereditary diffuse gastric. The CDS output flags these as germline-suggestive and recommends genetic counseling referral. It does not order a germline test or make a hereditary diagnosis itself.
- 04
Trial matching
Variant profiles are matched against ClinicalTrials.gov eligibility criteria continuously. Matches are returned as a ranked list with NCT ID, study name, phase, recruiting status, and the specific eligibility edge that produced the match. The matching is variant-aware: a trial requiring "EGFR exon 19 deletion or L858R" returns a match for both, with the right edge attribution.
- 05
CDx eligibility flags
Companion-diagnostic eligibility is a separate category from therapy options because the FDA approval bound is the test plus the drug, not the drug alone. The CDS API returns CDx flags for the major paired indications: F1CDx for olaparib in BRCA-mutant ovarian, MyChoice CDx for niraparib, FoundationOne Liquid CDx for liquid-biopsy-eligible osimertinib, and so on.
Output formats: structured JSON alert objects for direct embedding in CDS engines, FHIR Clinical Reasoning resources (PlanDefinition, ActivityDefinition, GuidanceResponse) for FHIR-native integrations, and a webhook stream for asynchronous alerts as new graph edges become available (a new FDA approval, a new trial, an updated CPIC guideline).
The reasoning runs against the same Neo4j knowledge graph Engine 1 uses. CIViC, ClinVar, ClinicalTrials.gov, openFDA, CPIC, and OncoKB level assignments are all reachable from a single variant query. New evidence edges land in versioned releases that customers can pin against, so a CDS recommendation can be replayed against an exact knowledge-graph snapshot for audit purposes.
Section 3
What you get back.
A single API call against a previously ingested report ID. The response is a structured alert array. Every alert carries a category, a severity, a recommendation, and a citation. The example below is the synthetic NSCLC case used elsewhere on the site.
Sample request
POST /v1/cds/evaluate HTTP/1.1
Host: api.unmiri.com
Content-Type: application/json
Authorization: Bearer <api-key>
{
"report_id": "rpt_synthetic_001",
"include": [
"drug_variant",
"therapy_options",
"hereditary",
"trials",
"cdx"
]
}Sample response (truncated)
{
"report_id": "rpt_synthetic_001",
"alerts": [
{
"category": "therapy_options",
"severity": "informational",
"variant": "EGFR p.Leu858Arg",
"recommendation": "First-line: osimertinib",
"evidence_level": "OncoKB Level 1",
"fda_status": "approved",
"source": "FLAURA (NEJM 2018)",
"rationale_url": "https://oncokb.org/gene/EGFR/L858R"
},
{
"category": "contraindication",
"severity": "high",
"trigger": "EGFR-mutant NSCLC + PD-L1 <1%",
"recommendation": "Avoid PD-1/PD-L1 inhibitor monotherapy",
"source": "openFDA label, TATTON precedent"
},
{
"category": "hereditary",
"severity": "informational",
"trigger": "TP53 variant detected",
"recommendation": "Consider germline TP53 testing and genetic counseling referral if clinically indicated",
"source": "ASCO Hereditary Cancer Genetic Testing Guidelines"
},
{
"category": "trial_match",
"nct_id": "NCT04988295",
"name": "MARIPOSA-2",
"match_type": "pre-matched for resistance pathway",
"recruiting": true
}
]
}Output fields
- alerts[]
- Array of all alert objects returned for the report
- alerts[].category
- drug_variant | therapy_options | hereditary | trial_match | cdx | contraindication
- alerts[].severity
- high | informational
- alerts[].source
- Underlying citation (CPIC guideline, OncoKB level, FDA label, NCT entry)
- alerts[].evidence_level
- Graded evidence level where applicable (OncoKB 1-4, CPIC Level A/B/C/D)
- alerts[].rationale_url
- Link to the source explanation, intended for the HCP reviewing the alert
Pricing
Pricing model fits the integration shape. High-volume API integrations use per-call pricing in the $0.10 to $2.00 range. Health-system deployments use a platform fee of $25K to $250K plus a per-member-per-month rate of $0.50 to $3.00. Typical ACV is $50K to $300K. Specific terms are part of the design-partner conversation, where pricing depends on call volume, integration depth, BAA scope, and which alert categories are enabled.
Section 4
Who Engine 2 is for.
The buyer set extends Engine 1's with health-system IT for in-house deployments. The cross-sell pattern is the strongest in the platform: customers already running Engine 1 pick up Engine 2 with a one-line API addition.
EHR vendors (cross-sell on Engine 1)
Customers already integrating Engine 1 add Engine 2 as a single additional API call. The variant data is already in scope and already structured. Engine 2 plugs into the same client SDK, the same auth, and the same BAA, and surfaces variant-aware decision support inside the EHR's existing oncology workflow.
Decision-support vendors
Lexicomp, UpToDate, VisualDx, and EHR-native CDS modules cover non-genomic clinical reasoning well. Engine 2 covers the oncology genomics layer those products do not. Decision-support vendors that need a variant-aware reasoning layer can embed Engine 2 below their existing alert surface, returning oncology-specific alerts with the same citation rigor their non-genomic alerts already carry.
Health-system IT
Large academic medical centers and community oncology networks running their own NGS programs (or routing to multiple labs) deploy Engine 2 for in-house decision support. The CDS API runs against any vendor's reports, not just one. The same call returns the same alert whether the report came from Foundation Medicine, Tempus, Caris, Guardant, or a hospital-developed panel.
Digital health platforms
Patient navigation tools, oncology-specific care pathway platforms, and digital health products embedded in payer or employer benefit plans use Engine 2 to surface variant-aware information inside HCP-facing review screens. Patient-facing rendering of CDS API output is contractually prohibited, which preserves the FDA CDS exemption on the customer's side.
Section 5
Trial matching is sold as flat SaaS.
On the federal Anti-Kickback Statute
UNMIRI does not charge per-enrolled-patient referral fees to pharma sponsors. That model, paying a vendor for each patient that ends up enrolled in a sponsored trial, runs directly into the federal Anti-Kickback Statute (42 USC §1320a-7b), which prohibits offering or receiving remuneration in exchange for referrals tied to federally reimbursable items or services. Many oncology trials touch federal payers. The risk is real, the OIG has prosecuted on this fact pattern, and sophisticated buyers in this space already know to ask.
Trial matching is a feature inside Engine 2, not a standalone product. It is sold as a flat SaaS feature to academic medical centers (AMCs), contract research organizations (CROs), and pharma sponsors. The fee is not contingent on enrollment, not per-patient, not per-match, and not adjusted by sponsor identity. The same trial database is searched the same way for every customer.
When the CDS API returns a trial match, the customer's clinician decides whether to act on it. UNMIRI is not paid based on that decision.
Section 6
FDA CDS exemption rationale.
Engine 2 is exempt from FDA premarket review under the 21st Century Cures Act, specifically section 3060(o)(1)(E), as implemented in the September 2022 FDA Clinical Decision Support Software Final Guidance and the December 2024 FAQ updates that softened enforcement on a few of the criteria. The exemption applies when four conditions are all met.
- 01
Outputs are options, not automatic actions.
The CDS API returns recommendations, alerts, and ranked matches. It does not place orders, dispense drugs, change treatment plans, or trigger any action without an HCP in the loop. Every output is framed as a recommendation for the clinician to evaluate.
- 02
Sources are cited transparently.
Every alert returns the underlying citation: the CPIC guideline version for pharmacogenomics, the OncoKB evidence level for therapy options, the FDA label for contraindications, the NCT ID and eligibility text for trial matches. The clinician can always trace the recommendation back to the source.
- 03
The target user is the HCP, not the patient.
The CDS API is licensed to providers, software vendors, and health systems for use inside HCP-facing workflows. Patient-facing repurposing of CDS API output is contractually prohibited in the standard customer agreement and disqualifies the FDA exemption.
- 04
No raw IVD signal analysis.
The CDS API operates on already-structured variant data from Engine 1 (which itself works from finalized lab reports, not raw sequencer signal). The CDS layer never sees BCL files, FASTQs, BAMs, or VCFs from the sequencer. It reasons over the curated, lab-finalized variant calls only.
When all four conditions hold, the software is excluded from the FDA's definition of a “device” under §201(h) of the FD&C Act and does not require premarket clearance or approval. Customers integrating the CDS API into HCP workflows preserve that exemption as long as they preserve the four conditions on their side too. The standard customer agreement encodes these four conditions as contractual obligations.
Section 7
Why this is hard to replicate.
Three things make Engine 2 defensible.
Knowledge-base curation is slow and expert-driven. Encoding CPIC pharmacogenomic guidelines as graph edges, with the right level granularity and the right citation linkages, is not work an LLM can generate or a junior engineer can ship. The same is true for variant-to-trial-eligibility edges from ClinicalTrials.gov, where eligibility text varies wildly in structure and a 95%-correct extraction is meaningfully worse than a 99.5%-correct one in production. UNMIRI's curation pipeline is partly automated (LLM-assisted extraction with strict validation) and partly hand-checked. New edges land in versioned releases that customers can pin against.
Integration depth with Engine 1 produces switching costs. Customers buying both engines get a unified pipeline: vendor PDF in, structured variant data plus clinical alerts out, all with a single API client and a single BAA. Customers who try to replace just one engine have to reintroduce the integration boundary they paid to remove. This compounds: the longer a customer uses the combined stack, the more their internal monitoring, alerting, and decision-support UI is tuned to the combined output schema.
Open data sources let customers verify our work. Customers who want to spot-check an alert can pull the CPIC guideline, the OncoKB level assignment, the FDA label, or the ClinicalTrials.gov eligibility text from the source's own site and confirm that the alert matches. Closed-source variant interpretation services do not allow this kind of verification. UNMIRI does. That asymmetry matters when a hospital medical informatics team is doing CDS due diligence.
Section 8
Compliance posture.
Engine 2 inherits Engine 1's HIPAA-ready posture. UNMIRI's architecture is built on AWS for the PHI path, with the following architectural targets:
- AWS RDS Postgres for structured data and audit logs
- Encrypted S3 (SSE-KMS, access-logged, versioned) for report storage
- AWS Textract for PDF extraction (Engine 1 dependency)
- Anthropic HIPAA-ready API tier for narrow LLM use (extraction edge cases only)
- us-east-1 region pinning across all PHI-handling resources
Cloud-subprocessor BAAs (AWS, Anthropic, Vercel) are in active negotiation; customer BAAs are part of design-partner onboarding once the upstream chain is in place. PHI is processed in memory and not persisted by UNMIRI after the response is returned.
The CDS-specific compliance layer is the FDA exemption framework above. Customer agreements include the four exemption preconditions as contractual obligations, which protects both UNMIRI and the customer from inadvertent classification as a regulated device.
The full subprocessor list, BAA status, and incident-response posture are at /security/subprocessors. Compliance documentation, including the API reference and the FDA exemption rationale package, is shipped to design partners under NDA.
Section 9
Become a design partner.
Engine 2 is in design-partner phase. Design partners get the API reference under NDA, hands-on integration support from the engineering team, the FDA exemption documentation package, and pricing locked at design-partner rates for the first year of production use. In exchange we ask for honest feedback on alert accuracy across your real-world workflow and a willingness to flag edge cases as they appear.