Sidebar
This is an old revision of the document!
Table of Contents
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 fdefalco@ohdsi.org or fdefalco@its.jnj.com.
| Feature / Functionality | Version 2 Component | Version 3 Component |
|---|---|---|
| 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 |
| 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 |
| 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 |
Rationale
In this section we provide our thinking on why each of these component trajectories make sense for the OHDSI architecture.
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.
