Imaging manufacturers that ship platform releases on schedule and through the audit.

CT, MR, X-ray, ultrasound and PET systems, and the reading and post processing software around them, run on large software platforms. The release date is fixed, and the scope keeps changing while the release is under way. We add engineers where the bottleneck is, in development, in verification or in the documentation, so the planned features have the engineers they need, inside your IEC 62304 lifecycle and quality system, for the EU MDR and the FDA.

Book a 30 minute call Write to us

Systems: Modalities · reading software · PACS
Standards: IEC 62304 · ISO 13485 · EU MDR · FDA
First step: Free 30 minute call with engineering

The software path

How a platform change reaches the field.

Requirement

The release date is fixed, the scope grows, and DICOM (the standard for medical images and their exchange) updates and field defects wait for the same engineers.

ImprovementOur engineers join where the bottleneck is, in development, verification or documentation, and work to your release plan.

Design

Design decisions in a large platform are written down after the code, and the link to the requirement is added shortly before the audit.

ImprovementThe design is written and linked to its requirement and risk assessment in your tools before the code.

Implementation

New engineers need months before they can change the platform safely.

ImprovementOur engineers start with a small work package under your review, so you judge their code before the team grows.

Verification

Tests are written and run late, so verification is behind development before every audit.

ImprovementAutomated regression runs with every change, so verification keeps pace with development.

Release

Manual build and test steps hold up each release.

ImprovementAn automated build and test chain runs these steps for every release.

Field support

Root cause analysis of field defects takes engineers away from planned work.

ImprovementOur engineers take over the root cause analysis, and each fix comes with a regression test.

Change

After a change, gaps in traceability turn into audit findings.

ImprovementEach change gets a documented assessment of whether the notified body has to be told or a new FDA submission is needed, and traceability from requirement to release is updated with it, so the file is complete before the audit.

The goal

A platform released to plan, with a file ready for the audit.

For the manufacturer

Releases to plan with a complete verification record
One chain from requirement to test result for the auditor to read
The same engineers on the platform from one release to the next

For the clinicians who use the device

A platform that behaves the same after an update
New DICOM editions and supplements that work with the systems installed on site
Field defects fixed with a regression test

For patients

Faster and safer examinations, because new features reach the scanner sooner
Defects fixed and out in the field quickly
Images and results they can trust after every update

Problems and solutions

What we hear, and what we do about it.

The release date or the scope is fixed, and the platform team is already full.

Our engineers join where the bottleneck is, in development, verification or documentation, and work in your lifecycle and review workflow. Every change is recorded with its requirement and risk assessment. When the scope grows, the team grows by another work package.

Team extension

Verification falls behind development before every audit.

We take over test automation and the build and release chain, so verification runs with every change. Traceability from requirement to release is kept in the record.

QA, compliance and regulatory support

A research algorithm works on a workstation, and hospitals cannot use it.

We host the algorithm as an isolated service with a secure DICOM path to PACS. Segmentations leave as DICOM SEG and findings as DICOM SR. We write the software documentation for the technical file, and the classification and clinical evidence are planned with your regulatory team.

Medical and dental imaging software

Our reading software and the clinical systems around it have to talk to other vendors' systems.

We specify and build the HL7 (a standard for exchanging clinical messages) and FHIR (a web standard for exchanging health records) interfaces, the device data gateways and the DICOM integration. The integration tests are kept in the verification record.

Interoperability

Security findings arrive faster than the platform team can investigate them.

Our engineers harden the platform, investigate the vulnerabilities and write the cybersecurity analysis. The work runs inside the same lifecycle as the platform code.

Medical device cybersecurity

New engineers will cost months of onboarding and the code quality will drop.

Every change goes through your review workflow and your release gates from the first line of code. The first work package is small, so you judge the code on real changes before the team grows.

How we work

An outside team means a second quality system in the audit.

Your procedures, review workflow and release gates stay in place, and our engineers work inside them with your templates. Third party libraries are recorded as SOUP (software of unknown provenance, meaning third party code used in the device) in your list, and code and records are kept in your repositories, so the auditor sees one system.

Medical software development

Systems

The systems around the platform, and the interfaces between them.

System	What it holds	Interface	Our work
Modalities	CT, MR, X-ray, ultrasound and PET images and acquisition data	DICOM	We add new DICOM editions, supplements and transfer syntaxes to a platform under maintenance and update the conformance statement.
PACS and archive	Studies, reports and structured findings	DICOM · DICOMweb · DICOM SEG · DICOM SR	We export segmentations and findings as DICOM SEG and DICOM SR objects.
HIS and RIS	Orders, worklists and reports	HL7 v2 · FHIR · DICOM MWL and MPPS	We specify the interfaces, build them and test them against the systems installed at the clinic.
Bedside and clinical information products	Device data and clinical documentation	HL7 · FHIR · device gateways	We build the device data gateways and keep the integration tests in the verification record.
Algorithm hosting	Research and AI algorithms as services	DICOM · cloud microservices	We run algorithms as isolated services that scale with demand, connect them to hospital PACS and write the documentation for the technical file.
Build and test chain	Code, builds and test evidence	CI/CD · traceability	We set up the build, test and release chain and keep the traceability from requirement to release.

Fit

When we are the right partner.

Call us when

You want more engineers for the next release who already work under IEC 62304
You want verification to keep pace with development before the next audit
You want a research algorithm running as a regulated service next to PACS
You want your DICOM and HL7 interfaces to work with other vendors' systems

Talk to us

Tell us what you are working on.

A release that needs more engineers, verification before an audit, a DICOM update or field defects. Write a few lines, or book a free 30 minute call with engineering.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Can your engineers work inside our IEC 62304 lifecycle and ISO 13485 QMS from the first change?

Yes. They follow your procedures, templates and review workflow. Every change carries its requirement, risk assessment and verification, and the records are made in your system, so the auditor sees one quality system.

How fast can engineers start, and how large can the team get?

The first engineers can start within two to three weeks of signature. The team grows one work package at a time.

Do you take over QA and DevOps as well as development?

Yes. Our engineers take over development, verification and the build and release chain together, or only the part where your team needs capacity. The work runs inside your lifecycle, and the records go into your quality system.

Which languages and tools do your engineers use on imaging platforms?

The ones your platform uses. Our engineers work in C++, C#, .NET and Python, with the common imaging and DICOM libraries and the usual build and cloud tools.

Do you build auto segmentation models?

Yes, when you have the data to train them on. We train and validate segmentation models on your data, or take your existing model, and build the product around it. That covers the inference service, the DICOM SEG export of the results, model version control and the evidence for the technical file.

How does a first engagement start?

With a technical call. Then we agree on the first step: one or two engineers who join your team, a defined work package, or an IEC 62304 gap analysis (a review of what is missing against the standard). The team grows in small steps as the work needs it. Each step is quoted individually and agreed in writing.

Related services and sectors.

Team extension Dedicated engineering teams Medical and dental imaging software Verification and validation Interoperability Medical device cybersecurity Radiotherapy OEMs