Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

ONCHIT Health IT Software Contests – Some Thoughts

Posted on May 30, 2012 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

Ken Terry at InformationWeek has an interesting editorial on Office of National Coordinator on Health IT’s (ONCHIT) latest contest for developers. This time the ONCHIT wants developers to come up with an IT product that can help ophthalmologists see better (yes, it’s a lame pun 🙂

Among the laundry list of requirements that this mythical software must possess: (I’m quoting from Terry’s article)

it must warehouse data from many different devices;
convert the data from proprietary formats to a single, vendor-neutral format;
enable clinicians to manipulate data and images;
and interface with existing EHR systems (presumably, just the top dozen or so)

Here’s the link to the slightly more detailed ONCHIT list. The first prize is $100,000 which is nothing to sneeze at.

Terry lists some problems uniquely faced by specialists such as oncologists and ophthalmologists: off the shelf EHRs don’t really grasp the nuances and details of information needed by specialists. Terry lists for example weight and height details that EHRs typically capture. Opthalmologists don’t really need this information. Typical EHRs on the other hand don’t allow for visual acuity information to be stored, at least not without (paid-for, and hence costly) customizations.

Looking at this issue as a some-time developer with some skin in the game, here’s how I see this process: ONCHIT wants to kick start IT development by getting developers interested via contests. This time it’s shining its light on opthalmologists. It has provided a list of not-so-impossible to design features, which might not capture all the nuances of features needed by ophthalmologists.

The major flaws I see in this process: the prize money is smallish, which means that the people that would be most interested in developing something would be the smaller IT shops. However, most IT developers don’t know enough about ophthalmology to truly understand what’s needed of their IT product. Till I saw Terry’s accompanying editorial, I was under the impression that this was a perfectly fine list of features to request. Also, I’m very underwhelmed by the “details” provided in the ONCHIT page. It is full of 20 dollar words, which will probably make little sense to the developers who are the intended targets of these words.

To be sure, you will see some health IT developers develop something and send them out, just because. Hell, it’s a contest, and there’s decent prize money.

Here’s what I’d rather have seen: maybe a short video that shows an ophthalmologist at work, a couple of minutes where s/he describes the main challenges s/he faces and provides the top 5-6 things that is on hizzer wishlist in an EMR. Or ONCHIT could facilitate talks between developers and specialists so each side understands what is required of them. Till then we’re doomed to square pegs in round holes software products that frustrate everyone soundly.

Fixing EMR Drawbacks

Posted on October 17, 2011 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

FierceHealthIT editor Ken Terry had a recent post on the need for better human-computer interfaces in EMRs. He highlighted a few areas where EMRs could stand some improvement, and I thought they were bang on. These are aspects I’ve thought about a great deal myself, and true to the Steve Jobs dictum of staying foolish, I’m offering some solutions to these oft-mentioned problems. I’m sure there are plenty of people who have already thought of these and better solutions, but here we go:

1) Initial Data Entry – The biggest headache for providers’ offices today is what to do with all those boxes of medical records. Scanning solutions exist but they leave you with unstructured data. Manual extraction is time-consuming and requires upfront investment. I’ve pondered for a while about this. I think on-demand data extraction might be the way to go. Provider offices know ahead of time what their weekly, even monthly appointments are. If a provider’s office digitizes the records of patients with upcoming appointments every week, it should have most of its records digitized by end of year. This is assuming patients make it to the doctor’s office for at least once-a-year appointments if not more. If the office outsources this work, it needs some monetary investment, no doubt, but such a setup might be affordable since it is pay-as-you-go.

2) Templating – Terry states that many doctors hate the templates that come with most EMRs. And templates make it easy to generate pages and pages of verbiage which say exactly the same thing for patients with similar profiles, or say very little that is meaningful. Surely customizable or extensible templates can get rid of this problem. Or speech-to-text dictation that allows the doctor to mirror practices from not so long ago.

3) Alert Overload – Many EMRs are designed to issue alerts for adverse drug interactions, prompts for patients and similar such decision support tools. But too few of these and you risk not asking the right questions. Too many providers just ignore them, or worse, override them. No easy solutions for this one, except maybe to figure out where the fine line lies between lack of decision support and too many alerts.

4) Interoperability – EMRs cannot talk to each other. So a patient who moves from one provider to another is really at the mercy of software whimsies. Or worse. For providers, it’s equally frustrating not to be able to get ahold of the patient records in a format suitable for their particular EMR software. One simple answer – standards. Granted HL7 is still evolving, but EMR vendors need to at least consider offering data exports in this format.