Thinking about DIY analytics? Before you get too deep, advice from someone who’s been doing DIY for 25 years.

Mar 18, 2023

Healthcare systems all over are looking at their data as a way to help them identify savings.  I  know because we meet with them all the time.  Many are in the ‘DIY’ phase of solving the issue.  Starting with some basic tools like Tableau or MSBI and a spreadsheet.  Some are having a modicum of success, which is great.  Most will fail eventually, although they don’t know that yet.

I  come in peace writing this.  I  am a huge believer in custom systems.  My prior life was 25 years of selling custom projects to companies all over the world. Custom projects are important in addressing the unique aspects of a business.  Yet, what we see are healthcare systems writing their own supply chain analytics systems. Here’s the issue: supply chain analytics is not unique.  Every facility has a supply chain.  Each has high-end spending and commodity spending. So why are so many facilities embarking on their own analytics project?  This is not an instance of uniqueness.  This is a place where a vendor with a system (see: Truvue) can bring a lot of value in a very short time. Cross-industry business issue similarities is a ‘buy’ signal in a ’build versus buy’ world.

Still not convinced?  Then continue reading.  Below I  list 14 hurdles of custom development, gleaned over years of exposure to the industry.  As I said earlier, I  come in peace!! I’ve seen too many projects fail using the wrong tools, the wrong training, or limited scope.  Before you get too deep, take a look at this list.  If you have them all addressed, I wish you the best. You should still check a solution to speed up your time-to-market.  You might find out everything you need is already there.  If you don’t have all these items checked off and overcome, please check out the marketplace of solutions.  Partner with a company that focuses on part of your business where you need immediate value. Without further ado, here is my list of hurdles.

The DIY analytics checklist

1. Your thoughts are too Insular. You’re only thinking about the problems you have. Software vendors have views that could be quite valuable to your enterprise. If you know those views or experiences existed. This is our purpose on Earth, not yours.

2. Data. The data that exists is cumbersome and complex. 40% of EMR data is freeform. That’s only one of the systems. The average hospital runs between 7-30 separate systems. Each has the data you need. Sure, PO data is easy to view. PO data is only part of the picture. There is valuable information in the EMR systems. Don’t overlook that information. That said…humans are involved in data entry. Distracted, imperfect, error-prone humans who fat-finger their entries and do the least amount of entry possible.

3. You think you have a data lake. I have news. It’s a data swamp. Full of errors that will trap you, and pull you under like wooly mammoths in tar pits. What you have is a pile of numbers, letters, and symbols. You had no idea how many ways people can spell, “Stryker”. You can’t call it “data” until you trust it. Got the skills to clean up the swamp?

4. Choice of metrics. There are 405 OR CPT codes and over 10,000 altogether. There are hundreds of HCSPCS codes. Many get added, changed, and revised every year. If you use this as a hierarchy, your historical data is in constant change. It was part number G10X23. Now it’s part number FF235U2 due to an internal change at your vendor that you weren’t privy to. How does your analytical approach handle that?

5. Structured and unstructured data. Normalizing and marrying disparate data in databases is difficult enough. Unstructured data makes it all the more error-prone. It requires database construction and continual modification. As time moves, further changes are necessary. This does not end. Many people trust native data because it is numeric, but don’t realize it is inaccurate, incomplete, or flat-out wrong. When you use insufficient data, you get bad results. Because you see numbers doesn’t mean you should trust them.

6. Skills. Spending time learning tableau, Power BI, or other platforms is admirable. It also prevents you from doing your job. Does Supply Chain want to become a software company?

7. Price. It is always far more expensive in time and money than you think. Changes are constant, new measurements need to take place.

8. Scaling. The data becomes geometric. You’re now storing many copies of your data and paying every month to do it.  

9. Ongoing Maintenance. For every $1.00 you spend building an application, you will spend 25 cents each year maintaining that application. As you grow, so will this maintenance. Soon the maintenance costs more than the initial application. The original value proposition no longer makes sense. Got a big team of all the different people needed to maintain software? Software devs, DB architects, business analysts, PMs, SQEs, UX/UI designers, SMEs, Security devs, Performance devs, Data scientists, Client success people? It takes a village, something you don’t know at the beginning.

10. Versioning/ refactoring/ upgrades. All software deprecates and needs replacement. Sure you use the cloud to handle database updates and OS-level releases. That’s great. But, the command stack will need replacement/ refurbishment. That requires a new skill set you either need to learn or hire out and replace. This moves us into chance control/ change management. How good are you at Agile, CI/CD, DevOps DB architecture, code architecture, multi-tenant enterprise level software dev, security, scalable infrastructure, full stack dev, SQE, data engineering, data science, packaging, advanced analytics ….? Ever heard of these terms before? You’re going to need to know them.

11. Building for a department instead of an enterprise. The use of industry and department-level nomenclature is standard. It also means your application will only be relevant to the subset of people who speak your language. Supply Chain, Finance, and Doctors all understand what they do from a different lens. Building agnostic systems takes a multi-lens understanding. Sometimes that means making the same application three times, now tripling your output. And thus your maintenance.

12. UI/ UX. Building a form factor agnostic application means taking into account different user experiences. This agnosticism can also mean doubling or tripling the required software stack. The more added, the further out the ROI for the effort required.

13. Core competence. You are in the business of healthcare. Our core competence is healthcare analytics. You aren’t ever going to be better than we are at it. You’ll waste a ton of time and money only to get the wrong answer late. Focus on what you’re good at. Outsource the rest to partners.  

14. Poor foundation. The problem: a change request comes in that is too complicated. You finally call in an expert who looks at your monster. The expert says, ‘the only way to do this right is to start again.’ The worst position to be in. The money is gone, now you need to spend 2X to do it again.

I understand why people want to solve their issues before calling in experts. My house is its own DIY project…and at one point I thought I could fix anything. Many expensive failures later, I’ve learned what I can do and when we should bring in outside help. Before your world becomes too unwieldy, see if there is a partner out there who can help. You might be surprised! Either way, good luck.