Archive for April, 2011

The Challenges of Ancillary Billing

Galen has recently helped several Allscripts Enterprise clients work through a specific charge issue related to billing for ancillary visits originally scheduled under a generic provider. This is a common registration/scheduling practice, and we thought it would be good to share the issue we found and how to address it.

An example of this type of scheduling would be a setting where a patient sees a rotating nurse for an EP device check. Appointments might be scheduled for a generic provider named Pacemaker NP. This schedule is then worked by the NP on duty that day and billed by the attending physician.

 From the standpoint of the EHR, there is an appointment scheduled for a non-billable provider, an order performed by a separate non-billable user, and then an encounter form billed by the attending physician. When an appointment for a non-billable provider is arrived, the EHR creates an encounter form but leaves the Billing Provider field blank. If this is not updated before charges start dropping to the encounter, problems arise.

If the ancillary staff places the order in the name of the attending provider, a separate encounter form is created for a Med Admin Encounter. This new encounter form is active under the name of the attending provider, but the original visit encounter form is still active with no billable provider. Two encounter forms for a single encounter.

Here’s an explanation of the flawed workflow and the solution we found.

Flawed Workflow:

  1. Patient is scheduled for a visit with a non-billable provider. For instance, “Clinic,Provider”.
  2. Ancillary staff monitors the Clinic,Provider schedule and clicks on current patient.
  3. Ancillary staff places a med admin order. Sets “Ordered By” to the name of the attending physician.
  4. This action creates a separate med admin encounter form for the ordering physician but also leaves the original encounter form linked to the non-billable provider appointment active.
  5. Confusion occurs as there are now two encounter forms for a single encounter. Potential for both double-billing and lost encounter forms.

Corrected Workflow:

Prerequisite: Ancillary staff personalizes the Daily Schedule so that double-clicking on appointment takes the user to the MD Charges screen. This only needs to be done once.

  1. Ancillary staff double-clicks on patient appointment from schedule. This takes the user to the Encounter Form.
  2. Ancillary staff changes the Billing Provider from non-billable provider to the attending physician.
  3. Staff navigates to the clinical desktop and places a med admin order.
  4. Staff selects the attending physician as the ‘Ordered By’ provider in the order details.
  5. Now the charges are dropped to the recently updated appointment encounter form.
  6. Appointment encounter form is submitted to biller for review.

The basic idea here is that the encounter form needs to be updated before the order is placed. Automatically navigating certain users from the daily schedule to the encounter form is a good way to remind and encourage them to follow this workflow. This issue can occur anytime appointments are scheduled for non-billable providers. It applies most commonly with med admin appointments but can also come into play with other ancillary workflows depending on how they are designed. Without this correction, you can end up with piles of incorrect encounter forms that will need to be sorted out.

Giving Back

Galen Healthcare Solutions was founded on the belief that the Allscripts Enterprise EHR is the premier ambulatory electronic health record and the conviction we could add more value to the community by focusing on client side implementations.  Over the past 5 years, we have watched that dream become a reality in many ways.  We are currently working with hundreds of clients and have over fifty experts working on our team in a variety of roles.  Our vast expertise is a critical component of facilitating our partners’ successful deployments and advancements of the electronic health record. 

At Galen, we believe strongly in sharing our success and giving back to our community.  One of our driving tenets internally is to “Perpetually Learn and Share”.  As a team member at Galen, it is not simply an expectation to further one’s knowledge of new and evolving areas of the application and stay current with the latest releases but a requirement. Furthermore, we foster a collaborative environment where this experience and knowledge are communicated to the entire team.  This has been instrumental to our success and ensures that when you work with a Galen team member you are getting full access to the resources that define our organization. 

This goal is not just an internal method for us to keep up to date and deliver value to our clients; it is also our philosophy to share this knowledge with the community for free.  We have established many forms of knowledge sharing for the community and our hope is that we are able to further educate the entire industry by doing so.  Throughout the years, we have actively expanded our roster of free guidance and I’m proud to affirm we now have three ways to share this knowledge:

