Spectroscopy Software Gap: Why Vendors Skip Clinical Workflow

Bruker, Thermo Fisher, Renishaw, Horiba, Agilent, and PerkinElmer build the best spectrometers in the world. Their instruments measure molecular vibrations with extraordinary precision. Their software controls those instruments with deep, sophisticated capability built over decades. None of them build clinical workflow software - the layer that connects a spectral measurement to a patient, routes a classification result to an electronic health record, and generates a billable diagnostic event.

This is not an oversight. It is a structural feature of how the spectroscopy industry is organized, funded, and incentivized. Understanding why the gap exists is essential for anyone building clinical spectroscopy applications, evaluating the market, or trying to deploy spectroscopy-based diagnostics in a hospital setting.

What instrument vendors actually build

Every major spectroscopy vendor ships software with their instruments. That software is genuinely good at what it does. The problem is that what it does is instrument control and spectral data processing - not clinical workflow management. Let us walk through each vendor's current software offering.

Bruker OPUS 9.3 is the standard for FTIR and Raman measurement. It handles data acquisition, spectral processing, library searching, quantitative analysis, and evaluation workflows. It supports cGMP, GLP, and GAMP compliance for pharmaceutical and industrial QA/QC applications. OPUS is a mature, powerful platform - and it has zero clinical workflow capability. No patient context. No HL7 messaging. No LIMS connectivity. No EHR integration. It is, by design, an analytical chemistry workbench. Bruker also ships ONET 3.1, a browser-based server for managing networks of FT-IR and FT-NIR instruments with centralized data management, remote control, user management, and audit trails. Again, no clinical workflow features. For more on interfacing with OPUS, see our guide to Bruker OPUS integration.

Thermo Fisher OMNIC Paradigm 2.8 controls Thermo's FTIR instruments across three product tiers. It handles spectral acquisition, diagnostics, and data processing. Thermo also offers OMNIC Anywhere, a cloud-based platform for spectral searching and cross-device access with 10 GB of free storage. Both are instrument-centric tools. No clinical features. This is notable because Thermo Fisher also sells SampleManager LIMS, which does support HL7 messaging (as of version 21.1) and is used in clinical testing environments. But OMNIC and SampleManager do not integrate with each other. They are products of completely separate divisions within a $42.88 billion company.

Renishaw WiRE 5.5 is a full-featured Raman spectroscopy platform. It supports particle analysis, cosmic ray removal, fluorescence background removal, chemometrics, and multivariate analysis. It is well-regarded in the research community. No clinical workflow. Renishaw's entire Analytical Instruments & Medical Devices segment generated GBP 41.6 million in FY 2025 - just 5.8% of the company's GBP 713 million total revenue. Spectroscopy is a small fraction of what is primarily a metrology and precision manufacturing company.

Horiba LabSpec 6 handles Raman, photoluminescence, cathodoluminescence, and AFM-Raman imaging. It offers GxP and 21 CFR Part 11 compliance through its ProtectionPlus module - useful for regulated environments but not clinical ones. No HL7. No EHR integration. No patient workflow. Horiba is a global leader in Raman spectroscopy with over 50 years of history in the field, but like Thermo Fisher, Horiba's medical products (hematology analyzers, clinical chemistry systems generating approximately JPY 29 billion, or ~$193 million) live in a completely separate division with no connection to LabSpec.

Agilent MicroLab 5.8 and MicroLab Pharma 5.8 power the Cary 630 FTIR with picture-guided workflows designed for routine analysis. They include 21 CFR Part 11 compliance for pharmaceutical environments. No clinical workflow. Agilent's instruments are widely used in academic clinical research - cancer detection, ALS biomarkers, diabetes monitoring - but those are third-party research applications, not Agilent products.

PerkinElmer Spectrum 10 drives all PerkinElmer FT-IR and FT-NIR spectrometers. It offers an Enhanced Security option for 21 CFR Part 11 compliance. No clinical workflow, no HL7, no EHR. It is worth noting that PerkinElmer's corporate structure has changed significantly: the parent company renamed to Revvity Inc. in April 2023, retaining the Life Sciences & Diagnostics businesses, while New Mountain Capital acquired the Applied, Food, and Enterprise Services businesses (including all spectroscopy instruments) for up to $2.45 billion, keeping the PerkinElmer brand. The spectroscopy business is now privately held with over 6,000 employees.

Vendor software comparison

Every entry in the last four columns is "No." This is not a cherry-picked comparison. These are the current production software packages from every major spectroscopy instrument vendor. None of them address clinical workflow. For a deeper look at what clinical workflow architecture actually requires, see our article on clinical workflow design.

