← BACK TO ALL WORK{ KAIZEN LABS } CASE STUDY
HealthcareFEASIBILITY BUILD

One data layer for seven devices that refuse to talk

CLIENT: Commissioned by a healthcare OEM, anonymised

An interoperability layer that connected seven screening and diagnostic devices, each locked to its own vendor app, into a single application and one data model.

Lab dashboard in technician mode: today's screening queue listing each session's tests and the device performing them, a connected-devices panel showing each instrument's transport and sync state, and pending reports. All displayed data is placeholder content.
// overview

A health-check station runs several devices from several manufacturers, and each one arrives with its own mobile app and its own idea of what a result looks like. The operator ends up switching between apps to run one screening, and the results never sit together in a single record. The hard part was never the dashboard; it was that nothing in the room spoke a shared language.

We built the bridge: an adapter per device, handling Bluetooth, Wi-Fi or the vendor's own SDK behind one interface, feeding a normalisation step that maps every vendor payload into one common schema. Above it sits an operator application in lab-technician mode: a searchable catalogue of the tests each connected device can run, device management, lab data, and a screening flow that assembles the selected tests into a single session.

// specs
Device classes
Cancer screening scanners, refractometer, spirometer, ECG and vitals monitoring
Connectivity
Bluetooth/BLE, Wi-Fi and vendor SDKs, depending on the device
Normalisation
Vendor-specific outputs mapped to one common schema
Operator surface
Lab-technician mode: test catalogue, device management, lab data, screening session
// what it does
01

Device adapters handling Bluetooth, Wi-Fi and vendor SDK transports behind one interface

02

Vendor-specific payloads normalised into a single common data schema

03

A unified patient-level view in place of one app per device

04

Test catalogue searchable and filterable by clinical category, each test tagged with the device that performs it

05

Required tests marked and gathered into a single screening session

06

Adapter pattern: a new device is a new adapter, not a new application

// how it runs
DEVICE → ADAPTER → COMMON SCHEMA → SESSION
  1. Devices
  2. Per-device adapters
  3. Normalisation
  4. Data layer
  5. Technician app
// how we worked
01 / Diagnose

Catalogued what each device actually emits and how it expects to be talked to, before assuming any of them could be treated the same way.

02 / Ship

One adapter per device against a single normalisation layer, with a technician-facing application proving the whole path end to end.

03 / Scale

The adapter boundary is the point: adding a device is an adapter, not a rewrite.

Got instruments that each need their own app?

Bring the workflow and the number it affects. A reply within one business day.

Book a pilotSee other work
// end of case study · One data layer for seven devices that refuse to talk