Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
There are many different requirements for workflow and processes for people developing maps depending on their business situation.
A wide variety of different team sizes, management styles and business processes are in use and so Snap2SNOMED has been designed to provide workflow support for collaborative authoring and reviewing tasks when developing a map while remaining flexible enough to support as many different workflows as possible.
Depending on personnel resourcing availability and internal business requirements, there are different ways to set the author/review workflow.
Snap2SNOMED supports the requirements of managing a variety of different workflows. Depending on business requirements and availability of personnel, a project owner can assign different roles to users to achieve different levels of control.
Participants can have one of three roles within a project:
Parallel
While authoring is being completed, review is occurring simultaneously.
This may be useful when time efficiency is required as processes can occur in parallel. It may also be useful where you do not have dedicated team members who can only spend shorter periods of time working on map development. It may be more difficult to maintain consistency, so clear, updated documentation and communication on mapping rules between team members is important.
Authoring tasks are created
As authoring begins review can begin. Review tasks can be created assigned
At the beginning containing all rows - users can check their review tasks periodically and review rows belonging to the task that are in the appropriate state (MAPPED), returning back and checking again until complete; OR
Hybrid
Mix of series and parallel workflows can be used. This can be a combination of completing authoring prior to review, and having some tasks open and close as resources such as specialised reviewers become available.
A hybrid approach would require close management by the map owner to ensure all work is completed.
This may be useful when you have a varying team with different resourcing availabilities. It may be more difficult to maintain consistency, so clear, updated documentation and communication on mapping rules between team members is important.
Note: there is currently no notification system available to notify users that work has been done or comments have been left. Manual monitoring needs to be done to keep track of workflow by users within a project.
Series
Authoring is completed before review is started. Once review is complete, an author can then pick up any rows that have been identified as problematic and then the author/reviewing cycle continues. This may be useful when time is not an issue. Doing it this way may make it easier to ensure consistency as reviewing can be completed when looking at the map as a whole (as well as individual map rows). As work is not done in parallel, this method can be more time consuming.
Authoring tasks are created
Once all rows in the source code set have been mapped and all authoring tasks completed, review tasks are created
Review tasks are completed
Where there are rejected map rows, new author tasks can be created containing those filtered rows and assigned to user(s) to author/update
New review tasks are created containing those newly mapped/updated rows and assigned to user(s) to review
Steps 4-5 repeated until all rows are approved
Note: Once an author task is completed, if rows have been rejected by a reviewer, then a new author task needs to be created.
A member has some permissions within a project. They are able to manage their own workflow within a project
Guest
A guest has limited permissions within a project. They have read access to the project and are unable to manage any workflow. They can only complete tasks that are assigned to them by the owner(s)
Some example scenarios
1
Single user project
By default, a single user project has one owner. No other settings are required
Owner
An owner has full permissions within a project. They are able to completely manage project membership and project workflow. A project must have at least one owner.
Member
As reviews are being completed and there are any REJECTED rows that
belong to an active author tasks, the assigned author can update as required
do not belong to an active author task (as it has been completed or cancelled), then these can be filtered and assigned to a user(s) to author/update
This process is continued until all rows are approved
The "Owner" is able to self-select work and manage membership to project
Full control of owner
1 user (owner) controlling membership
2+
Project owner wishes to direct the workflow of all author and review work and specify who does what and in what order.Project owner wants to have full control of project membership
Project owner can assign all participants in the project as "Guests".
Project owner can then create tasks and assign them to each "Guest" as required to complete the work"Guests" cannot self-select work, but need to be assigned tasks by the owner
High level of control of owner
1 user (owner) controlling membership
2+
Project owner wishes to allow some users to self-select and complete work, but direct work specifically to other usersProject owner wants to have full control of project membership
Project owner can assign some participants as "Members" and some users as "Guests"
"Members" are able to self-select work"Guests" cannot self-select work, but need to be assigned tasks by the owner
Moderate level of control of owner
1 user (owner) controlling membership
2+
Project owner wishes all users to self-select and complete workProject owner wants to have full control of project membership
Project owner can assign all participants as "Members"
"Members" are able to self-select work
Low level of control of owner
1 user (owner) controlling memberships
2+
Project owner wishes all users to self-select and complete workProject owner wants assistance in controlling of project membership
Project owner can assign some participants as "Owners" and some users as "Members"
"Owners" are able to self-select work and manage membership to project"Members" are able to self-select work
Low level of control of owner
Multiple users (owners) controlling memberships
2+
Project owner wishes all users to self-select and complete work and to allow other participants to manage membership
Project owner can assign all participants as "Owners"
"Owners" are able to self-select work and manage membership to project
Low level of control of owner
Multiple users (owners) controlling memberships
2+
Project owner wishes to allow some users to self-select and complete work, but direct work specifically to other usersProject owner wants assistance in controlling of project membership
Project owner can assign some participants as "Owners", some users as "Members", and some users as "Guests"
"Owners" are able to self-select work and manage membership to project. They can also create tasks and assign them to other users"Members" are able to self-select work"Guests" cannot self-select work, but need to be assigned tasks by the owner
Moderate level of control of owner
Multiple users (owners) controlling membership
A project is a collection of one or map versions that have the same source and target code systems (but not necessarily the same code system versions).
For example a single project could contain 2 maps: ACME codes to SNOMED map v1 (source: ACME code system v1.0, target: SNOMED CT International version 20210131) and ACME codes to SNOMED map v2 (source: ACME code system v1.0, target SNOMED CT International version 202107031).
When creating a new map, a project is automatically created. When a new version of an existing map is created within the tool, it will be placed into the same project as the original version that has been copied.
Snap2SNOMED is designed for collaborative map development. When creating a map, the user decides between two overall workflows, namely:
Single author mode
Dual author mode
Each of these overall approaches supports a range of options for collaboratively developing a map from a given source code set to SNOMED CT.
This overall approach supports multiple users working simultaneously on a map in a single author, single reviewer per source code manner. This means that work can be divided across a number of personnel to get work done.
A variety of workflows are currently supported, including:
A single user completes all author tasks for the map and then completes a review process on all mapped rows
A single user completes all author tasks for the map.
No review process is required
A single author completes all author tasks for the map.
A second user, the reviewer, will complete a review process on all mapped rows.
Two or more authors create mappings for each source code of the map.
Two or more reviewers completes the review processes on all mapped rows.
NOTE: A user can act as both an author and reviewer within the overall map (as assigned in a task), however, rules have been implemented to discourage the scenario of a user to reviewing their own authoring work. This can be overridden by an owner if required.
In the example flow shown, User 1 and User 4 can be the same person, ideally only reviewing the work of User 1+2.
Dual author mode allows two authors to independently map the same source codes. Conflicts arising from differing interpretations are identified and resolved through a reconciliation process. This workflow brings the advantage of diverse perspectives, allowing for a comprehensive assessment of mappings. It ensures a cross-validation process where conflicting interpretations can be discussed, resolved, and reconciled, leading to accurate and reliable mappings between different coding systems or terminologies.
A variety of workflows are currently supported, including:
Two users user completes all author tasks for the map.
A reconciler completes the reconciliation of conflicting maps.
An assigned reviewer completes the review of all map rows.
Two users user completes all author tasks for the map.
A reconciler completes the reconciliation of conflicting maps.
One or more users are assigned as reviewers for a specific set of source codes. Each map row is assigned to a single reviewer.
Two or more users complete the author tasks that have been assigned to them. The work is divided so that two users are mapping each source code.
One or more users are assigned as a reconciler. Each map row is assigned to one reconciler.
One or more users are assigned as reviewers for a specific set of source codes. Each map row is assigned to a single reviewer.
Two users complete all author tasks for the map.
A reconciler completes the reconciliation of conflicting maps.
No review process is required.
In Dual Author Mode, two independent mappers work separately on the same mapping task. The system keeps their mappings blinded until both have completed their work. Once both mappers submit their mappings, the system compares the results:
If both mappers select the same target, the row is marked as MAPPED and requires no further action.
If the mappers select different targets, the row automatically moves to RECONCILE, where a reconciler will review and determine the final mapping.
Key Considerations for Reviewing in Dual Author Mode
No Dedicated Reviewer Role: Unlike Single Author Mode, this mode does not require a separate reviewer because the reconciliation process ensures that discrepancies are addressed.
Modifying a Locked Mapping: Once a mapping is unblinded, it cannot be changed by either author. However, if adjustments are necessary, the status can be changed to RECONCILE using bulk change, or the Clear Targets option can be applied via bulk edit to reset the mapping and the blinding flag.
Handling Rejected Rows: If a reviewer (in an assigned review workflow) rejects a row, its status can be changed to RECONCILE using the bulk change feature. A reconciliation task can then be assigned to ensure the mapping is corrected.
Tasks are the way that Snap2SNOMED manages the workflow. All work being done within a map should be done through the tasking process.
Each task has a task type, an assigned user and assigned rows. Permissions for creating tasks is determined by the user's role (see table X)\
There are two different task types
Author tasks
Review tasks
Author tasks allow an assigned user to edit a source code mapping by adding or updating target codes, or adding "No Map" flags.
Review tasks allow an assigned users to review mapped source codes by giving them statuses of ACCEPTED and REJECTED.
Snap2SNOMED has two features to assist with mapping
This feature is available to users within an author task.
The bulk automap feature will attempt to return a match within the target scope of the map. If no map can be found, the target will remain blank.
All matches found will be set with a relationship type of "INEXACT". This is because the automap feature is unable to determine the level of equivalency of the match.
It is strongly recommended that all matches suggested by the automap feature are checked by a human mapper.
This feature is available in the detailed view of a source code. Users can use these suggestions for mapping by dragging and dropping their choices into the relationship box.
This is the user who is able to complete the task. Users who are not the assigned user are not able to access the task.
These are the rows that are assigned to a task. They allow users to interact with these rows within the task.
Each map between source and target should have a defined type of map relationship describing the type of relationship or degree of equivalence of source and target code.
Snap2SNOMED uses the following definitions
Equivalent
The definitions of the concepts mean the same thing (including when structural implications of meaning are considered) (i.e. extensionally identical).
Snap2SNOMED supports maintenance of maps that have been created within the tool and also allows upload of simple maps in a defined format for maintenance.
Maintenance is supported through the following workflows
Broader
The target mapping is broader in meaning than the source concept.
Narrower
The target mapping is narrower in meaning than the source concept.
Inexact
The target mapping overlaps with the source concept, but both source and target cover additional meaning, or the definitions are imprecise and it is uncertain whether they have the same boundaries to their meaning.
No match/unmatched
There is no match for this concept in the target code system.
Removed or retired codes in the source
tool will remove the rows from the map
New codes in the source
tool will create rows for the new source codes, with an empty target
Owners or members can filter empty target fields to create a task to complete mapping process
Identify changes in map due to change in target scope
Out of scope or retired codes in the target
Owners can use VALIDATE function in tool to identify out of scope codes
Owners or members can filter identified rows to create a task to update map targets and complete mapping process
New target codes in code system
Owners or members can filter relationship type for any type except for equivalent to create a task to review and update map targets and complete mapping process
Upload existing map
An existing map can be uploaded into the tool to then be updated.
Create new version of an existing map, update source scope (code system), target scope (code system) and migrate existing map rows
A new version of an existing map in the tool can be created through the project list by selecting the version to be copied and then creating a new version.
For map rows that are copied, the tool will migrate
source
target
relationship
status (e.g. DRAFT, MAPPED, ACCEPTED, etc.)
last author/reviewer data
Identify changes in map due to change in source scope
Status denotes the state of the mapping of a source code (not specifically to the targets).
UNMAPPED
Source code has neither a target or "No map" flag assigned
This is the default status when a map has been created and a target is yet to be assigned.
It will also occur when a "No map" flag has been removed.
The statuses used in this tool are split between the two task types, mapping and reviewing.
Mapping statuses are UNMAPPED, DRAFT and MAPPED.
Reviewing statuses are IN REVIEW, ACCEPTED and REJECTED.
In a mapping task, a user is able to transition a source code's status between UNMAPPED, DRAFT and MAPPED and where a source code has been rejected by a reviewer, the user can also change REJECTED to DRAFT or MAPPED. If a review process is being used, a status of MAPPED can also be considered the same as "ready for review".
In a review task, a user is able to transition a MAPPED source code to IN REVIEW, ACCEPTED and REJECTED. The IN REVIEW status is designed to be like a lock for the source code so no further changes can be made by the author. A reviewer can choose to bulk change all the status of the valid rows in their task to IN REVIEW if they wish to lock them while they are working.
Snap2SNOMED supports the creation of mappings between source codes and SNOMED CT target codes in the form of a map.
A map is a tabular form of the associations between source codes and target codes, and the relationship between them.
A new map is automatically created when creating a new project. A new map version can also be created from an existing map in the tool.
Maps require a
Name
Version
DRAFT
Source code has one or more target codes or a "No map" flag assigned and is in a draft state.
The status will automatically change to draft when a map row has been edited.
Examples:
when a target code has been added to source code with a status of UNMAPPED
when a target code is changed for a source code with a status of MAPPED
when a No Map flag is added to a source code
MAPPED
Source code has one or more target codes or a "No map" flag assigned and is in a completed map state.
This is a manual status change by an author to denote when the authoring of a mapping of a source code is complete and ready for review (if a review process is being used).
When a source code has this status, it can be reviewed if required
IN REVIEW
Source code and its mapping(s) is currently being reviewed
This is a manual status change by a reviewer to lock the source code from any changes by an author.
ACCEPTED
Source code and its mapping(s) have been accepted by the reviewer and mapping is complete.
This is a manual status change by a reviewer to reject the mapping and should be remapped by an author.
REJECTED
Source code and its mapping(s) have been rejected by the reviewer and needs remapping by an author
This is a manual status change by a reviewer to reject the mapping and should be remapped by an author.
Source scope (upload a source code set)
Target scope (SNOMED CT version and ECL subset)
Maps can be authored/updated in Snap2SNOMED and is managed through tasks.
Within an author task, the tool allows you to edit a row by interacting with the map table or by using the detailed view.
The map table view allows you to interact with the table directly (dragging and dropping terms from the search, selecting relationship and status from the drop downs etc.).
The detailed view is another view of a mapping which shows one source code and its associated information at a time. In this view you can add one or more target codes, update target codes, relationships and status.
Within a review task, much like authoring, the tool allows you to edit a row by interacting with the map table or by using the detailed view.
The map table view allows you to interact with the table directly (changing status to review).
The detailed view is another view of a mapping which shows one source code and its associated information at a time. In this view you can change status to review, leave comments and flag targets.
In order to facilitate efficient mapping and assist workflow, a bulk edit feature has been provided.
Within a task, the bulk edit feature allows users to bulk change all rows or a selection of rows.
A user can
Change relationship types
Change mapping status
Mark all as "No map"
Remove all "No map"
Clear targets
The bulk edit feature only allows one operation at a time, and can only enact changes on rows that have a to allow that change when following a normal mapping process.
Examples:
Within an author task, a user is not able to change any status to APPROVED or IN REVIEW as these belong to review tasks only
Within an author task, if the starting status is UNMAPPED (and so has no target assigned), then the bulk change will not be able to change the status to MAPPED
Within a review task, a user is not able to change any status to MAPPED as these belong to author tasks only
NOTE: It is intended that the bulk edit function is used only within a task, however there is a bulk edit function available to Owners from the map view to allow Owners to manage workflow.
The bulk edit function in the map view will adhere to the normal rules for changing status. This means the Owner must complete a sequence of bulk actions in line with the status change rules.
For example, to clear all the content of a to a row containing a target code cannot be changed to UNMAPPED, a status of DRAFT cannot be changed to ACCEPTED
Roles are used to grant permissions to users to provide access to a project and to perform specific tasks within a project.
Users are unable to see projects until they have been given a role within a project by an owner.
There are three roles being used in the tool.
Owner
An owner has full permissions within a project. They are able to completely manage project membership and project workflow. A project must have at least one owner.
Member
A member has some permissions within a project. They are able to manage their own workflow within a project
Guest
A guest has limited permissions within a project. They have read access to the project and are unable to manage any workflow. They can only complete tasks that are assigned to them by the owner(s)
Adding or removing users from a project
Yes
No
No
Create tasks for any user in project
Yes
No
No
Author actions within an assigned author task
Yes
Yes
Yes
Assigning roles to users in a project
Yes
No
No
Create tasks for self
Yes
Yes
No
Be an assignee for a task
Yes
Yes
Yes
Create tasks to re-allocate rows that have already been allocated to a user for the same task type/action
Yes
No
No
Create tasks to allow same user to author and review the same row
Yes
No
No
Complete a task assigned to self
Yes
Yes
Yes
Cancel a task assigned to self
Yes
Yes
Yes
Cancel a task assigned to any user in project
Yes
No
No
Author actions outside of an assigned author task
Yes - limited through
No
No
Review actions within an assigned review task
Yes
Yes
Yes
Review actions outside of an assigned review task
Yes - limited through
No
No
Create new version of a map within a project, update source and/or target scopes
Yes
No
No
Export map
Yes
Yes
Yes