Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

Does your practice utilize the Finish Note task in Allscripts Enterprise EHR^TM? 

If you answered yes, then this blog is for you.

In this article, I wanted to show you two possible outcomes when working in your  v11 Note. You will notice that there are two similar workflows to add and commit clinical data in the note that will impact how a Finish Note task appears in a user’s task list.

While you will find that these two workflows are scaled down to be very basic and generic, I wanted to limit them to clearly demonstrate the difference between the two.

Workflow #1: Committing data while saving and closing the v11 note

In this workflow, we assume that the user already has the patient in context at the clinical desktop.

The basic steps of this workflow are as follows:

1. Create a new v11 note
2. Add a new clinical item
• For example: add vitals to the patient chart
3. Select “Save and Close” in the Note window
4. Select “Save and Continue” on the Encounter Summary
5. Navigate to the Task List and select the Current Patient – All task view

Here you can see that the outcome is:

- One Active Finish Note task

So in this case, using the Current Patient – All or Current Patient – Active task views, you will see that just one Finish Note task has been created in an active status.  The task indicates that the note has been created and saved.  Keep in mind, at this point, that the commit action occurred while the user selected Save and Close in the Note. In this workflow, the system only reviewed the data once.

Workflow #2: Committing data prior to saving and closing the v11 note

As we did in the first workflow, here we assume that the user already has the patient in context at the clinical desktop.

The basic steps of this workflow are as follows:

1. Create a new v11 note
2. Add a new clinical item
• For example: add vitals to the patient chart
3. Click the Commit button
4. Select “Save and Continue” on the Encounter Summary
5. Select “Save and Close” in the Note window
6. Navigate to the Task List and select the Current Patient – All task view

Here you can see that the outcome is:

- A Complete Finish Note task and an Active Sign-Note task

If you use a task view that simply shows Current Patient – Active, you would not typically see the Finish Note task in this instance, but instead the Sign-Note task.  This means the note has not been signed and might not be the task you expect to receive if you seek the Finish Note task.

While a Finish Note task has been generated and marked as Complete, there may yet be information to add to the note.  The logic behind this workflow is that the second action of “Save and Close” is the second review after having hit “Commit”, and therefore results in the outcome we see here.  In this case, the system has reviewed the data twice, and the Finish Note task in regards to this note is completed and the active Sign Note task is automatically generated.

My advice in this situation is to follow Workflow #1 when working in a v11 Note. If users are creating a note and adding clinical data, but need a provider or second user to receive a Finish Note task and add additional items to the note; use the first workflow.   This way, the Finish Note task will be assigned and visible to the correct person, and users will be trained in such a way that ensures the success of this workflow.

Please don’t hesitate to leave your feedback below or Contact Galen Healthcare Solutions should you have further questions!

Tags: Allscripts, Allscripts Enterprise EHR, EHR, Enterprise EHR, Galen Webcast Series, Tasks, TouchWorks, v11, v11 Note

One of the many challenges in interfacing to the Electronic Healthcare Record is patient identification and matching. Results and documents from outside systems need to link to the correct patient record. This is especially profound in data conversion initiatives. Given the scenario of an organization converting to utilize an EHR, aside from the plethora of documents being scanned in and associated with the chart as well as “bulk loads”  from the practice management system, there are could also be several data silos which need to feed data into the EHR.

We encountered one such scenario with one of our clients. Our client had been processing and loading flat-files from its legacy systems into the EHR. The client loaded approximately 15 years of legacy data (equating to millions of records). In the import process, the client had followed a strict patient matching criteria and received a patient matching error rate of approximately 5% which may be considered a reasonable matching rate.

However, the client’s help desk was getting a multitude of calls reporting missing legacy system records in the EHR (suspected to be in the 5% that did not make the conversion). The issue working against the client was a drop-dead date upon which these legacy systems were being deprecated and thus the clinicians would no-longer have a “fall-back” plan to access the records – the repercussions of which were potential patient care issues.

