NOSH ChartingSystem

A new open source health charting system for doctors.


Leave a comment

What would a patient-centric electronic health record look like?

Electronic health records, historically, have always been provider-centric.  Providers, by definition include medical providers, clinics, or hospital entities.  EHR’s are housed and maintained by the provider and the data is “owned” by the provider itself (although sometimes that is debatable depending on what type of EHR vendor you use).  As an extension of this, all billing is done in a provider-centric way and historically, EHR’s were an extension of an existing practice management system framework.

But one of the main stumbling blocks of such a system of siloed provider-centric electronic health records is interoperability.  Even with “open standards” such as the C-CDA, vendors have different “versions” which render the whole idea of interoperability a joke.  If a patient goes to one provider with one EHR, but doesn’t talk to another provider with another EHR, imagine the potential problems this would be.  Lab test results, past documentation and hospital visits are not ideally centralized.  This potentially leads to ineffective and inefficient use of health care resources.  This leads to, at best, duplication of treatments and testing and at worst, causing harm if there was an undocumented allergy (for instance) that didn’t get transferred from one EHR to another.  Interoperability could have come a long way had Meaningful Use focused on this rather than doing “un-meaningful” approaches to encourage physician adoption to use an EHR.  So, I don’t see this as being a reality or being addressed any time in the near future.

But what if we turned the framework upside down (in the patient-provider relationship) and make the EHR patient-centric?

In a patient-centric EHR scenario, the patient would house and/or maintain the EHR for the patient and the data is “owned” by the patient.  Any provider who sees and treats the patient would input the data into the patient-centric EHR, thereby centralizing all the up-to-date data in one place, available, all the time.

In a patient-centric EHR scenario, this would take the concept of OpenNotes one step further (which, by the way, NOSH already has functionality  for through it’s patient portal feature).

As I was developing NOSH as a provider-centric electronic health record that happens to have a patient portal, I didn’t initially realize that the foundations I set for the NOSH code and database schema, especially now that it has been cleaned up with nice Laravel code, is also primed for a patient-centric EHR.  All that it needs to operate NOSH as a patient-centric EHR is the installation routine where the practice is not set initially, but the patient itself.  Because NOSH was not developed from a practice-management billing system, it’s very easy to decouple and reuse the existing code to make the transition into a patient-centric EHR very easy.

Furthermore, to limit the impact on non-clincial provider workflows such as billing, supply inventory, and population health analytics (which NOSH already handles out of the box), the provider would then install a NOSH version that remains provider-centric in the sense that it has a way to access all of their patient’s NOSH accounts through a provider ID (say the NPI number) and secured through a secret key associated with that provider ID which would then automatically input the provider’s data/practice into patient’s NOSH once and authorized by the patient.

So in essence, there is a patient NOSH and a provider NOSH and they would interoperate cohesively.  To recap, these are the potential benefits of a patient-centric EHR:

  • No interoperability issues
  • Centralized medical health information, including C-CDA’s
  • Limit duplication of treatments and tests
  • Potential cost-effectiveness of care

Of course, no idea comes without its challenges:

  • Potential extra work for providers to enter their practice information for a new patient.  However, having the API’s to connect between the patient and provider-centric EHR’s should mitigate this barrier.  Having well-documented APIs and keeping them open (through open source licensing such as NOSH) and non-proprietary from the patient-centric point of view should allow current and legacy EHR’s to connect for those who have already bought into expensive EHR technologies.  The idea of a strict, but open, API versus an open standard like a C-CDA is that the API approach literally guarantees interoperabilty if EHR’s or practice management systems choose to play nicely.
  • Existing technologies for ancillary medical services (lab, pharmacy) may need to be reconfigured for each provider.  However, with the recent HIPAA ruling going into effect currently, lab providers must allow patient access to the lab results.  Should this be done through a patient portal of sorts provided by the lab service, a patient-centric NOSH could then scrape that information, stored in the patient-centric NOSH with API access from the provider.  This may be an efficient workaround, bypassing the current hodgepodge of expensive, proprietary connections between various lab providers with legacy EHR’s.
  • This system is only as good as the percentage of healthcare providers that adopt and use it.  Current mandates through Meaningful Use achieved increased EHR adoption (primarily in the hospital and academic realm), but many physicians in both the inpatient and ambulatory realms are quite upset with the choices they have to make with lackluster user interfaces and significant disruptions to workflow and productivity, and unrealized return of investment.  The backlash was quite predictable.  However, offering an alternative avenue through positive patient engagement, especially with the youth and young-adult sector who are quite tech savvy , this may provide a non-punitive, non-paternalistic method of electronic patient record documentation adoption.

