How to build a good EMR

I am an MD, and I'll offer my 2¢ on the EMRs I have used:<p>1. They seem to be sold to hospital administrators, who hold the wallet but don't have to use them.<p>2. This flows from point 1. Given the target buyer, they seem to be made for the purpose of billing, and not for the purpose of facilitating patient care.<p>3. Doctors are all over the map with regard to tech savvy. Some are truly awful. Most of the EMR solutions I have seen are focused on slavishly re-creating a paper chart. Which is dumb.<p>There is a lot of room for innovation here.

The EMR/EHR market is actually a collection of different markets.<p>The institutional one is a lost cause -- you are not going to get Kaiser to back out of its $5B investment in Epic. These are enterprise systems with ancient cores who are largely sold on the golf course, under cover of RFPs and checklists so buyers can compare "apples to apples". No usability or modern technology considerations apply. You will take your Citrix and love it. Like most enterprise apps they have to do it all (billing, HR, compliance, security, and on yeah, some sort of medical charting) simply to be competitive, and as developers we know how that works out.<p>The small-practice market is where a lot of innovation is happening -- PracticeFusion, DrChrono, athenaHealth, eClinicalWorks, etc. It's competitive but the dollar amounts tend to be fairly low and the small-practice market is drying up as doctors ally themselves with hospital groups in advance of the freight train that is health reform.<p>The really bloody (and interesting) battle is in specialty EHRs, as others have mentioned. Generic records just don't fit for optometrists and dentists and therapists and the like. There's huge opportunity here for competition and the markets can be small and cozy enough that UX, SaaS, good service, etc becomes a big differentiator.<p>Jae doesn't get into constraints against ground-up reinvention too much, which are almost comically enormous. For example HIPAA (and "Son of HIPAA" from ARRA) is married to a wide variety of state-specific privacy regulations that go above and beyond the Federal regulations. The biggest constraint of them all is something called "Meaningful Use" (ONC-ATCB EHR Certification), which determines if your software makes you (the doctor) eligible for federal incentive dollars. It's the primary driver of EHR sales at the moment and creates a bunch of onerous and potentially user-unfriendly requirements on the part of the vendors who have to spend hundreds of thousands of dollars to comply, taking R&#38;D budget away from actual innovation. Just to give one example, Jae says "Your EMR does not need to have every single drug and its dosages installed in its database, with an automatic checker to make sure there are no negative drug reactions" -- as a matter of fact ONC EHR Certification (which, again, is driving the industry) calls for exactly that.<p>While I certainly agree with almost every one of Jae's suggestions, it's difficult to see them getting adopted under todays' market incentives. Clinicians don't buy EHRs. Administrators aren't interested the things he lists. And even when clinicians do purchase the systems, the game is heavily rigged towards large, legacy vendors pushing shitty, ugly software with their huge sales forces who can spend money complying with complicated regulations.<p>In closing, it's all sort of a clusterfuck.

As someone who's spent over a decade building systems for clinicians, I'm thrilled that there finally seems to be an awakening brewing, and that clinical users are beginning to demand more from their tools (and realize that more is possible!).<p>Also, semi-shameless plug but we're working really, really hard to build a much better EMR and much of what Jae says in this post is exactly why we started working on it. If you're interested in joining us, we'd love to hear from you! <a href="http://elationemr.com/" rel="nofollow">http://elationemr.com/</a>

EMR = Electronic Medical Record<p>I thought this article was going to be about MapReduce.

"The EMR is dead." - Lyle Berkowitz, MD <a href="http://www.youtube.com/watch?v=oSVIAG11OXM&#38;feature=player_embedded" rel="nofollow">http://www.youtube.com/watch?v=oSVIAG11OXM&#38;feature=playe...</a><p>EMRs were originally built for data legibility, ordering, patient continuity of data (OK, we still dont have this), and better financial tracking. The large EMR vendors have largely already created this functionality, but to an interesting conclusion - the realized value was not nearly as great as the perceived value. As a result, the opportunity for startups is NOT to built a better mousetrap! For the foreseable future docs are going to be stuck with Epic, like it or not. The perceived value of a "better" EMR is not strong enough for institutions to adopt your software. You can only sell on that failed promise once.<p>The opportunity IMHO lies in small applications that solve the problems of docs (or nurses). Pick a niche market (primary care, ortho, peds, nursing, etc.), talk to them, find their pain points, and build software that makes it easier.

