Why the device is the centre of everything

Every piece of operational software makes a structural decision early on that shapes everything that follows. Not a feature decision — a more fundamental one. A decision about what the primary object is. What sits at the centre of the data model and has everything else orbit around it.

In most field service software, that object is the job. In most contract management software, it is the contract. In most CRM-adjacent tools that have wandered into the service space, it is the customer.

In Mediora, it is the device.

This is not a minor implementation detail. It is the decision that determines what the software is actually good at, what it makes easy, what it makes harder than it needs to be, and whether it reflects the reality of how healthcare equipment service teams actually think about their work. We made this call early and deliberately, and it has been the right call, and it is worth explaining why.

How service teams actually think

Ask a field technician what they're working on and they will tell you about a machine. Not a job number. Not a contract. Not a customer account. A machine — a specific GE Signa at St. Mark's that has been running hot on the left gradient coil since the firmware update in September. A Philips Ingenia that one of the senior techs rebuilt from the ground up three years ago and which, partly as a result, runs better now than it did when it was new.

The device is the unit of meaning. Every other piece of information — service history, warranty status, parts replaced, fault patterns, contract terms, responsible technician, preferred service window — derives its significance from its relationship to a specific piece of equipment. A job that isn't attached to a device is an abstraction. A contract without the equipment it covers is a document. The device is what makes everything else concrete.

This is true at every level of the organisation. The operations manager thinking about fleet health is thinking about which machines are at risk. The service coordinator scheduling a week's visits is thinking about which machines need attention and when. The technician standing in a hospital corridor before a call is thinking about which machine they're about to open and what they already know about it.

If the software doesn't start from the same place, there is a translation cost every time someone uses it. They have to map their mental model — device-first — onto a data structure that thinks differently. That cost is small per instance and significant across thousands of daily interactions.

What the device record contains

The Mediora device record is the closest thing we have to a complete truth about a piece of equipment. Everything connected to that device lives there, accessible from a single screen, without navigation.

Full service history — every job ever logged against this machine, with notes, outcomes, and the technician who did the work. Open and resolved faults. Parts replaced and parts on order. Contract status, renewal date, coverage terms. The hospital it lives in and the contact there who manages service access. Any known issues flagged by the manufacturer. The service windows that this site prefers. Upcoming scheduled maintenance.

None of this is novel information. Every organisation that manages a service fleet has it somewhere. The difference is the somewhere. In most operational environments, this information is distributed across at least three systems and two people. Reassembling it — for a technician arriving at a new site, for a manager preparing for an audit, for a coordinator answering a hospital's question about their equipment — takes time and introduces error.

In Mediora, it takes one tap.

What becomes possible when the device is central

The structural decision to put the device at the centre is not just an organisational convenience. It enables things that are genuinely difficult to do when the data model is organised differently.

Predictive service becomes possible

When every piece of service history lives on the device record, patterns emerge that don't exist when the data is fragmented. A machine that has had three fault logs of the same type in eighteen months tells a story that a job-centric system doesn't surface — because the jobs were separate records, logged at different times, with no structural connection to each other. A device-centric system surfaces that pattern automatically. The same data, organised differently, produces different insight.

Knowledge stops leaving when people do

One of the most persistent and underacknowledged risks in service operations is tacit knowledge loss. The senior technician who has serviced a particular machine twelve times carries a model of that machine's behaviour that no formal system captures — until the device record exists as a place to put it. Field notes, historical context, known quirks — when these attach to the device rather than the job, they accumulate into something that survives the departure of the person who wrote them.

Onboarding a new site becomes fast

When a new hospital joins a service contract, the work of onboarding their equipment to the system is the work of creating device records. Once those records exist — populated with the existing service history, however patchy — the entire operational layer is immediately functional. The technician who attends the first call has context. The coordinator who schedules it has visibility. The manager who reviews it has a baseline.

This sounds obvious. It is only obvious when the device is the primary object. In a job-centric system, there is no natural place to put pre-existing context. The history starts at the first logged job, and everything before it is dark.

The objection we hear most often

The common pushback on a device-centric model is that not all service operations are device-centric. Some teams are primarily organised around customers — the hospital is the client, the equipment is secondary. Some are organised around contracts — the service agreement is the unit that drives scheduling and billing.

This is true, and the objection is fair.

Our response is not that the customer and the contract don't matter. They do, and they exist as first-class objects in Mediora with their own records and their own views. The response is that even in customer-centric or contract-centric organisations, the moment of service is device-centric. The technician is standing in front of a machine, not a contract. The question they need answered is about this specific piece of equipment, not about the account it belongs to.

The customer record and the contract record are important for management and administration. The device record is important for work. Building the system around the work — and linking everything else to it — is the design decision that makes the software useful to the people who use it most.

A note on what this cost us

Making the device the primary object had a price, and we should be honest about it.

It made certain reporting structures harder to build. Customer-level reporting — how are all the devices at this hospital performing? — requires aggregating up from individual device records rather than reading directly from a customer object. That aggregation is straightforward technically, but it was additional work, and it pushed some customer-centric features later in the roadmap than they might otherwise have been.

It also made the initial data model harder to explain. "What's the primary record type?" is a question that comes up early in every sales conversation, and "the device" requires more unpacking than "the customer" or "the job" — both of which map more directly to how buyers tend to think about operational software.

We made the trade. The software is more useful to the people doing the work, at the cost of being slightly harder to explain to the people buying it. We think that is the right trade. We are aware that not everyone agrees.