This positive, virtuous cycle, with the patient-centric EHR as the core foundation, would be this:

Patient signs up for a patient-centric EHR that is housed in a secure, cloud based server.

Patient goes to Doctor who may or may not have an EHR.

Patient asks Doctor to enter his encounter documentation into the patient’s EHR.

If Doctor has NOSH already, patient provides an encrypted API key to Doctor to access patient’s NOSH.  Doctor associates this encrypted API key to the patient’s NOSH chart and any notes generated on Doctor’s NOSH automatically is synchronized with patient’s NOSH.

If Doctor has EHR “X”, and the EHR doesn’t have a way to send information via the patient NOSH API, Doctor has several options:

  • Enter into patient’s NOSH anyways through a secure sign on process and bypass his current EHR. Doctor would then just enter billing information into EHR “X”.  Doctor might feel compelled to ask his EHR “X” to create code to access the patient NOSH API and point to the documentation provided to synchronize information between EHR “X” and patient NOSH to make Doctor’s life easier.
  • Doctor could ditch his old EHR completely (if the Doctor can do it without going broke) and adopt NOSH in the Cloud or set up NOSH on-site for his own practice.
  • Doctor could just install a basic practice management system and not have to keep any patient documentation on site however, this would limit Doctor’s ability to do any healthcare analytics for the practice.

If Doctor says “No, I don’t want to put my encounter documentation into your EHR”, the patient would likely say, “Then I’ll go somewhere else.”

 

The one benefit that NOSH can provide as a provider-centric EHR is the fact that the client user interface (either a provider or the patient) can be accessed by any device or operating system as long as there is a modern web browser and an internet connection.  Housing the patient-centric NOSH service could either be a cloud-based solution versus a low-cost, portable, appliance that the patient would have to maintain.  Being open-source allows peer review of the code to provide continuous improvement to the system and it would carry all the benefits of having provider-specific templates.  After all, being an open source licensed and non-certified EHR, NOSH is free to move into a patient-centric EHR domain, if it’s feasible without major reworking of the code.

Very soon, these ideas will become a reality.  Does anyone have any thoughts or any thing to add to the benefits and challenges list? Feel free to make a comment!

 

 


Leave a comment

Features of the Day: HEDIS functionality and notifications

Having an EHR is not just being able to merely document patient encounters and bill for them.  The real value of an EHR is what can you do with all the data put into it.  The returned data has to be meaningful to the provider and not just in the framework of billing and RVU productivity.

So one of the things that NOSH can do well is to simply query the database; the layout of NOSH’s exclusively simple database schema allows a NOSH user to able to glance in a patient’s chart or for the entire practice a snapshot of HEDIS, short for Healthcare Effectiveness Data and Information Set.

HEDIS core measures are generally being used by insurance companies to determine effectiveness of healthcare outcomes for their patient panel.  Although I hesitate to fully endorse HEDIS because of my concerns about the potential conflict of interest of NCQA (the agency that  developed the HEDIS core measures) and its association with managed care companies, I do feel that in the absence of any alternative health care effectiveness measurement system or criteria, HEDIS at least has published and relatively clear definitions of what these measures entail and how it gets measured (which makes my software coding job much easier).  And hence, I’ve included a HEDIS audit functionality in NOSH so that if you were a provider trying to track down effective interventions in your practice panel, then it can be done.  It probably won’t be endorsed by NCQA, but at least some built in tool that is simple to use rather than doing your own complicated search queries in your EHR, including NOSH, can be a powerful method to help improve patient care, especially in primary care.

