https://wiki.galenhealthcare.com/api.php?action=feedcontributions&user=Mwoodside&feedformat=atomGalen Healthcare Solutions - Allscripts TouchWorks EHR Wiki - User contributions [en]2024-03-28T18:27:19ZUser contributionsMediaWiki 1.35.1https://wiki.galenhealthcare.com/index.php?title=Extract_and_Load_via_SSMT&diff=13787Extract and Load via SSMT2012-06-08T20:55:30Z<p>Mwoodside: /* Access SSMT and Enter Database Login */</p>
<hr />
<div>__TOC__<br />
==Description==<br />
The Starter Set Migration Tool ('''SSMT''') is an Allscripts provided tool that allows clinics to extract and load the data in their Allscripts Enterprise EHR. Three common uses are:<br />
# To move data from one database to another<br />
# To load data from a spreadsheet to a database<br />
# To extract data, edit it, and then load it back<br />
<br />
This tool should only be used by persons who understands how and when to use SSMT and always adhere to the Allscripts documented process when utilizing this tool.<br />
<br />
{| style="background:#fcfcfc; border:1px dashed #ccc; padding:6px; width:100%;" <br />
| <br />
<span style="color:red;">'''Warning''':<br />
::Ensure that you complete a database [[SQL Backup]] prior to loading any data through SSMT. The tool is pretty robust, but human error or program bugs could create a mess. Completing a backup first takes only a few minutes and could save hours of time if something does happen.<br />
</span><br />
|}<br />
<br />
==Excel Formatting Tips==<br />
[[Excel]]<br />
<br />
==New SSMT released 1/12/2012- v2.2. HF 1==<br />
SSMT Version v2.2. HF 1 contains several changes (these can also be found on Supportforce> Production Documentation> SSMT and CMT category:<br />
* Removed "Security Code Name" field from content category "Task Name" in SSMT.* Added Specimen Type category <br />
* SSMT Installer allows clients to install a clinical and/or framework database that is not named "Works" and "IDXwf."<br />
* SSMT - "Favorites: Vaccines" creates and load a new entry successfully.<br />
* SSMT "Favorites: Medication" - The sublist of Users should be in alphabetical order by displayed user name.<br />
* Using SSMT to copy Task Views can corrupt the Task Views if the view (1) contains a Task Type with a name that has parentheses [such as 'Mng Chg Edits (Manage Charge Edits)'] or (2) contains many entries for a single filter in the view. <br />
* SSMT - Should be able to extract, edit, and load Note Definitions successfully.You are now able to extract and edit the "SectionDisplayName" column; change the "Default Action" column to "1" for all of the Assessment and Active Problems; and then load Note Definitions successfully.<br />
* SSMT content category "Clinical Desktop Views - Users" extracts the correct information for users and set users defaults appropriately.<br />
* SSMT is removing the entry from "NeedsInfoDEList" using the "OID - Orderable Item" content category.<br />
* SSMT content category "Favorites: Problem Based - Meds" - Should be able to remove items.You are now able to successfully remove favorite items using SSMT content category "Favorites: Problem Based &#8211; Meds".<br />
* The SSMT content category "OID_OCD Mapping" will now correctly overwrite existing OCD mappings in the OID and delete existing OCD mappings in the OID (this is equivalent to "unmapping" an item).<br />
* SSMT - The Suffix and Prefix fields are displaying in the wrong fields for Referring Provider.<br />
* Inactivate existing pre-11.2 favorites in an 11.2 environment using SSMT.<br />
<br />
==Access SSMT and Enter Database Login==<br />
<br />
1. Navigate to SSMT through Internet Explorer. Use the following URL and Replace Server Name with the web server name or IP provided by Tech or TOps:<br />
http://Server Name/TouchWorks/imps/ssmt/ssmt.asp<br />
<br />
2. Gather the following information from the Tech or TOps:<br />
* Clinical DB Server:<br />
* Clinical DB: (usually 'Works')<br />
* Clinical DB User: (contact Allscripts or your Galen resource for login credentials if needed)<br />
* Clinical DB Password: (contact Allscripts or your Galen resource for login credentials if needed)<br />
<br />
<br />
<br />
<br />
IDX Web FrameWork<br />
* FW DB Server: (usually same as Clinical DB Server)<br />
* FW DB: (usually 'IDXwf')<br />
* FW DB User: (usually 'sa') FW DB Password: (usually same as Clinical DB Password)<br />
<br />
3. After logging in, check the header to be sure that you are in the correct Database and Framework.<br />
<br />
[[Image:SSMT3.jpg]]<br />
<br />
4. Select a content category from the drop down menu. The name here should match the name in the Build Workbook EXACTLY<br />
<br />
[[Image:SSMT4.jpg]]<br />
<br />
==Extract Data==<br />
<br />
5. The Show Database calls box should remain unchecked unless you are using it for troubleshooting<br />
<br />
6. ALWAYS check show headers when extracting data<br />
<br />
<br />
[[Image:SSMT6.jpg]]<br />
<br />
7. Extract Data by clicking on the Extract data button in the lower left hand corner of the screen<br />
<br />
[[Image:SSMT7.jpg]]<br />
<br />
*This is what your screen will look like<br />
<br />
[[Image:SSMT8.jpg]]<br />
<br />
8. Open Excel<br />
<br />
9. Delete any headers existing in Excel<br />
<br />
10. Reformat all Excel worksheets as Text BEFORE loading extracted data to Excel<br />
The Excel default is General which strips leading 0’s so if extracted data is loaded into Excel before the cells are reformatted, it strips the zeros and does not “remember” they were there so formatting the cells to text ''after'' importing the extracted data will not work. Forgetting to change the cell format to text BEFORE pasting the data into Excel will cause problems in the application<br />
a) Click in the upper left hand corner of the screen to select all cells<br />
b) Right click and select format cells<br />
c) In the Format cells Dialog box select “Text” and click on OK<br />
<br />
[[Image:Ssmt9.jpg]]<br />
<br />
<br />
[[Image:SSMT10.jpg]]<br />
<br />
11. Navigate back to SSMT<br />
<br />
12. Click inside the large data field and use CTRL-A to SELECT ALL (including headers) <br />
<br />
13. CTRL-C to copy<br />
<br />
[[Image:SSMT11.jpg]]<br />
<br />
14. Navigate back to Excel<br />
<br />
15. Put your cursor in the very first cell of the Excel spreadsheet<br />
<br />
16. CTRL-V to paste the data into Excel (including headers)<br />
<br />
[[Image:SSMT12.jpg]]<br />
<br />
<br />
Check all cells for #####<br />
<br />
17. Do a find for # and reformat any column containing ##### to General<br />
<br />
a) Select the header of the column containing ####<br />
<br />
b) Right click and select format cells as General<br />
<br />
The #### means the data is too large for the cell. If the data is loaded into SSMT without changing the format of these columns to General the #### will be loaded in place of the data and cause problems in the application<br />
<br />
18. Done<br />
<br />
==Load Data==<br />
# Select a content category from the Go Live Weekend Configuration Guide. Find the same category in the BW extractions worksheet tabs. The category names should match exactly. If they do not, extract the same category with SSMT and make sure the headers match.<br />
# '''Verify the blank Excel worksheet was reformatted to text BEFORE the extracted data was pasted in'''<br />
#:The Excel default is General which strips leading 0’s so if extracted data is loaded into Excel before the cells are reformatted, it strips the zeros and does not “remember” they were there so formatting the cells to text ''after'' importing the extracted data will not work. Forgetting to change the cell format to text BEFORE pasting the data into Excel will cause problems in the application.<br />
#:Check each worksheet by clicking in the upper right-hand corner to select all cells and then right-clicking to format cells. You should see either no selection highlighted (because the sheet was formatted as text and then some columns were changed to general to fix ####) or Text highlighted. There is no way to tell if cells were formatted to text before or after importing the extracted data except to check with whoever extracted it. <br />
# '''Check all cells for #####'''<br />
#: Do a find for # and reformat any column containing ##### to General.<br />
#: Select the header of the column containing ####.<br />
#: Right click and select format cells as general.<br />
#:(#### means that the data is too large for the cell)<br />
# '''Modify Categories with Create (Y N) Column'''<br />
#: If the category has a column labeled "Create (Y N)" or something similar, change all these values to Y. load the data via SSMT (see details below), ignore the errors that say “No Record Found to Update”. Change all the Create (Y N) values back to N and load again. This should return no errors.<br />
# '''During GoLive, Try to avoid moving unwanted inactive items created in test to production'''<br />
#: Have a discussion with the client to identify these items because some inactive items may still be wanted in test. For the unwanted inactivated items created in test, make a back-up copy of the BW then delete the unwanted items from the BW before loading to prod via SSMT.<br />
# Navigate back to SSMT<br />
# Select the content category you will be loading from the drop down menu. The name here should match the name of the Excel worksheet exactly.<br />
# In the SSMT Window, use CTRL-A to select all, then hit delete. This ensures that there are no empty spaces in the SSMT data window that could throw off the Data you are loading.<br />
# Navigate back to your excel document. In Excel, you want to select all of your Data, but not the headers and no empty column. Grap starting from cell A2, even if there is no data in that cell and drag to grab all columns with data and '''NO MORE THAN 700 ROWS of DATA''' (SSMT can only move 65K of data at a time)<br />
# Use Ctrl-C to copy the Data<br />
# Navigate back to SSMT<br />
# put cursor into the SSMT Data Field<br />
# Use CTRL-A to select all<br />
# Use CTRL-V to paste data from excel.<br />
#* Note: using Ctrl-A then Ctrl- V helps ensure that you do not have any blank spaces in the data field that will distort your data.<br />
# Click on Load Data in lower left.<br />
<br />
*When [[Load Menus|loading menus]] the Server IIS Services MUST be restarted after the load for menus to appear and full privileges must be given to 'twappadmin'.<br />
<br />
==Error Messages==<br />
The SSMT tool returns various error messages. Here is a page dedicated to [[SSMT Error Messages]]<br />
<br />
==Content Categories==<br />
Below is list of content categories used to to migrate or update data via SSMT. Select the Spreadsheet name for a more in-depth description.<br />
* [[SSMT: Users / Providers]] - This is the spreadsheet used to load and manage user and provider accounts.<br />
* [[SSMT: User Security Classifications]] - This is the spreadsheet used to assign security classifications to user.<br />
* [[SSMT: RID - Resultable Item Dictionary]] - This is the spreadsheet that is used to load the result definitions from various lab vendors. <br />
* [[SSMT: OID - Orderable Item Dictionary ]] - This spreadsheet used to load Order Level items for various vendors.<br />
* [[SSMT: Order Performing Facility Identifiers]] - This spreadsheet is used to synchronize multiple vendors.<br />
* [[SSMT: OID - Order Defaults - Req Perf Location / Site]] - This is the spreadsheet that is used to set defaults on a [[Site]] or [[Requested Performing Location]] level. This can set various default behaviors such as charge behavior, order detail, and much, much more. <br />
* [[SSMT: OID - Order Defaults - Insurance/PatientLocation/Site]] - This is the spreadsheet used to specify orderable behavior on the insurance, patient location, or [[site]] level. It is used to set defaults such as the Default [[Requested Performing Location]], [[Requested Performing Location]] Picklist, Internal/External Required behavior, Referred to Vendor Org required behavior, Referred to Location Site Required behavior, and Referred to Provider Required behavior.<br />
<br />
* [[SSMT: Charge Codes]] - This spreadsheet is used to load or edit Charge Codes within TouchWorks<br />
* [[SSMT: Document Type]] - This is the spreadsheet used to upload or edit documents within TouchWorks<br />
<br />
* [[SSMT: Orderable Item Favorites | SSMT: Favorites Orderable Items <Order Type>]] - Used to load/edit/copy orderable items favorites. The various Order Types (Lab, Imaging, Supplies, etc)</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=File:CMT.jpg&diff=13786File:CMT.jpg2012-06-08T20:44:41Z<p>Mwoodside: uploaded a new version of &quot;File:CMT.jpg&quot;</p>
<hr />
<div></div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9615Enterprise EHR Test Strategy2010-11-18T21:11:56Z<p>Mwoodside: /* Test Cycle */</p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* '''Document''' - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.<br />
* '''Make the Certified your own''' - Use the Allscripts Certified Workflows as a jumping off point for your own documentation. These are well traveled pathways through the software and should provide the least resistance for your user community.<br />
* '''Level of Detail''' - Documenting test steps at the 'click' level is not necessary. The team that creates, and is ultimately responsible for test and validation, needs to be comfortable with the level of detail in the documented workflows. Enough detail and context should be provided such that ''most'' users with product experience can pick up a script and execute. Focus on clarity and application "triggers"; e.g. Charges dropping to an Encounter, Tasks falling onto a Task View or Worklist, Requisitions printing. Also, be sure to be clear with Who (RN, Doc, MA, Front Desk) is involved in a Workflow and where the changes from one use to another is made.<br />
* '''Peer & Clinical Review''' - Before testing begins (and Certainly prior to Go Live), Workflows should be reviewed with peers on the Application team and with end-users at the clinic who would be using the workflow to complete their work. Do not assume what was captured and documented in a design session is the absolute final product. Trust, but verify.<br />
* '''Change Control''' - Change are inevitable. Document the Team's Change Control Policy and be sure everyone on the team know how to request a change. Changes could be as simple as an update to a workflow, but should also consider application (build configuration) changes. <br />
* '''Build a living document''' - The final product should be a living document that evolves with the Organization's use of the application. A well built and well maintained set of workflows can be used in a variety of ways from testing a point release or hot fix to developing new avenues for end user training.<br />
<br />
===Test Cycle===<br />
* '''Assign a Test Lead''' - For consistency, a single Test Lead should be assigned for each Test Cycle. The Test Lead will coordinate who is responsible for testing which workflows and ensures coverage and communication throughout the cycle.<br />
* '''Assign Testers - who, what, when, where''' - Everyone involved with the testing effort should have a clear understanding of what is expected of them and how long they have to complete their assigned tasks.<br />
* '''Assign the work''' - Individuals (or teams) should be assigned and responsible for the completion of a workflow.<br />
* '''Report your results''' - Results (Pass or Fail) should be sent to the Test Lead. If a workflow scripts failed, a concise description of the issue is provided.<br />
* '''Do not hesitate to Fail a Workflow''' - People sometimes second guess their instincts and assume they are doing something incorrectly. If a testers thinks there is a problem with the behavior of the system (or the workflow), it should be reported as a failure. At the very least, the Workflow document should be updated with steps that are more clearly written.</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9614Enterprise EHR Test Strategy2010-11-18T20:58:32Z<p>Mwoodside: /* Clinical Workflow Documentation */</p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* '''Document''' - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.<br />
* '''Make the Certified your own''' - Use the Allscripts Certified Workflows as a jumping off point for your own documentation. These are well traveled pathways through the software and should provide the least resistance for your user community.<br />
* '''Level of Detail''' - Documenting test steps at the 'click' level is not necessary. The team that creates, and is ultimately responsible for test and validation, needs to be comfortable with the level of detail in the documented workflows. Enough detail and context should be provided such that ''most'' users with product experience can pick up a script and execute. Focus on clarity and application "triggers"; e.g. Charges dropping to an Encounter, Tasks falling onto a Task View or Worklist, Requisitions printing. Also, be sure to be clear with Who (RN, Doc, MA, Front Desk) is involved in a Workflow and where the changes from one use to another is made.<br />
* '''Peer & Clinical Review''' - Before testing begins (and Certainly prior to Go Live), Workflows should be reviewed with peers on the Application team and with end-users at the clinic who would be using the workflow to complete their work. Do not assume what was captured and documented in a design session is the absolute final product. Trust, but verify.<br />
* '''Change Control''' - Change are inevitable. Document the Team's Change Control Policy and be sure everyone on the team know how to request a change. Changes could be as simple as an update to a workflow, but should also consider application (build configuration) changes. <br />
* '''Build a living document''' - The final product should be a living document that evolves with the Organization's use of the application. A well built and well maintained set of workflows can be used in a variety of ways from testing a point release or hot fix to developing new avenues for end user training.<br />
<br />
===Test Cycle===<br />
* '''Assign a Test Lead'''<br />
* '''Assign Testers - who, what, when, where'''<br />
* '''Assign the work''' - <br />
* '''Report your results'''<br />
* '''Do not hesitate to Fail a Workflow'''</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9613Enterprise EHR Test Strategy2010-11-18T20:47:04Z<p>Mwoodside: /* Clinical Workflow Documentation */</p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* '''Document''' - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.<br />
* '''Make the Certified your own''' - Use the Allscripts Certified Workflows as a jumping off point for your own documentation. These are well traveled pathways through the software and should provide the least resistance for your user community.<br />
* '''Level of Detail''' - Documenting test steps at the 'click' level is not necessary. The team that creates, and is ultimately responsible for test and validation, needs to be comfortable with the level of detail in the documented workflows. Enough detail and context should be provided such that ''most'' users with product experience can pick up a script and execute. Focus on clarity.<br />
* '''Peer & Clinical Review''' - <br />
* '''Change Control''' - <br />
* '''Build a living document''' -<br />
<br />
===Test Cycle===<br />
* '''Assign a Test Lead'''<br />
* '''Assign Testers - who, what, when, where'''<br />
* '''Assign the work''' - <br />
* '''Report your results'''<br />
* '''Do not hesitate to Fail a Workflow'''</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9612Enterprise EHR Test Strategy2010-11-18T20:17:56Z<p>Mwoodside: /* Clinical Workflow Documentation */</p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* '''Document''' - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.<br />
* '''Make the Certified your own''' - Use the Allscripts Certified Workflows as a jumping off point for your own documentation. These are well traveled pathways through the software and should provide the least resistance for your user community.<br />
* '''Level of Detail''' - <br />
* '''Review'''<br />
* '''Change Control'''<br />
* '''Build a living document'''<br />
<br />
===Test Cycle===<br />
* '''Assign a Test Lead'''<br />
* '''Assign Testers - who, what, when, where'''<br />
* '''Assign the work''' - <br />
* '''Report your results'''<br />
* '''Do not hesitate to Fail a Workflow'''</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9572Enterprise EHR Test Strategy2010-11-17T21:55:11Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* '''Document''' - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.<br />
* '''Make the Certified your own''' - <br />
* '''Level of Detail'''<br />
* '''Review'''<br />
* '''Change Control'''<br />
* '''Build a living document'''<br />
<br />
===Test Cycle===<br />
* '''Assign a Test Lead'''<br />
* '''Assign Testers - who, what, when, where'''<br />
* '''Assign the work''' - <br />
* '''Report your results'''<br />
* '''Do not hesitate to Fail a Workflow'''</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9571Enterprise EHR Test Strategy2010-11-17T21:30:54Z<p>Mwoodside: /* General Preparation and Planning */</p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* '''Plan and schedule the testing cycle''' - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* '''Testers''' - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* '''Test Patients''' - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* '''Role Based Testing''' - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* '''Issue Tracking''' - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* '''End of day recap''' - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* '''Retesting Workflows''' - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and<br />
<br />
===Clinical Workflow Documentation===<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
===Test Cycle===<br />
* Assign a Test Lead<br />
* Assign Testers - who, what, when, where<br />
* Assign the work - <br />
* Report your results<br />
* Do not hesitate to Fail a Workflow</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9570Enterprise EHR Test Strategy2010-11-17T21:29:42Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* Plan and schedule the testing cycle - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* Testers - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MA, Practice Admin, RN) should also be encouraged to help with this effort.<br />
* Test Patients - A broad spectrum of Test Patients should be used when testing. When validating Workflows scripts, more often the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.<br />
* Role Based Testing - Different steps in the Workflow will required different User Roles of profiles. Each Workflow should reference Who is executing steps at any given time and also highlight when the workflow changes hands.<br />
* Issue Tracking - Some level of process must be used when reporting and tracking problems uncover during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.<br />
* End of day meetings and recap - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best use to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks. <br />
* Retesting Workflows - Any Failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue. Resting changes to the build can get overlooked and <br />
<br />
===Clinical Workflow Documentation===<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
===Test Cycle===<br />
* Assign a Test Lead<br />
* Assign Testers - who, what, when, where<br />
* Assign the work - <br />
* Report your results<br />
* Do not hesitate to Fail a Workflow</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9569Enterprise EHR Test Strategy2010-11-17T20:49:13Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
===General Preparation and Planning===<br />
* Plan and schedule the testing cycle - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* Testers<br />
* Test Patients<br />
* Role Based Testing<br />
* Issue Tracking<br />
* End of day meetings and recap<br />
* Retesting Workflows<br />
<br />
===Clinical Workflow Documentation===<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
===Test Cycle===<br />
* Assign a Test Lead<br />
* Assign Testers - who, what, when, where<br />
* Assign the work - <br />
* Report your results<br />
* Do not hesitate to Fail a Workflow</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9568Enterprise EHR Test Strategy2010-11-17T20:47:30Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
'''General Preparation and Planning'''<br />
* Plan and schedule the testing cycle - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.<br />
* Testers<br />
* Test Patients<br />
* Role Based Testing<br />
* Issue Tracking<br />
* End of day meetings and recap<br />
* Retesting Workflows<br />
<br />
'''Clinical Workflow Documentation'''<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
'''Test Cycle'''<br />
* Assign a Test Lead<br />
* Assign Testers - who, what, when, where<br />
* Assign the work - <br />
* Report your results<br />
* Do not hesitate to Fail a Workflow</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9562Enterprise EHR Test Strategy2010-11-17T20:31:41Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
'''General Preparation and Planning'''<br />
* Plan and schedule the testing cycle<br />
* Testers<br />
* Test Patients<br />
* Role Based Testing<br />
* Issue Tracking<br />
* End of day meetings and recap<br />
* Retesting Workflows<br />
<br />
'''Clinical Workflow Documentation'''<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
'''Test Cycle'''<br />
* Assign a Test Lead<br />
* Assign Testers - who, what, when, where<br />
* Assign the work - <br />
* Report your results<br />
* Do not hesitate to Fail a Workflow</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9561Enterprise EHR Test Strategy2010-11-17T20:16:33Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
'''General Preparation and Planning'''<br />
* Plan and schedule the testing cycle<br />
* Testers<br />
* Test Patients<br />
* Role Based Testing<br />
* Issue Tracking<br />
* End of day meetings and recap<br />
* Retesting Workflows<br />
<br />
'''Clinical Workflow Documentation'''<br />
* Document<br />
* Make the Certified your own<br />
* Level of Detail<br />
* Review<br />
* Change Control<br />
* Build a living document<br />
<br />
'''Testing Cycle'''<br />
*<br />
*<br />
*<br />
*<br />
*</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9560Enterprise EHR Test Strategy2010-11-17T20:13:51Z<p>Mwoodside: </p>
<hr />
<div>==Overview==<br />
The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.<br />
<br />
'''General Preparation and Planning'''<br />
* Plan and schedule the testing cycle<br />
* Testers<br />
*<br />
* <br />
* <br />
* <br />
* <br />
<br />
'''Clinical Workflow Documentation'''<br />
(*)<br />
(*) <br />
(*) <br />
(*) <br />
(*) <br />
<br />
'''Testing Cycle'''<br />
(*)<br />
(*) <br />
(*) <br />
(*) <br />
(*)</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Enterprise_EHR_Test_Strategy&diff=9558Enterprise EHR Test Strategy2010-11-17T18:55:58Z<p>Mwoodside: Created page with '==Overview== '''General Preparation and Planning''' '''Clinical Workflow Documentation''' '''Testing Cycle''''</p>
<hr />
<div>==Overview==<br />
<br />
'''General Preparation and Planning'''<br />
<br />
<br />
<br />
<br />
'''Clinical Workflow Documentation'''<br />
<br />
<br />
<br />
<br />
'''Testing Cycle'''</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Test_Guidelines&diff=9557Test Guidelines2010-11-17T18:54:31Z<p>Mwoodside: </p>
<hr />
<div>[http://wiki.galenhealthcare.com/images/8/81/Application_Change_Management_Protocol_for_Testing_Phase.rtf Application Change Management Protocol for Testing Phase]<br />
<br />
Superuser resource requirements for testing:<br />
<br />
1) '''# Providers''' 1 assuming standardization plus if there is a specialty or practice that has workflow(s) specific to that specialty or practice they should send a provider to test them<br />
An alternative would be to have a core team member demonstrate the workflow for the provider but that would probably take almost as much of the provider’s time.<br />
<br />
2) '''# and type of other users''' 1 per role plus if there is a specialty or practice that has workflow(s) specific to that specialty or practice they should send a superuser to test them<br />
For 1 and 2 above: These minimums are absolutely critical in order to ensure that the documented workflows actually cover all the critical details of all practices and specialties. The superusers and providers will be asked not to just test the documented workflow but to try anything they do that is not covered by the documented workflow.<br />
<br />
3) '''Total duration they will be needed for''' 4 hours per day for 2-3 days total<br />
<br />
4) '''# hours per day''' They do not have to test every day, the number of hours will depend on how many roles and workflows they test. I would say 4 hours on the days they are needed for testing. Generally they would test for 1 or 2 days near the beginning of the testing period as part of the 1st or 2nd testing cycle and then possibly be asked back a week or so later to retest if significant changes are made to the config or workflow.<br />
<br />
This testing time will also provide additional training for those involved and increase organizational acceptance.<br />
<br />
For more information, please see: [[Enterprise Test Strategy]]</div>Mwoodsidehttps://wiki.galenhealthcare.com/index.php?title=Test_Guidelines&diff=9556Test Guidelines2010-11-17T18:54:00Z<p>Mwoodside: </p>
<hr />
<div>[http://wiki.galenhealthcare.com/images/8/81/Application_Change_Management_Protocol_for_Testing_Phase.rtf Application Change Management Protocol for Testing Phase]<br />
<br />
Superuser resource requirements for testing:<br />
<br />
1) '''# Providers''' 1 assuming standardization plus if there is a specialty or practice that has workflow(s) specific to that specialty or practice they should send a provider to test them<br />
An alternative would be to have a core team member demonstrate the workflow for the provider but that would probably take almost as much of the provider’s time.<br />
<br />
2) '''# and type of other users''' 1 per role plus if there is a specialty or practice that has workflow(s) specific to that specialty or practice they should send a superuser to test them<br />
For 1 and 2 above: These minimums are absolutely critical in order to ensure that the documented workflows actually cover all the critical details of all practices and specialties. The superusers and providers will be asked not to just test the documented workflow but to try anything they do that is not covered by the documented workflow.<br />
<br />
3) '''Total duration they will be needed for''' 4 hours per day for 2-3 days total<br />
<br />
4) '''# hours per day''' They do not have to test every day, the number of hours will depend on how many roles and workflows they test. I would say 4 hours on the days they are needed for testing. Generally they would test for 1 or 2 days near the beginning of the testing period as part of the 1st or 2nd testing cycle and then possibly be asked back a week or so later to retest if significant changes are made to the config or workflow.<br />
<br />
This testing time will also provide additional training for those involved and increase organizational acceptance.<br />
<br />
More more information, please see: [[Enterprise Test Strategy]]</div>Mwoodside