[MUSIC] Hello and welcome back. I'm Jessica. You've probably heard the term Jira throughout other lectures. The focus of this lecture will be describing more and understanding exactly the role that Jira plays in the health IT Space. So in this lecture we'll review what is Jira, how Jira is used, the Jira process specific to help desk related issues, and what makes up a Jira a ticket. So let's start by reviewing exactly what Jira is. Jira is a product of the Atlassian company, which is based in Australia, and it's used for issue tracking and project management. So throughout other lectures we've discussed calling in to help desks, tiered escalation processes, the typical tracking for these issues, once a ticket is placed, is through Jira. This is the main mechanism of documenting and communicating system related issues at many healthcare organizations. The product name is a truncation of Gojira, the Japanese word for Godzilla. Jira is a very large product and it has a lot to offer. So this name is actually very fitting. One option for issue tracking and project management software, but not the only, and its main use of principles, are applications across multiple software options. So how is Jira used? Jira be used for help desk tickets. So if we have our end user that's experiencing an email issue or a telephone issue, they would call into their respective help desk and place a ticket to report the problem they're experiencing. It's important to remember such issues could be widespread. So email can impact many users across an organization which could hinder work flows. When the end user reports the problem, the help desk agent will typically open a ticket, enter all pertinent information, include attachments and screenshots, and then assigned to an analyst, if they're unable to resolve themselves. The same would be for a change request. A change request is a bit more specific in that software is typically in place, but there is a new piece of functionality that is being requested. Such change requests would go through a electronic health record, help desk analyst for additional build. These issues are also tracked using Jira. Jira tracking is great in the sense because not only are we logging issues and logging new build, but we contract process as well and where we are in the workflow. So for example, if we have a new change coming down the pipeline, we could enter Jirs ticket with all the pertinent information that we need. But we can also include business owner communication, validation, documentation and communication across teams or even within our own team. All of this information is crucial to the success of any build change. There is numerous checks and balances that any analyst must go through before moving any new build into the system. That's why Jira is so handy. All Jiras are numbered with the numbering convention available throughout the application team and are saved in a history and archived. This same rule of thumb would also apply to enhancement requests. Enhancement requests are billed that's in place, but operations or business owner has found a way to perhaps make a workflow work a little bit better. So we're going to streamline of workflow. We're going to use Jira in the same way documentation, communication and supporting the build that's going to go into place and a channel to track everything that's done along the way on this. Let's see, I'm starting that again. On this slide, you'll see an example of a simple Jira workflow. In the gray, we are waiting for a support or we're waiting for the customer. So this could mean a couple things. We're waiting for additional information or communication regarding an issue., is the issue still open, is the issue still being experienced? If the issue cannot be resolved at a tier one, then the escalation process will occur. From here, the status can either go from in progress or pending. Typically, the status will go to in progress, which means the Jira has been assigned to an analyst and is actively being worked on. However, there are instances due to prioritization. For example, if there is a priority project, an upgrade or a larger go live, a Jira may be kept in pending status until analysts have the bandwidth to begin working on the issue. Now each Jira that is submitted to the application team for the electronic Health Record Desk is reviewed for prioritization. If there are patient safety issues, these Jirs are typically not pended. They are escalated and worked on immediately because there are patient safety and clinical issues that need to be addressed and resolved as soon as possible. From here, we'll see that a Jira can either be canceled. So, for example, and NGO has submitted a ticket, but maybe the build wasn't the issue. Perhaps it was a training concern, or the NGOs are miscalculated a workflow and is asking that the Jira be closed on their own. We could cancel the Jira. For other similar issues, we could close the Jira. If there is build that comes into place and we have moved our builder production, we would not cancel the Jira. In that instance, we would close the Jira and the Jira would resolve. On this slide, we'll see another example off a more complex Jira workflow. So at the start of this video, we're seeing that we're waiting for support. We can either respond to a customer and wait for a customer response or we can start the work. Typically, when we start the work, it means that we have all the information that's needed. We've talked to the customer, we have all the supporting documentation and there is a complete and thorough understanding off the issue that has been reported. So then a Jira would move to in progress. When Jira is in progress, there's numerous steps that an analyst could take. It could be across application effort that requires different clinical teams to work together. Or a single clinical application could work within their own respective team to solve the issue. And then they would resolve and be completed with that issue. In the prior slide, we talked about the example where the customer submitted a ticket. Perhaps they had a conversation with the help desk analyst, but it turns out that they're asking to close the ticket because the issue that they reported was not truly a technical issue. And that's the key. If the issue is in a technical issue, you may find, the analyst is canceling the Jira. That means that no work needed to be done. There was really no additional research, and there was not a lot of hours put into the work within that Jira, then that Jira would be canceled. [MUSIC]
