Data Definitions – Finding Where the Data Lives

What is this term “Data Definition” that everyone is always talking about? Okay, I admit maybe not everyone is talking about data definitions, but it is a common term thrown around for us folks that work in the MEDITECH space. Especially for those involved with requesting, designing, or creating reports.

A Data Definition is MEDITECH’s Term for a Data Schema.

Simply put a data definition or data schema is just a description of how data is organized and stored in a database. The terms data definition and data schema refer to the same thing. Data Definitions and data schemas are like words in a dictionary. Every field or key in a database has a definition. Except in this case, instead of a description of what the word means the definition describes in technical terms how the field is organized in a database and what its attributes are.

Keys, Records, Fields, and Attributes – Oh My!

A field is simply the smallest element of data in a database. Fields are defined by attributes like name, size, data type, length, and required. Attributes describe the behavior of a field or record. In addition to attributes fields also have values. However, when we are discussing data definitions or data schemas, we are generally referring to the attributes of the fields and what records they belong to, rather than their values. The data definition is created when designing the database and the field and key values are put in place when the database is being used.

A record is simply a group of related fields. For instance, in MEDITECH the RegAcct.Providers record contains fields like IsPrimaryCareProv and IsAttendProv.  This record has two keys. The first key is the patient identifier. In MEDITECH the patient identifier is referred to as the OID or Object Identifier. The second key is the Provider, which points to the person dictionary. This would be the physician’s user ID or user mnemonic.

Keys are used to identify a specific instance of a record. To illustrate this concept, think about this simple real-world example: Lets design a database schema to keep track of library books. You might design a record called Book, that contains fields such as: book title, author, publish date, and type of book (paperback, hardcover, digital), ETC. A good key value for the book record may be the book’s ISBN number. It is often the case though that the library will have multiple copies for a particular book. In that case you may want a separate record to track each physical book in the library.  The record to track this might be called BookInventory and contains fields like ISBN number (points to the Book record), book status (in/out), and the library user that has the book checked out. The key for this record could be a system generated number that uniquely identifies each physical book in the library.

Why are Data Definitions Important?

Reports are an important part of the modern Electronic Health Record (EHR). The first step in designing any report or SQL query is determining what specific data is needed to meet the report requirements. Then you need to determine where the data is stored in the database. The data definitions are what you need to determine where the data is stored and how it is organized. To add fields to your report, you need to know how the fields are identified (what record keys are needed). There is no way to write a report without understanding the relationships of the fields that are needed for your report. The data definitions clearly spell this out for you.

Viewing Data

When working on reports or SQL queries it can be extremely valuable to view data in its raw form. Viewing the data definitions is helpful but looking at the raw data after reviewing the data definitions can really help you understand the relationships between the different fields and records. MEDITECH has a very powerful tool called Object Viewer that can be used to view MEDITECH data in its raw form. However, this tool is only available to MEDITECH staff. For those of you that are familiar with C/S and MAGIC NPR, this is akin to viewing MEDITECH data from the “G” get function at the MEDITECH front end.

We are all bound to protect patient data and should only be allowed to view data that we are granted access to view. It would be extremely useful for folks writing reports to be able to use a data viewer tool that only provides access to the data that the user has permission to view. When working on SQL reports or queries, typically the person writing the report can easily view all the data in the database he/she is working on. Keep in mind though that a MEDITECH SQL database (livefdb, lvendb) contains ALL of the MEDITECH applications for the designated platform (M-AT or NPR). Access to view specific data can be controlled at the table level in SQL. However, often access is granted to an entire database. This type of access does make sense for someone that is writing a report.

Viewing Data Definitions

Fortunately, there are a lot of great tools for viewing data definitions. I put this table together in order to outline all of the different tools that are available and some of their pros and cons.

Click here to view The HCI Solution’s Data Definitions Tool. The HCI Solution Data Services team also provides advanced report writing and report conversion assistance, Click here to check out our services. The HCI Solution gives back to the MEDITECH community by providing complimentary beginner to advanced Report Designer Educational Sessions each month. View our upcoming RD Ed Sessions.