The Galen Wiki – This houses the industry’s largest source of free Enterprise EHR information.  We currently have many customers, competitors and colleagues that use this repository on a regular basis to research and share information.  The Galen Wiki also allows you to sign up for an account if you’d like to share information.  If you haven’t accessed this site, we hope that you’ll take a minute to see what we’ve shared.  (

Galen Webcasts – Many groups utilizing the Enterprise application have benefited from the various webcasts that we have offered to date.  Our team offers a few sessions each month to cover various topics, including technical and functional based sessions.  The overall feedback has been remarkably positive and we feel this has been a great forum to educate the community and share some of the experience we’ve gained.  These webcasts are free to join and are announced on our website.  If you haven’t attended a session, we encourage you to register for one of the upcoming events!  (

Allscripts Interface Developers Network – Most recently, we launched a new forum dedicated to the Allscripts interface developers community.   This is meant to assist with questions and advice for interface developmental needs.  As the content and usage grows, our hope is that this will become the primary place to research interface advice or post a question with the challenges you are currently facing.  If you are an interface developer or work with interfaces on a regular basis, we suggest that you check it out and post questions or suggestions you may have.   (

These forums are our way of giving back to the community that has supported us throughout the years.  As we continue to grow and identify further needs, we expect these to continue to grow as well.  We hope that each of you is able to gain valuable insight from each of these resources and cultivate your own expertise so you can in return perpetually learn and share.  Together we will conquer the challenges universally faced within health care today and ensure that everyone in the community is well prepared to implement and deploy the Allscripts Enterprise EHR.

Allscripts Interface Developers Network

Introducing the Allscripts Interface Developers Network – a forum for Allscripts integrators by Allscripts integrators. The site is intended to facilitate knowledge-share and collaboration within the Allscripts integration community.

Too many of us live in silos and don’t have the means necessary to collaborate and exchange knowledge and IP instead of reinventing the wheel. Our hope is to enable our clients and the community to produce integrations that conform to best-practice principles and are efficient and safe in the transfer of critical patient clinical data. The scenarios for collaboration are vast, with just a few examples listed below:

  • Design: When designing an interface, an integration analyst may not have the necessary documentation they need concerning the functionality of the API, a list of configuration options, or a template to work off of.
  • Scripts (both interface engine and database): Additionally, there may be a need for custom scripts, and perhaps another member of the community has already developed said script.
  • Error Remediation and Mitigation: Perhaps an analyst has encountered an error that they have not seen before, yet another group has and has a process for mitigation
  • Performance Optimization: We recently encountered a scenario where clients were experiencing performance degradation in their live environment – namely results were taking upwards of three minutes (!!!) from when they were first received in the source system to the point where the processed and filed into the EHR. With a Cached Lookup solution, the client was able to get the processing time back down to a more reasonable value.

You’ll also notice that the forum contains quite a bit of content already. We recently conducted a “soft-launch” of the forum, reaching out to our strategic partners, and got phenomenal response. A special thank you and congrats goes out to Ray Lape, EHR Application Manager at Medisync Midwest. His contributions and collaboration have been outstanding thus far. We know there are more like Ray out there, so please register and begin participation today!

So, as integration questions arise, instead of – or in addition to – emailing to a corresponding interface vendor representative, please post on the forum. Create or branch threads where appropriate. Also note that RSS capability has been enabled on the forum to offer ease of subscription.

Lastly, feedback is certainly important and if there are ways we can improve the site, especially in regards to the forum categories, it is certainly appreciated. In fact, there is a separate forum category that addresses site feedback.


Building the Core EHR Team

With a majority of healthcare organizations being multi-site as well as an increasing trend in MSO oriented healthcare systems, the ability to effectively manage and deploy EHR to entire physician networks is critical to achieving an integrated patient record and reducing disparate records across physician networks.  The release of Allscripts Enterprise EHR version 11.2.x brings the movement towards meaningful use and reimbursement incentives; as well as penalties.  This requires that organizations develop the capacity and knowledge required to take on, prioritize, and execute multiple EHR initiatives simultaneously.  In many cases this involves what seems like the never ending rollout of sites, practices, and acquisitions that comprise these complex physician and community based networks.

So what is really involved in order to make this happen?  Is it really just about system configuration, setting system preferences, writing interfaces, analyzing workflows, and installing hardware?  Cumulatively it is, but who makes this happen and why don’t they grow on trees?  This article aims to take a step back and take a hard look at the soft skills needed to ensure not only a successful initial installation of EHR, but the underlying principals needed in order to ensure a fully functional, well seasoned, and confident EHR deployment team.

Perhaps a quite common question or source of anxiety presented to on site vendor support is “Well what happens once you’re gone?  Who is going to take care of us?”  The following are pre-emptive measures that organizations can take in order to ensure that once the “experts” leave, the pace of the EHR implementation can maintain its course.

Initiate the Transfer of Knowledge

The fast and furious pace of installing EHR at a particular practice can sometimes leave the remaining implementation and support staff straddling between new support duties and ramping up additional practices.  Don’t wait for the knowledge to come to you….go to where the knowledge is.

  • Identify the key drivers and what the critical build aspects are for the organization or practice installation.  Don’t just now what they are, but take the next steps and get a head start in building towards expert level knowledge in those areas.
    • Attend product focused webinars
    • Invest in either remote or on site focused system maintenance or functionality driven education courses
  • Granted these elements can require time and some capital to achieve, but the long term return on investment will come in the form of self sufficiency

First Impressions Are Everything

Remember that through the eyes of a practice going live on a brand new electronic health record the initial round of go-live support and change management will set the tone for the long term relationship between the practice(s) and the core EHR implementation team.

  • Get the core team’s faces out there and work to establish a positive rapport with new and upcoming practice(s), but keep in mind not to overwhelm them.
  • Make sure the practice(s) know that as a team they will be working together directly with the EHR implementation team and that they will not be experiencing this change alone.
  • Let the practice(s) know that it’s okay to ask questions prior to go-live and work to eliminate that potential perception go-live day is a just a silent time bomb waiting to explode.

Cross Training & Skill Set Ramp Up

Get as many of the core EHR and support team involved in all phases of the project life cycle for a given practice.  This will help build the perspective and broaden knowledge needed not only to maintain autonomy and depend less on other team members, but also increase the support capacity of each team member.  This can translate into increased support bandwidth and end user satisfaction.

  • Encourage every core team member to participate in clinic walkthroughs, workflow assessments, go-live support, and the post-live optimization process.
  • Provide internal or “brown bag” presentations (post-live) so that other team members can become familiar with each other’s focus or area of product specialty.

Remember that once the “experts” leave, the core EHR implementation and support team is the lifeblood of the implementation and a key driver to any organization’s long terms success with EHR.

Good Luck!

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 »