Practice Fusion is a free, web-based electronic health record that has seen a rapid rate of adoption over the last two years and, as we reported recently, is currently the largest commercial EHR installation after Kaiser and the Veterans Affairs.
But like all “overnight successes”, the rise of Practice Fusion is not accidental and not without laborious engineering. In fact, important design decisions at its inception have been instrumental in its growth, allowing for rapid iteration of features without incurring heavy development and deployment costs. Matthew Douglass, currently the VP of Product Development, has been through almost the entire history of the company. He was the second person to join the company and continues to lead the engineering process.
In this interview we learn some of the fascinating story of Practice Fusion’s rise, its plans to expand its API (application programming interface) and launch an app store.
We envision that doctors could prescribe an app much like they prescribe a medicine now. – Matthew Douglass
How did you get involved in Practice Fusion?
At the time I was approached by [now CEO] Ryan Howard in 2007, I was working in energy and finance. But, even then, I wanted to do something besides, as I said, “turning millionaires into billionaires”. Ryan had started in 2005 and had just bought a one site EHR that was developed by a family practitioner. I was charged with making it multi-tenant and web-based. Multi-tenant means having all the data stored in a single database, instead of separate for each user. Back then, we worked in coffee shops, communicating electronically. I worked hard for six weeks, including one non-stop 72 hour stretch just before we launched, which has become urban legend around here. Three months later, we went on to the web. That was the beginning of 2008.
How did Practice Fusion initially grow?
We initially charged $50 per month per doctor. Then we decreased it to just $50 for support and training. By the time we went to the web, we were free. This led to rapid growth. We started rapidly signing up physicians. Our very first web user, by chance, was also in San Francisco. With the passage of HITECH act in Feb 2009 [which provided financial incentives for physicians adopting EHRs], we started to get interest from investors. The first were a large Bay Area angel group called the Band of Angels. Later Mark Benioff [CEO of Salesforce] invested. We recently completed a series A round from a venture capital firm [7.2m, 11/24/09, Morgenthaler Ventures]. We don’t do direct sales, meaning door-to-door. Most of our customers find us online. The majority of our users are in California, New York, Florida and Texas.
How did you settle on free as the price?
We found that primary care practices were quite price sensitive, as their real income had stagnated for more than 20 years. We decreased our price until we got to free. We are committed to keeping it free. We feel there are enough other participants in the health care IT ecosystem who can subsidize the EHR, such as device makers, labs, billers, pharmacies, etc. Doctors should not have to pay.
How about advertising revenue?
Ads are a large part of our revenue.
Talk about your implementation
The original EHR was written by a physician, Robert Rowley, who is now the Chief Medical Officer. Our multi-tenant database, where all patients around the country are stored in a single database, has allowed us to scale smoothly by allowing us to release new versions of the software while keeping everybody on the same version. Our architecture also allowed us to easily add a patient portal [Patient Fusion]. Initially we were adding 5-6/day users a week, now we are adding as much as 350 users or about 40-50 practices per day. We have surpassed 60,000 registered users. Just two months ago we were adding 250/users a day, so the rate of growth is accelerating quickly, and we feel that with HITECH incentives in 2011, this may push it higher. We are planning for even greater acceleration.
How many engineers do you have at Practice Fusion ?
We have a total of 53 employees, 17 are engineers and we are hiring 6 more, thanks to the stimulus.
What are your continuing challenges?
A lot of what we do is integration, tying together other systems and suppliers. This does not always show up as an explicit feature. For example, seeing a Labcorp result requires getting a file, parsing it, displaying and storing it. And every single lab is different. e-Prescription integration, such as with Surescripts, and determining formulary eligibility can be very complicated behind the scenes. But because our system is multi-tenant and web-based, we just have to do it one time and all our customers get the update simultaneously.
Tell us about the Practice Fusion Developer Challenge
Last spring, Matthew Holt and Indu [Subaiya, of the Health 2.0 Conference] approached us about posting a Developer Challenge at the Health 2.0 meeting in July. We decided within a week, and launched within 3 weeks. [The Health 2.0 Developer Challenge is supported by HHS but run by Health 2.0]
For our Developer Challenge, we discussed it and decided to go with a limited API emphasizing ways to get real time data into Practice Fusion. We felt that getting the physician real-time measurements [e.g. blood pressure, etc] could be really valuable – instead of requiring the physician or practice to enter all the clinical information. We were very surprised when 35 developers submitted projects, more than any other challenge.
Of the 35 submissions, 25 had to do with medical devices and data transfer. This tells us that there is a market for this connectivity. The winner [Team Critical Systems] was a great example of hacking – a simple bathroom scale was hacked to read the LCD display and the result is transferred directly into Practice Fusion.
Any surprises among the submissions ?
I was surprised that 10 of the submissions did not even submit their own data, but rather co-opted the API to present unstructured data, for example turning a patient intake form into a rudimentary data entry API, e.g. patient submitted “mood” data. This [type of observation] will drive our API strategy. Other types of structured data we had not anticipated such as reporting diagnoses or clinical workflow.
How did you decide on your Challenge ?
There are a lot of medical device manufacturers which already transfer measurements to their own servers. However, this data is isolated. It does not take too much work for them to use an API to transfer this data to patients’ records and allow clinical decisions to be made from this information. This is what could be revolutionary. We already have a dozen companies lined up to work on our API
What future directions are you anticipating for your API ?
We are planning on extending the API enough to allow a limited interface. The first will be scheduling, problem list and medication manager. As with everything else, we will listen to the market. Extending the API has to be carefully done not to disturb published APIs. Developing an API does take away resources from other efforts, but we feel it is important.
What are your mobile plans ?
We will shortly have a Practice Fusion interface which will work on smartphones. It will have limited functionality, giving you the ability to view patients and the schedule. The extension of the API will probably have the same capabilities. We will be bringing our mobile interface, including iOS, Android, and RIM, hopefully in first half of 2011. This will work across all mobile devices with web enabled browsers. We are planning on native apps, depending on marketplace.
The Practice Fusion app store
The biggest enhancement will be a Practice Fusion app store. This is not yet announced although I have a rough date. The idea is that the doctor will have access to all the application within the Practice Fuson network . The app store concept is a way to unify the apps, downloading may occur elsewhere. We put the application as something the doctor can prescribe. The instructions to download the application may be sent to the patient via email.
This is a way for making applications work for you. The buyer could be the doctor, patient, payor, etc. It will be a place where developers can showcase their apps. The apps will be attached to a user’s account but could also be used on other devices, such as a communicating smartphone app.
We envision that doctors could prescribe an app much like they prescribe a medicine now. Right now all a doctor can do is write an order [CPOE] or hand out a pamphlet. But, there are a lot of things in between appointments where a patient can report back to the doctor – maybe compliance with a medication or nutrition plan. A weight monitoring app for a patient trying to lose weight can directly enter weights into their record. Simple alerts can signal patient compliance, or can even provide feedback to the patient herself.
