Writing Apps for the EMR. It Worked for iPhone | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Writing Apps for the EMR. It Worked for iPhone

April 14, 2009
by James Feldbaum
| Reprints

The Wall Street Journal today reported on the “perspective” by Kenneth Mandl and Isaac Kohane in theNew England Journal of Medicine. Their point of view, namely creating an iPhone-like open platform, would allow developers to write applications that would rise or fall on their own merits. Their argument “allowing competition and 'natural selection' for high-value, low-cost products. This approach contrasts sharply with design of a national system by committee."

This perspective will send shivers down the collective spines of vendors who are counting on their “certification” as their ticket into the EMR arena. Clearly, there are already dozens of advanced “home-grown systems” that could be faced with obtaining some form of certification if the government agencies make it a requirement for stimulus money. In my travels I have seen some extraordinary EMRs created by physicians for their personal practices. There is some real talent out there that would enjoy the opportunity to contribute to an open system EMR. Are we missing an opportunity? The genius of the United States is not best or most in its executives or legislatures, nor in its ambassadors or authors or colleges, or churches, or parlors, nor even in its newspapers or inventors, but always most in the common people. Walt Whitman (1819 - 1892)



"Make everything as simple as possible, but not simpler."

- Albert Einstein.

You ended on a quote, so I started on one.

Are we missing an opportunity?  No.  Most, if not all, vendors demonstrated iPhone apps that tightly integrate with their supportable platform at HIMSS last week.  Whether the apps come from lots of small software vendors as well-behaved, cooperating apps, or from an integrator (read HIS Enterprise vendor), a set of coordinated, standardized services is required.

Here's why.  In order for any healthcare encounter to be enabled with technology, the processes must include ability to:

1) uniquely and reliability identify the patient and their information
2) support assessing the patients needs
3) reviewing existing"'results." be they notes from other providers, labs, radiology, or simply "lists"
4) plan (review existing plan, create a new one or update an existing plan ... aka coordinate care)
5) order what's planned (e.g. ePrescribing, CPOE)
6) scheduled what's ordered (one of many collaboration steps)
7) get those things done (manage the healthcare project plan)
8) document what you did (compliant with "medical necessity," E&M documentation/coding)
9) bill for what you did (or account for care, even if you don't bill)

Same list applies in all major care delivery settings, inpatient and outpatient.

It's really not an issue of open platforms versus closed ones.  The issue is how to fulfill the above requirements, in a manner that's cost-effective, supportable, and good enough.  Since we're talking about healthcare, it's important to define "good enough."  Here, that means assures safety and promotes quality, in every one of those nine steps, and the ones I missed.

Creating clarity around these requirements, through certification and interoperability, is exactly what the policy makers are attempting to achieve through their design.  The design that's woven throughout ARRA-2009.

I'd like to better understand Ken and Zac's statement that, "This approach contrasts sharply with design of a national system by committee."  It seems to me, based on the above outline, that government and industry are focused on getting the balance right between order and chaos.  Order being the necessary standards required to connect those nine items above.  And chaos, letting the market innovate above the minimal requisite standards.

I'm not pretending that this will ever be easy and straightforward.  We'd all welcome a better/faster/cheaper alternative.

iPhone apps can be really high value.  They do save lives, promote efficiencies, and provide information into workflow that was impractical or impossible in past years.  (See Labkoff/my article here, showing positive results with Apple's predecessor to the iPhone, rolled out at two prestigious Harvard hospitals.)  Confusing device-dependent application development with the healthcare information platforms and services, and their related business models, distorts the issues.  ONC, in my opinion, correctly identified certification and interoperability as missing essential ingredients for HCIT. 

Mobile devices and supporting device-based applications and connectivity are part of the solution.  They aren't the solution.  The systems that they talk to are essential, too.