NOSH ChartingSystem

A new open source health charting system for doctors.

1 Comment

A Close Look Under the Hood of NOSH 1.8.0.

So I’ll start with two new features of NOSH 1.8.0 that benefits both the users (providers, patients) and the developer (me) that was recently released.


I wanted to have providers attain the ability to create their form templates on-the-fly using a web-based interface similar to what WordPress uses for its blog creation platform, specifically regarding forms.

Thanks to the dForm plugin for jQuery, I was able to make this work as a proof-of-concept with the introduction of electronic patient forms.  With JSON, form elements and their data was easily transmitted to the server and back.  Applying this principle to the review of systems (ROS) and physical examination (PE) section of the encounters view, I was able to create an on-the-fly template designing tool.  By designating the template to a particular element of the ROS/PE headings, one could create an unlimited number of templates for any condition.

This is a screenshot where the provider can edit the templates (Configure link -> PE templates).

NOSH ChartingSystem - Chromium_018

This is what the physical examination looks like with the template buttons on the right.  Clicking on the button will transfer a value text into the preview text box on the left.

NOSH ChartingSystem - Chromium_017


Rolling Releases

One new feature of NOSH is its ability to take advantage of GitHub’s revision control system.   Any changes to the NOSH code are tracked and  differences are documented between one version with another.  NOSH, because it is PHP and Javascript based, allows easy tracking and there is no binary code.  In the past, NOSH was updated either manually through an install script or through a Debian package script.  It was clumsy as sometimes there were issues from any Linux system (or Ubuntu version) that I didn’t anticipate, which caused premature script errors in the installation process.  This was quite frustrating for me and NOSH users.  With 1.8.0,  once NOSH is installed, it will no longer require updating via install scripts or Debian package scripts.  It runs in the background as a Laravel route, through a scheduled (Cron) script to be done nightly.  The Laravel route points to a controller that polls GitHub through it’s excellent API, tracks any changes and then applies those changes to the NOSH installation.  Any version changes that require database table modifications are  then applied afterwards if needed through NOSH’s internal version tracking.  And with Laravel’s Migration tool, table schema tracking is painless.  And with Composer’s dependency management system, updates of dependent packages is also automatic.

Wow…this is such a far cry from what I was doing with plain old PHP and Codeigniter from a couple of years ago.  Thank goodness for innovation and open source tools that keep getting better all the time!



Leave a comment

Thank you Laravel, from NOSH ChartingSystem…

I sincerely apologize for the radio silence for the past few months.  Being a solo open source software developer has its challenges (while at the same time…being a doctor seeing patients, taking boards for specialty certification, and most importantly, being a dad!).  Unfortunately, some things had to be put on the back burner and that was blogging and tweeting and all the social media stuff.

But now that I’m out of my coding cave, I’m pleased to announce my newest update for NOSH.

One of the fun things about being a developer is being able to review your own work, and it was interesting to see what I was coding when I was building NOSH in the wee hours of the night while rocking my infant daughter to sleep back in 2009.  And some of it, honestly, was not pretty.  And sometimes those not-so-pretty code came back to bite you when you’re trying to add in a new feature or fixing a bug which turned out to be a bigger hidden bug, and it’s just like peeling an onion.  It goes deeper and deeper and then you see the things that make you go “Huh?!”.

On top of that, Codeigniter, the PHP framework that is the basis of NOSH, had changed its open source licensing and I was worried about the future development of my project and the legal implications of it.  It probably was not such a big deal, but it worried me anyway.

And then, Nate DeNiro, whom I was meeting over for some coffee, mentioned to me about Laravel, another PHP framework.  Now, I knew about other PHP frameworks and I had compared the ones that existed when I was initially coding NOSH, but I had not come across it (because I suppose it didn’t exist back then).  Codeigniter, at the time, had a big developer base and lots of interest, and it made a whole lot of sense to me, so I stuck with it.

But over time (and even initially), there were significant modifications to Codeigniter that I had to make for NOSH to work to my liking, such as the authentication library (Codeigniter didn’t have one), and creating PDF’s (had to hack on a mPDF class, which took a lot time to make it right) that made the coding a bit more difficult.

