What the device actually does, reconstructed from the device itself.
IrisMed is IRIS configured for medical device software. It builds an accurate, reusable model of a legacy device system from its own source and records — then turns that model into the FMEA, specifications, standards-gap analysis and traceability your quality organisation has to produce anyway. Deployed inside your environment, with our engineers working alongside yours until the output is one your own team will sign.
The engineering survived. The reasoning behind it did not.
Devices designed decades ago are still in service and still being changed. The engineers who made the original decisions have moved on. The silicon underneath has turned over across vendor generations, each substitution carrying assumptions nobody recorded. And when a field issue surfaces, the answer has to be documented, defensible and fast.
The constraint is almost never the engineering. It is that the reasoning behind the design was never captured in a form anyone can file — so every question becomes an archaeology project before it can become an answer.
Two layers. Context first, because evidence is only as good as the context behind it.
An accurate model of the system, kept and reused
Understanding device code requires context, and context that is wrong is worse than none. IrisMed generates that context from the existing code and whatever information you supply, then works with your engineers to correct and deepen it. The result is stored securely as your asset, and reused on every question that follows rather than rebuilt each time.
The artefacts your quality system has to produce
With the context established, IrisMed generates FMEA analysis, specifications, adherence-and-gap analysis against the standards you are held to, and traceability across the set. Every output cites where in the source it came from, so a reviewer can follow the claim back rather than take it on trust.
Tooling, method, and people who stay
IrisMed is delivered as an engagement, not a download. We bring the supporting tools, deploy them under a method built for device software, and stay alongside your systems engineers until the value is realised and your team can carry it without us.
Six dimensions, built once and reused.
Application architecture
How the system is actually assembled, as built rather than as designed.
Organisational context
Who owns what, and the conventions a team applied that no specification records.
Domain
The clinical and engineering domain the device operates in, and the vocabulary its code uses for it.
Code organisation
How the source is structured, where responsibility sits, and which boundaries are real.
Dataflow
What moves through the system, in what order, and what transforms it on the way.
Critical system events
The events the device's safety and behaviour depend on — the ones a reviewer will ask about first.
Output that goes into the record, not into a report nobody files.
Failure modes and effects
Generated from the system as it is, with severity, occurrence and detection scored and the source of each entry cited.
What the system does, written down
Behaviour recovered from the implementation and stated in the form your process expects.
Adherence to standards
Where the system meets the standards you are held to and where it does not — named, located and evidenced.
The thread between them
Requirement to design to implementation to risk, linked, so a change can be followed through the whole set.
IrisMed is the medical device configuration of IRIS.
IRIS is the underlying platform: it reads code and records, captures what experts know, and produces evidence that cites its sources. IrisMed is that platform built out for device software specifically — the context model, the standards set, the artefact formats and the delivery method are all shaped for regulated medical devices rather than for enterprise systems generally.
If you are looking at enterprise applications, ERP estates or a carve-out rather than device software, IRIS is the page you want.
Bring one device. We will show you what comes back.
Thirty minutes to understand the system and the obligation attached to it. If there is a fit, we start with a scoped proof of concept on a device you name — in your environment, with the output assigned to you.