The Viral Workflow: The Bug That Spreads Within Your Organization’s EHR

Viral Workflow

You’re at your desk minding your business when Suzie Sneezer walks in, coughing, sneezing, and blowing her germs all over the office. She’s come to help you with a project and wants to show you something. So it begins, within two days everyone in your office is also sick with the sneezing and coughing. Suzie Sneezer, though well-intentioned, has spread her virus throughout the office like wildfire.

This can also happen with incorrect workflows, bad data entry habits, or unapproved workarounds which can be highly contagious. With the best intentions users often share “short cuts” or “tips” amongst themselves, and these can spread like a virus from user to user throughout an organization and infect the healthiest of EHRs. Some of these “Viral Workflows” might be just a case of the sniffles. On the other hand some viruses, if not treated aggressively, could lead to wide spread issues and have systemic effects throughout the entire organization.

As consultants we are constantly vigilant, always concerned with the health of our clients’ EHR systems and the wellbeing of the entire organization. While engaged with a single client, consultants may work with numerous members spanning the spectrum of roles within an organization, as well as other hired resources and vendors. This variance in role relations often allows us to witness firsthand the processes and/or workflows of many of the organization’s users, and are in a sense indirectly exposed to these “viruses”.

Below are some examples of “Viral Workflows” my colleagues and I have diagnosed and eradicated recently.

  • While managing an upgrade project for a client, our consultants discovered that 80% of their EHR users were logged onto webserver #1. Upon further research, they found that several months prior, webserver #2 began having issues but it had gone unreported. Instead of reporting the problem with webserver #2 to the proper department so it could be resolved, a user had concocted a “work around” to bypass the load balancer altogether. The provider showed a few users how to edit the URL to hit a specific server (clearly webserver #1), and before long the viral workflow had spread. To the provider this seemed benign so he shared his shortcut with everyone around him, though on a large scale it proved detrimental to the health of the EHR.
  • Optimization assessments often uncover chronic “viral workflows”. A clinical staff person was observed clicking the “reconcile” button during a patient work up in preparation for a provider appointment. Other than allergies, medications were not discussed during the time with the patient. When questioned by the consultant the user stated, “I was told in training if it is was yellow, click it”. This user was not aware that reconciling the patient medications actually meant reviewing each medication with the patient. This clinical staff and others had been doing so for several years.
  • This viral workflow is very common and has been discovered by several consultants: in Allscripts TouchWorksTM, clinical staff who are pressed for time will search for a patient by name or MR# instead of selecting a patient from a provider’s schedule as prescribed by the best practice workflows. When saving any data changes, the application presents the user with an Encounter Selector, forcing the user to choose an existing encounter or create a new one. In haste a new encounter is often created. This virus has a trickledown effect that spreads to billing and coding, causing reporting issues that providers may eventually have to deal with as well.
  • While optimizing in preparation for an EpicTM conversion, consultants uncovered an issue while dissecting preliminary reports. They discovered that many providers were “removing” tasks or messages from the message basket rather than actually completing them according to the best practices. While seemingly harmless to the providers, they found that this fragmented process of “removing” instead of resolving was very cumbersome and was spreading like an infection throughout the system. Order cycles were not completing correctly, reports were not accurately capturing data, and a large number of results and un-signed notes would not have converted as desired by the organization.

Okay, I have some good news and some bad news. Why don’t we go with the good new first? There is a treatment and prevention for these viruses. That treatment is knowledge. Knowledge is the antidote that should be administered to eradicate many viruses within your organizations and EHR system.

As with the human body, some viruses are easily prevented with the proper inoculation. In this case, the vaccine would be proper initial training coupled with ongoing reinforcement, along with policies and procedures to keep users informed and up to date. This could prevent the majority of diseases from spreading within the organizations EHR.

Just as with the health of humans, some viral workflows are hard to diagnose and have symptoms that are subtle or go unnoticed for lengths of time.  Until a secondary diagnosis becomes acute and causes severe symptoms or widespread problems throughout the EHR, users and administrators would never even know the system was “sick”.

Now for the bad news. It may take some cognitive effort to resolve the symptoms and cure your organization of the virus. Sometimes the treatment plan can be as simple as retraining users on a certain workflow or process, but that is not always the case. Evaluating and treating one “virus” can often lead to discovering another. Having an “if it ain’t broke don’t fix it” attitude can be detrimental to your system. With this mindset, organizations are most likely addressing one symptom at a time, nescient to the fact that eventually every group needs to consider a full system optimization.