As such, Galen was engaged to analyze the records that did not meet the strict patient matching criteria , determine which records could be successfully loaded to the EHR under relaxed patient matching rules, and describe the impact of relaxing the patient matching. In the analysis that followed, it was recognized that in the data set that erred due to patient matching errors, identifier fields (namely first name, last name, DOB, MRN, Other Number1 and Other Number2) exhibited typos and inconsistencies. Enter Microsoft SQL Server Integration Studio’s (SSIS) Fuzzy Lookup Transformation. For those unfamiliar with fuzzy logic, it is “the process of reaching conclusions based on information and facts that are not 100 percent certain.”

The underlying algorithm to the Fuzzy Matching transformation is the SOUNDEX function:

• In the late nineteenth century, United States census officials faced a dilemma. During the process of counting the huddled masses, our public servants created a huge paperwork trail that the law required them to preserve for future historians. With amazing forethought, they realized that people searching for records might not know the exact spelling of their ancestor’s name. Was it Smith or Smythe? Chapple, Chapel or Chapelle?

• To ease these searches, census officials turned to the Soundex phonetic filing system. This system uses a simple phonetic algorithm to reduce each name to a four character alphanumeric code. The first letter of the code corresponds to the first letter of the last name. The remainder of the code consists of three digits derived from the syllables of the word.

• Largely unused outside of the halls of government and genealogy, the Soundex system is making a comeback in modern databases. Database developers have long struggled with the problem of matching words that might not look alike, but actually sound alike.

Thus to reclaim some of the records that erred in matching to a patient chart in the EHR, the Fuzzy Matching transformation was utilized. Flat-files output from legacy data silos were input, pre-processed and then fed to the transformation. Given previous studies, the matching criterion utilized was as follows:  Match on LastName and FirstName Similarity Threshold >.8 AND DOB matches exactly AND one of three (MRN, OtherNumber, OtherNumber2) cross-referenced match exactly. The end result was reclamation of close to 25% of those legacy system patient records that originally failed patient matching.

If your organization is looking for assistance in data conversion, please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

Tags: Allscripts Enterprise EHR, Data Conversion, Database, Integration, Patient Matching, Technical, TouchWorks

Tags: Allscripts Enterprise EHR, Clinical Desktop, Galen Webcast Series, TouchWorks

More structure and planning help to head off excuses and voluntary non-compliance.  One of the more common excuses is finding reasons the system is less than perfect, ignoring the fact that the system is replacing a flawed system in many cases.  I couldn’t count the times I have spent  explaining “flaws” in a system that were really the same flaws that existed in the paper world.

There has to be accountability for non-compliance with expectations.  Metrics have to be in place to track compliance and remediation has to be in place to assist with compliance.  This needs the appropriate chain of command authority and support.

Here are some thought to promote compliance.

Competition – Use individuals competitive spirit to drive compliance.  Publish compliance success stories that prove utilization is possible which naturally spark some competitive spirit in some, which also is aided by the “un-biased” peer being the one that made it work and can use their clinical credibility to persuade.  Physician Champions are often well suited for this because they have a better understanding of the big picture.

Buttons – Take the time to take notice of what the pain points and satisfaction buttons are for the varied audiences.   If you know what these are the message can be tailored to accommodate the differences.

Piloting – Use piloting to work out the kinks.  If you aren’t sure how something is going to play out in a specific situation, play it out with a willing participant or champion to refine the process before rolling it out in mass.

Tags: Adoption, EHR, Successful EHR Implementation, TouchWorks

This fall, a team of Galen consultants aided their client, a prominent healthcare system in the Midwest, in actualizing the vision of a ‘practice with no walls.’ This Healthcare system has been bringing their clinics, including hundreds of providers, live on Allscripts Enterprise, enabling the highly coveted shared patient record to be available across a large metropolitan region.  When the independent physicians elected to join this endeavor, the potential benefit was multiplied, but so were the challenges and risks.  While the original implementations were split across two Organizations, each independent practice would constitute its own Organization within the Allscripts EHR and integrate its own Practice Management (PM) systems.

Each member of the Independent Practice Association (IPA) is required to undergo a workflow improvement initiative.  This methodology assists the practice and design teams with building workflows that will maximize their utilization of the EHR.

