NOSH ChartingSystem

A new open source health charting system for doctors.

The future of interoperability

Leave a comment

Next week, NOSH ChartingSystem will be providing new features and structural frameworks that point the way to a significant development regarding interoperability.  Health information exchanges (HIE) is THE buzzword these days, specifically regarding the recommendations in Stage 3 of Meaningful Use.  Even though NOSH ChartingSystem is not a certified EHR (nor will it ever be due to principles, not due to features), the whole goal of interoperability (for which HIE’s are the guideposts to that goal) is one of the reasons why I believe EHRs were meant to function and that NOSH ChartingSystem aims to be the leader and example of true interoperability.

Unfortunately, there are significant barriers towards interoperability.  The big elephant in the room is  the simple fact that in the current, monopolistic, closed-source software environment that is pervasive in the saturated EHR market, interoperability is anathema to the end-goals of this type of environment.  Think about it…if you were a software company wanting complete control of the market, why design components or redesign your software to accommodate other systems in the aims of sharing information?  However, if your goal is to gain near complete control of the market, you want your software to be THE standard.   That’s what most software vendors want their potential buyers to feel…to feel the “peer pressure” of getting the same system as your competitors so that your systems could “potentially” talk to one another.   But alas, there are many examples where even buying the “same” system doesn’t get you interoperability (see this link, and go down to comments where there is one comment by David Chase talking about Epic EHRs not talking to each of the large metro Portland, Oregon hospitals).  Tsk, tsk.

But for the doctor, health practice, or hospital, is that really a good thing?

I believe there is a better solution.  Just like in the internet, you have a choice to pick any browser you want (Firefox, Chrome, Safari, Opera, iPhone, iPad, Android, Internet Explorer, etc.) they all talk the same language from one web site to another.  There are standards (HTML, JavaScript) that these browsers need to conform to.  Having standards levels the playing field so that each browser can focus on a particular feature that they feel they are strong at and to market to that strength rather than rigging the game and trying to up-end the entire environment at the behest of the user.  An example of this involves Internet Explorer version 6, where Microsoft tried to program the browser to use a closed, proprietary version of CSS (the code that develops the style of the website), that (in the end) became an utter disaster for everyone.  Websites that were created for IE6 did not work for other browsers and vice versa.  Website developers were frustrated that they had to create two versions of their websites so that it will look and work the same across all browsers.  End users became frustrated that they had to use only one type of browser to view a particular website (especially those that pertained to their work that relied on Microsoft technology) when they typically used another web browser as their default.  Microsoft had the audacity to believe that they could create their own environment and steer the competition away (from Netscape and Mozilla), but in the end (because of the standards in place), Microsoft had to give in and subsequent versions of IE were more standards-friendly than IE6.

Well, the unfortunate truth is, there are no standards for interoperability in the EHR world because no one took the leadership role in the health IT sphere to make it so (typically the government has a big hand in this and is able to if they really wanted to…unfortunately, they abdicated that role and hence the void).  And the horse is out of the barn, so to speak, and the powers that be who have significant control of the market will not want  to have standards in place at this stage in the game for it will put them at a competitive disadvantage.  For if the goal is to monopolize the market, you want the software environment to be like the wild, wild west and whoever has the most power and influence wins, irregardless if the user likes it or not.  It’s already happening, much to my dismay.

But like in those old Western movies, there are always a few characters with good hearts and good intentions who eventually persevere  and provide the common good despite the “rigged lawlessness” that is so pervasive in the environment.  One of those good characters in the health IT world is this product called Mirth.  Mirth is an open-source product whose primary goal is to provide a way for one electronic interface to query their system database, translate the result so that another electronic interface can read it, understand it, and synchronize that information into their own database so that the end-user, irregardless of the system they are using has the ability to share information with another end-user.  You can send lab results, referrals, prescriptions, chart notes, and more in a very secure method.  As long as Mirth is attached to your system, you’re good to go.

Well, the great news is that NOSH ChartingSystem was built from the ground up to be Mirth friendly.  Because NOSH uses a commonly used database (MySQL) and NOSH’s organized table framework,  Mirth interfaces with it perfectly.  Because Mirth is not proprietary in what type of operating system it is installed on (it’s based on Java, which can be installed on Windows, Mac, and yes, Linux!), it runs perfectly with NOSH ChartingSystem when it’s installed on Ubuntu.  With Mirth, you can create “channels” that act as the data grabber, translator, and data sender to the destination you want and know that it’ll get there.  It it all happens automatically since Mirth constantly polls the database for any specified changes or polls for any incoming messages that arrive into the system and incorporates into the database 24 hours a day.

With NOSH ChartingSystem, I’ve created some installer scripts that make it easy to install and configure Mirth to work with NOSH.  This will be available at the next release next week (Yeah!!).  I’ll also release, in the near future, some example channels that demonstrate who NOSH can interface various services (ePrescribing, Labs, Imaging, sending records, etc) without having significant expertise in using Mirth. 

Mirth, as far as I can tell, have been around for some time.  It’s beyond me why it’s not THE Swiss Army Knife for all health IT technology functions (it clearly is), but given the hostile closed-source, monopolistic health IT environment, I’m also not surprised that we’re not seeing Mirth being used to its full potential.  It’s the first, but most important, step towards interoperability in this hostile environment.


Author: shihjay

I am a family physician and previous medical director for a child abuse assessment center. I am now promoting my new electronic health record system (NOSH ChartingSystem) that I have developed and used for myself in my private practice since 2010 and now I want to share it to the rest of the doctoring world.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s