Thermo Fisher OMNIC Integration: Automating Nicolet FTIR and DXR Raman for Clinical Workflows

Thermo Fisher Scientific has the largest spectroscopy installed base in the world. Their Nicolet FTIR line - from the compact Summit LITE to the modular iS50 - and the DXR3 Raman family are fixtures in pharmaceutical QC labs, clinical research facilities, and industrial testing environments. If you are building automated spectroscopy workflows, there is a significant chance you need to interface with OMNIC.

The challenge: OMNIC was designed for spectroscopists, not for software developers. Thermo Fisher's documentation for programmatic access is scattered across knowledge base articles behind login walls, PDF manuals hosted on university servers, and application notes buried in marketing pages. There is no single, comprehensive public API reference. The interfaces that exist span five generations of technology - from Windows DDE in the 1990s, through COM/ActiveX and Macros Pro, to the modern .NET-based Paradigm SDK and the visual workflow tile editor.

This guide maps the entire landscape. We cover every available integration path for Thermo Fisher spectroscopy instruments, with working code where possible and honest assessments where documentation runs thin. If you have already read our Bruker OPUS integration guide, you will find this article follows the same structure - a companion piece for the other major FTIR vendor.

The Thermo Fisher spectroscopy ecosystem

Before discussing integration interfaces, it helps to understand what you are integrating with. Thermo Fisher's spectroscopy instrument lineup spans multiple price points, modalities, and use cases.

FTIR instruments

Nicolet iS50 is Thermo's flagship research FTIR. It is modular - configurable with multiple sampling accessories (ATR, DRIFTS, transmission, specular reflectance), an integrated diamond ATR, and optional near-IR and Raman modules on the same platform. The iS50 is common in pharma R&D and advanced QC labs where a single instrument handles diverse analyses. Key specs: resolution better than 0.09 cm⁻¹, signal-to-noise ratio of approximately 65,000:1, dual-source capability (Polaris IR source plus tungsten-halogen), gold mid-IR optics, and an automated beamsplitter exchanger for multi-range operation. Spectral range extends from 27,000 to 15 cm⁻¹ with appropriate accessories.

Nicolet iS20 is the mid-range workhorse. It covers routine FTIR applications - material identification, quality verification, and incoming material testing. Resolution better than 0.25 cm⁻¹, signal-to-noise ratio of 50,000:1, spectral range of 7,800 to 350 cm⁻¹. This is the instrument you will most commonly encounter in pharmaceutical QC and industrial testing.

Nicolet Summit is the compact FTIR family aimed at routine analysis. Three variants:

All Summit models share the LightDrive Optical Engine (eliminates hot spot migration), Smart Background technology, resolution better than 0.6 cm⁻¹, spectral range of 8,000 to 350 cm⁻¹, and cGxP compliance qualification (Ph. Eur., USP, JP, CP). For clinical deployments where a non-specialist operator runs the instrument, the Summit PRO's simplified interface and built-in computer make it the most deployment-friendly option.

Raman instruments

The DXR3 family includes four instruments sharing the same optical platform:

All DXR3 instruments capture the full spectral range (3,500 to 50 cm⁻¹) in a single CCD exposure - no stitching artifacts. Laser options include 455 nm, 532 nm, 633 nm, and 785 nm, and the lasers are interchangeable and sharable across the entire DXR3 family. Auto-alignment and calibration require no manual procedures.

The DXR3 SmartRaman+ deserves special attention for industrial integration: it features OPC UA connectivity for Industry 4.0 manufacturing environments. This is the only Thermo Fisher spectroscopy instrument with a standardized industrial automation protocol, making it the natural choice for PAT (Process Analytical Technology) applications in pharmaceutical manufacturing.

Software stack

OMNIC (legacy) is the software that controlled all Thermo Fisher FTIR and Raman instruments for decades. It runs on Windows and provides spectral acquisition, processing, library searching, quantitative analysis, and three automation interfaces: DDE, COM/ActiveX, and Macros Basic/Pro.

OMNIC Paradigm (current, v2.8 HF2 as of September 2025) is the current-generation software, replacing legacy OMNIC. It features three interface views (Desktop, Touchscreen, and Operator), visual drag-and-drop workflow tiles, cloud integration through Thermo Fisher Connect, and a .NET-based SDK (ParadigmLib) for programmatic control. OMNIC Paradigm controls all current Nicolet FTIR and DXR Raman instruments.