Interfacing the new practice with the patient records was a significant challenge as sustaining data integrity is of the utmost importance. The risks included overwriting patient data, merging differing patient records, and creating multiple records for the same individual.  Integrating multiple PM systems into an Allscripts Enterprise environment of this magnitude is a challenge with little precedent.  The Registration and Scheduling and Billing interfaces were both new, while the Lab, Document and Hospital ADT were existing interfaces that required modifications to accommodate the new Organizations and physicians.

On October 22, the pilot practice went live on its first of two phases.  Two weeks in, there have been no major issues to note.   This month, the practice will go live with phase 2, which will introduce new functionality. The Galen team will support the client with training and supporting the practice in meeting its goals of a paperless environment.  The providers (and their staff) are greatly anticipating the Charge and Note modules to reduce their manual entry requirements and improve their high standard of patient care.

One last note – on the first day of the Phase 1 rollout, a provider at the pilot practice was with a patient.  The doctor had been working with this patient on a cardiac related diagnosis and referred them to a specialist within the health system.  When the patient returned on that day, the doctor accessed their now shared record and was amazed to find the cardiologists report ready and available to her.  It did not take long for this independent practice to truly appreciate the value of their new Allscripts Enterprise system and their innovative investment in a ‘practice with no walls’.

Tags: Allscripts Enterprise EHR, IPA, MSO, Multi-Org, TouchWorks

When implementing new software, organizations understandably focus on the short term goal of go-live, but taking a more long term approach can actually lead to less work, a smoother transition and better results. Here are 3 techniques to accomplish this shift.

Know the software – cold
Don’t try to imagine or decide how to best configure the software for your workflow and then build it. Instead build test components (worklists, views, menus, etc.) and then bring that knowledge to the decision process. Divide the build tasks up and assign to teams. Each team should include a leader with build access and a few advisors with clinical workflow experience. Build the examples in our Wiki or provided by Allscripts or make up your own. The other team members should watch the build process and ask questions. This will give them firsthand knowledge of what can and cannot be done to better inform their decisions and allow them to translate to the larger user community. It does not matter what you build. The goal is to get familiar with the options and limitations. This will allow the team to use a more creative approach to the build. It is easy for a team to get bogged down in deciding what will work best for their providers and  delay the actual building only to discover a better approach after they get started and are short on time.

Don’t assume the end user always knows what will make them happy
Build decisions often involve a compromise between the experience the end user is requesting and other concerns such as patient safety, workload for IT support staff, etc. Teams often focus on finding solutions to these conflicting needs without first considering the underlying assumptions. A user may be insisting on a particular workflow or other requirement because they are unaware of all the options that are available. Allowing end user representatives to observe the actual build work is one way ensure that they know all the options and enables them to help find creative solutions to the software’s limitations. Observation is another useful method. In an article about the innovative design firm IDEO, author James M. Pethokoukis gives an example of how direct observation can yield new insights:

….IDEO general manager Tom Kelley gives the example of working on a project with the SSM DePaul Health Center in St. Louis to revamp its emergency room. One approach the firm could have taken would have been to quiz a bunch of former patients on their experiences.

While there is much to be gained from carefully constructed interview questions, IDEO understands that self-observation does not reveal the whole story.

The article goes on to explain:

For instance, one IDEO anthropologist pretended to be a patient and managed to videotape his entire emergency room experience. One realization: While the admitting and treatment process might seem logical and orderly to staff, it appears chaotic and confusing to patients. So IDEO created a simple “map” that the hospital staff could give each incoming patient outlining the seven steps of the emergency room experience, starting with the triage nurse. It also recommended cards that each member of the staff could hand out so the patients could keep track of who’s who. “They understand that creativity had to be provoked and fed,” says Robert Porter, who has twice worked with IDEO, now as head of strategic and business development for SSM Health Care-St. Louis, part of one of the largest Roman Catholic systems in the country. “They understand that you need a messy process to gain consumer insights.”

A similar approach can be applied to EHR implementations. Including users in configuration decisions is a good first step but direct observation can lead to a more thorough and accurate understanding of the workflow. Have end users demonstrate their workflow in the office and trade roles to understand the handoffs and risks. How are transitions handled? Who logs in and out and when? Can the patient see their chart?