Every organization should treat their system proactively and have a plan to maintain the health and wellbeing of their EHR. A full system optimization is the panacea for your organizations EHR and its “viral workflows”. Think about it, your EHR is a like a living being, constantly growing, changing, and evolving. With upgrades, new versions, employee turnover, changes in government requirements, etc., your system is bound to need a checkup. Like a hacking cough, your organization may only be treating the “viral workflow” symptoms that become bothersome. The best plan of care for every organization’s EHR is to have a full top to bottom health evaluation (aka System Optimization) that eventually leads to a treatment plan to achieve a healthy system. Furthermore, a plan should be put in place to maintain the optimum level of health for your organization’s EHR.

Forget about the EHR, learn how to use a computer first


Zoolander. Dir. Ben. Stiller. 2001.

As I sat in an exam room last month awaiting my orthopedic surgery consult, my mind swelled with a lot of atypical patient questions, primarily due to the nature of my Healthcare IT background. Some of these thoughts included:

  • What kind of EHR are they using?
  • Do they have a patient portal?
  • Will they remember to give me a clinical summary?
  • Do all the departments use the same system? Or at least have interfaces to share this information?

Before I could even ask these questions or peek at what application they were using, we hit our first road block… the nurse could not log into her computer. It wasn’t because of a complex system setting or other unique set up, it was because of the dreaded…wait for it…CAPS lock! All of my questions were now replaced with wondering why standard computer training is not a part of EHR training?

Once she was able to login to her PC, she then had to login to a separate server to access the application which required another password. Again, she could not get logged in, this time because she couldn’t remember the password. After 15 minutes of this she finally gave up and did not document one thing electronically. It’s very easy to see that just a simple operation like logging into a system can create many minutes of waste for the staff and the patients, ultimately reducing the quality of care.

I have supported numerous EHR go-lives and not once do I remember a basic computer operation or typing class being part of the process. Many times during go-lives, the biggest obstacle I would face would be getting through to staff who were not comfortable using computers, let alone the EHRs. It’s one thing to train and support somebody on how to do their job using an EHR – but if they can’t even figure out how to login, click around, or type efficiently, you are going to have a very difficult time.

What can be done about this?

  • Conduct a computer skills aptitude evaluation to determine who would benefit from basic computer training
  • Implement SSO (Single Sign On) for applications so that once users login to their workstation, they can easily login to the EHR software as well
    • Badge readers can further streamline workflows because they allow users to swipe their ID cards to login and logout of systems.
    • This minimizes the amount of clicks and keystrokes required to access workstations and necessary applications
  • Condense the number of disparate systems throughout the organization to flatten the learning curve for new applications
    • This makes it much easier to share resources across an organization, enabling staff to more efficiently collect important patient information, and ultimately reduce patient wait times
    • Another side, but obvious benefit to this is a reduction in the unnecessary support and maintenance that comes from using one system in the hospital and another in the outpatient clinics
  • Simplify clinical documentation for your providers
    • Personalize the application to be as similar to your providers’ handwritten notes to make the transition easier for them
    • Consider incorporating some kind of voice recognition software, like Dragon, for providers and staff who are not efficient at typing

Although there’s a greater initial investment to train users on these basic skills, it will save everyone time in the long run and most importantly, it will increase the quality of care for your patients. Ultimately, isn’t that why we use computers in the first place?

10 Tips and Tricks to Make Mirth™ Connect Work for You


