System Access & Technical Requirements

This is the first of a series of articles designed to provide you with tips for adding efficiency and value to your clinical data migration.

The Galen Data Migration team has developed a migration methodology comprised of 6 distinct phases, the first of which is defined as System Access & Project Kick Off. In very basic terms, the start of this phase is marked when the client signs a contract for the data migration, the Galen project team is identified, and hand-off of the Statement of Work from the contracting team occurs. Plans to engage the client-side resources quickly ensue, and preparation for a whole project team kick off meeting gets underway.

Perhaps THE MOST important early objective to be defined and fulfilled has to do with setting up and confirming project team access to all the various client-side applications, systems, and databases required for data migration activities. A boiled-down version of requirements involves enabling access to:

• The client network via some form of remote capability
• A dedicated server – set up and configured according to Galen specifications
• The legacy patient and clinical databases for data extractions
• The front-end of the legacy and target systems for validation and testing

There are almost always complicating factors, questions, and unforeseen issues that arise adding complexity to the request for system access, for example:

• Is this a first-time data migration for the client, or might the team be able to capitalize on some previously established points of access?
• What method will the client use to provide remote capability – Citrix, VPN, Securelink?
  • Will confidentiality/security agreements need to be completed?
  • Will the client be providing access to all systems in one location – like a Citrix portal, or will there be multiple ways to access systems and data?
• Does the client have direct access to their legacy and target system databases?
  • Will Galen have direct access to the databases, or will the client or vendor be providing a database copy or extract?
  • If the database is vendor hosted, is there a cost associated to getting access to a backup? How many backups will be required? Is a contract needed? How will the data be provided – will a hard drive need to be procured? How much time is estimated for this process to complete?
  • Have the databases been assessed for size and storage requirements?
  • Is there a target test environment set up and available for project team use?
    • Is this environment the same software version as the production environment? Are any upgrades or updates being planned?
    • When was the test environment last copied/created?
    • Is this environment in use by other project teams?
    • Status of EMPI for patient load. Are the legacy patients already loaded into the test and production environments, or will patients need to be extracted and loaded as part of the migration activities?
  • Does the client have a server already set up and available for project team use? Are the specifications for the server adequate, will more space need to be added?

In our data migration experience, this aspect of project ramp-up – fulfilling access requirements – is often complicated, and can take much longer to complete than originally anticipated. This is partly because the activities usually involve gaining the cooperation of resources from other areas of the client organization such as legal and security teams, IT, help desk, and, in the case of some migrations, outside vendors. Additional consideration must be given to larger data migration projects which involve multiple legacy systems, growing the request for system access exponentially. The problem we seek to avoid is having the project timeline suffer delay while awaiting access requirements to be fulfilled.

So, the takeaway message is three-fold:

1. Evaluate the client environments and define a comprehensive set of system and access requirements – early. Hold a review call to help identify and guide the full details of the access request. If a third-party vendor is involved, include a representative in the access discussions to avoid any late-breaking surprises about how and when access to applications or data may be provided.

Create an end-user grid containing all access requirements. Include a brief explanation for how access will be used, as this is often a requirement of the client’s security team. Keep this document updated regularly. Specify system-defined roles or “like” other existing user profiles to speed the request up.

2. Consider that you may not need to wait for the official project kickoff to get things moving. Determine if it is possible to engage the client system administrator, security team, and/or third-party vendor in discussions over access beforehand. The goal is not only to get a jump on fulfilling access requirements as soon as possible, but also ferreting out any peripheral requirements that may be necessary – such as user access agreements.

3. Push the request along to finish quickly. Check in on progress frequently, identify where requests are hung up, and resolve these issues to keep things moving forward. Have the team test access as soon as credentials are received, notify the administrator immediately if something is not working while you have their attention to the matter.

By defining system access requirements comprehensively, completely, and early on, you can make sure your clinical data migration timeline does not suffer delay while you await fulfillment of system access. Please check back for the next installment in this data migration blog series: Getting the Biggest Return from your Data Migration Kickoff Meeting.