5 Common Mistakes in Managing Healthcare Data Products

As we embark on another chapter of technology adoption, moving from the Internet of Things (IoT) to web3 and the metaverse, and as a greater degree of interoperability takes hold, data in all things healthcare is no longer a differentiator but a table stake.  As we cover in our research, “Transforming Healthcare: The Changemaker Playbook,” the ongoing healthcare data revolution opens the opportunity to deliver better clinical decisions, faster and more appropriate care delivery and ultimately more equity and context to patient treatment. Everyone by now knows that by using data and managing it the right way, organizations will see costs go down and both clinical and business processes get smarter and more efficient. However, where does data specific to your needs come from?  Who’s generating it, curating it and selling it?   

There is a massive gap emerging in organizations as it relates to managing and extracting value from their data, namely the productization of it. Yes, there are seasoned players in the healthcare data space such as Optum, Merative and IQVIA that have a high degree of maturity as it relates to data-as-a-product.  But there are also new entrants, such as growing physician groups, amassing unique and compelling data sets, as well as device and equipment manufacturers, whose smart products are also accumulating data.   

We are finding that these fringe players in healthcare data are extremely eclectic as it relates to their product management capabilities with data. These organizations are oftentimes shining examples in product development with their core products (e.g. specialty practices, vital signs monitors, claims clearing houses, etc.), but when it comes to data-as-a-product, they are often overlooking a variety of fundamentals. These mistakes are having a dramatic impact on their ability to create value with data. Generally, we are seeing three categories of data products that exist in healthcare:  

3 Categories of Healthcare Data Products

1. DaaS: Data as a Service – When you take raw or transformed data that can be sold or licensed to additional parties
2. Data Resulting From a Feature – By utilizing features of an existing product or service to generate data that may be productized
3. Algorithmic and Logic Based – Where you take data, apply logic and algorithms to it to give outputs or aid in decision making 

The following highlights a set of frequent mistakes to avoid when entering the healthcare data space.  
   

1. Prioritizing “More” Data Instead of Necessary Data 

Date range or depth are often things companies will tote as a major selling point. As you peel this back, we found that customers look for the quality and completeness of the essential data that they need to solve problems they’re working on.  

Focusing on who wants or needs this data, and why, is a critical question to answer when defining the data product. Adding lots of nice-to-have data sets to your product may not create customer value. Sophisticated customers who take the time to examine your data will often try to poke holes or find gaps that will impact their decision to purchase and adopt your product.   

2. Lack of Data Accessibility  

Whether your product is a database, web platform, App or API, thinking through the end-to-end customer journey is often a gap. Data is usually part of a broader workflow that combines multiple systems, tech stacks, integrations and processes.  

As you build your product, it’s crucial to envision the data’s entire journey. Make sure your customers can pull and access the data! Rarely does a customer only use a single data source, so being able to integrate and distribute with their other solutions is essential. Often data may need to be mapped to your customers’ existing data models. A helpful tip is understanding your customer’s personas, and their level of understanding and skills, as they will be the day-to-day people interacting with the data.   

3. Loose Data Governance Practices 

As your product’s data is generated or compiled, it is critical to creating a formal taxonomy (hierarchical grouping which gives structure and standardizes terminology). This allows you to keep track of the attribution (source, rights, ownership) of where the data comes from.  some of the things included in data taxonomy are clear definitions of what data means, whether those terms are generally accepted in your industry and knowledge of how to explain the data. Another critical element to data governance is understanding your meta-data. For example, it is essential to document things like time stamping, user, source, security, segmentation and IP rights. Data in healthcare can be sensitive with regulations and policies affiliated with it so understanding what is classified as HIPAA when data can remain identified or needs to be de-identified needs to be considered.  

There will be a number of team members working around your data (engineers, data scientists, database managers, statisticians, researchers, product managers, etc.), so creating a taxonomy and decision for access rights ensures the integrity of your data is preserved. Continuously auditing change logs and benchmarking data is essential and good hygiene. Furthermore, you need to ensure that this data is protected and that your business model for monetization is secure with accessibility. Whether it be in your technology or contract terms, protect your data’s IP. From the business and legal side of governance, your MSA, EULA and contract language (whatever is applicable to your product) need to clearly spell out ownership, give the right to anonymize, create derivate or redistribute data. Knowing where you are or what you can’t do must be relayed back to the product and technology development process.   

4. Data Analytics and Tools as an Afterthought 

Along with #2, we have found that customers want to generate more insights out of their data. This is often why clients ask for periodic data dumps or direct lines of access to the data. It is an important product decision to determine if and how much you want to invest in analytics and tools that enable your customers to generate more insights on their data.  

The more you understand their needs and what they are doing with the data outside of your product, the more you should consider what would make your product stickier if you built those capabilities in. These can be simple things like filtering, searching, scheduled reports or extracts or dashboards. We often see customers still taking data and using excel or tableau to generate basic insights that can be offered inside your product.   

5. Overly Technical Products Can Deter Adoption 

Knowing your user, their technical abilities and their thresholds should be accounted for in your product development process. User retention will suffer if it takes too long to develop skills and understanding to use your product. This will manifest itself with low user activity, as well as unsatisfied business stakeholders who made an investment in selecting and implementing your product. If you are building products that are technical in nature, be sure to engage that user type/ persona early-on and understand how big that sellable market is. Don’t expect a large population of non-technical people to easily embrace your product. You will get early and stronger usage with intuitive products, short-term implementation cycles and onboarding processes, FAQ/help documents and quality customer support offerings.