Technical Considerations > Data Normalization and Standardization
Technical Considerations

Data Normalization and Standardization

After years of little regulation surrounding EHR data integration, a health system may send data to an integration partner using any number of methods, formats, and value sets. A big value our engine provides is standardizing the data we receive from EHR systems into our JSON models as well as normalizing the incoming value sets. This means that a message we send you from one system can be processed by your application the same way a message of the same type from a different EHR is processed.

So what kinds of data do we normalize and how is this done in our engine? We do this for almost any data field where there is a set list of possible values within the EHR. These fields include patient race, ethnicity, marital status, and language among many others (click here for a full list of our normalized fields). During an implementation, we analyze the values in these fields coming from the health system and make sure they are mapped to new or existing values in our own standard tables of values. As an example of this normalization, we make sure that all of the values we receive indicating a contact’s relationship to a patient look the same. If the contact is the patient’s brother, that data could come across as “Brother”, “BRO”, “B”, etc., but we will always map those values to “Brother”.

A group of data we do not yet normalize is coded values. This is largely due to the size of the code sets, which include ICD, SNOMED, NDC, RxNORM, LOINC, CPT, and HCPCS codes. Translating codes and mapping them between code sets can also have significant clinical implications, as there isn’t always a perfect mapping alignment between sets. We’ve also found that due to government regulations it’s pretty safe to assume that most health systems have already implemented a number of these code sets, such as ICD-10 and LOINC codes. If you are interested in coded value normalization please let us know as we are always interested in hearing about particular use cases and discussing what we could support.