HEDIS, being targeted to the managed care industry, has a very different aim than that of a stand alone primary care clinic.  In particular, the set of HEDIS measures that is specific and helpful for primary care clinics is the domain of care that is defined as “Effectiveness of Care”.  This is what NOSH aims to measure.  The current implementation of HEDIS is also problematic for providers in that there is a very poor feedback loop to identify patients or encounters that fail to meet the core measurement standards.  All the data is going to  the insurance companies and the end result is typically rewards (or lack thereof) for pay-for-performance programs.  Money aside, most providers (I think) would rather like to know what needs to be rectified to meet these measurements in the future.  The problem is, most providers find that getting feedback data is difficult to understand and then on top of that, how do you target those deficiencies to improve them?  What’s the point of measuring if it doesn’t help to prevent future issues or negative outcomes?   It’s tedious and very old school and certainly not provider friendly (sounds like most EHR’s to…doesn’t it?).  Can’t we do better?  So here’s my answer and it comes in the form of a NOSH functionality called a HEDIS audit.

NOSH, by design, allows HEDIS data gathering to occur seamlessly and with just a click of a button, you can get a HEDIS snapshot for your practice (as seen below):

HEDIS screenshot

 

As you can see, in addition to a very clear listing of each measure, you’ll get a percentage for your practice and then on the Rectify column, you can identify which patient need to have this addressed, if applicable.  You can then set a nice, polite alert for yourself for the patient to help you recall what needs to be changed, if any.   If you need more detail, you can see the HEDIS auditing on a per patient basis as seen below:

HEDIS screenshot 2

And NOSH won’t berate you or barrage you with a whole bunch of multi-colored alerts and flashing lights, or prohibit you from doing something because you didn’t meet all the HEDIS core measures.  All you see is a HEDIS Audit link in the left hand side…one click is all you need to get the information that you need, so you can do your job (and mine as well), which is taking care of patients and doing it well.

Just like the patient portal and online scheduling features, NOSH does this in an intuitive, non-intrusive, and simple approach that is user-friendly without information overload for the provider.  NOSH doesn’t need clunky third-party services that may or may not fully integrate with the EHR to get the data return that you need.  And best of all, you can use the fully featured live demo to try it out.

Speaking of alerts, NOSH also now has the functionality to provide chart notifications that pertain to alerts due on the day that you open the patient’s chart or appointment notes.  What’s appointment notes?  Well, it’s a very simple, yet powerful, field that you or your assistant can enter for the patient’s appointment in the scheduling window.  You can use it to communicate with your staff about the status of a patient as the appointment is occurring.  Like tags for NOSH, you can do anything you want with it!   This can include whether a patient is going to be coming in late or a room assignment or when the patient is ready for evaluation after getting vital signs, for example.  It’s only limited by your imagination.  And with the text template engine built-in, you can use your own personalized text phrases, easily setting these notes on a click or by typing it out.  And then whenever an appointment note is set, and a provider has his/her patient chart open, the note will pop up as a small, discrete notification (known as a Growl for Mac users) on the upper right hand corner.  Like this…

Growl

So I urge you to check it out for yourself on the fully featured live demo.  And if you’re looking for a no-hardware-hassle solution, check out NOSH in the cloud.  It’s always up-to-date with all the NOSH goodness.


Leave a comment

Defending our dignity…doctors must embrace EMR technologies on OUR terms

A pivotal moment in the US health care system is taking shape. Physicians across the US are wondering what their role will be in this new healthcare landscape that is being shaped by legislation (from the Affordable Care Act and from Meaningful Use), by social media, and by technology advancements.

