Skip to main content
Contact us
National Digital home
Book a callContact us

1300 800 855enquiries@nationaldigital.com.au

Having trouble? Open the scheduler in a new tab

Case study · Medical Devices

Interface foundations across three imaging programs

Micro-X's imaging hardware runs operator and passenger interfaces that National Digital built against device contracts Micro-X owns.

Last updated

At a glance

Industry
Medical Devices
Client size
94 employees
Engagement type
Interface engineering
First release
2024
Team
National Digital engineering team

✓ Verified Review

“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

Micro-X by the numbers

  • Operator and passenger

    Interfaces National Digital built

  • None

    Hardware units needed for interface development

  • Device-free

    Component tests run without a device

  • Offline

    Interface never needs a network connection

The Micro-X Baggage Scanner product page, showing the scanner with its touch-screen Welcome screen.

About the client

Micro-X is an ASX-listed Australian company that develops medical imaging products, along with selected security applications, using its own cold cathode carbon nanotube X-ray emitters. Electronic control of the emitters makes its X-ray products smaller, lighter and lower in power use. Micro-X designs and builds its products in Adelaide and has a technical and commercial team in Seattle for its US business.

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 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

National Digital built front-end foundations against Micro-X's own device contracts so the work did not depend on hardware. The framework and structure came first, and a mock server stood in for the device where needed. The passenger journey used a content-driven screen flow so the sequence could change without a release. National Digital built the screening unit's touch-screen operator application end to end.

  • 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

What we built in each area

  • Staff tools

    A touch-screen operator application for the screening unit was built end to end as an offline-capable progressive web app.

    • Nuxt
    • Vue
    • TypeScript
    • PWA

  • Apps & workflows

    The front-end foundations follow Micro-X's own system-controller API, and the device software and APIs are Micro-X owned. A mock GraphQL server stood in for the device so interface work could start before hardware was available, and the passenger screen flow carries its animation as content.

    • GraphQL
    • Apollo
    • Lottie

The outcome

Micro-X's teams had interfaces running against their own contracts before hardware was available. On two of the three programs, Micro-X developers took the codebase forward after National Digital established it. National Digital built the screening unit's operator interface and maintained it for the duration of the engagement.

Where it went next

National Digital set up the front-end foundations and integrated them against Micro-X's device contracts, and Micro-X's engineers extended them. A team whose hardware is still in development can split the work the same way.

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

Key Takeaways

Building the interface when the client owns the instrument

  • The device software is the client's; the interface boundary is ours.Critical

    Micro-X owns the imaging hardware, its control APIs and its schemas. National Digital built the interfaces that consume them. National Digital stated that boundary explicitly at the start and integrated against a contract it did not control.

  • Interface work cannot be gated on hardware availability.Critical

    Device software, control APIs and physical units are developed concurrently. National Digital built against the client's published schema through a mock server, so interface work started before a unit was available for the team to use.

  • The passenger screening flow is authored as content.Important

    Because the screen sequence, animation and audio narration are content, the passenger journey can be re-ordered or re-worded without a software release. The journey can then be tuned from observing real people as they use it.

  • An operator interface in a live environment has to work without a network.Important

    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 when the network drops is an operational failure.

  • Leaving a foundation the client's own team takes over is a legitimate outcome.Helpful

    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 test of that work was whether Micro-X's engineers could extend a foundation they did not write.

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

What did Micro-X need?

Micro-X needed interfaces for imaging hardware that did not wait on the hardware. Device software, control APIs and physical units were all in development at once, and the interfaces had to serve an officer operating a screening unit, a clinician running a scanner and a member of the public self-screening without training.

What did National Digital build for Micro-X?

National Digital built front-end foundations against Micro-X device contracts across three programs, with a mock server standing in for the device where needed. On one program it built the screening unit touch-screen operator application end to end, as an offline-capable progressive web app.

When did the Micro-X work first release?

The study records the first release as 2024 and classes the work as interface engineering. It does not state how long each program took.

What did Micro-X keep after the engagement?

Micro-X owns its device software and control APIs, and National Digital built against them. On two of the three programs, Micro-X developers took the codebase forward after the foundation was established, and National Digital maintained the operator interface for the duration of the engagement.

Questions decision-makers ask about this build

Which parts of this did National Digital build?

National Digital built the interfaces. 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?

The interface is built against the device contract. 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. Developers build and test screens against the mock server for day-to-day work. A real device is then needed only to validate the finished interface against the hardware it will run on.

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 and kept out of the application code. Re-ordering the journey or changing wording is a content edit and needs no software release. Narration accompanies every screen, so a member of the public with no training does not have to read a display to complete the journey.

Why does an operator interface need to work offline?

The application runs on equipment in a live operating environment where connectivity is not guaranteed. National Digital built the touch-screen application as a progressive web app so it keeps functioning when the network drops. A screening unit can be mid-operation when that happens, so the interface has to keep the operator working through the outage and recover cleanly when the connection returns.

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

A handover to the client's team 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 final commit history on those programs is therefore mostly Micro-X's, and this case study claims only the foundational work National Digital did.

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

National Digital wrote the interface to the published contract. Micro-X's schema defines synchronous control through queries and mutations and asynchronous status through subscriptions, and the interface code follows that document. Where the contract carries a version, a client can check compatibility before it connects, so a version mismatch shows up before runtime.

More client work

What's next

Building an interface on someone else's hardware?

National Digital built 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, GraphQL implementation and custom web applications.

References

Who stands behind this page

Registered business
General Consulting Services Pty Ltd as trustee for the Australian Business Trust, trading as National Digital. ABN 13 744 838 758.
In business
National Digital has shipped production platforms since 2016. About National Digital
Google reviews
National Digital has 14 Google reviews with an average rating of 5.0 out of 5, read on 2 November 2026. How the figures are counted National Digital on Google Maps

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

or enquiries@nationaldigital.com.au1300 800 855