For those in Ontario (Canada), our province actually outlines exactly what an EMR should do, the format the input and outputs should be, and defines how data must be imported &#38; exported. It's actually not bad as far as specs go. There are about 16 or so certified EMRs in Ontario that have to meet the requirements to be sold to hospitals and docs.<p><a href="https://www.ontariomd.ca/portal/server.pt?space=CommunityPage&#38;cached=true&#38;parentname=CommunityPage&#38;parentid=4&#38;in_hi_userid=2&#38;control=SetCommunity&#38;CommunityID=553&#38;PageID=1763#specification" rel="nofollow">https://www.ontariomd.ca/portal/server.pt?space=CommunityPag...</a><p>For aspiring devs out there who want to build an EMR and aren't sure where to start, implement this spec. I'm sure it'll overlap with many requirements that US health agencies might need. Except for complex billing with an array of insurance companies, but that's for another thread :)

Jae is thinking in exactly the right direction. The challenge I feel is not building a better EMR - but rather its convincing hospitals that their EMRs really really suck and the $MMs they spent on "Traditional EMR" was all a waste.<p>I think in this industry its all about understanding the environment of current medical practice and re-engineering it piece by piece.

I was just talking to an ex-HIPAA software manager the other day.<p>The complexities are ridiculous. For example, who can edit a patient record, when can they update it, why should they be able to edit it. Who can add information about drugs a patient is taking, which departments are allowed to update certain sections of a patient record...

EMR's are just one part of healthcare, What we need is for all EMR's to follow standards which would make extracting/reusing information from them straightforward.<p>on a related note: <a href="http://challenge.gov/HHS/134-smart-apps-for-health" rel="nofollow">http://challenge.gov/HHS/134-smart-apps-for-health</a>

I discovered last year that this is still a field where good honest money can be made since everyone is bitching about the fact that there is not a good solution.<p>I just wanted to keep my MRI and digital X-ray scans. I wanted to send them to the doctors to get their opinions on them and pay them for the time.<p>I still haven't done much on this myself, but lately I did use <a href="http://www.webpax.com" rel="nofollow">http://www.webpax.com</a> to send some scans to several doctors. Their ideas saved me from a "recommended" operation by a previous doctor. Uploading DICOM could be easier, but still at least there is someplace on the web that enables it for me.

A hospital when implementing an EMR is looking for some cost benefit in doing so. One obvious one is reducing medical errors. The other is reducing staff size. If the physician has to do all the work in entering the medication (drug, dosage, start/stop time, a reason, etc.), someone in the pharmacy department of the hospital is probably not doing it - reduced staff size = more profit for the hospital.

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.<p>I was also co-founder of Contineo [2], with which we applied to YC in 2009 and were rejected.<p>Contineo was an attempt to answer many of these issues - and we had a hell of a time trying to get traction.<p>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.<p>My answer was - and still is - an HL-7 Compliant, back-end agnostic client which can be deployed on iOS and Android devices.<p>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.<p>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.<p>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...<p>But the idea is still valid, as are the main challenges.<p>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.<p>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.<p>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.<p>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...<p>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.<p>The EMRs that are in place represent MILLIONS of dollars of inertial entrenchment behind such systems.<p>In this article he makes the following claims:<p>Build for the web<p>Build for ipad<p>Simple design<p>Design for small screen<p>Dream big<p>Leave it open ended<p>---<p>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.<p>Workflows account for the actual environment within the hospital and how that effects their ability to perform their duties.<p>---<p>Build for the ipad:<p>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.<p>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.<p>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.<p>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.<p>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.<p>(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.)<p>---<p>Make it simple:<p>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.<p>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.<p>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.<p>The AVERAGE age of their nursing staff was 47 years old. They did NOT want a small screen.<p>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.<p>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.<p>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.<p>Epic didn't want to work with us because they dont want any agnostic clients touching their system.<p>Eclipsys is barely technically capable. They don't even fully implement HL-7 making it difficult to get the interactions you need.<p>---<p>Leave it open ended:<p>You will need to be able to make custom workflows for any client. Every client will be different.<p>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.<p>All the other EMR apps built on iPad are really targeted to the small practice physicians. Dr Chrono is doing well at this angle.<p>--<p>[1] <a href="http://www.popsci.com/bown/2009/product/el-camino-hospital" rel="nofollow">http://www.popsci.com/bown/2009/product/el-camino-hospital</a> [2] <a href="http://medsphere.org/community/project/ovid/blog/2009/11/25/announcing-openvista-rest" rel="nofollow">http://medsphere.org/community/project/ovid/blog/2009/11/25/...</a>