Use an iterative approach
The goal of your team should be to get as many team-members familiar with the application options and limitations as possible and to have at least one build expert for each area. The nature of software is that most people find the conceptual structures and relationships difficult to learn but once they know them it is very easy for them to build, edit and rebuild as needed. The organization benefits most if the team members understand the software itself rather than just the one or two configurations the organization has chosen. An iterative approach provides this type of knowledge allows for more creative solutions and encourages reevaluation. After each team has built practice configurations, have them regroup and decide on the baseline enterprise level configuration. Keep this initial configuration as simple as possible to allow for thorough testing and minimize complexity during and after go-live. Once the system is live and users have had time to become familiar with the baseline configuration, they will be better able to contribute to the next round of improvement.

The transition from paper to an electronic workflow is more than just translation; it is a creative process that leads to new efficiencies and improved experiences for both physicians and patients.

Tags: Allscripts Enterprise EHR, EHR, Successful EHR Implementation, TouchWorks

I worked with a large group who had been using TouchWorks for a year or so, after converting data from their previous EHR (a predecessor of TouchWorks). The conversion brought their Problems into TouchWorks; however, the problems were viewed differently and were now also viewed and managed by physicians, rather than only the nursing staff. While these changes were generally fine, the personal and family history that they had captured on paper, then showed in their old EHR, now cluttered patients’ problem lists – they had 10 copies of “Coffee Consumption” or “Denies Drug Use”. They also commonly had patients with duplicates of other problems as these didn’t appear as duplicates in the previous EHR.

We spent a few weeks designing a neat de-duplication process. I’ll spare you the details, but it went along the lines of finding problems of the same type, status, category and view. We’d take the oldest entry and keep it. We’d mark the rest as Entered in Error; however, we didn’t toss them away completely – we’d store each problem entry as an assessment on the first problem entry so you could always view the problem details to see the Audit/History.

We also took out some other attributes of the converted problems, such as the category of History Of for every problem and comments that the physician group thought might be useful.

Before I continue, I have to say – both the physician group and those assisting with the conversion (at Allscripts) did a great job of converting the 12 years of electronic charts (about 2MM patients). I think the biggest issue was the group not having a year’s experience using TouchWorks to make some of the decisions – hindsight is 20/20.

Luckily, we had the ability to make corrections as we went. We were able to convert millions of problems, removing duplicates (while maintaining their history!) and saving the clinicians a great amount of time and frustration. An internal medicine doc remarked that it saved him somewhere in the area of 100 hours of effort (not to mention the gray hairs).

I wouldn’t say we did anything extraordinary, but just had the luck to work on a fun project that helped out a couple hundred nurses and physicians. And hopefully make their transition to a (full) EHR a little more pleasant.

Tags: EHR, Technical, TouchWorks, TouchWorks Problem

Labs require that you provide them with the type of billing, and the insurance info if they are to bill the insurance company.  Sending this information with Allscripts Enterprise (formerly TouchWorks EHR) requires consideration of work flows and design.

Insurance information is easy with Enterprise – you store the insurance with the patient’s record from the Practice Management System (PMS), and then send it along to the lab with each Order placed in Enterprise.

Bill Type is pretty easy too – for the majority Orders that are placed.  Most clinics have certain rules that govern the insurance to be used.  It can be as simple as the clinic always bills the patient or their insurance, or they always have the lab bill.  There are times when the insurance or the order being placed may contribute – sometimes this logic is built in to your interface, other times it’s not deemed worth the build effort.  And, there may be other factors – such as the patient indicates that the reason for their visit is due to an on-the-job injury (Workers Comp).
I have not found a great solution for handling the exceptions, but I did see an interesting solution a few months back that works pretty well.

A group I was working with stumbled upon the Special Billing (aka Injury Type) dictionary and asked if we could use it.  We thought about it for a bit and it seemed to meet a lot of the needs that we had:

1. No impact on other modules – for them, and perhaps not for you, they did not send Special Billing information back to their PMS.  This is the only standard use for Special Billing information.
2. It affected all orders on a particular encounter – in their case they knew that all labs should be billed by the lab, except when they shouldn’t.  They could not determine the rules for exceptions from talking to the clinic – the employees there said they just knew when the clinic should bill and all orders for the encounter should follow that exception.
3. It was sent to the ConnectR interface.
4. They could create their own entries – such as “Client Bill”, “Third-party Bill” and “Patient Bill” (the three values the lab would accept).

