7 Configuring Your Discrepancy Workflow

This section contains the following topics:

"Discrepancy States and Allowed Transitions"
"Actions"
"Out-of-the-Box Workflow"
"Creating a Custom Workflow by Creating Custom Actions"

Discrepancy States and Allowed Transitions

Oracle Health Sciences Data Management Workbench (Oracle DMW) comes with a set of discrepancy states, allowed transitions between them, and actions that change the state of the discrepancy and/or apply a tag. The allowed transitions differ depending on the source of the discrepant data. You can define custom actions, following the same rules.

Discrepancies on Lab Data

When a discrepancy is created on lab data in Oracle DMW, either by a user or by a validation check, the system allows the maximum number of states and transitions, as shown in Figure 7-1, "Discrepancy States and Allowed Transitions for Lab Data Discrepancies":

Figure 7-1 Discrepancy States and Allowed Transitions for Lab Data Discrepancies

Description of "Figure 7-1 Discrepancy States and Allowed Transitions for Lab Data Discrepancies"

As shown in the diagram, for lab data discrepancies:

Candidate and Open are the two valid beginning states for a discrepancy.
Cancelled and Closed are the two valid end states for a discrepancy.
Candidate discrepancies can move to Open, Cancelled, or Closed.
Open discrepancies can move to Cancelled, Answered, or Closed.
Answered discrepancies can move back to Open or to Closed. They cannot be reopened as Candidate.
Discrepancies can be closed from the Candidate, Open, or Answered state.

Discrepancies on InForm Data

Discrepancies can be raised against data from InForm in either system:

Queries raised in InForm are loaded into Oracle DMW as discrepancies with the same state as in InForm.
Either a validation check or a user can raise a discrepancy in Oracle DMW against data that originated in InForm.

When a discrepancy is sent to InForm, the system limits the actions an Oracle DMW user can take on the discrepancy until it is sent back to Oracle DMW. The same limited actions are allowed whether the discrepancy originated in InForm or in Oracle DMW. While the discrepancy is in InForm, Oracle DMW users can apply comments and categories, which are never sent to InForm.

In addition, discrepancies on InForm data, whether raised in InForm or in DMW:

Can be answered only in InForm. An Oracle DMW user cannot change its state to Answered. An InForm user can answer the query either by changing the underlying data point or by providing explanatory text. InForm then changes the state to Answered and exports the update to Oracle DMW.
Can transition to a state of Cancelled only if there has been no data change in InForm.
Can be closed in either system. The change is then propagated to the other system.

Communication with InForm

State changes made in Oracle DMW are sent to InForm almost immediately using a web service.

Changes made in InForm are updated in Oracle DMW in the next data load from InForm for the study.

Actions

Users apply actions to discrepancies to move them from one state to another. The system comes with a set of predefined actions, and you can create your own custom actions. An action includes:

Start and Result States: An action is available to a user only for discrepancies that are in the action's defined start state. When the user applies an action to a discrepancy, the discrepancy's state changes to the defined result state. If you create custom actions, the start and result states must constitute an allowed transition (see "Discrepancy States and Allowed Transitions") or be the same. If the start and result states are the same, they normally have different start tags, result tags, or both.

Note:
No defined action is required to create a discrepancy. Users and validation checks can create discrepancies in either of the two valid start states, Candidate or Open.
Start and Result Tags (Optional): Tags can be used to allow a dialog between users without changing the state or to effectively create a substate. Users can filter records in the Discrepancies page based on tag values.

A tag is a label applied to a discrepancy when a user performs an action that specifies it. An action with a start tag specified is available to a user only for discrepancies that have that tag.

When the user applies an action to a discrepancy, the system applies the action's defined result tag (if there is one) to the discrepancy.
Enabled: This attribute determines whether an action is available for use. You can use this attribute, for example, to ensure that users have access only to the custom actions you define, and not to the predefined actions.

Each time a user applies an action, the system maintains an unmodifiable audit trail of the event.

Note:
Users with access to the Discrepancies page can add comments to a discrepancy at any time. It is not necessary to apply an action in order to add a comment.

Out-of-the-Box Workflow

The system comes with a set of actions that users can apply to move a discrepancy from one state to another and, in most cases, apply a tag to the discrepancy.

Predefined Actions

