Manual Versioning of Risks with SoftComply Risk Manager

For tracking changes in risk management over time you might want to have versioning of your risk management table and risk reports. In other words, you may want to take a snapshot of the current status of your risks for an audit, archive that status and continue managing these risks in real time. Below is […]

Read more ››

The Importance of IEC 62304 Compliance

IEC 62304 outlines the guiding principles for the development of medical software. It is the gold standards for medical device companies, but its importance goes beyond legal manufacturers and established medical software suppliers. In the vast majority of cases, software embedded in a device (or a device itself) use abundant OTS (Off The Shelf) code, […]

Read more ››

How to Become Compliant on Jira and Confluence with Comalatech and SoftComply

Written together with Mike Rink of Comalatech  Until recently, the Medical Device industry was comprised of a handful of large and well-established hardware manufacturing organizations. As those devices have become more software-driven, so too have software development companies begun working closer with the medical device manufacturers. In addition to supplying software to those manufacturers, these […]

Read more ››

Don’t be a ”victim” of your Quality System, but instead use it to achieve your objectives!

“If you can’t beat them, join them!” If your company has decided to enter the medical device market, and you are in charge of making this transition, one of the things you will have to implement sooner or later is a compliant quality system. It is not going to be an easy job, but on […]

Read more ››

What is a Risk Mitigation Requirement and How to Write It?

Medical device risk mitigation actions aim at reducing the occurrence and/or the severity of the potential harm. Risk mitigations are equivalent to requirements. But unlike requirements coming from user needs or other higher level requirements, risk mitigations need special attention. Of course “Requirements shall be complete, unambiguous, able to be verified or validated, and not […]

Read more ››