Based on our frequent conversations with practicing physicians, and knowledge of how other industries automated and implemented information sharing, we have three primary knocks against the current stable of electronic health records systems:

1. Terrible user interfaces based on a Microsoft .NET paradigm, which focuses on building screens to capture data into an SQL database vs. building applications which automate and improve doctor’s workflows and time management.

2. EHRs utilize some data security techniques, but virtually none do anything to implement patient privacy and granular consent over what health information is shared with whom and when.

3. The is a complete lack of integration standards and capabilities built into most EHRs.   

However, as the New Year approaches, we see progress on all three fronts. 

Our informal survey of primary care doctors found that nearly all doctors either use Macs at home, have an iPad or Kindle, and use iPhones, Androids or Blackberries.  But in nearly all cases the respondents said the most difficult computer to use is the one they use for their jobs, and it just turns out it’s the one they use the most. 

A short list of EHR vendors is recognizing the problem, and once they’ve broken the .NET-screen-to-SQL-database design mentality they begin building software that actually helps docs get through their busy day. These new EHR apps are portable, visually rich, fast, simple and sleek. We are nowhere near the end of EHR innovation but the mold has been broken, and to mix metaphors, the genie is not going back into the bottle.  EHRs built on these new design principles are just now coming on the market.

Second, and third, it looks like government incentives and just good common sense is causing EHRs, and all HIT applications for that matter, to adopt XML as a foundation for integration and data sharing.  XML is not an interchange standard per se but a “language” for defining how to build specific interchanges (XML is actually a lot more than that, but for our purposes that’s a good working definition).

The really interesting thing about XML is that it allows pretty much unlimited flexibility and extension for health I.T. applications.  Let’s use an analogy: In elementary school we all learned how to address an envelope. We put the return address on the upper left corner of the envelope and the put the name of the recipient in the middle on the top line, followed by a line for street address, and a third line for city and state separated by a comma.  This was a great standard, but then it didn’t include a set position for apartment numbers, and then Zip codes were added into the mix.  Where do you put the apartment number and Zip code?  For humans it’s easy to find and process the new information randomly added to an envelope address, but for machines it’s much more difficult.  And addressing an envelope is relatively simple compared with “mailing” medical information. 

With XML computers can be taught to read the information found on an envelope perfectly every time.  XML uses a tagging system in the format of content .  So an address in XML would be Joe Smith , 123 Main St , and Paris, Kentucky . Name, street_address, and city_state are the tags.  All you need for two computers to share address information is knowledge of what tags are in the message and what they mean.  Adding a Zip code is easy 40361 .  This just requires an agreement between the parties to add Zip codes to the message and a relatively trivial amount of programming.

Sorry to drag you readers through this technical mush, but if you can get your heads wrapped around this simple technical concept, you can see how XML will allow various EHRs and all other XML-enabled health care applications to communicate.  Here is a highly simplified but relevant example:  If one health care application, say an EHR in a hospital ED, needs to know a patient’s allergies as documented by the patient’s primary care doctor, the ED can send a message Baptist Hospital Miami , Dade Internist , Bill Smith , ? .  Dade Internists’ EHR gets the message, knows how to address a reply and exactly what information is requested.

It’s a very simple example, and clearly all parties must have the same definition for the tags, but expanding the content of the messages and integration is relatively easy.  Also, this type of architecture for communications resolves a huge problem with health information exchanges and patient privacy.

In the case of HIEs, using XML-based messaging to share information provides a clean methodology for granular information sharing.  If a woman shows up at the ED with a broken toe an XML-based information sharing process means the ED can get information relevant to treating the toe, but not her entire medical history--her gynecological information, for example.  If the ED doc decides she needs the GYN info there is nothing preventing her from making a second request if the patient has authorized access to that information.  And in extreme cases there can be a “break the glass” provision to allow the ED to get “unauthorized” information.

The other really interesting thing about using XML-type messaging for integration and sharing is that it is relatively easy to log the messages in XML database for tracking and auditing. And the messaging specifications can require two important privacy components--tags for the exchange, and when an exchange takes place.  With these two tags we can implement a comprehensive system for ensuring the standing and identity of the authorizing parties for health information sharing at every level.  And we can implement patient notification.  In the above cases, the first patient could have permitted general access to his allergies to any certified health care provider without notification, and the second patient could have requested that any GYN information sharing must be done concurrent with patient notification. His or her choice.

Rob Tholemeier is a research analyst for Crosstree Capital Management in Tampa, Fla., covering the heath I.T. industry. He has over 25 years experience as an information technology investor, research analyst, investment banker and consultant, after beginning his career as a hardware engineer and designer.

 

Register or login for access to this item and much more

All Health Data Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access