Creating user/provider in v11
Steps for creating a User/Provider TW account
This is a document used to describe the manual process for creating accounts for Providers that will use note, Rx, charge, order, and etc. utilizing an electronic workflow. I call this the manual process because some of these steps will/can be accomplished using SSMT. It should be understood that although this document will describe all the steps required, it may not drill down to all the details. Additional detailed explanations and screenshots can be added later.
To begin: Log into TWAdmin> TWUser admin> click the Add button. Usertype dropdown = user/provider> enter Last name> enter First Name> email address> org dropdown = (select the name of the org).
User Details: Enter username> default password> profession> credentials> check the electronic workflow box> finalization authority (provider =8)> ownership authority (provider =8)(each client will choose the different authority levels based on the role of the user within their own organization, but "8" is fairly standard for a provider)
Provider Detail I: Enter Code (In v10 the code was automatically loaded. In v11 you must assign a unique code to each user. To make it simple and unique, we recommend that you use your orgainizations mnemonic paired with a number i.e. "GHC0001" Galen Healthcare 0001 > Order authority (8)> Primary Specialty> Secondary Specialty> DEA#> DEA expiration> checkbox Billing Provide> checkbox Schedulable> check the "PCP" box (if primary care)
Provider Detail II: Check the box(s) for prescribe levels 2-4 (as needed),> click “License”> click “add”> select state from the drop down menu> enter License #> enter expiration date> click “OK”> click “cancel”,> enter outbound Dictate ID
Address: If desired fill out the providers address
Security: Highlight “(the name of the org)”> click “Add/Remove” select and highlight security> click the down arrow button> click “OK”
Workplaces: Click “Edit Workspaces” button> click the ellipsis (…) button> click “search”> select the desired workplace (eg.Provider_WP)> click “Save”> click “OK”> Click the “Save button”
Done with TWAdmin (for now)
At this stage if you log in as this provider you will get a user agreement message to accept but this is in no way finished for the build. I think this is likely where the separation may be between an IS build for this provider and where "the practice" may finish the build.
Workplaces: Desktop view Log into TWAdmin> click Work Def Admin on the VTB> in View drop down to Default> search for user> click the down arrow to add the Default clinical desktop view to your user> click save.
Note View: In view, drop down to “Note View”> search for user> click the down arrow> click save. This is for granting note view from the clinical desktop and not to be confused with the view for the note module.
Note (module view): In view, drop down to “Note”> search for the user> click the down arrow> click save. This is needed for the note module and is separate from the note viewer in the clinical desktop.
Worklists: TWAdmin> click Work Def Admin on the VTB> click the “Worklist tab> click the “edit view” button> radio button =“User”> search for user> click Manage Personal tab> select desired worklist by highlighting> click “add to my views”> repeat for all needed> click “close”. (use the description for assistance in determining what to grant each user)
Task Views: TWAdmin> Task Admin> Manage personal> click “all”> search for user by Last name, First name> click “OK”> select desired views under Enterprise by highlighting> click “add to my views” (do this for all views needed based on role and site)
Chart Viewer: (view for chart NOT desktop views) TWAdmin> Chart Admin> click “all”> search for user by Last name, First name> click “OK”> highlight “All by section by subsection”> click “set as default”.
To verify that user was built correctly generally it is advisable to log in as that user perform a quick QA and log out. Then go to TWAdmin> TWuser admin> search for that user> check the box for “require password change”> click “save”. That will force the new user to choose a new password when they themselves sign on. This method of testing is not optimal when building out users on a large scale.
When creating a large number of users at one time it is best to create "shell users". The shell user is based on role. For example: "Test1, Nurse" would be a nurse role user set up. This user profile would be built out with all rights, preferences, tasks, views, etc. Once the set up for this role was completed, sign in and testing could be done on the front end. Then that "shell User" profile is copied with the actually user names on the back end or loaded via SSMT.