Table 7-1, "Predefined Actions Available at each Discrepancy State" lists all predefined actions. The system displays only those that are valid given the current state of the selected discrepancy. For example, although there are three predefined actions named Close, only one of them is displayed to the user at a time, depending on the current state of the discrepancy the user has selected; either Candidate, Open, or Answered.

For each action named Close the system applies a different tag, depending on the start state:

Discrepancies that started in the Candidate state get the tag ClosedAsIs.
Discrepancies that started in the Answered state get the tag ClosedByAnswer.
Discrepancies that started in the Open state get the tag ClosedByDataChange.

Only the appropriate action is available to the user.

Note:

None of the predefined actions specifies a starting tag. They can be applied to a discrepancy in the appropriate starting state with any tag or with no tag.

Table 7-1 Predefined Actions Available at each Discrepancy State

Start State	Action Name	Routing Operation	Result State	Result Tag
Candidate	Open	None	Open	None
Candidate	Cancel	None	Cancelled	None
Candidate	Open in InForm	SendToInForm	Open	SentToInForm (This action creates a new Open InForm query.)
Candidate	Send to InForm	SendToInForm	Candidate	SentToInForm (This action creates a new Candidate InForm query.)
Candidate	Close Discrepancy	None	Closed	ClosedAsIs
Candidate	Needs DM Review	None	Candidate	NeedsDMReview
Candidate	Send to Spreadsheet	Send to Spreadsheet	Open	None
Open	Cancel	None	Cancelled	None
Open	Send to InForm	Send To InForm	Open	Sent To InForm (This action creates a new Open InForm query.)
Open	Send to Spreadsheet	Send To Spreadsheet	Open	Sent to Spreadsheet (This action generates a .csv file in the location you specify that includes all selected discrepancies. The file can then be sent to the lab.)
Open	Needs DM Review	None	Open	NeedsDMReview
Open	Answer	None	Answered	Answered By User Response (if a user uses the action Answer) Answered By Data Change (if a data change occurred in the source system)
Open	Close	None	Closed	Closed By Data Change (if a data change occurred in the source system)
Answered	Reopen	None	Open	None
Answered	Close	None	Closed	Closed With Answer

Although Table 7-1 lists all valid actions based on the applicable state for a discrepancy, not all the actions are valid for every discrepancy in that state. The system automatically filters available actions based on the following factors:

Existence of the specified Start Tag value, if any.
The data source; for example, the Send to InForm action is not available for discrepancies on lab data.
When a discrepancy has been sent to an external system, no actions are available in Oracle DMW.

Out-of-the-Box Workflows

Using only predefined actions, you still have many options:

You can choose to create discrepancies in either the Candidate or Open state.

Note:
InForm queries are imported in their InForm state; you cannot change that.
You can send either Candidate or Open discrepancies to their source—lab or InForm—for review, or require manual review in Oracle DMW first.
You can require a formal medical review of each discrepancy or not.
You can require a formal data management review of each discrepancy or not.
You can set up validation checks so that when they run, they automatically close discrepancies they created when the underlying data is corrected in such a way that the validation check logic no longer sees the data as discrepant.
Alternatively, you can require manual review of validation check-created discrepancies whose underlying data has been changed.

You can disable any actions you do not want to use.

Lab Workflow Example

A validation check with Autoclose set to Yes detects several lab test results that are out of range, and creates a discrepancy for each one. These discrepancies are displayed in the VC Listings page under the name of the validation check and in the Discrepancies page.
In the Discrepancies page, the data manager clicks Send to Spreadsheet to export the records to a file on her personal computer and sends the file to the lab.
Lab personnel open the file in Microsoft Excel and check the test result values against the original source data. In Excel, they fix the data for all but one of the discrepancies, ready for the next data load back into Oracle DMW.

The lab personnel also send information separately about how the remaining discrepancy should be handled, and the data manager updates the discrepancy manually in Oracle DMW.
The next time the validation check runs, it automatically closes the discrepancies on the corrected data and makes no change to the other discrepancy.

InForm Workflow Example

Using Custom Listings, a data manager detects several BMI values that are out of range, creates a discrepancy for each one, and sends the discrepancies to InForm as Open queries.
The CRA checks all the data in InForm and is able to resolve all queries by correcting one data point for each one. The CRA then sets all queries in InForm to Answered.
The InForm Connector detects the data changes and loads the updated data and queries (discrepancies) into the correct study InForm data model. In DMW the discrepancies will be updated to have the same state as in InForm and the discrepancy history will include an "Updated from InForm" entry.
In the Discrepancy page, the data manager looks for discrepancies in the Answered state and closes them. The system sends the update to Closed state to InForm to close the queries there.

