Databases + Healthcare – Watta Happy Family

Danny Database + Hani Healthcare = Family?

I know pronounce the two of you in a happy JOIN, to form this relational happy family.

** I love you, you love me, we’re a happy family. With a great big hug and a kiss from me to you, won’t you say you love me too. ** Get some old feels? Feel nostalgic? WELL! That’s not the point of today, but I just wanted to bring back some nice feels for the happy family that we will be talking about today, Danny and Hani. In a series that I will be writing a lot more about, I’ll be discussing just how valuable data is and how it is used in healthcare. But a quick overview is this: Healthcare + Rules + Laws + Crap Ton Of Money = RAPID transformation from a paper heavy industry into electronic records with a crap ton of healthcare data. With electronic data… comes databases.

The foundation to all things data, regardless if they were on paper, on excel sheets and even the modern databases today, I still find it confusing about how some of the data is specifically used and how they can play a role in healthcare. One of the most common database types used in healthcare is the OLTP database (online transaction processing). For the most part, the commonly used electronic health records utilize a OLTP database because it allows for quick, real-time transactional processing of data that emphasizes speed and quick response times. Today, these applications and software are used not only in EHR, but for lab systems, billing and financial, administration, patient satisfaction (I’ll have another day on this), tracking, research, and so much more… just look at Epic’s array of software available and you’ll understand why it’s not a suite but a penthouse. However, the difficulty is that with each of these applications, there is its own database which can lead to very fragmented and different forms and kinds of data and values being recorded, as would be expected. The problem is when people are trying to analyze trends and metrics, it makes it very difficult to generate reports or even to aggregate them together. This brings about why healthcare data is just so difficult to deal with:

Happy Family ... right?

  1. As expected with many different applications, each with very different measured values and metrics, all of the data will be located in multiple places and in multiple different formats. These different sources, stem from different departments, that stem from different metric indicators, that are all used to measure different patients… who use a different insurance and so on! Fortunately, there have been movements to try and standardize certain criteria, primarily with SNOMED/ICD-9/ICD-10 for diagnoses codes. A happy family knows how to make compromises to try integrate different methods of cooking spaghetti (example spaghetti).
  2. Some of the data can be structured, and some are not. Back in the paper days, information would be taken that would best help the provider, but now, the EHR are simply capturing everything, ranging from patient notes to patient billables it is very difficult to differentiate and annoying to sift through information that might not even be relevant. The unstructured difficulty would be in situations of strict standardization, where providers can end up using the free-text boxes for their own notes that might not fit any of the drop down choices or checkboxes. The happy family would ask why there are no nightly chores, only for others to respond that it’s not necessary!Happy Family - Where Are You?
  3. EVERYBODY NAMES THINGS DIFFERENTLY. WHY!? Date of Birth has so many variations, how are phone numbers stored, how are the diagnoses stored? How are the physician notes? Metrics? Variables? There is rarely ever an agreed upon naming convention which makes the transferability of health data such a difficult task. It’s like when Danny and Hani are arguing about what to name their children, and who will be the oldest at 3NF, 2NF and then 1NF? The key to a happy family, is to make sure they’re all treated like the 3NF.
  4. The data is complex. There is so much information, useful and not useful. There is so much  variation. There is so much security and so many precautions behind it. Each hospital names things differently, each application names that differently, and each database will read it in differently. This would be like the “side-chicks”, completely against a happy family.
  5. CMS – HIPPA – Meaningful Use- HITECH – ARRA … more and more regulatory bodies are trying to limit the information or trying to request for more open data to be transmitted. There is a push for transparency… there is a push from fee-for-service to fee-for-value… there is a shift in ways that only burden the healthcare community through lowering reimbursements, increasing health coverage and what not. These would be the meddling and annoying In-Laws for the happy family.

With those in consideration, it’s important to consider solutions that can help alleviate these problems, one of which is the enterprise data warehouse or a clinical data repository. The clinical data repository, is just that, a repository, so it lacks the analytical tools that EDWs have access to, and can only provide few insights on ways to improve efficiency, patient care and make strategic and tactical business decisions. EDWs can alleviate that depending on the model and design that they are built on, but in some cases they can help provide cleaner data, analytic tools, better opportunities to generate reports, and reduce waste and inefficiencies in financial spending and healthcare decisions.




Article by Sir. Lappleton III

I'm a happy-go-lucky recent graduate that started a blog as a way to not only document my education and my experiences, but also to share it with whoever stumbles upon my site! Hopefully I can keep you guys entertained as well as learn about a few things from IT as well as from my time and experiences as I plunge deeper and deeper into healthcare! A couple of my areas of focus is data management, system security (cyber security), as well as information technology policy.