...
A study design file contains more than just study configurations. It also includes instance configurations closely linked to study properties configuration entities such as Roles, Sites, Lab Interfaces, Devices, Volunteer Connectivity Parameters, and Devicesso on. These configurations are not always limited to the study that is being exported/imported, but would impact all studies in the a ClinSpark instance upon each upload.
One of the main purposes of the For this reason, the purpose of study design import mechanism is to provide an automated way to ensure that relevant configurations of a TEST instance match the MAIN instance. Many of the configurations in TEST instances are purposely not allowed to be changed via the ClinSpark user interface because they are intended to automatically configured to match MAIN instance using this feature.
...
Study design files can be exported using the Administration > Utilities component. Starting in ClinSpark version 1.5, This can also be done while an environment is in Test Mode.
...
Study design files can be imported brought into to an environment through one of two ways:features - using the Administration > Utilities area in the context of an existing study that is selected, or, by uploading the design file as a brand new study.
Administration > Utilities | Import
Using Administration > Utilities, users can
...
Import study design from a PROD instance into a TEST instance. Upon import, the selected target study in TEST will have all study data erased and study design updated to match that of the source design file from PROD.
...
Administration > Studies | Upload
Using Administration > Studies, users can select the ‘Upload’ action menu item. This workflow accepts a .studydesign file from the same ClinSpark instance.
This upload feature safely copies a design
...
into a brand-new study, instead of replacing an existing study.
This feature is intended to be a quick way to copy an existing study design. Users also have the ability to review, modify and optionally remove certain study design elements during the importation process.
...
This upload mechanism is
...
designed to only accept study design files from the same ClinSpark instance. For example, it is expected that a study design from PROD MAIN be uploaded into the same PROD MAIN instance.
| Note |
|---|
This feature does not support the upload of design files across different ClinSpark instances (such as taking a design from |
...
MAIN and uploading to |
...
TEST) or different environments (such as taking a design from a VAL environment into a PROD environment). |
Dynamic Configuration Logic
There is a configurable global system setting called ‘ImportExportService’ . This system setting contains a majority which defines a portion of the logic supporting the import/export process, and allows for a wide range of dynamic features. As a dynamic system setting, it allows for certain updates of the import/export features to be done without requiring the need for a core code change (similar to other dynamic system components likes reports and dashboards).
...
Changes to the system setting logic may be necessary to support unique customer requirements or certain support scenarios where issues with study design imports may be occurring.
Modifications to this setting are protected by Foundry Health ‘superadmin’ superadmin users and accommodated via service desk tickets where applicable.
...
Import will automatically merge a wide range of study and instance configurations from the source instance to the target instance. However, certain preconditions of import are expected in order for the operation to proceed. Summarized, these entities are expected to match between source & target environments:
ClinSpark versions
Medical Dictionaries
Sites
Matching ClinSpark Versions
When using Administration > Studies > | Upload feature, the version & build numbers between source and target environments must be an exact match. Additionally, the study design file must be sourced from the same environment (meaning a design file cannot be uploaded if it came from another environment).
When uploading via using the Administration > Utilities in an environment running in ‘Test Mode’| Import feature, the version & build does do not need to be an exact match between source and target environments. Additionally, the design file can be sourced from a different environment (meaning a design file sourced from PROD can be imported into TEST).
| Info |
|---|
We do not encourage customers import study designs from different types of environments, for example, taking a design file from a Sandbox or VAL environment and importing into PROD. Clinspark was not designed with design files to be important wit this intent. These imports often do not succeed due to differences in system settings, configurations and feature differences between versions. |
Medical Dictionaries
Customers that leverage WHODrug and MedDRA dictionaries as part of study configurations are expected to have matching dictionary files loaded between their PROD MAIN and PROD TEST instances. However sometimes there may not be an exact match in the dictionaries between source/target environments which may cause certain issues upon import.
...
When importing a study design file, system logic will attempt to merge all matching site configurations from the source design file environment into the target.
If sites are missing in the target environment, the import mechanism will attempt to create them and associate with the imported study, but this may not always succeed with desired results (as the sites may not be properly linked to the study). To prevent these sorts of issues, it’s always best to ensure that site configurations match between target and source environments before performing an upload.
...
Addressing Import Failures
...
If customers continue to experience challenges with imports even into new studies, they should reach out to the Foundry Health IQVIA support team via service desk. It is ideal to provide a screenshot of the error message present in the user interface as well as the study design file that is being used.
Import Entities
The following table represents details represent all of the import entities that ClinSpark attempts to merge from source (MAIN) into target (TEST) studies.
...
Imported Entity
...
Description and Notes
...
Sample Tasks
...
Specimen Containers
...
. An entity can represent a set of configurations or settings that influence the behavior of an environment or a study design.
Sample Tasks
...
Specimen Containers
...
User Roles
Application User Role configurations are designed to be synchronized from source to target upon import. This action overwrites user Roles & Role Actions at the system level within the target environment.
...
| Note |
|---|
Role Actions assigned on existing Roles cannot be modified |
...
on TEST environment (running in ‘Test Mode’ |
...
). Changes to existing Roles in TEST environments can only be made through the import mechanism. |
Sites
...
Existing sites attributes are synchronized, and new sites (in target environments) are added through import mechanism.
...
The import process also synchronizes Lab Interfaces. This includes Lab Tests, Lab Panels, and Lab Specimen Categories.
...
Device Categories
...
Devices
...
EDC Devices
...
This includes all EDC Devices, EDC Device Parameters and EDC Device Settings
...
Volunteers Interfaces
...
These are bindings between a Volunteer record and a CRF form. They are used in automatic importation into a form from the volunteer record.
...
Sample Containers
...
Study Lab Panels
...
Device Integrations
The domain of ‘EDC Devices’ covers all Device Integration configurations. These are synchronized during import.
...
Device details, device parameters, and device settings are synchronized.
...
Modification of EDC Devices is disallowed when running in test mode.
Volunteer Data Collection Connectivity Settings
Within the Administration > General Settings > Volunteer Settings area exists a number of volunteer data collection connectivity parameters. These influence the data entry experience on volunteer records and certain connected study forms, covering the domains of Concomitant Medications, Demographics, Medical History, and Substance Use.
These volunteer settings are unable to be modified in Test Mode. These are only updated in target TEST environments during import workflows.
...
Study Lab Panels
Study specific lab panels in Lab > Configure are included into design file imports. Any Lab Panels belonging to the imported study, along with all lab tests referenced by those panels, are merged in.
...
Study Sample Path
...
Configurations
Study specific sample paths and sample configurations are brought through study imports into target studies. This includes the study’s Sample Paths, Sample Path Transfers, Sample Path Step Devices, and Sample Path Specimen Containers.
...
Study ECG
...
OpenClinica Account
...
The configuration of OpenClinica for the exported study if applicable.
...
Rave Account
...
The configuration of Rave for the exported study if applicable.
...
All CRF Design for the exported study
...
Configurations
...
CRF Design | Study Library
All Study Library contents and design entities are included. This includes Study Metadata, Study Events, Forms, Item Groups, Items
...
, Code Lists,
...
All Activity Plan design for the exported study
...
Notes
Everything configurable from this tab is included in the export.
...
All Study configuration for the exported study
...
Methods, Measurement Units and Conditions.
...
CRF Design | Activity Plans
Activity Plans are included into design file import workflows. This includes the Activity Plan design and associated study events and forms, applicable to each plan.
...
Study Configuration
Several study specific configurations are brought into target studies. This includes:
Study Basics
Epochs and Cohorts
Study Sites / Recruitment
WHO Drug Dictionary
Medidata Rave Account
OpenClinica Account
...
The following items are not included with study specific configurations:
MedDRA Dictionary
Data Reviewers
Informed Consent
Recruitment Questionnaires
User Access
Cohort Assignments or Subjects that existed in ‘source’ studies