OMNIC Anywhere is a cloud-based companion platform running on AWS, offering spectral viewing, peak-picking, manipulation, and cross-device sharing with 10 GB of free storage. It is not an instrument control interface - you cannot trigger measurements through OMNIC Anywhere. It works from Windows or Apple devices via browser.

Instrument-software mapping

Integration interfaces

OMNIC provides five distinct integration paths across its legacy and current software. This matches Bruker OPUS's five interfaces (DDE, Named Pipes, HTTP, OPC, COM/ActiveX) in quantity, but the character is different: Bruker's interfaces are better documented publicly, have stronger community tooling, and have remained more stable across versions. Thermo Fisher's interfaces are more fragmented across software generations, with the critical Paradigm SDK documentation sitting behind a login wall.

Interface 1: Paradigm SDK (ParadigmLib .NET assembly)

The Paradigm SDK is Thermo Fisher's forward-looking automation interface. It is a .NET assembly called ParadigmLib that replaces the OMNIC Paradigm GUI client - custom applications communicate with the Paradigm backend directly through the DLL.

What the SDK provides

ParadigmLib exposes a RemoteParadigm object that connects to the Paradigm backend service. Through this object, your application can:

• Calibrate: Align the spectrometer (returns SpectrometerAlignInfo with alignment state and interferogram data)
• Acquire: Trigger background and sample measurements (via StartBackgroundMeasurement and StartSampleMeasurement, both accepting callbacks for progress and final spectral data)
• Process: Apply ATR correction, baseline correction, and other processing steps
• Run workflows: Execute saved workflow configurations and import workflow parameters
• Diagnose: Run instrument diagnostics

Constraints

• No REST API. The interface is entirely .NET-based. There is no HTTP endpoint, no JSON, no WebSocket. Your automation application must load the ParadigmLib assembly.
• Requires OMNIC Paradigm 2.3+. The SDK is not available for legacy OMNIC.
• Documentation is behind a login wall. The full API reference lives on Thermo Fisher's Knowledge Base (knowledge1.thermofisher.com) and is not publicly indexed by search engines. You need a Thermo Fisher account.
• Windows only. The .NET assembly runs on Windows. Cross-platform .NET Core support is not documented.

Working code

From C# (the primary supported language):

using ThermoFisher.Paradigm;
 
// Create and initialize the connection to Paradigm backend
var paradigm = new RemoteParadigm();
paradigm.Initialize();
 
// Check spectrometer alignment
var alignInfo = paradigm.AlignSpectrometer();
Console.WriteLine($"Alignment state: {alignInfo.AlignState}");
 
// Collect a background measurement
paradigm.StartBackgroundMeasurement(
    progressCallback: (progress) =>
    {
        Console.WriteLine($"Background: {progress}%");
    },
    completedCallback: (spectrum) =>
    {
        Console.WriteLine("Background collected");
    }
);
 
// Collect a sample measurement
paradigm.StartSampleMeasurement(
    progressCallback: (progress) =>
    {
        Console.WriteLine($"Sample: {progress}%");
    },
    completedCallback: (spectrum) =>
    {
        // spectrum contains the acquired spectral data
        Console.WriteLine($"Sample acquired: {spectrum.NumberOfPoints} points");
    }
);

From Python (via pythonnet):

import clr
# pythonnet requires specific setup:
# 1. Install pythonnet: pip install pythonnet
# 2. Copy python.exe.config and pythonw.exe.config to your Python folder
#    (files provided in SDK package at C:\Users\Public\Documents\
#     thermo scientific\SDK\Python)
 
# Load the Paradigm SDK assembly
clr.AddReference("ParadigmLib")
from ThermoFisher.Paradigm import RemoteParadigm
 
paradigm = RemoteParadigm()
paradigm.Initialize()
 
# Align the spectrometer
align_info = paradigm.AlignSpectrometer()
print(f"Alignment state: {align_info.AlignState}")
 
# Start a sample measurement with callbacks
def on_progress(progress):
    print(f"Measuring: {progress}%")
 
def on_complete(spectrum):
    print(f"Acquired: {spectrum.NumberOfPoints} points")
 
paradigm.StartSampleMeasurement(on_progress, on_complete)

