I'm currently working on my thesis, I'm trying to design a radically different take on EMR/EHR systems - http://barnett.surge.sh/
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.
As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly. Remember, the digital transformation didn't occur until the HITECH act in 2009, which mandated the use of electronic health records. Why digitize your operations and worry about maintaining tech infrastructure when you can do everything on paper with a handful of secretaries? You could argue providing better data-driven healthcare to patients, but guess what--most health systems don't care because they make money every time you get sick.[0]
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.
> As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly
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.
I have no idea what the market is like in New Zealand, so my insights there are limited, but a lot of EMR systems in the US have a similar notion of customizability built into the interface. Epic, the largest EHR vendor in the US, for example, doesn't sell a one size fits all solution. Hospitals develop their own GUIs and workflows within Epic, but again, hospital administrators make all the UX/UI decisions while optimizing for documentation that bolsters billing. Again, the doctors lose.
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.
The reason why so many EHRs are poorly designed is in part because they are so flexible. Don't under estimate the ego of a physician to think their way is superior to the way the doctor down the road does something.
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.
SQL has 'interoperability' re: an ANSI standard. Theoretically you should be able to get off all those old Oracle contracts right? Eventually there are little nuanced things that users end up building their workflow completely around. Even if you change no functionality and just slightly alter the GUI, you're going to have complaints that something is broken. Inertia is your #1 vendor lock in feature. EPIC is as golden as Oracle just due to resident incumbency.
#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).
While I strongly agree with points 2 and 3, SQL standards are useless when hospitals invent their own schemas and data governance. Looking for serum creatinine? Good luck without local knowledge. There are probably 30 tables (not exaggerating) for that lab, and the closest you can get without chasing 7 people for info is grepping all the table names for "/CREA/".*
You don't seem to understand the market dynamics. Consumer preferences have little or no impact on provider EHR selection. In general the only consumers who really care about controlling their own data are those with complex, long-term chronic medical conditions who see providers from multiple different organizations. Otherwise most patients are satisfied using the captive PHRs tied into individual provider organization EHRs. Real world patients aren't going to switch providers over issues like this.
Actually quite the contrary. I work in this space everyday.
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.
Oh man, this is so insanely true, allow me to just contextualize this for you with a POV from the States.
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.
I work in healthcare integration. I have interfaced with EPIC and Cerner and pretty much all the other main EHR platforms and seen my clients struggle with their IT.
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.
I don't see why any physician implements an EMR. My family doctor, who was part of a midsize practice was punished hard by adopting a system. They did it in 2007 thinking they would save money... which didn't happen as they were only able to eliminate 1/4 clerk positions and had to pick up an IT guy and a consultant. Then they really got the shaft when the solution they chose wasn't meeting Medicare guidelines. They ended up getting another system that is worse.
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.
I saw one system that seemed like a must have: apps that ensure you got the prescription right. Paper-loving doctors screwing up prescriptions harms a lot of patients. Especially when they insist on writing in cursive.
Much of your post seems to be about bad tech, though. It could mostly be mitigated with a supplier that gave a shit.
I'm not going that far. What I read implied it was either a mental slip or illegible writing. Some of the drug names look similar when they're written in chicken scratch.
I'm just a patient, but I see the advantage to paper.
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.
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.
I work at an academic hospital, and I've seen how the incentives drive policy. Frankly, it's terrifying.
> 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.
It's no longer necessarily true that providers make money every time you get sick. Insurers have shifted risk to providers in some areas in the form of accountable care organizations (ACOs) which receive a flat fee per patient. So in theory the ACOs have a financial incentive to prevent you from getting sick.
Kaiser Permanente uses the same Epic EMR software as many other large provider organizations.
And I have seen shifts that ACOs have caused first hand! Unfortunately, the only insurer running ACOs is Medicare which is an example of a political solution to the problem. While we have yet to see what the financial implications of ACOs are, I can say that I've seen admins work hard to develop data-oriented preventative care. However, these advances are still only limited to the ACO population, which gets back to my point. Hospitals aren't going to fund patient risk analysis until the economic incentives are in place, and for that reason, I fear that the issue of bad interoperability will exist for as long as we live in a "fee-for-service" world.
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!
Kaiser was, however, one the first systems to start (2000) and finish (2010) their electronic transition. Their decision had nothing to do with the government mandate in 2009, precisely because their business depended on it.
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.
There is absolutely an incentive for healthcare systems to do these transformations. But it requires leadership that is willing and able to see the long-term benefits. Of course, that can be challenging, and is probably only feasible in larger nonprofits (for-profits need to please shareholders, and smaller organizations simply can't afford it), but the future payoff is there.
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.
When patients are treated as consumers we'll see the wave of economic incentives. Value based care as part of the ACA is headed in the right direction.
I can assure you, that no patient is a willing "customer" or "consumer" of healthcare. True 'consumers' or 'customers' have a choice to buy something or not. If you are a sick patient, there is no choice.
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.
Um, what? I've spent 20 years implementing EHRs. You seem to be implying that hospitals were using paper until 2009. I've implemented lab systems with electronic charts in VMS. The systems weren't, and aren't, interoperable, but they were definitely recognizable as EMRs.
He's probably limiting the definition to the kind of overarching EMR that fully replaces paper charts for all departments and provide a single view of the patients.
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.)
I strongly suspect that for the US healthcare system setting you are talking about, the incentives are misaligned for building a better EMR/EHR system. What we endure today satisfies those who profit mightily from it just fine, and improvements in health outcomes represent profit erosion, hence no true incentives to truly improve.
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.
Just to be clear, I'm actually designing this system with New Zealand in mind, which has a very socialised healthcare system. I've got no idea how to help the american healthcare system
So my startup hosts and supports a decent number of EHR/EMR solutions and I even seriously entered talks at one point for us to partner up with a large medical conglomerate to write a new platform. That idea died for the same two reasons most similar initiatives in healthcare die: Government and Insurance (called "Payers" in the healthcare industry).
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....
Interesting. I think there's a real argument that an integration platform for healthcare should be a government run entity - ensuring that all parties have a chance.
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.
I work in healthcare. A lot of the complexity is FROM government attempts to help.
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.
There's also some structural reasons. Why is it that larger practices don't write their own software? Well, maybe a few do, but:
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 observation, I've found that there are quite a few larger healthcare providers, and that even the "smaller" hospitals are pretty big in terms of IT needs.
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.
Part of the challenge is that hospitals represent only one portion of the care chain. My mom's GP, for instance, has never used a hospital as their office. There are dozens of hospitals within 30 minutes driving distance, of which few are owned by the same company / non-profit.
KP is in the vein of what I'm suggesting though, just wish it was more widely available.
The combination of OpenEMR being open source, open community, volunteer driven, physician driven and getting significant use in the real world makes it a perfect vehicle to glean really useful insights into EMR use and I highly recommend looking into it in your research endeavors. For example, in subjects such as EMR system development and the effects of regulation.
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).
Yes, thats the main focus of the project. One of my critiques of healthcare systems is they do wayyy to much. Eg a practice management system (pms), handles appointments, records, invoicing, staff management, inventory, decision support - so much stuff.
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
Most if not all health care systems are implementing FHIR as a layer over HL7. Most of those systems don't have people really conversant with web technologies. Interoperability is, I think, a mirage built on top of already overworked integration staffs.
Have you considered, in your model, how your system would work if a customer wanted to integrate with, as an example, a machine learning platform that attempts to predict the likelihood of a patient's readmission given their current status?
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.
So, if I want to run an daily analysis of every record in your system, does that processing happen on your system, or do you somehow replicate the data to me?
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?
It's a self hosted system - so you as an institution have a copy of all of your patients records on your own servers, which you control. So analyse away.
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
Double bonus for this, we've been working with FHIR at Lumiata and it's quite good for certain things. Difficulty is that most EMRs as is work with tabular databases, and FHIR isn't quite organized that way. It does require some work to translate the tables people usually have into that format.
Lumiata looks super interesting. Ps your https is expired?
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?
Above all we want a data format that's consistent.
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
EHR is not difficult. There's a lot to the required data model, but building a working system doesn't require mental gymnastics, just time and effort.
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.
The EMR market is consolidating on two big vendors: Epic and Cerner. Depending on how you measure it (Hospitals on a system or Medical Records under management), either Cerner or Epic is #1 and the other is #2.
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.
> In New Zealand, the market is different at this point, but how long can they resist the network effects of the big vendors?
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.
It's kind of funny cause I'm in the imaging side and there's a buzz now about "deconstructed PACS" where centers will mix and match different vendors to provide radiologist workflow, image storage, DMWL worklist, Diagnostics Viewer, VR, distribution and analytics.
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.
It wouldn't help. Very few patients actually care about this stuff. When patients go in to see their doctors they aren't going to waste time discussing software.
lots of people are working on the patient-centric record. No one has cracked the cultural problem and the integration problems. You would be requiring docs to re-enter most of the information in their own system.
Remember, the things we call EMR aren't primarily medical records, they are systems for sending the right codes to the billing systems
As other comments mention, this project has been going for a while, the central reason it (or something like it) has not been robustly built out and deployed universally is because of the way congress chose to structure the funding for development of EMRs/EHRs. Rather than trying to find a system that could be universalized, the (idiotic) plan has been to give millions of dollars to multiple corporations to develop systems, then subsidize the purchase cost to providers to encourage adoption. Then, only once everyone has invested in their own proprietary system will they begin trying to universalize the system by developing cross compatibility. This methodology is perfectly in line with the free-market approach that the US has championed for decades. It is also the opposite of how almost every other country has developed and adopted universal EMRs. Sad. Especially because we know that a good, affordable universal EMR would significantly enhance the ability to deliver care for almost all sizes of healthcare providers.
As a programmer for an American EHR firm -- all of the market share already belongs to one of those companies you malign.
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.
But most physicians don't work for hospitals. They work at small practices with 10 physicians or fewer (according to the AMA).
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.
The issue with small practices and even slightly larger physician's groups is that an EMR is often just a cost, with very little benefit.
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.
So I am a physician with a large hospital system that uses Epic. I think your comments about poor communication (btw Epic systems) are outdated. For the last two years when I admit a patient I can easily access all Epic records not only in other hospitals in my state, but in the country through their system labeled "CareEverywhere". It is a game changer and is really the main reason why I rank Epic above other EMRs I've used.
It is primarily through deterrence. Anyone allowed to use an EMR must go through training about HIPAA rules. A waiver is sometimes required that Epic asks you to print out and sign and put in the patient's chart (although they obviously can't prove you did this, it would be an issue if there was a problem later and it turns out you didn't do this, i.e. You would be liable for whatever penalties/prosecution). Furthermore, all usage is recorded and occasionally audited in my system. I'm not 100% sure the auditing is a requirement and true everywhere (definitely with any hospital or large clinic it will be).
Also, in reply to who is accessing your records you don't know. I suppose you could ask for records of who had accessed it by a certain date, but once your records are in there they will likely be accessed by your insurance company for billing purposes.
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...
Thanks- ideally the auditing would be done regularly, and require a reason to be entered for any access the first time a new provider accesses your information. Even better each patient would have a USB stick with a One Time Token generator that would 1) hold basic emergency information on the USB drive) 2) Generate One Time Keys to grant access to new providers. Of course, in an emergency situation where a provider has an ID but can't find your USB key, they could enter an over-ride with a reason- which would be strictly audited. Also, patients should have a list of who has accessed their information and why- and even be able to sign up for alerts anytime someone new accesses it.
So I think your ideas are good, but you have to realize the multiple competing priorities in healthcare. When you say ideally, you mean from a privacy standpoint. In my opinion "best health outcome of the patient" should be the highest ideal.
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 see your points- I agree that "best health outcome of the patient" is the priority. I don't think that is always at the cost of privacy, though. In fact, if people feel more secure about the privacy of their information, they will be more likely to be open and to even visit a health care provider in the first place. (Some people may not care either way, but there are those who do- and certain circumstances that people are more likely to care about than others).
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.
I agree that the challenges aren't unsurmountable, but we have to make sure that we realize everything we change has unintended and unforeseen consequences, even things that seem as simple as adding an additional click or checkmark.
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?
That is great for other accesing records from other hospitals that use Epic, but what happens if you want to access the records of a patient who also visits a VA or Cerner hospital? You are still in the dark.
Absolutely, I still have to fax and it's ridiculous how low the bar is. I was just replying to the op that just the fact that Epic can talk to itself at other hospitals (for the record the VA can do this too, but it is slow) makes it relatively great.
What I see happening is that eventually there will be so much merging of our healthcare systems in the next 10 years that there will eventually be a point where there are only several "players" in any area meaning that the problem of intercommunication becomes much simpler (i.e. Epic, Cerner, and Medtronic).
Unfortunately with the consolidation into medical "groups" that has been going on among doctors and with the hospitals offering "deals" along side those vendors they use for the doctors to adopt them, a lot of doctor's groups have adopted whatever system they are most integrated with's EHR.
The small medical practices are rapidly disappearing. Providers are consolidating in order to have more negotiating power with payers (insurance companies), and the payers and in turn consolidating to have more negotiating power against providers, and so on.
Not entirely related, but the pain of the "paper cycle" as a "customer" of health-care is real.
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.
I am actually not opposed to the "CD you have to buy" policy. If I was hospital network admin I would not want people just plugging in random usb sticks into my network.
I think the expectation is that these organizations should be able to send this data to each other. That they was put the data on a disk and then give that to a patient who the drives it over to another part of town and hands the disk over is a ridiculous waste of everyone's time.
It also highlights how far the entrenched vendors and hospitals will go to keep their customers "locked in."
And in most cases they can send that data to each other, at least in the sense that their existing systems are capable of interoperating based on open standards. But to make it work the provider organizations often have to configure and test data interfaces with other organizations. That's an expensive process and no one wants to pay for it.
> The crux you may not realize is how customized every major hospital system expects their EHR software to be.
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.
>Cerner, Allscripts, and others aren't much better.
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.
That's simply false. Hospitals and other large provider organizations often do insist on extensive customization and non-standard configuration during EHR implementations. I've seen it happen. They'll spend weeks going around in circles about ridiculous issues like the placement of a logo and the format of a lab result document. You really can't blame the vendors for that.
All enterprise customers are stupid about COTS customization.
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.
Labeling something as "legacy" is a lame basis for criticism. Customers don't care about the age of a product's code base. What matters is price, functionality, and support. If you want a non-legacy EMR just for the sake of novelty then there are plenty of options available. But they aren't necessarily any better.
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.
>Rather than trying to find a system that could be universalized, the (idiotic) plan has been to give millions of dollars to multiple corporations to develop systems, then subsidize the purchase cost to providers to encourage adoption. Then, only once everyone has invested in their own proprietary system will they begin trying to universalize the system by developing cross compatibility.
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.
I don't think we will ever see HL7 messages exchanged between organizations. Each product has it's own list of message types that they support, and even then they will vary in terms of which segments have data and in some cases, even what that data will be. Patient identifiers also vary between organizations, making it hard to know which patient goes with which piece of data.
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.
I work at a top 10 EMR on the interface engine team. Messages between products require a lot of custom work to align message types and IDs, establishing a compendium of identifiers for external labs and identifiers, but it's not uncommon.
Yeah, but I can't take my data from Epic and move it all into Cerner via HL7, no matter what.
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.
You haven't been paying attention. I've been working on products which exchange HL7 messages between organizations for 20 years. It's very common now. Some configuration work is usually needed on each interface but that's mostly a solved problem.
I think he likely meant "I don't think we will ever see HL7 messages exchanged between organizations [routinely and with little effort]."
"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.
My experience has been closer to that of
mcphilip, every time we bring in a new system we end up with consultants from both sides (the new product and the hospital information system) and the cost is quite high. Where I work, exchanging HL7 messages directly with another organization has never been on the table and we have done a couple interop projects with other area hospitals.
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.
My experience is that "some configuration" translates to 6 months and 50k$. Especially when the really big vendors are involved and when those vendors have competing products.
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.
>affordable universal EMR would significantly enhance the ability to deliver care for almost all sizes of healthcare providers.
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.
I work in this space in the private sector. From my perspective, the greatest impediment in the U.S. relates to our laws regarding PHI. I work on a system with petabytes of medical data -- but researchers can't access it because our laws and regulations don't support it (and thus provide no financial incentive and only risk and lawsuits for the companies holding it.) It's abysmally sad.
Well, PHI protection (HIPAA) is actually a good thing and doesn't really prevent researchers from accessing data as long as PHI is stripped (de-identified dataset). Now getting that de-identified data is not always easy...
Now you've hit my area of expertise. This might help enable large retrospective cohort studies but would not be sufficient. In order to do that the universal system would need to do several things which are unlikely: 1)Universal clinically meaningful data model 2) Extensive use of standard terminology codes 3) good model of timeline 4) user interface which encourages the entry of discrete data over free text
> This methodology is perfectly in line with the free-market approach that the US has championed for decades.
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".
Ah, but then you ignore the many years of deliberate effort by politicians to equate "privatization" and "public/private partnerships" with "free markets", to the point where OP's statement is perfectly reasonable in light of history.
My undoubtedly imperfect emulation of a libertarian wishes me to note in response that that's just the sort of thing which a statist politician, heavily invested of necessity in the status quo, would say, and that there's no reason why we should lend the claim credence just because it's been around for a while.
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.
> Rather than trying to find a system that could be universalized,
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?
If the government has to get involved, it should be on helping (forcing) to define a flexible/complete vendor agnostic data interchange model that patients can carry along wherever they may go. The rest is just GUI, bells and whistles.
The Office of the National Coordinator has been helping on some aspects of that through support of the HL7 Consolidated CDA (C-CDA) initiative. So we do have a vendor agnostic data interchange format. But typically patient records are sent from one provider to another; there's still no good way for patients to "carry" their records.
Your statement is factually incorrect. The US federal government has given little or no money directly to EMR vendors. Instead the HITECH Act grant funding went to providers to reimburse them for purchasing and implementing EMRs. And in order to receive that funding the providers had to demonstrate that they were actually using their EMRs in a meaningful way.
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.
EMR is simply too messy for openEMR to put a dent in the issue. I truely wish it were different. If insurance carriers are permitted to operate across state lines in the future, i think there is a chance of a Google or Microsoft getting into the space which I think is the right way to go. Right now, the large companies managing EMR and huge monoliths that simply don't care about innovation. They are like defense contractors to the military.
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.
To test this hypothesis, look to California. Here we have a very large healthcare system, a variety of insurance providers, a variety of care providers and no internal barriers to insurance competition. Still, practices/insurers use different EMRs, sometimes a little different from one another, sometimes radically so. Further, providers/insurers are loathe to move away from systems they already have because of some of the issues mentioned by @JusticeJuice (currently top comment). 1.) It's super complicated 2.) It's super risky 3.) It's super hard to buy and sell, in part because of 1.) and 2.).
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?
That sounds more like a patient portal used by patients. Building something for physicians, nurses, revenue personnel, lab personnel, and practice managers is a completely different game.
I think the idea they were going for is that Google Health would be an EMR intended to be used by institutions except that the patient is in control of their record - enabling them to take their health record to any provider. The problem is that institutions have close to no reasons for investing into something like that.
I think Microsoft HealthVault was more of what you describe, where it's a portal intended to be used by patients.
No, @FLUX-YOU has it right. Google Health was only ever intended as a patient portal (PHR) and was a direct competitor to Microsoft HealthVault. Google never added any EMR features. In fact after the initial release they never added any features at all; they just lost interest in it and shut it down.
It turns out re. docs and nurses, not really. It's important to understand the who pays for what in healthcare, and how many links in the chain exist between payer, payee and who benefits. Physicians and nurses are not able to pick whatever software they want to view patient data because 1.) you need high security all around that data, and 2.) that data is primarily useful to someone else. It's useful to the doctor because they want to treat the patient. It's a lot more useful to the hospital because they want to get paid for what was done.
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.
>But the front line workers are kind of disconnected from the design and functionality of the EMR.
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.
That's not how the EMR market works. Insurance sales across state lines won't make much difference to EMRs either way.
Google and Microsoft are horizontal vendors. They aren't likely to put a major effort into a vertical market, and even if they did there's no reason that they would do it any better than the existing vendors. It's not like Google and Microsoft have some sort of magic pixie dust that would allow them to overcome experienced vendors in a brutally competitive market.
> It's not like Google and Microsoft have some sort of magic pixie dust that would allow them to overcome experienced vendors in a brutally competitive market.
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.
I don't think you've been paying attention. All the major payers Health IT vendors have analytics as good as anything at MS or Google, to the point where it's almost becoming a commodity rather than a real differentiator. Yes provider organizations are behind the curve in actually using those tools due to misaligned incentives but adding another vendor to the market won't solve that problem.
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 don't think you've been paying attention. All the major payers Health IT vendors have analytics as good as anything at MS or Google,
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.
They aren't even the only ones who moved into the EHR space, discovered that it's a nightmare, and moved back out. GE bought one of the smaller "big ten" vendors (IDX) in the late 2000s, then gave up and spun off the formerly-IDX EHR; even Siemens came, saw, and left.
your faith in Microsoft and Google is heartwarming and hilarious. I've been hearing this for over 20 years, as soon as the real smart tech people get involved we'll have this problem solved lickity split. Well, both those companies have tried to lick healthcare and both ran away with their tails between their legs after they took a crap on the bed.
Healthcare information tech sucks because it's innately more difficult than most other problem spaces
Norway has been building a universal and state-run system the last couple of years, which gathers all the patient information in one centralized system. Existing commercial companies that already deliver solutions to doctors and hospitals have integrated this new system into their existing products. It is practically interoperable by now. I believe this is the way to go. The system was beta-testet last year, and is being rolled out to doctors offices this year.
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?
How do patients authorize a new care provider to access their data? How do patients prevent the government from accessing their private health data? (Obviously the latter is a problem even for distributed systems, but a lot easier if the government already has the data on servers they control!)
If people had any idea how much antiquated medical software is out there in production running on Windows 98, 2000 or XP and coded in Visual Basic they would run away screaming. It's seriously that bad.
I did some work for a company that had 100+ banks running accounting software developed in Visual Basic in the early 90s.
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.
Willing to bet you $5 that the spaghetti code accounting software written in VB in the early 1990s is actually a GUI front end on top of an AS/400 or an IBM system/360 thing that's now running in emulation on a "mainframe".
Showcase ODBC is what we used to talk to Big Iron databases. People could not learn the IBM Mainframe or AS/400 systems. So we made a VB GUI frontend using Showcase ODBC to contect to the database. It was a lot easier that way.
You might be interested in athenahealth, a Web-oriented healthcare company which actually runs a sort of startup incubator ("More Disruption, Please"), and has led a lot of initiatives to improve interoperability. They realize these things create trouble for them as well as the rest of the field, but I think they're betting that their rivals are significantly less flexible than they are.
(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!)
Slightly OT: I read somewhere that whenever you see "to disrupt" you should replace it with "to fuck up" as that is the true meaning of what is being said. Not that it's always a bad thing, but it is almost always destructive.
Does anyone know of a EMR system that could house my household/personal health data? One of the struggles I have is organizing my own health data in a singular place with structured data formats, document uploads, etc.
The closest thing I have found is http://mymedicalapp.com/ but it appears to have been abandoned by the developer.
Thanks for the recommendation. It is what I am looking for except that it doesn't seem to offer any upload options if there are holes in the data they retrieve. Still, a step in the right direction and I'll give it a try.
PicnicHealth CEO here. You won't have this problem because we don't miss any data :) But really, if you have old stuff we can't get anymore we can find a way for you to send it over.
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.
this project has been around for a long time. I always take a look at it when I need a reference system for thinking about data models or ux related issues for health record type projects.
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.
Yep there was a lot of work both above and under the hood to modernize OpenEMR on the most recent release. Also was a several year effort to get complete meaningful use certification. Can see here for some more details on both efforts: http://www.openhealthnews.com/content/openemr-achieves-compl...
How are they planning on pushing it to hospitals? All major players have adopted Epic EMR, at least here in Colorado. And once they have a system, they'll stick with it due to premium support and huge cost will prevent switching.
Epic, Cerner and Meditech are the largest EHRs and they combined control just about 50% of the market. Epic and Cerner tend more towards the Academic hospitals and Meditech and McKesson (#4) tend towards the Commercial hospitals.
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.
This is huge. I previously worked for a healthcare startup, and it seems like for every other healthcare startup we worked alongside or networked with, all roads lead to EMRs. It was (felt like) an impossibly large task without a clear path to execution due to the tangled web of healthcare IT & regulations.
Something like this is huge, especially to potential competitors that now have a target to aim for.
There's a pretty nifty open source OpenMRS app called Bahmni that is widely used in poor countries. A lot of my friends contribute to it. Worth checking.
I think it's getting more and more popular, hearing about a lot of offices switching to OpenDental. I'm not sure how proprietary software will compete in the future.
It's been pretty easy to run, no complaints other than the usual MySQL ones.
I think the one nice thing about the dental world is that "for now" there are still far more independent entities without the ties into hospital groups like doctors and practice groups all have.
After sourceforge bundled malware with downloads, it's hard to trust a project that stuck with them, especially with health data, especially when there are numerous alternatives that are better.
As much as I would love this, I simply dont think it will work. Why? Epic is simply too big and has too much of the market and they are too far behind.
I use picnichealth.com to deal with this EMR mess and I love it!
The pricing seems incredibly high, am I understanding correctly that they want ~$300 up front then $33/month thereafter?
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?
PicnicHealth CEO here. We did raise prices to keep quality super high as we scale, but here's a nice discount for our HN friends. Enjoy! https://picnichealth.com/friends-of-picnic
That's weird, they changed their pricing plan. I only see the concierge service. Perhaps they have enough customers to be happy at the moment. I pay 10/month which is completely worth it in my mind. I can pull up pathology reports at my out of state docs office in real-time. Makes the best out of 3 hour trip to see the doc!
EDIT: I have also used this in conjunction with healthtap. EXTREMELY USEFUL! Doctors love it!
I use open dental. Tell me how open it is. An open EMR in healthcare does not mean much. Take a look at the necessary support needed to have the proper compliance.
It shows the use of ImageMagick, a legendarily buggy and insecure application and library. It shows the use of system crypt() for password hashes, which isn't really very secure since (afaik) it doesn't support pbkdf2 on most systems or bcrypt (not the blowfish one) or script. It shows hardcoding database credentials in a flat file. And it shows it uses PHP, which has its own security problems as well as being well known as a language used by people not aware of secure coding practices.
My first permanent IT job was actually working with practice management software. It worked across multiple jurisdictions with fairly minimal changes - an appointment is an appointment in any country.
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.
I don't mean to come across as an asshole; I applaud the effort!
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.
I would analyze the most used click paths and extract the real-life scenarios people are serving with them, and just make buttons for them. Clicking them will provide you with a wizard-like interface that aims at a specific need.
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.
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.
http://barnett.surge.sh/
eliot.slevin@gmail.com