---
type: CaseStudy
title: 'Micro-X: Operator and Passenger Interfaces for Imaging Hardware'
description: How National Digital builds the interfaces on top of Micro-X's imaging hardware - offline-capable operator applications and a guided passenger screening flow.
resource: https://nationaldigital.com.au/case-studies/micro-x/
tags:
  - real-time systems development
  - offline-capable progressive web app
  - medical device interface development
  - operator interface development Australia
  - Medical Devices
timestamp: '2026-07-06T14:41:55.000Z'
language: en-AU
publisher: National Digital
author: Cameron Young
authorRole: CEO
datePublished: '2026-07-06'
dateModified: '2026-07-06'
canonical: https://nationaldigital.com.au/case-studies/micro-x/
---

_Home — Recent Work — Micro-X: Operator and Passenger Interfaces for Imaging Hardware_

# Micro-X: Operator and Passenger Interfaces for Imaging Hardware

*Case study · Medical Devices*

## Interface foundations across three imaging programs

**At a glance**

- Industry: Medical Devices
- Engagement type: Interface engineering
- First release: 2024
- Team: National Digital engineering team

[Platform Engineering](/platform-engineering) · [Digital Product Development](/digital-product-development)

### The challenge

Interfaces for imaging hardware cannot wait on the hardware. Device software, control APIs and physical units are all in development at once, and a front-end team that can only start once a real device exists becomes the critical path. The interfaces also had to serve very different users - an officer operating a screening unit, a clinician running a scanner, and a member of the public self-screening with no training and no instruction.

### What we built

Front-end foundations built against Micro-X's own device contracts rather than against hardware: framework and structure established first, a mock server standing in for the device where needed, and a content-driven screen flow for the passenger journey so the sequence can change without a release. One interface - the screening unit's touch-screen operator application - was built and maintained end to end.

A Nuxt and Vue touch-screen operator application built as an offline-capable progressive web app against Micro-X's system-controller API; a Nuxt 3 passenger self-screening interface where the screen sequence, animation and audio narration are authored as content rather than code; and the base framework plus a mock GraphQL server for a CT operator application, developed against Micro-X's published schema so interface work could begin before hardware was available.

**Workstreams:**
- Touch-screen operator interface built end to end as an offline-capable PWA
- Integration against Micro-X's own system-controller API
- Passenger self-screening flow: layouts, screen progression and vestibule screens
- Content-driven screen sequence with animation and audio narration
- Base framework setup for a CT operator application
- Mock GraphQL server so interface work could start before hardware
- Component test coverage with Jest and Vitest

### The outcome

Micro-X's teams got interfaces running against their own contracts early rather than waiting on hardware, and a foundation their engineers could build on - which is what happened on two of the three programs, where Micro-X developers took the codebase forward after National Digital established it. The screening unit's operator interface has been built and maintained by National Digital throughout.

### Where it went next

The working relationship is as much the deliverable as any one interface: National Digital stands up the front-end foundation and integrates against Micro-X's device contracts, and Micro-X's engineers extend it from there.

**The stack:** Nuxt, Vue, TypeScript, Apollo, GraphQL, PWA, Lottie

_This case study describes real work delivered by National Digital for Micro-X. Selected figures are indicative and rounded._

## Architecture

- **Operator & passenger screens** — Nuxt + Vue interfaces
- **Integration boundary** — Client-owned device contracts
- **Device software & APIs** — Micro-X owned
- **Real-time status** — GraphQL subscriptions
- **Development harness** — Mock server, component tests

- **3** — Micro-X programs interfaced
- **0** — Hardware units needed for interface development
- **100s** — Automated tests
- **Offline** — Interface never needs a network connection

> National Digital have been a pleasure to collaborate with, seamlessly integrating with our product development team. They have a strong ability to understand our requirements and consistently deliver high-quality results.

— Shane Koehne, Project Lead at Micro-X

- Verified review

*Key Takeaways*

## Building the interface when the client owns the instrument

Micro-X owns the imaging hardware and its control APIs; National Digital builds the interfaces on top. Across three programs we established the front-end foundation, and built one screening-unit operator interface end to end.

- **The device software is the client's; the interface boundary is ours.** Micro-X owns the imaging hardware, its control APIs and its schemas. National Digital builds the interfaces that consume them. Being explicit about that boundary is what makes the engagement work - we integrate against a contract we do not control, and we do not pretend otherwise. _Critical_
- **Interface work cannot be gated on hardware availability.** Device software, control APIs and physical units are developed concurrently. Building against the client's published schema through a mock server keeps the front end off the critical path, so a real unit is needed for validation rather than for day-to-day development. _Critical_
- **A public-facing screening flow is data, not code.** Screen sequence, animation and audio narration are authored as content, so the passenger journey can be re-ordered or re-worded without a software release, and tuned from watching real people use it rather than from a specification. _Important_
- **An operator interface in a live environment has to work without a network.** It is built as a progressive web app so the application keeps functioning when connectivity drops. For equipment operating in a live screening lane, an interface that stalls with the network is an operational failure rather than an inconvenience. _Important_
- **Leaving a foundation the client's own team takes over is a legitimate outcome.** On two of the three programs National Digital set up the framework, structure and development harness and Micro-X's engineers built on it. The measure of that work is whether the foundation held up under a team that did not write it. _Helpful_

