I am a healthcare systems designer -- I design various technology aspects used in a hospital from the physical cable plant, the way technologies interact and information is displayed and consult on how data is accessed and consumed. I designed technology systems for both El Camino Hospital [1] and San Francisco General Hospital.

I was also co-founder of Contineo [2], with which we applied to YC in 2009 and were rejected.

Contineo was an attempt to answer many of these issues - and we had a hell of a time trying to get traction.

This post is good - but there are a lot of other factors that are at play in an organization which result in their deployment of whichever EMR they are on.

My answer was - and still is - an HL-7 Compliant, back-end agnostic client which can be deployed on iOS and Android devices.

We built this client and a demo for El Camino on top of both MedSphere's Open Vista EMR (We needed a schema to demo against) and we did a demo on El Camino Hospital's (ECH) implementation of Microsoft Amalga.

We built this as an iPod Touch application for a range of reasons but the two main ones at the time were the iPad didnt exist yet - though we were expecting it and the iPod touch is wifi and cheap. A $200 device for the use made good sense.

After having no traction or interest from YC or angels who all told us we needed paid pilots, and having a fallout with my co-founder it died...

But the idea is still valid, as are the main challenges.

Ill discuss each point in here - and again while this is a good post - it is actually made by someone who really isn't too familiar with how healthcare organizations are run, especially from an IT perspective and even more so from an EMR perspective.

There is an eternal battle between medical staff trying to always bring in some technology that will help them in their care and the IT organizations who are expected to manage and maintain all systems that peoples lives depend on.

This is further complicated by the fact that hospitals, and their staff ARE NOT IT ORGANIZATIONS and they most often outsource their IT operations to companies like Eclipsys, Perot systems (dell), and others.

This is the biggest issue. Because of this fact - orgs that outsource to Eclipsys get the Eclipsys EMR, Perot uses Epic, Others use Siemens etc...

And guess what -- these IT organizations are under strict contracts and WORK FOR A PROFIT so they have ZERO incentive to make changes, be fluid, "design for the web" or any other nice things we all take for obvious and granted.

The EMRs that are in place represent MILLIONS of dollars of inertial entrenchment behind such systems.

In this article he makes the following claims:

Build for the web

Build for ipad

Simple design

Design for small screen

Dream big

Leave it open ended

---

Build for the web:
THESE SYSTEMS ARE NOT ON THE WEB. They are either run in house - or via the IT providers datacenter through PPP tunnel. Every hospital has a number of BSA IT Folks on staff FULL TIME to manage the EMR for JUST THAT SITE. So to simply say that an EMR should be "on the web" is not thinking about the long term support of that EMR - and the organizations individual workflows that are built around two things: their staff and the physical layout of their facility.

Workflows account for the actual environment within the hospital and how that effects their ability to perform their duties.

---

Build for the ipad:

The ipad is a beautiful luxurious device. Docctors make lots of money. Doctors are smart. Doctors like to buy luxurious things with their money. The ipad fits into this really really well. What it does not fit nicely into is a close-minded IT organizations view of a critical device that i easily maintained, managed and supported.

The ipad's environment is OWNED by APPLE. Apple takes a cut of the profit (30%) of your app. The case is not rugged, it is not hermetically sealed. And the device does not have a good multi-device charging station. The device cannot take external peripherals.

I love the iPad -- and I do think it is the future of medicine - but until Apple stops douching about with their iron grip on the thing, and make some concessions for enterprise, it is still hard for the iPad to be the device we all want it to.

The IT organizations in a hospital don't feel they can manage the iPad - and having years of experience in IT, the mantra will always be the same when an IT org is operating in fear mode "We don't have the resources" -- they will always say this. They don't like change.

And to the parent company, the IT org in each hospital is minimal staff to perform the requirements of the contract -- they are not there for anything else.

(Personally, I am working on a project (alternate YC application project to what I applied for) which is a medical information content management platform, but based on Android. The issue is that hospitals spend millions on hardware: computers, carts, tablets, televisions etc.. there is yet a single platform that can work for both patients (patient entertainment and education in-room) and staff (role based access to medical systems. I think that this is achievable through android.)

---

Make it simple:

I agree with this, however just because it takes 6 hours to learn an application does not make one suck at making software... Autodesk makes AMAZING software that takes a lot more than 6 hours.

The issue here is that every organization has individualized workflows. You need to spend a lot of time boiling them down to their essence. Certain aspects should be able to be made simple and consistent - like medication administration.

Design for the small screen: This was actually the biggest push back! There are almost 3 million registered nurses in the US. At El Camino alone they had more than 900 ON SHIFT at any given moment - with an employee population nearing 6000.

The AVERAGE age of their nursing staff was 47 years old. They did NOT want a small screen.

Even with all the reasons why the iPod touch was a great device, even the typical 15" screens in the facility were too small for them.

This is correct - you must design for a small screen - but what this means is that you need to really understand the workflow so you can only put the UI elements on screen that must be there for each step - big buttons.

Dream Big: Every big EMR player out there is going to try and stop you. We were asked by Thrasys (who makes sorian med suite for Siemens) if we would OEM our product to them, they had us come in and meet with them, review our capabilities etc... under the guise of them wanting to OEM - but really they were phishing for ideas to steal.

Epic didn't want to work with us because they dont want any agnostic clients touching their system.

Eclipsys is barely technically capable. They don't even fully implement HL-7 making it difficult to get the interactions you need.

---

Leave it open ended:

You will need to be able to make custom workflows for any client. Every client will be different.

The EMR really needs to be addressed - but with the current state of EMRs, the closed minded stance that their creators have and the incentive to defend like mad their territory -- there are other ways to make in-roads into the healthcare space that might work a bit easier. This is why I am going after the patient entertainment space -- the patient room is where you can really make headway in this battle - because the EMR folks wont see you coming. But it is at the bedside, the experience that the patient has and the affect you can have on staff, that one can start to take on the big players.

All the other EMR apps built on iPad are really targeted to the small practice physicians. Dr Chrono is doing well at this angle.

--

[1] http://www.popsci.com/bown/2009/product/el-camino-hospital
[2] http://medsphere.org/community/project/ovid/blog/2009/11/25/...