Then we were on our way – a small change to the interface to override the logic we had built based on Special Billing / Injury Type, if it was set.  They added the appropriate entries and trained the users to pop in to the Encounter Form and set the Sp Billing value to “Client Bill” if the clinic should charge for the blood work.  It’s a great solution for groups that are otherwise not using Special Billing in Charge.

Tags: EHR, Enterprise Order, TouchWorks

Groups using the Allscripts Enterprise EHR (formerly TouchWorks EHR) that I’ve worked with have always yearned for a better training system. Issues with the current training system run the gambit, starting with the majority of groups using their Test or Production/Live system for training purposes. The groups that do have a training system often have a number of very reasonable requests.
Let me outline the ones I’ve always seen:

- The training system build / configuration isn’t close to production,
- Or it isn’t close to the test/development environment where new versions or new build work is available.
- The patient data isn’t realistic.
- The “test” patients become “cluttered”, e.g. 100 problems, 500 notes, 300 medications, etc, etc.
- The patients in the training system are real patients.
- The information is out of date. For example: tasks are months or years overdue or there are no appointments on providers’ schedules.
- If any of these are accomplished (for example, Galen has worked with a handful of groups to add some of the smaller, items such as de-identifying real patients, updating schedules and task lists), the physician group finds that changes are difficult, such as training both new users on the current version, and preparing to train users on a new version that they are upgrading to soon.

There are some serious technical hurdles to overcome to have a training system that avoids the above pitfalls and any others I failed to mention. The biggest hurdles come in combining an EHR “build” (menus, Note definitions, tasking work flows, etc) with patient data. If you can do that successfully, there may be other hurdles – for example, I talked to a large group about a training system several months back. We were able to design it in such a way that we overcame all of the above issues, but it required the client to purchase another server and work through some serious red-tape with their IT group, especially as it related to copying their production system. They would have been interested in the solution, if it were reasonably feasible to get a system that could do everything outlined above, but was completely remote – e.g. I would pick up their build (say from their prod or test system), upload it to a TouchWorks environment that we hosted, then play in the clinical / content information, such as patients, their charts, tasks, appointments, etc.

I’m curious to hear what folks think about training environments, what’s missing and what could be done without. Ideas?

Tags: EHR, Technical, TouchWorks

How do you create a manual for an application that requires fluid knowledge? The information of today may be changed by tomorrow’s hot fix, or next year’s upgrade. Knowledge about how people are using the system informs how we work to support them, their TouchWorks Allscripts Enterprise EHR system and their technical environment. Consultants to the Healthcare Industry must be more than just experts, they must be collaborators and partners with their client base in order to create the best and most robust systems for their clients and further the goals of better, higher quality medical care.

The Wiki is a tool that helps us to do just that. It is not a knowledgebase or SharePoint full of static articles that will be outdated tomorrow, but a dynamic and robust resource that can easily be updated to reflect the information that is current today. The Wiki is not “our” proprietary information. It is a collaboration between Galen employees and the greater EHR community (primarily Allscripts users right now)

Our knowledge and skills are constantly enhanced by the creative problem solving that we encounter as we work with our client base to develop systems that support physicians providing the best care to their patients. The Wiki is a tool that can keep up with the pace of information and innovation as we move forward. The name “Wiki” comes from the Hawaiian word “Wiki – Wiki” meaning fast.

Galen has been using the Wiki to publish answers to upgrade related questions as they are asked. Other collaborators can then see the information instantly (and are alerted in their outlook if they subscribe to the RSS feed) and can add any additional information that may be helpful.

Clients often come to us with real practical knowledge of their experiences with EHR and great stories of innovation that could be helpful to other product users. The Galen wiki is a place where users can have a platform to share their stories of how they made their system work for them and share suggestions with others. There are also talk pages connected to each article, so if a user has a question that they would like answered they could enter that into a discussion page connected to an article in order to get some additional information.

http://wiki.galenhealthcare.com

M. Maxwell Henson-Stroud, MSW

Upgrade Consultant

Tags: Allscripts Enterprise EHR, EHR, TouchWorks