A typical day on the ward

I didn't mind driving through icy Boston roads at five in the morning -- but I did mind the fact that I was doing a job that computers should be able to do far faster and more accurately.

The EHR was a terminal-based system, and I wound up routing traffic through a local proxy, analyzing the logs, and figuring out how the protocols worked. (I'm sure that reading about terminal emulators would have been more effective than reverse engineering them; I can only blame sleep deprivation.) I ultimately built a Python script to drive the terminal based on a list of medical record numbers, recording vital signs and slotting them into pre-formatted progress notes for printing. It even plotted sparklines for fever curves.

It worked. And the chief of surgery loved it. He wrote me a stellar evaluation that prominently mentioned my work with the computer system (I also did good clinical work and all).

Two months later when the medical school dean read my evaluation, I got a very angry phone call. She was horrified that I had "hacked" into the computer system and taken matters into my own hands. I tried my best to explain how the system worked, and why it wasn't a threat. But I didn't really get the message across.

The upshot, though: I realized just how broken healthcare information systems were -- and that I enjoyed working on solutions. After medical school I joined the research faculty at Boston Children's Hospital, where I'm working on open specs, tools, and standards that make it easier to integrate third-party health apps with clinical data and EHRs [1]. It's been an interesting ride -- and I've learned an incredible amount about health interoperability, politics, data, and security along the way.

1. http://smartplatforms.org/

1. EHR technology is sold to managers, not clinicians.

2. The leadership of introducing the EHR is fragmented and highly dependent on local conditions such that success in one location does not guarantee success in another location. Likewise with failure.

3. Researchers have a tendency to treat evaluation of health technology as epistemologically equivalent to evaluation of pharmaceutical technology even though a cursory examination of the logic underpinning this assumption clearly demonstrates that this is not the case.

(point 3 makes my job very difficult and political. Fortunately this work[1] and the very few others like it, generally from the same research group lends my work instant legitimacy. Without it, getting my thesis through the committie would I fear be impossible).

[1] http://www.ncbi.nlm.nih.gov/pubmed/22188347

-

This looks like a great tool How are you going to deal with the inevitable hurdles of HIPPA compliance? (HIPPA = patient privacy laws in the US, for people who don't know).

The big 'but' is that there are so many hidden requirements here. Privacy is a huge concern. Data on patients may not leave the hospital. With the devices we have these days, it is almost impossible to create a near offline system. Almost all devices are connected to "the cloud" in some form or another, making them vulnerable.

The fact that health insurers are grossly incompetent in this aspect does not mean that hospitals should go down to that level.

Another hidden requirement is that this system has to work, always, no matter what happens. Paper notes may not be efficient, or complete. However, you can be pretty sure that while the hospital is still standing, this system works. Making a digital system that is as reliable is a very hard task.

All this will make such a system a huge investment, not only the system itself, but also in training. Balanced against the cost, it is not so evident that this is really an acceptable investment.

  Oh my god, we still have to write things down on paper?!

The problem arises when others have to discern an individual's short hand notes.

So, an array of shitty post-notes is weak and lacks integrity, but similarly, so do disparate plain text files, haphazardly saved in an array of folders with haphazard file names. And yes, you could theoretically grep such a data store for meaningful details, but then again: Have you ever actually tried to parse someone else's randomly sorted plain text notes? It's a brain nullifying experience sifting through someone else's disorganized stream of consciousness.

This is a garbage-in-garbage-out scenario, and coping with a tide of inadvertently injured humanity does not lend itself to well-formed XML and proper SQL grammar. People don't plan on coughing up a lung, or getting shot, or run over. No one plans on syphlis dimentia.

You can bulldoze a landfill of printed circuit boards onto this problem, and still come back and say "boo-hoo, healthcare broken."

It's a hard problem, and there's always going to be a 50% share of elbow grease to pony up on the buy-in. Hospitals are hotels where people disintegrate in the most controlled manner possible.

Feel free to try and automate garbage collection in this environment. You'll assuredly end up with more bloated heap space than a Windows virtual machine running a JVM that emulates a .NET runtime environment.

Please be assured that the state-of-the-art is not as described. Sufficiently advanced hospitals would have means for healthcare workers to access vitals, lab values, patient location, current medications, current problem list / diagnoses, medical history from previous days and even previous visits, and even medical history from other institutions - all electronically. Staffs enter data into system directly and no transcribing is required. These are available as discrete data i.e. not freetext strings only decipherable by humans.

Also don't forget about electronic prescribing of drugs, glorified vending machines with pockets that only open when there is an order for that particular medication, and barcoded medication administration system.

I wonder what would happen if an intern group got together and said "No. This is a stupid and dangerous way of doing things. We're no longer going to turn up an hour early for a 12-hour shift to copy out notes that should have been taken in a more sensible way to start with."

@jeeshan, I'm assuming you're the author. Why have these practices (archaic maintenance of lists) been maintained?

[1] - HN Guidelines -https://news.ycombinator.com/newsguidelines.html

For anyone else, the URL is: http://www.listrunnerapp.com/

I'm glad people care, but for me, these are first world problems compared to drug shortages, inadequate facilities for water and sanitation, missing diagnostics, payroll shortfalls, and so many things.

Sadly, though, these are not problems that programmers can do much to fix.

An average intern during a ward round has to do the following things for each patient : 1) Handwrite notes into the patient's bedside notes as the senior doctor takes a history / examines the patient. 2) Look at the patient's vitals chart and medications chart. 3) Handwrite a plan in the patient's notes at the end (this is essentially a list of tasks for the intern to do during the day). 4) Often while the intern is still writing the plan, into the patients notes, the rest of the team is already moving onto the next patient. The intern will hurriedly re-write any tasks from the plan onto their personal printed patient list (takes < 5 seconds) and then quickly go get the notes for the next patient and begin this process again. Also note that often the patients are scattered around multiple wards in the hospital.

Now Listrunner, in their demo video shows a list of tasks for each patient on an iPhone. Awesome!

But where in the ward round does my list of tasks get copied into Listrunner? If I have to manually find the patient in the app and then manually add the tasks to an app it would take minutes, not the <5 seconds it does to rewrite the tasks on a personal list in super shorthand. And no senior doctor is going to wait a couple of minutes for you to write each patients tasks into your phone (this would add 40 minutes to a 20 patient ward round).

I've been thinking about this a lot, and I think a solution using google glass would be super amazing here. I'm currently in the prototyping and validation stage of the project (following Eric Reis' 'build-measure-learn'). Happy to talk to any doctors interested in it.

It works as follows:

1) After you finish writing the patient's plan you take a photo of it with google glass. 2) OCR is performed on the photo, right then an there (hopefully in <= 1 sec) and the OCR is shown to the google glass wearer who can confirm that the OCR is correct.* 3) Those tasks are then synced to the doctor's phone, or for security reasons perhaps a hospital owned phone or tablet.

The advantage of this system is that it doesn't change the current workflow at all. It doesn't affect the speed of the ward round. Thus, faces a lower level of resistance to adoption.

Disadvantage - doctor's are notorious for bad handwriting, thus it will not work for all doctors. It's expensive. However, as google glass (and perhaps other similar tech) gets cheaper this may not be significant.

*Patient labels are already affixed to the top of the page (so OCR can be performed on the label to associate the tasks with the patient). But if the solution became widely used, a simple QR code could be added to patient labels, to make this easier.