Where instrument software stops

The table above shows the absence of clinical features, but it helps to be concrete about what "clinical workflow" actually means in practice. Here is what happens when a clinician needs to run a spectroscopy-based diagnostic test - and where instrument software cannot help.

• Patient identification and context. Before a measurement means anything clinically, it must be associated with a patient. That means scanning or entering a medical record number (MRN), pulling the active order from the hospital information system, and linking the spectral acquisition to that specific patient encounter. No instrument software has a concept of a patient. OPUS has samples. LabSpec has measurement files. WiRE has datasets. None of these are patients.

• One-button acquisition for non-specialists. Instrument software is designed for spectroscopists. OPUS expects the user to select an experiment file, configure measurement parameters, and understand what they are looking at. A clinical test needs a single "Run Test" button. The parameters should be locked down and invisible to the operator. The clinician is a nurse or a lab technician, not a PhD spectroscopist.

• Classification result in clinical language. When OPUS finishes a measurement, it shows a spectrum. When a library search runs, it shows hit quality indices and compound matches. A clinician needs "Positive," "Negative," or "Indeterminate" - not "HQI: 847" or "Library Match: Streptococcus pyogenes (92.3%)." The translation from spectral data to clinical language requires a purpose-built ML classification pipeline and a results engine that maps model outputs to clinically actionable categories.

• HL7v2/FHIR result delivery. The classification result needs to flow into the patient's electronic health record. That means generating an HL7v2 ORU message or a FHIR DiagnosticReport resource and transmitting it to the hospital's integration engine (Mirth Connect, Rhapsody, Cloverleaf, or similar). This is standard clinical informatics - every lab analyzer in the hospital does it - but no spectrometer does.

• Billing and reimbursement. A diagnostic test that cannot be billed is a diagnostic test that will not survive. The workflow must capture the CPT code, associate it with the encounter, and generate the appropriate charge event. This requires integration with the facility's revenue cycle management system.

• Quality control and audit. Clinical labs operate under CLIA regulations. Every test run needs QC tracking, operator identification, lot number recording, and a complete audit trail that meets regulatory requirements. Instrument software has some audit trail capability (particularly with 21 CFR Part 11 modules), but these are designed for pharmaceutical manufacturing compliance, not clinical laboratory operations.

• Multi-site management. A clinical deployment is rarely a single instrument. It is a network of instruments across multiple sites, each with its own operators, QC schedules, and reporting relationships. The platform needs centralized management, remote monitoring, and aggregated analytics. ONET 3.1 handles networked instrument management, but only for Bruker instruments, and without any clinical overlay.

Each of these capabilities is individually well-understood. Hospitals run thousands of diagnostic tests daily that include all of them. The challenge is that the spectroscopy world and the clinical informatics world have developed independently, and no one has built the bridge. For a detailed look at how different spectroscopy modalities factor into this picture, see our FTIR, Raman, and NIR comparison.

Why the gap exists: six structural reasons

The absence of clinical workflow software from instrument vendors is not random. It is the predictable result of how these companies are structured, where their revenue comes from, and what their R&D organizations are optimized to build.

1. Software is an instrument accessory, not a product

In the spectroscopy industry, software exists to sell hardware. Bruker does not sell OPUS licenses as a standalone product - OPUS ships with the instrument. Thermo Fisher does not price OMNIC Paradigm separately from the spectrometer. Software is bundled, often at no additional charge, as part of the instrument sale.

The numbers tell the story. In the global spectroscopy market, instruments account for 76-78% of revenue, with software comprising only 22-24%. The total spectroscopy software market is approximately $1.1-1.5 billion. For a company like Thermo Fisher with $42.88 billion in annual revenue, clinical spectroscopy software would not move the needle. Even Bruker, at $3.37 billion in FY 2024 revenue, would find it difficult to justify a dedicated clinical software product line against its core instrument and consumables business.

When software is an accessory to hardware, investment in software tracks hardware investment. Features get added to software when they help sell more instruments. Clinical workflow does not help sell more instruments - it helps deploy instruments in a new market that requires an entirely different go-to-market motion, sales force, and support infrastructure.

2. Organizational silos separate spectroscopy from clinical products

The most revealing evidence comes from companies that already have clinical products and spectroscopy products - but keep them in completely separate divisions.

