In recent years, there has been an explosion of Digital Healthcare Startups launching a vast array of both hardware and software into the health and wellness market. These companies offer everything from simple consumer-focused monitoring devices and apps such as Fitbit, to complex interactive health management apps aimed at both Clinicians and patients with Chronic conditions, such as Sense.ly. This market is expected to reach $233.3 billion by 2020, with the primary growth happening in the mobile healthcare market.
As further evidence of the vitality of this area we are starting to see Venture Funds and Accelerators being established with a specific focus on the Digital Healthcare, such as Rock Health, Launchpad Digital Health and the NY Digital Health Accelerator. The healthcare industry – with it long R&D cycles and dependency on FDA approval and other regulations – has not been a traditional target for Venture Capital funds. However, the continual advances in open-source programming libraries, APIs and cloud-based infrastructure are making it easier than ever to build affordable products and services for populations within the USA (and around the world) who are currently under-served. One example is the Hispanic community in the US, who have been up until now an ‘unseen’ market, considered a complex target to engage with due to such challenges as the language barrier, immigration status concerns and comparatively low incomes. Unfortunately these factors, among others, have contributed to the large health disparities between White and Hispanic communities in the USA.
But Venture Capitalists and Entrepreneurs alike have quickly realized that there is real money to be be made in working with these ‘invisible’ populations; if you can design your product with the end-user in mind, and leverage emerging technologies which dramatically lower the cost of delivering your solution at scale. This is something of which we at AllCode have first-hand experience, since our valued partner Consejo Sano has just raised $4.9 million dollars to deliver a digital communications platform to the Hispanic Community that will dramatically improve their engagement with healthcare providers, leading to an improvement in general health.
So there are plenty of good social and economic reasons why you might want to create a Digital Heathcare App, and you don’t need to raise $5 million dollars in order to make it happen, but if you want your app to be successful there are a few areas that you will need to invest time in learning about. From our perspective as healthcare software Developers, there are three main things to consider – Mobile Endpoints & Health Data Security, User-Centered Design, and potential marketplaces in which you will sell your product. Of course, if you were to ask healthcare professionals and patients – and I hope that you do – I’m sure they would add a few things to the list! In part one of this two-part blog I’ll focus on Health Data security.
EHRs and Healthcare Data Security
Depending upon the ambition and function of your app, you will have some responsibility for managing the Protected Health Information (PHI) of your users. If your app is fairly ‘light-touch’ and makes use of simple data gleaned from monitoring devices such as Fitbit or the Apple watch you probably don’t have too much work to do in terms of understanding your role as a Data Controller. The Federal Trade Commission (FTC) website is a good place to start if you are totally new to building apps that handle consumer data – you can find a wealth of information here and suggestions on how to ensure data security for your customers. Security is something that you need to be considering right from the start, as you design your app you will need to be making the right choices about which tools, APIs and services to use; and as you build your app you will want to test rigorously to ensure that those services deliver the level of security expected.
Of specific relevance to anyone who is planning to build an app that will be used at a Clinical Endpoint are two pieces of legislation – HIPAA and HITECH. This is a huge topic, and I won’t even pretend that we can create a comprehensive overview of these two key pieces of legislation in this blog, however, there are a couple of specific things I’d like to point out in relation to developing a Healthcare app. Firstly though, do you know what HIPAA actually stands for?
Put briefly, HIPAA is the Health Insurance Portability and Accountability Act. The HHS Office for Civil Rights (OCR) enforces the HIPAA Privacy and Security Rules, which help keep entities covered under HIPAA accountable for the privacy and security of patients’ health information. Although Electronic Health Records allow providers to use information more effectively to improve the quality and efficiency of your care, they do not change the obligations providers have to keep your protected health information private and secure. The HITECH Act was imposed to account for the transition to electronic records and the security vulnerabilities associated with handling digital data. The HIPAA HITECH Act defines rules for the sharing of electronic medical records (EMR) and imposes stiff penalties upon those entities that fail to show that they have a system in place to impart such responsibility.
Phew! So in practice, there are two things that you’ll want to ensure when you start thinking about the back-end architecture of your app – the first is HIPAA compliant hosting. You’re either going to want to build your own HIPAA compliant back-end with it’s own dedicated server, or you can use one of the many compliant cloud hosting services available. Arkenea have collated a list of 11 great options for HIPAA compliant hosting, with our personal favorites AWS and Aptible both receiving the nod.
Encryption, Restrictions, Containment
The next things you’ll want to consider are data encryption, permission and access restrictions, and containment. But briefly, these are best practice processes in maintaining the safety and security of PHI especially in Clinical endpoints where there is a Bring Your Own Device (BYOD) policy. When Clinicians and patients are using their own devices to access healthcare data there is additional potential for security breaches to take place. Even if you have ensured that your app is hosted on a HIPAA compliant cloud platform, patient data that is accessed from mobile devices is likely stored remotely. The information is usually sent to smartphones or mobile devices from a server located in a secure facility, behind firewalls. Information that travels wirelessly and is stored within mobile devices can still pose a security risk if left unencrypted. It is a mobile healthcare security best practice to encrypt the sensitive health information while it’s being transferred, as well as while it’s at rest. This will help mitigate any leakage and offer strong data protection to ensure compliance.
Mobile devices must follow access control processes and procedures similar to restrictions seen within the world of desktops and laptops. This means only users with appropriate authorizations can gain access to protected data on mobile devices, and only IT has adequate tools to audit and manage all users’ permissions.
With most healthcare professionals using their mobile devices for a mix of personal and business use, it’s challenging for IT to implement restrictions without causing end users to feel locked out of their devices. It is critical that mHealth apps that capture patient data stay isolated and protected from other tools or apps within mobile devices to avoid putting patient data at risk.
To solve this issue, many hospitals and Fortune 500 companies have implemented app and data containment. This is done by running mobile apps separately from all other apps to prevent sensitive data from being copied or penetrated. Creating this separation between personal data and healthcare data reassures IT that patient data can be protected with the right BYOD policy.
Whilst this post has covered some of the most essential considerations for those developing a mobile healthcare application, it is obviously not an exhaustive list. I would encourage you to do as much research as possible and if in doubt contact a service provider who can help you navigate the tricky waters of HIPAA and HITECH compliance! In the next blog we’ll be looking at the intersection between security and user-focused design.