Existing cloud based medical device - questions regarding improving the processes

Hirvo

Starting to get Involved
#1
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... :)
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
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

Trusted Information Resource
#3
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

Starting to get Involved
#4
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

Trusted Information Resource
#5
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

Trusted Information Resource
#6
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

Starting to get Involved
#7
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!
 
Thread starter Similar threads Forum Replies Date
N EU MDR and its impact on existing Registrations EU Medical Device Regulations 1
H Verification Process for the existing MDS Product IEC 62304 - Medical Device Software Life Cycle Processes 5
K Relabeling an existing medical device in the field? Other US Medical Device Regulations 6
hockeyhead Existing process never included in AS9100 scope of certification AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
M Do we need to create a new CER or can we just update the existing CER EU Medical Device Regulations 3
P Adding "new" medical device to existing CER - under MDD CE Marking (Conformité Européene) / CB Scheme 1
N New (Upgraded Technology) vs Existing Equipment - Measurements Shift Design and Development of Products and Processes 4
D Validation of existing equipment - Risk based approach example ISO 13485:2016 - Medical Device Quality Management Systems 3
D Validation of existing equipment - I have been asked to write a quality assessment for equipment ISO 13485:2016 - Medical Device Quality Management Systems 13
D How to create IQ, OQ, PQ protocol for existing equipment Other Medical Device Related Standards 2
shimonv Creating a new commercial product based on a modification to an existing product Other US Medical Device Regulations 4
K Change of Existing Medical Devices and 510(k) US Food and Drug Administration (FDA) 9
F Device Standards - Managing Changes to existing standards that apply to our devices Other Medical Device Related Standards 1
J Implementing EN 62304:2006 on existing and proven medical devices IEC 62304 - Medical Device Software Life Cycle Processes 6
H Classification of a device that uses an existing battery IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
C ISO 14001 vs Existing Quality System - How to keep them separate? ISO 14001:2015 Specific Discussions 3
K Addition of a test reader to existing CE marked product. Other ISO and International Standards and European Regulations 2
D Introducing an existing product into automotive context - DFMEA needed? IATF 16949 - Automotive Quality Systems Standard 8
B NEED HSE-MS Gap Analysis between 2 existing Management Systems Occupational Health & Safety Management Standards 0
D How to add AS9145 requirements to my existing AS9100 QMS? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
K 510k "Premarket" Submission for Existing Class II Software Medical Device US Food and Drug Administration (FDA) 3
A How do we implement a Process Approach ISO 13485:2016 - Existing GMP QMS Other ISO and International Standards and European Regulations 2
N Is a new 510K required for change of manufacturing location for an existing device? US Food and Drug Administration (FDA) 1
K APQP requirement when a new print or spec is received from a customer - Existing Part APQP and PPAP 3
V Procedure to change the Company name in existing TS16949-2009 certificate ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
M Use of a "Priority existing chemical" in medical device in Australia Other Medical Device Regulations World-Wide 1
B Existing reports and altering such reports AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
A How best to start revising an existing ISO 9001:2008 system in a company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
I Is it acceptable it is to list new products under an existing 510(k)? Other US Medical Device Regulations 14
G New model for existing Class I Device Listing (510K exempt) US Food and Drug Administration (FDA) 8
S Evaluation of our existing Suppliers ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
S Digitising Existing Documents to ensure regulatory compliance Document Control Systems, Procedures, Forms and Templates 6
S Already Existing Customer Open-PO (Purchase Order) Review ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
S Temporary Facility Used For Production - Use of existing Third Party Logos ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
alonFAI Update an existing QMS manual or write a new one for AS9100C Certification? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
R Regulation Process for Add on Accessory to an Existing Medical Device Other US Medical Device Regulations 1
M QSR - Design Control on Existing Device not Designed following QSR 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
H Medical Device Design Control Requirements (820.30) on Existing Products 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
M Anyone added I-m to an existing I-s CE Certificate? EU Medical Device Regulations 1
Q Combining existing 510(k)s into a new 510(k) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K Integrating acquired existing product into Quality Management System Records ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
D AS9100C - New requirements to existing standard? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
X Existing Toolroom Process Validation - Need to identify clauses addressed. Manufacturing and Related Processes 7
A Understanding adoption of a product to an existing Sterilization Cycle Other US Medical Device Regulations 1
V Improvement Plan for existing QUALITY TEAM Quality Manager and Management Related Issues 6
P Usability Plan for Existing Equipment IEC 62366 - Medical Device Usability Engineering 5
Q Implementing ISO 14001 into an existing ISO/TS 16949 Quality Management System IATF 16949 - Automotive Quality Systems Standard 6
M Reusing existing RUO Software for IVD Development 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
shimonv Deciding When to Submit a 510(k) for a Change to an Existing Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 17

Similar threads

Top Bottom