Guest Spot: The Need for Data Synchronization Tools

Contributed by: Joyce Crook, Director of Corporate Accounts, Summit Healthcare Services, Inc.

In the past year, there has been a steady rise in demand for data synchronization tools in the healthcare industry. With the continued evolution of healthcare requirements coupled with increased project work and staffing constraints in the area of Information Systems; clients and peers have demanded specialized applications to help them maintain the integrity of their databases (or dictionaries). My experiences in this area remember an era where the party or parties responsible for dictionary maintenance were instructed to build all dictionary data in the HCIS Test environment manually, and after thorough testing and verification of the hardcopy with all affected parties, then, and only then could the data be moved or keyed into the Live environment. This works well in theory, but only if you are living in a world where the resources are unlimited and your IT projects are going along at a comfortable pace; without any major hiccups gumming up the works. The reality of it all is that at some point in time, despite best efforts to keep up with dictionary maintenance, your data integrity begins to slip a bit more each day.

Just what is Data Synchronization and why is it so important?

Data synchronization as it applies to healthcare IT in its simplest form is the process of ensuring that the content of data within two or more systems (possibly disparate) are the same for the purposes of data integrity. That’s a pretty broad spectrum and of course the devil, as they say, is in the details of it all. As healthcare professionals really began to take a hold of this issue and ‘peel back the onion’ of data synchronization and peer into its many layers, they soon realized that there is more to this process that meets the eye. The available tools on the market that provide the ability to synchronize data come in all different flavors, and as with anything there are factors to consider based on the feature and functionality that you want to employ in your solution.

The question remains; why is data synchronization needed? There are a multitude of reasons why a healthcare organization decides to spend time and valuable resources ensuring their data is properly synchronized. I will highlight a few scenarios below:

• Maintaining the Quality of Clinical and Financial Data

• Simplifying Advanced Clinical Implementations

• Avoiding the Risk of Users Testing New Rings In Live

• Reproducing an Issue in Test to Resolve a ‘Live’ Problem

• The Need for a More Realistic Training Ground for Users

• Managing Multiple Facility’s Data (Standardization)

What are the different approaches to synchronize data that are used in Healthcare today?

Going back a few years there were many different approaches used by hospitals to synch their data, each having its own degree of success. I’ll outline some of the older methods that may very well be in use at some facilities as well as some of the more current methodologies:

Older Methods:

• Manual Entry

  • Need I say more!

• Use of Existing MEDITECH (Magic) Routines That Could Compare Dictionaries

  • These routines are very basic in nature and it’s an all or none approach

• IT Comparison Tools That Could Highlight Differences

  • These tools are usually more suited for a technical resource (not user friendly)

  • Extraction of the data from the HCIS itself was slow and required special knowledge of report tools (like NPR)

  • This method lacks the support of parent/child relationships (drilling down)

  • No way to filter the data

  • Lacked integration with an automation tool to support the update process

More Recent Methods:

• Scripting Automation Tools

• Specialized Applications for Healthcare Information Systems

So by now you’re asking yourself “why bother with a specialized synchronization application at all, when I can just use a scripting automation tool to script the data into a destination system”? Well, in truth many have gone this way in their early attempts to get their data integrity under control, but they soon realized that it wasn’t always the most efficient approach to get their dictionaries synchronized.

The most common concerns that I’ve come across with using scripting alone include:

• Scripting takes too long to analyze all the differences between two dictionaries, due in part to the number of rules you have to build in your script (to handle multiple fields, etc)

• Concerns about the need to have an easy to use tool to analyze the data before running a script to update the records

• Writing over a complete dictionary without choosing just the differences from a ‘master file’ takes too long via scripting

• Performance (large dictionary files were too large and took too long to process)

• Sometimes a Programmer Level Resource is Required

Specialized applications also come in different shapes and sizes, and from there it all comes down to the cost effectiveness of the product, speed, preferred functionality; the ability to handle complex dictionaries and how easy it is to implement and use.

