Existing cloud based medical device - questions regarding improving the processes

[Hirvo]

We have a low risk cloud based software service which is at a moment a medical device.
All customers (= professionals and the patients in the hospitals) use the same.
The software is same for all customers, but the content is their own. Also there are some customer based configurations possible and some features are made so that the customers pay for the changes.
The service has been in production for many years.
We use agile development process.

We still need to fullfill and complete all the documentation and procesess according to the IEC 62304, ISO13485 and ISO14971.

I have a lot of questions:
Q1
- Is the software development plan a kind of project plan?
- the standard asks for Change Management and Maintenance Management and Development Plan. All these are handled in the same way in the agile process. All changes and development issues are handled in development tickets. -> can we manage all these thing in one process: Maintenance process? Or what would be the difference between Change Management and Maintenance Management and Development Plan in this case?

Q2
What is a difference between SOFTWARE SYSTEM requirements and SYSTEM requirements (it is not a standalone software, it is cloudbased)?

Q3
We cannot make any difference in configuration management and in version management. Should we?

Q4
Architectural Planning, Software Unit Planning and Integration planning
All the development tasks/features/epics are in the jira tickets. The ticket has phases: requirement, definition, implementation, verification, validation phase and finally many tickets are collected to the one release. The release is also verified and validated. Also Risk Management is involved.
BUT my question is, how do we describe Software ARCHITECTURAL design, Software Units detailed design and Software integration and integration testing?

I hope my question is understandable...

 

[yodon]

I have a lot of questions:

Don't we all! Seriously though, single questions in a post typically get better responses than trying to address a bunch at once. I'll give it a go this time, though.

- Is the software development plan a kind of project plan?

Yes. It establishes the plan from inception through maintenance (post-release). Do you have a copy of 62366? It's pretty clear what the expected contents need to be.

- the standard asks for Change Management and Maintenance Management and Development Plan. All these are handled in the same way in the agile process. All changes and development issues are handled in development tickets. -> can we manage all these thing in one process: Maintenance process? Or what would be the difference between Change Management and Maintenance Management and Development Plan in this case?

Once a product is "baselined" then all changes from that baseline need to be identifiable and tied to a change authorization. This can be either development tickets or sometimes a new feature established in the requirements document. You want to be able to demonstrate that only authorized changes are made. We, at least, do this through check-in or check-out comments (many systems automatically integrates this). This is the configuration status accounting in 8.3 of the standard.

What is a difference between SOFTWARE SYSTEM requirements and SYSTEM requirements (it is not a standalone software, it is cloudbased)?

The standard covers everything from embedded software to software applications driving systems to stand-alone software. So system requirements might say something like temperature is monitored and an alarm raised if it goes above some threshold. This would have hardware as well as software implications. The software requirements would have how often the temperature is polled, what kind of alarms (audible, messages, LEDs) to raise, etc. The software requirements point back to the (parent) system requirement.

If your system runs in the cloud, I'm guessing it IS stand-alone software. The 'cloud' is not a hardware medical device.

We cannot make any difference in configuration management and in version management. Should we?

They're different. Configuration management encompasses everything that's controlled and how changes are applied. Version management is more at the release level. For example, you may have multiple changes going into a single release.

BUT my question is, how do we describe Software ARCHITECTURAL design, Software Units detailed design and Software integration and integration testing?

Architectural design: that is unlikely to have major changes across sprints or releases so it's just a matter of documenting and keeping up to date.
Software units: a bit tricky since YOU define what a unit is. I think a lot of folks think a unit is a file but the definition of a unit is a "SOFTWARE ITEM that is not subdivided into other items." That doesn't say it CAN'T be further subdivided, just that it isn't. Without knowing your system, it's not possible to say what the units would be. Do realize that once you establish something as a unit, there are unit verification and approval criteria.
Integration: actually pretty easy under agile. All your sprint builds can easily be considered integration testing! And basically, your sprint planning can satisfy the requirements for integration planning. Bear in mind that integration tests themselves need to be controlled, assessed for adequacy (review record), and there are requirements for integration test (results) content

Hope that helps some.

 

[Tidge]

I applaud @yodon for being willing to tackle a multi-part question with so many different pieces. I will admit my own bias against doing so.

There was a reference above to the usability standard series (62366), but I think the directive is to look at 62304 for software development (in medical devices).

 

[Hirvo]

Very much thank you!

As we have a cloud based service already in production use since many years and we have the technical file including the Development Plan, I suppose
- Development Plan = Software Development Process description, because it is the only software we are developing - isn't this ok?). No changes for this at this point any more.
- We only use Maintenance Process for changes and further development ideas, no other Development Plans
- we define UNIT = feature (we make the requirement, testing plans, testing for feature) - sounds this ok?
- Architectural Plan is the original one and in the Maintenance Process are the changes for the Architectural Plan handled
- System Requirements and Software Requirements are handled in the same way in the Maintenance Process (One requirement is one feature)

But still I cannot recognize in our process is the configuration management. In our case we update all the changes in the next release, but sometimes we hide some features in the production. We have been thinking, is this a kind of configuration management phase...

Ps. I've red that standalone software should work without internet... our cloud based medical device is in Google cloud. That's why I was thinking that it is not a standalone software.

 

[Tidge]

Very much thank you!
- we define UNIT = feature (we make the requirement, testing plans, testing for feature) - sounds this ok?

In my way of thinking, FEATURES are more directly traceable to REQUIREMENTS, whereas UNITS are the smallest (necessary) atoms of the DESIGN. For example: a single sort function that is used to support multiple features could be an example UNIT. Depending on the software safety classification (per 62304) you may not even have to call out UNITS, so I'll just stop here.

But still I cannot recognize in our process is the configuration management. In our case we update all the changes in the next release, but sometimes we hide some features in the production. We have been thinking, is this a kind of configuration management phase...

CONFIGURATION MANAGEMENT is the process by which the provenance of the device (here, a software device) is established and maintained. Configuration Management allows for the rebuilding of a specific version of the DMR, and supports the update/repair (here, code changes) to newer versions. It supports investigations of previous versions; i.e. it can be used to repeat design verification tests if necessary (unit, integration, system level testing).

 

[Tidge]

Ps. I've red that standalone software should work without internet... our cloud based medical device is in Google cloud. That's why I was thinking that it is not a standalone software.

In the Medical Device world, "standalone" refers to software that can be used without a specific hardware solution. That is: The software isn't integrated within a specific hardware design that is marketed by a manufacturer (and subject to regulatory oversight). The Internet is not a medical device. Unless your company only allows for your software to work on machines that you sell, it is almost certainly in the "standalone" category.

 

[Hirvo]

In the Medical Device world, "standalone" refers to software that can be used without a specific hardware solution. That is: The software isn't integrated within a specific hardware design that is marketed by a manufacturer (and subject to regulatory oversight). The Internet is not a medical device. Unless your company only allows for your software to work on machines that you sell, it is almost certainly in the "standalone" category.

Okay, thank you for the explanation!