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.
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.
I recently had a student from one of our online training sessions email me a few days after class, asking why I recommend always using the SourceID column as part of every TSQL join. They sent two queries to demonstrate why they felt they shouldn’t use SourceID.
So, in plain English, what is a T-SQL user-defined function? A function is a SQL query saved as a database object, which leverages and outputs data to serve a focused purpose. Once a function is created it easily can be utilized at any time by anyone with proper access. Measured creation and execution of functions will greatly streamline data production from your T-SQL environment, allowing technology to do what it’s supposed to - make our lives easier! Let’s start with a simple example to better explain why we should be using functions and illustrate different types.
MEDITECH's Data Repository best practices recommend a dedicated drive for tempdb data files, that the space allocated to this drive be 25-30% of total data space for the SQL Instance, and that the allocated space be split between eight data files and one log file. Is it possible to modify tempdb to meet these standards? Read on to learn how.