User Guide — Data Migration

athenaCollector

An athenaOne-to-athenaOne data migration is a one-time movement of providers' patient demographic and appointment data from one athenaOne context to another, to accommodate a business change. Usually, this process is driven by mergers, divestitures, or TIN changes.

 

An athenaOne-to-athenaOne data migration moves supported data types from one athenaOne context to another, so you do not need to perform manual registration for existing patients, and so that the check-in and checkout workflow is not disrupted during the transition. Data migration is accomplished through a one-time push of data that is scoped, tested in a non-live environment, and then run in live athenaOne the night before your business change.

 

A data migration is a supplement to, not a replacement for, a standard onboarding project with athenahealth. Whether setting up a new athenaOne context or adding a provider/department to an existing context, please contact your Customer Success Manager to secure an onboarding project manager to assist in implementation, configuration, and training.

 

 

 

athenaOne-to-athenaOne data migrations includes the following types of data:

 

Patient demographic and insurance information

  • Historic and future appointments for migrating patients/providers
  • Appointment ticklers and waitlist items for migrating patients/providers
  • Related admin tables (referring providers, NPI numbers, referral source, and employers)

 

Clinical data

  • Gynecological (GYN) History

  • Past Medical History

  • Social History

  • Family History

  • Surgical History

  • Obstetric (OB) History

  • Lab and Imaging Results

Note: For the migration of additional clinical data that is not currently supported, please contact your Customer Success Manager to discuss the viability of setting up a chart link back to prior content if it's appropriate for all parties.

 

After thorough testing, the migration will be scheduled the evening prior to the intended day of your business change and move the above data.

 

 

 

 

Patients to be migrated are determined by the following logic:

  • Patients are migrated if the Usual provider selected on the patient Quickview is defined and mapped in our mapping process.
  • Patients are migrated if they have a past or future appointment with a provider that is defined and mapped in our mapping process.

 

 

 

Appointments to be migrated are determined by the following logic:

  • Appointments are migrated if the department, provider, and appointment type are all defined and mapped in our mapping process.
  • Historic appointments (unless excluded by request) are copied from the source tablespace and generated in the destination.
  • Future appointments are cancelled in the source tablespace and generated in the destination tablespace.

 

 

 

You can choose to migrate all custom questions and templates or only those questions that match with the destination context.

 

The local question templates to be migrated are determined by the following logic:

  • When you have the template option set as "All Local Clinical Questions"

    • Custom questions that do not already exist in the destination are created during the migration so that the answers to those questions also get migrated to patient charts.

    • New custom questions are not soft-deleted in the destination so that the answers show on patient charts.

    • In the case of a multi-specialty destination practice, the questions are not selected for any specialty in the admin page, but answered questions still appear on patient charts.

    • In the case of a non-multi-specialty destination practice, the questions are selected in the "Fields to Show" on the admin page. Otherwise, they do not appear on patient charts, even if answered.

  • When you have the template option set as "Matching Local Clinical Questions Only"

    • No custom templates or questions is created during migration. Only global answers and answers to local questions that already exist in the destination migrate.

 

 

 

You can choose to migrate all custom questions and templates or only those questions that match with the destination context.

 

The local question templates to be migrated are determined by the following logic:

  • When you have the template option set as "All Local Clinical Questions"

    • Custom questions that do not already exist in the destination will be created by the migration so that the answers to those questions can be migrated to patient charts.

    • New custom questions will be soft-deleted by the migration so that they will only appear on charts where they have been answered.

  • When you have the template option set as "Matching Local Clinical Questions Only"

    • No custom templates or questions will be created during migration. Only answers to local questions that already exist in the destination will migrate.

 

Notes:

  • UPDATED or CPICOPIED patients will retain the status of "No to all" check box in the destination tablespace.

  • NEW patients will be migrated with the same status of the check box that they have in the source.

  • All questions available in the source chart appear in the destination chart along with Notes and their Answer (Yes/No).

 

 

 

All answered global questions are migrated for every patient for whom this information is visible on the chart, without modifying the global social history configuration.

 

