An Approach to Parallel Amendments

Goals

This post outlines steps to support an implementation for parallel amendments. The described approach is guided by the following principles:

Performance
Only create data that is necessary to support the functional requirements and avoid long running transactions. New amendments should not need to cause the creation of a complete copy of the previously approved protocol.

Ease of Review
Provide features that improve the overall experience of the reviewer.

Efficiency
Avoid the review bottleneck by allowing for amendments of different types to be in process at any given time.

Ease of Maintenance
While supporting the first two principles, the design should minimize redundancy of configuration

This is based upon ideas that have been floating in my head for a while now and largely driven by my desire to effectively support parallel amendments and dramatically reduce the dependence upon clone. We’re in the middle of the first real implementation of this approach and so far so good.

High Level Approach

Upon approval of the original protocol, the system will create a copy of the entire protocol to be used as the draft version during the amendment process. This draft will be the only one necessary so additional copies of the protocol are not required. Amendments are classified into types such that each amendment type restricts the PI and Study team to a unique section of the protocol SmartForm such that no amendment types overlap with respect to the information that can be altered through the amendment. All proposed changed edits are made in the draft protocol and submitted for review. Upon approval of an amendment, the changes are them published to the original protocol. If an amendment is withdrawn or rejected, the draft version is restored by resetting the applicable fields from the original protocol.

This approach requires that the following rules are strictly enforced:

1. Each amendment type represents a distinct set of protocol data. There can be no protocol information editable in more than one amendment type. Enforcement of this rule implies that a single protocol view cannot include attributes from more than one amendment type.
2. Only one amendment of a given type can be open at a time for a given protocol. However, it is possible for a single Amendment to involve multiple types at once. This can be facilitated by allowing the PI, at the time the Amendment is created, to select the sections they wish to modify by presenting a list of the supported Amendment types for selection. Only those types for which there is not already an open amendment will be available for selection.
3. The approved protocol cannot be updated outside the amendment process. No exceptions.
   

Implementation Approach

The implementation of amendments involves a set of specific configuration elements.

Protocol Project Type Data Model

Additional properties need to be added to the Protocol project type to represent the existence of open and in-process amendments. There will be one property for each type of amendment and each will be a reference to an Amendment project. In addition, there will be a property that refers to the draft protocol.

Protocol Workflow

In addition to the States supporting the initial protocol review process, a state named “Draft” needs to be added.

Upon approval, the protocol is cloned to create the draft protocol. A reference to the draft protocol is then set on the approved protocol. The state of the draft protocol is set to “Draft”. The draft protocol will not have a workspace. There must be a change tacking activity assigned to the Draft state so that all changes are logged into the audit trail of the draft protocol.

Protocol Workspaces

In the Approved protocol workspace, Project Creator components need to be added, one for each type of amendment. Alternatively, a single “New Amendment” button can be added and the user would then be prompted for amendment type on the first step of the Amendment SmartForm.

If adopting the multiple project creator approach, once an amendment is opened, the project creator component for that amendment type, should not be presented to the user until that amendment is approved, or otherwise terminated.

In the case where the open amendments cover the entire protocol, the user should not be allowed to create a new amendment of any type.

Amendment Project Type

This represents the “cover sheet” for the amendment. If presenting the choice of amendment type in the first step of the SmartForm, only the types that the user is allowed to select should be presented. In other words, if an amendment of a particular type already exists and is active, the user should not be allowed to create another amendment of that type.

When a new amendment is created, the draft protocol is updated to record a reference to the amendment in the appropriate property based upon amendment type. If the amendment covers the entire protocol, then all amendment type properties should be updated to refer to the newly created amendment.

Upon the creation of the amendment, an activity is recorded on the draft Protocol to increment the version of the draft. This sets a point in time (like a label in source control) to serve as a point of comparison during review.

Amendment Workspace

Access to the draft protocol is provided via the Amendment workspace. This is accomplished through the use of a Wrapper component to expose the following links created via a Site Designer layout:

· Link to the Draft Study Smartform. The URL will include querystring parameters to take the user to the appropriate Step in the protocol SmartForm based upon the Amendment type.

· Link to Printer Friendly View of the Draft Protocol. In this case the user will be able to create a read-only, printable display for the section of the protocol exposed through the amendment.

· Link to View differences for the draft protocol

Amendment Workflow

Submit/Submit Changes

Each time the user submits or resubmits the amendment for review, the version of the draft protocol is incremented by executing an activity on the draft protocol.

Completing the Amendment

If the amendment is approved, all of the modified properties need to be published to the previously approved protocol. The version of the draft protocol is incremented by executing an activity on the draft protocol.

The converse is also true. If the amendment is withdrawn or otherwise terminated without being approved, the property values in the draft protocol need to be reset by copying the values from the previously approved protocol back to the draft protocol.

