Report and Data Validation

How do I know it's right?

One of the challenges in writing reports from MEDITECH Data Repository (or any system for that matter) is knowing for certain that you got it right. That not only means the data are accurate, but the person requesting the report is satisfied with the result too.

Data Repository remember is not the "source of truth" for MEDITECH data, because it's a COPY of the application data that lives natively in the EHR. In the old days of DR, many of us remember how the slightest hiccup in local network traffic could cause problems with DR data transfers, often undetected, resulting in inaccurate data. Often you wouldn't find this until later when writing a report for a user only to find problems. As we write reports, we should always validate the report data, that is, confirm that it's accurate and matches what we find in MEDITECH. Data validation is a bit different that auditing data, which is the process of comparing data, row-by-row, from Data Repository tables to MEDITECH applications using automated software like DrAuditor or MEDITECH's built-in tool.

With that in mind, here are some suggested guidelines to follow for validating report data. 

Understand the purpose of the report 

Have a conversation with the report requestor about the report's purpose. What's it for? Ask about relevant workflows in MEDITECH and have them provide screenshots if applicable. Understanding how the report will be used and by whom will help you write it correctly and validate its accuracy.

Work with examples 

As you're working with a detailed report, something with many thousands (or more) of records potentially, it's helpful to have a few reference examples of the detail-level identifier to work with while you test your code and logic. For example, many reports are based on a patient account number with details from that visit. Use a few accounts that otherwise meet all the other report criteria to test with as you validate the report. Ask the report requestor for a small number of examples, based on what they see in MEDITECH.  Use different examples to make sure every possible scenario is covered (e.g., inpatients, outpatients, etc.). Using examples may expose an issue with the report that wasn’t anticipated and provides another level of data accuracy and validation before you publish the final report.

Compare data against its source

Once you have the initial version of the report done, ask the report requestor if there's a standard report in MEDITECH you can compare against. If you've written a B/AR report, for example, you can often find financial reports from the B/AR desktop that will produce the same detail, so you can compare results at both a summary and detail level, down to the penny, if necessary. Another approach you can take is comparing against established (and we hope, previously validated) NPR reports. This is especially helpful for MAGIC, C/S and 6.0x hospitals that are anticipating an upgrade to Expanse at some point, as most NPR reports will need to be re-written, and Data Repository is a great alternative for these.

Extra steps for data exports 

If you're using Data Repository as a source for exporting data to a delimited file (for use by an external vendor, or some other type of data submission), there are some other considerations to keep in mind. First, read the file specification! Make sure you understand the requirements for file format, delimiters, field width, required data elements, etc. Be sure to test and verify your process that produces the file (e.g., a scheduled SSIS package using SQL Agent) and that the end result meets all the requirements. Finally, if the file needs to be produced on a regular basis, make sure you accommodate that schedule as appropriate. For example, if it runs once a month for the previous month, you can use TSQL date functions in your stored procedure to always get last month's data, based on the run date from your automation.

These are just a few suggestions that you can follow to ensure your reports are accurate and keep your users happy. If you have other ideas, please tell us about them!