When I started NOSH, I thought it was more efficient to replicate and take away code for each access control user (like the provider, patient, billing, and assistants).  But now, I’m wondering, “what the hell was I thinking??!!”   (I suppose it was from sleep deprivation with a crying infant).  With each new modification to the code, any similar code on the other users had to be accounted for.  And that became such an increasing pain over time and it subsequently created more bugs and more bugs due to inconsistencies in code when I didn’t account for changes between user levels.  And when it came time for me to tackle on a big change in electronic order entry, it became abundantly clear this was not going to work for me anymore.

And so, after I put the finishing wraps on my NOSH in the Cloud service, I went over to the Laravel page and I was getting a grasp of what this framework had to offer.   I immediately got hooked on the phrase “web artisan”…I never considered myself one (I thought I was more of an amateur hacker…but I like being called a “web artisan”, just because it sounds nice).  And as I dug deeper into what it could do, it became clear to me that this is the future for NOSH.  Even if I stopped development for NOSH, perhaps the foundation using Laravel would make it a good entry point for any PHP/Javascript developer to really know how to dive in, help with the NOSH code, and carrying it forward.

Why Laravel?  Here it is in a nutshell:

1.  It’s fully featured  - All the relevant features I needed for NOSH are already available out of the box.

2.  It’s secure – It comes with a robust authentication library out of the box.  No new modifications needed.  Hurrah!

3.  It’s easily expandable – Laravel uses the Composer dependency manager and so any plugin and anything else that the plugin needs gets accounted for.  And it doesn’t mess with your own code when you install it which is great.  It made my life a whole lot easier!  One cool plugin that I want to shout out about is the wkhtmltopdf binary that is an open source library that generates PDFs from HTML code.   NOSH had that feature before, but in a clunky and memory intensive way.  But thanks to the open source rendering engine of WebKit (which is the code that is behind  the Google Chrome and Safari web browsers), wkhtmltopdf allows NOSH to generate PDFs very quickly without all the memory intensive processing it used to do through PHP.  With its excellent HTML rendering, I don’t have to worry anymore about having to designing  and modify the HTML for the PDF document anymore.  And with a Laravel wrapper which gets easily installed, it was perfect.

4.  Although it required me to unlearn my habits with Codeigniter coding, I grew to appreciate the elegant way Laravel coded some things that allowed me to condense my code significantly.  In fact, with the changes I made, NOSH went on a major diet again, going from 20 mb of code to 8 mb!  That’s a 60% reduction.  That’s way cool.  But I suspect it also means I actually learned how to code better.  It’s a learning experience for me all the way, which is kinda surreal since I’m a doctor treating patients too.  Doctor Web Artisan calling…

So yes, Laravel saved my project.  It was nuts that I re-coded NOSH from the ground up in 3 months, but I feel that in the long-term, it is definitely worth it.  We shall see…   And without further ado.  NOSH 1.8.0 is here and check it out the latest and greatest with  the fully featured live demo here.

BTW, NOSH in the Cloud is now on 1.8.0 too.

In future blog posts, I’ll speak about the specific changes with 1.8.0.  In conclusion, I’ll list off the user-apparent changes in NOSH 1.8.0 (the full feature list is here):

  • Ability to create HPI (History of Present Illness), ROS (Review of Systems), and PE (Physical Exam) templates.
  • There is now an additional Encounter template (rather than the 1 standard medical template that has been used previously).  This allows assistant users to be able to sign this template (called the Clinical Support Visit) and to be able to bill for this type of encounter.  The way the framework is designed allows future updates to occur easily, by allowing increased customization of different types of encounters.
  • Ability to now import a Consolidated Clinical Document Architecture (C-CDA) which is going to be a new standard of sending relevant clinical information about a patient from one record system to another.  Check out the BlueButtonPlus initiative regarding this.  The way NOSH integrates C-CDA involves the ability to upload the C-CDA document, parses the information and displays a Reconciliation process where the provider can then update the Problem List, Medications, Allergies, and Immunizations for the patient so that it is current.  Furthermore, the provider can view a C-CDA though a document generated by bbClear which is a great open-source tool that allows easy visualization of C-CDA by normal human beings.  It’s great for patients to have and for providers to use.
  • Easier access to the schedule and intra-office/patient portal messaging system.
  • The user interface was improved for tablet and touch interface devices.  An example of this is the use of an accordion-like interface on the left side panel of the patient chart where a user has quick-click access to the pertinent medical history of the patient.
  • Visit types for the scheduling system are now configured per provider instead of per practice.
  • HCFA forms are now up-to-date to the 02/12 version which is what is required for insurance claim compliance on April 1, 2014.

