Case study · Medical Devices

Interface foundations across three imaging programs

  • 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

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.

  • 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

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.

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

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

  • Interface work cannot be gated on hardware availability.Critical

    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.

  • A public-facing screening flow is data, not code.Important

    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.

  • 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 with the network is an operational failure rather than an inconvenience.

  • 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 measure of that work is whether the foundation held up under a team that did not write it.

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.

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

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