Thermo Fisher is the clearest example. Their Analytical Instruments segment (17% of $42.88 billion revenue) includes OMNIC and the spectroscopy product line. Their Specialty Diagnostics segment (10% of revenue) includes clinical testing products. Their Lab Products & Biopharma Services segment (52% of revenue) includes SampleManager LIMS, which actually has HL7 messaging capability. These three groups do not share engineering teams, product roadmaps, or go-to-market strategies. OMNIC does not integrate with SampleManager. Nobody inside Thermo Fisher has the organizational mandate to connect them.

Horiba reorganized from five segments to three in recent years (Energy & Environment, Bio & Healthcare, Materials & Semiconductor), but the underlying separation persists. Horiba Medical, which makes hematology analyzers and clinical chemistry systems generating approximately $193 million annually, has no connection to the LabSpec spectroscopy product line. Different engineering teams. Different sales channels. Different customers.

Bruker is the most interesting case. Their MALDI Biotyper franchise - approximately 8,000 installed systems, over 200 million identifications, FDA cleared - is a genuine clinical microbiology product. Their IR Biotyper extends this to FTIR-based microbial strain typing (currently Research Use Only, with FDA submissions planned for mycobacteria and fungi identification in 2026). But even Bruker keeps these products organizationally separate from OPUS and the general spectroscopy line.

These silos exist for rational reasons. Clinical products require:

• Different regulatory frameworks (SaMD classification, FDA clearance, CLIA compliance)
• Different quality systems (ISO 13485 vs. ISO 9001)
• Different sales processes (hospital procurement vs. lab equipment purchasing)
• Different support models (24/7 clinical support vs. business-hours technical support)

Merging these organizations would create enormous complexity for uncertain return.

3. R&D follows the money - and the money is in hardware

Bruker invested $376.5 million in R&D in FY 2024, representing 11.2% of revenue - up 28% from the prior year. That is a significant commitment. But look at where it went: hardware innovation and acquisitions. Recent acquisitions include Arxspan (electronic lab notebooks), ZONTAL (digital lab management), Chemspeed (lab automation), and NanoString ($392.6 million for spatial biology). All feed into the SciY platform for pharmaceutical R&D, not clinical diagnostics workflow.

In 2024, over 150 patents for miniaturized spectroscopy hardware were filed in the United States alone. The industry's inventive energy is overwhelmingly directed at building better, smaller, cheaper instruments. This makes sense - hardware innovation is what these companies are best at, and hardware differentiation is what drives purchasing decisions.

Thermo Fisher's R&D spend was $1.39 billion in FY 2024, but at 3.2% of revenue, it is spread across a massive portfolio. Analytical instruments are 17% of revenue. Spectroscopy is a fraction of that. And clinical spectroscopy software would be a fraction of a fraction. The capital allocation math does not work.

Agilent spent $455 million on R&D (6.5% of $6.51 billion revenue). Renishaw's entire Analytical Instruments & Medical Devices segment is GBP 41.6 million - the cost of a single mid-sized software engineering team at a Bay Area startup would represent a significant percentage of that segment's revenue.

4. Scale mismatch makes the market invisible

The global spectroscopy market is approximately $19.7 billion, projected to reach $35.7 billion by 2032. The molecular spectroscopy segment (which includes FTIR, Raman, and NIR - the modalities most relevant to clinical diagnostics) is approximately $7.1 billion in 2026. The Raman market alone is $3.66 billion in 2025, projected to reach $19.7 billion by 2034 at a remarkable 20.4% CAGR.

But the spectroscopy software market is only $1.1-1.5 billion total. Clinical spectroscopy workflow software - the subset that addresses hospital deployment - is a small fraction of that. For a $3.37 billion company like Bruker or a $42.88 billion company like Thermo Fisher, this market is a rounding error. It would not justify the organizational complexity, regulatory investment, and go-to-market restructuring required to pursue it.

This is not a criticism. Large companies are right to focus their resources where they can have the most impact relative to their scale. A $50 million clinical spectroscopy software opportunity is transformative for a focused startup. It is invisible to a company managing a $42.88 billion portfolio.

5. Clinical software requires fundamentally different competencies

Building instrument control software and building clinical workflow software are different disciplines.

Instrument software is physics and chemistry - signal processing, interferogram computation, Fourier transforms, baseline correction, spectral matching algorithms. The developers are typically spectroscopists and physicists.

Clinical workflow software is healthcare informatics - HL7 message parsing, FHIR resource construction, clinical terminology mapping (LOINC, SNOMED CT), EHR integration patterns, HIPAA-compliant data handling, clinical decision support, and regulatory compliance for Software as a Medical Device. The developers are healthcare software engineers who understand hospital IT infrastructure.

