UNMIRI Platform Roadmap

Molecular pathology coding is one of the messier corners of healthcare revenue cycle. NGS panel claims, companion-diagnostic test billing, and Medicare G-code submissions vary across payers. Many specialty pathology labs spend meaningful staff time on coding errors that drive denials rather than on the science of the test itself. Payer policy is inconsistent across regions, panel sizes affect the coding tier in ways that are not always documented in the published policy, and CDx eligibility flags often need cross-referencing between the NGS report and the payer's specific drug-test pairing list. The result is a long tail of denials that lab billing teams chase one at a time.

Engine 1 already parses the structured data this layer would need: gene panel composition, panel size, biomarker coverage (TMB, MSI, HRD, PD-L1), and CDx eligibility flags. The roadmap capability would add a coding layer on top: ingestion of payer-specific G-code rules, automatic mapping from the parsed panel data to the most likely correct claim code, and a structured rationale field the lab's billing team can attach to a denial appeal. The output would slot into existing revenue-cycle tools rather than replacing them.

Position: a natural extension of Engine 1, sold as an add-on to existing API customers rather than as a standalone product. Customer demand from mid-tier reference labs would determine whether this becomes a 2027 deliverable or stays parked.

A concrete example of where the coding ambiguity bites: a CDx claim for a Foundation One CDx panel can hit different reimbursement tiers depending on whether the payer's policy treats it as a comprehensive genomic profile or as a targeted multi-gene panel, and the deciding factor is sometimes the specific gene list called out in the report against the payer's approved CDx-to-drug pairings list. Labs that hit denial loops on this class of cases lose meaningful margin per claim. The capability would surface the policy-tier ambiguity at submission time, not at appeal time.

Family history intake and hereditary cancer risk scoring are increasingly delivered through digital health products: telehealth visits, women's health platforms, employer benefit programs, primary care patient apps. The intake is structured (a yes/no family history pedigree across roughly 20 fields), the risk models are well-published (Tyrer-Cuzick, BRCAPRO, BOADICEA, Gail), and the output is meant to drive a downstream decision: refer to genetic counseling, or not. Most digital health products that ship this feature build it from scratch each time, with underlying risk-model implementations of varying quality.

A roadmap capability here would package guideline-aligned family-history intake (a structured questionnaire patterned on the standard hereditary cancer syndromes Lynch, hereditary breast and ovarian, Li-Fraumeni, hereditary diffuse gastric, and a handful of others) plus a vetted implementation of the major risk calculators behind a single API call. The output would be a structured risk score with a referral recommendation, sources cited, and provenance fields suitable for an FDA CDS-exempt deployment when the target user is the HCP rather than the patient.

