How Much of Your Own System Do You Hold? Four Measures, Now and Where They Should Be.

The auditor has a simple question. How does the billing system decide what to charge when an insured stay runs beyond the approved number of days?

The finance head does not know. The technology head does not know either. The system was built by a supplier nine years ago, and the supplier still hosts it and changes it. The answer given to the auditor is the one always given. We will ask the supplier.

The reply comes a week later, in two sentences. Nobody at the hospital can check whether they are right.

What We Found

We looked at what the public record says about the suppliers behind health organisations’ systems, and at what it says about what their customers hold.

Before the findings, the limit that runs through this whole issue. Holding your own record of a system does not keep a supplier’s servers running. We cannot stop a supplier failing, we provide no fallback, and we make no arrangement with your suppliers. A record changes what you can do, and whom you have to ask.

Suppliers carry their own old systems. According to a trade-press article written by a technology vendor’s executive, a large US supplier of health record systems said that an attacker had used compromised login details to reach old servers that had not yet been migrated, and had taken data from them. The article gives no year and no figure for the effect. A hospital that depends on a supplier depends on that supplier’s old systems too, and cannot see into them.

When a supplier stops, its customers stop. In a recent case, ransomware hit a supplier of pathology services to hospitals in one European capital, and the hospitals it served had to cancel surgery and clinic appointments on a large scale, according to a trade journal’s report. The report does not tie the attack to old technology, and says it was not possible to determine how the attackers got in.

What nobody measures. We found no figure, in healthcare or elsewhere, for how much of a supplier-built system its customers hold in writing, how often a hospital can get a second quote for a change, or how many of its connections to suppliers it has listed. We found no public case in healthcare of a supplier holding back code or knowledge, and we claim none. In our reading, that silence in the measures is itself the problem: an organisation cannot reduce a dependence it has never counted.

What Holding Your Own Record Opens Up

A supplier that built and runs a hospital’s system usually holds the only description of it. Our reading is that writing that description down on the hospital’s side changes three things.

• Questions are answered in-house. An auditor’s question about how a charge is worked out is answered from the hospital’s own document, and can be checked against the system.
• A second quote becomes possible. Another firm can price a change to a system that has been described, subject to the hospital’s own contract with its present supplier.
• Leaving becomes a decision. The cost of moving the connecting part, or the whole system, can be set beside the cost of staying.

This is our reading. It is not a measured market figure.

Three Ways to Hold a Record of a System a Supplier Built, Weighed

Option	When it fits	What it risks
Ask the supplier for documentation	The contract provides for it, and the supplier is willing	The description is written by the party the hospital depends on. Nobody on the hospital’s side can check it against the system
Ask the hospital’s own staff to write down what they know	The system is small and its users know it well	Staff write what they see on the screen. The rules underneath, the overnight jobs and the connections are missed
Have the system read from its code and written down, with the hospital’s own experts confirming each part, on read-only access to the code that the hospital arranges with its supplier, as its contract allows (that step is the hospital’s)	The system is used every day, the supplier built it, and the hospital wants a description it can check and keep	It costs money before anything changes. The supplier may not welcome the exercise. Some contracts restrict access or what may be shown to a third party, which is a question for the hospital’s legal adviser first. And the record goes stale unless someone keeps it

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the assessment starts, and fill in as it goes.

Measure	Typical starting point	Where it should be	How it is checked
Share of outside connections listed, each with an owner and what stops if that supplier stops	None; one line for “third parties”	Every connection from your own applications	The map and the risk register
Connections that can be pointed to a second route without rewriting the rest of the application	None	Every one the board decides not to carry	Signed acceptance for each rebuilt module, and its traceability matrix
Share of a supplier-built system’s behaviour in a specification that is yours, confirmed by your own experts	None; the supplier holds it	Every part in use	The specification, and who confirmed each part
Whether a second supplier could quote a change from that specification	No; only the present supplier can	Yes, subject to your own contract with your present supplier	A change described from the specification alone, without asking the present supplier

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a healthcare organisation.

A small part of a filled-in benchmark might look like this.

Supplier and connection	Listed, with owner and what stops	Could be pointed to a second route	In a specification that is the hospital’s
Outside laboratory: orders and results	Yes, owned by the laboratory head	Yes: stage 1, accepted	Yes, confirmed by the laboratory head
Billing system built by a supplier	Yes, owned by the finance head	Not chosen by the board; carried knowingly	Yes, confirmed by the finance and billing heads
Claims route to insurers	Yes, owned by the revenue head	Not yet decided	Drafted; waiting for review

The rows above are an illustration, not taken from a real hospital.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the systems your suppliers built or connect to, and the questions you can only answer by asking them. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
3. We read the system and propose: the Legacy System Specification Assessment. Where a supplier built the system, you arrange read-only access to its code with that supplier, as your contract allows; that step is yours, and we do not obtain code from a supplier. It produces a map of the system as it stands and of what it connects to, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the part that connects to a supplier, and a staged plan with a fixed quote. It also lists which accounts, domains, licences and keys are held in whose name. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. The specification is yours, and you can show it to other suppliers, subject to your own contract with your present supplier.
4. If you approve, we build. We rebuild only the part of your own application that connects to a supplier, as one module, while the old application keeps running, so that it can be pointed to a second supplier or another route if you arrange one. We never do a single cutover. A traceability matrix links each old function of that part to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module. Where the module touches clinical work, accepting it is your clinicians’ decision.
5. We review against the benchmark. Before work starts we set the benchmark above. As each part is delivered and accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price, and limits. Your supplier may not welcome the exercise. What your contract lets you show us, or another supplier, is a question for your own legal adviser before it is one for us; we give no legal advice on contracts or on who owns code or data. The record goes out of date unless someone on your side keeps it when the supplier makes a change. And it does not make the supplier’s system any more reliable: if their servers stop, yours stop, record or no record. We do not work on packaged health record products or on a supplier’s own systems.

At the end you hold the map, the specification, the risk register, the traceability matrix for any part we rebuilt, and a benchmark in which every measure shows where it started and where it stands.

What changes for the business:

Role	What they gain
CEO	The organisation is no longer the one party that cannot explain its own system.
CTO or CIO	A specification that is the organisation’s, which makes a second opinion or a second supplier possible.
CFO	Quotes for changes can be compared, because the specification can go to another supplier, subject to the organisation’s own contract with its present supplier.
COO	Questions about how the system behaves are answered in-house, without waiting for the supplier.
Risk and compliance	Something in the organisation’s own hands to show when asked how it oversees its supplier.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A large US supplier of health record systems said an attacker had reached old servers that were waiting to be moved.	Our part is narrower than this case. We do not assess a supplier, and we do not work on packaged health record products or on a supplier’s systems. For an organisation that relies on a supplier, we write a specification of the system built for it, which the organisation holds.
Ransomware hit a supplier of pathology services to hospitals in one European capital, and the hospitals it served had to cancel surgery and clinic appointments.	Our part is much narrower than this case. We cannot stop a supplier failing, and we provide no fallback. We set and fill in the benchmark of what the organisation holds and what depends on each supplier.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We count what you hold of your own system first, so you can see the dependence fall.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →