OHDSI / WebAPI

OHDSI WebAPI contains all OHDSI services that can be called from OHDSI applications
Apache License 2.0
126 stars 156 forks source link

Application usage statistics #2329

Open alex-odysseus opened 6 months ago

alex-odysseus commented 6 months ago

Business requirements

There should be a way to know which application functionality is used frequently by users so that any future feature enhancements can be additionally supplemented with some raw data of actual application usage in the relevant areas

Answering to the following questions is essential:

Design Ideas and Functional Requirements

As the Audit Trail (https://github.com/OHDSI/WebAPI/pull/1913) contains the most comprehensive data entries of by whom/when/which endpoints have been invoked the newly designed endpoints will rely on those

The first endpoint will be tailored to the particular functionality - Analysis Execution (including Cohorts) on Data Sources The second endpoint will be more common and may receive an arbitrary list of analyzed endpoints of interest with a notion of placeholders

By default both endpoints will be available for the administrators only (additionally can be administered by assigning the corresponding permissions to a desired user role) and should have a possibility to provide the results both in JSON and CSV formats for its easy processing by the client applications. As user identifiers are usually treated as personal identifiable information (PII) there should be a possibility to exclude their propagation to the results

@mrechkem @Sathyaraos

anthonysena commented 4 months ago

Raising a few questions with this requested feature:

Answering to the following questions is essential:

  1. how often a user performs an Analysis Execution on a particular Data Source
  2. what are trends of a user accessing a particular application functionality

For 1 above, can't we obtain this from the jobs table(s) in the WebAPI database? Any analysis that runs is captured in this table and should include the data source.

For 2 above, can this live outside of the ATLAS DB? Since the audit log trail produces .txt files with this info, wouldn't a simple log parser suffice? Is this really necessary to surface in the the application?