Vendor-Agnostic Middleware for Medical Devices: How Manufacturer-Neutral Platforms Unify Multi-Brand PFT Equipment Into a Single Database

Feb 20, 2026

Respiratory and sleep labs routinely operate equipment from multiple manufacturers, yet most pulmonary function test software is built to serve only the device it came with. Vendor-agnostic middleware solves this by sitting between your equipment and your reporting system, normalising data from any brand into a single, structured database. The result is a unified clinical record, fewer manual errors, and a lab that is no longer hostage to any one manufacturer's roadmap.

TL;DR

  • Vendor-agnostic middleware acts as a translation layer between multi-brand PFT devices and a central reporting database.

  • Manufacturer lock-in is a real operational and financial risk for respiratory labs running mixed-brand equipment.

  • A unified database reduces double data entry, improves data integrity, and supports better clinical decisions.

  • Regulatory compliance and cybersecurity obligations apply to middleware platforms, not just the devices themselves.

  • Platforms like Rezibase are built from the ground up to be manufacturer-neutral, removing the integration burden from lab staff.

What Is Vendor-Agnostic Middleware in a Medical Device Context?

Middleware is software that "sits in the middle" between two different sets of devices, systems, or software, as defined by the College of American Pathologists. In a medical device context, it handles the messy work of data acquisition, protocol conversion, and format normalisation so that downstream systems receive clean, consistent data regardless of where it originated.

For respiratory labs, this means a spirometer from one manufacturer, a body plethysmograph from another, and a DLCO device from a third can all feed into the same reporting workflow without manual re-entry or bespoke connectors for each machine.

Key functions of medical device middleware:

  • Protocol conversion: Translates proprietary device output into a standard format.

  • Data normalisation: Reconciles differences in units, field names, and data structures.

  • Routing: Directs data to the correct patient record, worklist, or downstream system.

  • Audit trail: Logs every data transaction for compliance and traceability.

Why Does Vendor Lock-In Create Real Problems for PFT Labs?

Vendor lock-in occurs when a lab's data, workflows, or reporting infrastructure becomes so tightly coupled to a single manufacturer's ecosystem that switching becomes prohibitively expensive or disruptive.

According to Capsule Technologies, a vendor-neutral approach is key to maximising medical device data potential and improving patient outcomes. The alternative, building around a single vendor's proprietary stack, creates fragility at every level.

Practical consequences for respiratory labs running locked-in systems:

Problem

Impact

New device purchase constrained by software compatibility

Limits clinical and procurement flexibility

Data siloed per manufacturer platform

No single patient view across test types

Upgrade cycles dictated by vendor, not clinical need

Operational disruption on the vendor's schedule

Switching costs inflated by data migration complexity

Labs stay on outdated systems longer than they should

The financial and clinical risk compounds over time. A lab that acquires a new spirometer but cannot integrate it into its existing pulmonary function test software without expensive custom work is effectively paying twice.

How Does a Manufacturer-Neutral Platform Actually Unify Multi-Brand Equipment?

The technical architecture follows a consistent pattern. As described in SP Software's guide to medical device integration, middleware acts as an intermediary that handles diverse protocols and data formats, performing data acquisition, normalisation, and protocol conversion before passing structured data to the receiving system.

For a PFT lab, the practical workflow looks like this:

  1. Device generates output in its native format (PDF, HL7, proprietary binary, DICOM).

  2. Middleware receives the output and identifies the data type, device source, and patient identifiers.

  3. Normalisation engine converts the data into a consistent schema, extracting discrete values such as FEV1, FVC, flow-volume loops, and DLCO.

  4. Data is written to a central database linked to the correct patient record.

  5. Reporting layer presents a unified view for the reporting scientist or physician, regardless of which device produced the data.

This is precisely what Rezibase's Magic Import function does. It accepts device reports directly, automatically extracts discrete data including flow-volume loops, and writes them into a single patient record. No manual transcription, no separate logins for each device's software.

