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 AMP/ASCO/CAP 2017 evidence tiers (I-A through IV) and trial-stage drugs flagged separately. EGFR L858R in NSCLC returns osimertinib as Tier I-A 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 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.
One call. The request body is an Engine 1 NgsInterpretationResponse plus optional patient context, so Engine 1 and Engine 2 chain directly. The response is an array of recommendation objects. Every recommendation carries a type, a priority, an evidence chain, and a Non-Device CDS attestation. To try it without an Engine 1 report, POST /v2/recommendations/sample runs the same engine against a pre-loaded synthetic case. The example below is the synthetic NSCLC case used elsewhere on the site.
Sample request
POST /v2/recommendations HTTP/1.1
Host: api.unmiri.com
Content-Type: application/json
Authorization: Bearer <partner-api-key>
{
"parsed": { "...": "an Engine 1 NgsInterpretationResponse" },
"context": {
"tumor_type": "non-small cell lung cancer",
"prior_therapies": []
}
}Sample response (truncated)
{
"recommendations": [
{
"recommendationId": "6d1215b7-d13a-402b-bd34-1a298f0d82bc",
"recommendationType": "therapy-match",
"triggeredBy": [
{ "refType": "cdxFlag", "refId": "8d493dbb-..." },
{ "refType": "variant", "refId": "cce1a88a-..." }
],
"evidenceChain": [
{
"kbSource": "openFDA",
"evidenceLevel": "FDA",
"citation": "FDA-CDx:Osimertinib",
"url": "https://www.accessdata.fda.gov/drugsatfda_docs/label/",
"summaryShort": "Osimertinib approved as companion diagnostic for non-small cell lung cancer per FDA."
}
],
"confidence": 0.95,
"priority": "advisory",
"narrative": "Osimertinib is FDA-approved as a companion diagnostic for non-small cell lung cancer. The patient's report includes a finding that matches the labeled indication. Educational use only; clinician verification required.",
"nonDeviceCdsAttestation": {
"timeNotCritical": true,
"publiclyAvailableEvidence": true,
"transparentlyExplained": true,
"clinicianCanVerify": true
},
"ruleId": "fda_cdx_therapy_match.v1",
"associatedDrug": { "name": "Osimertinib" },
"associatedDisease": { "display": "non-small cell lung cancer" }
}
],
"engine_version": "engine-2-api/0.1.0",
"schema_version": "0.3.0",
"disclaimer": "Educational use only. Not a medical device. ..."
}Output fields
- recommendations[]
- Array of recommendation objects produced for the parsed report
- recommendations[].recommendationType
- therapy-match, drug-interaction, hereditary-flag, evidence-gap, or cdx-eligibility (the five reasoning categories)
- recommendations[].priority
- advisory or informational. Every recommendation is an option for the HCP to weigh, never an auto-action.
- recommendations[].evidenceChain
- Ordered evidence items: each carries kbSource, evidenceLevel, a citation string, a source URL, and a short summary
- recommendations[].narrative
- Plain-language explanation rendered from a deterministic template; LLM use is scoped to extraction edges, never to the clinical claim
- recommendations[].nonDeviceCdsAttestation
- The four FDA Non-Device CDS criteria as booleans: time-non-critical, publicly-available evidence, transparently explained, clinician-verifiable
- recommendations[].confidence
- 0 to 1 confidence score for the recommendation
- recommendations[].ruleId
- The deterministic rule that fired (e.g. fda_cdx_therapy_match.v1), so the customer can trace and reproduce it
- disclaimer
- Non-Device CDS disclaimer string, returned on every response
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.
See it interactively
- /recommendations → EGFR L858R: deterministic CDS card
- Five-step product tour: parse → match → CDS
- TMB + MSI walkthrough: tumor-agnostic CDS routing
- BRCA1 + HRD walkthrough: combined-predicate PARP branch
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 section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act, codified at 21 U.S.C. 360j(o)(1)(E), as amended by §3060 of the 21st Century Cures Act and 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 AMP/ASCO/CAP tier and primary trial publication 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 CIViC entry, the FDA label, the primary trial publication, 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. The entire PHI path runs in a single AWS account in us-east-1 on HIPAA-eligible services, under an active AWS BAA. Microsoft Azure OpenAI handles narrow LLM inference under the Microsoft Online Services BAA. The architecture meets these targets:
- Managed PostgreSQL Multi-AZ for structured data and audit logs (AWS RDS in the BAA-covered AWS account; the entire PHI path is AWS-only)
- Encrypted object storage with customer-managed keys, access logging, and versioning for report storage (AWS S3 with SSE-KMS in the BAA-covered AWS account)
- Managed document extraction for PDF parsing (Engine 1 dependency, AWS Textract in the BAA-covered AWS account)
- HIPAA-eligible LLM inference for extraction edge cases (Azure OpenAI Service under the Microsoft Online Services BAA), de-identified inputs only
- US-only data residency across all PHI-handling resources
Upstream subprocessor BAAs are active: AWS Business Associate Addendum (account-scoped) and the Microsoft Online Services HIPAA BAA. Customer BAAs are part of design-partner onboarding. PHI is processed in memory and not persisted by UNMIRI after the response is returned. Effective dates are on the subprocessors page.
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.
Frequently asked questions
Is the CDS API FDA-regulated?
No. Engine 2's outputs sit inside the Clinical Decision Support exemption at 21 U.S.C. 360j(o)(1)(E) added by §3060 of the 21st Century Cures Act. The API returns evidence chains and recommendations that an HCP can independently review; it does not drive a device, dose, or autonomous action. The exemption document package is part of the design-partner kit.
Why don't you ship with NCCN or OncoKB content built in?
Both are licensed proprietary content with per-customer commercial terms that we don't presume to redistribute. The engine exposes a documented `evidence.externalLevels` extension that licensed customers plug their own NCCN or OncoKB feed into under their own contract. The open content (CIViC, ClinVar, openFDA, CPIC, AMP/ASCO/CAP 2017) is shipped in-engine and is sufficient for the FDA-label-aligned decision tier.
How does pricing work?
Per-call ($0.10 to $2.00 depending on volume), per-month platform ($25K to $250K), or PMPM ($0.50 to $3 per member per month). Typical first-year ACV runs $50K to $300K depending on integration depth and patient volume. Design-partner pricing is held for the first year of production use.
Can I get this on-premises, or is it cloud-only?
Cloud-only today through AWS us-east-1 under the active AWS BAA. On-prem or VPC-peered deployment is a paid SOW after the first paid pilot lands. The schema is the same; the deployment shape changes.
How are alerts kept current as FDA labels and CPIC guidelines change?
openFDA drug labels are ingested on a daily refresh; CPIC guidelines on a monthly refresh; CIViC on its public release cadence; ClinVar on a weekly refresh. The engine reports the source content date on every evidence-chain entry so a customer can audit recency.
What's the difference between Engine 1 (NGS API) and Engine 2 (CDS API)?
Engine 1 parses vendor PDFs into structured FHIR Genomics. Engine 2 takes that structured output and returns clinical recommendations: therapy matches, hereditary triggers, trial leads, CDx flags. Engine 2 depends on Engine 1's schema as its input contract.
Is the LLM in the decision loop?
No. The decision logic is deterministic. LLMs are used narrowly in two upstream places: parse-time extraction assistance and long-tail variant fallback. Both are flagged in the response. The recommendation engine itself reads structured inputs and returns structured outputs through pure logic.
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.