OpenEMR: Electronic Medical Records and Medical Practice Management Software
open-emr.org
open-emr.org
I've come to realize healthcare software is a significantly trickier problem than most realize. Not in terms of technical possiblity, but other factors.
Building healthcare software is really hard - which seems like such a paradox, because surely ensuring highly trained individuals have half decent tools would be a huge goal for society - but almost all healthcare software is still frankly, terrible.
After heaps of reading I've narrowed it down to 3 reasons why healthcare software is so hard to build.
1 - Modern healthcare is complex, and varied. Building any healthcare softawre is no easy task, even simple systems have many other systems to integrate with. But what makes this worse, is that no two places do healthcare quite the same. Between regions, and institutions, healthcare can vary a shit ton.
2 - Healthcare is risky. Sounds obvious, but if your software fails, people die - but this risk creates an attitude of "dont touch it". Changing systems has such a risk, that institutions will use the same software until it's so out of date its not funny. This impeeds improvement and innovation.
3 - Healthcare software is hard to sell. Not in the sense that its unprofitable, but that it takes ages to get users. Say if I made video editing software - I could get professionals trying it out tommorrow. However, if I make a PMS, I have to sell it to the entire practice - not just a few keen doctors. From making contact to actually getting a small practice using your software could literally be years - making it super hard to enter the market.
I've been working on this topic fulltime for a year now - and I must admit, I don't have the golden answer. However, I'm designing a system as a response to these factors, an alternative to interoperability, and would love to talk anybody in the industry about it.
eliot.slevin@gmail.com
I'm instead focusing on just health records - and the interfaces medical professionals use to work with them.
I've had a good look at FHIR and many other standards, but FHIR is built for an interoperability model - eg, your record is sent back and forth between your gp, hospital, specialist, labs, etc. I'm instead focusing on a central access model - so all of the parties interested in your record are all accessing one central point, so I'm doing something a bit different, it almost looks like NPM.
That being said, I'm all for any standard becoming the industry standard - I don't care what it is, anything is better than nothing. So I wish FHIR the best of luck :) http://standardhealthrecord.org/ is also a standard I really like
A health record is a collaboration - unlike a medical record, which just shows a slice of your health from the perspective of a single institution, a health record aims to show as many facets as possible. An EHR system should be agnostic about who access the record, and what they use it for - obviously gps, specialists, hosptitals, labs, the patient should all have access - but what about, as your said, software?
The ideal system would be,patient visits your system, goes through an OAuth flow, and your system has api access.
The tricky part is format. Its really hard to define a format which fits the entire world's use case. If you consider, what is healthcare information - you realize it's any data relevant to the patients health. So how can you even start to define that?
My compromise is a system where formats are promoted to become popular, regionally, and condition specific. So if you're building a machine learning readmission software, you can target a specific market - say British Primary care, or a specific condition, say diabetes. You can expand out to other markets by writing transformers to translate from one regional format to another.
I guess my point is... it's likely that you may want a "single source of truth" for the data, but farm out copies for other applications. And once you do that, you probably want some kind of "replication protocol" that sends updates, rather than making a full copy of the data every day.
And once you've done that, aren't you right back where we are today?
What it provides is a way to replicate some or all of the record to other health institutions. Say, you share the patient's medication list with the hospital - they also keep a copy. When you prescribe a new medicine, the hospital's copy also gets updated.
And yes, arguably this is just another version of interoperability. However, if you want to share healthcare information, in a way which allows institutions to have freedom, it's unavoidable. The concept of interoperability isn't bad, just the implementation is.
The alternative is all patients records are kept, and accessed from the same place. However, this is very tricky. Many governments have tried to make national health record storage systems, which had immense budgets, and didn't really work out. Often with systems controlled by one party, it's hard to work on ideas which don't fit their goals. Say if you have this great idea for a new format to manage diabetes - that wont fit into their standard format, and you'll have to work outside of their system. Not to mention the control over the population this organisation would have.
Patient owned and controled systems are often suggested, and have been built, but I've never seen one work. Patients expect their doctor to manage their record - and they pay for them. It would be a huge challenge to get every patient to pay their yearly 'health record server fees'.
On top of that, heath records also belong to the doctors - legally in NZ they have to keep a copy of your record for 10 years since your last visit. For their own liability they need access.
In my mind only two models can really work - Goverment run systems which are run better than current systems - A better take on the interoperability model
Still a native FHIR EMR would be really cool!
[EDIT]: https://www.hl7.org/fhir/ for the interested
As a company trying to use machine learning to predict healthcare risk, what do you look for in a format to work with? How do you deal with incomplete data / incorrectly formatted data?
The nice thing about FHIR is that it quickly allows us to join up all the data for a single patient, and all the pieces of data we need are always in the same, standards-compliant place. It also does a good job of defining what datatype to expect when you access a part of the patient record (low bar, but yeah, medical data :( ).
The bad part about FHIR is that it's so heavily nested and flexible that it can get annoying to extract some of the data. For example, the date that something happened is accessible by a different key or keys based on the type of event that happened. Same with trying to access what doctor was responsible for that event. That's meaningful medically, and one-size-fits-all in these things is hard, but I have to jump through all sorts of hoops to get to it and write lots of "if this then that" code to get the same information. There are also some odd omissions. For example ethnicity isn't super consistently represented.
For incomplete data, we deal with very large numbers of patients so some of that washes out in the aggregate as we build models. If the data for a given patient is truly incomplete, we then simply don't use that patient. We do a few other things, but can't go into much detail here ;).
Incorrectly formatted data drives me nuts. It's super manual. We pass things through a series of filters and reshaping that helps cut down on the problem, but it sucks. A lot. Not much to do but try to figure out rules for common data entry or format screwups.
re. HTTPS, yeah it's screwed up in a couple ways but we're getting it fixed. The public website has nothing to do with how we secure/transfer/handle client data though.
If you've got more questions, I'd be happy to email, feel free to reach out at ntilmans@lumiata.com
With HITECH, the government forced them to transition to EHRs, and here's what hospital systems optimized for...
1. Reliability
2. Optimizing billing
3. Guaranteeing compliance with different protocols, particularly those related to billing
Openess? Interoperability? They don't care. You're piling on more technical and administrative costs without the promise of future returns.
> ensuring highly trained individuals have half decent tools would be a huge goal for society - but almost all healthcare software is still frankly, terrible.
You know who hates EHRs the most? Doctors. Do you know who loves them? Hospital administrators. Guess who pays for the EHR? ;)
[0]: An exception to this is Kaiser Permanente. They insure the patients for which they care, so they're incetivized to improve health to reduce costs over time.
Yes. Thing is, say you have shitty software and see 20 patients in one day. Say you have fantastic software - you'll probably still only see 20 patients a day. The cost of upgrading is usually not justified if it doesn't hit the bottom line.
I'm trying to tackle this by making a system where improving it isn't a huge risk, or cost. For example, it has an extensible user interface - imagine something like atom text editor, or even browser extensions. Say you look at the immunization screen all day, and hate it. Find / build a small extension to arange it how you want, without changing any of the back-end system, and then share it to a registry for other people in your situation. Easy win.
I'm actually designing this system within the context of primary care in New Zealand. We have a socialized healthcare system, which is honestly very effective. Everybody pays for it via tax, and resources are evenly distributed. We even bulk purchase generic drugs for the entire country.
There isn't so much of an evil incentive to ensure all their 'customers' stay sick, but instead funding is a bit hard to come by. Funding happens regionally, and building national healthcare software systems is a huge task nobody but the government is willing to try. The market is so small (population of 4mill) that vendors can usually make more money elsewhere - so getting NZ tailored solutions is rare.
This is why I think the opportunity is in making a crowdsourced system, as opposed to a 'product' to sell.
For small practices, this might be a viable solution, but then again, they'd probably rather purchase a complete IT solution than something that handles medical records alone.
Also, have you looked at OpenMRS?[0] They have a module system that allows you to develop extensions to the EHR.[1] If you're looking for your thesis to have a big impact, I'd really recommend getting in touch with an organization like OpenMRS or Partners Healthcare to see how you can extend their platforms. If you want an introduction, drop me a note: faraz dot yashar at the gmail.
[0]: https://openmrs.org
The EHR model will eventually lose because its one sided. Consumers and patients are completely left out of the picture and EHRs have no incentives right now to change. Beyond that companies like Epic are operating on outdated business models. The days of the black box of data that lives inside the four walls of the health system are numbered.
Consumers won't deal with a dumpster fire of technology once they have the choice. Digital health will win once the barriers of compliance and interoperability are broken down.
#2 is the whole risk aversion thing. Any platform migration is going to have political risk attached to it. Nike won't move away from Oracle even if Postgres can do everything it can line for line because paying the $200k maintenance fee each quarter is a cheap recurring cost compared to the political risk of a failed project.
That's not even factoring in #3, the little features here and there which are value-adds to the platform and not part of the standard. I've inherited projects where my firm offers to support O&M for some poorly written ASP 1.1 Classic software. We'll go in, patch some business-logic bug, and get a phone-call later that afternoon asking to rollback our fix. Turns out their users had integrated bugs into their workflow such that when the software operates "properly" (i.e. 'to spec') it actually breaks things (i.e. stops operating in an expected fashion).
*Based on a true story.
My point was that the model you describe is dated and broken. When consumers have the choice to make decisions around technology, price and value, they'll do exactly that. Right now they have no say in the matter, as you've pointed out.
I'm not in medicine (oh thank Christ) but I come from a family where I couldn't ignore the the industry if I wanted to. (Literally every male for 3 generations on both sides have worked directly in either medicine in a university capacity after their PhD, actively practice(d) medicine, or more commonly done both.) My mother's an RN, and my sister's a BS/LPN who's one of those "do gooders" who jumps around (on her third graduate degree now) working usually neuro AC or OR full-time concurrently. So I've heard it from the board-level to the overworked resident side to the 'thank god that fellowship is over' and the 'just got off a double and had three GSRs and a handfull of standard MeOHs', from the the early EHR adopters (interestingly enough, B&W/Partners in Boston) side, the pen-and-paper side, to the 'in between'. The 'in between' is the worst for every one, at every level, bar none, unless you're the one on the steaks-and-strippers sales side.
The limbo period is where absolutely everyone is frazzled because things don't work the way they used to. That's fine for us since we design the damn things, if the scheduling API changes we can just use ...anything really... to make that new JSON invocation or XML-RPC call and Bob's your uncle. But everyone can't be expected to "just pop the hood change the carburetor's flow by 3cfm"; they just want their damned car's engine to turn over so they can use the vehicle. So everyone else is fighting new apps and new workflows while still having to make sure that you're still maintaining an SLA of literally 24/7 operational functionality in certain departments with maybe 3 hours a quarter of scheduled yellow-time for upgrades on 3AMs of the first Sunday each month.
Let's start with getting paid, since everyone needs a paycheck, right? The new system dictates that all employees have to badge-in with new RFID's at certain points (entrances, exits, secure regions, etc). In theory, great idea. Part-time employees salary now gets automated plus now we can ensure better operational security (why is Dr Jane, 9AM-6PM, internal medicine, badging into the OR, 4 floors from her office 5 hours after her shift, where all the Demerol happens to be kept...?). Any non-salaried employees pay-check gets tied into the badge-in/out and literally 70% of the staffers forget to do this, since they never had to before and after lunch they're just walking back in as they normally would. Jon the Janitor pulls up his Bank of America statement and is wondering why last weeks check (bi-monthly, with one pay-cycle close period for adjustment/payout -- so some of these hours, remember, are from potentially 5 weeks ago) was for $90 instead of $2400. So he calls HR to get the money he worked for, and Oprah who's been a great HR employee tries to figure out where the 'alter' feature is and after 5 minutes of "bear with me, sorry, this is a new system...(awkward pause)..." they finally figure out how to make adjustments to the hours (turns out the a manager 2 levels up has to authorize the labor change, since it's past the adjustment business rule of +/- 10% of the hours). AP is slammed with a 40% increase of workload since all those checks have been sent out and we're already in to the second week of the new cost-accounting period. So everyone is frantically calling in 5 weeks after the quarter closed as to why last weeks check was for $90 instead of $3400. Having fun yet?
So Tim works the support-desk phones making sure Derm's scheduling is taken care of. He's spent 20 years making sure all those follow-ups are properly scheduled, all the new patients coming in have the proper primary referrals, etc. Not a glamorous job but he's good at it. Jane's in her 50s and been seeing Dr Eczema for 8 years. She's calling to schedule her yearly just to make sure that mole on her neck which was 2 of 5 on the ABCDE ("looks alright now, let's keep an eye on it though") hasn't developed into a malignant growth. He tries to pull up her file (there's about a 75 second delay there as he fumbles around with the new system's UI and "no no, that's not your subscriber ID, that's your patient ID, your member ID is 8 digits and begins with 40", he finally gets to the right modal menu, and has no idea to even see if her doctor has any availability on the Tuesdays mornings she's got some free-time to take off from work. (Before this, he's would have always just told Jane to "please hold.." and punched in the extension number for Dr Eczema's PA, Mr Clockwork to see if there's availability.) So now he's literally iterates through every possible drop-down, for every 15-minute interval Jane can take off work (9AM to 11:30AM, 10 slots), for the next 6 weeks (takes say 4min30sec per patient). It ends up taking him five minutes, but he gets really good over the course of 8 months at clicking buttons (clocks that down to just under 2 minutes, boom!) before a co-worker tells him there's an "Availability" modal hidden 3 sub-screens in that lets you access Dr Eczema's full calendar. (He was sick on that training session day.) Tim's ecstatic.
Don't get me started on the the custom iPads that the CIO thought "we gotta have, it's the new thing!" which no one uses since the GUI is obtuse and every room has a desktop which is far easier to take notes while talking to your patients. 6 months later, 2k iPads are gathering dust and everyone just uses an RDP session into the Win2k12 server since it's way way easier to take notes/make referrals/write scripts. Don't get me started on actual selection process, as board-level CIOs' wife happens to hold 200k shares of pre-IPO stock she scored 12 years ago that's worth a small fortune now. He conveniently omitted that fact, and rather than recusing from the selection committee was actively pushing for it. (True story.)
Now the CIO is evaluating 'hmm should we go to Cerner?' because we have 2k iPads sitting around doing nothing, some 60 year old absolutely-brilliant neurologist who's responsible for a ton of patient draw (as such, a lot of political clout) can't figure out how to use the damned thing. (An apt comparison would be "ever tried to help your grandparents use email during the hotmail-era?" for those of you who remember that sort of thing.) [Basically the equivalent of moving from SAP to Sage500/Dynamics/other-ERP which also happens; the Mayo Clinic transitioned from EPIC to another EHR while my uncle was there, all sorts of fun I heard!]
There are all sorts of issues on the logistics "who gets what money for what and when". E.g. you have changing insurance issues (i.e. OK, so this patient with this internal medical record saw Dr Foo in dept Bar, which we can internal cost accounted at $x, let's get this invoice for $y out to... (oh damnit, ok who is their health insurance company, let's ping the state's open exchange since this patient gave us their MassHealth ID number[or whatever appropriate exchange your state has if they opted to take the ACA federal funding] and see who their insurance provider is so we can bill this out). Single-payer would be a blessing in reducing complexity!
If you've ever wondered why some cities drop 12 million dollars on a new HR platform only to have it fail 18 months in, it's because information management is hard, regulatory reporting burdens are high, and transition costs (both the political stake the primary project manager who initiates the change-over, as well as the actual quantifiable monetary costs) are astronomical. ATC still uses software designed in the 70s where their web interface is literally screen-scraping IBM CISC software. It's horribly inefficent, but it's been battle-field tested.
You sir are absolutely spot on.
As for single-payer, well yes it does make a huge difference on the billing side which is often the biggest IT/tech user of an hospital. My canadian clients still have to worry about billing but they only have 1 insurance carrier to deal with and they know precisely how much everything will earn them upfront. Everyone else (tourists, out of region people, folks who let their healthcare ID lapse) pays cash at basically the same rates, thank you.
Fun fact, the oldest healthcare products like Meditech started from Billing and grew from there, it shows throughout the software still (and not just because they're written in MUMPS / InterSystems Caché). In Meditech results don't actually need a patient ID to be accepted (via electronic messaging/HL7), they need an account number so they can be billed on the right invoice. Nope the software will not figure out from the Order ID which account it goes to... Downstream systems are expected to keep those account numbers around and up to date, a patient might have 2-4 of them at the same time.
Now they got swallowed up by a regional medical system and have yet another EMR, plus they have 6 clerical staff versus 3 and whatever outsourcer handles IT for the hospital system.
My other doctor friend is a ophamologist. It's a small practice with 3 full time and 1 part time doctor. They pay the fine every year for not having an EMR and use paper and have a standalone system for sending prescriptions. He is enormously happy with paper and feels that's it better in every way, including cost. I agree -- I see zero value in the EMR systems.
Much of your post seems to be about bad tech, though. It could mostly be mitigated with a supplier that gave a shit.
Everything else is not only bad IT, but ruins your interactions because the medicinal person is bent over a laptop.
1. Once it's on your digital record--it's vunerable to hackers, or staff sending a patient's information off without their consent--with a tired swipe, or send key.
2. Once a doctor knows you have been on a potentially addictive drug, or had a problem in the past with addiction, or theses days; self medication, good luck trying to get relief from future pain.(pain=physical, and emotional.) About a year ago I went to a hospital with a case of shingles that looked twice as bad as those commercials on t.v. The staff looked at my record, and I could tell they were concerned about something. Yes--I'm on a low dose of a benzodiazepine. They didn't even bring up pain medication. I didn't even ask, but the pain was bad. Here's a script for 3 10mgs of predisone. I walked out of the emergency room with a prognosis of Anxiety on that stapled care instructions. I was so misserable, I didn't care. They mixed up my record with the guy next to my bed.
3. A compassionate/caring doctor will sometimes write things on paper they wouldn't on a electronic document. In the ninties, my long retired family doctor asked me if I tested positive for the AID's virus, he would put the results in sub-script writing only he would know. He was protecting me from being denied insurance.
4. I thought electronic medical records would be available for patients online. I don't know if patients can access them, nor care anymore. I'm so tired of the system, I just don't care much anymore.
As a physician and subspecialist I have invested 24+ years of education to achieve this title. Its degrading to our profession and patients to refer to us doctors as 'providers' and to patients as 'consumers'.
This takeover of healthcare by MBA-speak is one of the most irksome trends, and rebranding patients as "consumers" is a patently false equivalence.
They are notorious in the medical community for valuing efficiency above all else. Kaiser also doesn't serve extremely difficult cases, uninsured patients or patients on Medicaid. Academic hospitals do.
Kaiser can do a lot of things differently by virtue of being subsidized by the generosity of the state and the state's highly talented doctors. I don't know how much there is to learn from them.
> they make money every time you get sick
Nobody at an academic hospital makes money every time you get sick. Discharging patients is a high priority. Doctors are constantly trying to figure out how to do preventative care with the sorts of "frequent flyer" patients that tie up emergency rooms and hospital beds.
To be more blunt, you're not really describing reality. You're describing a particularly cynical point of view, common among people who are unlucky enough to be (or to know someone) rich, sick and not getting better. It's doctor as antagonist, and it tends to emerge in some kind of economic rationalization.
Here's reality: Mark Zuckerberg put his name on an academic hospital in San Francisco that has utterly dysfunctional EHR. Everyone in the system—especially the doctors, contrary to what you say—hates it and wishes the money would have been spent to improve it.
Even the tech fantasy of magic money wand can't solve this problem. It isn't the fault of doctors ("you know who hates EHRs the most? Doctors"). No clever turn of the phrase or insight is going to provide the answer. Blah-blah-blahing about incentives isn't going to provide any solutions. It's a complex system.
The original poster was saying as much. But then all the other commenters go on and start talking about economics, incentives, anecdotes, and assorted conspiracy theories. The guy is studying this! I think he's coming to the right answers.
> Nobody at an academic hospital makes money every time you get sick.
Of course they do! Every time you go in for treatment, they make money, and there only incentives for preventative care come from government/Medicare mandates (e.g. hospital readmissions, ACOs.)
Let me color the picture a bit more vividly. At a public pitch competition within the university, a department head--and judge of the competition--laughed at an ML start up: "you do realize we make money from the procedures you're trying to prevent."
> Discharging patients is a high priority.
Hospitals are often penalized for long stays by insurance.
> Doctors are constantly trying to figure out how to do preventative care with the sorts of "frequent flyer" patients that tie up emergency rooms and hospital beds.
Aside from tying up resources, high-utilizers can't afford to pay for services and the hospitals treat them at a massive loss. Naturally, a hospital would like to free up these resources for patients who can pay.
> It's doctor as antagonist.
I never said this, and nor do I believe this. Doctors are victims of this system. I even made the point that doctors hate the EHR because it's been warped by hospital administrators into a billing-centric machine with umpteen documentation requirements at every turn.
For this reason, many who went into medicine for altruistic reasons end up disenchanted with the health system that's been wrecked by those running the business.
I've also done migrations (I'm in radiology systems, PACS and RIS) where clients had reports going back to the early 1980s. Not very common mind you, especially in private practices (which we get a lot of) and rural hospitals (the kind of places with CPSI/Evident or, god forbid, Healthland.)
Just a few
1) Getting patients to pay their bills.
2) Spending less time on each patient.
3) Reducing errors.
All these have economic incentives. But yes it's still a hard sell.
Kaiser Permanente uses the same Epic EMR software as many other large provider organizations.
Also, don't forget that EHRs don't come with a data governance model, so the entire onus of maintaining clean, available, interoperable data falls on the institution. Again, since Kaiser depends on clean, available, interoperable data, they made that a priority both internally and in their contracts with Epic.
As for Kaiser adopting Epic, remember I noted that hospitals can customize the EHR to their needs in detail--it does however require troves of cash. Since Kaiser heavily relies on data-driven preventative care as part of their business model, they pay to have a lot of data systems in place to facilitate their operations. Hell, Kaiser even had an Open API since 2013!![0] Good luck finding that anywhere else!
I think we're in the turd-age (opposite of golden age) of EMRs right now. Everyone has adopted them—many unwillingly—but user interfaces are still terrible, and interoperability is spotty at best. There are signs of this changing (lots of vendors are touting/promising UX improvements, and FHIR is hot right now), but it will still take time.
You can write the absolute best EMR & PM (Practice Management) platform on the planet but if you can't get the payers to integrate with it you're dead in the water. The only practices who would even consider you without those integrations are ones not currently using an EMR, which means that your first hurdle with them has to be convincing them to go electronic - which means you own all the logistical hurdles associated with a large-scale chart-scanning operation, user training, mindset shifting, and much more.
And don't even get me started on the barriers to entry the Department of Health and Human Services have put in place....
I'm curious about these barriers you speak of - I'm based in New Zealand, and I must admit I haven't run into many government based barriers to entry - just barriers created by privatized companies.
Look at HIPAA. Originally about medical record portability, now it largely deals with security, privacy, and availability. These sound good, but it is frustratingly vague, subject to massive reactive fines, and assumes a lot of practices that always feel out of date. It's way more of a pain than private compliance frameworks like PCI.
The problems in US healthcare are complex, entrenched, and Brook no simple fix. The government is incredibly buearacratic, designed by lawyers who value an openness to interpretation by courts that creates ambiguity, and creates solutions in their own mold.
Could there be more room for improvements building from the ground up in alternative healthcare environments, like co-ops, hospitals where billing is in cash only and fees for standard procedures posted up-front, concierge, etc.? I don't think the mainstream US healthcare industry will change for the better unless it is presented with an immediate (<6 months), concrete, existential threat to its existence as we know it today. Considering how unfathomably unlikely that is, then substantive improvements in health outcomes could lay only "off the grid" of the current system.
Going down that path is absolutely more risky and less remunerative. Your post gives me the impression that while compensation ranks for you, I'm-On-A-Boat FU money at the expense of poor health outcomes for those you serve might not rank, so I thought I might throw out some outlier ideas and see what discussion falls out of that, if any.
To give an idea of how misaligned the US system is, this blog post [1] from my reading list today came up --- but to pick one at random out of a 3-second Google would be pretty easy --- describes how in the US a $5K MRI tab is not unusual. You can fly to NRT, pay in cash in Japan for an MRI and consult, fly back, about four times for that much. Cray cray.
a) nearly all states require that ownership in medical practice be restricted to those licensed to practice. This reduces access to capital, and more or less ensures that practices remain small businesses. b) nearly all care in the US is fragmented across specialists in different practices. c) healthcare in the US is largely paid for by parties fairly disinterested in actually transacting. While most folks on HN might A/B test UI improvements looking at click through rates, the implicit idea in insurance billing software is that submitting claims is someone else's expense to deal with.
When you look at places where there is a scale to medical practice, opportunity for software opens up. VA and DoD both operate and staff their own health care facilities, and have software systems they've implemented. But even DoD has problems receiving and retaining records from outside care providers (if Wikipedia is to be believed).
If there were fewer, larger medical practices in the US, it would both be easier to agree on standardized data sharing protocols, and more likely for patients to see multiple doctors working for the same employer, thus never necessitating a data transfer. Admittedly, it'd be harder entrepreneurs like yourself to break in. Perhaps you'd be an employee or Engineering manager working on the problem instead. Or perhaps you'd be selling a plugin to a larger EMR.
In my hometown alone, there's Kaiser Permanente, Sutter Health, and UC Davis. Sure, none of them are quite nationwide, but they're by no means "small", either.
KP is in the vein of what I'm suggesting though, just wish it was more widely available.
At this point, in the U.S., it is almost impossible for a newcomer to break into the market. There are many companies out there slowly losing market share to Epic or Cerner. Allscripts, Nextgen, McKesson/HBOC, GE, and others. Some are big, well-funded companies, others are more like startups with OK funding. Most of them are falling by the wayside, casualties to the bitter Epic/Cerner market war.
The HITECH act really exacerbated this point by accelerating spending on EMR's since 2008. Meaningful Use meant that a lot of homegrown systems had to be replaced, simply because hospitals couldn't keep up with the regulation and complaince. Likewise, smaller companies had to spend more money on compliance than adding features and also faded. Sure, there are plenty of Allscripts and HBOC customers out there, but their number is shrinking, not growing.
In a way it's a shame, because the two biggest vendors each have critical flaws. Cerner has a decent store in Oracle, but is hobbled by reliance on its own homegrown language for integration and middleware. The language is CCL and is like a cross between PL/SQL and TCL with HL7 Domain knowledge thrown in. Epic has an ancient store with Caché, which is really MUMPS with some OO and relational hooks tossed in. Cerner excels at customization, while Epic excels at disciplined project implementation. You can browbeat Cerner into giving you what you want, but you can implement Epic pretty much close to on time and close to budget with an impressive reliability.
Neither system really wants to interoperate with the other. It can be done, but it takes a months-long project with specialists writing HL7 interfaces to pass demographic, lab, and document data between each system. And this interoperability, once established, doesn't really help the patient. Docs can see orders entered in Cerner Powerchart displayed in Epic Hyperspace, but the patient doesn't necessarily get access to either the order or the result unless it goes to either system's portal.
Finally, you have to realize that you are dealing with a very powerful and conservative management culture. Many Silicon Valley startups with whizbang solutions have foundered when they run up against the entrenched incumbents. Well-funded companies with highly competent engineers have failed because they don't have the patience to spend a couple of decades building up a user base. Investors realize that they can get more bang for their buck elsewhere and leave the game. If you even want to make a dent, you have to be willing to spend at least 15 years and untold amounts of money just trying to take on the big guys. If you're going against a market with relatively short turnarounds, like a calendaring app or even a game console, you have a shot. If you're going against a market that is very conservative and waits at least a decade before reevaluating installed systems, you have a very tough row to hoe.
Ultimately, at least in the U.S., I think that implementing a new EMR is a sucker's game. You can spend millions and lose.
In New Zealand, the market is different at this point, but how long can they resist the network effects of the big vendors? Cerner and Epic are currently battling it out in Australia, and will exert pressure in NZ once that market is settled. I know for a fact that Cerner went after NZ in the late 90's but pulled back after it became clear that entrenched corruption in the NZ procurement system would determine the winner. I don't have names and places for you, but I was in Sydney at the time and remember the disappointment of the executive team when they realized that NZ at that point was not a genuinely open market.
You have mentioned in another post that you are concentrating just on records, and avoiding the extra complexity of the other systems in terms of patient management, practice management, supply management, etc… With all due respect, I think you are being naïve. A modern EMR system has to take into account the entire needs of the practice and how to manage it. When a health care practice is spending a buck, they want to get as much out of that dollar as possible. If vendor A is offering "just records", but vendor B is offering records plus practice management, they will go with vendor B. Every time.
In any case, I wish you the best of luck. I have a lot of experience in this sector and would be happy to share my knowledge with you.
Good point, here all hospitals use software from Orion Health, which is an NZ company - They have a really good hold on the market and I don't see that changing.
> You have mentioned in another post that you are concentrating just on records, … With all due respect, I think you are being naïve.
That thought has definitely crossed my mind. It's a tricky puzzle - part of the reason I think healthcare software is so hard, is that current systems are so monolithic - they do it all. To compete, you need to do it all as well. This impedes improvement, if you know how to build a fantastic appointment system, why should you have to also build invoicing systems? You have to bite off more than you can chew.
I don't really have an answer to this problem, but my approach is to break up the problem as much as possible into smaller parts.
Right now, that's quite niche and arguably the DICOM space is the most open part of Health IT, but perhaps that will eventually percolate up to EMRs. Maybe once FHIR catches on or whatever will replace FHIR. I'm frankly still using HL7 2.x and mostly 2.2/2.3 level features.
Has anybody tried to address the patient needs before?
Patients should be easier to convince. It could be a good strategy to influence the doctors and mangement to change their habits.
I'm thinking of a tool to allow the patient to enter data that they could give to their doctor.
Remember, the things we call EMR aren't primarily medical records, they are systems for sending the right codes to the billing systems
Why not gave-up at the beginning with data exchange. Make something that could help both the patients and the physicians.
For example, a mobile app could gather some data concerning the patient habits (with the gps, accelerometer...).
The idea is to create a need and make it mandatory (because very useful).
> Remember, the things we call EMR aren't primarily medical records, they are systems for sending the right codes to the billing systems
Yes. I'm looking for a way to change that. For example, with something more health-centric than money-centric.
Selling isn't particularly challenging either. There is a tried and true model for selling to medical practices and hospitals that works. Customer acquisition is expensive and resource intensive, but it's doable with the right team and right investment for any product.
There is risk, but HIPAA is a lot more of a risk than a logical failure. With every HIPAA violation, there are fingers pointing in every direction, and that means that resources are required to respond to everything - even when it's painfully obvious the software isn't at fault.
I would say that the biggest challenge to creating a market for a new EHR product is that there are generations of people resistant to any real user interface changes. I'm not even talking about adding tabs or checkboxes. If an EHR product logically maps to one of the legacy powerhouses like EPIC, it makes sense to people. If it logically maps to health care instead - No dice. People are entrenched in a system that was designed by engineers for health care because that's all that was available for a generation. They've gone to classes to learn how to work in that environment, they've worked in it for years, and it works for them. A major shift of any sort means retraining doctors, nurses, call center operators... anyone and everyone up and down the food chain. Even in a small practice that's a lot of time and energy to invest. There is resistance every step of the way.
A really nice and innovative example on EMR system development is the development of the Eye module released in OpenEMR's most recent version 5.0. A practicing ophthalmologist, Dr. Ray Magauran, decided to develop a ophthalmology module in OpenEMR with the goal of actually improving efficiency over paper (as a physician, I would confidently say I have never used an EMR that is faster than paper). What this physician/developer did was simply amazing and the details of this eye module(including the makings of it) can be found here: http://www.open-emr.org/wiki/index.php/Eye_Exam
What I think is innovative here is that this was designed, built, tested, and used by a practicing physician on the front lines.
Then on the flip side can also learn about the dichotomy of fulfilling regulations versus developing an innovative and efficient EMR system, which OpenEMR provides a ring side seat too since the road to complete meaningful use certification was done the open source way(ie. in full public view).
I think a lot could be solved if someone decided to build the healthcare version of Zapier.
You could not have had the government sponsor some new software which would eliminate a billion dollar software market.
It's a non-starter. All the hospitals already are signed on multi-year contracts with those large providers. Some of the EHR providers began writing medical software for hospitals in the 1960s and 1970s. These companies have multi-decade relationships with the hospitals they service, and decades of patient data stored.
What Obama and the Democrats did was to break the "paper cycle". Many hospitals used paper-only system with very little software even into the 2000's and 2010's.
The point of investing in each company was to jumpstart their products into meeting the huge new regulations, and the point of giving clients money to buy this new software was to break the paper cycle.
There is no "one size fits all" option in the American market.
I find it funny that you malign our practice as "(idiotic)" when it is your plan, quite frankly, which is so ignorant to the complicated history and reality of medical providers and their software, that seems idiotic to me.
Your opinion sounds to me like "The US Gov should, instead of using MS Windows, pay a company to invent a new operating system, then ban all use of Windows, OSX and Linux to ensure all firms must use the single new solution".
We already had so many options that have existed for decades, with so many clients, and so much built-out software infrastructure. There was no "one-size-fits-all" solution unless your solution includes "Destroy the entire industry, and use force of government to destroy a half dozen major software companies in favor of the government mandated and almost assuredly inferior option"
The crux you may not realize is how customized every major hospital system expects their EHR software to be. I don't think you realize the sheer level of customization these networks require, due to the size and scope of their businesses. It takes entire teams of my company to service certain major clients. The idea of a one-size-fits-all would have been laughed out of our country.
It seems as if to avoid dealing with hipaa regulation it's all paper, fax machine, and come pick up your x-rays burnt on a cd during your work hours (cd that you have to buy).
Having not grown in the states, this type of practices seems very primitive to me. Amongst many other aspects of the American healthcare, but that's another debate.
It also highlights how far the entrenched vendors and hospitals will go to keep their customers "locked in."
There was a completely open market, made of the majority of physicians, regardless of existing provider contracts with hospitals.
I know I talked to a few physicians (and other healthcare professionals) in the mid-2000s who lamented the paperwork they had to do every day and the lack of available computer automation.
There's a ton of slimy dealings going on sadly.
If you're a hospital with lab facilities, imaging facilities, surgical facilities etc. it's hugely useful to have medical records flow internally (quasi-)seamlessly. The EMR does that well, and the large cost of typing things into the EMR (it's slow, painful, annoying, never met a doc who preferred it to the old clipboard and notes system) is totally worth it.
For a small practice, that intercommunication problem isn't anywhere near as large, but the cost of typing things in painfully is the same. So small practices hate it.
And before you say, "but it's useful to share medical records between offices/specialists/hospitals when they move around", it turns out that a lot of these systems don't play very well with one another. Even between two healthcare systems that share the same software provider (in this case Epic, one of the big two, the other one is Cerner), I've heard people finding it easier to print it out, fax it over, and scan it back in. Yes there are people who want to solve that problem, (see YC's own https://www.patientbank.us), but it's a tough area because who pays for the service? How expensive is it to build software that interacts with all the 10 zillion different flavors of Epic? How do you harmonize the peculiarities in how people actually record the data in those systems? It's really really hard.
You can add an additional layer of warning in Epic. I see this most often with psych records or pts who want an extra layer, such as if they work in the same hospital. All this entails though is an extra prompt warning requiring you to put in a reason why you are accessing the records, and put in your usr/pwd again and warns you it is being recorded, etc...
Say I am working a night where I may be paged on 100 patients who I am meeting for the first time. Just opening their records on The EMR eats a significant amount of time. Time which I need to take care of people. Adding an additional click would mean even less time and poorer outcomes.
You also have to realize that nobody is going to carry a USB. I have worked in diabetes clinics where most pts don't remember to bring in their glucometer, which is the entire point of the clinic. You have to realize that the patient population also includes the average American (and half by definition are below average intelligence.)
I mean, I could go on for hours and make my own personal list of the issues with American Healthcare and I wouldn't list pt privacy in the first 100....
Not trying to be dismissive but I'm just trying to give you computer technical folk an idea of why EMR is such a hard field and how many factors you have to consider which is really difficult if you aren't 'in' the system. Even I who knows more about programming than 99% of docs feel completely ignorant when I talk to healthcare IT folks about HL7, etc...
I don't think the challenges you mention are unsurmountable-
An ER doctor seeing 100 patients a night might have the system setup to automatically log in as an emergency, and they already need to log the reason for the appointment- or else there is no there is no record of it...
Setting up the initial access should be handled by staff during check-in for non-emergency visits.
Patients are generally already expected to carry a health insurance card (at least in the US- not sure how that is handled in countries with Government provided health-care). As the system becomes more widespread, it would become normal for everyone to have a security token, and they could use those tokens for access to multiple systems, not just health care (The USB disk thing is probably optional, just a slight improvement for when the network is down or you can't otherwise access the information).
I also think the User Experience on the systems I have seen could be greatly improved to reduce unnecessary clicks- and I have noticed that more often then not though- loading information over a slow network takes more time than navigating the GUI.
I would agree that the problems with health care go far beyond EMR systems, but they were the topic of the discussion.
Thanks for participating, I want to better understand all of the issues and these types of discussions help a lot toward that goal.
You are right there are those who do not seek care because of privacy, but in my experience they are by far a minority compared to the people who don't get healthcare because there aren't enough providers to get an appointment (mostly because they are all already too busy and overwhelmed to take on new patients), are worried about cost, or who just are in denial about how sick they are.
The deal with insurance cards though is that there is no problem or issue if you don't remember to carry it. Registration can still be done, they just look you up by name, address, or SS# if needed. Not to belabor the point (because as you mention you could use a network) but any system that depends on people carrying something will have a lot of caveats.
No matter what you pick it will sometimes not work, the network will be down, the USB flash memory will no longer work, the USB port will be broken, etc... so there will have to be a non-emergency allowance for 'token' system not working. How are you going to verify it really isn't working and that people aren't just clicking 'not working' because it is easier (or because they are malicious and lying to steal data...).
With regards to automatically logging people in: Consider your ER doctor system, ok that works when it is logged as an emergency in the ER. Now consider my role. I am a hospitalist, meaning I admit patients to the hospital and take care of the ones already admitted. Should I already be covered under the emergency since they are sick enough to be in the hospital or do I have to go through additional steps to log in to address a patient who just needs some extra nausea or pain medications or a sleeping pill? If I have to log in it detracts from the time I can spend dealing with a patient who suddenly has a more pressing issue (such as new chest pain that needs to be seen)? Of course, I am going to see the chest pain patient and so the nauseated patient is miserable for a few extra minutes. Now this sounds like squabbling over a loss of seconds but in reality managing an inpatient service is juggling multiple pages at once for sometimes several hours straight on many patients, triaging what needs to be done urgently vs later, and admitting patients, etc... It can be nonstop. So just one additional step really does add up.
So you can then say, why not have it set up that once a patient is admitted, they get logged in once and then you don't have to worry. I would then answer that that is basically what we do now. When you get admitted to the hospital you sign a release which covers this.
I will bring up another issue: you say a new provider should only have to log in once. Do you really want a provider you saw maybe 5 years ago for a one time visit have access to your records. How long until they have to reregister?
Another issue: What if you have tests done that aren't resulted by the time you leave the hospital. For example you have a blood culture that becomes positive after 5 days which means you need to be notified to get new labs done. The doctors that took care of you are off shift or on vacation. Usually this is taken care of by another provider, who you may never meet, are they going to be covered under the token system?
Out of curiosity what is your background in this since you mention User Experience?
The crux that you may not realize is that this customization was done mostly to boost profits and promote vendor lock-in. This was aided by the .gov failing to make public and standardized requirements for things like medical records (and no, referring to an AAMI or whatever doc that costs serious coin to view doesn't count!).
> . There was no "one-size-fits-all" solution unless your solution includes "Destroy the entire industry, and use force of government to destroy a half dozen major software companies in favor of the government mandated and almost assuredly inferior option"
BULLSHIT. Epic is built on MUMPS, arguably one of the worst languages ever designed. Hyperspace is garbage. Their systems are garbage. They get by because they've attached like gigantic leeches to hospitals. Cerner, Allscripts, and others aren't much better.
> Many hospitals used paper-only system with very little software even into the 2000's and 2010's.
Feature not bug--notice how much more physicians and nurses seemed to like those systems.
~
Look, your entire industry is fucking cancer and the sooner the .gov decides to use truly open standards the sooner some hungry companies can clean out all the garbage you and others have managed to clog institutions with. You should be ashamed.
That doesn't change the fact that the software surrounding the entire medical industry is largely ridiculous legacy crap maintained by a little cartel of fat & lazy vendors with a captive market.
With good reason btw... these systems were the earliest big data processing shops. Blue Cross and Medicare was doing centralized billing for healthcare since before fax machines were popular.
But the fact is that these ancient systems are nightmarish to work with, and because they are so ancient, they predate many of the standards and capabilities that modern systems have.
I spent a decade working around a big legacy system originally built on a Sperry mainframe in the mid 70s. The system was awesome in some ways -- amazingly performant, efficient and well tuned. But the reason it was so awesome was it's downside as well... it is almost static, changes are difficult/impossible to make. In the EMR space, things have to change, but because it uses an ancient/domain specific set of artifacts, you're stuck with a small number of incumbent vendors with whatever functionality they are willing to do.
To quote the great Henry Ford: "Any customer can have a car painted any color that he wants so long as it is black."
They've empowered the clients to keep doing stupid things because it's good for business.
Allscripts is a dumpster fire. I'm quitting my job that deals with them in the next 6 months and traveling.
Most of the EMRs established lock-ins when interface design was still pretty primitive compared to today: before WPF, C#, decent browsers, and javascript libraries. This sucks because we have to deal with extremely verbose code in laying things out. Meanwhile, modern web and desktop design has skyrocketed ahead of these old beasts, so they look extremely dated when we'll soon have a new generation of med students walking in who have grown up with mobile phones, tablets, Chrome, FireFox, IE11, and Win 7 and their beautiful interfaces and design by comparison.
Additionally, it would open the door for EHR-based research on a massive scale. Getting different hospitals' EMRs to play nice with one another is a huge barrier for large, retrospective cohort studies. Projects like the Million Veteran Program (http://www.research.va.gov/mvp/) would be just the beginning.
By "system that can be standardized", do you mean, e.g., defining standard data content, representation, and interchange formats and perhaps funding one or more open source implementations, or creating and mandating a single mandatory software system?
This is misinformation. Interoperability via HL7 messages has roots in the 80s. The subsidies encouraging provider adoption of EMRs during Obama's administration set constraints on qualifying EMRs including a certain level of support for interoperability. The government sensibly leveraged existing standards produced by those free market forces you decry.
HL7 is literally just a syntax, and one that isn't reliably followed at that. It makes no solid guarantees about the semantic structure of the messages, and so is next to worthless.
For a simple analogy, consider that two companies have agreed to write contracts in English--and little else.
Alternative methods for passing data between organizations have been proposed, but the vendors as well as the hospitals have been fighting this tooth and nail. The big EMR vendors are dragging their feet (and cashing government checks) but hospitals aren't pushing for this functionality either. IMHO, hospitals also would prefer to keep patient data to themselves.
What we need are government standards for data at rest, similar to DICOM, for other data - and tied to Medicare reimbursement. Literally some functionary at CMS could write that rule and patients would be better off.
"some configuration work is usually needed on each interface" is the key phrase in your response. Just because many organizations have poured cash into yours and your competitors' solutions when the economic stars align does not mean that message passing between organizations is a solved problem.
That said, in my opinion the two organizations looking to exchange messages would need to have a pretty good relationship and a real business need in order to pursue this strategy. They may also have to compromise on dictionary values, etc., in order to have comprehensible data on both sides. For organizations with even a modest amount of rivalry, I can't see them spending this kind of time, effort and money.
My understanding was that "meaningful use" would make interop much easier, perhaps on a higher level than HL7 messages. In my experience this has not been the case.
Not really a libertarian myself, but were I to pretend for a moment that I was, I'd say that this statement of yours could not possibly be less accurate, and that federal interference of this sort is the precise, diametrical antithesis of what is meant by the phrase "free market".
He suggested following that up with what I believe to be an Upton Sinclair quote, but I'd rather eat my supper than participate in an argument over Mises and Rothbard, so I think it's time I snapshot and terminate the running instance.
Most other countries don't have universal EMRs, and the ones who do aren't necessarily happy with them. One size doesn't fit all.
If the market ever opens up and consumers have more choice, its clear that someone like google or MS would win and I honestly believe really give healthcare a boost in this country.
They have analytics, "moneyball" so to speak. There is a plethora of untapped data in these systems. I've worked with Gesinger in PA and you would not believe how far behind the curve they are and they are often touted to be on the forefront.
What needs to happen is getting google or MS into health insurance. They could utilize all the data collected to benefit the patients and make a big profit. Additionally, they have the know how to set up a pharm lab for drug development. Insurance companies really should drive drug development. It makes sense for them to develop drugs for conditions costing them the most amount of money per patient. Instead, they are middle men who have to work with whatever big pharma give them.
Payers have no interest in driving drug development. It wouldn't give them any competitive advantage. It's not like they could restrict sales of a new drug to only their own members! And most payers are providing very little "insurance" now anyway. Mostly they just process claims on behalf of self-insured group buyers.
And the notion of those companies getting into medical insurance or drug development is just ludicrous. Their corporate boards would laugh the idea out of the room.
I work with the Geisinger health system at a major US University doing analytics work for them. They are far ahead of most other systems and they are woefully behind.
Even without barriers to competition, there's no consolidated EMR format or a software market with many competing players, what makes you think that opening it up nationally would revitalize the market?
http://www.modernhealthcare.com/article/20161010/NEWS/161019...
https://www.forbes.com/sites/brucejapsen/2016/10/10/sorry-tr...
They did try actually
I think Microsoft HealthVault was more of what you describe, where it's a portal intended to be used by patients.
So the hospital is willing to shell out a ton of cash so that they have a Very Secure system that helps them better manage their cash flow. If you walk in as a doc with (for example) a nifty phone app that lets you track your patients in real time, you'll confront 2 problems: 1.) the hospital won't let you connect because it'll assume (possibly incorrectly) that it's a huge security hole. 2.) even if they did let you connect, their EMR is non-standard (basically all of them end up non-standard) and there's no lingua franca protocol for medical data, so your app is incompatible.
It's really really tricky to solve all those issues AND have it be cheap enough for a doc to be willing to shell out for it out of pocket. I personally you'd need that kind of consumer-side scale to get enough competition to get medical software to innovate more quickly. I will say a common interchange format would help a lot, that's one of the objectives FHIR had, and the industry has been slowly adopting it.
You accurately point out revenue personnel and practice managers as key players here, and yes they're the ones that usually push EMRs etc. But the front line workers are kind of disconnected from the design and functionality of the EMR.
Put another way you have software that's bought by one person (hospital/provider), it's used to collect data by a totally different person with different needs (docs/nurses), and it's paid for eventually by another person who has no idea how it works nor any direct pressing need for it (patient/but let's be real, insurance company/government).
Without a tight connection between who pays for the software, who uses the software and who benefits from the software (most consumer software is a pretty tight loop), it's hard to have a good virtuous cycle of innovation coming from customer/user insight/observation/needs.
We have front line personnel complaining to us all the time that the EMR is slow and unwieldy and suggest features to bypass the features that the EMR has built. These are applications that block the UI thread for nearly every database or long-running call, a veritable sin these days.
Most apps would come from people who have worked directly with the EMRs before, so it's rare to have one thing that talks to all of them but not impossible. If there is a perfect example of institutional knowledge, EMRs would be it. As a developer, you'd be focusing your marketing on people who already have that solution and position it as an addon. Independent products are difficult to do because interop barely exists and that interop standards that do (like HL7) have very little constraints or an escape hatch to add whatever you like.
The reason you have to take this parasitic marketing stance is due to the massive effect that EMRs have on every day workflow. Many decisions for buying software are made in light of how it works with the EMR if it's relevant to patient care. EMR choice is akin to operating system choice for the hospital or practice.
And there could well be a tight connection between the front line workers and the EMR developers, but it wouldn't matter because long-term contracts prevent any threat of either side losing their jobs soon.
Healthcare information tech sucks because it's innately more difficult than most other problem spaces
This will benefit both doctors and patients, as they no longer need to manually juggle between countless different systems (and plain old paperfiles). Overmedication (and dangerous drug interactions) has been a real problem for decades, because one doctor does not know what the other has been doing. When a patient has to visit different hospitals, they have to take new blood samples, tests etc.
Patients can now log in to one service (helsenorge.no), with the same security as other state-run services (taxes etc), they get access to their complete health journal, they can order an appointment at their local doctors office, order an online consultation, reorder prescriptions etc.
Maybe something for other countries to learn from?
(This is a safe bet, of course. The giants of the field, Epic and Cerner, are infamous for overwork, low pay, and high turnover. Their technology's also obsolete: Epic has a VB6 front end and MUMPS back end; Cerner uses C++, but it's probably C++ thinly translated from C thinly translated from Pascal, so they're not a whole lot better. At least MUMPS isn't vulnerable to C-style buffer overflow attacks!)
Unfortunately, this experience, supporting obsolete, spaghetti-code-nightmare, opened my eyes to the world that business is done in a much dirtier way than how I imagined growing up.
The closest thing I have found is http://mymedicalapp.com/ but it appears to have been abandoned by the developer.
I think these tools would be even better if they released their code under LGPL (instead of GPL) so that lazy commercial EHR developers would reuse and help maintain some core modules to promote more interoperability.
I don't think it's going to ever be possible (or that it is even desirable) to ever have a "Universal EHR" that everyone is forced to use through either government intervention or through market/economic forces. We can all exchange emails with each other, but we aren't all forced to use the same email client
The reason that the entire healthcare system seems broken to most consumers is legacy EHR systems in large hospitals. These legacy enterprise vendors are essentially what Oracle was 20 years ago in the rest of the enterprise software market before companies like Salesforce.com came along. Another part of this "broken" feeling is the difficulty of exchanging data between different EHR systems; but this doesn't have to be the case.
"If you've seen one HL7 standard implementation, you have seen exactly one HL7 standard implementation." Which means most systems don't interoperates with anyone else's systems unless there is an existing commercial relationship that forced everyone to interoperate on a local scale.
For anyone looking to work on an idea to improve healthcare check out: https://www.drchrono.com/api/ and/or https://www.drchrono.com/careers/
https://app.drchrono.com/ehr-emr/medical-form-templates/5561...
looks like it got a major facelift since the last time I checked it out. that must of been a lot of work. congrats to the contributors for making that happen, looks more modern.
There has also been a ton of incentive payments from CMS that have almost exceeded the EHR industry as a whole.
There have also been quite a few big switches from the 90s to today, a bunch of them from Meditech/Epic/Cerner to others, so it can definitely happen.
Something like this is huge, especially to potential competitors that now have a target to aim for.
I run OpenDental for my wife's practice in North Beach, SF. It's licensed as AGPL, but I'll still take it :)
HN becomes smaller each day :)
It's been pretty easy to run, no complaints other than the usual MySQL ones.
There is talk between myself and a couple of other contributors to move the site and wiki to AWS :).
Feel free to volunteer to speed this up, of course.
EDIT: Misread your comment. We are hosting downloads on the SF site. Really need to move to AWS...
I use picnichealth.com to deal with this EMR mess and I love it!
That said, working in this industry, I know exactly how hard it is to do this right. In many ways this is what it costs to do the job, if not more, but I'm not sure I'd pay it. There's the tragedy of the whole EMR/patient data story: bloody expensive, who pays?
EDIT: I have also used this in conjunction with healthtap. EXTREMELY USEFUL! Doctors love it!
OSCAR
OpenEMR is 100% open source. It's GPL'ed :).
As far as compliance, we are happy to inform you that OpenEMR is now 2014 ONC Ambulatory EHR Certification complete.
EDIT: If you're asking about support, there are over 30 professional vendors. Community support is also available.
If you have further questions, feel free to reach out to my email (in my profile).
But then I saw this: http://www.open-emr.org/wiki/index.php/FAQ#What_is_ImageMagi...
And then this: http://www.open-emr.org/wiki/index.php/FAQ#What_are_the_corr...
..... http://www.open-emr.org/wiki/index.php/FAQ#What_do_I_do_if_I... http://www.open-emr.org/wiki/index.php/FAQ#What_is_OpenEMR.2...
God help us all.
Note there has not been a default password for about 5 years, and will update the FAQ.
Regarding the other FAQ links you posted, what specific security issues are there with those?
To get an idea of OpenEMR's security, recommend checking out the following section on the wiki(1 of those links has several 3rd party security audits): http://www.open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Pag...
"clinical:meteor is an open-source project creating a next-gen framework for building healthcare apps".
I actually suspect it violated several laws - I remember I had full access to a database stored offshore where patient notes were there in plain text, along with their names and addresses. I emailed the privacy commission about it but they wanted to me to name names and I was scared of losing my job.
So yeah, I hope you encrypt notes.
But seeing hierarchical menus just made me close the tab immediately. There are others, much more human-approachable, UI paradigmas.
If we want to push meaningful software to the non-tech-savvy people to make their lives better, we have to start letting go of ancient UX methodologies.
Obviously this cannot replace all menus but hey, it's a start.
Please note: I am not an UX expert. It's just what I subjectively find as a common-sensical approach.
As far as safety, openEMR is fully HIPPA compliant as well as 2014 ONC Complete Ambulatory EHR certified (a/k/a Meaningful Use 2).