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.

  • Nuxt
  • Vue
  • TypeScript
  • Apollo
  • GraphQL
  • PWA
  • Lottie
✓ 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

3

Micro-X programs interfaced

0

Hardware units needed for interface development

100s

Automated tests

Offline

Interface never needs a network connection

At a glance

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

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

The stack

National Digital built a Nuxt and Vue touch-screen operator application as an offline-capable progressive web app against Micro-X's system-controller API. It contributed to a Nuxt 3 passenger self-screening interface in which the screen sequence, animation and audio narration are authored as content. For a CT operator application, it set up the base framework and a mock GraphQL server against Micro-X's published schema, so interface work could begin before hardware was available.

Operator & passenger screensNuxt + Vue interfaces

Integration boundaryClient-owned device contracts

Device software & APIsMicro-X owned

Real-time statusGraphQL subscriptions

Development harnessMock server, component tests

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.

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.

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.

or enquiries@nationaldigital.com.au1300 800 855