Health Language Blog

Identify Constraints that May Impact your Data Normalization Plan

Posted on 09/24/15


At this point in the integration of your data normalization solution, the project team has a strong executive sponsor and has assessed the healthcare organization’s data normalization needs. So far so good. Now it’s time to identify the constraints that might hinder the normalization initiative. Those constraints will determine the pace of the project and highlight areas in which additional planning will be required to overcome obstacles.

A project as wide-ranging as data normalization is likely to encounter some difficulties along the way. A health system that takes the time to identify possible risks—before plunging into a project—stands a much better chance of success.

Standard Constraints

The constraints facing a normalization initiative are the same ones that typically confound any project: time, money and resources. The project will call for several team members (project managers, for instance) to devote most of their time to the normalization project. Other participants such as members of the management team or IT analysts may need to contribute 10 to 20 percent of their time to the cause. The project’s leadership must determine whether team members have the bandwidth to handle project responsibilities amid the healthcare organization’s other initiatives. This is where executive buy-in can be decisive: executive endorsement keeps the focus on normalization as a priority.

Executive support can also ensure that sufficient funding is earmarked for normalization during the budgeting process. If funding is limited, an organization will have to account for budgetary constraints in its project planning and implementation timetable.

When considering resource constraints, the availability of technical subject matter experts (SMEs) is particularly important. SMEs possess the domain knowledge and, therefore, are in a position to contribute their understanding of how to normalize the data under their jurisdiction. The project team must identify those SMEs. This task can be difficult in the case of legacy systems. Can the team find the owners of legacy systems and secure a portion of their time for the project? A programmer or technical resource with knowledge of that legacy system is required for extracting the data out of the legacy system.  A person who set up the data or administered it, and understands why certain values were chosen and how they are used in the system, is key. Understanding how to normalize data in an antiquated system with no SME and, possibly, no documentation will take more time. It's a constraint that the project team should identify early on.

Hidden Issues

A project team also needs to look for hidden problems in addition to the obvious constraints of time, money, and resources. One potentially overlooked constraint is the limitation imposed by a healthcare organization’s IT systems.

Consider the following example: A health system wants to develop a standard coding schema for identifying each of its sites. The ability to impose a standard nomenclature spanning all sites will facilitate data aggregation and analysis. The health system will be able to know how many patients seek treatment at each site and how much each facility is billing.

Different sites, and different physician groups working with those sites, will most likely be using multiple electronic health record (EHR) systems from different vendors. One of those EHR systems may impose its own coding standard, making it impossible to normalize in the EHR and forcing data normalization to occur in a data warehouse.

Understanding this data normalization constraint upfront will determine the initiative’s strategy going forward. The project team must plan for an extra normalization step in which the nonconforming EHR system's value for a given site is mapped to the standard value desired by the healthcare system.

Consider Different Perspectives

Finally, a project team should take care to look at data normalization from both a technology and a business perspective. Just because data normalization makes it technically feasible to aggregate certain sets of data doesn’t mean it makes business sense to do so. A healthcare organization running systems for payers and plans, for instance, will probably not want to mix the data generated by those systems. Instead, they will aggregate data within separate groups.

What do you view as the key obstacles in the path of data normalization? Leave your comments below.

Next Up: Prioritize Your Data Normalization To-Do List with an Impact Analysis


 Read Previous Data Normalization Blog                                      Read Next Data Normalization Blog

Topics: data normalization

About the Author

Brian Laberge joined Health Language in September 2010 and has served in multiple capacities including Technical Consultant, Project Manager, and Director Of Client Implementations. He brings over 18 years of implementation and software deployment experience to Health Language and has managed several Data Normalization and ICD-9 to ICD-10 projects for Payers and Providers during his tenure here.