Discrete Problem History Data Migration
The scope of the data migration will depend on a variety of factors, among them: timeline, cost, available resources, legal ramifications, and whether or not that data will be useful moving forward. One particular data element that falls mostly into the latter category is problem histories (past medical, past surgical, social and family histories). These are sometimes overlooked in the evaluation process as organizations and Providers are mostly focused on making sure their notes and results are in the scope of any data being migrated. However, this data should be migrated to the new system just as well as any other data from the organizations legacy systems for many reasons.
There are many reasons why an organization should migrate their data. For one it increases productivity as time does not need to be spent re-entering information into the new system. If the staff will be manually re-entering the data this also increases the chances the data will not be in the system when it is needed by the Provider, which in turn will possibly bring about negative patient outcomes. When it comes to problem histories, this is the type of data that is reviewed in every single office visit and you can understand how it will save the staff a lot of time and effort if it is migrated beforehand.
Read More about how Galen can help your organization with a data migration
Problem Histories consist of:
- Past Medical
- Past Surgical
- Family History
- Social History
Mapping Considerations
- How is the source data stored?
- Is this a new implementation or existing target system?
- If you are working on a new implementation you will need all build to be complete to be able to map all values from the source system.
- If this an existing target system you will need to make sure you do not overwrite any data in the system and factor in how you will add new data.
- If the source system allows free text entries or allows the user to create new data points that get stored to the database that will make it much more difficult to match to the source system.
- If you have a large amount of source system data to map you should consider using a generic option and bringing the source system information into a comment.
- However, if you can determine a list of the most frequently used items you can make a point to map those to make sure a majority are mapped to an actual value in the target system (For example: for all data that occurs more than 10 times in the source system)
Validation Considerations
- How much time do have available to test?
- How many resources are available to do the validation?
- Does the target system display the same information in different ways?
- An example of this is would be if you were migrating a family history of "CAD" from the source system which was mapped to "Coronary Artery Disease" in the target system. Although the value would be the same there could be some confusion when doing the validation on whether or not it is displaying correctly in the target system.
- In this instance it is important to have a clinical person review and sign off on your data mappings to make sure you are using the most clinically relevant option in the target system.
Data Load Considerations
- Since you will have more data to load into the target system before go-live make sure you estimate the amount of time the problem histories need to load.
- Will you need to perform a gap load if the staff enters data after you extract the initial set of data?
- What kind of interfaces need to be set up in order to load problem history data into the target system?
- What type of statuses will you convert? (IE - will you include inactive or suppressed histories?)