Protocol SmartForm

Rather than use the configured SmartForm branching for a new Protocol. Special case branching is required in order to take into account the type of Amendment used to enter the Draft SmartForm. This is accomplished by leveraging a new (and currently undocumented) feature in Extranet 5.7 that allows for special case overrides. To leverage this feature, a new per entity method is added to the Protocol project type:

onDetermineNextPage(currentSmartFormStep)

The return value is the next SmartForm step page to which the user will be redirected. If null is returned, the standard SmartForm branching configuration is used. For draft protocols, this method should only return null if the amendment type opens up the entire protocol for editing. IN all other cases, a specific SmartForm step should be returned. If the current SmartForm step is the last editable step for the type of amendment, then the method should return “$END”.

Determining the next SmartForm Step involves the following logic:

1. If the open amendment reflects that the entire protocol is open for editing (as determined by the amendment reference for that type being non-null) then allow the standard branching configuration to rule the day by returning null.
2. Identify the type of amendment associated with the current view. If there is a next step in the SmartForm for the current amendment type, then return a reference to that SmartForm step (WizardPage) else return “$END”

The last thing that needs to be done is to insure that when the user exits the SmartForm, they are returned to the Amendment workspace. This requires an override of the Project.getURL() method to add special handling for Protocols in the draft state. In this case, the related amendment is determined and the result of the getURL() method on the amendment is returned as the URL for the draft protocol.

NOTE: There are still some ambiguities that need to be worked out to make this work in all cases as there are cases where the specific amendment used to initially enter the draft protocol SmartForm cannot be uniquely determined.

Protocol Security

For new protocols, all the security rules can be configured through standard site policies. For the draft protocol, however, the notion of the protocol as a whole being editable or not doesn’t meet the needs because different sections of the protocol are editable according to the existence and state of the amendment associated with each section. For this reason, we need to handle this in a special way.

We’ll start by setting the default access rules for a protocol in the draft state to never be editable according to the configured security policies. We’ll then need to implement logic to override this policy on a SmartForm Step by SmartForm Step basis.

To accomplish this, we’ll take advantage of the initializeForm() method to execute logic at the top of each rendered SmartForm step. This method will test the status of the current protocol and, if “Draft” will look up the amendment that controls the current SmartForm step and open the step up for editing if the user has the right to edit the Amendment based upon it’s configured security policies.

In order for this to work, a simple Selection CDT will be created to hold a map between Protocol view ID and Amendment Type. If the state of the current Protocol is “Draft”, the initializeForm() method will look up the Amendment type based up the ID of the view being rendered. Once the type is known, the appropriate property on the parent protocol will be used to locate the current Amendment project.

If the user is allowed to edit the amendment, then the current view will be enabled for editing by passing false to the EntityViewRenderingContext.setForceReadOnly() method.

In the same way, the test to see if a user is allowed to read the draft protocol is driven by the user’s ability to read the amendment associated with the current view.

The best place to capture all of this logic is as an override of the userCanRead and userCanEdit methods in Protocol. If the state of the protocol is “Draft” then the security check is deferred to the associated Amendment. If not in the “Draft” state then enforcement of security is handled by the default implementation on the supertype.

Amendment Review

Lastly, we want to continue to leverage the Reviewer Notes and View Differences features to support the review process. 

Reviewer Notes

We want to allow Reviewer Notes to be added to the draft protocol by reviewers. The first step is simple. In the Reviewer Notes configuration for the Protocol project type, make sure that Reviewer Notes are enabled for Protocols in the Draft state.

So that these notes don’t live on after the amendment is approved, they will be archived into the notes for the Amendment approval activity on the amendment, then cleared from the draft protocol. This enforces that they are not present for the next occurrence of the same Amendment type.

View Differences

As the standard View Differences display leverages the same base capabilities as the Project Smartform to determine the Smartform path the ability to view differences for the applicable sections of the draft protocol should just work. The only extra bit of work that is required is to make sure that the entry point into the View Differences display is the same one as when the user enters the Draft Protocol SmartForm. This is accomplished by constructing the correct initial URL via the same Site Designer layout used to build the SmartForm link to the draft protocol. Both links, plus the Printer Friendly link are all displayed in the Amendment workspace via a Wrapper component.

Conclusion

Many elements of this are taking shape in a first time implementation and it’s fair to say that we haven’t reached the end of the initial experiment. I feel, however, that the idea holds together well and what remains is to tackle the specific corner cases that will most certainly surface.

Input of any kind is welcome as it can only help solidify the approach and expose areas that I may have overlooked. I challenge you to poke holes in the ideas presented here and, if this approach intrigues you, I’ll be happy to work with you and your Huron Project Manager to give it a go in your site.

If there is enough interest, I’ll post a follow-up once the inaugural implementation hits the streets.

Cheers!