Why contact lens data in EMRs is taking a while

I recently wrote a blog post about how I would like to see contact lens data and calculations integrated into EMRs. I even went so far to create a little mockup of how it could work.

My intention was to create a concept piece - an idealized look at what the future might, or should, hold for us EMR-using ODs in the trenches.

I’ve received some great feedback from people expressing their frustration that these dreams are not a reality. As a person who has been brainstorming about how this could work for many years, I share that frustration.

However, my deep thinking on this subject has also given me some perspective on why things move slower than we’d like them to. As an optometrist who also writes software I can see both sides of this issue.

So, why can’t EMRs do more fancy things like better integrate contact lens data?

 

1. Electronic medical records are immature. Most of them are less than 10 years old, and very few are less than 20 years old. The newer ones are actually more likely to be using more modern web-based technologies, but all should be considered to be in an active development stage because . . .

2. EMRs are complicated. I can’t imagine building an EMR. Actually, I have imagined it, but it quickly gives me a headache. I daydream about how I’d create a UI and I always get stuck on how to make it complete yet easy to use. And the UI is the fun, relatively easy part. The not-so-fun part is the backend: Writing and reading to/from databases, making data redundant (so you don’t lose any), making sure you do everything humanly possible to avoid downtime. And then there’s HIPPA.

3. EMR developers have been preoccupied. Federal mandates related to EMRs have been a blessing and a curse. It’s obviously been a boon for our EMR vendors, but I also know that a very large portion of their time over the last few years has been devoted to meaningful use. I know I personally live in a constant state of frustration that administrative duties keep me from developing new features for EyeDock, and I bet our EMR developers feel the same way.

4. EMRs aren’t coded by optometrists. Not to toot my own horn, but the things I’ve built into EyeDock are pretty complicated. I’m far from a master programmer - when I write code I probably have 100 failures for every success - however, the one advantage I have over a “real” programmer is the fact I’m an optometrist, and I know exactly how we need things to look and feel. This may actually be tough for us (ODs) to understand  because the decisions we make (vertexing, transposing, keeping spherical equivalents, rounding axes, etc. etc) are all second nature. Things like this can really throw muggles (non-OD folk) for a loop. Believe me, as my life started getting busier I tried to outsource EyeDock work on a couple occasions, and it was a failure every time. To make things work the way I wanted them to I pretty much had to teach programmers to be optometrists, and in the end I came to the conclusion it made more sense to do it myself. In summary, EMR coders are better programmers than I’ll ever be, but they’ll never have a complete understanding of what we need.

5. Contact lens data is tricky. I created EyeDock’s database from scratch over 10 years ago and have constantly refined it’s structure over the last decade. Making one database to handle all types of contact lens data is very cumbersome (eg. base curves can be “flat”, “8.5”, or a SAG value). Dealing with these issues requires a lot of workarounds, which results in a very complicated database. A 10 column spreadsheet isn’t going to cut it, at least not if you want to search, sort, and display your information in a meaningful way.

Furthermore, EyeDock was created to essentially be a search engine. The difference between this goal and an EMR’s needs is subtle but significant. An EMR can’t use a block of text that says “sphere power is -0.50 to -10.00 in 0.25 steps when the axis is 90/180 +/- 20º”. They need lists of parameters (-0.50, -0.75, . . ., -10.00) that are grouped by what the manufactures give us. For an extreme example, consider the Acuvue Advanced for Astigmatism’s convoluted set of parameters.

OK, so, after years of trying, I finally created a database that can handle all these idiosyncratic parameters. It can still be used to search and display pretty results, and now it can be used to populate dropdown boxes in a mockup. However . . .

6. Sharing data is tricky. Due to the data complexity a fair amount of code had to be written to populate the database, do the searching and displaying, and especially to populate dropdown boxes. As I said, I’ve been writing code to do this for the last decade +, but it would be extremely difficult for an outsider to come in and do the same thing. On the few occasions that I’ve showed EyeDock’s databases to outsiders, well, I’m pretty sure they were quite overwhelmed - and perhaps a little horrified.

This is one reason I’m trying to make EyeDock more accessible from the outside. If it’s too complicated to use this data from within an EMR, perhaps EyeDock can do the heavy lifting. The EMR tells EyeDock what it wants and EyeDock searches, parses, and returns the relevant information back to the EMR.

From the EMR’s perspective, however, . . .

7. It’s not easy to rely on third parties. Software developers tend to like to minimize dependencies on the outside. You never want your user’s perception of your product to be tainted by something that’s out of your control. If I were an EMR developer living in an ideal world I’d have my own in-house database and my own code to access it. Outside of an ideal world, I think this would require significantly more resources than any developer would be willing to put into it.

 

In conclusion, although the pace is frustrating, I think we’re all going to have to take baby steps towards or contact lens / EMR utopia.

 

Quick Calcs

 

Patient Education