In our last blog post in this series, we introduced the Mirth™ Connect interface engine and discussed how it stacks up against the competition in the healthcare IT space. What we love most about Mirth™ is the breadth of customization options that are offered, and today we want to give you a deeper look inside the application with our tips and tricks segment.

  • Add channel metadata to troubleshoot faster: You may already be storing useful information about incoming messages in channel variables, such as the MRN of a patient, an identifier for a hospital, or the HTTP response code of a message you are POSTing via Mirth™. By adding these channel variables to the metadata of a channel, you can view the values for these variables on the message log screen and also speed up your searches when using the Advanced search filter and specifying the metadata you have defined.

    Figure 1: In the Source screen of your channel, enter your variable names and provide a name for the column where you can view the variable on the message log screen.

    Figure 2: Now in the message log screen for your channel you can see your new metadata, adding important information to your message log. Use the Advanced search option with metadata specified to experience faster search results.

  • Stay DRY (Don’t Repeat Yourself): Apply the abstraction principle by using code templates and global scripts in place of duplicate code. For example, if you have multiple channels, destinations, or transformers that all need to connect to the same database, move your database connection string into a code template and reference the code template any time. This way, if you ever change your database credentials, you will only need to update your code template instead of every database-accessing channel.
  • Don’t reinvent the wheel – leverage external code libraries: Mirth™ allows you to import external Java and JavaScript libraries just like you would in a traditional IDE. When we needed to store data securely in our database, we used the CryptoJS JavaScript library to encrypt our data instead of writing our own complicated encryption algorithms. Pro-tip: when using external JavaScript libraries, host the library locally to avoid making expensive (slower) calls to an external server with every message that Mirth™ processes.
  • Don’t catch errors gracefully: You don’t often hear this, but in your Mirth™ JavaScript code, you may not want to catch errors gracefully. If you wrap your code in try/catch blocks but do not throw the error, Mirth™ will let the message continue processing and anything could happen with a broken message downstream. Throw your errors to let the message fail.

    Figure 3: Wrap your JavaScript code in try/catch blocks to capture errors and make sure to throw the error so that the message gets set to ERROR and does not continue being processed.

  • Don’t code (or test) in production: Once the save button is clicked on a channel or code template, your changes are permanent and can’t be undone (unless you have backups). As with anything else in IT, don’t code or test in production – use a separate instance of Mirth™ as your development/staging environment. Create new channels and change existing ones there, and once you’ve tested your changes thoroughly, export your channel from the staging environment and import it into production.
  • Handling source control yourself: Another feature still lacking in Mirth™ Connect is channel source control. As of Mirth™ 3.2, there are no ways in the Mirth™ user interface to view or revert changes made by users. If someone else has broken a channel, you have very little information available to know what has changed. However, one nice thing about Mirth™ channels and code templates is that they are saved as XML files. You can use an external source control tool such as GitHub or BitBucket and export your channels from Mirth™ into them.
  • Use an external IDE: With the 3.2 release of Mirth™ Connect in February, some improvements were made to the JavaScript Editor, including code completion and bracket matching. Still, for many of us used to coding in a dedicated IDE like Visual Studio or Eclipse, Mirth’s JavaScript Editor lacks some of the features we’ve grown accustomed to, like source control, writing unit tests with JUnit (Java) or QUnit (JavaScript), or refactoring with Resharper for Visual Studio. Nothing is stopping you from writing your JavaScript code in your favorite IDE and copying and pasting into Mirth™ when you’re finished.
  • Safely restarting Mirth™: If your instance of Mirth™ is handling hundreds of thousands of messages a day like the ones we have worked with, your channels are likely using a lot of system memory. When restarting Mirth™ – maybe because you are upgrading the application or you are doing server maintenance – you should make sure to disable and undeploy all of your channels before restarting. If not, Mirth™ will attempt to quickly halt all traffic during the shutdown phase, potentially causing errors to messages being processed, and during the restart phase Mirth™ will try to automatically deploy all channels at the same time. Since your channels may have upstream or downstream dependencies on other channels, manually launching your channels in a specific order may be necessary.
  • Give yourself some more memory to work with: If you ever get an OutOfMemory error in Mirth™ and the heap size is mentioned, you may want to think about increasing the heap size of both your Mirth™ Connect server and client. This will provision more RAM for Mirth™ to use when handling heavy traffic or opening the logs for large messages. You can increase the server’s heap size by going to Mirth™ Connect Settings in your appliance and you can increase the client’s (the actual instance of Mirth™ Connect you interact with) by editing the .jnlp file in a text editor and looking for where the heap size is defined.
  • Fine tune the message storage option for each of your channels: Some channels may handle more traffic than others or process messages with greater magnitudes of length. As these messages and their metadata (channel variables, HTTP response statuses, etc) are stored in Mirth’s database, space can run out fast depending on the disk space of your server. In each channel, you can use the Message Storage slider to configure what Mirth should save, ultimately changing what level of detail you have to work with in the Message Log screen. Pair this setting with the Message Pruning option to let Mirth save the exact kind of content you need for as long as you want. If you notice that you’re running out of disk space, change the settings and get to that sweet spot that lets you have robust archives without bringing your server down.Mirth 2.4

