In the world of healthcare, Electronic Health Records (EHRs) have become indispensable tools, revolutionizing the way patient information is documented, managed, and shared.  MEDITECH, one of the leading providers of EHR systems, has played a significant role in this transformation.  However, despite their reliability, EHR systems are not immune to downtime, which can occur due to various reasons such as technical glitches, ransomware attacks, maintenance activities or even natural disasters. 

In part one of this blog from January 2024, I wrote about why I think Microsoft Power BI is a superior data analysis and reporting platform for MEDITECH Data Repository compared to SQL Server Reporting Services. In this second part of a a two-part analysis, I continue the discussion by reviewing the user presentation and interactivity experience.

I’ve been working with MEDITECH Data Repository since 2000. That’s longer than I care to note, but I still remember when SQL Server Reporting Services was first included with SQL Server, in version 2000: after struggling to find an easy way for our small hospital to share DR data and reports without having budget dollars for software like Crystal Reports, suddenly we could share it on our intranet. 

What are indexes? Simply put, indexes in a SQL Server database are structures that speed up data access from tables and views. There are two types of indexes: clustered and nonclustered. Since any database table can only have a single primary key (therefore, a single clustered index), nonclustered indexes are what we as developers and analysts can optionally use to improve query performance. 

In our previous Power BI blogs, we’ve introduced the Power BI platform and described why it’s such a great tool for developing custom business and clinical analytics reports for MEDITECH Data Repository. In this blog, we’ll discuss a vitally important concept at the heart of all Power BI report development: the data model.

Working with data these days seems to be all about metrics, measurements, and numbers. Healthcare data of course is no exception, just think of the many different contexts of numeric values possible in the MEDITECH EHR: lab test results, patient counts, drug dosages, account balances and budgets – the list is long. Fortunately, SQL Server gives us some tools to work with and manipulate numeric values to the sometimes very precise formats we need in a clinical context.

I often find myself having the same conversation with folks about the health of the data in MEDITECH’S Data Repository (DR).  I remind them that if they use the DR for reporting, but don’t have a process to maintain data health and accuracy, then they shouldn’t be using DR. Keeping DR data healthy is easy, it’s just a matter of knowing what to do and when to do it.

The ability to scan a patient record into the system greatly improves workflow and reduces errors. Did you know that it's easy to use barcodes on reports from Data Repository?

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.

In our first Power BI blog, we introduced the Power BI platform and reviewed the desktop applications and cloud-based tools we can use to develop and share reports and dashboards. In this blog, we’ll look more specifically at the ins and outs of using Power BI with MEDITECH Data Repository.

MEDITECH’s Data Repository has come a long way since its inception over twenty years ago. In the early days of DR, usable front-end reporting tools were few and far between: Microsoft Access and Crystal Reports were common choices for many hospitals. Fast forward to 2021 however, and DR is an integral part of the MEDITECH EHR and report developers have a variety of tools to use: the ubiquitous SQL Server Reporting Services (SSRS) from Microsoft; MEDITECH’s BCA with MicroStrategy; and third-party software like Tableau and Qlik, among others.

In part 1 of this blog, we covered at a high level the basics of T-SQL user defined functions. In part 2 we’ll explore the advantages of leveraging functions, and when to do so.