Note: Global questions that were deleted during the switch to Global Social History Templates in 2020 show up in the Other template and are not migrated.

 

You can choose to migrate all custom questions and templates or only those questions that match with the destination context.

 

The local question templates to be migrated are determined by the following logic:

  • When you have the template option set as "All Local Clinical Questions"

    • Custom questions that do not already exist in the destination are created during migration and added to a new template called "Migrated Local Questions"

    • The "Always show" toggle is checked for this new template to display in patients' charts with answered questions. However, you can also uncheck this option anytime post-migration.

  • When you have the template option set as "Matching Local Clinical Questions Only"

    • No custom templates or questions are created during migration. Only global answers and answers to local questions that already exist in the destination migrate.

 

 

 

Entire Family History including the fields - "Relative, Onset Age, Died, Note" appears in the patient's chart after migration.

 

For relationships, you can only have one entry for parents, grandparents, etc. with the same condition and relationship, to prevent error during migration.

 

 

 

Entire OB History including the eight fields - "Total, Full term, Premature, Abortions induced, Abortions spontaneous, Ectopics, Multiple births, Living" appears in the patient's chart after migration.

 

If data for any these eight fields is already available in the destination context, then the data from the source context will not be used for filling or replacement.

 

Note:

OB Episodes are yet to be supported by the migration process, so you have to manually re-create active OB Episodes in the destination.

 

As a result of re-creating the OB Episode, 1 pregnancy will be added to the Total field in the patient's OB History, meaning that pregnancy will be duplicated.

 

To ensure you have the exact count of total pregnancies, reduce the Total value in OB History by 1 after re-creating the OB Episode which you have manually copied from source to destination.

 

 

 

Entire Surgical History information is migrated for every patient for whom it is visible on the chart, regardless of the state of the associated question configuration. The migration includes all 3 types of procedures:

Surgical History ordering is done by the Surgery Date. Alphabetically migrated surgeries follow that ordering and get inserted appropriately with the pre-existing surgeries in the destination tablespace.

 

Note:

The custom surgical history procedures (questions) will be created in the destination tablespace and displayed in the Surgical History section of the associated patients’ charts. However, if you want to add that custom procedure to another patient who does not already have it, then you will not be able to search for that procedure and add; because these custom procedures are created during the migration process in Settings > Clinicals > Surgical History Questions and get soft deleted.

 

 

Lab result information recorded for a patient is visible on the chart.

  • Only Lab Results in CLOSED status can be migrated.
  • The order associated with a lab result does not migrate, but the document category is retained.
  • History does not migrate, but an informative note is included on the lab result in the destination explaining that it is a migrated lab result.
  • Performing labs that are in-house and not global in the source are added to the Lab Result History Note section in the destination.
  • Interface messages do not migrate.
  • Lab results are tied to any encounters that have migrated, but that does not necessarily include all encounters that were tied to the lab result in the source.
  • All Imaging results are included with the Lab results.

 

 

Data migrations are scoped for eight weeks from the project's kickoff call to account for other ancillary teams involved in moving providers/departments (onboarding, interface modification, enrollment, etc.). If you have concerns regarding the timeline of a migration in relation to your business change, please consult your Customer Success Manager to escalate your migration need.

 

 

 

If you need to initiate a data migration, please contact your Customer Success Manager, who will be responsible for providing an onboarding project manager (CSM) and data migration lead to assist you. Once staffed, the project will consist of four phases.

 

Kickoff/Scoping

A proposal defining the scope of a client's project needs to be filled out and signed. After project scoping, a kickoff call will be held to collectively go over the project and ask any open questions. Your CSM can guide you through this process as needed.

 

Mapping

A document will be provided to you to clarify where and how the data is to be moved. You should clarify which provider groups, providers, departments, and appointment type the migrating data will be tied to. This step hinges on the completion of these tables in the new athenaOne context.

 

Mapping Workbook Overview

At the start of your data migration, you will be provided with a mapping workbook. A mapping workbook is a spreadsheet used in data migrations that enables your project team to map providers, departments, and appointment types from one source to another destination. The workbook will be partially filled out for you with all relevant provider groups, providers, departments, and types from the source environment entered into the yellow shaded OLD ID and OLD NAME columns. You will be asked to fill in the corresponding right side "New" columns of each tab of the spreadsheet (see below in blue) within 3-5 business days.

