Volunteer Database Migration
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 Health.
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.
The migration process is as follows:
The specification itself guides the initial tasks around documenting the source UI, database and migration requirements.
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 Health. 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.
Remember that all changes to this instance will be erased at the end of each implementation iteration.
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.