User Tools

Site Tools


OHDSI Architecture Roadmap

The OHDSI Archiecture's current state is represented by Version 2. Future versions are proposed technology roadmaps. Version 3 is a draft architecture roadmap that is open for public comment. Please direct feedback to or

Feature / Functionality Mature / Current Implementation Vision / Under Consideration
Search SQL based string search Lucene / SOLR
CDM Database Support SQL Server, PostgreSQL, Redshift, Microsoft Parallel Datawarehouse, Oracle SQL Server, PostgreSQL, Redshift, Microsoft Parallel Datawarehouse, Oracle, Impala / Hadoop, Google BigQuery
OHDSI Schema Storage Relational - SQL Server, PostgreSQL, Oracle Document / Relational - PostgreSQL, MongoDb
Visualization Framework d3, custom visualization libraries d3, vega, custom visualizations
Deployment Strategy custom build with maven, java, database inserts docker, docker-compose
Web Framework HTML5, javascript, knockout HTML5, javascript, react / redux
Web API monolithic java API microservices enabled through secure API layer
Web Package Management n/a npm / yarn
Analytics R R, Python
Evidence Repository per CDM per CDM, OHDSI shared
Analysis Clients ATLAS, R ATLAS, R, Shiny, Jupyter, VocabViz
Environment Configuration docker-compose, yaml, .env


In this section we provide our thinking on why each of these component trajectories make sense for the OHDSI architecture.

Our current search implementation is a simple SQL LIKE statement. Given our requirement to support multiple database platforms this restricts our ability to leverage full text index or other search capabilities that have different implementations or restrictions in each relational database engine. Moving to SOLR would allow us to establish SOLR cores for each version of the vocabulary that could be shared in the community. The performance of SOLR compared to our current search is 100x faster. Leveraging SOLR will also provide us with more robust search capabilities including similarity search, proximity search and graph search.

Hybrid Document / Relational OHDSI Schema

The OHDSI schema is where we store the metadata and specifications that our tools create. An example of a specification would be either a concept set or a cohort definition. The default editor for these tools is ATLAS which leverages the WebAPI to load and save specifications. The version 2 component for the OHDSI schema is a pure relational database where we support multiple relational providers including postgresql, oracle and sql server. This means that when the JSON specification is saved we either save it as a text field or sometimes deal with mapping properties of the object into a relational table structure. The relational mapping of JSON formatted objects can be cumbersome. Use of a document based data store technology such as MongoDb would provide a simpler mechanism for storing/retrieving these specifications.

development/roadmap.txt · Last modified: 2017/07/27 17:49 by frank_defalco