It’s an existential moment. Physicians are wondering if we are knaves, pawns, or knights in this chess game called the US health care system. Physicians are screaming to be heard on major news outlets about the perils of being a primary care physician in the face of increasing pressure from health care executives, insurance companies, unfunded government mandates, and so on. Right or wrong, physicians are in the middle of this changing and impactful landscape and we can choose to be leaders of this change or be succumbed by it.

But where do physician’s start? Speaking about it is a start and as such, it’s good to hear that some of the major news outlets are starting to speak about the inevitable horrors that the country will face when we realize that primary care (when measured in workforce numbers as well as moral support) has been neutered for decades in a fee-for-service model that inadvertently favors procedures over prevention and face-to-face time with a patient.

However, speaking about it alone will not change the way the game is played. Some have argued that those that have the current leverage (health care executives for instance), have the tools, money, and experience necessary to play the long game politically. For as long as the field has existed, physician training has been focused on medicine, pure and simple. But rarely has there been education and awareness about how our field could be pushed aside by others outside the field, perverting and distorting the health care delivery system that used to exist. As a result, we (physicians and patients together), have succumbed to the system.  We have become divided by the system.  And now we have essentially become pawns in the health care delivery game.  As physicians, like to think of ourselves as knights, noble guardians of the profession, speaking about how we should reject the sliding slope of EMR technology as the tool that will bring our profession down. But in fact, the robbery has already happened. It reminded me of an amusing skit on the second season of the Muppet show (which I was watching with my kids recently) where Sam the Eagle speaks with dignified presence behind the podium about increasing crime.  Sam speaks about how it is important to be vigilant about stopping crime whenever and wherever it lurks, while completely unaware that three robbers are stealing and taking away the props on the stage, eventually the podium, and then Sam the Eagle himself. Have we become, as a profession, Sam too?

Sam the Eagle speaking about crime

So as we ponder our existential question and hope that we do not become permanent pawns in this health care system chess game, I strongly urge that we do not shy away from EMR technologies entirely, irregardless of your disgust, familiarity, and experience with EMR’s.  Yes, we have been bamboozled and bullied into to buying EMR’s that don’t respect our clinical workflows with Meaningful Use and we have been insulted by the insane measures of how we ought to be using these EMR’s.  Yes, most EMR’s really suck right now and no one is going to listen to us gripping and complaining, because we’re not (despite our belief that we ought to be) their ultimate customers.  Most would unfortunately care less about how we think EMR’s are unsafe and unsatisfying to use.  It’s not to say that these are not important issues (it should be!); it’s just that the game has been deliberately rigged where physicians are no longer heard anymore about this realm because we have become irrelevant (gasp!) in the realm of health care technologies.  Shying away from these technologies and outright rejecting it does not make it go away, nor does it empower us.  We must embrace the these technologies with our eyes wide open.  Embracing the latest technologies and knowing their limitations and potential benefits is a sound strategy by any player in a game (such as our health care system chess game) as long as the tool is designed and optimized for the player.

As we speak, EMR’s aren’t really designed for us but it doesn’t mean that the door is shut.   Embracing open source software technologies and projects which encourages participation and input from any or all physicians in the design and implementation of an EMR design, resulting in increased transparency and adaptability for the tools that we use, can be seen as a vital weapon against those that choose to sidestep our profession.  As some disgruntled and primary care physicians who have stepped out of this health care system chess game and done it on their own terms  (such as Direct Pay Practices…hooray for them!), physicians as a group must also set the standards and technologies (especially where it comes to usability and safety) for our EMR’s on OUR terms.  By doing this, we stake our ground, and make others know that we’re not going to be stepped on anymore.  Our dignity for the profession is not just merely reflected in our spoken words, but it is reflected in our actions.


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 :)


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!

Follow

Get every new post delivered to your Inbox.

Join 171 other followers