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 | 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.
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.