Let me ask you 3 questions. If you answer Yes to all 3 – read this post, if not, then move on.
- Do you assume that your DCT vendor has a security incident policy – based on the Web site?
- Are you VP R&D or CEO or regulatory and compliance officer at a drug company.
- Are you planning DCT decentralized clinical trials for your new oncology treatment?
Why DCT and why oncology?
Oncology is a space with a growing interest in sensors to capture movement between visits, to indicate that the treatment enables the patient to become more active.
Part of your DCT solution is to use a mobile app to capture movement. The patient will have a UI to check in once/day and provide subjective feedback – feel good/feeling less good than yesterday. Patient feedback and patient movement are transferred to a cloud application server using RESTful services over HTTPS.
This is a common architecture for DCT – mobile – cloud server – EDC. Are you assuming that your DCT and EDC vendors have security and privacy covered?
There are 4 key security issues when you use sensors in a DCT
- How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
- How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
- How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
- How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.
How effective is your security incident response?
The SANS 2019 Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.
Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.
First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees. Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.
Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond. This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.
Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.
3 things sponsors must have for effective security incident response in their DCT
- Establish an IRT. (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools). Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
- Lead from the front. Ensure that the head of IRT reports to the CEO. In security incident response, management needs to up front and not lead from behind.
- Detect attacks on your EDC/DCT vendors’ servers in real time.
Think about your security incident response before you run a DCT.
Make it a management requirement to prepare for the unexpected.
Because the unexpected will happen – threatening the success of your clinical trial, your company, your investors and your career.