Position: an Engine 2 expansion targeting OEM channel partners (telehealth, women's health, employer benefit platforms) rather than direct provider sales. Pricing model would mirror Engine 2: per-call or platform fee plus PMPM, with optional BAA scope when the deployment touches PHI.

Concrete buyer set: women's-health platforms running BRCA risk-screening workflows for primary-care patients, telehealth oncology platforms screening for hereditary GI syndromes during routine colonoscopy referral intake, employer benefit programs offering hereditary risk assessment as a benefit for employees with relevant family history, and patient-app companies building proactive screening features. The OEM channel pattern is established in adjacent areas (cardiovascular risk APIs, mental health screening APIs); hereditary cancer risk has the same shape but no clear consolidated provider yet.

Prior authorization for oncology drugs is a bottleneck. The clinical criteria payers apply are increasingly variant-aware (osimertinib for EGFR-mutant NSCLC requires the EGFR test result; olaparib for BRCA-mutant ovarian requires the BRCA test result), and many payers also gate on line of therapy and prior-treatment history. The existing PA platforms (SamaCare and others) handle the workflow side well; the gap is on the clinical-rationale side, where a denial often depends on whether the submitted justification packet correctly references the variant, the evidence level, and the appropriate drug label precedent.

A roadmap capability here would not be a provider-facing PA tool. SamaCare dominates that channel and there is no compelling reason to compete head-on. Instead, the capability would be a wholesale API selling structured PA decision logic to PA platforms: variant-aware drug-line-eligibility evaluation, evidence-based justification packet generation referencing OncoKB levels and FDA labels, and payer-specific form pre-fill JSON for the downstream platform to render. CMS-0057-F (the electronic PA final rule effective 2026/2027) creates additional demand for structured decision logic on the PA platform side.

Position: an extension of Engine 2 with a different sales motion (PA platforms as channel partners rather than end customers). Whether this ships depends primarily on whether two or more PA platforms credibly commit to integrating it.

CMS-0057-F (the electronic prior authorization final rule) requires payers covering Medicare Advantage, Medicaid managed care, and certain ACA marketplace plans to support FHIR-based PA APIs by January 2027. The rule creates structured-data demand on the PA-platform side that does not exist today: every PA platform integrating with payer FHIR endpoints will need consistent, structured clinical-rationale generation, and oncology PA is one of the highest-friction areas. Engine 2's variant-aware reasoning maps directly onto the structured-rationale need, which is part of why the timing of this capability is anchored to the CMS rule rather than to internal product priorities.

Real-world evidence is a recurring ask from pharma medical affairs and HEOR teams. The structured data flowing through Engine 1 (vendor-normalized variants, biomarkers, treatment timelines, outcomes when reported) is the right shape for RWE consumption, especially for indications where existing RWE sources (Flatiron, Tempus, COTA) are sparse or priced for top-twenty pharma. Genitourinary oncology specifically has a smaller pure-play RWE footprint than NSCLC or breast, which makes it an attractive starting point.

A roadmap capability here would build a federated RWE corpus from Engine 1 customers, with consent flows handled at the customer level (the lab or health system the patient already has a treatment relationship with). UNMIRI would not directly access PHI for RWE production; the federation layer would emit de-identified aggregate data suitable for licensing to pharma medical affairs and HEOR teams. The licensing model would be flat fee per indication and per query type, not per-patient.

Position: Year 3 monetization at earliest. The capability depends on Engine 1 reaching enough customer volume that a federated corpus becomes meaningful, plus consent infrastructure being in place across customer agreements. Pre-Year-2 demand signals are still useful for prioritization.

The technical pattern is federated query rather than centralized aggregation: queries land at the customer's Engine 1 deployment, the customer's consent infrastructure determines whether each patient's data is included in the federated result set, and only de-identified aggregate counts and summary statistics leave the customer environment. This pattern avoids creating a centralized PHI honeypot at UNMIRI, which is the design constraint that makes the BAA story manageable for both UNMIRI and the customer health system or lab.

Standard FHIR Genomics output is sufficient for most downstream software ingestion, but oncology-specific analysis frequently needs more structure than the base profiles emit. Treatment-line construction (a first-line, second-line, third-line view of a patient's therapy sequence) is not a built-in FHIR resource. Biomarker normalization across vendor-specific reporting conventions (different PD-L1 IHC clones, different MSI assay thresholds, different TMB panel sizes and reference ranges) is not part of the FHIR Genomics IG. Longitudinal patient journey reconstruction across multiple NGS reports for the same patient over time is a custom layer almost everywhere it gets built.

A roadmap capability here would package these oncology-specific normalizations as a higher-level export from Engine 1. The output would be mCODE- and FHIR-Genomics-compatible (so it composes with existing FHIR pipelines) but with the additional oncology structure baked in: typed treatment-line edges, normalized biomarker components with cross-vendor harmonization, and patient-timeline Bundles spanning multiple NGS reports.

Position: useful for academic medical centers running cancer-registry and quality-improvement pipelines, and for life-sciences research consortia working with FHIR-native cancer data. Sold as an add-on to Engine 1 in volume contexts.

Concrete examples of what cross-vendor harmonization fixes: a PD-L1 result reported as TPS 22% (Dako 22C3 antibody) by one vendor and a PD-L1 result reported as “high expression” (SP142 antibody) by another vendor are not the same biomarker measurement, but FHIR's base profiles do not encode the antibody-and-method differences in a way downstream analysis can reason about. TMB normalization across panel sizes (a TMB of 8 mut/Mb on a 324-gene panel is not the same signal as TMB 8 on a 600-gene panel) is similar. The roadmap capability would emit these as typed component values with the underlying assay metadata preserved, so a downstream HEOR or quality-improvement analysis can apply the right comparability rules.

CAP-aligned synoptic pathology reports are a regulatory requirement for many tumor types in accredited US labs, and the data-entry burden falls on pathologists who are already time-constrained. The pattern is increasingly well-served by ambient scribing for the narrative dictation portion (Abridge, DeepScribe, and others own that channel), but the structured synoptic checklist itself, plus tumor-board orchestration around the synoptic report, is a less crowded space.

A roadmap capability here would pair structured synoptic checklist generation with downstream tumor-board orchestration: agenda preparation from the synoptic structure, case-summary rendering for the board meeting, and post-board action capture feeding back into the LIS. Integration patterns would mirror Engine 4 (free pathologist tool) on the input side and Engine 1 (LIS-routed FHIR Bundles) on the output side.

Position: Year 3 standalone product candidate, with a precondition that Engine 4 reaches its 1,500+ active monthly user threshold first. Without the clinician user base from Engine 4, a synoptic product enters an installed-base market that ambient-scribing incumbents already touch. With it, the existing relationship is a credible distribution channel.

A concrete workflow example: a tumor-board case from a synoptic pathology report needs structured fields for tumor histology, grade, biomarker results, applicable trials, and prior-line history. The current state of practice involves a pathologist or oncology fellow assembling these fields by hand from the synoptic report, the linked NGS report, and the patient's prior records. The capability would render that case-summary structure automatically from data UNMIRI already parses, leaving the clinician to review and adjust rather than to assemble from scratch.

Engine 3 already covers the core surveillance, digest, and KOL-intelligence surface for medical affairs teams. The adjacent workflow surface is broader: medical inquiry response automation, MSL call planning and follow-up tracking, advisory board orchestration, congress intelligence (live coverage is part of Engine 3, but the pre-congress preparation and post-congress synthesis workflow is a separate product), and structured KOL profiling for engagement planning.

A roadmap capability here would extend Engine 3 from a surveillance product into a productized medical affairs platform. The reasoning layer underneath stays the same (the oncology-specific knowledge graph, the citation-grounded summaries, the audit trails). What changes is the workflow surface wrapped around it. Pricing would slot above Engine 3's Team tier and below the enterprise band, targeting biotech medical affairs teams that are outgrowing the surveillance-only feature set.

Position: Engine 3 expansion. Likely customer development pattern is Team-tier customers asking for adjacent workflow features one at a time.

Concrete sub-capabilities under consideration: medical inquiry response automation that drafts citation-grounded answers from the literature graph (with inquiry triage and human review staying manual), MSL territory and call planning that uses the KOL graph to suggest engagement priorities by indication and drug class, advisory board orchestration that aligns participant selection and discussion-guide generation with the team's current evidence base, and structured congress preparation that pre-builds case-by-case briefing documents for the team's MSL coverage. Each of these would be a discrete sub-product that Team-tier Engine 3 customers can opt into rather than a single bundle.

Variant-aware trial matching is already a feature inside the Genomics-Aware CDS API. A standalone institutional product (academic medical centers, contract research organizations, pharma sponsors) is on the roadmap as a separate SKU, sold as flat SaaS with the same Anti-Kickback-Statute-clean business model documented on the CDS API page (no per-enrolled-patient referral fees, no per-match contingent pricing).

What a standalone product would add over the embedded CDS feature: institutional case-by-case matching workflows for AMC tumor boards, multi-trial portfolio management for sponsors running concurrent oncology trials, and CRO-side patient identification across an AMC site network. The reasoning layer stays the same; the workflow surface and pricing model differ. Pricing remains flat SaaS, in keeping with the AKS-clean model.

Hereditary cancer risk assessment workflows often bottleneck at the genetic counselor handoff: there are not enough certified genetic counselors to meet demand, and the patient-facing portion of the intake (family history, prior testing, indication for referral) can be structured.

A roadmap capability here would build automated decision trees for the structured portion of hereditary cancer risk assessment, scoped tightly within FDA CDS-exempt criteria (HCP-targeted outputs, transparent citations, options not auto-actions, no IVD signal analysis). It could ship as a standalone product or as a feature of Engine 2's decision-support API. Either path would route the patient to a human genetic counselor for the actual counseling encounter; the automation handles only the intake structure and the risk calculation.

Scope detail: the automation handles structured intake (family history pedigree, prior testing history, indication for referral) and risk-model output (Tyrer-Cuzick, BRCAPRO, BOADICEA, Gail) plus a referral recommendation. It does not generate counseling content for the patient, does not provide variant-specific counseling, and does not order a germline test. A certified genetic counselor remains the human in the loop for the actual counseling encounter; the automation is for the structured pre-encounter intake only.