Note: This process can be completed only after provider groups, providers, departments, and appointment types have been built into the destination environment.

 

 

 

The athenaOne-to-athenaOne mapping workbook consists of the following tab-separated Excel sheets designed to clarify the following data types that are required prior to kicking off a test run:

  • Provider Groups (On the Main Menu, click Settings > Billing. In the left menu, under Practice Links — Providers, click Provider Groups)
  • Providers (On the Main Menu, click Settings > Billing. In the left menu, under Practice Links — Providers, click Providers)
  • Departments (On the Main Menu, click Settings > Billing. In the left menu, under Practice Links — Departments, click Departments)
  • Appointment Types (On the Main Menu, click Settings > Schedule. In the left menu, under Practice Links — Scheduling, click Appointment Types)
  • Account Numbers for Enrollment Labs (On the Main Menu, click Settings > Billing. In the left menu, under Practice Links — Enrollment and Numbers, click NPIs and Other Numbers, and then search by lab)

For each tab, you see a consistent set of columns on the left and right sides of the spreadsheet indicating the following:

 

OLD ID — This column denotes the numerical ID of the data point in its corresponding admin table of the source athenaOne environment. This number is a unique identifier that can exist only once per data type.

 

OLD NAME — This column denotes the name of the data point in its corresponding admin table of the source athenaOne environment.

 

NEW ID — This column denotes the numerical ID of the data point in its corresponding admin table of the destination athenaOne environment. This number is a unique identifier that can exist only once per data type.

 

NEW NAME — This column denotes the name of the data point in its corresponding admin table of the destination athenaOne environment.

 

The relationship between OLD ID and NEW ID will be used as the primary key to dictate how our migration connects source to destination. The new data values for each data point need to first be built into the destination and cannot be soft deleted in order for them to be mapped correctly. Please follow up with your onboarding project manager if you need help building or modifying any of the new values.

  • Provider Groups (if destination has Enterprise functionality enabled)
  • Providers
  • Departments
  • Appointment Types

Data Type Mapping — During the mapping phase of a data migration, you will be asked to map every relevant provider, department, and appointment type that is present in the source tablespace to an existing equivalent in the destination tablespace. If the destination tablespace is missing any data types or still requires new content to be built before kicking off a data migration, please consult your onboarding project manager.

 

Provider Groups — If you are coming from an enterprise tablespace you will be asked to clarify which provider groups will be moving in the migration. If you are unsure, this can often be found tied to both the departments and providers that you are intending to move under their respective billing admin tables (see above). You may also be asked to clarify which provider group you are moving into. If you are unsure of this, please consult your Professional Services team for clarification. Please note, if a provider exists in multiple provider groups, and you intend to bring all their data over, you will need to map all iterations of the provider across the various groups in which he/she works.

 

Providers — Mapped providers drive the selection of both patients and appointments that will be migrated. Patients will be included in a migration if they have a mapped usual provider, or a past/future appointment with a mapped provider. Appointments are migrated only if they have a mapped scheduling provider. If a provider is not being re-built into the destination tablespace from the source (for instance, a provider is no longer going with the organization, or is not part of the migrating body), you have the choice to:

  1. Map the former provider to an existing provider. This will ensure that any patient/appointments tied to the migrating provider are moved.
  2. Do not map the provider and instead enter "DO NOT MAP" into all New columns.

Note: Any data tied to non-mapped providers will be ignored by our migration code and left in the source tablespace. Also, mapped providers determine which appointments will be cancelled in the source and regenerated in the destination. If you do not want a provider's appointments to be moved, mark that provider line with DO NOT MAP. This means that any appointments, past or future, will not migrate to the destination patient's appointment history/schedule.

 

On the Provider Mapping tab of the workbook you will also be asked to fill in a designated home department for each provider. This designated department is the STAFF bucket where all abnormal/urgent results, as well as any results that are not able to be matched to a patient will end up.

 

