If you’ve followed the previous steps outlined in this blog series, you should have a good idea of how to pursue data normalization within your healthcare organization. But challenges will continue to arise once you get underway. One of the decisions a healthcare provider or payer will face in the course of a project is whether to use an existing industry standard or create a local terminology. As it turns out, the answer isn’t cut and dried, and will depend to a large degree on the use case involved.
Why Use Existing Industry Standards?
First let’s look at the case for using existing industry standards. At the very least, tapping what’s already out there will avoid reinventing the wheel. Most of us are familiar with common clinical terminology standards such as ICD-9 and 10 for diagnoses, SNOMED CT for problem lists and other clinical applications, RxNorm for medications, and LOINC for laboratory tests. A healthcare organization can also use more specialized standards, such as the Code on Dental Procedures and Nomenclature, which provides a standard for numbering teeth, among other things. But a healthcare organization will have other items to codify beyond medical vocabularies. A surprising array of standards exist, covering elements ranging from bank routing numbers to Zip Codes. Health Language provides over 200 different code sets including geographic locations and bank routing numbers.
Using an industry standard eliminates the time and effort needed to create a home-grown terminology. In some cases, the use of industry standards may help an organization fulfill government requirements. Data recorded in an industry-standard format can be more readily shared within a healthcare system and between healthcare systems and external providers in a collaborative care Refer to ONC’s 2016 Interoperability Standards Advisory to find the industry standard most appropriate for your needs.
Why Create Your Own Terminology?
From a reporting standpoint, there may be times when a provider or payer wants to create its own terminology. Sometimes an industry standard won’t quite address a healthcare organization’s particular set of circumstances. And an internally developed terminology may let the organization extract data in a way that it finds more meaningful.
Use of a local terminology, however, doesn’t preclude industry standards. A health system can map its local terminology to an industry standard to get the best of both worlds. The mapping decisions should be approved by the healthcare system’s data governance committee and documented as part of the data normalization process. For many healthcare providers and payers the use of both existing industry standards and local terminologies will probably be the norm rather than the exception.
If you decide to use a local terminology, various options are available for mapping to a standard terminology. If you have a simple list of concepts, maintaining them and mapping them to standards may be straightforward. However, for larger sets of concepts, terminology tools such as Health Language’s LExScape and LEAP Map Manager may be useful. LExScape, for instance, is particularly valuable if you are maintaining ontological relationships in your local terminology.
Sometimes your local terminology may be represented as an extension of an existing standard. Some clients have extended ICD-9-CM, for example, by appending letters or digits to ICD-9-CM codes for internal use. More formally, it is also possible to take advantage of advanced SNOMED CT capabilities such as creating post-coordinated concepts or adding new concepts using a unique "namespace." These can be clever solutions—but sometimes too clever, as these special SNOMED CT constructions may be difficult to maintain. They may also be only “pseudo-interoperable,” that is, they appear to be perfectly interoperable since they resemble other pre-coordinated SNOMED CT concepts, but they won’t be recognized when sent to other organizations.
The decision on selecting existing standards versus deploying local terminologies is one every health system will have to make at some point. The data normalization project team and your data governance structure will see you through this process.
At this point, you should be well on your way toward data normalization. Next up is the last blog post in this series: Mastering the Data Normalization Cycle.