Happy NOSHing :)

Leave a comment

NOSH In The Cloud

If you are a medical provider looking for a turnkey solution that won’t break the bank and think that installing NOSH on your own is too daunting of a task, I have great news!

There is now a new option to be able to use NOSH ChartingSystem.  I call in NOSH In The Cloud and it is NOSH ChartingSystem fully implemented in a HIPAA-compliant cloud server (Amazon EC2, for all the techie folks).  This version of NOSH is every bit identical to the one that you can download yourself and install, only that you don’t need to buy any computer hardware or worry if you need to fix it should anything fails (like hard drives, motherboard, memory, and an IT person, etc.).  You also get the benefit of automatic updates and an unlimited number of support users (like assistants, billing specialists, and most importantly, patients).  The cost is a simple $50 per medical provider per month.  Furthermore, being a NOSH In The Cloud user, you automatically belong to a community of medical providers who aim to create a better world-class EHR together without being encumbered by Meaningful Use attestations and the cost of buying an expensive, difficult-to-use, EHR.

Click here to get to the NOSH In The Cloud site!


Why EHR design matters

Besides the importance of physician happiness when using an EHR, using design principles that maximize user intuition and presentation of relevant information, there is one aspect of health care information systems that should never be overlooked…patient safety.

Scot Silverstein, MD, blogging at Health Care Renewal as InformaticsMD, frequently brings to light issues surrounding health care IT implementations that compromise patient safety.  Reading his posts should be sobering and concerning to both medical professionals and the public alike.  Like I’ve said, health care IT, in my opinion, is still in its infancy despite the number of years computers have been around and the existence of Meaningful Use legislation.

As a practicing physician as well as a software coder, I’ve used a number of EHR’s (and still currently using a well known EHR by my employer of my part time job) to know how some of these appalling user interfaces affect not just workflow and user happiness, but patient safety.

An example of one design element that most physicians may not be able to identify, ironically, is the one that is most harmful when it comes to patient safety. In this well known EHR, you are presented a medication list for a patient. As a physician, you assume that this list is a current medication list and is up to date.  However, the reality is that this EHR system automatically removes a medication from the list when it is determined to be expired even if it should be appearing on the current medication list. When a physician prescribes a medication from this system, it calculates the duration of usage of the medication based on the instructions, quantity of medication prescribed, and the number of refills. Once the duration exceeds the number of days that has elapsed since the prescription was made, the medication is taken off the current list automatically by the EHR. Now, taken at face value, this sounds like the logical approach to manage a medication list and utilizes the computing power that an EHR will gladly show off as a benefit to physicians.

Unfortunately, the EHR programmers failed to understand that medications are not taken regularly by all patients all the time. In fact, no physician assumes that at all. So why should an EHR make that assumption? Furthermore, there are plenty of treatments that are to be taken only as needed so how can an EHR account for that? Absolutely, impossible.

So I recently treated a patient that reportedly has asthma. I happened to look at a previous note and find out that the patient was denied a refill request for Albuterol, a bronchodialator that is meant to be taken as needed. She ended up in a life threatening asthma flare up and needed emergent care. It turns out the physician on call who was given the refill request several days prior didn’t realize that the EHR removed the Albuterol from her list and subsequently instructed that the patient needed to have a physician visit for having the medication prescribed. After going through 2 different windows and unclicking a check box, I was able to identify that the patient did in fact have an active prescription for Albuterol, but the EHR made it disappear. She has used it infrequently, probably because her asthma was well controlled. Unfortunately, she ended up in worse shape when she needed the medication the most.

