This is an old revision of the document!
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 |
In this section we provide our thinking on why each of these component trajectories make sense for the OHDSI architecture.
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. While the default editor for these tools is ATLAS the serialization of these specifications is in JSON format.