NOSH ChartingSystem

A new open source health charting system for doctors.


Leave a comment

Open Sourcing Healthcare

One common question I get since I started NOSH ChartingSystem is why I decided to release it as an open source software project.  Naturally, some providers who are new to computer and software technology ask what makes open source projects different from say the “traditional”, closed-source licensed software.

Those unfamiliar with open source software would rightfully have a stance of fear, uncertainty, and doubt (FUD) about a project that allows people to download and install a program at will without having to pay a penny if they don’t want to.   If that applies to you, that’s OK…I’m as skeptical as you are too.  So below are some likely questions and concerns you would probably have and which I’ll be addressing along the way in this post…

  1. If it is open source, does that mean that my patient data is open for others to see?
  2. If it is open source, is it more prone to viruses and security breaches?
  3. If it is open source, does that mean I will not get any support currently and in the future?
  4. If it is open source, is it inferior or “beta” compared to other software products?
  5. Is there a catch if it is “free”?

And you know, these are perfectly reasonable assumptions and questions that not too long ago, other non-healthcare related industries had been struggling with.   To get to the point, I would argue that the concept of open source is quite complementary and synergistic with what physicians idealize as what healthcare ought to be.  And that’s coming from someone who is trained as a physician and who also happens to dabble in software coding.

I’ll start by pointing out this excellent editorial called “Open source and the ‘fear factor’ mentality” from several years back that is quite relevant today.  One of the key points in this post includes the concept of peer reviewing the work of the software code, which I will refer to as the part of the system that processes the data that eventually gets saved into a database and how it gets displayed for a user to see.  One cannot do this easily in a closed source environment.  In medicine, peer reviews are the standard for which we review articles published about new or updated medical findings and treatments. Can one imagine what our medical education system and our current healthcare system be without a peer review process?  Likewise, the implications of this reality in the software world is quite important.  For if there was a problem with the code for any reason at any time, others could not interpret and identify the problem for a fix.  You’re completely are the behest of the original software developer(s).  A real-life example that occurred recently was during the rollout of the Healthcare.gov enrollment website.  The front-end, where users sees and interfaces with the website, was an open source software project.  The back-end, where the data processing occurred, was a closed-source, proprietary affair.  What happened immediately after the initial failures of the website was that many software developers around the country and around the world were able to accurately deduce that the front-end was working as expected and they were able to test it repeatedly in different environments with the same results.  This was because the software code was hosted on GitHub (the same site where NOSH resides) so everyone could look at it, inspect it, use it, and test it in different environments.  The same could not be said of the back-end, which ultimately was the problem and it took a lot of manpower and money to identify these issues and fix them.

One aspect that I quickly explained previously was what software code is.  And this is the key distinction for those who are unfamiliar with technology.  The software code IS NOT, and SHOULD NOT CONTAIN any data (and that includes personal and patient data).  The code is a set of instructions for how data is entered, saved, and displayed.  So when a software project is released as open source, all that one sees on GitHub is how these instructions are carried out.  One could learn from looking at the code how the data is structured, but it does not give anyone access to the data elements themselves.  So, to answer the first question, your patient data is still yours and is as secure as any other software product, open or otherwise.  Data security is still ultimately dependent on having a secure server, with good passwords, and keeping passwords and keys private…these are what I refer to as good, common sense, data security practices.

Subsequently, some of you might think that because these instructions are available for others to see, it’s more easily “hacked” than proprietary systems.  As noted in the guest post referenced earlier, just because it is closed sourced software doesn’t mean that it is impervious to being “hacked”.  Hacking, by and large, is going to happen no matter what.  The primary thrill for hackers, though, is being able “reverse engineer” a closed product, because it’s essentially a challenge.  It’s not much of a challenge for hackers to have a “cheat sheet” where the code is fully given to them.   Furthermore, hacking will not work if you operate on good, common sense, data security practices.  Yes, it seems to not be congruent to what most people initially believe when they think of open source products because people have been given a mistaken perception (from years of closed sourced software propaganda) that “open source” is a “hacker’s heaven”.  But if you understand the nature of hacking and what drives them to do what they do, it makes perfect sense that open source projects are less vulnerable to hacking and being targets to hackers in general.

One of the benefits that closed source and proprietary systems bank on is the perception that the end-user and clients will receive unquestioned support for the product they purchased.  While that may be true for the short-term, long-term support does come at a price (and sometimes quite hefty).  Furthermore, if the software company should discontinue support (for a real life example, look at the recent discontinued support for Microsoft Windows XP) or if the company shuts down, the software code is forever lost or gone.  You cannot “reverse engineer” your product that you purchased (unless you want to become a hacker!) to adapt to future changes.  You’re literally on your own.

To be fair, support of any kind (open or closed) does cost something.  That is the cost of ownership and being able to customize your tool for your own use.   The nice thing with open source software is that YOU get to dictate what kind of support YOU want.  If you’re a minimalist and really out of cash, you could download the software, install it on your computer and run it to heart’s content with minimal cost.  Of course, if you don’t have computer software experience and you want to customize your software, you’ll need to pay for some support and assistance.   Ideally, that assistance is from someone who has had the most experience with the project and who originated the code.  But because it is open source, and if any other software developer can read the code on GitHub, it’s very likely that others could learn and provide assistance too.