Creating a Custom Workflow by Creating Custom Actions

Your company's standard operating procedures may require additional or different workflow steps. You can create a set of actions to suit your company's procedures—within the predefined transition rules—and disable any shipped actions you do not need. If you need more states, create tags to serve as substates and create actions that specify a starting and resulting tag.

Custom InForm Workflow Example

In the case of the out-of-range BMI values:

The CRA responds that the weight, height, and units for one of the subjects are all correct and the patient is extraordinarily heavy. The discrepancy when imported back into the system has a state of Answered with a tag Answered by User Response.

The data manager wants to send the discrepancy for medical review to determine if the subject qualifies for participation in the study. This requires a custom action:

Table 7-2 Example of Custom Actions

Start State	Custom Action	Routing	Start Tag	Result State	Result Tag
Answered	Answered but Requires Medical Review	None	AnsweredByUser Response	Answered	Needs Medical Review
Answered	Send to DM	None	Needs Medical Review	Answered	Remove Subject from Study
Answered	Remove Subject	Send to InForm	Remove Subject from Study	Answered	Remove Subject from Study

The medical reviewer uses another custom action, Send to DM (with a Start State of Answered) to respond to the data manager that the subject is not eligible for the study and should be removed, leaving the discrepancy state set to Answered.
The data manager uses a custom action, Remove Subject, to send the discrepancy back to InForm instructing the CRA to remove the subject from the study.
The CRA removes the subject from the study and sends a comment back informing the data manager.
The data manager uses a predefined action to close the discrepancy.

Custom Lab Workflow Example

Table 7-3 lists custom actions that allow a custom workflow between data management and medical review teams. In this case, company policy is for all lab test discrepancies to go through medical review first.

When a validation check creates a discrepancy on lab data, it gives the discrepancy a state of Candidate. The data manager reviews the discrepancy and applies a custom action that applies the tag Needs Medical Review while leaving the discrepancy state as Candidate. The medical reviewer then either applies the Needs DM Review tag, with a result state of Open, or the Send to Spreadsheet action and then sends the discrepancy to the lab.

Table 7-3 Examples of Custom Actions for Workflow between Data Management and Review Teams

Start State	Custom Action	Routing Operation	Start Tag	Result State	Result Tag
Candidate	Answer Data Management	None	NeedsMedReview	Answered	MedAnswered
Candidate	Assign to Data Management	None	NeedsMedReview	Open	MedResponded

Creating and Editing Actions

To create new actions or edit the predefined ones, you must use public APIs. Information is included in the Oracle Life Sciences Data Hub Application Programming Interface GuideYou can define or modify the following attributes:

Name: The action's name does not appear in the user interface. It is required and the combination of Name and Start State must be unique in the database.

For example, you can have two actions with the name XYZ, one with a Start State of Open and the other with a Start State of Candidate, but you cannot have two actions named XYZ with a Start State of Open.
Menu Label: Enter text to appear in the user interface. This is what the user will see and apply to a discrepancy. The label is required but does not need to be unique.
Start State: Select the state that discrepancies must have for this action to be available to a user. This action will be available to users only for discrepancies that are in this state.
Result State: Select the state that the system should apply to discrepancies when the user applies this action. The result state must be an allowed transition state from the start state; see "Discrepancy States and Allowed Transitions".
Start Tag (Optional): Select the tag that discrepancies must have for this action to be available to a user. You can create new tags in the Administration page; see "Viewing and Creating Discrepancy Tags". Tags can be used as substates, for communication within a state, and as filters in the Discrepancies page.
Result Tag (Optional): Select the tag that the system should apply to discrepancies when the user applies this action, if any.
Routing Operation (Optional): If the discrepancy needs to be checked or resolved in the source data system, select the appropriate operation:
- SendToInform: The system sends the discrepancy to InForm immediately and applies a transition restriction of Limited to it.
- ExportToCSV: The system creates a .csv file suitable for export to a lab as is or as an Excel spreadsheet.
Enabled: Select this attribute to make this action available for use. Deselect it to prevent the action's use.