Preparing your data
This is what we need to plan and run your migration. Share it with your IT team and, if needed, your current EMR vendor. The sooner access and exports are in hand, the sooner validation can start.
The data questionnaire
We start with a short questionnaire. Having the answers ready saves the most time.
| Topic | What we ask |
|---|---|
| Your organisation | Number of sites and time zones; estimated active patients and historical cycles; volume of files to migrate |
| Identifiers | Whether patient IDs are consistent across all your systems |
| Your systems | Name and version of your EMR, number of instances, modules in use, and any other systems holding patient data (spreadsheets, finance, cryostorage, scheduling) |
| Documentation | Whether API or data-export documentation exists |
| Known issues | Anything you already know about, such as an earlier migration that changed ID formats, or old records missing key details |
| Scope | For each data area, what you want migrated and in what format it is available (database, CSV, API, PDF scans) |
| People | Your third-party IT provider, if any, and the person accountable for signing off the migrated data |
Your data, in one of these forms
| Form | What we need |
|---|---|
| Database backup or file | A full backup or database file, uploaded through a secure link we send you. Send a fresh copy for each refresh, including the final one at cutover. |
| Read-only database access | A dedicated, read-only database account and a network path to the database, for example over a Site-to-Site VPN |
| CSV exports | One file per table or report, zipped and uploaded through a secure link |
| API access | Read-only API credentials with access to all the data in scope. Some vendors need to enable roles or change tracking first; ask them early. |
Plus, for documents (scanned consents, letters, reports, images): an export of the file store or document folder, or the documents held in the database.
Supporting information
Depending on your data, we may also ask for:
- Staff list: names, email addresses and whether each person is still active.
- Mappings: your appointment types to wawa appointment types, and practitioners in the old system to wawa users.
- Lookup codes: what site-specific codes in your system mean.
- Separate exports: for example appointments, if scheduling lives in another system, or a donor register kept in a spreadsheet.
- Scope decisions: what counts as an active patient, which historical records to include, and how to treat duplicates and cancelled cycles.
People and time
- A data owner who agrees the reconciliation counts and is accountable for sign-off.
- A lead for each bundle (for example a clinician for patients, an embryologist for embryology and cryostorage) with time to validate their bundle in wawa and join short kick-off and feedback meetings.
- Your IT provider or current vendor, available to provide access and exports.
- An agreed cutover window, when you stop entering data in the old system and we take the final top-up extract.
Account configuration
Before data is loaded, your wawa account is configured: clinics, users, appointment types and statuses, treatment types and similar settings. Your team can adjust these throughout the migration.