Create and edit a pipeline

A pipeline is a structured list of events which collect, quality control and analyse the project data to produce results.

Each stage in turn is built up of one or many events. A pipeline can be in two modes, design or live, and has a version number that is incremented every time a new version of a pipeline is approved. 

Example of a pipeline depicting the progress for each subject

A new pipeline version is developed in design mode. In this mode, it can be run against test subjects and test data, in order to test and validate its functionality. 

Example an empty pipeline to be edited

Edit pipeline

To edit or start building a pipeline you select the “Edit Pipeline” option. This switches state from live to design. By default there will be no stages and you will have to add one, by selecting "Add Stage". 

Example of a stage creation form

With a new stage you are ready to create events to populate the stage.

Event

An event represents an activity to be performed and collect/create/review data. Each event, 

  • is versioned through the pipeline

  • has a signature at the bottom

  • contain modules

  • is assigned to role (e.g. uploader)

  • is run against each subject

  • is of type Standard or Quality Control

    • Standard events simply move the pipeline forward and the signature allows the user to approve and sign the event to lock down the data records created

    • Quality control events are used to QC the data from the linked previous event(s). The signature can either approve or reject the event, allowing the pipeline to move forward or in the case of rejection back up to the previous event(s) which in turn need to be re-run.

Event updates are version controlled through the pipeline and no approval is required to create a new version. The new version enters the pipeline in design mode until the next approval of the pipeline has been performed. To create a new event you select on the right side in the "Edit pipeline" view.

Example of an event creation form

The event has to be given a name, type and assigned role. It can be linked to follow previous events or stand alone. Description and ID are not mandatory. If no ID is given one will be automatically generated. 

Example of an event to upload data of type standard. The event can be configured by clicking on the configure icon.

Modules

A module can be used within an event to either create, structure, move or review data. The available modules are:

  • A tool, which is part of a repository-wide library, is a function built into a container for automated execution on the pipeline. Tools can be uploaded to the system, checked in and integrated into an event on the pipeline.
  • Form, allows users to select a form and version to be used in the event. Forms are not specific to a certain project but rather part of the repository

  • Upload, allows users to upload data to be stored in the event, pipeline and project. Upload can be configured to what data to expect/allow

  • External, allows users to download the event data, execute an external process and upload the result in a way compliant with regulation. Collective Minds recommends that the there is a user standard operating procedure (SOP), or equivalent, in place to guarantee regulatory compliance

  • Databrowser, allows users to view data present for a subject in the pipeline stage. The data browser will display data from all previous events, or only the data inputted in the previous event, depending on configuration. 

  • Screening, extracts a subject’s result lines and displays them. The purpose is to be able to take screening include/exclude decisions

  • Segmentation, allows users to annotate images in both 2D and 3D. Annotations will be saved as RT structs.  

Modules (right side) can be added by drag and drop to populate an event. Once added they can be edited by clicking on properties tab (right side)

Each module has editable properties to configure their behavior. Once the desired modules have been added and configured, they are saved back to the event.

Example pipeline with one stage containing one event

Run Pipeline

Once the desired stages, events and modules have been added the pipeline can be tested by selecting the "Test Pipeline" button. This allows you to add subjects for testing and making sure the pipeline performs as expected. Once tested the pipeline can be signed in by clicking on the approve button (bottom right).

Example of a complete project pipeline with six stages and multiple events and modules. "Test Pipeline" allows you to test the pipeline before signing it in (approve) to go live.

Approving a pipeline allows for two options, continue and reset. Continue updates the pipeline preserving all previously signed events. Reset will update the pipeline but also reset all events back to, and including, what is selected from the drop down menu/s. When resetting parallel events, only the one you choose from the drop down will be reset (in addition to any following events). When resetting standalone events, only this event will be reset. Please note that this process will preserve history but reset events need to be run as if it was the first time.

Design

When a pipeline is being edited, before going live, it will be in design state. This allows for modifications of stages and events. Test subjects can be used to verify functionality by using the “Test Pipeline” option on the top right. Once the pipeline is ready it needs to be approved before going live. Approving a pipeline will replace the current one and increase the version number.

A subsequent pipeline version is automatically created, in design mode, which can be prepared and tested in parallel in design mode. This cycle is endless with the result that there is always an n+1 version of the pipeline in design mode and an n version of the pipeline in live mode (assuming the very first version has been approved).

Example of a pipeline in design state.

Live

The live pipeline allows members of the project to move subjects through the different events and stages. The move forward icon indicates that an event is ready to be run, while a check box icon informs that the event has been run. By clicking on any move forward or check box icon the event can be re-/run and displays who has signed the event and what version it has. 

Example of a live pipeline

Color scheme for event status

  • Black, an event has not been run yet.
  • Green, an event has successfully been run.
  • Red, a quality control (QC) event has been signed as rejected.
  • Yellow,  the event is pending rerun following a rejected quality control event.
  • Green lock, an event that is locked and currently being run by another member.