Data Vendors are picky.

It's understandable. Most data vendors aren't specifically in the business of licensing or selling data anyway; generally, they're running transaction networks, or repricing concerns or other data services where huge volumes of data stream through their business model, and selling data is simply an additional revenue stream. Some vendors are challenging to work with - very limited data uses are available, and the data is very expensive. Others are more flexible, and can be are more open minded to new, creative uses for their data. The one things they all have in common is that they're very careful regarding how a company can use their data, and part of the engagement process is to build a valid use case.

Brokering

Finding the data your model needs, knowing the vendor - how they work, what data they have, what data they don't have, their accuracy, how they deal with duplicates, with PHI and de-identification, how they deliver data, and what to expect - this is what we do. Hagimo's team has more than 20 years of experience successfully finding, licensing, and managing bulk medical data, both for clients and for our own use in our own service lines. We can find the data you're looking for, and put you in front of the vendors that have it. That's just the beginning of the process, though.

Building a successful Use Case

A use case is simply a description of how you intend to use a vendor's data. It's an easy concept to understand, but building a successful use case that accurately reflects your model without giving away your secret sauce, and that meets the requirements of the vendor can be a challenge, and getting it wrong can be costly. As a rule, enterprise data vendors generally won't give you another chance to file a use case. This is because companies have a long history of simply adjusting their use cases to fit the requirements of the data vendor, and then they go ahead and use the data as they originally intended. Data vendors are very aware of this, often keeping quiet about the types of use cases they will approve, in addition to limiting the number of chances you have to file one.

A good use case will include the following considerations:

1. It will accurately describe your intended business model safeguarding your proprietary processes that you've developed that will give you an edge in the marketplace.
2. It will conform to the (often unspoken) data usage requirements of the vendor.
3. It will make financial sense to both sides.

Here's an example of a use case that was not approved:

UseCaseExample_Fail.pdf

This example was rejected not because it was a bad idea (it wasn't, and we later got it approved) - it was rejected because the client didn't know that the data vendor's primary data source was transactions directly sourced from medical providers at hospitals and clinics, and the model describes a process where diagnoses and procedures were going to be dictated to the medical providers, which might alienate them.

Here's an example of a use case that was approved:

UseCaseExample_Pass.pdf

This example was submitted to the same vendor, and was approved - it doesn't have any processes that might cast medical providers in a bad light, nor does it affect their workflow in any way. Rather, it scrutinizes payers and third-party administrators, who are often responsible for excessive spend across self-funded health plans.

The data you need.

You need to know the vendors who have what you're looking for - all data vendors are not the same, and they're not licensing the same data. You need to know their culture, their structure, and what models they've approved so you can build a compelling use case that will be approved - the first time. And you'll need to know the answers they want to hear to questions about security, data management, revenue models, potential sharing, data updates and subscription models and more.

Don't get lost in the shuffle. We can help.