Profile EMR Workflow Guide

Contents

• Definitions
• Change Request (CR)
  • Submitting a New Request
  • Active Request Workflow Diagram
    • Additional Details for Profile EMR specific workflow:
  • Analysis & Design Phase
  • Development Phase
  • QA Phase
  • Production Ready: Submitting and Managing your CCs
    • When is a CC ready to be submitted?
    • How to submit a CC
    • Expected timeline of a CC from submission to release
    • What is the re-submit process?
  • Closing Request Activities
• References and Templates

Definitions

• Work item – a unit of work that needs to be done/applied to our system. A workitem folder would be a collection of files used for the workitem (documentation, configuration steps, etc.)
• Change Control (CC) – changes to the product/application in a controlled, coordinated manner. There are a variety of types from small items to large initiatives/projects.
• Standard Order (SO) – a defined list of work items that are repeatable, do not require additional analysis, low risk, and can be done by anyone following the instructions. For SOs, please see the Zen Desk article specific for this workflow: https://imitspccs.zendesk.com/hc/en-us/articles/360060063932-Guidelines-for-Standard-Order-Requests 
• JIRA – the online tool where we track our workitems
• Intrahealth (IH) – the vendor who created the Profile EMR application.
• Forms - forms changes (add/amend/delete) are a common type of request we receive. For more details about form requests, see Form Reference Guides and Checklists

Change Request (CR)

Below outlines the processes used if a change is requested for the system.

Submitting a New Request

When a request comes in from a user, via email, ServiceNow ticket, etc., the first step is to identify if it is a considered a Standard Order. If it is, see the Standard Order section below. If not, create JIRA issue for tracking and its associated work folder for its file resources. Follow the steps below.

1. Create a JIRA ticket. Use the PCCIS Field Guide to help you create and manage your tickets: \\vch.ca\departments\PCCIS_DataShare\System Administration\JIRA Toolkit - PCCIS

2. Once the JIRA ticket is created, navigate to \\vch.ca\departments\PCAC_EMR\01 - PCCEMR\Work Items\00 - All Items (JIRA)\[GENERATE WORK ITEM FOLDER] and double click on Generate Work Item Folder.vbs

3. By following the prompts, it should then create the workitem folder properly named and with all the standard folders within. It also includes the templates for:

• Requirements and Specifications (reqs & specs), inside of the Analysis subfolder
• System Configuration (sysconfig)
• Test Case template, inside of the Testing subfolder
• Complex Form Checklist, inside of the Analysis subfolder
• CC Submission email, inside the Emails subfolder

The main folder should be visible in the 00 – All Items (JIRA) folder

4. Once this is set up, during the next intake meeting, it will be decided on how best to handle the request (cancel, pending/more information needed, assigned).

Active Request Workflow Diagram

Below outlines the usual workflow:

For more details, refer to the JIRA PCCIS Field Guide: \\vch.ca\departments\PCCIS_DataShare\System Administration\JIRA Toolkit - PCCIS

Additional Details for Profile EMR specific workflow:

• Everything that comes in from business will be a story. Switch it to bug type if it is:
  o A bug we found in the core system and in production that have been reported to IH
  o A bug we found during upgrade/build testing
• If there is an IH support ticket related to the request, add the ID number to Vendor Reference (can be found under the Project Management)
• If the item is on hold, use these statuses to help define why it’s on hold:
  o Waiting for support – on hold for internal reasons within IMITS
  o Waiting for approval – on hold waiting for business to approve/clarify/answer
• If the workitem is linked to other workitems, use these terms when linking it in JIRA:
  o Contains – Parent to Child
  o Is Contained By – Child to Parent
  o Relates to – any link items (Eg. These two need to go out together, this one needs to go out first, etc.)

Analysis & Design Phase

• During the analysis phase, the requirements and specification document must be completed. Note: if this is a Simple Form, no Reqs & Specs are required and the auto-generated file in the work item folder should be deleted.
• If needed the lead analyst can ask guidance during the bi-weekly analyst touch point meeting for clinical or business advise, or ask a senior developer if technical aspects need to be considered.
• During intake, some items will be marked to require Requirements and Specifications Document peer review. This is much like how the development phase has a Technical Review. If the work item is selected for this peer review, they should use the Reqs and Specs Review Checklist.xlsx as a base (see References and Templates)
• A communication plan should be decided and developed during this phase. There is a consideration section in the Reqs and Specs to help guide the analyst on this. If one is required, create a subtask to the JIRA as User Readiness for [JIRA ID]
• Note: for more details about form requests, see Form Reference Guides and Checklists

Development Phase

