7 tips for an agile healthtech startup

It’s a time when we are all remote-workers.   Startups looking for new ways to add value to customers.  Large pharmas looking for ways to innovate without breaking the system.

To quote Bill Gates from 25 years ago. Gates was asked how Microsoft can compete in enterprise software when they only had business-unit capabilities.  Gates was quoted as saying that large enterprises are a collection of many business units, so he was not worried.

The same is true today – whether you are a business unit in Pfizer or a 5-person healthtech startup

Here are 7 tips for innovation in healthcare

1. One person in the team will be a technical guru, let’s call him/her the CTO. Don’t give the CTO admin access to AWS.  He / she should not be fooling around with your instances. Same for sudo access to the Linux machines.
2. Make a no rule – No changes 1 hour before end of day. No changes Thursday/Friday
3. Security – think about security before writing code.  Develop a threat model first. I’ve seen too many startups get this wrong.   Also big HMOs get it wrong.
4. Standards – standardize on one dev stack – listen to the CTO but do not try new things. If a new requirement comes up, talk about it, be critical, sleep on it.    Tip – your CTO’s first inclination will be to write code – this is not always the best strategy – the best is not writing any code at all.  You may be tempted to use some third-party tools like Tableaux – be very very careful.   The licensing or the lack of multi-tenancy may be a very bad  fit for you – so always keep your eye on your budget and business model.
5. Experiment – budget for experimentation by the dev team. Better to plan an experiment and block out time/money for it and fail than get derailed in an unplanned way.  This will also keep things interesting for the team and help you know that they are not doing their own midnight projects.
6. Minimize – always be removing features.  Less is more.
7. CAPA – (corrective and preventive action) – Debrief everything.  Especially failures. Document in a Slack channel and create follow-up actions (easy in slack – just star them).

The golden rule for digital therapeutics and connected medical devices

He who has the gold rules.   That’s all you need to know when it comes to privacy compliance.

In the past 5 years, a lot has happened in the digital health space. Venture funding in 2018 was close to $10BN and a lot of work is being done in the area of digital therapeutics and connected medical devices.

As our customers progress through their clinical trial journey to FDA clearance and post-marketing, we are frequently asked on how to achieve HIPAA compliance in an era of digital health apps, medical IoT and collection of RWD (real-world data) from patients.

I will try and help connected medical device engineering and regulatory managers make sense out of HIPAA and the HITECH Act (Health Information Technology for Economical and Clinical Health).

On January 25, 2013, the HIPAA Omnibus Rule was published in the Federal Register, which created the final modifications to the HIPAA privacy and security rule. You can see the source of the law here.

The HITECH Act created a supply chain trust model.

According to 45 CFR 164.502(e), the Privacy Rule applies only to covered entities (healthcare providers, health plans and healthcare clearinghouses). Going down the chain, covered entities have suppliers who are defined as BAS (business associates). A business associate is a supplier that creates, receives, maintains, or transmits protected health information on behalf of a covered entity or other business associates.

The HITECH Act requires suppliers in the chain of trust to comply with the Security Rule.   A medtech company and its’ cloud service providers, customer engagement service providers et al are all business associates.

The HITECH Act does not impose all Privacy Rule obligations upon a BA but:

1.BAs are subject to HIPAA penalties if they violate the required terms of their BA Agreement (BAA).

2.BAs may use or disclose PHI only in accordance with the required terms of its BAA

3.BAs may not use or disclose PHI in a manner that would violate the Privacy Rule if done by the CE

Down the supply chain and to the right

When we go downstream in the supply chain, the BAA becomes more and more restricted regarding permissible uses and disclosures.

For example, if a business associate agreement between a covered entity and a supplier does not permit the supplier to de-identify protected health information, then the business associate agreement between the supplier and a subcontractor (and the agreement between the subcontractor and another subcontractor) cannot permit the de-identification of protected health information. Such a use may be permissible if done by the covered entity, but is not permitted by the downstream suppliers in the supply chain, if it is not permitted by the covered entity’s business associate agreement with the contractor.

Concrete example of a digital therapeutic.

A physician (covered entity) prescribes a digital therapeutic app. The physician writes a script that is sent to a customer service center, which provides customer support to patients to download and use the app.