What Are the Regulatory and Compliance Considerations for Middleware Platforms?

Middleware that processes clinical data is not exempt from regulatory scrutiny. According to Innolitics, medical device software regulations carry specific obligations depending on the intended use and risk classification of the software.

Separately, Censinet's FDA vendor compliance framework highlights that third-party risk management, including the use of Software Bills of Materials (SBOMs), secure development practices, and documented corrective action plans, is now a baseline expectation for platforms connected to medical devices.

For labs evaluating middleware, the compliance checklist should include:

  • Is the platform validated for clinical use in your jurisdiction?

  • Does the vendor maintain a documented software development lifecycle?

  • How are vulnerabilities disclosed and patched?

  • Does the platform support audit trails required for accreditation standards such as ISO 15189?

Rezibase addresses this directly through its accreditation module, which covers document management, training records, non-conformance tracking, action plans, audits, and quality control aligned to TSANZ/NATA standards and ISO 15189 requirements.

Does the Research Support Vendor-Neutral Approaches in Digital Health?

A 2019 study published in the Journal of Medical Internet Research by Vandenberk et al. described the development of DHARMA, a vendor-independent mobile health monitoring platform designed to combine data from multiple device sources. The study noted the operational value of building platforms that are not tied to any single manufacturer's data format or connectivity standard. While the context was mobile health monitoring rather than PFT specifically, the architectural principle is directly transferable: manufacturer neutrality improves research utility, data completeness, and long-term platform sustainability.

The 2025 Remote Patient Monitoring Landscape Report by IntuitionLabs further noted that middleware providers capable of pulling data from hundreds of devices are now well-established in the broader health data ecosystem, reflecting growing market acceptance of the vendor-neutral model.

Frequently Asked Questions

What is vendor-agnostic middleware?
Software that connects devices or systems from different manufacturers by translating their data into a common format, without requiring a proprietary connection to any single brand.

Can a vendor-neutral platform handle all PFT device types?
A well-designed platform should handle spirometry, body plethysmography, DLCO, and other modalities regardless of manufacturer, provided the middleware supports the relevant output formats.

Is switching from an existing system to a vendor-neutral platform disruptive?
Data migration from an existing system like Respiro to Rezibase is a straightforward, supported process. Rezibase handles the transition so that lab staff can focus on clinical work rather than IT logistics.

Does vendor-neutral software comply with accreditation standards?
It depends on the platform. Rezibase is specifically built to support ISO 15189 and TSANZ/NATA accreditation requirements.

What happens to historical data when switching platforms?
Historical records are migrated as part of the onboarding process, preserving continuity of the patient record.

Is cloud-based middleware secure for clinical data?
Cloud platforms subject to appropriate security controls and regulatory frameworks are widely used in clinical settings. Rezibase is a cloud-based SaaS solution built for hospital-grade environments, with on-premises deployment available for enterprise requirements.

How long does implementation typically take?
Implementation timelines vary by site complexity, but Rezibase offers a 30-day free trial, giving labs a practical way to evaluate the platform before committing.

About Rezibase

Rezibase is Australia's most advanced cloud-based respiratory and sleep reporting solution, designed by respiratory scientists for respiratory scientists. Trusted by over 35 sites including NHS and NSW Health facilities, Rezibase delivers a fully manufacturer-neutral platform that unifies multi-brand PFT equipment into a single reporting environment, with no vendor lock-in, no local servers, and no lock-in contracts.

Explore Rezibase at rezibase.com or start a 30-day free trial to see how a vendor-neutral platform can simplify your lab's workflow.

References

Remote Credentialing and Supervision in Respiratory Labs: Regulatory Frameworks for Offsite PFT Review and Sign-Off in 2026 ›

Remote Credentialing and Supervision in Respiratory Labs: Regulatory Frameworks for Offsite PFT Review and Sign-Off in 2026 ›