These are non-overlapping skill sets. A spectroscopy software team that can build a world-class Fourier transform engine cannot build an HL7 integration without hiring an entirely new team with entirely different expertise. And that team would need to be supported by regulatory affairs specialists, clinical affairs managers, and a clinical support organization - none of which exist in an instrument company's software division.

6. The business model is wrong for clinical software

Instrument vendors sell hardware with attached service contracts and consumables. Bruker's MALDI Biotyper franchise illustrates the model: the real revenue comes from consumables (reagent cartridges for microbial identification), not from the instrument itself. Thermo Fisher's revenue breakdown makes it explicit: consumables are 41% of revenue, services are 41.6%, and instruments are only 17.4%.

Clinical workflow software is a subscription SaaS business. It requires:

• Per-site licensing
• Ongoing updates for regulatory compliance
• 24/7 support with clinical-grade SLAs
• Continuous integration maintenance as hospital EHR systems evolve

This is a fundamentally different revenue model from selling instruments and consumables. It requires different pricing expertise, different contract structures, different customer success operations, and different financial metrics (ARR and net retention instead of unit volume and ASP).

Instrument vendors could build these capabilities, but doing so would mean building an entirely new business unit with a different culture, different hiring profile, different incentive structures, and different success metrics. It is easier and more rational to focus on what they already do well.

Case studies that prove the pattern

Three examples demonstrate that the gap persists even when vendors have the pieces to close it.

Thermo Fisher: OMNIC + SampleManager = no integration

Thermo Fisher sells OMNIC Paradigm for spectroscopy instrument control and SampleManager LIMS for laboratory information management, including HL7 messaging. These products exist within the same company. They do not integrate with each other.

A hospital that buys a Thermo Fisher FTIR spectrometer and a Thermo Fisher SampleManager LIMS still cannot run a clinical spectroscopy test without custom middleware to connect them. The spectral data from OMNIC does not flow into SampleManager. The patient context from SampleManager does not flow into OMNIC. They are products of separate divisions with separate engineering organizations, separate product managers, and separate P&L accountability.

This is the strongest evidence that the gap is structural, not incidental. If the market opportunity were large enough relative to Thermo Fisher's scale, they would connect these products. They have not, because the opportunity does not justify the organizational disruption at their scale.

Horiba: LabSpec + Horiba Medical = no connection

Horiba is a global leader in Raman spectroscopy with over 50 years of expertise. Horiba Medical is a respected clinical diagnostics company selling hematology analyzers and clinical chemistry systems. These businesses share a parent company, a brand, and nothing else.

A research group using Horiba's LabSpec 6 for clinical Raman studies cannot deploy their assay using Horiba Medical's clinical infrastructure. The spectroscopy division and the medical division have different customers, different regulatory frameworks, different sales organizations, and different technology stacks. After the recent reorganization into three segments (Energy & Environment, Bio & Healthcare, Materials & Semiconductor), there may be more organizational proximity between these groups, but there is no integrated product.

Bruker: the closest to clinical, still not general-purpose

Bruker is the vendor that has come closest to building clinical spectroscopy products. The MALDI Biotyper is FDA cleared, clinically deployed in thousands of hospitals, and generates significant consumables revenue. The IR Biotyper extends FTIR-based identification to microbial strain typing. The new IR Tracker targets hospital-acquired infection surveillance. FDA submissions for mycobacteria and fungi identification are planned for 2026.

But look at the scope. Every one of these products is specifically for microbial identification - a well-defined, high-volume clinical microbiology application with established reimbursement codes and a clear regulatory pathway. Bruker is not building a general-purpose clinical spectroscopy workflow platform. They are not building a system that could deploy an FTIR-based cancer screening test, or a Raman-based drug identification assay, or an NIR-based blood glucose monitor. Project Accelerate 3.0 is explicitly focused on the MALDI Biotyper consumables franchise and AI-ready labs in clinical microbiology.

This is a rational strategy. Bruker has a successful clinical microbiology business and is expanding it. But it leaves the general-purpose clinical spectroscopy workflow layer unaddressed. Anyone building a spectroscopy-based diagnostic that is not microbial identification cannot use Bruker's clinical infrastructure.

What the middleware layer needs to do

The gap between instrument software and clinical systems is well-defined. Bridging it requires a middleware platform that handles six categories of functionality that no instrument vendor provides. For a complete view of the journey from research prototype to clinical product, see our article on the 10 gaps from prototype to clinical product.

