Patients in medical device clinical trials are on their phones.  On their phones for WhatsApp and for monitoring chronic conditions and reporting outcomes at home, at work and in the middle of a call to their friends.

Medtech developers are looking to make their product development process as effective as  possible and are facing conflicting requirements when it comes to meeting regulatory requirements and reimbursement opportunities.

For example – generation and collection of clinical evidence needs to come from well-designed controlled clinical studies on one hand and  on the other hand needs to be provide generalizable data from near-real-life usage.

Near real-life usage requires a high level of reliability and usability – you simply afford to have a buggy mobile medical device app that goes into an infinite retry loop on the mobile API to the Clear Clinica monitoring as a service simply because of faulty error handling in the code. The code will eventually time out and the connection may be black-listed resulting in losing data points from the subject in the study.

The latest developments in wearables, connected medical devices, mobile medical apps, cloud services and APIs (and any combination thereof) present a challenge and at the same an opportunity to revisit traditional clinical trial design management tools and processes.

The first challenge is regulatory compliance.  I’ll put it to you straight:

Compliance from Dr. Google is a very bad idea.

Searching for HIPAA Security Rule compliance yields about  240,000 hits on Google. Some of the information is outdated and does not relate to the Final Rule and a good deal of other information is sponsored by service providers and technology companies selling silver bullets for HIPAA compliance.

The online dialog on HIPAA Security Rule compliance is dominated by discussions by requirements for health providers.   There is very little information online for the downstream medtech and mobile medical app vendors who use the cloud to store data and process transactions for their covered entity customers

If you are an innovative medtech startup and you copy policies and procedures from a healthcare provider, you will be overpaying and over-implementing SOP’s which are mostly not relevant to medtech startups.

In addition, the HIPAA Security Rule risk analysis for a SaaS provider or mobile medical devices that stores PHI in the cloud is not even remotely similar to the risk analysis for a hospital.

If you copy and paste a risk analysis – you won’t understand what you’re doing and why you’re doing it and since HIPAA privacy infractions carry both a criminal civil penalty, you don’t want to even attempt to comply via Google.

For example – if you are a mobile medical device vendor – you will need to take into account technology and privacy considerations such as mobile app software security, application activity monitoring, mobile and cloud data encryption and key management none of which may be relevant for a traditional IT hospital-run electronic health records system.

What policies and procedures do I need for HIPAA compliance?

First of all – if you are an innovative medtech vendor doing medical device clinical trial – the answer is “it depends”.

In clinical research, physician-investigators often stand in dual roles to the subject: As a treating physician and as a researcher. For the treating physician, duties of confidentiality have long been established under well-known legal and ethical standards. The Privacy Rule adds to these existing obligations. Where a covered entity conducts clinical research involving protected health information (PHI), physician-investigators need to understand the Privacy Rule’s restrictions on the use and disclosure of PHI for research purposes.

In technology development, the engineers often are exposed to EPHI as part of the debugging process of the medical device API and cloud database processing.

Exposure to subject data in the course of the study may not only result in a data loss and HIPAA Security Rule violation but may also invalidate the findings of a double-blind clinical trial where the sponsor (i..e the medtech vendor) must be blinded to subject profiles.

6 reasons why  HIPAA security policies  are not copy and paste:

1. It depends on the business situation and technology model. A biotechnology company doing drug development will not have the same threat surface as a mobile health company.
2. Your security is worse than you think. When was the last time you looked? Or had an external audit of your encryption policies?
3. It also depends on timing – if the life science company is doing clinical research, then informed consent may release the sponsor from HIPAA privacy rule compliance. But in clinical research, physician-investigators often stand in dual roles to the subject: as a treating physician (who has to comply with the HIPAA Privacy Rule) and as a researcher (who has to comply with both GCP and 21 CFR Parts 50 and 56 regarding informed consent with adults and children).  In my experience with medical device companies, they often do medical device clinical trials in parallel to commercial betas and work closely with physician-investigators. This means that your HIPAA Security Rule compliance posture needs to be nailed down in order to eliminate holes of privacy leakage.
4. Life science companies have quality management systems as part of their FDA submissions – the HIPAA Security Rule policies and procedures need to become part of your quality system. Make sure sure that your regulatory/QA/QC leads understand what it means to implement them and help them integrate into your own internal formats, policies and training programs.
5Covered entities may also have impose specific  requirements in their BAA on the life science vendor;  we then need to customize the policies and procedures to comply with the their internal guidelines.     Sometimes these are quite strange like  the story of the West Coast hospital that deliberately weakened the WiFi signal of their routers in the thought that it was a security countermeasure for hacking their wireless access points.

5. There are also situations of intersection with other Privacy regulation such as CA 1280.15 for Data breach – California is sticky on this and then if  you do business with U of C – there are will be additional things to cover

FlaskData.io provides a Cloud service for assuring patient compliance for medtech companies with a single data model for forms, medical device API and patient recorded outcomes.  We speak your language – the language of API’s, JSON, real-time alerts and analytics that visualize trends in your patient outcomes, clinical sites and mobile app data streams.