When a German-based medical device manufacturer needed to replace 15-year-old software running its contrast media injector, the stakes went well beyond a routine rewrite. The device delivers contrast solution directly into patients during CT scans – a context where software failures aren’t an option.
Sections in this article:
The challenge | What we delivered | Teams and collaboration | Software architecture and design | Technology stack | IEC 62304 lifecycle compliance | Real-world engineering constraints | Testing and validation | Audit and oversight | Why does this matter
Project at a glance
| Device type | Contrast media injector for CT imaging diagnostics |
| Risk classification | Class C – highest risk category under IEC 62304 |
| Scope | Complete rewrite of the console application (primary + secondary/remote console) |
| Standard | IEC 62304:2015 |
| Duration | ~ 1.5 years |
| Customer | Seleon GmbH, Germany |
| Teams | Romania (software development) – Germany (client, coordinator) – Republic of Moldova (firmware) |
They needed a complete rebuild of the console application within the formal IEC 62304 Class C framework governing medical device software. This case study covers how the rewrite was delivered, the constraints that shaped it, and what it took to keep a safety-critical system audit-ready at every stage.
The challenge
A German-based medical device manufacturer needed to completely replace the software driving its contrast media injector – a device used in CT imaging to precisely deliver contrast solution into patients during diagnostic scans.
The existing application was over 15 years old, written in C and C++, and running on outdated operating systems and hardware. The manufacturer’s ambition went beyond a software refresh: the underlying single-board computer was upgraded in parallel to a faster processor with more memory, and the software had to be rebuilt from the ground up within a formal IEC 62304 framework – the international standard governing the full lifecycle of medical device software.
Team insight The stakes were clear: this was a Class C device, the highest safety classification under IEC 62304. Any software failure during a procedure is not recoverable in the way a desktop application might be. The final system had to be architecturally sound, fully documented, and demonstrably safe. |
What we delivered
RomSoft delivered the console application for the contrast media injector – covering both the primary console next to the device and a secondary console used by the assistant in a separate room. We were also responsible for maintaining structured and updated documentation according to IEC 62304 Class C requirements throughout the full development lifecycle. The lower-level firmware controlling pumps, motors, and sensors was developed by a separate third-party team. RomSoft’s software governed that hardware, ran injection programs, and handled monitoring and error management. The system is now in production and in active clinical use.
Contrast media injector console architecture
Teams and collaboration
The RomSoft team included eight specialists: one Team Lead, one Architect, five Developers, and one Tester. RomSoft synced directly with a client-side team in Germany – two developers and a Team Lead/Architect – who also coordinated a partner team based in Republic of Moldova. Collaboration with Germany was close and continuous: joint reviews, documentation, requirements, and test discussions. Contact with the Moldova-based team was informal, mainly to understand the firmware/hardware interface that RomSoft’s software needed to consume.
| LOCATION | ROLE |
|---|---|
| Romania | Console application development, requirements & architecture documentation, detail design, IEC 62304 process governance (reviews, approvals) |
| Germany | Client and manufacturer; overall system architecture & requirements, project management ownership, regulatory liaison, tooling/validation/version control, cross-team coordination |
| Republic of Moldova | Partner team, firmware development (low level software controlling pumps, motors, sensors) |
An important role within the RomSoft team was covering the requirements engineering management – owning requirements definition and maintenance, contributing to detailed design documentation, and making sure the process itself was followed day to day: that reviews happened in the right order, documents were written, revised, and approved, and the team stayed disciplined about IEC 62304 record-keeping.
The overall system Architect/Project Manager role for the full device sat with the German-based team lead/architect, who also coordinated the Republic of Moldova-based team.
Software architecture and design
The architecture was designed for deterministic, failure-safe operation. Given the device’s role in actual patient procedures, the software was built to handle hardware states – pump behavior, error conditions, display interactions, injector controls – with no ambiguity in failure modes.
The interface ran on a touchscreen console built on a custom-hardened Windows IoT image. For security reasons, ports were disabled, so that no peripherals could be connected (USB storage, mouse, etc.) Underneath the console sat the injector hardware and the firmware that drove it directly.
Technology stack
- Programming language: C#, WPF
- Technology frameworks: .Net 4.5, WPF, AutoFac, MSTest, Entity Framework, CanOpen
- Communication protocols: RS 232, RS 485, CiA 425
- Operating system: Windows 10 IoT
- Device processor: Intel Core i5/Quad core
- CI/CD: TeamCity
- Requirements and bug tracking: Polarion, Jira
- Architecture design: Enterprise Architect 13
The main application was running on a single-board computer system. This allowed the team to use a mature, expressive language with the embedded performance profile required by the device, while avoiding reliance on open-source libraries that would not satisfy regulatory traceability requirements.
IEC 62304 lifecycle compliance
Every phase of development was conducted and documented under IEC 62304:2015 Class C requirements, following a waterfall process with clearly delimited ownership, deadlines, and deliverables at each stage:
- Development planning: project-level documentation of lifecycle activities, roles, and deliverables
- Requirements analysis: complete traceability from system requirements to software requirements
- Architectural design: documented decomposition of software items and their interfaces
- Detailed design: unit-level design documentation for each software unit
- Unit implementation and verification: code review and unit testing with documented results
- Integration and integration testing: incremental integration with full test documentation
- System testing: end-to-end validation against requirements
- Release: formal release documentation and version control artifacts
The overall system architecture and the initial requirements were largely established before implementation phase started. RomSoft’s contribution was to refine, update, and implement against that baseline. Because the process was rigorously planned upfront in a waterfall model, delivery held few surprises – changes were limited to minor, incremental adjustments to architecture and requirements as implementation progressed, not major redesigns driven by unforeseen risk findings.
⚠ CLASS C The project was governed by IEC 62304 – Class C, applied for software where failure or malfunction could result in serious injury or death. Every lifecycle activity – requirements, architecture, unit implementation, integration, testing, and maintenance – must be fully documented and traceable. Additional standard applied: ISO 14971 – defining risk management of medical devices throughout their entire lifecycle. |
Tooling, validation, and version control were owned by the customer team in Germany. Within RomSoft’s own delivery team, some Agile practices – daily stand-ups in particular – were layered on top of the waterfall governance to keep day-to-day work coordinated
Real-world engineering constraints
Beyond the regulatory framework, there were some real-world engineering constraints that shaped the project and required our team to adapt to the on-site realities:
- UI parity: the customer required the new application to replicate the legacy graphical interface one-to-one. Any deviation would have triggered re-certification and retraining the clinical staff operating the system, so the front-end design space was fixed from day one rather than being a typical open UX problem.
- Legacy lab infrastructure: more capable communication protocols were technically available, but the cabling connecting the patient room to the assistant’s control room could not be easily replaced – a decision that belonged to the medical facility, not the vendor. The software had to perform reliably over the existing LAN/TCP cabling.
- Two-console, mirrored architecture: because staff could not enter the patient’s room during the procedure, the system had a primary console next to the device and a secondary console in the assistant’s room. Both ran a mirrored version of the application and had to stay synchronized in real time over that same legacy cabling, so the assistant could trigger additional contrast injections remotely while watching the CT feed.
Team insight For Class C medical software, a framework or dependency upgrade is not a routine maintenance event. It can constitute a change significant enough to trigger re-validation of the entire system. The team managed the software stack with long-term stability as a design constraint, documenting the rationale for all third-party component decisions and their regulatory implications. |
Testing and validation
Testing covered both simulator environments and physical device testing – the latter involving direct interaction with the injector hardware to validate real-world edge cases.
Team insight At one point, risk analysis surfaced a scenario the team hadn’t originally planned for: data arriving from an external device could be incomplete, corrupt, or out of format. The feature itself would have worked against the original requirements. Luckily, the formal risk review found that processing bad data could produce incorrect results further down the chain. That single find led to a set of risk control measures: input validation, message integrity checks, explicit error handling, and alerts when something looked wrong. Therefore, requirements, tests, and verification records were updated to prove they worked. It’s a good example of the process surfacing a real risk during design, well before it could have shown up during integration or, worse, in the field. |
All test results were documented as formal records within the IEC 62304 lifecycle. No critical software issues have been reported back to RomSoft since go-live and the system remains in active clinical use.
Audit and oversight
RomSoft, as an external collaborating company, was audited directly by the client throughout the engagement – the client holds the device’s regulatory certification and is itself responsible for satisfying the notified body.
Why does this matter
Class C medical device software is among the most demanding engineering environments in regulated industries. The consequences of a software failure during an active CT imaging procedure, with contrast media being delivered to a patient, leave no margin for ambiguity in design, testing, or documentation.
Successfully delivering this project required more than software development capability. It required a team that understood how to operate within a formal safety lifecycle, produce audit-ready documentation at every stage, and make engineering decisions with long-term regulatory implications in mind.
RomSoft delivered this as the primary engineering team responsible for the console application.
Looking for a partner who treats compliance as engineering?We are looking for medtech and device-adjacent companies that are building or maintaining software where regulatory compliance is structural – baked into architecture, lifecycle, and team culture. If your situation involves any of the following, we should talk:
Get in touch: office@rms.ro |