NOSH ChartingSystem

A new open source health charting system for doctors.

Leave a comment

More EHR Pet Peeves

I just can’t stand it…I just have to vent.  Because it happens nearly EVERY DAY!

I’m a clinician day in and day out and I have to see past lab reports generated by an Epic EHR which are faxed over to me.  Yes, in these modern times, we still have to get a fax; because as a small clinic, you just can’t afford to get Epic and to have CareEverywhere…so much for Meaningful Use and being in the year 2016!)

So, I’m looking for abnormal values and I see them.

But there’s a problem.

Epic highlights these values in a shaded color (I have no idea what color it’s supposed to be because it’s printed in black and white).

Then you fax this paper to another clinic and it gets even more pixelated to the point of illegibility.

And so all you know is that there’s something wrong but YOU CAN’T READ THE VALUE.

I have to take the extra time to call the clinic to get the numerical value and normal ranges, VERBALLY.

Really, in this day and age?



1 Comment

It’s Alive!

A concerned follower asks:

Is NOSH dead?

And here’s my reply:

More than being alive, here’s a preview of what’s to come with NOSH in this recent conversation with other physicians: Adrian Gropper, Michael Mascia, and Peter Elias.  We’re talking about “One True Record” #onetruerecord and where NOSH fits into a patient centered electronic health record.  And there’s going to be a mobile version that is in the works which is fully integrated into NOSH.  It’s really exciting and ground breaking stuff.

Lastly, I apologize for the radio silence…it’s hard to blog, code, see patients, run a clinic, and be a dad all at the same time.  But I’m certainly here and I’ll be posting more soon.


1 Comment

New Feature: Timelines

As an open-source project, NOSH gets inspiration from a variety of physician-led ideas.  Actually incorporating them in the ethos of keeping NOSH simple and easy to use is the fun part for me.  So one of the ideas that came out of the idea of having a visible timeline (similar to a Facebook page) for a patient is something that Dr. Rob Lamberts suggested in one of his blog posts on KevinMD.

So one of the new features on NOSH 1.84 that recently got pushed on GitHub has this timeline feature.  Using the Live Demo will give you the best experience for what that is like.  However, I’ll briefly go over what it does.

When you click on Timeline when you enter a patient’s chart, you’ll be instantly given a window that pulls in all the encounters, medications, immunizations, allergies, problem lists, medical history, surgical history, and test results in a linear timeline fashion.  The feature is both easy to use for those using a mouse or with touch devices using a swiping function.

When clicking on the timeline item, it will then take you directly to the encounter that generated this historical item, if there is one associated with it.  For most providers, having that timeline just visible (you can see it whenever you’re already charting an encounter or just perusing in the chart) with a click on the left hand side makes it easy for all providers to have this in a ready-access, and not overly inundating manner.  Of course it’s a start, but as an open-source project, there is always a way to improve on it.  Keep the suggestions going!

Below are the screenshots for this feature:

NOSHCapture NOSHCapture1 NOSHCapture2

1 Comment

Meaningful Use Stage 3 and Three Quarters

It is with regret that Meaningful Use legislation has barreled down the path of insanity.  As a primary care physician, I don’t see how 700+ pages of rules and proposals mean any bit of relevance to my clinical practice anymore.  As the attrition continues regarding eligible providers, it is leading primary care physicians towards the junction point of going off the grid entirely or being enslaved by horrible EHR’s forever.

I won’t bother giving a point-by-point critique of Meaningful Use Stage 3.  If you want to know the details, there are some well written posts by Dr. Hamlaka and Margalit Gur-Arie, if you want to amuse yourself, beseech the gods, or cry (I have experienced all three).

Instead, in this post, I’d like you to close your eyes and imagine being a physician-wizard-to-be, stepping on a train platform called Meaningful Use and walking towards Stage 3…all the while looking for a Stage 3 and three-quarters written on a piece of paper in your hand.

On the Stage 3 platform, you come across a gate that has a sign that lists the 10 commandments by Dr. Octo Barnett, written way back in 1970:

1. Thou shall know what you want to do
2. Thou shall construct modular systems – given chaotic nature of hospitals
3. Thou shall build a computer system that can evolve in a graceful fashion
4. Thou shall build a system that allows easy and rapid programming development and modification
5. Thou shall build a system that has consistently rapid response time and is easy for the non-computernik to use
6. Thou shall have duplicate hardware systems
7. Thou shall build and implement your system in a joint effort with real users in a real situation with real problems
8. Thou shall be concerned with realities of the cost and projected benefit of the computer system
9. Innovation in computer technology is not enough; there must be a commitment to the potentials of radical change in other aspects of healthcare delivery, particularly those having to do with organization and manpower utilization
10. Be optimistic about the future, supportive of good work that is being done, passionate in your commitment, but always guided by a fundamental skepticism.

