Software as a NON-medical device

Hi Bill, to build upon Tidge's earlier point on Cybersecurity and Data Privacy, I will assume your software is not a MD, and will use the example of Zoom for use in Telehealth setting. You're lucky that I had to do a presentation on this for our company yesterday, so the info is fresh in my mind.

Is Zoom a MD? Obviously not. But it can be used in healthcare settings to facilitate tele-health conferences. Since it is only intended to display information, ie: Doctor and Patient face and video, and possibly display some medical information, here is what you should think about:

1. Cybersecurity. The directives are:
- NIS Directive 2016/1148
- EU Cybersecurity Act 2019/881
- Also recommend ENISA website. Have fun with this.
- Some standards to begin with: ISO 27799 or ISO 27001 series, those that apply in healthcare
- Do note that HIPAA is not recognised in the EU

2. GDPR: Personal Data Protection
- There was some dispute about EU-US Privacy Shield, not sure about specifics, but since you are based in the US, good to know
- Doctor Face, Patient Face, Patient Health Records, all these fall under 'data concerning health', and are regulated under Article 9 of the GDPR. This is important to note!
- Also, each individual EU state might have slight differences when it comes to application of the GDPR, good to check with your GDPR rep or EU rep
- Data transfer to third country: Would you need to setup a physical server location in the EU? Not sure, depends.
- maximilian schrems vs facebook. This is a good case study on why GPDR is important.

3. Software Development:
- Since it's not a MD, do whatever you want. Scrum Ninja Six Black Belt whatever

Sooo yep that's all I know about. Maybe others will point out some stuff not already covered. Have fun!

@Junn1992 thank you this is very useful information!!

bill.Kal said:

@Junn1992 thank you this is very useful information!!

Click to expand...

just giving back to the cove i've learnt so much here as well

bill.Kal said:

Again this is NOT my case. I am dealing with a NON medical device. What you are sending is MDCG 2019-11 (software for medical purposes).
Thank you!!

Click to expand...

I know I'm coming in late on this, but this guidance (MDCG 2019-11) also has a lot of explanation of the boundary between a medical device software and a non-medical device software, which I'm not sure from the message chain whether this was answered for you clearly for the EU.

Hello,
I am in the same case as you Bill, could you tell me what document you have prepared for non-medical device software, is there a risk management to be done?
Thanks in advance,

iam1235 said:

Hello,
I am in the same case as you Bill, could you tell me what document you have prepared for non-medical device software, is there a risk management to be done?
Thanks in advance,

Click to expand...

Hi Iam,
I'm not sure if you mean a document explaining why the product is not a medical device or the technical documentation, so I'll answer both.

1. I wrote up a policy document that laid out the crtieria from MDCG 2019-11 and explained in detail for each why it didn't apply, including anywhere there might be a misinterpretation that could mean the criteria applied. This wasn't a requirement, but I thought would be good practice in case a regulator or auditor ever enquired.

2. I was working at a medical device company, so we still followed our product development process and created the majority of a technical file (e.g. requirements, verification, validation), only missing things like the ERC/GSPRC and the Declaration. We also tailored some of the requirements to make them easier (e.g. fewer users in the usability testing). What is required for medical devices is also good practice for non-medical device products and my company was used to following our standard process, so agreed that it would deliver a quality product.
In our situation, this wasn't much of a concern, but by implementing some or all of the SaMD requirements, it meant that if a regulator ever disagreed with our assessment or we want to enter a market with different definitions of a SaMD that included our product, we would be closer to compliance.