Archive for the tag 'Technical'

Load Testing Allscripts Enterprise EHR™


  1. A feeling of worry, nervousness, or unease, typically about an imminent event or something with an uncertain outcome.
  2. Desire to do something, typically accompanied by unease.

If you have ever worked on a project that has required a significant change to your Allscripts Enterprise EHR™ infrastructure then you certainly know the feeling. You’ve carefully planned your infrastructure, done extensive functional / unit testing and now comes the day of go-live. How will your new infrastructure handle a production load?

This question is far too common, but I have recently worked with a major health system that made significant infrastructure changes and used HP LoadRunner to simulate load given common resource intensive workflows like Note & Results Verification. Here are few lessons learned to share about this experience:

  • Value – Licensing around load testing software is expensive and is normally based on the number of users in which you want to simulate load – the more load you want to put on your system the more it costs.
  • Risk – Using HP LoadRunner requires a few minor configuration changes to every web servers where load will be tested. This will require a server admin to make changes to the web servers which will then need to be reverted after load testing is completed. Please use caution when scheduling your load testing to ensure that these changes can be reverted and a subsequent smoke test can be executed in a timely manner.
  • Define your workflows: Simulation testing is 100% based on capturing and scripting workflows which can be very timely – in some cases it can take days to script out just one workflow in your load simulation software. In this client’s case, we used 4 common workflows including a Nurse Note for Urgent Care Visit, Chart download, Results Verification (POC orders) via worklist, and Charge.
  • Technical challenge: Using HP LoadRunner we had to programmatically create/copy both test patients and test users. So if your maximum threshold for testing is 1000 users then you will need to create 1000 test users with unique logins and 1000 test patients.
  • What is your organizations baseline? Load testing is based on concurrent users, but Allscripts has a variety of different user roles all which have varying demands on the system. In the aforementioned client’s case, it was decided that a clinician role would be used where common workflows could be utilized. Once you have your role selected you will need to create a tiered approach where you are starting with an average number of system users and slowly ratchet up the simulation testing against your capacity (and even beyond).
  • Add a little chaos… Once you have captured your baseline numbers rerun the simulation just short of your capacity using real testers. Click around and measure the impact to your load testing given workflows that aren’t being accounted for in your load simulation. Compare these results with your baseline numbers.

Automatically Capture Charges from the Note


I am currently working with Clark & Daughtrey Medical Group to solve a unique problem. The group, which boasts national accreditation in many of its specialties, is looking to report on PCMH measures in innovative ways. So we started a conversation on how we could help them reach their PCMH goals. We discovered that their payers are reimbursing them for performing various clinical assessments. To do this, they have custom charge codes that are manually entered into the practice management system based on a medical coder’s review of each note. The medical billing staff spends hours every day sifting through these notes and entering the charges based on pre-configured flags in the note. With over 800 patient visits every day, this task is tedious and costs the practice a lot of money.

They asked us if there was a way that we could help them report on certain items in their notes. Unfortunately the note data is not discrete like medications and problems. It is actually a complex document stored in a format known as XML.While XML is a structured language, the document is first compressed then stored as one long string of text in the database. This means that if you wanted to search through the note in the database you would first have to decompress the note and then scan through the entire document for an identifier that is specific to that note. That is a nightmare for any type of reporting!

After talking with the staff at Clark & Daughtrey Medical Group we realized that this entire process could be automated! Using Note Form Reporting, I have developed a way to identify the appropriate check-boxes in the note and automatically submit the charges to the EHR. If the level of service charge has already been processed, then the charge is automatically submitted to the practice management system; if the encounter level charge has not been submitted then the provider will see it in the Allscripts Enterprise application just like any other charge waiting to be submitted. Clark & Daughtrey Medical Group will no longer have to waste time and money searching these notes for charges, the possibility of human error will be reduced, and the charges will now appear in both in the practice management system and the EHR.



Announcing Allscripts Analytics and Reporting Training

Do you create reports from Allscripts data? Are you tasked with making changes to existing reports? Do you track Meaningful Use data? Do you create worksheets to track Bridges to Excellence, GPRO, or IPRO data? Have you ever wondered how to utilize the Allscripts Analytics reporting tool? Do you want to learn how to create your own custom reports? If you answered yes to any of these questions, Galen’s Technical Services team would like to invite you to a full day of reporting training in Boston.

Who: Allscripts Reporting Analysts

WhatAllscripts Analytics and Reporting Training

Where70 Federal Street, 7th Floor, Boston, MA 02110.

When: Wednesday, June 13th, 2012 from 9AM-5PM with lunch provided. There will also be a cocktails and networking hour from 4PM-5PM with beer, wine, and light snacks.

Why: Learn about the details of reporting with Analytics and working with custom reports.

Cost: $250/seat


  • Analytics overview
  • Analytics reporting review
  • Developing a report with Analytics
  • Review of reporting within Allscripts
  • Demonstration and customization of a report
  • Deployment, testing, and best practices
  • Much more!

Please contact us if there is a topic you would like to learn more about that isn’t in the list above.

Travel: If you are driving into the city, there are parking garages nearby. The cheapest and most convenient is the Winthrop Square Parking Garage at $20/day. If you are coming in from out of town, there are many hotels in the area. Also note that we will have wireless internet and workstations with a hardwired internet connection available for those who need it.

Space is limited – register today!  If you can’t make the training, it’s OK! Galen offers free webcasts about every two weeks.

Technical Assessments: Improving Performance and Reducing Risk

One of my first client-related activities after joining Galen Healthcare Solutions was doing data collection for a Technical Assessment. One of our senior resources was on-site, and he thought this would be a good opportunity to get my feet wet.

