Before connecting any new clinical system to your respiratory lab, you need a clear picture of what already exists. An integration topology audit is the process of documenting every data flow, interface, and system dependency in your lab's current environment. For respiratory labs specifically, this means understanding how patient data moves between your spirometry devices, reporting software, Patient Administration System (PAS), Electronic Medical Record (EMR), and any downstream clinical consumers. Without this map, adding a new system creates unpredictable risk. With it, integration becomes a controlled, low-risk process.

TL;DR

• An integration topology audit documents all existing data flows before any new system is introduced.

• Respiratory labs have unique integration complexity due to device diversity, specialist data types, and multi-directional data exchange.

• The audit should cover five layers: systems, interfaces, data types, ownership, and failure points.

• Healthcare data integration is a known challenge across the industry, but structured frameworks make it manageable.

• Platforms like Rezibase are built to slot into existing hospital topologies with minimal disruption, supporting connections to PAS, EMR, DICOM, and finance systems.

What Is an Integration Topology Audit and Why Does It Matter for Respiratory Labs?

An integration topology audit is a structured review of every system, data connection, and information exchange point in a clinical environment. It produces a living map showing where data originates, how it travels, and where it lands.

Respiratory labs are not simple environments. A single patient encounter can generate data from multiple devices (spirometers, body plethysmographs, sleep study equipment), require normal value lookups, feed into a reporting system, and ultimately need to reach a referring physician via an EMR. According to guidance on healthcare data integration from Pi Tech, unifying patient information across systems requires understanding existing workflows before layering new technology on top. Skipping the audit phase is one of the most common reasons integration projects stall or fail.

The audit matters because:

• It prevents duplicate integration work (discovering an interface already exists).

• It identifies fragile or undocumented connections that could break when a new system is introduced.

• It surfaces data quality problems before they propagate into a new platform.

• It gives your IT and clinical teams a shared language for discussing the environment.

What Are the Five Layers of a Respiratory Lab Integration Topology?

A useful audit framework organizes the environment into five distinct layers:

Working through these five layers systematically ensures nothing is assumed or overlooked.

How Do You Actually Conduct the Audit? A Step-by-Step Approach

Step 1: Inventory every system in scope

Start with a simple spreadsheet. List every system that touches patient data in your respiratory lab, including devices that export files manually. Do not assume anything is out of scope.

Step 2: Interview the people who actually use the systems

Formal system documentation is often outdated. The scientists and admin staff who work in the lab daily know where the workarounds are, where data gets re-keyed manually, and which connections are unreliable. These conversations surface the real topology, not the theoretical one.

Step 3: Trace each data type from origin to destination

For each data type (patient demographics, test orders, results, reports), map the full journey. Ask: Where does this data first enter the system? How does it move? Where does it end up? Who consumes it?

Step 4: Identify and label all interfaces

For each connection between systems, document the protocol (HL7, DICOM, API, file transfer), the direction of data flow, the frequency, and who owns the interface. Flag any connections that are undocumented or maintained informally.

Step 5: Assess and prioritize failure points

Not all risks are equal. Prioritize failure points by their clinical impact. Manual re-keying of patient demographics, for example, carries higher clinical risk than a delayed billing file export. Implementation science frameworks used in respiratory care settings emphasize that understanding existing workflows is a prerequisite for any successful change, as noted in resources from the Pulmonary Diagnostic Laboratory Resource Center.

Step 6: Validate with IT and vendor representatives

Cross-check your map against what IT and current vendors have on record. Discrepancies are common and important to resolve before any new system is introduced.

What Are the Most Common Integration Gaps Found in Respiratory Labs?

Based on common patterns in clinical physiology environments, the most frequently discovered gaps include:

• Manual demographic entry: Patient details typed directly into reporting software rather than received from PAS, creating risk of mismatch.

• Orphaned device exports: Spirometry or sleep study devices writing data to local folders with no automated ingestion path.

• One-way result delivery: Results sent to EMR but no electronic orders received back, meaning staff must check two systems for requests.

• Undocumented middleware: A legacy integration engine running in the background that no current staff member fully understands.

• No structured data for key results: Reports delivered as PDFs only, with no discrete data values available for clinical analytics or population health reporting.

Research published in PLOS ONE on patient-specific respiratory drug deposition modelling highlights how granular, structured clinical data enables meaningful patient-level analysis. Labs that deliver only unstructured PDF reports are effectively locking that analytical potential away.

How Does This Audit Change When You Are Switching Reporting Systems?

When a lab is moving from one reporting platform to another (for example, transitioning from a legacy system like Respiro to a modern platform like Rezibase), the integration topology audit becomes even more valuable. It answers a critical question: which interfaces need to be rebuilt, which can be reused, and which should be improved as part of the transition?

The good news is that modern, vendor-neutral platforms are designed to connect to standard hospital infrastructure without requiring a rebuild from scratch. Rezibase, for example, supports integration with PAS, EMR, DICOM Modality Worklists, electronic ordering systems, and hospital finance systems as part of its standard offering. The data migration process is straightforward: existing patient records and historical results are brought across cleanly, and the new integration points are configured against the topology map you have already built.

The audit also protects the migration itself. Knowing exactly what data exists, where it lives, and how it is structured means there are no surprises during the transition.

Frequently Asked Questions

How long does an integration topology audit take?
For a typical respiratory lab, a thorough audit takes two to four weeks, depending on the number of systems in scope and the availability of IT and clinical staff for interviews.

Do we need external consultants to run the audit?
Not necessarily. Many labs can conduct the audit internally using a structured framework. External support is useful when legacy systems are poorly documented or when the lab lacks dedicated IT resource.

What if we discover undocumented interfaces during the audit?
Document them immediately and assign an owner. Undocumented interfaces are common and not unusual to find. The goal is to bring them into the formal topology so they can be managed properly.

Does the audit need to be repeated?
Yes. Integration topology maps become outdated as systems change. A lightweight review should be conducted annually and a full audit before any major system addition or replacement.

How does Rezibase support labs with complex existing topologies?
Rezibase is designed as a vendor-neutral, cloud-based platform with broad integration support. Its team works with labs to configure connections to existing hospital systems, meaning the platform adapts to your environment rather than requiring you to rebuild around it.

What happens to historical data when switching reporting platforms?
Historical data migration is a standard part of any platform transition. Rezibase supports structured data migration so that existing patient records and test results are carried across intact.

Is the audit relevant for smaller private respiratory clinics?
Yes, though the scope is smaller. Even a two-system environment benefits from a documented topology, particularly when considering future growth or accreditation requirements.

About Rezibase

Rezibase is Australia's most advanced cloud-based respiratory and sleep reporting platform, built by respiratory scientists for respiratory labs. Trusted by over 35 sites including NHS hospitals in the UK and NSW Health facilities in Australia, Rezibase offers vendor-neutral integrations, AI-assisted reporting, and a comprehensive accreditation module, all delivered without lock-in contracts. Learn more at rezibase.com.

References

• Pi Tech. Healthcare Data Integration Guide: Best Practices for 2025. https://pi.tech/blog/healthcare-data-integration-guide

• Williams, J. et al. Validated respiratory drug deposition predictions from 2D and 3D imaging. PLOS ONE. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0297437

• Pulmonary Diagnostic Laboratory Resource Center. Implementation Science: A Primer of Key Concepts for the Respiratory Care Practitioner. https://pftlabresources.com/implementation-science-a-primer-of-key-concepts-for-the-respiratory-care-practitioner/