This is the third video of our series about collaborative authoring. The video demonstrates how to create a reference set using dual blind authoring. The workflow scenario involves two authors working independently on a reference set with one reviewer.
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 the workflow and dual independent authoring
- Description of a use case with two independent authors and one reviewer, please select use case 5
- Information about editing reference sets
This is the third video about working in collaborative mode. Today I would like to demonstrate a scenario that involves two authors working independently on a task.
We will have the same users as in the previous video: I will be creating the task, my colleagues Balazs and Brandon will be the authors, and Orsi will be the reviewer.
We are logged into my account right now, which you can see down here and let’s start by creating a task for this scenario. We will be doing reference set authoring again, the task title is “Create Diclofenac reference set,” and I will use this in the task summary as well. The reference set will be called “Diclofenac simple type reference set;” the components are SNOMED CT concepts.
Now we have to select a scenario. In the previous video we used dual authoring, which meant that both authors were sharing the task of creating a reference set and working on one branch. In the scenario today the authors will be working on separate branches independently, so they do not see each other’s work.
Now I need to specify the authors: Balazs and Brandon, and Orsi for the reviewer. Let’s submit this task.
Dual independent authoring is something that is often used when you are creating mappings, for example, if different experts do to the mapping independently and you wanted to compare what each expert came up with. Another example would be a problem list for cardiology where specialists might have different opinions on what should be included in a cardiology reference set.
Let’s refresh the task list and take a look at the task that I just created. When creating a dual independent authoring task, you’re not just creating one task but three tasks that are automatically created. There’s a parent task and two branches. The reason for this is that we have the two authors working independently. So the first author is working on this branch, which has the number 6403, and the other author is working on the branch with that number.
Let’s go to the first author, to Balazs and take a look at how it is displayed in his view. We can see the parent task and the two sub-tasks. As you can see only one of the sub-tasks has this little white circle, which means Balazs is only able to activate one of those tasks because the other one is Brandon’s task. Since this is his sub-task we can open the editor and we can also see that he is specified as the author here in this sub-task.
Let’s activate the task. Now we have moved from MAIN to a separate branch when we activated this task. We can see the name of the task displayed down here and there is a “Diclofenac reference set” created on this branch.
Let’s open it, (you can see it’s empty) and add some members. Balazs would like to add this concept here, and this one. So I’m adding the concept and the descendants, and “Diclofenac poisoning” and its children. We’ve added ten members now.
I can also display those as a flat list where we can see each of the members individually. If you haven’t seen this, this is the reference set editor, which displays a list of the members that are part of the reference set. If you click on one of them you can see additional information displayed here and you could also maximize this. This would be the information about this concept.
If you double-click one of those members, you can see the full editor displayed with all the information about this concept.
OK, let’s assume Balazs is done. He added these different clinical findings, and he will save his work. To move the workflow forward to the reviewer, he has to change the status to FIXED, and save the status change. Now Balazs’ work is done.
Let’s go to Brandon. This is the task here; it’s already in his view. This is again the parent task, this is Balazs’ task, you can see it’s grey because Balazs has already completed his work. This is Brandon’s task; it has the white circle, which means this is a task that he can activate.
Let’s open the editor and activate the task. Now we’re moving from MAIN to the branch, here’s the link to the reference set that was just created for Brandon’s branch. So this reference set is empty. If you recall in the previous video – where Brandon and Balazs shared the task of creating a reference set – when Balazs added some members and saved them Brandon could also see the members that were added by Balazs in his reference set editor. But this was because they were working together on the same branch, now they’re working on separate branches so each of them has a separate reference set. Brandon could actually add exactly the same members because he does not know what Balazs was doing.
Let’s do a search for Diclofenac, and add “Adverse reaction” and descendants. These were two concepts that were also added by Balazs; I can also display this as a flat list. Let’s do something different now, let’s add some diclofenac products and descendants, I just added this branch of the hierarchy. We have six members overall, two clinical findings and four products.
Let’s say the work is done. Save the work. Now Brandon also has to change the status to FIXED, it’s not enough if just one of the authors changes the status like in the previous video. Since they’re both working on separate branches they both have to mark the task as RESOLVED FIXED to move the workflow forward.
OK, now both of their work is done. Now we can move to reviewer, which is Orsi. This is her account and here’s the task: We can see both of the authors are done, and Orsi is going to be working on the parent task because the parent task summarizes the work of both authors. It brings the concepts together that each of them added to their reference set.
When we’re working in this scenario we don’t need to activate the task. There’s actually not even an activation button here, it’s sufficient if Orsi just opens the editor and goes to the review tab. Let’s maximize this view. This is the work of Balazs who was working on branch and this is the work of Brandon who was working on the other branch.
Orsi is able to see the work of each of the authors in this table here: These were the products that were added by Brandon but not by Balazs, this is why these cells here are empty.
These were clinical findings that were only added by Balazs. These two concepts were added by both authors. So Orsi can instantly see, in which cases the authors agree and where they had different opinions on what should be part of the reference set.
The rest of the workflow is pretty much the same as in the previous scenarios: We have different buttons to accept or deny. She can use this button to accept all members of the first author and this button to accept all members of the second author. This button denies all members, you can also manually change the review. It’s just important that you review all items.
Let’s assume we only want to promote the clinical findings but not the products. Therefore we denied all products and accepted the clinical findings for the final reference set. Once this is done we save the review, then change the status to Mark as VERIFIED. If you forgot one of the items, you won’t be able to change this to Mark as VERIFED; this is how we’re making sure that all items are reviewed.
Now we need to save the status change. Once this is done we can promote the task with this button here. Just click it and that works just like in the previous scenarios that I showed. The accepted work is merging from the branch to MAIN.
Now the reference set has actually been promoted to MAIN. It’s the one that says diclofenac, and if we open it, it has only ten members. You can see they are all clinical findings; they all have this heart icon. You could open a member to take a closer look at each of the concepts. As expected, the products were not promoted because the reviewer denied them.
That’s it for today. In the next video we will make it even more complicated and add another reviewer. We will have two authors, two reviewers, and one adjudicator who makes the final decision about what is going to be promoted. Thanks for your attention. Bye-bye.