Most physicians don’t have the time nor the technical know-how to peer through a complicated EHR. Perhaps I normally don’t trust the EHR because I’ve be jaded by bad designs and because I know how to hack around a system when a bad design didn’t give me the information that I want. But this example highly illustrates that a poorly designed EHR that has not gone through a reality test with a practicing physician leaves patient safety in harms way. I ultimately find it appalling that physicians are being peddled multi-million dollar systems that have not had any real practicing physician input in how these systems are designed.

We are beginning to see studies that question the effectiveness of EHR’s when it comes to health care cost reduction and patient safety. One should not make a general conclusion that all EHR’s don’t help, are a waste of money, and have no place in health care. What gets lost in the translation is that an electronic health record system is not the same from one system to an another. Some do a better job than others. What doesn’t get studied is how physician directed user design can affect these results. From other industries where user design is absolutely paramount, including automobile and airplane ergonomics as well as smartphone operating systems and their apps, we know how improved and user informed design makes all the difference in terms of quality output by the user. It’s all about using the right tools for the job. If it can be used intuitively, reliably, and repetitively, you have the right tool for the job. Right now, most EHR’s are like sledgehammers when what we really need are sharp chisels that create works of art.

Leave a comment

Tags, tags, everywhere tags!

Another release of NOSH ChartingSystem is out in the wild.  In version 1.7.2, there are significant changes and exciting new features that are worth mentioning.

As stated in previous posts, one of the new features of NOSH is the ability to record tags in various elements (encounters, telephone messages, test results, documents, appointments).  A tag is any defining keyword(s) that a medical provider can designate to help organize common traits between patient charts or medical history.  This is similar to the idea of tags, if you’ve used Evernote (on your Android or iPhone) or set up a blog (like on WordPress).  Currently, the only defining characteristic (or element of a medical chart) is the diagnosis code.  But being that it is only one characteristic is truly limiting.  A patient is more than just a diagnosis.  A patient and the relationship between the provider and patient is truly an organic process…an EHR that only defines the encounter in just one defining aspect like a diagnosis code is a great disservice to practice of medicine.

By having tags utilized, one can see not just the whole aspect of the patient, but the practice too.  Perhaps my view of tags is limited, but another provider can utilize tags in NOSH to whatever use they want.  Once you have a few tags under your belt, go under the Office link on the top, you can query their tags and identify these elements and see them (viewing the encounter or PDF document, for instance) from the patient’s chart.  There really are no constraints to the idea of tags and how they can be used.  Go ahead and try in the free, fully functional demo on this website!

Another new feature that is incubating right now is the ability to integrate with PeaceHealth Labs.  It is currently in the works but it is a first in the series where NOSH will be able to fully parse and receive HL7 messages to any number of lab providers.  But it will only work if I get a community of users so I can work with these labs (which use their own HL7 formatting, unfortunately) to make it work right to a wider number of users.  In the next set of posts, I’ll be talking about why open source development is a key solution to some of our most pressing health care problems.  And the cool thing is that open source invites and brings together both users and developers to make a good product even better.

Here is the change log for 1.7.2 for those who what to know more about it!

* New Feature – Tagging features available for Messages, Telephone Messages, and Encounters.
* New Feature – Ability to save CPT favorites and default units for a specific CPT code.
* New Feature – Ability to search for active supplements in super query.
* New Feature – Ability to view and chart electronically downloaded lab results.
* New Feature – Direct interface with PeaceHealth Labs.
* New Feature – Patient reminders automatically sent upon creation or change of a future appointment.
* Update – Reworked code to allow for more than 1 practice in a NOSH instance.
* Update – Ability to enter new password whenever a new user is added.
* Update – Clicking on a grid header will open and close the grid instead of just clicking the arrow.
* Update – Orders summary now includes specific instructions for supplement orders.
* Update – Provider signature editor incorporated in provider user configuration dialog in dashboard.
* Update – Reduced redundant search entries for medication dosages when performing autocomplete.
* Fixed – Error with billing compiling when there is an empty procedure CPT code.
* Fixed – Error with saving bills under Assistant user level.
* Fixed – Some printing errors when no billing is assigned for an encounter.
* Fixed – CPT grid not loading correctly in configuration when Billing tab is opened in encounters.
* Fixed – Super query not searching active medications or issues.
* Fixed – Addendum encounters keep reappearing when encounter initiated by assistant user.
* Fixed – Some large batch HCFA-1500′s with numerous CPT codes were not printing properly.
* Fixed – Billing elements not saved properly with PHP error codes with numerous CPT codes and diagnoses codes.
* Fixed – Display and button alignments of ROS and PE dialogs not compatible with certain browsers and devices.
* Fixed – Dashboard page not logging out after 30 minutes of inactivity.

