Creating Allscripts Enterprise EHR Users

From Galen Healthcare Solutions - Allscripts TouchWorks EHR Wiki
Jump to navigation Jump to search

Creating Allscripts Enterprise TouchWorks Users


Creating and Maintaining users can be a daunting task with any application. This article is intended to provide information regarding the best approach to creating and understanding roles within AEEHR.

Defining Roles

The first step of the process is to understand your user community. Get a list of all of your potential AEEHR users that contains their role or title to begin understanding the different types of people within your organization. Using this list and an understanding of their function, group the users into roles being careful not to combine roles. There may be similar roles that would be easier to combine initially, but when thinking about long-term support, it is better to separate them. This gives you flexibility to make a menu or security change to a specific role and it'll ensure that you're not effecting another group of users.

Here is an example of the typical user roles within an organization:

   *  Biller
   *  Clinician
   *  Front Desk
   *  Medical Assistant
   *  Medical Records
   *  Nurse
   *  Nurse Practitioner 
   *  Physician Assistant
   *  Site Admin
   *  System Administrator

You'll also want to consider the approach you are taking when rolling out the Allscripts TouchWorks EHR. If you are doing a phased approach, you need to have an idea of which modules you are grouping into each phase. Define which roles will be effected by each phase. In some cases, a particular role may not begin using the application in the initial phase.

Designing Roles

Once you have an idea of the roles and phases you are implementing, you can begin designing the layout of the workplace. The first step is to understand which menu items a user needs access to for each phase your implementing. The best way to determine this is to log into Allscripts Enterprise as a user that has access to everything. Go through the application acting as each role while also considering the number of phases in your implementation process. For example, a front desk representative probably doesn't need access to the Charge module within Enterprise, so you wouldn't add that document to their workplace.

After you have defined the documents that each role will need access to for each phase of your implementation you want to consider the layout of the workplace. For the most part, the menus that Allscripts provides as a start are a great example of a good layout. There are however some tricks to saving users clicks (for anyone new, this is one of the most important things you can do). To consider ways to do this, you must really consider the work-flows that need to be performed.

For example, a clinician receives a task stating that his/her patient needs a refill of a medication. Before the provider can approve the request he must review the patients appointment history to determine the last time he saw them and also review the medication list to understand the last time it was prescribed. If you used a menu structure similar to the one delivered by default, the provider would need to click the 'Patient' VTB to review the appointments, then click the 'Chart' VTB to display the 'meds' HTB, then select the 'meds' tab to display the current list of medications. Once he/she is done the review, they would need to click the 'tasks' VTB to get back to the task list. At a high level, that took 4 clicks to review the information and get back to the task list. If you designed the 'tasks' VTB to include the appointments, and meds documents, the provider would be able to click on meds, then appointments, and then back to tasks. This saves them one click.

While one click doesn't seem like much, this can be done with other work-flows such as verifying results and signing notes. Reducing a click here and there translates into a time savings when the provider is completing these common work flows throughout the day.

The last step of designing the user role is to consider the security component. By default most security gates are turned off, but there are a lot of options out there. For example you can restrict editing rights, printing rights, and print chart rights. When used properly these security gates can be of great value. When you have determined which features you will use, you must determine which security codes a role will need. This process is similar to determining which menu items they need access to. For example, a Medical Assistant that fulfills refill requests will need the 'can prescribe' code to complete that request.

Building Roles

Now that you have defined the requirements, you want to be sure that you build the menu items and security groups properly to ensure that you can easily remember how it works and easily make changes to the menus in the future.

Assign Security Classifications to Organization Roles

Build Menus

Change User Name