| QA Guidelines |
|
Congratulations on becoming part of Quality Assurance (QA) team! As a QA, there are several roles you will serve.
When you log in as a QA, you will receive the highest-priority, oldest job in the system, no matter if it is a QA job or a scribe job. You are expected to be a pillar of excellence for transcription accuracy and QAs should seldom feel the need to send a scribe job to QA. You are expected to maintain a Direct Send percentage of 95% or better on a daily basis. You will be expected to continue to put forth your absolute best effort on all scribe jobs, and to make wise decisions if/when you need to send a job to QA.
You should be productive with the time you spend on QA jobs. QA X-Factors should generally be as fast as, if not faster than, scribe X-Factors. If after your first couple of weeks at QAing your QA X-Factor is outside this range, you may need to talk to a supervisor about ways to be more efficient.
When you receive a QA job, you will notice a few things that look different in Formalizer:
When you first get a QA job, there are several steps you should take before you begin to review the job:
After you have set up the QA job, you can begin reviewing. Every job you receive as a QA should be reviewed in full. Here are some of the basics you will need to know when reviewing jobs.
Never assume the text is correct and all mistakes are already bookmarked. QAs can miss important changes because what you're reading affects what you're hearing. Sometimes it helps to close your eyes and re-listen to a questionable section to separate yourself from what was already scribed and help you decide if what the Scribe typed is actually correct. It may also be helpful to read ahead because if the sentence doesn't make sense in the context of the dictation, there is probably a mistake.
While your goal as a QA is to clear up as many bookmarks and inaccuracies as you can in a job, there are times when bookmarks are still necessary. Use your best judgment when it comes to clearing up bookmarks left by the Scribe and which bookmarks would be more appropriately used.
As a QA, it is part of your job to make a decision as to whether a Scribe has correctly chosen how to send the job (to QA or directly), and whether the Scribe processed the job on par with our quality standards. For all Scribes, new and old, the QA's function is to provide quality assurance and training by assisting with difficult and confusing dictations. You ARE NOT there to fix what a Scribe should have been able to do on their own before they sent the job out.
There may be some jobs where you feel you could clear up very little and you may be tempted to send the job to another QA for further clarification. However, this should almost never be done. If a job is that difficult, it probably wouldn't be fixed much by the third person. Always check with an OS or OM before sending a QA job to QA. In the rare case you do have to send a QA job to QA, you must always leave a comment to the next QA indicating why you're sending the job to another QA.
Note: If you have a scribe job where you encounter one of the Mandatory Reasons to Send to QA (i.e. vulgar content, bookmark in the subject), it is still mandatory that you send the job to QA with a comment indicating why. However, if you have one of these issues on a QA job you're reviewing, you should speak to an OS if you are uncertain of the accuracy.
After reviewing and making all necessary corrections to a QA job, review the Problem Fields and comments you have left in the F2 tab. This will help you determine whether or not the Scribe made the right decision of sending to QA or sending directly.
If you believe the Scribe did NOT make the right decision, you will update the blank comment you left in the F2 tab when you first got the job. If the job was inappropriately sent to QA, you will put "Reason/s for FQA". If the job was inappropriately sent direct, you will put "Reason/s for FDS". The comment can simply read: "Reasons for FDS" or "Reasons for FQA" as all the comments/problem fields left afterwards serve as reasons.
Once you've evaluated if the Scribe made the right decision, you will continue sending off the job. Even though you've already reviewed the job, you should still pay attention to the words flagged in spellcheck. Sometimes you may not catch a misspelling of a common English word while reviewing but it will be flagged in spellcheck. Misspelling of a common English word is an automatic reason to FDS (which we'll cover shortly).
After completing spellcheck, Formalizer will ask you "Decision Was Correct?". Marking "No" is how a job is marked as an FDS or FQA. If the scribe made the correct choice to send the job to QA but the errors still warranted an FQA, then you would still select "No".
When an employee is hired, re-hired, or found to be not meeting quality expectations, they will be in the "Employee Training" period until they reach certain productivity metrics. It is important to always check whether "Employee Training" is displayed in the top bar in Formalizer before you begin reviewing the job. If there is a valid reason to FDS or FQA on a job labeled as "Employee Training", you should still do so just as you would for any other job.
Reviewing jobs is a very important part of the learning process for Scribes in "Employee Training". Listening for comprehension is much more effective for many new Scribes when only listening and reading, as opposed to listening and scribing. It is essential that you, as a QA, leave helpful and encouraging comments on any job labeled "Employee Training". New Scribes are still getting used to navigating the documents, so it's always a good idea to reference the pertinent document/s to refer to in the future.
You should never be condescending in any comment that you leave for any Scribe, whether experienced or new. Your comments should be concise and informative. If you notice ongoing trends in a Scribe's quality, you should relay that information to an OS or OM and not address it in a comment to the Scribe. If a Scribe did a good job, we encourage you to comment that they did do a good job and to leave a smiley face after you leave any positive feedback or advice.
Scribes in Employee Training are still expected to send to QA when appropriate. If you are reviewing a job that warrants an FDS from a Scribe in Employee Training, you should FDS accordingly and explain why the mistakes they made warranted an FDS, and how to avoid those mistakes in the future. However, you should NOT automatically FDS or FQA a Scribe solely based on the "Employee Training" label.
In addition to QAs helping with the training process, we also have a series of training jobs that we assign to new Scribes. These jobs are designed to allow for new employees to practice certain concepts pertinent to the training process. Occasionally, you may receive one of these jobs as a QA.
Return to TopAn FDS, or False Direct Send, is the result of the Scribe choosing to send their job directly when there were significant errors that the customer should not have received. An FQA, or False QA send, is the result of the Scribe sending the job to QA when there was either no reason to send to QA or there were significant errors either not bookmarked or bookmarked incorrectly that affect the quality of the job. Remember, you ARE NOT there to fix what a Scribe should have been able to do on their own before they sent the job out.
In addition to using Problem Fields (see the Problem Fields document), marking jobs as FDS or FQA is an additional step for when the job itself does not meet our quality expectations.
As you process a job, you'll take notice of each mistake and mentally add up how it impacts the quality of the job as a whole, in terms of how these mistakes affect the meaning or readability of the job. An important aspect to consider is asking yourself "Was I able to understand this?". It is very difficult to grade or judge what someone else was able to hear. However, it is very easy to determine for yourself what you were able to hear.
As a QA, you help set the standard for quality, and what we expect of you is what we expect of everyone. So for each job you QA, the bar is set at what you were and were not able to clearly interpret. You have some latitude to make judgments about what would be an FDS or FQA, and you'll consider factors such as:
We realize that even the most experienced Scribe will make an occasional mistake, and our goal is to minimize the frequency and severity of errors in order to maintain a high quality and consistent product. Certain mistakes will weigh very heavily on the decision to FDS or FQA, while others will be a judgment call. Please understand that the nature of the job prevents us from being able to have all possible scenarios well defined.
On Direct Sends, there are 3 types of errors that would automatically result in an FDS. These 3 types of errors are not necessarily an automatic reason to FQA, but usually strongly impact your decision to FQA.
The following two notes should be kept in mind when evaluating whether to FDS for a misspelling.
Note: Bookmark usage, audio quality, speaker quality, and avoidability of mistake should be taken into consideration with Automatic Reasons for FDS. If you find a correction that qualifies as an Automatic Reason for FDS, but there is reasonable doubt as to why the mistake was made, you do not need to automatically FDS.
When a scribe sends a job to QA they are basically saying they had difficulty, that the dictation is not ready for the customer to see, and they're asking for help. QA sends will typically have below average audio quality. QA sends are also always going back to the scribe for review. Therefore, you should be more forgiving in issuing FQAs than FDSes. That said, you are not there to do the scribes' job for them, and sending a job to QA is no excuse for sloppy work. The reasons to mark a job an FQA are the same that you would mark a job an FDS.
Automatic Reasons for FDS are not considered Automatic Reasons for FQAs. However, these three mistakes will weigh heavily in your decision to FQA. If you feel you have a compelling reason for leniency, contact an OS.
Incorrect QA Send: One additional reason to mark a job FQA is if the job shouldn't have been sent to QA to begin with. This means there was no bookmark in the subject line, no profanity, no comment explaining an issue the scribe felt justified a QA send, and not enough bookmarks on their own to justify a QA send.
Note:The "three bookmarks per minute of dictation" guideline is just that: a guideline. It is NOT a rule. The reasoning behind the guideline is that, if a job contains more bookmarks than that, it is probably worth a QA's time to review it, while if it has fewer bookmarks it is probably not worth the QA's time. A QA should only FQA a job for being an improper QA send if the scribe is significantly below the 3 BM/min guideline. If they are close to the guideline, but you feel the job could have been sent directly, you should indicate that politely to the scribe in the comments section.
The following are factors to consider when evaluating whether to FDS or FQA. Some of these factors weigh more heavily to FDS on a direct send. When a Scribe chooses to send to QA, we can assume they were not confident in the quality of the job and if bookmarked appropriately, these factors may not weigh heavily towards an FQA. As a QA, you should use your best judgment when making your decision based on the following factors, or speak to an OS/OM if you are unsure.
A job should be marked as an FDS if there is a significant loss in information at the fault of the transcriptionist. This could be caused by a variety of things to include, but not limited to:
The frequency of these mistakes and total number of mistakes are important to consider when weighing a potential FDS or FQA, as well as the overall audio and speaker quality of the job.
The proper use of bookmarks is important. Adding unnecessary bookmarks makes the reader doubt the accuracy of the transcription, whereas not adding bookmarks where they are necessary gives a false representation to the quality of the transcription. A job could potentially be marked as an FDS or FQA if:
Note: If a Scribe has 3 bookmarks per minute of dictation, it is a good reason to send to QA. However, this is NOT a rule and if the bookmarks are not easily cleared, then you should not FDS unless there are other significant errors in the job.
Subject Lines need to be scribed as accurately as possible in ALL scenarios, and we need to minimize bookmark use in the Subject Line unless absolutely necessary.
Subject Lines have their own rules for punctuation and Scribes must adhere to those rules.
Advisor Assistant and other CRM Integrations rely on correctly formatted Subject Lines. Any mistake with an Advisor Assistant or CRM Subject line, or any other types of FDSable mistakes that are previously outlined in this document, weigh very heavily as a reason to FDS if they occur in the Subject Line.
Scribes are responsible for knowing how to correctly use the Error Codes. Choosing the wrong Error Code, or failing to choose the correct Error Code, is a potential reason for FDS.
If a scribe sends a job Direct-Send and there is an issue with the CRM integration (for example, because the CRM Processing Standards were not followed or because a subject line or Form was not selected or selected incorrectly), contact an OS. You will likely FDS the job. Refer to the CRM Processing Standards document in Formalizer for more information on how these jobs should be processed.
All Scribes are responsible for following the transcribing guidelines on the Standards document. Missing multiple Standards is a potential reason to FDS, or missing a particularly important/glaring Standards mistake is a potential reason for an FDS. Consider the following when making your decision:
All Scribes should be familiar with the Common Terms list and should have it as a reference on their screens at all times. QAs will take into account the difference between Common Terms that are difficult to find if heard wrong and Common Terms that were heard correctly but the Scribe mistyped it due to non-use of the Common Terms List. Missing multiple Common Terms is a possible reason for an FDS, considering how many were missed, how common they are, and how avoidable the mistake was.
Formatting of Common Terms is important, but is a lesser mistake than missing the Common Term outright.
Any incorrect Common Terms related to the following will almost always result in an FDS:
Minor mistakes are acceptable, but it becomes a problem when the mistakes are significant or frequent enough to where they alter the meaning or readability of the text. Errors that might warrant an FDS:
If the customer clearly specifies a section of text to be formatted a certain way (e.g. bullet points, bold, new paragraphs) then this is important to the customer and mistakes in this regard should be weighted heavily for a potential FDS. As always though, use your judgment as to the scale of the mistake and how understandable it was - sometimes the customer may give unclear instructions.
Note: Scribe formatting for Underline, Bold and Italicize may or may not show up on a QA copy. If you see a scribe seemingly hasn't done one of these, it should be corrected and commented upon but not used as a primary reason for an FDS, just in case this is a display bug on your end.
It's impossible to give all examples of this, but QAs should use their best judgment here and contact a supervisor when things of this nature pop up. The following errors should also be considered as a reason for an FDS or FQA:
If you feel a job should be an FDS even though the problem doesn't fit into any of the previous categories, you should contact a supervisor to assist you with making your decision. If you feel a job could be marked as an FDS, but after weighing all the factors you're leaning towards not FDSing, you should still contact a supervisor to notify them of the problems in the job.
As a QA, it is very important to mark Problem Fields (PFs) accurately and always when there are significant changes to the QA job, regardless of whether the job will be an FDS or FQA. The purpose of leaving comments on QA jobs is twofold:
In general, every significant change you make in your QA jobs should have a corresponding comment with an appropriate problem field. The main exception to this is when a Scribe commits the same error multiple times. If a Scribe misses a Common Term or Processing Standard multiple times throughout a job, leaving only one comment per set of identical mistakes is required. If a Scribe misses multiple Common Terms, each new Common Term they miss should have its own comment.
It is your responsibility as a QA to be familiar with the proper usage of PFs and to use your best judgment when selecting the correct PF. You should refer to the Problem Fields document for more details and examples for each Problem Field. In situations where you believe two or more problem fields cover the same mistake and one of those problem fields is a "Severe" and one isn't, use the Severe mistake. Otherwise, use your best judgment for which PF is most applicable.
Using Problem Fields incorrectly (or failure to use Problem Fields when they should be used) may result in further action, up to and including loss of QA status. If you see a job that had incorrect Problem Field usage you should contact a supervisor.
While some corrections can fall under more than one problem field, it is important that the most severe problem field for the correction is marked. You'll notice how the three automatic reasons for FDS are included in this category, as well as a few other ones. You should always mark these problem fields as you are processing each QA job as these issues very likely affect the meaning and/or readability of the job and will weigh more heavily towards your decision to FDS or FQA.
The following are considered Severe Problem Fields:
The second category of problem fields are less severe, meaning these mistakes did not have a profound impact on overall meaning and/or readability of the job. While all severe problem fields should be marked appropriately, the less severe problem fields can be more ambiguous. However, this does NOT mean that you should not mark a problem field.
Typically these individual mistakes would not warrant an FDS or FQA but if there are a significant amount of the less severe problem fields marked by the end of a job, it will weigh more heavily towards your decision to FDS or FQA.
The following are considered Less Severe Problem Fields:
The Problem Field that you choose will also determine how you should format the comment. There are 3 main ways of formatting comments:
This format allows the Scribe to see what they had put that was incorrect compared to the corrected text. This format should be used for the following Problem Fields:
This format shows the Scribe the corrected text only since the Problem Field is typically enough of an explanation for how to correct that mistake in the future. This format should be used for the following Problem Fields:
This format will be the most challenging for you at first. You will need to learn how to "standardize" your comments. There may be times where you will use one of the formats listed above but should also include an explanation for the Scribe to review. This format should be used for the following Problem Fields:
Refer to the Problem Fields document on examples for how to format comments appropriately.
Return to TopIt is essential that QAs provide pertinent feedback on scribe performance to supervisors. Properly relaying this feedback is expected of all QAs. Some situations require that you wait for further instructions from a supervisor before sending the job out, while other situations require that you simply inform the supervisor of the job information and issue at hand, and you can continue to process the job without waiting for a reply.
In most situations, it's best to finish QAing the job in full before providing feedback, because you don't know what else might happen in the job that may require the supervisor's attention. Some issues are better addressed by the scribe's OS than your OS. Contact your OS leaving the previous information and they will direct you to the correct office.
On a regular basis, your supervisors need to be informed directly of certain types of jobs via Psi. Whenever you message a supervisor about a job via Psi, ALWAYS begin your message by providing the following information:
Here are two examples of how to structure your Psi message:
[15:58:03] <gnv.jbason> Hey, are you there?
[15:58:37] <GNV OS - Brian Nelson> Yes.
[15:59:10] <gnv.jbason> can I ask you a question?
[15:59:13] <GNV OS - Brian Nelson> Sure.
[15:59:25] <gnv.jbason> I have a job where the scribe did something that I'm not sure if it's an fds or not
[15:59:30] <GNV OS - Brian Nelson> Okay, what is the Scribe ID? What did they do? How long is the dictation? Was it DS or QA?
[16:01:38] <gnv.jbason> the customer said to put the job in bullet points, but then he said bullet point number one, number two, number three, and the Scribe put 1. 2. and 3. instead of using dashes like a bullet point
[16:01:49] <gnv.jbason> it was 2118
[16:02:01] <gnv.jbason> the job was 3:13 and a direct send
[15:58:03] <gnv.jbason> Hey, I have a DS job from 2118, 3:13, the customer said to put the job in bullet points, but then he said bullet point number one, number two, number three, and the Scribe put 1. 2. and 3. instead of using dashes like a bullet point, should I FDS it?
[15:58:37] <GNV OS - Brian Nelson> No, when a customer says bullet point and then says it as numbers it's okay to actually do either bullets or numbers. That's on the Standards Doc :)
As a QA, you now have the responsibility of marking a job as an Issue when it needs to be sent to Copytalk's customer service. We will mark a job as an Issue any time the customer is clearly trying to talk to, contact, or get feedback from Copytalk. A job should not be marked as an Issue if there is any other content besides information that should be relayed to Copytalk.
Only QAs can choose this Error Code. Scribes can only use this Error Code if they are instructed to do so by a supervisor (or as outlined on the Error Codes doc for multiple error codes). With this Error Code, you would still transcribe the job as normal.
Always check with a supervisor BEFORE choosing this Error Code. Only QAs can choose this Error Code. Scribes can only use this Error Code if they are instructed to do so by a supervisor. With this Error Code, you would not transcribe the job, and the job will be discarded. This Error Code must never be used on a Note job.
When receiving a forms-enabled job, Formalizer's forms dropdown menu may display "Select Form" even when a Scribe correctly selected a form. When this happens, change the form to any other form. Formalizer will then create a prompt if you wish to erase the text from the Scribe.
When this happens, select "No." Formalizer's dropdown will then properly display the form with which the job was transcribed.
Jobs from scribes who fail to use the form, who use the wrong form, or who do not follow the form standards as listed on the CRM Processing Standards, should be marked as an FDS.
Return to TopYou should be familiar with most hotkeys by this point. As a QA, you should use as many hotkeys as possible. Below is a list of hotkeys you should use as a QA:
| Hotkey | Function |
|---|---|
| ctrl + arrow | Select text letter by letter |
| ctrl + shift + arrow | Select text by word or paragraph |
| select text + F2 + enter | Opens Problem Field |
| alt + 0 | Return to text |
| ctrl + F | Find/replace text OR search documents |
| alt + ↑ | Capitalizes entire word |
| alt + shift + ↑ | Capitalizes first letter of word |
| alt + ↓ | converts word to lowercase |
| ctrl + home/end OR page up/page down | Move cursor to beginning or end of text |
| ctrl + C | Copy |
| ctrl + V | Paste |
| ctrl + P | Split screen |
New QAs start at an elevated QA review percentage, in the same way that new scribes start at an elevated review percentage. Your primary role is to help train these new QAs. On a QAQA job the top section will be what the QA put and the bottom section is what the Scribe put. You will be editing the top part. It's very important to document any corrections as you make them, as you will be copying over the record of the original QA changes. The top of the job that records whether it was a Direct Send or a QA send is only indicating what the original scribe selected. Assume that the QA sent the job directly, unless they specifically leave a comment stating otherwise. You may press the dropdown arrow to the right of Get Job to see who the scribe and QA(s) were, as well as to select any iteration of the job.
All of the reasons for FDS in normal QA jobs apply to QAQA jobs. However, we do hold QAs to a higher standard, and the job should have very few mistakes after two people have gone through it. While a scribe missing a few Standards or CTs may not be sufficient reason to FDS the scribe, it would be sufficient reason to FDS a QA. In addition, you will be focused on the comments tab to make sure the QA:
You will use the same "Is the decision correct" tab in the final popup to rate the job an FDS or not FDS, but you are only making that decision for the QA.
WARNING: The Decision box will originally be set to whatever the QA selected. This means if they chose "no" to FDS the scribe, and that decision was correct, you will have to manually change that to "yes" to avoid FDSing the QA. Be careful to not accidentally FDS the QA!!!
Any time you believe the QA deserves an FDS you should message an OS. Feedback on new QAs is extremely important, and you should message an OS any time you encounter one of the comment mistakes listed above.
If you have any questions regarding any of the topics covered or not covered in this Document, please message an OS/OM via Psi.