OHDSI Home | Forums | Wiki | Github

Specifying OMOP queries / optimizing query development time

#1

We are starting the process of moving our production data warehouse query/data delivery activities to OMOP and wanted to get tips/tricks/worksheets/intake forms that more established groups have developed that accelerates responsiveness to query requests. Unlike some others, our requestors want raw data, not processed evidence.

For those in similar circumstances:

  • Do you have a query request/specification intake form that helps get to the cohort and data elements quickly?
  • Have you developed any “library” or “views” that enables you to respond to data requests more quickly than always starting with the the raw OMOP model every time?
  • What other practices have you developed that allows your team to more quickly respond to data requests?

Thanks for sharing whatever you have learned about creating an efficient way to deliver OMOP-based data requests.

#2

I welcome others from Columbia to correct me, but bottom line is that we have an intake form that goes to a committee that approves all data requests. This is after the IRB. The form covers all possible requests for all systems, so it is not specific to EHR or claims data and does not have separate fields to check off (condition, drug, etc.). So pretty much narrative once you get to the field level. That gets reviewed and the request gets forwarded to the group who processes it. They would then read the request, perhaps get more information from the requestor, and run SQL against the database to gather the data and send it to the requestor. The group might be the central group or might be a department-specific data navigator who dotted-line reports up to the central group. The support of data navigators allows departments to invest in their own observational research without having to send money outside the department. The SQL becomes second nature to the analysts, so it is not clear that a tool would help them much.

#4

Don’t move it off the forum! This is actually quite an important
discussion thread, and I hope more people chime in so we can all learn from
each other’s experiences.

Even though it may be a little less relevant, I’ll make sure my Janssen
team provides our experience and perspective as well…

#5

The following is my understanding, which may be flawed. They are paid by their department and sit in their department. The latter is important because they need to be near their customers. They are trained by the central group and dotted line report up to them. In fact, many or most of them used to work in the central group. They participate in regular frequent in-person central meetings about privacy, security, and operations. They have access to the full identified database, plus additional department-specific data. Their queries are overseen by the central query permission committee. Everything reports up to the same dean, so if there is ever an incident, HR can take action without conflict. Basically, they are viewed as part of the core team that manages the institutional data. This is a mechanism to allocate the cost and to have them physically located near their customers.

t