The forth video of our series about collaborative authoring shows a scenario with two authors working collaboratively on a reference set. The reference set is revised by two reviewers and one adjudicator.
This video is part of our series about working in collaborative mode. You can find the videos of this series at:
- Video 1: Collaboratively authoring reference sets 1 (one author – one reviewer)
- Video 2: Collaboratively authoring reference sets 2 (two authors – single reviewer – dual authoring)
- Video 3: Collaboratively authoring reference sets 3 (two authors – one reviewer – dual blind authoring)
- Video 4: Collaboratively authoring reference sets 4 (two authors – two reviewers – one adjudicator)
- Video 5: Collaborative SNOMED CT content authoring (one author – one reviewer)
Once you’ve seen the video, you can find additional documentation at:
- General introduction to collaborative authoring
- Description of the use case demonstrated in the video, please select use case 6
- Information about editing reference sets
This is the fourth video of our series about working in collaborative mode. Today I would like to demonstrate a scenario that involves five users. We will have two authors – Brandon and Balazs – working collaboratively on a reference set. There will be also two reviewers – Orsi and Akos – and an adjudicator who makes the final decision about what is going to be promoted to the main repository.
We are logged into my account. Now let’s create a task for this scenario. It will be a SNOMED CT reference set authoring task and the task title is going to be “Create an Ibuprofen reference set.” I will use the same text for the summary and the name of the reference set is “Ibuprofen 2.”
Now we need to select a scenario: So far we’ve gotten through the first three scenarios. The last two scenarios are for five users. There are two options; one is for dual authoring and the other one for blind authoring.
The first option, which we’re going to do today, means that the authors are working collaboratively on a reference set, so they’re working on the same branch and are able to see each other’s work. The authoring part of the workflow is similar to the second video.
The other option would be that the authors are working independently on the reference set which is similar to the previous video that you’ve seen. So the authoring part is pretty much the same, it’s only the review part that changes. Therefore I will go through the authoring part fairly quickly today.
Now I need to specify the different users: Balazs, Brandon, Orsi, Akos and I will be the adjudicator today. Let’s submit the task to the task management system.
We can already go to the first author, to Balazs, and refresh his task list to bring up the task: Here it is. Balazs needs to open the task editor, and activate the task. He’s moving from MAIN to the branch now, we can see this down here. On this branch is the reference set, it’s empty and we can add some members: I will do this fairly quickly and just add two clinical findings and save the work.
Balazs’ job is already done, now let’s go to the second author, to Brandon. They’re both working on the same branch, so this is the same task here, he also needs to activate it to move to the branch and open the reference set. We can already see the work that has been done by Balazs. Now let’s add some pharmaceutical products and save the work. Since they are both working on the same branch it’s sufficient if one author pushes the workflow forward. This means that Brandon is setting the task status from ASSIGNED to FIXED and saving the status change.
Whenever there’s a status change or if someone leaves a comment here in this section all users that are assigned to the task, all users that are here in this part of the task editor get an email notification. This way the reviewers know that the task is ready to be reviewed. You can see that the green dots also moved from the authors to the reviewers and the adjudicator.
So we can go to the first reviewer, to Orsi. Orsi also has to open the editor and activate the task to start the review. So far this scenario has been similar to the second video, now comes the new part of the workflow.
The review tab is a bit more complex: There are different columns here, each of the reviewers has two separate columns: one is to accept or deny a reference set member and the second one is to leave a comment. These are Orsi’s columns: Here is her user name and her role, these two are for Akos, and these two are for the adjudicator.
Let’s assume Orsi would like to accept only the clinical findings, this one and this one. She cannot make changes in Akos’ column, if I click here nothing happens, she can only make changes in her part of the review tab. When she’s done with her review, she saves it and then Akos can continue. Of course they could also be working at the same time.
Let’s open the task here, Akos also needs to activate it, and since Orsi has already made some changes, I need to refresh this and maximize it. We can already see Orsi’s review because there is no such thing as dual blind reviewing. As soon as one reviewer saves his work the other one can see the review. The dual blind scenario, which I showed in the previous video, only applies to the authors but not to the reviewers.
Here are the columns with Akos’ name: Let’s assume he wants to deny these two reference set members. He agrees with Orsi in these cases, he also agrees with the clinical findings but he would like to accept these two pharmaceutical products. So there is some disagreement between the reviewers. He also has to save his review.
Once the reviewers are done they need to notify the adjudicator. If they’re working in a small team they might just communicate in person. If they’re working remotely, they could leave a comment here in the section, for example, “The review has been finished, please proceed,” which would trigger an email to the adjudicator.
Since I’m acting as the adjudicator, we go to my account now: I have to activate the task and open the review tab. I don’t need to check in which cases the authors agreed, this is set automatically, which we can see down here in this column “Automatically set by matching choice.” Because in these cases both of the reviews match, here both reviewers accepted and here both denied the reference set members. I only need to settle these cases, where the cells are empty. Let’s just assume I would like to accept these two reference set members, then I save my review.
It’s important that all items are settled. If one is missing, I cannot push the workflow forward; I cannot mark the task as VERIFIED. This way we wanted to make sure that all items are reviewed by both of the reviewers and also by the adjudicator, so that each of these cells is set either to accept or deny. Once this is the case then the workflow can be pushed forward. It’s also possible for the adjudicator to overwrite the decision of the reviewers: I could accept these two reference set members if I wanted to, but this is not the general role of the adjudicator. It’s usually just to settle the cases in which there was disagreement.
I moved the workflow forward, I marked it to VERIFIED, I need to save the status change and this enables the promote button. This is similar to the other workflow scenarios that we went through, now I can promote the reference set to the main repository. Only the reference set members that were accepted by the adjudicator are promoted. If I open the reference set, we can see it’s the two clinical findings and the two pharmaceutical products that were promoted, because the adjudicator has the final decision.
So much about dual reference set authoring with two reviewers. I hope you enjoyed this video. Thank you very much for your attention. Bye-bye.