• A developer will be assigned If the workitem requires development.
• During intake if it is clear who would be best to handle it (it’s in their specialty), they may tag the developer in the comments to give them a heads up that this is an upcoming item for them.
• Development is to be done in the DEV environment only (there are exceptions like in cases where it needs larger data set)
• If it’s a complex items, developers may ask the analyst to do minor unit testing to confirm that this matches the specifications
• At this point, developers may ask for another developer to do a tech review (if it requires it) and an analyst to do QA on it. This can be done in tandem. 
• Note: If tech review is not required, please add a note in JIRA in the comments section for this so that the CC approver is aware that tech review was considered (not just missed). 
• For tech review, follow these steps:
  1. Developer will ask another developer to do the Tech Review item.
  2. Developer will create a subtask and assign it to the person who agreed to tech review, labeled as Tech Review – xxxxxxx where xxxxxxx is the title of the main workitem. (note the main workitem will stay with the main developer during DEV phase, or lead analyst if it's in QA phase)
  3. Tech reviewer will perform the review and mark the subtask done once all is good.
  4. After completion, the developer will let the lead analyst know it's completed and if it's not already set, assign lead analyst the JIRA ticket
• The developer needs to update the System Configuration file (sysconfig) either during this phase or before the end of QA phase (must be before Production Ready and CC submitted)

QA Phase

• Once development is complete, testing should be completed and included in Jira as a subtask. To see a full explanation on the QA process, please see Testing Process Overview 
• Before the end of QA phase and if the development is complex (ie: not a simple form), the subtask tech review must be completed before it can be considered Production Ready. Note: If tech review is not required, the developer needs to add a comment in JIRA so that the CC approver is aware it was considered (not just missed). If any major changes are asked during the tech review phase, another round of QA may be necessary. 
• If by this point the tech review task is not created and completed, or there is no JIRA comment by the developer saying that this work item is exempted from tech review, tester will reassign JIRA back to developer to finish this up.

Production Ready: Submitting and Managing your CCs

When is a CC ready to be submitted?

1. All analysis and design has been completed including:

a. Specifications and Requirements document completed. The exemption are Simple Forms however they should have the original request saved out to the Analysis or Email subfolder in its place.
b. Appropriate stakeholders have been engaged (Privacy/Decision Support/Interface Team/Excelleris/Health Records, etc.)

2. Testing is complete and the TestRail number is added to the comments of the JIRA ticket

3. If development was required, tech review subtask is present in JIRA and marked Done or a comment was made on why Tech Review wasn’t needed.

4. The JIRA ticket is an a Production Ready state

5. Everything is packaged up and ready for deploy:

a. Spec & reqs is finalized and saved to the workitem folder
b. If dev was required, a system configuration (sysconfig) document is completed
c. If no dev required, an instructional document on how to deploy is completed. Template for this can be found in SharePoint (see References)

6. If user readiness needs involvement, the plan has been signed off

a. In majority of the cases, user readiness work should be done before submitting the CC. There could be exceptions, but it must be agreed upon by the user readiness lead.

To see a full list of what is looked for during CC Approval, download CC Approval Checklist.xlsx from the References and Templates section

How to submit a CC

1. The work item's Emails subfolder should have a copy of the CC Submission.msg with it.
2. Fill in the appropriate fields as outlined in the template
3. Send CC Submitted email to [e-mail] 

Expected timeline of a CC from submission to release

After the CC is emailed, the CC reviewer will need 1-2 business days for approval process. If approved, the CC reviewer will deploy the CC immediately unless there is a specified target deploy date. Once that's done, the CC reviewer will send an email to the Contact listed in the CC submission email to let them know it's both approved and deployed. NOTE: Unless high urgency/impact and approved, CCs are not deployed on the last work day of the week (ie: Fridays or Thursday if the Friday is a stat).

What is the re-submit process?

Resubmission process is used when there is any change to the workitem that the CC reviewers are not aware of after the CC has been submitted but before it has been deployed. This could be a simple target deployment date change or an actual dev/config change. This could also include if the workitem needs to be put on hold or cancelled.

1. Lead analyst will send an email to [e-mail] with what and why the change needs to be done. Depending on the type of change, it may set back the target deploy date or cause a second round of approval.

a. If it’s a simple date change, the CC reviewer will check with the current schedule to see if it’s possible. If so, no further action needed by the lead analyst.

b. If additional dev or config changes are needed, possibly another approval round is needed which may delay the target deploy date.

c. If the CC needs to go on hold or is cancelled, the CC reviewer will contact the assigned deploy resource (if it was scheduled ahead).

d. All other changes will need to reviewed and actioned accordingly.

Closing Request Activities

These are the steps that must be done by the lead analyst (or delegate) after they have been notified that it has been deployed

1. Validate the change in EMR Production. Reminder that this is live so we can’t just add any information. Best if validation can be done with just viewing and not creating fake data. If it requires, it must be under the test client with PID 84484 or 148

2. Update the CC Submitted email as the CC Completed by updating:

a. Both Subject and body’s status changed to Approved/Completed

b. Update the Date/Time Deployment and Who implemented

3. Send out to who is outlined in our process document (see References for document)

4. Inform the requestor and others as required per the communication plan

5. If any User Readiness piece is needed for post-deploy, this is when it would be done

6. Close the request in JIRA. Refer to the JIRA PCCIS Field Guide: \\vch.ca\departments\PCCIS_DataShare\System Administration\JIRA Toolkit - PCCIS

References and Templates

1.  CC Approval checklist: Download the attached file CC Approval Checklist.xlsx to see the criteria that the CC Approvers follow. This can be used as a reference before submitting to minimize the chances of back and forth discussions before it can be approved.

2. Reqs and Specs peer review: Download the attached file Reqs and Specs Review Checklist.xlsx and use this as a base for analyst peer review

3. Flow chart for EMR CC Submission Process: \\vch\departments\PCAC_EMR\01 - PCCEMR\03-Guidelines & Tipsheets\EMR CC Submission Process.pdf