Instrument abstraction

The platform must communicate with spectrometers from multiple vendors - Bruker via OPUS command-line or DDE interfaces, Thermo Fisher via OMNIC COM automation, Horiba via LabSpec scripting, and so on. Each vendor has different APIs, different data formats, and different command structures. The middleware layer presents a unified interface: configure, acquire, retrieve spectrum. The clinician and the application logic above do not need to know which vendor's instrument is connected.

Clinical context management

Every measurement must be linked to a patient encounter. This means MRN validation, order retrieval, specimen tracking, operator identification, and QC lot association. The middleware manages this context and ensures that no measurement can be completed without proper patient and order linkage - a concept that does not exist in any instrument software.

ML classification pipeline

Raw spectra must be preprocessed (baseline correction, normalization, quality filtering) and classified by a trained model. The middleware manages model versioning, preprocessing pipelines, confidence scoring, and result interpretation. It translates model outputs into clinical categories and handles edge cases (low-confidence results, QC failures, instrument errors) according to defined clinical rules. This is an area where the lab staffing crisis makes automation particularly valuable - clinical labs cannot afford to have PhD spectroscopists manually interpreting every spectrum.

Integration engine

Results must be delivered to the hospital's information systems via HL7v2 or FHIR. The middleware generates properly formatted messages, manages the TCP/IP or REST connections to the integration engine, handles acknowledgments and retransmissions, and logs every transaction for audit purposes. This is standard clinical informatics work, but it requires deep knowledge of healthcare messaging standards and hospital IT infrastructure.

Regulatory compliance layer

The entire system must operate within the SaMD regulatory framework. This means validated software with documented verification and validation, change control procedures, complaint handling, adverse event reporting, and ongoing post-market surveillance. The middleware must maintain an audit trail that satisfies both CLIA inspection requirements and FDA software validation expectations.

Multi-site operations

Clinical deployments are networks, not individual instruments. The platform must support centralized configuration management, remote software updates, aggregated quality metrics, cross-site analytics, and role-based access control. A laboratory director needs to see QC performance across all sites. A quality manager needs to review flagged results from any site. An administrator needs to manage operator credentials across the network.

The AI adoption gap reinforces the opportunity

One additional data point deserves attention. According to recent industry surveys, only 11.8% of spectroscopy organizations have AI fully integrated into their workflows, and 23.5% have no plans to adopt AI at all. This means the industry is early in the adoption curve for precisely the technology that makes clinical spectroscopy viable.

Clinical spectroscopy depends on ML classification. A trained model is what transforms a raw spectrum into a diagnostic result. If the broader spectroscopy industry is only beginning to adopt AI, the clinical middleware layer - which must include ML classification as a core capability - is even further from being addressed by incumbent vendors.

This aligns with the structural analysis above. Instrument vendors are optimized to build hardware and instrument control software. AI/ML for clinical classification is yet another competency that falls outside their core expertise, further widening the gap that a purpose-built platform needs to fill.

Key Takeaways

For clinical spectroscopy developers: Do not wait for instrument vendors to build the clinical workflow layer. It is not coming. The structural reasons - revenue models, organizational silos, scale mismatch, competency boundaries - are durable. Adopt a purpose-built clinical workflow platform for spectroscopy or build the middleware independently, and treat instrument software as a data acquisition layer to abstract over.

For laboratory directors evaluating spectroscopy-based diagnostics: Understand that buying an instrument does not give you a clinical test. The instrument is the sensing element. The clinical workflow - patient context, classification, result delivery, billing, QC - is a separate system that must be procured or built separately. Budget and plan accordingly.

For instrument vendors considering clinical markets: The opportunity is real but requires a fundamentally different organizational structure, business model, and competency set. Bruker's microbial identification franchise demonstrates that it can be done for specific, well-defined applications. A general-purpose platform would require a dedicated business unit with clinical software DNA - or a partnership with a company that already has it.

For investors evaluating the space: The spectroscopy software market is projected to grow from $1.1-1.5 billion to $3.2 billion by 2033. The clinical middleware layer is the highest-value, most defensible segment of that market. It sits at the intersection of:

• Instrument integration (high switching costs)
• Regulatory compliance (high barriers to entry)
• Clinical workflow (high customer lock-in)

The fact that no instrument vendor is building it is not a risk - it is the structural condition that makes the opportunity durable.

The instruments are excellent. The science is proven. The clinical need is real. What is missing is the software layer that connects them - and the companies best positioned to build that layer are not the ones that build the instruments.