Medical Record Data Quality and Validation

Medical record data may be missing, duplicative, slow to retrieve, unstructured, malformed, or even corrupt. The truth of the medical domain is that data quality varies significantly due to interoperability, format, individual practitioner practices, and provider provider practices. Risk, HEDIS, prior auth, disability evaluation, and other processes all heavily rely on having good data quality.

Because of this, entities who with healthcare data must do one or multiple of the following:

1. Learn to work with data regardless of it's state.

2. Bias toward better data sources over lower quality ones.

3. Coerce sources to improve their quality with policy or incentives.

Most entities, including Payers, Pharma, and Providers must usually work with 1, however larger entities like those such as federal agencies may be able to choose 2 or 3. For these reasons it is valuable to build tools to determine what quality is and a reasonable way to measure it.

Medical Data Validation vs Medical Data Quality

Validator Tools exist for almost all formats. In HL7 FHIR example, tools like Inferno allow a user to load in Implementation Guides that define how the data must be structured to be valid. These systems also provide guidance where strict errors, warnings, and general informational guidance is available based on data structure. Tenasol hosts a FHIR Viewer and FHIR Validator for free use [blog].

Quality Tools exist to make sure that the presence of information is complete, already assuming that the data structure is formatted properly for a specified use case. The FHIR analog to Inferno would be PIQI, which is a framework for specifying narrower requirements of FHIR data fields. For example if a pediatrics clinic is trying to validate that their patients ages are below a certain age. Here is a table for further guidance:

Generalized Measures of Healthcare Data Quality

Examples of information that effect quality of a medical record corpus include:

• presence of fields patient information - such as name, date of birth, date of death (if applicable), ssn, sex, race, ethnicity, phone, email, address. These are missing all the time from all types of medical records.

• percent of structured files (e.g. X12, HL7v2) - Structured files have higher resiliency and accuracy. In some cases we see scans of scans which can degrade image quality, while a structured data file is persistent. These fields are also strict and may easily be validated.

• code validation errors - Codes such as LOINC. ICD-10, or RxNorm codes are verifiable with regular expressions. They should also be attributable to a practice, practitioner, and date of service.

• unit validation errors - When applicable units much match UCUM standards to be accepted by most structured data engines in healthcare.

• generalized processing errors - A file must be parse-able to be processed rather than corrupted or malformed.

• medical applicability of files - files must me medical in nature to be useful. It is common for such information as financial forms or general email communications to slip into a larger set of medical data.

• duplicate files - duplicate data is very common. This may occur from practitioners or systems faxing data multiple times on accident.

• duplicate pages - duplicate pages may occur when the same record

• duplicate fields - duplicate fields are very common in even structured data. This occurs when the same concept is referred to multiple times, or expecially in FHIR bundles when data has different hash references but is essentially the same underlying data.

• mis-oriented pages - These are common in image or PDF unstructured files when pages are loaded into a scanner incorrectly.

• handwriting - handwriting may be detected with image analysis or rudimentary trigram machine learning models. High presence of it may complicate a charts value for a specified use case.

Specific use cases may also be interested in:

• cost of record procurement - The method of retrieval varies by the methods of:

  • Electronic network

  • Fax/email transfer

  • Physical collection

• speed of record procurement - also varies by interoperability partner and

• relevance of record data to application - date of service, or data on an incorrect patient may cause conflicts that make the data not applicable to the case.

Tenasol uses these measures to build an overall measure of a repo of medical records' data quality, regardless of mix of underlying format.

Conclusion

Healthcare data quality is not a binary measure of whether a record is valid or invalid. It reflects whether the underlying information is complete, accurate, usable, relevant, and fit for its intended purpose. Validation tools can identify structural and terminology problems, while broader quality frameworks can measure issues such as missing information, duplication, poor image quality, inconsistent coding, and record relevance. By combining these measures across structured and unstructured data, organizations can quantify the quality of an entire medical record corpus. This allows healthcare organizations to identify weak data sources, prioritize remediation, and make better decisions about which data can reliably support downstream applications.