The Achievement of Just-in-time Data Binding for Healthcare

You’ve heard of late-binding and you’ve heard of early-binding but have you heard of just-in-time binding? Late and early binding are the most used in the healthcare industry hence their huge popularity in healthcare literature but there’s not a lot of data or people discussing Just-in-time Data Binding for Healthcare. Well, what can we say? Just-in-time binding is a combination of late and early binding. It’s applying techniques from both in a strategic way that takes advantage of the high points of both styles. The industries like military, manufacturing, and healthcare that have operated their data warehouses using late-binding principles for more than 20 years continue to deliver an unparalleled track record for proven results. Some of the major advantages of the late-binding technique are:

  • Minimize remodeling data in the data warehouse until the analytic use case requires it. Leverage the natural data models of the source systems by reflecting much of the same data modeling in the data warehouse.
  • Delay binding to rules and vocabulary as long as possible until a clear use case requires it.
  • Earlier binding is appropriate for business rules or vocabularies that change infrequently or that the organization wants to lock down for consistent analytics.
  • Late binding in the visualization layer is appropriate for what-if scenario analysis.
  • Retain a record of the changes to vocabulary and rule bindings in the data models of the data warehouse. This will provide a self-contained configuration control history that can be invaluable for conducting retrospective analysis that feeds forecasting and predictive analytics.

The idea of late binding in data warehousing borrows from the lessons learned in the early years of software engineering. In those early years, very large software programs characterized software development. It was very common and a widespread practice to program hundreds of thousands of lines of code in a single module, supporting numerous and widely different business functions. The code for these varied business functions was tightly bound or coupled together all at once, at compile time. It was a time-consuming process to write and troubleshoot these large programs. If one piece of the program failed at compile time, the entire program failed. It was all-or-nothing programming. Also, if the program required changes or modifications because of new business rules and requirements after compile time, the entire program had to be modified, recompiled, and placed back in service, often with significant downtime. Hence simplifying Late-Binding data increases agility and efficiency and makes for more efficient use of the data.

Early binding is the process where traditional data warehouses try to model the perfect database from the outset, determining in advance every possible business rule and vocabulary set that will be needed. This early binding practice is a time-consuming, expensive undertaking. In healthcare, business rules and vocabularies are dynamic and improve rapidly – and so do they use the cases that data linked to different source systems can serve. Mappings must be redone again and again as data models shift. Early binding architectures – like those espoused by Bill Inmon, Ralph Kimball, and others – force early data bindings into proprietary enterprise data models. Time has proven early-binding architectures to be inflexible, one-size-fits-all solutions, enforcing a compromised, least-common-denominator warehouse.

In summary, the combination of these two binding techniques is what many organizations seek to have there data management. Besides data binding, organizational structure can be said to be the only other determinant of performance but that is not the case. Organizational structure is not the only determinant of performance. In some cases, it is not even particularly important. That’s why changing a company’s structure to meet a particular strategic goal can actually exacerbate problems rather than help solve them. For example, an organization struggling to innovate may try to gather more and more creative input—and end up getting too many people involved, thereby slowing the pace of decision making and stifling innovation.