Happy NOSHing (and hopefully you had a Happy Thanksgiving too, and a big NOSH to boot!)!

Leave a comment

Shut out, shut up, and shut down

I’ve been tracking the troubled launch of and I was surprised to find some disturbing themes as we learn more about what led to the disaster.  Aside from all the political rhetoric (which I won’t go into here, as I find it irrelevant) and the vague and shallow analysis that is predominant in the mainstream media, I came upon several blog articles that went into some meaningful discussion about why this happened and what can be done to prevent it in the future.

Shut out

One interesting post comes from Clay Johnson, who spent 6 months as a White House Presidential Innovation Fellow, who talks about the procurement process and how federal and state governments complete aversion to risk produces a bidding process that all but nixes out the best and the brightest minds and technological companies at a major cost to the citizens of the country.  A shocking statistic is that more than 90% of projects that cost more than $10 million ends up failing.  In his post, Clay Johnson states that the process is riddled with practices such as these: pre-approved vendor lists,  6,500 pages of regulation, cumbersome business registration processes, and hostile bidding environments.  All of these practices practically ensure that vendors that cater to the government and know how to cut through the red tape (because it’s their specialty, not because they know how to make innovative products) are chosen for new projects, even if the older projects have spectacularly failed.  In my world in clinical medicine, I’ve heard from several government-related officials about IT infrastructure  and implementation disasters (health and human services documentation systems, immunization registries, and even electronic health record systems for county-funded clinics).  I never knew exactly why these disasters kept affecting government-related projects, but now it seems much more plausible that it’s not just pure dumb luck (or the lack thereof).  It’s about the inadvertent shutting out of the best and brightest in an antiquated and mis-guided procurement process.

Shut up

Robert McMillan’s article in Wired, talks about how the open-source code for the front end (the part that people see when they visit was removed from GitHub (where the large majority of open source code, including NOSH, is stored) was one of the few aspects of the website that actually did work as intended.  The GitHub site was also where many people sought answers to why was not working as expected.  It became clear through those discussions that it was the backend, which was closed and proprietary, that was at fault but there was no one that could answer for these issues.  So the Centers for Medicare & Medicaid Services simply just shut down the GitHub site.  I personally don’t think this was the right thing to do, especially in the spirit of open source.  Even if one concluded that the problem was found to be a part of the backend, wouldn’t it be helpful for those that are implementing and managing to know what other’s think of the problem?   I don’t think anyone really knows what CMS was thinking when they decided to pull their GitHub site, but thankfully, in the spirit of open source, someone forked the code and there is now a new GitHub site with the front end code.  The one thing about open source code is that nothing every dies, even if you want to shove it back in the closet never to be seen again.

Shut down

And where it all seems to fail is this concept that we’re building a contraption that has so many parts that even though only one part of it is open source and the rest is not, it’s just not an open source project.  Period.  Kin Lane writes about how the lack of transparency is the overwhelming flaw  in this project.  A term that describes this is called openwashing

Openwashing in government is spin that deceptively promotes IT projects and policies as “transparent” and “innovative” when actual practices and spending are not.

Open source code is just one aspect of an open process.  And that also includes the procurement process and its lack of open-ness that starts it all.  Imagine an alternate reality where all the synergy of collaboration and energies are spent in a transparent, open process along with open source code.  It’s process as if people mattered, both in the developmental process and in the delivery of services to help people.  Perhaps that is why I’m passionate about open source computing, and in fact, even open source health care, if there is such a thing.  The more we exclude, the more we hurt ourselves.  I feel that the is a perfect case study in what happens when you have a process that is non-transparent, exclusionary, and closed-minded.  In effect, shutting out, shutting up, and ultimately leading to a shut down.


Get every new post delivered to your Inbox.

Join 154 other followers