The healthcare provider will need a BA with the digital therapeutics company (or its customer service center that may be a separate business), who then has BAAs with other online suppliers for cloud and Braze customer engagement services. Graphically, the supply chain looks like this:

As we move down the supply chain and to the right, we see that the suppliers are providing specific and more restricted digital services.

Digital therapeutics HIPAA

 

The golden rule

Although a BA is a formal, regulatory requirement, it includes compliance with the HIPAA Security Rule and possible exposure to Privacy Rule disclosures. To a large degree, the Golden Rule applies – “He who has the gold rules”.   For early stage medtech and digital therapeutics companies, your customers have the gold. Do a good job on your homework on your security and privacy risk assessment.  Consider external threats as well as possible exploits and cascade attacks on your APIs.

Why the CRO model for medical device clinical trials is broken and how to fix it

medical device clinical trials - remote monitoring

Who said: ‘If you are not part of the solution, you must be part of the problem’?

This appears to be a misquotation of Eldridge Cleaver  author of the 1968 book “Soul on Ice” and early leader of the Black Panthers. The correct (full) quote is: ‘There is no more neutrality in the world. You either have to be part of the solution, or you’re going to be part of the problem.

“CROs play a crucial role in operating clinical trials and meeting milestones. However, effectively managing CROs by having continuous visibility on their work and the quality of the data they provide remains a large concern for Clinical Operations executives. ”

This is a quote taken from a marketing email from Comprehend – a cloud software company that is focused on central monitoring. They’ve developed outstanding software; I’m on the mailing list and I enjoy reading the customer success stories.

Onsite monitoring performed by CROs accounts for 20-30 percent of total study cost and delivers 1-2 percent actionable items. Calling the quality of the data they provide a large concern for Clinical Operations executives is an understatement.

If data security worked like this – IT managers would be paying outsourcing companies like HP and IBM 20-30% of their total IT budget for monitoring their network which in return would result in only 1-2% actionable intelligence.     I don’t think so.   There is not a single IT manager in the world that would accept such abysmal performance at such high prices.

Hmm.   So let me get this straight.

CROs are delivering abysmally low-quality service – yet we are calling this an oversight and visibility issue.

Why? Why should we paper over a broken system with software?

The CRO business model is broken.

Where entire industries have undergone business process re-engineering over the past 30 years – clinical trials operations are stuck in the 80s with goofy/manual onsite monitoring and sponsors are being held hostage by CROS. This is reminiscent of the IT service bureau model of the 70s and 80s which evolved into software as a service for anything model of today.

Several years ago – our business unit that specializes in medical device security in Israel had engaged with a client running a large multi-center trial. We had a lot of interaction with the CRO and when I asked the CRO General Manager  (rather naively I  suppose) why they were not doing remote monitoring of data from their EDC system – she told me that she had given a talk about RBM at a conference the previous year but she didn’t seem to have a good reason for not actually implementing RBM with this particular study that had 30 hospitals in the trials

I pondered on the reason for that and realized that human, manual, onsite monitoring was an incredibly lucrative business for them.  They had no economic incentive to use better technology.  Good for the CRO. Bad for the sponsor that pays high prices and gets low-quality results.

Oversight is not a replacement for re-engineering the system.

CRO oversight is not a replacement for re-engineering the system which I believe will require more than oversight dashboards.   As we wrote here, communications with the sites is a critical component relating to a study’s performance and ultimately, its success.  In addition, cloud remote monitoring technologies and dynamic methods of risk assessment can help improve safety and get results faster by saving avoidable rework after data lock.

Productivity tools must result in better prices and results.

Good quality data with real-time alerts and collaboration that help teams work better together are great productivity tools that should enable the CRO to deliver much higher quality results at much lower prices.

15 years ago I was a business unit manager at a large group of companies.   One of the General managers pitched the CEO of the group with an idea to create cross-functional groups, share high quality data and improve collaboration to help teams work better together.

The CEO said – “The best synergy is when each person does their job”

If  sponsors told their CROs that their target is to reduce their monitoring prices by 50% and improve their rate of acquiring actionable intelligence from the sites by 5X ( 5% instead of 1% should not be a challenge) the industry would start going through a phase transition.

Just the way FedEx, IBM and Amazon changed the way we do business today, it’s time that sponsors started standing up for better service and lower prices.