At Galen, we have worked with Orion Rhapsody, Epic Bridges, InterSystems Ensemble, and almost every other healthcare interface engine out there, and helping our clients achieve interoperability is something we are passionate about. For our next article in this series on Mirth™, we will leverage our years of experience in the industry to present our final opinion on Mirth™ and explain why it may be the right interface engine for you. To learn about how Galen can assist your organization with using Mirth™, please contact us at

Care coordination is complicated. Your solution shouldn’t be.

FREE Webcast – PinpointCare: Coordinating Care By Design


PinpointCare Webcast

Bundled payments are increasingly becoming a popular form of risk-based contracting. Commercial payers along with Medicare are offering a payment model where organizations agree to participate and enter into payment arrangements that include both financial and performance accountability for specific Episodes of Care. The goal being to keep the cost down and to decrease the chance of patient readmission. The episodes range from procedures associated with Orthopedic surgery to the management of chronic conditions.

Galen Healthcare Solutions is excited to be collaborating with PinpointCare, to bring you its one-of-a-kind platform for management of these Episodes of Care. Join us for a webcast where we will share the details of the easy-to-use application that allows the care team to closely monitor adherence to the care plans associated with each Episode of Care. It is done in real-time collaboration regardless of setting: acute, ambulatory, rehabilitation, skilled nursing facility, home health or outpatient physical therapy. If you are in or considering Bundled Payment contracting, you do not want to miss this webcast! Details and registration information for the webcast are available here.

eRX Refills – Just Click the Button, Right?


How many people fully understand the complete workflow involved in refilling a patient prescription electronically?  Can I see a show of hands? Technically speaking, you just click a button, right?  If that is the case, then why are there threats of mutiny when organizations allow eRX messages from pharmacies to filter into the physician bucket instead of a pharmacy team or nurse bucket?  The physician has to sign off on it anyway, so shouldn’t the message just go to the physician and cut out the middle man?  Plus, when using electronic prescribing, all a provider needs to do is a click a button, select “Approve” or “Deny”, and abracadabra – the prescription is filled.

Although clicking on the pharmacy refill request message and selecting “Approve” or “Deny” does not involve many steps, the process to ensure optimal patient care and safety does.

There are several steps involved in refilling a prescription to ensure that the best medical care is provided. Let’s walk step-by-step through the actual process (which stems from the Five Rights of Medication Administration ) that all nurses have drilled into their heads.

First, we need to determine if the patient is an actual patient of the physician (often pharmacies will send a refill message to whoever filled a script last, even if it was done years ago) and that the patient demographic information is correct. Second, we need to confirm the condition or disease process for which the patient is taking the medication, and check if there have been any changes in dosage or if the patient is still taking the medication. Third, most clinics have protocols in place in regards to when the last patient visit occurred prior to fulfilling the renewal, and we need to ensure this requirement is satisfied.  Typically it is within one year, however depending on the medication, it could be less.  Fourth, we need to find out if any lab work was needed to check levels which could determine a change in dose, a complete change, or discontinuation in the medication.  Some other actions may include contacting the patient or other healthcare providers for additional information as needed.

Once all relevant items have been reviewed and documented following the clinic protocols, the prescription can then be refilled. Because it is within a nurse’s scope of practice to administer medications with a physician order, telephone orders to a pharmacy and now e-prescribing also fall within that scope of practice.

With this in mind, which makes more sense?  We can have the nurse receive the eRX pharmacy renewal request message, obtain all of the relevant information needed, click the “Approve” or “Deny” button, and then forward the renewal request to the provider to retrospectively sign off on once complete.  Alternatively, we can have the eRX renewal messages filter to the physician bucket so that the provider can perform all due diligence prior to refilling.   It is understood that we want physicians involved in e-prescribing and that they should be aware of what is occurring with patient refills.  When the “retrospective” workflow is followed, the provider does sign off on the order.  Ultimately, it is up to each organization to determine which refill e-prescription workflow is the most time (and cost) efficient to put into place.

Next Page »