Departments — If you are not going to use one of your service locations from the source tablespace in the destination (for instance, a department is no longer going to be used when the project is completed, or is not part of the migrating body), you have the choice to:

  1. Map the departments to an existing department. This will ensure that any patients/appointments tied to the migrating department are moved.
  2. Do not map the department and instead enter "DO NOT MAP" into all New columns.

Note: Any appointments scheduled in non-mapped departments will be ignored by our migration code and left in the source tablespace.

 

Appointment types — If you are not using some of the source tablespace's appointment types due to a new appointment type policy, appointment type consolidation, or a lack of usage, you have the choice to:

  1. Map the source appointment types to an existing destination appointment type. This will ensure that any appointments tied to the mapped appointment type are moved.
  2. Do not map the appointment types and instead enter "DO NOT MAP" into the New columns for the rows of Appointment Types that should be omitted.

Note: Any appointments tied to non-mapped appointment types will be ignored by our migration code, left in the source tablespace, and not appear in destination patient's appointment histories. If multiple source appointment types are being consolidated to a single new appointment type, complete the mapping for all source appointment types. It is the athenahealth best practice when mapping appointment types to ensure that durations align between the source and destination.

 

Data migrations support the movement of both historical and future appointments.

 

Historical appointments (occurring before the run of the migration) that are completed or in progress) will be copied from the source and recreated in the destination as checked out (Status "4"). Any past appointments that have not been checked in will be ignored by the migration. In all cases the historical appointments of the source will not be altered.

 

Future appointments (occurring after the run of the migration) will be cancelled in the source as "cancelled via API" and will be scheduled as status "f" (filled) in the destination as per the mappings defined in the mapping workbook.

 

Appointments tied to cash plans cannot be migrated as the financial information that they are tied to is not supported by a data migration. Cancelled appointments are not migrated.

Account Number Template — If you have an interface with one of the following labs, then you will need to fill out this tab:

  • Quest Diagnostics
  • LabCorp
  • American Esoteric Laboratories (AEL)
  • Aurora Diagnostics GPA Laboratories
  • BioReference
  • Clinical Pathology Laboratories (CPL)
  • Clinical Pathology Laboratories Southeast (CPLSE)
  • East Side Clinical Lab
  • HealthLab
  • Interpath Laboratory
  • Medical Diagnostic Laboratories (MDL)
  • MetroPath
  • Pathlabs
  • Poplar Healthcare
  • ProPath
  • SaraPath Diagnostics
  • Shiel Medical Laboratory
  • Solstas Lab Partners
  • Sunrise Medical Laboratories

Note: These interfaces are mapped based on account numbers and department.

 

Testing: The migration will be tested in a demo of athenaOne called Preview. Once complete in Preview, the test run will undergo both athenahealth and client-side review and QA. When all parties are satisfied, authorization will be granted using a sign-off sheet.

 

Conducting Client-Side Quality Assurance

 

During the testing phase, a data migration will be run in our Preview testing environment to validate the mappings and data migrated. You will be asked to conduct Quality Assurance (QA) on the test migration performing a random spot check of patients and appointments to ensure the data was migrated as intended. When directed to by your project team, please follow these steps:

  1. Open your browser to preview.athenahealth.com.
  2. Enter your usual username and password.
  3. When prompted, select practice source of the data migration.
    Note: Multiple iterations of preview can exist with carrying ID numbers. Ensure you select the set of testing sites as specified by your project team.
  4. Go to a department/schedule where you would expect to see patients/appointments.
  5. In a separate tab or window open a second window of preview.athenahealth.com in private or incognito mode (this will allow you to have multiple windows of athenaOne open at once).
  6. Enter your username and password.
  7. When prompted select practice destination of the data migration.
    Note: Multiple iterations of preview can exist with carrying ID numbers. Ensure you select the set of testing sites as specified by your project team.
  8. Go to a department/schedule where you would expect to see patients, and compare it to what you saw in step 4.
    Note that future appointments will be cancelled in the source.

Go Live — The migration will be scheduled to run overnight the evening before go-live. The data migration lead will provide verification and day of migration related support, should any issues arise.