Pondering at the sign, you can’t help but be annoyed by a parrot overhead cackling “Keep it simple, stupid!” over and over again.  Looking down, you see what you thought were train tracks, but is actually a cobblestone path.

Curious, you open the gate and climb off the platform.  You start walking down the rocky cobblestone path for a mile or so, when you stumble into a deep, dark forest.  You then come to a murky lake and pages and pages of what appears to be Meaningful Use legislation are found floating in the lake.  As you reach down to pick up one of the pages, a spindly hand grabs hold of your arm, pulling you face down into the lake.

Immediately, you feel like you’re suffocating from the murky water, unable to see what is pulling you deeper and deeper.  You continue to struggle, but it’s no use.  As your feet finally touch the bottom depths of the lake, the spindly hand lets go of your arm and you find yourself immersed in darkness and shadows.

You begin to see shapes of what appears to other physicians, ambling aimlessly in the dark water.  They are staring at computer screens like zombies, unable to look away to focus on you.  They mumble incomprehensible words but you can feel their anger, fear, and frustration in the way their muscles twitch on their face, uncontrollably.  You can sense they’ve been imprisoned in the lake for years and years.  They have forgotten how to heal.

Looking up, you somehow see all the pages still floating above you, and yet all the light never shines through around it.  Puzzled, you turn all around to see where there could have been a light that allowed you to see the pages.  You look down into the muddy bottom and you see a small sparkle of luminescence.  Shuffling your feet to push away some of the ground beneath you, the light gets brighter.  You shuffle more dirt away with your legs, but the weight of the water wears you out.  Fatigued, you drop down onto the barren lake bottom.  You try to keep your eyes open, staring at the light, hoping to never lose sight of it.  In desperation, you pound your fist into the dirt.  Suddenly, the dirt gives way and you fall into a blindingly bright cave chamber.   A torrent of water rushes all around you as you fall in, knocking you headlong into a rocky wall.  You pass out.

As you come to, you awake to find yourself in a brightly colored room.  Next to you is another physician holding a tablet.  The physician looks intently at you as you come to and asks how you’re feeling.  Before speaking, you notice that there is a serene calmness in the room.  Despite the presence of the tablet, the physician appears to be highly focused on you instead.  You notice that the physician is minimally entering information into the system either through voice recognition or performing 1 to 2 taps at most for any search query.  The physician rarely has to take his eyes off you during the interview and subsequent examination.  You peer over the physician, looking at the tablet.  You see a screen that appears to be very simple, clean, and uncluttered in its appearance.  The physician actually looks happy and smiles at you.  You ask where you are, and he responds, “You, my friend, are in my clinic for a head injury.  What you’re experiencing is Meaningful Use Stage 3 and three-quarters.”

“What does that mean?”

“It means, simply, that you’re seeing a physician being happy with using the latest technology tools in harmony with practicing medicine and treating their patients.  It can be done, but we must never forget that the ones using the tools ought to be the ones who design and refine the tool.  These tools are meaningless and harmful if we don’t know how to harness it and sculpt it to our needs.  To prevent that, we must never cede our needs and our knowledge to someone else who doesn’t really know what physicians do.  Technology engagement and keeping a constant eye on patient safety and improving patient care ultimately leads to real meaningful use.  It’s not rocket science.  It’s a very simple concept that adheres to Dr. Barnett’s 10 commandments and doesn’t require 700 pages to decipher it.”

“So, what do I do now?”

“Once you’ve recovered, go forth on your quest to be a great physician.  And when you see other physician-wizards-to-be as well as physician-zombies, tell them to look for Meaningful Use Stage 3 and three-quarters.  They will learn soon enough that Meaningful Use Stage 3 is an illusion, an unnecessary distraction, and a path towards destruction for all that is sacred in medicine.  The right path is the one not so easily seen, but is simple in all respects.”

1 Comment

So much money for so much nothing – dire straits for electronic health records

I’ve previously written about my experience with poorly designed electronic health records and how it negatively impacts provider happiness and patient safety.  Apparently, I’m not alone in my experiences and my sentiments about this subject.

First, we have a study that validates the concern that EHR’s waste time for doctors.  Imagine the impact for primary care physicians who are already crammed for time, seeing patients in short time intervals just to keep their overhead.

Then, we have Dr. Clem McDonald, one of the pioneering physician champions for EHR’s at the Regenstrief Institute in Indianapolis and the author for the study, lamenting how a 5-year, $27 billion Meaningful Use Incentives legislation to encourage EHR adoption by physicians was a disappointment and a tragedy.

