In this article series on data normalization, we have outlined how to secure executive buy-in and identified constraints that may impact your normalization plan — you should be ready to start your first normalization project.
A project team that has gone through an impact analysis and prioritized its data normalization projects will probably have a short list of likely project candidates. The two critical factors to consider when selecting the initial project are size and impact. The project must be small enough to be manageable and likely to be completed in a reasonable time, but large enough to demonstrate a meaningful early win to key stakeholders. Resistance to changes (such as formal data governance processes) can be minimized if participants readily see how they will benefit.
This approach will also keep executive leadership on board. A project’s champions may have obtained executive support early on, but they must continue to sell the value of normalization throughout the project lifecycle.
Selecting your healthcare terminology standards
Once the project is selected, the project team determines which terminology standards to employ. A team may opt to use an industry standard or a locally developed standard or some combination of these two. Sometimes you will be seeking to comply with government mandates such as Meaningful Use requirements, and this means you’ll need to use an industry standard. Remember that even in the absence of a mandate, choosing an industry standard provides the advantage of making data more portable across systems.
Standards are very diverse, covering familiar diseases and procedures, and less common concepts such as race/ethnicity, dental anatomy, and medical devices. With so many terminologies to choose from, deciding on a standard can be challenging. It’s a good idea to see what standards others have chosen for the same domain. Resources to consider include the Office of the National Coordinator (ONC), which has overseen the Meaningful Use technical requirements, the Value Set Authority Center, and the CDC Public Health Information Network. Organizations like Wolters Kluwer, Health Language also provide consulting services on best terminology practices.
In some situations, however, healthcare providers or payers may want to create a local standard that is more meaningful to them and addresses their particular needs and circumstances. I will dive more deeply into this in the next blog.
Documenting decisions throughout your healthcare data normalization project
As the project team rolls out the first data normalization project, every decision it makes along the way should be well documented. The team needs to spell out why it is selecting one standard over another or adopting a local standard versus an industry standard. Decisions about what type of data will be mapped to which standard should also be documented. Mapping tools like Health Language’s Map Manager simplify context-sensitive documentation and automation of the audit trail.
Documentation helps make an organization’s data normalization processes consistent and repeatable. Documentation should include guidelines and processes. Otherwise, different mappers will impose their individual views on mapping, creating inconsistencies in your data. You will be revisiting your mappings again as standards change. Having documentation readily available allows you to provide the original rationale when questioned for an audit months or years later.
Keep in mind that the documentation is a “living document” that will evolve over time as context, standards, and team members change. It’s a good practice to make sure that as edits are made to the document, you retain old versions for future reference. Rigorous documentation allows a future project team to make informed decisions that ensure consistency of data normalization.
Managing expectations for success
A project team should get used to the idea that the initial mapping rules they have established need additional clarification. A team may need several attempts to get the mapping rules fully defined, but that’s part of the learning experience. The key is to normalize data through several scenarios and catch any opportunities to refine your rules before the project goes live.
Because of the potential for error and the need for testing, the project team should add additional time in the project schedule for this refinement process. A buffer will be especially important for the first couple of projects.
Speak to an expert to learn how Health Language solutions can help your healthcare organization.
