Here we see the Jira process for help desk issues. An example is, we have a customer that calls the help desk or enters a web ticket. In prior lectures, we learned that there were numerous avenues that an end user could use to submit a ticket. Two of those being; placing a call or entering an issue via the website that would allow them to open the help desk to get on their own, in which they could enter all of the pertinent information related to the issue and attach screenshots and supporting documentation. The issue is then logged via Jira. The Jira will sit in a queue, which will be picked up by a help desk agent, and triaged. Once the issue is triaged, and what we mean here is reviewed. What is the depth of the issue that's being reported? How severe is the issue that's being reported? Is the issue a patient safety issue? Or perhaps the issue is related to a registration workflow? But the end-user is still able to complete their daily function. These two examples would be of separate priorities. Patient safety would be a high priority, a registration issue where an end-user can still complete their workflow would probably be a minor or a standard priority. Then the issue will be assigned to the respective application team. Once assigned to the application team, there's typically subject matter experts within each application team that handles specific types of issues. Examples of this could be security-related issues, clinical-related issues, work-related issues, or reporting related issues. Once all of the work is completed, our Jira would be resolved. On this screen, we're going to talk a little bit more about the Jira process in detail. Help desk tickets are generally given a unique title for each issue. The reason for this is because when we look at a Jira queue specific to each application team, so our front desk registration application team or our clinical applications, we want to ensure that the title of our Jira correctly reflects the issue that's being reported. If we don't have specific titles, we can be misled, incorrectly route Jiras, or not pay attention to the Jira priority due to the title of the Jira. In many instances, tickets are submitted and the analyst designed will actually go ahead and update that title so that it reflects more closely the actual issue. An example of this is, if you work for a health system that uses Epic, an electronic health record vendor, you might receive tickets that are titled EPICROJ-HD. What this stands for is Epic Project - Help Desk. This is very generic and we would want to ensure that this were correctly updated to reflect the actual issue that was being reported. In the prior slide, we discussed different analysts that may specialize in certain areas. A reporting issue, we could rename the Jira to clinical reporting issue, pharmaceutical information and DC numbers incorrect. That would be a great name for a Jira ticket. It's more specific to the actual issue that's being reported. When it comes to assigning tickets, I briefly spoke of this in a prior slide, but typically an analyst on the team assigns the ticket to themselves and investigates. This can vary by team. Many healthcare organizations will have an on-call rotation. Within that on-call rotation responsibility is ensuring that tickets that are received by each application team on a daily basis are reviewed for prioritization, escalation, and assignment. There are some teams that when reviewing the tickets received for the day, depending on volume, may work those tickets when they're on-call. There are other teams that may assign those tickets out based on volume, analysts bandwidth, and areas of specialization and knowledge. Typically, analysts are assigned a day of the week and they could troubleshoot tickets that are logged that day. That would be more of the non on-call Jira review process role where analysts work on a rotating basis to review all of those Jiras that are coming in. This is really a great even way to split up the work. When you work in the health care IT space, especially with electronic health records, there are many projects that come along and many enhancements that come along. Bandwidth can really vary. The amount of volume for Projects on any given day, week or month can vary greatly. This is a really nice cohesive way to assign out tickets and ensure that everyone is reviewing tickets and working them as they can. If you have this type of rotation in your workplace, typically the rest of the week is spent working on those other assignments or projects that may have deadlines and be upcoming. Let's talk more about investigating the ticket issue. So what might an analyst actually do? The first step is really to try to emulate the customer. A great way that we can do this as analysts working with electronic health records or at a help desk for email issues or telephone issues, is we can emulate the customer and a copy of a production environment. Which basically means that we're not going to impact the end user or customer that called in and their workflow. We'll be able to sign into another respective system that is a duplicate of production. This would ensure that we are seeing what the end user sees and attempting to recreate the issue that they are reporting. What else may we do? Well, one rule of thumb, which we've discussed in other lectures, is ensuring that we reach out to the customer for more information. We could also be troubleshooting over the phone. There are different instances where troubleshooting over the phone or doing a screen share or troubleshooting through screenshots is appropriate depending on the type of issue that's being reported. Here what we see is we can call the customer, complete that screen share that I previously spoke of, maybe were able to resolve the issue right then. Perhaps it's a workflow issue, but we wouldn't have known this if we hadn't completed the screen share with the customer or the customer is reporting receiving an error message pop-up, by completing a screen share, we see this occur. We know that there is a system technical issue. We take a screenshot of the error received and we attach it to the Jira ticket. This is great supporting documentation so that we don't need to contact the customer again in an effort to have them recreate the issue. We can complete investigation, any build modifications that are needed based on that one share with the customer. The customer can show the analyst exactly what issue they're experiencing. Just receiving a Jira ticket, even with really thorough detailed documentation and screenshots, talking with the customer and seeing the customers workflow can be really a crucial key in the success of resolving an issue in a timely manner and understanding the issue that's being reported by the customer. Let's not forget our general rule of thumb. Even if all of our supporting documentation is in place, the description of the reported issue is excellent. It's always right to contact the customer so that they understand that ticket has been assigned to an analyst and it is actively being worked on. Clear documentation is key to what we do. Because what happens if I'm not here tomorrow? What happens then? Because if I leave projects halfway through, my colleague should be able to come behind me and pick up where I left off. We'll work in health care facility where we're dealing with patients lives. That is very important.
