Update of SRS and SAD templates for GDPR
By Mitch on Wednesday, 18 April 2018, 15:18 - Templates - Permalink
European Regulation 2016/679, aka GDPR, will be fully in force in May 2018. Everybody knowns that we have something to do to be compliant since it has been published. And everybody is getting awake only two months before the full application. So do I.
GDPR has a global impact on organizations managing personal data, and personal health data. The processes, software and IT infrastructure of the organization have to be reviewed and reworked to be compliant to GDPR. The purpose of this blog is on software, thus we restrict the view to software design only.
The impact on software medical devices is primarily in the software requirements, and by extension in the software architecture. Let's see why.
GDPR requirements for manufacturers of software medical devices
Software medical devices are either sold embedded in physical medical devices, or deployed to the premises of the end-users, or used in remote mode, like Saas or Cloud. In either cases, the manufacturer isn't the Controller (article 27) of personal data, excepted rare cases. The manufacturer can be the Processor (article 28) of personal data, when the software device is used in remote mode by the healthcare provider.
Being manufacturer of software medical device and Processor implies a lot of requirements to this person. Again, we won't discuss that here, this is more by contract and organization that compliance to GDPR requirements applicable to Processors can be demonstrated.
Excepted very rare cases, the Controller of personal data is the healthcare provider. Thus, manufacturers of software medical devices have to design and deliver software, with the right functionalities, which will help the Controller to be compliant to GDPR.
Impact of GDPR Requirements on software requirements
In all the requirements of the GDPR, we can isolate a subset of requirements with an impact on software functionalities. The following additional functions may be required, depending on the device intended use:
| GDPR requirements | Software functionalities |
| Article 15 Right of access by the data subject | A function, which outputs the items of the bullet 1. A function to export data The controller shall provide a copy of the personal data undergoing processing. |
| Article 16 Right to rectification | Functions to update data upon request, with a report of update. |
| Article 17 Right to erasure (‘right to be forgotten’) | Functions to permanently delete data, with a report of deletion. |
| Article 18 Right to restriction of processing | Functions to set some processing parameters to on or off, depending on the restriction. |
| Article 20 Right to data portability | Functions to export data in a common format (which one? good question!) |
| Article 21 Right to object | Functions to set some processing parameters to on or off, depending on the objection |
| Article 22 Automated individual decision-making, including profiling | Functions to set some processing parameters to on or off, depending on the request |
The use of such functions should be the end of an administrative process initiated by the person subject of personal data. Thus, these functionalities are more prone to be used by administrators or data managers than by end-users with non-administrative profiles. Likewise, not all functions shall be present in software compliant to GDPR. The requirements mentioned above can also be handled by manual administrative processes.
Impact of GDPR requirements on software architecture
In the same spirit, we have two articles with an impact on the architecture design:
| GDPR requirement | Software architecture |
| Article 25 Data protection by design and by default | The architecture shall be designed in a way to: implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects only personal data which are necessary for each specific purpose of the processing are processed by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons |
| Article 32 Security of processing | The architecture shall implement appropriate measures, commensurate to the risks on personal data: (a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing |
These requirements are consistent with other risk-based approaches, like the requirements on risks in the Medical Device Regulation 2017/745 Annex I, chapter I, bullet 4 (a): eliminate or reduce risks as far as possible through safe design and manufacture, and ISO 14971 section 6.2 Safety inherent by design. We come back here to the previous articles discussing cybersecurity in medical devices.
The architectural design is strongly influenced by the risk based approach. A Privacy Impact Assessment (PIA) has to be conducted by the Controlled of data. To help the Controllers manage their PIA, the software manufacturer can anticipate this assessment by performing a risk assessment on its own, and implement mitigation actions, which will be referenced in the PIA, as appropriate.
Templates SRS and SAD
As a consequence of these new requirements, the templates on SRS and SAD have been updated. new sections on GDPR, and by extension HIPAA, have been added:
- Download Software Requirements Specifications template,
- Download System Architecture Document template.
You will also find them in the templates repository page.
I share this template with the conditions of CC-BY-NC-ND license.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.
Comments
Hi
I went through your templates adn I can see that in the SRS and also test related documents you use verification method I, A, D, T.
I haven't met this kind of division before and I am interested if this is a mandatory procedure for medical software or only an example how to do verification process?
Thank you
Kasia
Hi Kasia
This is just an example.
Bye