Clinical Data Conversions: Functional and Technical Considerations

Description

In previous conversion webcasts we have given overviews on what a conversion is and the general methodology. In this webcast, we will cover both functional and technical decisions that are important to consider when performing a clinical data conversion. We will cover different options, as well as advantages and disadvantages of each.

Presentation Materials

Download the slide deck Presented July 2013

Q&A

Q: What about any new items that were added in the legacy system after the initial extract was taken? How do we include those items in the conversion?

A: There are a couple different ways this can be handled. It depends a bit on the exact source system you are converting from. If the source system allows free text items (medications, problems etc.) it can be helpful to instruct users to not enter free text after the initial extract and to only use dictionary items. Then to capture any data that was added, a second extract can be taken a week or so prior to the go live and a catch-up mapping exercise can be performed. This should capture any items that were added.

Q: Why does the conversion only grab the most recent instance of each item?

A: Most EMR systems store each time a clinical time was updated separately. For example, if a diagnosis was assessed 3 different times during 3 separate visits, there would be 3 records of that diagnosis. If we were to convert each instance of that diagnosis, you can imagine we would end up with duplicates in the patient’s chart. We typically extract the most recent example the item so we get the most up to date comments/edits to that item.

Q: What do we do when a patient is not able to be matched?

A: There are a few different options you have when patient matching fails. During the conversion process, we can provide a report of those patients that failed. The easiest method to correct the errors is to update the legacy system or EEHR to fix the reason for the error. This might be updating the patient’s last name or some other piece of information so it matches the other system. If patients are missing from the target system, they can also be added. If the patients do exist in both systems and the first method is not an option, a one to one mapping exercise can be completed that will map the patient in EEHR to the unmatched patient record from the legacy system. This mapping can then be added to the conversion logic so data is able to be converted. Another option is just to manually abstract the information for those patients that cannot be mapped. This can be a preferred option if there aren’t many patient matching errors or if the project is on a tight timeline.