The players on the Meaningful Use stage are now starting to walk away.  First exiting is CCHIT, the governing body that somehow gave us the great idea of thinking that EHR’s need to be certified on the condition that they be expensive and that doctors need to somehow prove that we can use an EHR in a “meaningful” way, never mind that doctors then forget how to talk to patients and only clicking check boxes and safety measures are ignored.

Then the numbers for those who have attested for Meaningful Use Stage 2, due at the end of this year, are absolutely dismal.  Just looking at the data up to September, 2014, we had a total of 333,454 eligible Medicare providers.  Of those, 80% (266,067) successfully attested for Stage 1.  And now (with the deadline for Stage 2 ending at the end of this year), we have less than 1% (2,282) who are successfully attested for Stage 2.  I feel bad for the folks that put all their efforts into Stage 1 and are now stuck. (99% of them)  So much for the incentive money.  So much for using EHR’s meaningfully.  Apparently doctors don’t know how to use an EHR correctly because we doctors just don’t understand how to use a system that is supposed to be used by doctors.  But we now have some really happy EHR companies that have their physicians captive to their expensive, unusable system.

To add insult to injury, even patients don’t even trust information stored in the EHR’s because of their concern for data security and privacy.

I also point to Exhibit A where I personally used a big vendor, multi-million dollar EHR recently (unfortunately the same as this one) and I noted that there was an erroneously entered diagnosis code after a lab interface attempted to duplicate an ICD-9 code, but incorrectly selected a different one instead.  I didn’t want this poor patient to be an example of where an EHR virtually gave them syphilis, so I diligently attempted to try to remove this ICD-9 code from her problem list and chart.  Alas, no matter how many different ways to outsmart this EHR (and with my hacking skills, no less), I was unable to do this.  I thought that since I was a practicing physician, I should have the privileges to be able to edit it.  I also incorrectly assumed that since an EHR ought to have auditing features, removing an ICD-9 code would be noted (in the case my action to remove it might be construed as erroneous, at best, and covering up something nefarious, at worst) anyways.  So in desperation, I contacted tech support.  I was told that it couldn’t be done once an ICD-9 code has been associated with an order.  But then I said, well, I tried to reorder it without the wrong ICD-9 code, and yet, the code still appears in the chart.  They said, that once it’s even on an order that was redacted, an ICD-9 code cannot be removed from the chart.

No wonder, patients can’t trust the information in an EHR, because shenanigans like this keep a doctor from keeping the chart as accurate as possible.  But for that poor tech support person, I suppose they figured out a way to remove it at my persistence.  Chart correction in this EHR apparently is such a difficult process that can only be achieved through tech support privileges, which appears to be higher than a physician user privilege.  What does that say about the role of physicians and their EHR’s if the EHR won’t let physician’s use their medical knowledge to enter data?

With these examples, what’s the point of using an EHR anymore?  As a physician, a patient, and a citizen, I can’t believe we spent so much money ($27 billion) on so much nothing.

Music video for Money for Nothing from Dire Straits

On the flip side of what appears to be dire straits for the EHR world, we have patients that reportedly yearn to be more proactive with their health through online technologies.  First, a 2-year study from the ONC, revealed that despite privacy and security concerns, patients prefer that their physicians use an electronic medical record instead of a paper and pen.  Regarding patient engagement, an online survey performed by an EHR software research company, Software Advice found that 60% of Latinos would be willing to access their medical records online so that they are able to track their diabetes-related health risks.  Furthermore, 54% of Latinos say they would be willing to log and send personal health information electronically at their doctor’s recommendation if they had the means necessary.  Lastly, regarding patient collaboration, we have a recent study from the University of Chicago, University of Massachusetts, and Geisinger Health Systems that show that patient medical record accuracy can be improved with systems that incorporate patient feedback.

We have physicians who are trying to marry unique practice models such as direct pay practices and EHR’s that aren’t constrained to Meaningful Use incentives, including EHR’s home-grown in these innovative practice models (like yours truly and Rob Lambert’s).

So how can we harness the patient and physician’s desires and frustrations to overcome the dysfunctional status quo of health IT and Meaningful Use?

Whatever the solution is, below are what I believe must be the fundamental guiding principles going forward:

  • Use of open and modern API standards (like FHIR) for the digital exchange of information.
  • Ease of use for the physician and patient (OMG, why the user experience for an EHR is everything!) so they can enter their data without disrupting their workflow.
  • The cost of entry must be low for patients AND physicians so that no one is excluded.
  • And for the sake of data privacy and security, the data must aim to be decentralized and not stored by one monopolistic entity.

This is a vision of a different kind of interoperability, where physicians and patients collaborate on a unified, modern, AND secure personal health record…that is not wholly owned by a third party entity, but primarily owned by one entity that is truly meaningful…the patient.






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…


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 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, 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.


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!