## Questions decision-makers ask about this build

### Which parts of this did National Digital build?

The interfaces, not the instruments. Micro-X owns the imaging hardware, the device software, and the control APIs and schemas those interfaces talk to. National Digital built the touch-screen operator application for a screening unit end to end, contributed the layouts, screen progression and animation handling for a passenger self-screening interface, and set up the base framework and a mock server for a CT operator application.

### How do you build an interface for hardware that does not exist yet?

Against the contract rather than the device. Micro-X publishes a schema for the system, so interface work runs against a mock server implementing that same schema while physical units are still scarce. The front end stops being the critical path, and a real device is then needed for validation rather than for daily development. It also means the interface is written to the documented contract, not to one machine's quirks.

### What does a content-driven passenger flow mean in practice?

The screen sequence, the animation shown on each screen and the audio narration that accompanies it are authored as content rather than hard-coded. Re-ordering the journey or changing wording becomes a content edit, not a software release. That matters for a public-facing flow that gets tuned from watching real people use it, and narration on every screen means the journey never depends on reading a display.

### Why does an operator interface need to work offline?

Because it runs on equipment in a live operating environment where connectivity is not guaranteed. The touch-screen application is built as a progressive web app so it keeps functioning when the network drops. For a screening unit mid-operation, an interface that stalls with the network is an operational failure rather than an inconvenience, and recovering cleanly matters more than looking polished.

### What happens when the client's team takes the code over?

That is often the intended outcome. On two of the three programs National Digital established the framework, structure and development harness, and Micro-X's own engineers built on top of it from there. The measure of that kind of engagement is whether the foundation held up under a team that did not write it, which is a different question from how much of the final commit history is ours.

### How do you integrate against an API you do not own?

Against the published contract rather than the running system. Micro-X's schema defines synchronous control through queries and mutations and asynchronous status through subscriptions, and the interface is written to that document rather than to observed behaviour. Where the contract carries a version, a client can check compatibility before connecting instead of discovering a mismatch at runtime.

## More client work

- [NRMA Parks & Resorts: WordPress to Contentful Migration](/case-studies/nrma-parks-and-resorts/) — Tourism & Hospitality
- [Luxico & Staylonger: One Property Management Platform](/case-studies/luxico/) — Property Management & Short Stays

*What's next*

## Building an interface on someone else's hardware?

National Digital builds the interfaces on top of Micro-X's imaging hardware, integrating against contracts the client owns. If you're solving something similar, see our work on [system integration](/platform-engineering/system-integration), [GraphQL implementation](/platform-engineering/api-development-and-management/graphql-implementation) and [custom web applications](/digital-product-development/custom-web-applications).

## Want a platform like this for your business?

Tell us what you're building. We'll come back within one business day with what we'd do first and what it would take.

- [Book a call](https://calendly.com/cameron-at-national-digital/discovery)
- Email: enquiries@nationaldigital.com.au
- Phone: 1300 800 855

## Related

**Parent:**
- [Real platforms, in production.](/okf/case-studies.md)

**Related:**
- [NRMA Parks & Resorts: WordPress to Contentful Migration](/okf/case-studies/nrma-parks-and-resorts.md)
- [Luxico & Staylonger: One Property Management Platform](/okf/case-studies/luxico.md)
- [MyStrengths: Student Assessment Platform](/okf/case-studies/mystrengths.md)
- [Gratofy: Custom E-commerce Marketplace](/okf/case-studies/gratofy.md)
- [Booking systems built around your operation.](/okf/booking-systems.md)
- [Custom software, built by senior engineers.](/okf/custom-software.md)
- [AI that survives contact with production.](/okf/ai-automation-services.md)
- [how2vote.au: A Provably Neutral Voting Tool](/okf/case-studies/how2vote.md)
- [Surgery Waits: Comparable Hospital Waiting Times](/okf/case-studies/surgery-waits.md)
- [Public Trails: Lawful Access, Computed from Official Records](/okf/case-studies/public-trails.md)
- [FreeCamps: Where You Can Lawfully Stay, Traced to the Source](/okf/case-studies/freecamps.md)
- [publicdata.au: Versioned Government Open Data, Ready for AI Agents](/okf/case-studies/publicdata.md)
- [AI Visibility Management](/okf/services/ai-visibility-management.md)