I’m occasionally asked to consult with startups who are launching medical applications. Often the leaders of these companies are extraordinarily bright and passionate individuals, but they have a superficial understanding of what’s required to be successful in the medical software field. Even companies with physician leaders or other medical professionals experience trouble with going to market with medical apps.
So, what’s different about medical applications?
Medical Apps are Safety Critical Systems
There are commonalities between medical apps and those in other industries, but there are many significant differences. The most obvious of these is the potential for harm. In healthcare we seek to treat and prevent disease. A byproduct of this is that your app can affect the emotional or physical wellbeing of the patient.
Imagine an application for dermatology that over compresses images and introduces JPEG artifacts. In the worst case, the dermatologist may not diagnose an early melanoma leading to metastatic disease, and ultimately death.
Safety critical systems are more expensive to design and develop. In the case of medical apps this means you’ll spend a lot more money in ensuring that you app will cause no harm, and then even more money testing and deploying. Simply pushing apps out into an app store with no real testing may be acceptable in very low risk applications. For more complex applications this can be a receipe for litigation.
Healthcare is a highly regulated industry. Startups often struggle with what is required for compliance because they cannot afford to hire a dedicated compliance and quality officer. The reality is that compliance comes in multiple flavors and it’s important to pick the right one. If you are building diagnostic apps you need to learn about the GXPs. For non-diagnostic apps a decent understanding of HIPAA and HITECH provisions may suffice. There is a massive difference between these two sets of regulations in terms of cost and time to market and knowing which to follow is critical.
For a simple application that reports blood pressure readings to a MD the regulatory hurdle is quite low. However, if you plan to measure blood pressure using a novel technique on the iphone, expect a visit from the FDA. Federal law may classify your application as a medical device, and you’ll need to perform extensive clinical validation prior to sale. You cannot sell your product until this is complete.
While regulation is not something to skirt around, most startups would not get off the ground if they did not employ a risk based approach. We’re going to focus on giving you what we believe to be the minimal set of things you must do, as well as a guide to build on this over time as funds permit. This will keep you out of jail and away from massive fines while not killing the company before it’s begun.
Finally, selling and marketing medical applications in Healthcare has unique constraints. Regulatory elements such as the Stark anti-kickback laws prohibit marketing services to sources of patients. A hospital cannot, for example, financially incent physicians to send patients to a referral center, and an application that provides any form of “kick-back” will most likely be considered illegal.
Interoperabilty and systems
Another difference between Healthcare and other industries is that interoperability is absolutely central. Larger hospitals may have hundreds of clinical systems that work together to provide patient care. The connections between these systems are complex and making changes can be difficult. Your application will need to participate in this spider web at some point, and understanding when, and how data flows, is key.
Let’s say I’m working on a gamified blood pressure monitoring application. Patients enter their results three times daily and these numbers must be reported to their medical record. Typically this means reporting to the Electronic Health Record in use at their provider via an interface such as FHIR (Fast Healthcare Interoperability Resources). The EHR may have rules to detect abnormally high readings that notify the on call cardiologist via pager or secure email. The specialist may want to see the past six months of readings, however not all of these are kept in the EHR. A coordination dance ensues as the systems exchange information and everybody comes up to speed.
Medical Standards for interoperability can be complex. When working with medical images it’s common to use a standard called DICOM (Digital Imaging Communications in Medicine) that specifies the format of files generated by modalities like CT machines, and how those files are transfered around networks. There are literally thousands of pages of material in the DICOM standard and it can take significant time to understand, and become comfortable with how it is used in practice. If you’re just getting started in the field this can be extremely intimidating.
Healthcare is a field that has hundreds of years of established practice and protocol with a powerful elite of medical professionals at it’s core. Many of these practices were created for sound clinical reasons. Something as simple as the way patients are identified using medical records numbers can in reality be quite complex when you take into account systems such as Enterprise Medical Patient Identifiers (EMPI).
In most applications of information technology, the product or service can be completely standardized to improve efficiency and quality. Unfortunately, when you’ve seen one product or service in Healthcare, you’ve seen on product or service in healthcare. This is particularly problematic when you are working with a minimum viable product (MVP) approach. What works at Cedars Sinai may not work at Beth Israel Deaconess without significant modifications and it’s important to understand that early in the new product development process to avoid incurring rework and cost.
A lengthy sales cycle
Selling into Healthcare, particularly hospitals, is time consuming because decisions are often made by committees using a rigorous sales process. During the planning stage the hospital will work to “identify the need”. Your application will be evaluated against the hospital’s overall strategy to determine the benefits you bring to operational workflow and financial outcomes within the institution. Make no mistake, hospitals are complex, and the scope of this evaluation will likely reflect that.
If you pass the first phase, your firm will be evaluated against your competitors – typically through an RFI process. Hosptial RFI’s are lengthy documents that probe every aspect of your performance and take a great deal of time to fill out well. When the document is submitted, even more committees will review every aspect and make ask for clarification. Gettting to “yes” can take six to nine months.
HealthCare is different
Medical apps are different and they require unique skills. There is, of course, a continumn at play here. On the easy end of the spectrum applications such as weight trackers that don’t contain identifying information about the patient, have very few barriers to entry and are accessible. When you cross into medical devices and personalized medicine a completely different level of complexity comes into play. It’s important to know where your app falls along this spectrum so you can apply appropriate strategies and maximise profit.