...

Summary

Phase I customers typically have an existing volunteer database. This database can be migrated into ClinSpark during the onboarding process. Nearly any input format can be migrated into ClinSpark.

The migration process is iterative and driven by a requirements specification. The process is done in partnership with the customer and Foundry HealthIQVIA.

The migration specification is central to this process. It is a living document, which to start with captures key details from the source system, and all customer requirements. As the process continues, it captures questions, design decisions, and ultimately implementation evidence. When complete this provides clear guidance for the validation team, and also documentation of what was delivered.

...

Note that the iteration flow follows a pattern. For each iteration, a requirement specification is created by the customer and is reviewed jointly by the customer and Foundry HealthIQVIA. Once review is complete, the spec is implemented, and the Migration ClinSpark instance is loaded with the output for review by the customer.

The above process is repeated in iterations until the output passes final review and the work is complete.

Test Volunteers

Customer source databases typically have many thousands of volunteers. For the migration process, we will focus on a small subset of representative volunteers hand-chosen by the customer. This subset, typically only 20 or so, but never more than 50, should reflect a representative set of volunteer data, focusing attention for review on a small set and allowing the iterative process to proceed more rapidly.

Ideally these volunteers should be fake to avoid any concerns around PHI as these are referenced in specification. If this is not possible then we can collectively take care to blur PHI.

Migration ClinSpark Instance

To support the development and review of the migration, a Migration instance of ClinSpark will be created and dedicated exclusively to this purpose. After each specification review is complete, the implementation output from that cycle will be published to this instance for review. This will only contain the Test Volunteers, which focuses the testing and review efforts on the representative test examples.

...

You will be asked to provide a list of usernames who will have access to this instance. You may add as many as you like to the instance, but when it results are published to this instance, only this set will initially be present.

Database Migration Specification

The specification captures all relevant details of the source system and DB, and requirements. It is documented in its own section of this documentation.

Timelines

In our experience, the amount of time that the migration process takes is primarily dependent on how completely and quickly the customer completes the Migration Specification. The technical implementation aspect tends to be fairly rapid. The review process, decisions around migration and transformation logic, and documenting the source UI and DB tend to be the most variable duration portions of the process.

We have had some customers come through the process in only 2 iterations. While for others it has taken significantly more.

Access Control

Access to Migration environments is typically very tightly controlled as it contains PII / PHI from the real participants. The migrating testing / QC team are expected to be authorised to view participant PII / PHI as part of their system testing responsibilities.

Customers must provide a list of staff / testers that need access to the Migration environment, as accounts will be created for them and these users are encoded into the migration scripts. They will need to perform a password reset each time a migration iteration occurs as the environment configuration is over-written each time.