Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, October 7, 2011

The EHR is a Platform, not an Application

One of the challenges many face in their evaluation of Electronic Health Records is the treatment of an EHR as an application that provides all necessary functionality out of the box, rather than a platform that enables it.  Almost anyone who's seen more than one EHR knows this isn't usually case.  While we all might wish that it were true, there are numerous challenges to that assumption:
  1. There is no single way all providers, even within a single organization or specialty, practice medicine.
  2. Provider workflow vary according to institution, specialty, "local policy", and provider personal preference.  
  3. Organizational needs differ based on existing IT Infrastructures.  One organization may wish to integrate an existing ePrescribing capability, while another doesn't have any and wants that as a built-in feature.
I've seen several EHR systems in action at my children's pediatrician's office, my own physician's office,  the urgent care center about 30 minutes away from me, several emergency rooms, specialty practices, et cetera.  Many of these locations use the same product: One ED and the pediatrician's office and another specialist use the same product.  My GP and the Urgent care center and yet another specialist use another product.
Yet, the way these systems are used, the screens that are displayed, and even the documents they create are different.  Even the way two providers using "The Same Product" e-Prescribe is different!

Many years ago, I worked with one site were two providers created exactly the same clinical note, but each heading was named differently, and the order and sequence varied.  Yet both providers captured essentially the same content for the same kind of visit, worked in the same specialty, in the same organization.  Oh, and to add a further complication, each one had a different note they created for that visit type depending upon what State the patient lived, because of reporting requirements of each state (The organization was the only facility of its type within 60 minutes of two cities on either side of a state border). 

There are basic capabilities that an EHR needs.  Clearly there must be a clinical data repository.  Also, they must produce documentation of visits.  They need to support import of data from other systems (e.g., registration data, reports, lab results).  They need to export data to other systems (prescriptions, orders, summary documents).

Entry of patient data is often done through forms, but some documentation may also be dictated (that preference is highly related to specialty), and some providers love to use handwriting recognition.  Many systems provide the ability to create different kinds of forms, provide sequencing logic, and often, programming language capabilities which enable them to be used in a variety of interesting ways.  

It needs to run on workstation, laptop, iPad, iPhone, Windows Phone, Android Tablet, ...
It needs to run on Windows (7 different versions), Apple (only a couple), Linux (quite a few variations) or Unix...
The database needs to use the organizations existing licenses for Oracle, Microsoft SQL Server, ...

What I've quickly learned is that most Healthcare providers do not agree upon a single best way to practice their trade.  I would note that the same is also true of car manufacturers, restaurants, software companies, hardware companies, home building contractors, or any other business.

There are a few systems out there that make assumptions that providers will follow only one pre-selected workflow, but most providers I've ever heard from loath these.  The great "Extormity" parody site even touts it as a feature.  In most EHR systems (at least those that providers like to work with), provider workflows are accommodated by allowing an implementation to be customized; supporting different capabilities, activities, sequences, and the roles accessing them.

Now, here is the real question.  When you get to usability, if the end user creates and designs the workflow, and then has trouble following it in the EHR as designed, is that a problem with the EHR, or with the workflow? 

I'm in the process right now of reading through the NIST Draft proposal (pdf) for the "Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records" recently announced for public comment between now and November 10th.  I'll be thinking about how one would truly evaluate the usability of a platform vs. an application.  Imagine, if you would, applying some of the proposed evaluations to a product like Oracle or Microsoft SQL Server combined with a UI frameworks developed in Java or .Net.  Many of the tests probably wouldn't be able to be evaluated, certainly not with any consistency.  It will be an interesting exercise.


  1. I couldn't agree more that EHR customization on a platform, rather than an application is essential. Web-based, cloud computing EHR platforms that are customizable, while rare, are the best solution; they allow physicians the mobility to chart as they please, wherever there is an internet connection. I think customization is also key when it comes to hardware. While some doctors may be comfortable using their EHR on an iPad, others may still prefer traditional desktop or laptop computers. I think the main thing to take away from this well-written article is the fact that physicians need to shop around, and choose an EHR that will work for everyone in a given practice.

  2. For it it doesn't matter if its a platform or an app. the mere fact that it help doctors with various activity in a fast pace then its ok with me. If you are interested with doctor reasons regarding using EHR you can read it at titled "More Doctors are Now Using EHR: Know their Reasons"