On the other hand, if you (or someone who works for you) have some ability to read and modify software code, and you want to do it yourself, you could do so without voiding your license.  All we (open source advocates) ask in return is that you contribute back to the original project (it’s voluntary, of course, but in the spirit of paying it forward, you’ll probably know that it’s the right thing to do).   The open source software code never really goes away.  For instance, for the front-end code for Healthcare.gov, the government tried to remove it from GitHub initially after the initial failure of the website, but someone already forked (copied) the code to another project site, ensuring its continued existence. Likewise, my NOSH code is my gift to the medical community.  Even if I stop development or disappear, my work will continue to exist.  I give you full license to do what you wish with the source code.  And if you like it, thank you!  If you don’t like it and want to make it better, thank you even more!  In fact, open source software is more than just about how one licenses a software product.  It’s a movement.  It’s an ethical and humanistic announcement with the idea that everyone can benefit from shared knowledge and that a group of contributing individuals can make significant, meaningful,  achievements in ways that are much more profound than if just one person or organization can produce.

To me, open source software code is like a medical textbook.  One could pay a small fee to access it and read it and keep it.  And then you can share that knowledge to others and perhaps that knowledge can spur someone else to come up with a new idea to advance a new medical treatment.  That is the spirit that has carried our profession to great advancements in the past century.  It is the same spirit that drives the open source community.  If you’re looking at advancements that open source computing has provided in the past few years, I’ll list off the big ones.

  1. Google, including the Android smartphone
  2. Social media technologies, such as Facebook, Twitter, Tumblr, and Reddit
  3. Web browser technologies, such as Chrome and Firefox
  4. Apple (yes, Apple)…they significantly benefited from open source software technologies (such as their operating system, virtual machine technologies, web browser technologies)
  5. It goes on and on...

 

Switching gears, I’d like to address the issue of perceived inferiority of open source software solutions compared to proprietary solutions.  In the medical profession, we expect things to work as it should.  We all lead busy lives and we don’t need distractions to keep us from being productive and being available for our patients.  It is reasonable to expect that we should not settle for inferior and mockup products that do not work.  On the other hand, just because a software solution is proprietary does not make it “bug-free”.  And if there are bugs in the system, which solution is going to have these addressed in a timely fashion?  The answer depends on how active the user and developer base for both open and closed solutions.  Furthermore, there is a perception that anything that is “beta” is not worthy of consideration as a tool.  But let’s think about it by taking a step back…some of us are more willing to work “on the fringe” or on the “cutting edge” to see where the technologies can go.  If you fit that description open source is a very viable option.  Sure there are some things that do not work quite right currently, but with most active, open source projects, most fixes happen very quickly.  If it were not for those of us on the cutting edge, we would not be able to make new advancements in medical treatments possible.  (That’s what clinical trials are called, likewise, we have “beta testers” in the software world).  In a closed source system, those clinical trials are very limited in scope.  In an open source environment, we have testers using different systems to make sure it works right in most environments, not just the one that is called for by the developer.  With that in mind, what kind of system would you prefer…a system that works only in a limited environment or one that works and has been tested by many others in many types of environments?

Perhaps the only catch for choosing an open source software project over a closed source product is that the success of the project entirely depends on its users (the physicians) and the amount of contributions as well as the moral and monetary support to the project.  It is a type of product that expects feedback from its users and in return it gets better and better.  The viability of the product is not dependent on keeping your data hostage in return for continued support.  It is a community and peer driven project that aims to make a great tool for physicians so that we can be better doctors to our patients.   If you feel that you’re still skeptical or that your healthcare aims are different, I understand.   However, if you feel that the open source ethos resonates with you as a physician, please join me in any way that you want (or can) to this project to make it better!

In my opinion, the healthcare sphere is fairly behind the open source bandwagon in many significant ways.  I think this has to do with the nature and the working assumptions of the current leaders of health information technology that believe that closed-source, proprietary technologies are the best way to go, and informing the customers (the physicians) that this belief is the truth.  I firmly believe that the large, monetary clout within the closed-source, proprietary companies will make sure that their message will be heard more by physicians than the less organized, relatively less profitable open source developers/contributors.  After all, money speaks these days.

But as physicians, we must be skeptical of these assertions (from both closed and open source entities…yes, be critical of my blog post!).  Review the evidence and not just what the salesman, magazines, editorials, and organization leaders just say about it.  I believe that you’ll agree that physicians in general have been feeling “duped” lately with the recent Meaningful Use legislation and that even though some of us had made great sacrifices in making large investments in an closed-source, proprietary system and that some of us didn’t make this investment decision in an informed fashion and that we did out of compliance or because of the “everyone else is doing it” mentality, which is not a really good way to make a very important decision for your practice.

For some of us who have not jumped onto the Meaningful Use bandwagon, we are still wondering what our healthcare system will be like in the next few years.  For sure, it is in a midst of great transformation but it remains unclear whether it will be a positive or a negative outcome for our profession and our patients.  What we can do, as physicians, is to try to get back on our saddles and be firmly in charge of our destinies during this wave of change.  One way to do this is to fully embrace and not be afraid of open source technologies for our healthcare system.  A lot of what defines open source software is already an intrinsic value in our healthcare system and medical education system.  We just have not embraced this same model for our software technologies.  The question then would be, “Why not?”  Perhaps with this small step, we could encourage increased adoption of technologies at our own pace, in our own way where physicians have a say in the design and implementation of software for our needs and not for others.  With this small step, we embrace collaboration over monopolistic competition.  And with this small step, we can dictate how we can best input that data and what data gets to be collected and that the data remains secure and not in the hands of third parties that can aim to divide us between physicians and patients.  Disruptive innovation is a catch phrase these days, but I feel that it is quite apt to use this term if physicians were to adopt open source methodologies and technologies into the healthcare IT sphere.  After all, the current status quo in this sphere is currently anything but open.

 


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.

Templates

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 🙂