Comment by mistermann | Hacker News Reader

Comment by mistermann | Hacker News Reader

This is depressing in so many ways...just a few:

The software he is using is obviously extremely poorly designed:

"It turns out that in our electronic medical record system there is a 1,000-character maximum in the assessment field."

- Unreal. No further comment necessary.

"In practice, most doctors end up opening only the last two or three visits; everything before that is effectively consigned to the electronic dust heap."

- Opening individual windows for each visit is ridiculous, this should be viewed through a historic report at least (as well as a thousand other subtle smart features).

"As I type away, I feel like I’m doing the right thing, explicating my clinical reasoning rather than just plugging numbers into a formula."

- Why is a doctor be typing this stuff in? This should be spoken and recorded permanently, and transcribed by a qualified person into text.

And, maybe it's just me....I don't expect doctors to be experts in software design, but I would like to think doctors would be of average to above average intelligence...these shortcomings should be obvious to him as poor design as a reasonably intelligent person who has interacted with many forms of software in his day to day life and recognized as such - but from the article, he seems to think these are natural tradeoffs that must be made when switching to an electronic format.

Medical electronic record systems are almost always poorly designed like this one. That's why doctors perceive such deficiencies as "natural."

I would hope that my doctor uses mainstream technology (internet, iPad) and could differentiate between what is "common" and what is possible.

If one isn't able to do that, I would seriously question their ability to properly diagnose complex ailments.

“Enterprise” software, as a rule, has horrible user interfaces. The people who buy this kind of stuff are three layers of management removed from the people who actually use it, the software is often customized, and quality of user experience is not a critical factor in the purchasing decision.

From the perspective of a non-geek who works in a medium-to-large company, bad “enterprise” software is just an irritation that goes with the job, like bad coffee. You may complain about it but you don’t seriously expect it to be fixed.

If you pick up a book on best practices in development of enterprise software, it is basically a catalog of obviously beneficial things that people fantasize about in the pages of a book because they are never allowed to do them in real life.

For instance, talking to prospective users. The importance of this has been stressed over and over again and is no longer disputed. In fact, when an in-house team started designing changes to an accounting app my friend had to use, there was an official user expert designated to work with the developers. The user "expert" was her manager, who had never used the application that was being changed, had never used a similar application, and had never even done a job similar to the one done by the users. What's more, she forbade the developers to speak to the users because she didn't want the development effort to affect their productivity. Oh, it did affect their productivity eventually, believe me it did.

(It's an exaggeration to say it's uniformly terrible; I had a good experience with the one enterprise app I built, but it was for a network operations team, so they understood a lot about software and about the need to be generous with time and access.)

Privacy laws and regulations restrict what doctors can do with technology. I'm mostly happy about that obstruction, just because I know who has the greatest interest and ability to influence medical IT (the insurance companies) and what their motivations are (sell private information, deny claims, only cover healthy people.)

A guy in the oil business once told me a story about why Bangladesh's gas fields have not been thoroughly exploited yet. Basically it was a big tangle of political crap -- and according to him, Bangladeshis are very happy not to have the gas fields exploited, because they assume that both the current leadership and the opposition party are so corrupt that all the money would be stolen anyway, so it's better if the gas is not exploited until the far future when some of the money might go to the people. I have no idea if that's true or not, but it captures why I'm mostly glad that the use of technology in medicine is stuck in the dark ages. Until there is some stakeholder involved who gives a crap about patient rights and privacy (the doctors care about effective treatment, but not rights or privacy) it's best if nothing changes at all.

But the thing is, biological systems are incredibly complex and poorly understood. So in a biological system, you can't say "we can do X so it should be an easy step to do Y".

If one was reasoning about a computer in the way you have to reason about a biological system, there wouldn't be any reason to think that since you can create with a browser unlimited character field it, you can create a medical transcription system with an unlimited character field.

The problem is a bad feedback loop. Doctors need to demand an adequate user-experience, and buyers of these systems need to include user-experience "intangibles" into their decisions.

I'll play sort of a devil's advocate here as someone who's worked in this field: the feature-gaps identified aren't all that bad.

- 1k-assessment limit: It's not ridiculous; assessment-notes are usually 0-2 acronym-laden sentences, probably under 200 characters in general. Writing a 1k-long assessment note seems extremely unusual and I think in many situations would be completely loathed by co-practitioners, who need to very quickly read visit notes (the assessment is just one field out of dozens or hundreds). An inexperienced doctor could easily be reprimanded for such verbosity. However, there are many different working and documentation styles which work better for certain patient populations, specialties, institutional needs, etc. -- this doc may absolutely be justified in wanting to be thorough in this situation. A call from an experienced doc should be investigated and most probably addressed in future versions of the software.

- Reviewing past visits: The EMR probably does have some kind of history report/index view into the list of past visits, but the problem here seems to be that the index doesn't have the right data in it. The doc wants to review in detail the "thickest" or most important notes, so you need to display that into the index. It's a good feature idea, but not an obvious one.

- Dictation: It's disruptive and awkward to dictate in front of patients. So typing/writing while talking to the patient is generally more efficient, even if the doc has to wrap up after the patient has left. For work that is entirely done when patients are not present, dictation is a fine solution and in fact is used by many, many docs, integrated into EMRs, etc.

One issue, not explicit in the article but possibly relevant, is that managers often use constraints in enterprise software in order to control end-users. Field-lengths sometimes come out of these ("They're wasting time! They should move onto the next [patient/customer/widget/etc.]!"). But the problem there is poor communication & lack of agreement between management and workers, rather than an outright deficiency in the IT itself.

Most doctors have themselves to blame, they hate change, they hate tech, they hate having to learn something new. Even if it is to do with there specialty, they have to be forced by the government to study new stuff. There is a huge industry around getting drs to go study new stuff, which they are paid to do.

Doctors hate change, they want to keep things as they are. For most non complicated consults, people are much better of with a smart system rather than going to talk to a bored dr, but drs do not want to give up their control.

Everyone hates change and with good reason.

Assume the doctor has a working system that enables them to do their job, without being distracted by having to learn new, irrelevant procedures. Any new "better" system has to provide really tangible benefits to be worthwhile learning. If that new system has been designed by administrators, for the benefit of administrators, then it's little wonder that the doctors are resistant to change.

I agree - the author seems to think that problems with a particular design are intrinsic to any electronic solution.

Reply on news.ycombinator.com