The Python approach requires pythonnet to bridge Python to the .NET runtime. The SDK ships example Python applications at C:\Users\Public\Documents\thermo scientific\SDK\Python.

When to use the Paradigm SDK

The SDK is the right choice for building new automation applications against current OMNIC Paradigm installations. It provides the most complete programmatic access to the current instrument platform. If you are writing in C# or have .NET infrastructure, this is the cleanest path. The pythonnet bridge works but adds a dependency layer that can be fragile.

Interface 2: DDE (Dynamic Data Exchange) — legacy OMNIC

DDE is the oldest integration interface, available in legacy OMNIC. Like Bruker OPUS, OMNIC registers as a DDE server on Windows, accepting command strings from client applications.

What DDE provides

A documented set of commands covering measurement control, file operations, spectral processing, and display management. The full command reference is published in the "OMNIC DDE Commands & Parameters" manual (publicly available via Caltech's FTIR resource archive).

Constraints

• Legacy OMNIC only. DDE is not available in OMNIC Paradigm.
• Same PC only. DDE is a local Windows IPC protocol.
• OMNIC must be running. Your application connects to a running OMNIC instance.
• Single client. One DDE client at a time.

Working code

An open-source C# library exists specifically for OMNIC DDE automation: specshell.software.omnic.dde. It isolates atomic DDE calls to OMNIC for Nicolet instruments and exposes them in a generic, consumable way.

// Using the specshell OMNIC DDE library
using SpecShell.Software.Omnic.Dde;
 
var omnic = new OmnicDdeClient();
omnic.Connect();
 
// Collect a background spectrum
omnic.ExecuteCommand("CollectBackground");
 
// Collect a sample spectrum
omnic.ExecuteCommand("CollectSample");
 
// Save the result
omnic.ExecuteCommand("SaveAs", @"C:\Spectra\result.spa");
 
omnic.Disconnect();

From Python, you can use win32ui.dde directly:

import win32ui
import dde
 
server = dde.CreateServer()
server.Create("PythonClient")
conversation = dde.CreateConversation(server)
 
# Connect to OMNIC DDE server
conversation.ConnectTo("OMNIC", "System")
 
# Execute commands
conversation.Exec("CollectBackground")
conversation.Exec("CollectSample")
conversation.Exec(f'SaveAs "C:\\Spectra\\result.spa"')

The DDE command set includes: CollectBackground, CollectSample, SaveAs, OpenFile, CloseFile, FindPeaks, BaselineCorrect, ATRCorrect, LibrarySearch, and dozens more. Each command maps to a menu action in OMNIC.

When to use DDE

DDE is the right choice for automating legacy OMNIC installations when you need to trigger measurements and processing from an external application. If you are maintaining existing automation code that targets legacy OMNIC, DDE is likely what it uses. For new development against OMNIC Paradigm, use the Paradigm SDK instead.

Interface 3: COM/ActiveX (OmnicCom) — legacy OMNIC

Legacy OMNIC registers as an ActiveX automation server via omnic32.exe. This provides a COM-based interface that can be consumed from any COM-compatible language.

What COM provides

The primary mechanism is an ExecuteCommand method - nearly everything in OMNIC is handled through this single method with different command strings and parameters. Setup parameters (.exp experiment files) can be specified on disk rather than set programmatically.

Constraints

• Legacy OMNIC only. The COM/ActiveX interface (OmnicCom) is not available in OMNIC Paradigm. Paradigm uses the .NET SDK instead.
• Windows only. COM is a Windows technology.
• Breaking changes. The transition from legacy OMNIC to OMNIC Paradigm broke existing COM automation code. This is not a theoretical risk - Thermo Fisher has acknowledged the incompatibility. See our article on build vs. buy decisions for more on this.

Working code

From Excel VBA (a common use case in pharma QC):

' Add reference: Tools > References > omnic32.exe
Dim omnic As Object
Set omnic = CreateObject("OMNIC.Application")
 
' Collect a reference spectrum
omnic.ExecuteCommand "CollectBackground"
 
' Collect a sample spectrum
omnic.ExecuteCommand "CollectSample"
 
' Get spectral data into Excel
Dim numPoints As Long
numPoints = omnic.GetNumberOfPoints()
 
For i = 0 To numPoints - 1
    Cells(i + 1, 1).Value = omnic.GetXValue(i)  ' wavenumber
    Cells(i + 1, 2).Value = omnic.GetYValue(i)  ' absorbance
Next i

From Python using win32com:

import win32com.client
 
omnic = win32com.client.Dispatch("OMNIC.Application")
 
# Open a spectral file
omnic.OpenFile(r"C:\Spectra\sample.spa")
 
# Access spectral data
spectrum = omnic.ActiveDocument
num_points = spectrum.GetNumberOfPoints()
x_data = spectrum.GetXData()
y_data = spectrum.GetYData()
 
print(f"Spectrum: {num_points} points")
print(f"Range: {x_data[0]:.1f} - {x_data[-1]:.1f} cm-1")

Discovery technique

Since Thermo Fisher does not publish a comprehensive COM API reference, use Python's win32com to inspect the type library:

import win32com.client
 
# Generate a cached Python wrapper with all available methods
omnic = win32com.client.gencache.EnsureDispatch("OMNIC.Application")
print(dir(omnic))

This generates a Python module with method signatures - the closest thing to API documentation you will get for the COM interface.

When to use COM

COM automation is the right choice for legacy OMNIC environments where VBA/Excel integration is needed (common in pharma QC workflows that predate dedicated automation software) or where .NET applications need deeper access than DDE provides.

Interface 4: Macros Basic/Pro — legacy OMNIC

Legacy OMNIC included two tiers of built-in macro automation:

• Macros Basic provides simple scripting for routine tasks: file conversion, looping data collection, and spectrum processing sequences.
• Macros Pro is the advanced tier for standardizing spectral acquisition, processing, interpretation, and reporting. It includes a workflow authoring environment for building operator-guided sequences.

Constraints

• Legacy OMNIC only. Macros Basic and Macros Pro do not run in OMNIC Paradigm. If you are migrating from legacy OMNIC to Paradigm, all macros must be rebuilt as Paradigm workflow tiles or SDK applications.
• Proprietary scripting language. Macros use OMNIC's own scripting syntax, not Python or VBA.

Legacy Macros are not recommended for new development. We mention them because you may encounter them in existing deployments, particularly in pharmaceutical QC labs that have been running OMNIC automation for years and face a migration decision. The migration path is to rebuild as Paradigm workflows (tile-based) or Paradigm SDK applications.

Interface 5: File-based integration (watch folder)

File-based integration is the most reliable, most portable, and least vendor-dependent approach. It works with both legacy OMNIC and OMNIC Paradigm, requires no special licenses, and is the approach we recommend as the primary integration path for clinical workflows.

How it works

1. OMNIC (or Paradigm) is configured to automatically save acquired spectra to a designated output folder.
2. Your workflow application monitors that folder for new files.
3. When a new spectral file appears, your application reads it, runs classification, and continues the clinical workflow.

For bidirectional communication, pair the file watcher with a Paradigm workflow tile or SDK application:

1. Your workflow application writes a request file (JSON) to an input folder.
2. A Paradigm SDK application or workflow script monitors the input folder and triggers the requested measurement.
3. OMNIC writes the result to the output folder.
4. Your workflow application picks up the result.

Constraints

• Latency. File system polling introduces latency. Using FileSystemWatcher (C#) or watchdog (Python) with OS-level notifications reduces this to under 100ms on Windows, acceptable for clinical workflows where the measurement itself takes 5-30 seconds.
• File locking. OMNIC may hold a write lock briefly after acquisition. Your watcher must handle "file not ready" errors with retry logic.
• No direct instrument control. In the simplest form, file watching only captures output. The bidirectional pattern adds control capability but requires a Paradigm-side component.

Working code

Python watcher using watchdog:

import time
from pathlib import Path
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
 
class SpectrumHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.src_path.endswith(('.spa', '.spg', '.spc', '.dx')):
            self.process_spectrum(event.src_path)
 
    def process_spectrum(self, filepath):
        path = Path(filepath)
        # Wait for OMNIC to release the file
        for _ in range(10):
            try:
                data = path.read_bytes()
                if len(data) > 0:
                    break
            except PermissionError:
                time.sleep(0.5)
 
        print(f"New spectrum: {filepath}")
        # Parse, classify, and continue clinical workflow
 
watch_dir = r"C:\OMNIC\AutoExport"
observer = Observer()
observer.schedule(SpectrumHandler(), watch_dir, recursive=False)
observer.start()

C# watcher:

var watcher = new FileSystemWatcher(
    @"C:\OMNIC\AutoExport");
watcher.Filters.Add("*.spa");
watcher.Filters.Add("*.dx");
watcher.Filters.Add("*.spc");
 
watcher.Created += (sender, e) =>
{
    Thread.Sleep(500); // Brief delay for OMNIC write completion
 
    byte[] data = File.ReadAllBytes(e.FullPath);
    Console.WriteLine($"New spectrum: {e.Name}, {data.Length} bytes");
    // Parse, classify, continue workflow
};
 
watcher.EnableRaisingEvents = true;

When to use file-based integration

File-based integration is the right choice when you need a robust, version-independent integration that survives OMNIC software upgrades. It is the approach we recommend for production clinical deployments because it has the fewest dependencies on Thermo Fisher's internal APIs. It works identically across legacy OMNIC and Paradigm.

OMNIC Paradigm workflows (tile-based automation)

OMNIC Paradigm includes a built-in visual workflow editor with drag-and-drop tiles. This replaces the legacy Macros Basic/Pro system with a more modern, accessible approach to automation.

How it works

The workflow editor provides 18 tiles covering the full analytical workflow:

You build a workflow by dragging tiles into a sequence, configuring each tile's parameters, and saving the workflow as an .rwfl file (or .rdep package for distribution). Operators run saved workflows with a single click. The system enforces the tile sequence - operators cannot skip steps or modify locked parameters.

Security Suite and Managed Workflows

For regulated environments (pharmaceutical QC, GMP manufacturing), the Security Suite add-on provides:

• 21 CFR Part 11 compliance: Electronic signatures, audit trail database, event logging covering user actions, system events, and instrument events. See our detailed article on 21 CFR Part 11 compliance.
• Managed Workflows (v2.8+): Administrators control workflow lifecycle through secure data folders. Workflow states are tracked, access is restricted per state, and standard operating procedures are enforced through the system.
• Method locking: Measurement parameters are locked into the workflow. Operators cannot modify resolution, scan count, or spectral range without authorized method changes.

Integration with workflow tiles

Direct programmatic integration with the workflow tile editor is limited - it is designed as a visual, operator-facing tool, not an API. The most practical approach for clinical workflows is to treat Paradigm workflows as the operator and instrument compliance layer, and integrate at the data output level:

1. Paradigm workflows handle operator guidance, method enforcement, and per-instrument audit trail.
2. Workflows export results to a designated folder (JCAMP-DX, SPC, or TSV format).
3. Your clinical workflow platform picks up results via the file-based watch pattern.
4. Your platform handles clinical workflow: patient context, classification, HL7 output, billing, multi-site aggregation.

File formats

Thermo Fisher instruments produce spectral data in several formats. Understanding the format landscape is essential for building robust parsing.

SPA and SPG (OMNIC native)

The .spa format stores a single spectrum with full metadata - instrument parameters, acquisition date, operator, resolution, number of scans, spectral units (absorbance, transmittance, reflectance, Kubelka-Munk, Raman intensity, and others), and x-axis units (cm⁻¹, nm, µm, or Raman shift). The .spg format stores spectrum groups - multiple spectra in a single file. The .srs format stores time series data from legacy OMNIC (importable into Paradigm).

The SPA binary format specification is proprietary and not published by Thermo Fisher. Community tools are based on reverse engineering. File sizes are typically 10-160 KB per spectrum.

# Parsing .spa files with spectrochempy
import spectrochempy as scp
 
# read_omnic handles both .spa and .spg files
dataset = scp.read_omnic(r"C:\Spectra\sample.spa")
wavenumbers = dataset.x.values
absorbance = dataset.data[0]
 
print(f"Points: {len(wavenumbers)}")
print(f"Range: {wavenumbers[0]:.0f} - {wavenumbers[-1]:.0f} cm-1")

Additional open-source parsers for SPA files:

SPC (Galactic/Thermo standard)

The .spc format originated at Galactic Industries. When Thermo Fisher acquired Galactic, SPC became a secondary standard across Thermo instruments. It is more widely supported than .spa by third-party software. OMNIC Paradigm lists SPC as "Grams" format in its import/export menus. For detailed SPC parsing code and format structure, see our guide to spectral data formats.

from spc_spectra import SPC
 
spc_file = SPC.from_file(r"C:\Spectra\sample.spc")
x = spc_file.x
y = spc_file.sub[0].y
 
print(f"Resolution: {spc_file.fres}")
print(f"Log text: {spc_file.log_other}")

JCAMP-DX export

OMNIC and OMNIC Paradigm both export to JCAMP-DX (.dx, .jdx), the IUPAC standard for spectral data exchange. This is the preferred export format for cross-vendor interoperability.

from jcamp import jcamp_readfile
 
data = jcamp_readfile(r"C:\Spectra\sample.dx")
wavenumbers = data["x"]
absorbance = data["y"]
 
print(f"Title: {data['title']}")
print(f"Origin: {data.get('origin', 'unknown')}")

TSV text export

OMNIC Paradigm supports tab-separated value export (listed as "TSV Text" in the export menu). This is functionally equivalent to CSV but tab-delimited. Native comma-separated CSV is not explicitly listed in OMNIC Paradigm's export options, though the TSV format is universally parseable.

Import capabilities

OMNIC Paradigm can import spectral data from other vendor formats, which is useful in multi-vendor labs:

• OMNIC Spectra (.spa, .spg)
• Grams/SPC (.spc)
• JCAMP-DX (.dx, .jdx)
• Bruker OPUS files
• Jasco files
• PerkinElmer files
• TSV Text
• Time Series (.srs)

The ability to import Bruker OPUS files directly into OMNIC Paradigm is notable for labs transitioning between vendors or operating both instrument brands.

Format recommendation

For clinical deployments, configure OMNIC Paradigm to auto-export in JCAMP-DX format after each acquisition. This gives you a vendor-neutral, metadata-rich file that your workflow platform can parse without any dependency on Thermo-specific libraries.

Bridging to clinical workflows

Knowing how to extract data from OMNIC is necessary but not sufficient. A clinical deployment requires the same additional layers that every spectroscopy instrument needs - and that no instrument vendor provides.

The adapter pattern

At SpectraDx, we use an instrument adapter architecture. Each vendor's spectrometer gets an adapter that translates between the vendor-specific interface and a standardized internal API. The clinical workflow platform only talks to the adapter interface - it never calls OMNIC or OPUS directly.

[Clinical Workflow Platform]
         |
    [Adapter Interface]     ← Standardized: configure, acquire, retrieve
         |
   ┌─────┴─────┐
   |            |
[Bruker         [Thermo
 Adapter]        Adapter]
   |            |
[OPUS via       [OMNIC via
 DDE]            file watch +
   |             Paradigm SDK]
   |            |
[Alpha II]      [Nicolet iS20]

The Bruker adapter uses DDE via brukeropus (detailed in our OPUS guide). The Thermo adapter uses the file-based watch pattern, optionally augmented by the Paradigm SDK for direct instrument control. Both adapters present the same interface to the platform:

from abc import ABC, abstractmethod
from dataclasses import dataclass
import numpy as np
 
@dataclass
class SpectrumResult:
    wavenumbers: np.ndarray
    intensities: np.ndarray
    instrument_id: str
    acquisition_time: str
    metadata: dict
 
class InstrumentAdapter(ABC):
    @abstractmethod
    def acquire_background(self) -> bool: ...
 
    @abstractmethod
    def acquire_sample(self) -> SpectrumResult: ...
 
    @abstractmethod
    def get_instrument_status(self) -> dict: ...
 
class ThermoAdapter(InstrumentAdapter):
    def __init__(self, watch_dir: str, request_dir: str):
        self.watch_dir = watch_dir
        self.request_dir = request_dir
 
    def acquire_sample(self) -> SpectrumResult:
        # Write measurement request
        request = {"action": "measure", "scans": 32, "resolution": 4}
        request_path = Path(self.request_dir) / f"{uuid4()}.json"
        request_path.write_text(json.dumps(request))
 
        # Wait for result in watch directory
        result_path = self._wait_for_result(request_path.stem)
 
        # Parse the exported spectrum
        data = jcamp_readfile(str(result_path))
        return SpectrumResult(
            wavenumbers=data["x"],
            intensities=data["y"],
            instrument_id="nicolet-is20-001",
            acquisition_time=datetime.utcnow().isoformat(),
            metadata=dict(data)
        )

This architecture means adding Thermo Fisher instrument support to a deployment that already runs on Bruker is a configuration change, not a platform rebuild. The clinical workflow - patient identification, classification pipeline, HL7 output, billing - is identical regardless of which instrument is connected. For the full architecture, see our article on building clinical workflow software.

OMNIC vs. OPUS: a practical comparison

Labs choosing between Bruker and Thermo Fisher instruments - or, more commonly, labs that already have both - need to understand how the software stacks compare for automation purposes.

Where OPUS wins

OPUS has a clear advantage in open-source Python tooling. The brukeropus library provides a clean, well-documented Python wrapper for DDE automation, and three additional libraries handle file parsing. If your team writes Python and needs rapid prototyping, Bruker instruments are simpler to automate. OPUS interfaces have also been more stable across versions - code written for OPUS 7 generally works on OPUS 9.

Where OMNIC Paradigm wins

The Paradigm SDK is architecturally more modern than any of OPUS's interfaces. A proper .NET assembly with typed methods and callback patterns is a significant step up from DDE command strings. The visual workflow tile editor is a capability OPUS does not match - for pharma QC environments where non-developer laboratory staff need to build automated sequences, the tile editor is genuinely easier to use than writing OPUS macros. And the OPC UA connectivity on the DXR3 SmartRaman+ is a modern industrial protocol, while OPUS primarily supports the older OPC DA.

Where both fall short

Neither OPUS nor OMNIC provides clinical workflow capability. No patient context. No HL7/FHIR messaging. No billing automation. No multi-vendor instrument management. No clinician-facing UI. Both are spectroscopy workbenches designed for spectroscopists. The gap between what instrument software provides and what a clinical deployment requires is identical for both vendors.

This is precisely the layer that SpectraDx builds. The same platform manages workflows across Bruker and Thermo instruments - the adapter pattern abstracts the vendor differences so that the clinical workflow is instrument-agnostic.

Practical integration recommendations

Based on our experience integrating Thermo Fisher instruments into clinical and pharmaceutical workflows, here is our decision framework.

For new deployments on OMNIC Paradigm

Use the Paradigm SDK for instrument control plus file-based export for data flow. The SDK gives you real-time control (trigger measurements, check alignment, run diagnostics). Configure Paradigm to auto-export results as JCAMP-DX to a watched folder for data ingestion. This two-layer approach gives you the best of both: reliable data flow through file watching, with instrument control through the SDK when needed.

For legacy OMNIC deployments

Use DDE or COM for instrument control. If you have working automation code, keep using it. The specshell DDE library provides a clean C# interface. But have a Paradigm migration plan - Thermo Fisher is pushing the entire installed base toward Paradigm, and legacy OMNIC will eventually lose support. Build new features against the file-based pattern so they survive the migration.

For pharmaceutical QC environments

Leverage Paradigm workflows with Security Suite for instrument-level compliance. Let the tile-based workflow editor handle operator guidance, method locking, and per-instrument audit trail. Integrate at the data output level with your workflow platform for cross-instrument compliance, multi-site management, and centralized reporting. For a complete guide to automating pharma QC across multiple instrument vendors, see our dedicated article on pharma QC spectroscopy automation.

For multi-vendor labs

Use the adapter pattern. If your lab has both Bruker and Thermo instruments - or Horiba, Renishaw, or any other vendor - build a unified adapter layer. This is what clinical workflow platforms like SpectraDx provide. For more on why instrument vendors do not build this layer themselves, see our article on the spectroscopy software gap.

Further reading

• Bruker OPUS Python Integration: Guide to All 5 Interfaces - the companion guide for Bruker instruments
• Building Clinical Workflow Software for Spectroscopy-Based Diagnostics - full system architecture
• Spectral Data Formats: JCAMP-DX, SPC, and ANDI Compared - detailed format parsing guide
• Spectroscopy LIMS Integration: Protocols and Middleware Guide - connecting instruments to LIMS

SpectraDx is clinical workflow software for spectroscopy-based diagnostics. We handle the integration layer between your spectrometer and your clinician - across Bruker, Thermo Fisher, Horiba, and more. Learn more or get in touch.