NOSH ChartingSystem

A new open source health charting system for doctors.

Open Sourcing Healthcare

Leave a comment

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.

 

Advertisements

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:

WordPress.com Logo

You are commenting using your WordPress.com 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