THANK YOU FOR SUBSCRIBING

Question…… what percentage of you at community hospitals have a couple of million dollars laying around for analytics?

To quote Ben Stein, “Anyone…., anyone…..”

Didn’t think so….

Another question….. What percentage of you would like to answer basic questions regarding re-admissions, quality metrics, population health, etc.?

So, how can we get these questions answered within the face of budget constraints?

I would wish to propose one method.

The basic problem….

Most of the questions that cross my way are fairly candid. The complexity arises largely because systems don’t ask one another. Imagine a world where each piece of knowledge was in ONE SYSTEM! How easy would analytics be then! the truth is that we are faced with many systems and sources of knowledge in healthcare and that we don’t have a simple way of accessing the info.

Enter the info Lake

One tool that we use to deal with data gathering may be a Data Lake. I'm often asked how a knowledge Lake and a knowledge Warehouse differ. a knowledge Lake is just a repository where data is stored in its native format. Data Warehouses are defined as data structures that model a business area or need. The higher, more complete the model, the higher the warehouse.

Data Warehouses are at their best once they have an objective. When the business area they affect is fairly well defined. That isn’t the case in modern healthcare. The questions come hot and heavy from all areas…. the info does like-wise.

Data Warehouses are “Pay Now” systems: You pay upfront to define and optimize the structure, normalize and cargo the info.

Data Lakes are “Pay Later”: It’s a relatively straightforward interest “Take what you're given” and put it somewhere.

You pay once you got to use the info. You then need to pull what you would like, relate it somehow, normalize/ optimize the info, and visualize it.

The idea with the Lake is that you simply can “mix and match” the info as required to deal with the question at hand.

The reasons we use a knowledge Lake:

1) It stores an outsized amount of knowledge from a good sort of source.

2) The info has no discernable or immediately identifiable keys to match on.

3) We lack a platoon of Data Modelers, DBAs, and Business Analysts to coin a warehouse.

4) We don’t know what business areas this data will get to address.

Truth be told, I might much prefer a knowledge Warehouse, but when the info is so varied, the questions are so fluid, and therefore the resources so constrained, the “pay later” approach seems to form the foremost sense.

Borrowing from Agile

So now that we have the info, how can we best get the answers we seek?

In Scrum (Agile) methodology, you build small working versions of a product at predefined intervals eventually building an entire product. This concept seems perfect for our analytics dilemma!

Why? Agile care with doing things in little pieces…. Complete pieces, but piece-parts non-the-less…. It works in teams of “7 plus or minus 2” and everyone functions are performed by one team.

So here’s the plan…. be happy to undertake it subsequent time you would like an issue answered and end up without an analytics team!

1) Select a “Scrum Master”. This may be the “point person” who coordinates the method.

2) Clearly define the question. For instance, “How many re-admissions of condition X are there?”

3) Have a gathering with business and data people on the brink of the world in question. During this meeting:

a. Define an inventory of required data points.

b. Select the primary three or four data points to collect.

c. Define a period for the team to return up with these data points. During this point, the team will gather the info. Traditionally this “sprint” is defined as 2 fortnight, but it is often any reasonable period that the team is comfortable with.

4) Have a daily 15-minute call to uncover any obstacles. Any issues should be addressed immediately to stay the method moving.

5) At the top of the period, meet and assign more data gathering if required.

6) Repeat steps 3-5 until enough data is captured to deal with the question.

7) When enough data is captured, have a final “sprint” to see the info into a presentable finding.

Questions that are much targeted work best with this method. Questions that start like: “What’s the amount of…” or “How many….” Larger questions which will be weakened into smaller data gathering tasks are good candidates also.

As more data is made, and demands on organizations increase, the necessity for flexible approaches to analytics will too. I hope this has given you food for considered the appliance of agile techniques for analytics.