What are the features or components that you might find in a Data Synchronization Tool?

MEDITECH, for example, is a hierarchal system where dictionaries are built with dependencies on other dictionaries. This layered data structure contains dictionaries with ’multiples’ (one field with many different entries), as well as parent/child and brother/sister relationships. It is rapidly discovered when building these types of dictionaries that using this ‘family style’ data structure, the user must start building from the lowest relationship up. For example, you must build the group response before you build the group; which must be built before the query, which will need to be built before the customer defined screen. Sound familiar?

Some tools handle these relationships better than others and some don’t have a means to handle these special relationships at all.

Now let’s up the ante a little bit more and talk about the unique synchronization requirements of a large multi-chain hospital system. First off, using economy to scale, larger hospital systems often have multiple facilities with separate applications databases to contend with. Without a doubt, the physical geography and configuration landscape add a layer of complexity to the mix right off the bat! But finding a sync tool that can deal with multiple application databases and their complex relationships is just the tip of the ice burg! There is a multitude of less obvious, but equally impacting factors that a large hospital organization must think about as they hunt through the feature list of a data synchronization tool. The most prevalent factors are:

• Built for the Enterprise!

  • Ease of deployment (installation)

  • Supports sharing of synchronization projects to facilitate peer review

  • Low learning curve

  • East to support

• Supports the Need to Standardize Databases From a ‘Master File’

  • Compare the master against multiple hospital databases – quickly!

• Can Quickly Identify Differences in Complex Dictionaries

  • MIS (down to a queries attribute)

  • Clinical Dictionaries (LAB, Pharmacy etc.)

• Reporting & Recovery

  • Must have a comprehensive audit trail of what is updated, when, and by whom

  • Must have the ability to easily revert back in case of a problem during update

Beyond the size of the hospital organization and all the features, bells and whistles that a synchronization tool may or may not have, the bottom line is that in order to be adopted into the organization successfully, the application must be reliable, easy to use and customizable to some degree. In order for one to achieve maximum value of their synchronization tool, the sync application needs to automate each manual process that you’re doing to date; regardless if you are synchronizing simple or complex dictionaries. There are also a number of key features that make the synchronization process more efficient. Features may include:

• Data Analysis Tools

• Support Multiple Data Extraction Methods

• Support of Parent/Child Relationships (complex dictionaries)

• Ability to Select Discreet Data to Synchronize

• Data Filtering

• Support for the Enterprise (peer review on sync project)

• Integrated Method to Update the Dictionaries

As you can see there are many different features to evaluate. You have to decide what feature set is right for your particular facility or project. That said I’m going to take a moment to highlight some of the more prominent features like data analysis and extraction.

Data Analysis

The Data Analysis feature as it relates to a synchronization project is comprised of two distinct parts. First, there is the part to analyze and select discreet data from both HCIS environments (Test and Live) that identifies what you want to synchronize. The second piece is where a user is able to use a grid to quickly view and identify the differences found between the two environments so you can decide what you want to update (which environment wins for any given field). The act of analyzing the data during the selection process can be accomplished manually while keying in the fields you wish to select in your custom report (NPR) or automated through an extraction method which I’ll touch upon in a minute. I believe it is necessary to be able to analyze your discreet data during the extraction itself (data selection) as well as have the ability to analyze the data post extraction and pre update. This is because by analyzing the data before synchronization you can be selective about the data you update, and at the same time achieve a more efficient processing time during the update of the dictionaries. In addition a sync tool with a data analysis grid is especially effective when you can actually see the discrepancies between environments – some products even let you view a parent dictionary against its children!

In my mind, without the data analysis piece, you simply have an un-optimized script solution that pushes data from one point to the next.

Data Extraction

There are basically two methods to extract data from an HCIS for the purposes of synching your data.

• Direct (Database)

• Indirect (Reports)

Direct from the Database:

