The medical device landscape is changing. For many companies, this means transitioning from being a hardware producer to a software company and facing new compliance-related challenges. In particular, creating accurate requirements traceability reports while increasing release frequency, requires a more agile approach.
But where to begin?
In a recent webinar, RadBee CEO Rina Nir chatted with Richard Koch, Founder of PURI – a Swiss-based medical device software company – to find out about his innovative and technology-driven approach to this challenge.
Richard was previously the CFO and Quality Manager of a medtech startup, so he knows a thing or two about ensuring SaMD (software as a medical device) meets stringent regulations. It was fascinating to take a closer look at Richard’s workflow, which includes the Snapshots of Jira Data into Confluence, to learn about the complexity of compliance and how technology can help solve the industry’s traceability problem.
Here, we take you through some of the key points raised in the webinar. But you can also watch the whole session in full.
The state of medtech and compliance
“If you’re a responsible person, you want to know you’re compliant – not just hope.”
Richard Koch, Founder, PURI
The medtech industry is a mix of legacy organizations and newcomers eager to get in on the action. Something they all have in common is underestimating the effort and resources required to be compliant. Many businesses hold onto document-based QMS approaches which are at odds with agile software development practices, causing communication issues.
There’s also a generational gap between the leadership side and the developers doing the work.
With so few companies failing to understand the commitment compliance requires or how to effectively use a QMS and internal processes to make better-performing, safer, more competitive products, anyone who is able to step up has a huge competitive advantage. Richard says the goal for industry should be ‘clause-perfect’ SaMD traceability – and that change in mindset has to start with leadership.
“I don’t think companies know they’re compliant,” he says. “I think they hope they are. But I know there are non-compliant products on the market. If you don’t get your software compliant, the risk just compounds. And putting a device on the market that’s not compliant is potentially criminal.”
Designing for SaMD traceability
“What I’m trying to achieve, and I’m almost there, is ‘clause-perfect’ compliance with Jira. And I use Snapshots to verify the clause of the requirements, the product requirements, the regulations, so I can review and not guess I’m compliant but know I’m compliant.”
Richard Koch, Founder, PURI
Richard showed the V model for IEC 62304, which defines the life cycle requirements for medical device software. It included the ticket types, boards, and link types that he uses in Jira, showing how a product requirement ticket causes a software requirement ticket, which causes a detailed design ticket (e.g. a story, a task, or a bug). And then how a risk ticket is mitigated by any of those three.Richard separates stories from requirements. Stories are in the detailed design level and close to the code. The various issue types and their links are creating the requirements traceability.
The V Model for SaMD Design, including effort analysis.
Image credit to Richard Koch.
Importantly, the V model also demonstrates the amount of effort required. In PURI’s last release there were 569 tickets, which generated about 1,500 links – a lot of human brainpower and time is needed to build those correctly. Agile is indeed incremental but even with Agile, the first release always involves big effort (enabling you to move more quickly thereafter). Many companies don’t put the work in to even get to the first version of their traceability to be correct and complete. They never get this under control, which means it continues to spiral for each release.
A sneak peek at PURI’s documentation
Ahead of PURI’s latest release, we then took a look at an example of a traceability report generated using Jira Snapshots for Confluence, organized around the IEC 62304 stages. The report showed product requirements, for example “patients must consent to mandatory legal terms prior to using PURI”, and how those requirements are implemented in the product.
Richard also showed what the three-level report looks like in Snapshots. The report is grouped by epic, which can then be collapsed or expanded to suit the user. Richard uses epics as a simple grouper, helping him filter to find what he needs. The Snapshots report shows the epic, the children of that epic, the product requirements, the status of the ticket, and all the software requirements caused as a result of the product requirements.
Configuring your Jira board and adding links to build the requirements traceability
“Just like the three little piggies – you’ve got the house of hay, the house of sticks, and the house of stone – to get any meaningful information out of your Snapshots reports, you’ve got to have your data under control in your Jira project.”
Richard Koch, Founder, PURI
PURI’s set up with five Jira boards: product requirements, software requirements, detailed design (essentially the dev backlog), risk, and verification for Xray tickets. Referring back to the V model above, you can see how with that set-up you can use simple queries to get all the reports you need.
This creates a holistic view that puts all the product requirements in one place. When teams manage different requirements in different ways, things can get confusing and are harder to control.
To review the state of coverage, he uses Links Explorer. Filtering by all the software requirements for the release and all the links chosen that he wants to see in the requirements traceability matrix, it’s easier to scroll see if there are any gaps.
With everything linked up, it’s simple to use Jira Snapshots to create all the reports you need.
Setting up your Snapshots for requirements traceability
For the “Product requirements” (PRD) table, Richard uses a single-level Jira Snapshot. He simply lists all the product requirements without needing to include their relationship to other items in the V model. The query he uses just fetches the “Product Requirement” issues in scope for the product.
Checkout the short extract from the webinar to see how this is done.
For his SRS (Software Requirement Specification), Richard wants to show each software requirement linked upward to the PRD and grouped according to epics. That’s why he uses a three-level Jira Snapshot, like this:
- Level 1: the epics. You can be verys specific with JQL, like this: Project in (DEV) AND issuetype=”Epic” AND labels=PRQ AND status=”In Progress” ORDER BY “Epic Link” ASC.
- Level 2: the PRDs, retrieved via this extended JQL: “Epic Link”=$key AND status=”Requirement Delivered” ORDER BY Description
- Level 3: the SRSs, retrieved with this extended JQL: issue in linkedIssues($key,”causes”) AND status=”Requirement Delivered” ORDER BY Description
And here is another extract from the Webinar, showing how this is done.
The case for Jira and Confluence for SaMD compliance
“Coverage is not verification. It’s really important to see the data. Sit in a room with your team, go ‘Am I compliant? Is that a good implementation of the software requirement? Is that risk mitigated?’ And have those group meetings. If you don’t like it, open the ticket, change it – that’s one of the really powerful things [about Jira].”
Richard Koch, Founder, PURI
Word-based systems for handling SaMD compliance are dying. And moving to Jira to handle your QMS offers so much more functionality. Think about Jira as a sophisticated database – it’s up to you how you want to use it.
The first step is to train your quality management department in understanding Git and ticket-based systems like Jira. You don’t have to transform everything at once, but take it step by step.
“I came from the traditional world,” says Richard. “It’s taken me a long time to get where I am today. I would suggest it’s imperative for industry, and the ones who can do it quickly and get on top of it, there’s a big advantage in competitiveness and potentially cost savings, faster development cycles, better products, and lower compliance risk.”
Want a recap?
Missed the webinar first time round? No problem. We recorded the whole thing so you can watch it back whenever you want. Hear more from Richard’s extensive experience and take a closer look at PURI’s set-up and documentation in your own time.