A full Technical Assessment of a client’s EEHR environment involves reviewing server hardware, software, settings, network configuration, etc. The benefit to the client of these assessments is two-fold. First, we can identify and attempt to resolve performance bottlenecks, typically stemming from misconfiguration. Second, we can identify general areas of concern, such as staffing, hardware, software, or future growth concerns.

To begin, I went through and confirmed a server listing with the client for both their production and test environments. I then proceeded to collect pertinent information for each server, including a number of role-specific items, for example, the version and service pack level of SQL used in the Clinical Database Server. This process is akin to the System Certification process done during EHR upgrades.

I collected a considerable amount of the necessary data with a VBScript-based application, which leveraged Windows Management Instrumentation (WMI) and dumped most of what I needed into text files for each server. I then proceeded to populate that information into my reports, and I shared those with my team. The details of those findings were compiled into a written report by the senior resource and presented to the client.

Shortly after the report was delivered, I was notified that one of my findings had been found to be the cause of one of their most significant issues. A misconfigured “Lock pages in memory” Local Security Policy setting was hindering their ability to properly fail over the clinical database cluster to another node. It is required that the user running the SQL Server service is configured to have this ability.

I have done a number of similar assessments for other clients over the years, and it is always interesting to find out what new information we can provide our clients to help them better utilize their systems. It is also great to be able to put a face with a name. As part of the Upgrade Team here at Galen Healthcare Solutions, we look forward to helping clients through the changes necessary to implement new and upcoming versions of EEHR and the updated technology that goes along with it.

Clinical Conversion Toolkit

Introducing the Galen Clinical Conversion Toolkit, a solution and process designed to guide clients through converting from legacy systems and existing EHRs to the Allscripts Enterprise EHR. As Managed Service Organizations (MSOs) seek to expand their footprint through acquisitions, conversions to consolidate to a standardized system are often desirable to avoid the Healthcare Information System Mosaic.  Leveraging experience gained from previous clinical conversions, the Clinical Conversion Toolkit streamlines the process and provides a means of converting clinical data safely and efficiently. It should be noted that while conversions can be extremely useful in the sense that they save duplicate data entry, clients need to exercise caution in that any conversion data should be reviewed.

Discrete Conversion Types

  • Allergies

  • Immunizations

  • Medications

  • Documents

  • Results

  • Problems

  • Vitals

  • Dictionaries

  • Process Overview

    • Data Extraction

    • Data Analysis: Cross-Referencing

    • Design: Data Filtering, Matching (Provider, Patient Item), and Exceptions/Errors

    • Testing

    • Go-Live

    Data Extraction

    Whether the historical system is an EHR such as NextGen, Greenway or eClinicalWorks, a PM such as GE Centricity, or a legacy in-house clinical information system, one of the most important aspect of the conversion will be acquisition of the data. Often times, this will require assistance with the current vendor to trigger a bulk-load export of the data. The preference is to output to flat-file, thus facilitating an intermediary step of data analysis and cross-referencing to prep the data before it is loaded into the EHR.

    Data Analysis – Cross-Referencing:

    The most important part to cross-referencing is to ensure that the corresponding AE-EHR dictionary dependency exists in the dictionary. If starting from a “blank-slate,” it is prudent to extract the compendium information for the exported data file from the source/reference system. In the case that dictionary entries already exist in the AE-EHR (for instance, in the scenario of a client that is an MSO, multi-org, and single EHRDB), it will be important to setup cross references so that the codes in the reference system match up to the corresponding values in AE-EHR. This is often realized through deployment of translation tables within the Clinical Conversion Toolkit.

    • Provider code – Recommendation to use default “dummy” provider to identify clinical items loaded from conversion
    • Document type
    • Allergy code
    • Immunization name, provider, route of admin, body site and manufacturer
    • Problem and procedure codes
      • These codes will need to be cross referenced with the more-granular Medcin nomenclature.
      • This presents a challenge in that an ICD9 or CPT code could have a one-to-many relationship with Medcin.
      • The Clinical Conversion Toolkit provides a translation tool utilized in previous problem conversions to assist in the cross-reference.
    • Vital sign names
    • Order/Result Item Codes

    Design – Filtering:

    Filtering can be performed up-stream as part of the source/reference system extraction process, or it can be realized within the Clinical Conversion Toolkit logic. Typical filtering options include the following (but are not limited to):

    • Items that have been entered in error in vendor system
    • Allergies – NKA and NKDA entries are typically excluded to avoid incorrect reporting of NKA and NKDA
    • Exclusion of non-finalized documents or results

    Design – Matching:

    Patient Matching: Patient matching is crucial to the exchange of clinical information between systems.  The Allscripts Enterprise EHR has strict matching criteria – in summary, matching on three of the four of the following: Name, Date of Birth, Medical Record Number (MRN) and Social Security Number (SSN).  As there is a move away from using SSN, by patients at least, this leaves us with only three fields to match on for many patients: Name, Date of Birth and MRN. In certain cases, more advanced options for patient matching can be deployed such as fuzzy matching as previously described on our blog.

    Provider Matching: Clinical items will need to tie back to the provider who originally entered, ordered or authorized.  Typically, a short numeric or alphanumeric identifier is used to link a provider entry in the Other Vendor’s system to the provider entry in the EHR.  The current trend is to use a provider’s National Provider Identifier (NPI) as the identifier that the two systems exchange.

    Design – Exceptions:

    Not all of the data will load to the EHR without error. Some records will require manual assistance via add-on tools such as Allscripts Patient Bridge, while others may require more advanced troubleshooting and re-file. The Clinical Conversion Toolkit takes care of logging those transactions which generated error for future reference.


    Please contact if you or your organization would like to learn more about Galen’s Clinical Conversion Toolkit for the Allscripts Enterprise EHR.

    Next Page »