There are a few vendors on the market that provide a direct extraction method, either through a direct ODBC or .NET driver. The idea here is to have the sync application plug right into your HCIS database with a direct connection and automatically extract the data to a report that is ingested into the synchronization software. This is quite often much faster than traditional report extracts! However, be aware that some sync tools also provide the flexibility to process both a ‘flat file’ import and direct HCIS extraction. This may be something to consider in a sync tool depending on your platform landscape, because support of a flat file import method likely provides the levity to go outside one HCIS into another disparate system for the purposes of synchronizing data (like users and providers).

Sync tools that use a direct method of extraction from the database may also include a wizard to guide a user through the entire process. This is an important point to think about, because the lack of a wizard may mean that a programmer’s skill is required to navigate through the process of connecting to the database, selecting data, and importing the data into your synchronization project. When you look at a product that uses a direct data extraction method, also look for these sub features:

• A Wizard to Guide Through

  • HCIS Connection

  • Data Selection

  • Import into your Synchronization Project

• Support for Multiple File Import Methods (Direct and Indirect)

  • Driver (.NET or ODBC)

  • ASCII

Indirect (Via Report):

There are a few common indirect methods to extract data from the HCIS:

• Standard Reports

• Custom Reports (NPR or Crystal, etc.)

The problem that I see with using Standard Reports (canned) is that you often lack all of the fields necessary to synchronize your databases effectively. This then leads you down the path of finding custom reporting tool resources (Data Analysts) to customize the reports for extraction. NPR, or like reporting tools will certainly fit the bill of extracting your dictionary data into a flat file, but in my experience, these experts are often few and far between, and/or are already loaded down with various custom report requests. Plus who wants to create thousands of NPR reports that will inevitably have to be edited every time a change occurs to your data structure? I haven’t run across one person yet that was overly enthusiastic about this approach!

So, while some may argue the importance of a feature like data analysis over the importance of the data extraction method – I argue it a bit differently. I see these two separate components integrated into one necessary feature!

Now you know the tools you need to synchronize, and have the data ready! What’s next?

It’s time to synchronize. Depending on the size of your synchronization project, there are really only two ways to synch your dictionaries.

1. Manually, like you’re probably doing today. This is effective if its a few fields, so go for it, and have a great time.

2. Using a specialized data synchronization application with an integrated scripting tool. Let’s face it; the only other way to get data back into MEDITECH is either via HL7 or a scripting tool. So, regardless of what solution you choose in the market, it’s scripting in the forefront or the background that is automating this process.

I have often been asked by many about the likelihood of writing updates directly to the MEDITECH database (through some type of direct driver). Sorry folks; this isn’t an option that can be used because such an action would probably break your service contract with MEDITECH - and we don’t want to do that!

In Conclusion:

If your organizations motto is “we never synchronized our data before and there just isn’t enough time to maintain synchronized data”; I’m afraid you won’t be able to stem the sea of change much longer. Hospital Administrators are rapidly coming to the realization that continuing the practice of testing a new HCIS release in a Live environment can lead to incomplete testing and result in other equally unsavory data integrity problems. Administrators can no longer afford to be at clinical or financial risk by having unsynchronized databases.

So in conclusion, I have reviewed a number of reasons why Data Synchronization Tools are needed in healthcare. I also took a look into old and new methodologies used to synchronize data between systems as well as explored some of the most common features and benefits found on the market.

I think you would agree that the value of using a progressive data synchronization tool cannot be disputed. There are many great choices for the healthcare consumer and the right tool will help your organization get back on track with your data integrity or dictionary standardization goals.

####
As the Director of Corporate Accounts, Joyce Crook brings over 11 years of direct healthcare experience to Summit Healthcare. Joyce spent 7 years at MEDITECH in application support and direct sales followed by 2 years of consulting services at First Consulting Group (FCG). Joyce brings a high level of understanding to her Summit Healthcare client relationships due to her unique blend of experience in healthcare technology and consulting services. Joyce continues to direct all account management efforts for Summit Healthcare and is eager to develop innovative programs to manage her client’s needs.