Hello OpenELIS community,
I would like to introduce OMOP Bridge, a platform we are developing to help harmonise clinical data from different health information systems into the OMOP Common Data Model (CDM). OMOP Bridge supports AI-assisted concept mapping, transformation, and human review to help make clinical data ready for standardised research and analytics.
We are currently in the validation-testing phase of OMOP Bridge and would like to include OpenELIS Global as one of the systems we validate against.
We have successfully set up a Dockerized OpenELIS Global instance, but the database is currently empty. We are therefore looking for a sample SQL database dump or de-identified OpenELIS dataset that we can load into our test environment.
Having a realistic dataset would allow us to test the complete workflow:
OpenELIS Global → OMOP Bridge → OMOP CDM
We would particularly like to evaluate laboratory test/result extraction, terminology mapping, data transformation, and overall data quality.
If anyone in the community can provide a suitable de-identified sample database/dataset, or point us to an existing OpenELIS dataset that can be used for this type of validation, we would greatly appreciate your guidance.
Thank you, and we look forward to collaborating with the OpenELIS community.
@caseyi @Jan_Flowers @Moses_Mutesasira
1 Like
@abertnamanya How about if we use the FHIR API instead of direct DB access, this looks better to build on, our fhir server can expose standardised resources that map naturally to OMOP CDM and is the main way we are using to support interoperability of late.
- we can also think about creating some data using the OE demo as another work around, OpenELIS ships with Liquibase-managed seed data. Once your Docker instance is running, you can populate it by going through the UI and creating a few test patients, orders, and results. The test fixtures in the integration test suite (
src/test/resources/testdata/) also show the exact schema structure if you want to craft SQL inserts. 
Thank you @Agaba_Derrick_Junior That is true. OpenELIS already exposes FHIR resources, and we already have FHIR integration implemented as one of the approaches supported by OMOP Bridge.
However, since the FHIR resources are already standardised and expose structured resources, one of the key scenarios we would also like to validate is direct database integration. This is a different and more complex use case, as it requires OMOP Bridge to work directly with the source database schema, identify the relevant tables, perform the necessary joins, and map local source concepts to OMOP standard concepts.
Testing this approach will help us evaluate how well OMOP Bridge performs when working directly with data from an operational system, where the underlying database structure and local concepts require additional transformation and mapping before the data can be represented in the OMOP CDM.
Thanks @abertnamanya for clarifying. While the FHIR API is the preferred interoperability approach in OpenELIS Global and is well suited to OMOP integration, validating the direct-database approach is also a useful use case.
Whether an anonymised production database dump can be shared depends on the data-governance policies and approvals of the specific laboratory or implementation site. In the meantime, synthetic datasets can be used to support this validation and should be sufficient for testing the end-to-end workflow.
A useful synthetic dataset should include representative laboratory workflows: patient registration, orders, specimens, test catalogues, results, units, reference ranges, and both coded and free-text observations. This would allow OMOP Bridge to evaluate the database-level extraction, joins, terminology mapping, transformation, and data-quality checks required before data can be represented in the OMOP CDM.
It would be helpful to share the OpenELIS Global version you are using and the laboratory workflows you would like to validate. We can then help identify the relevant data structures and mapping considerations, particularly around local test catalogues, LOINC/SNOMED CT mappings, units, and result interpretations.
Thank you @Moses_Mutesasira
Below is the OpenElis version that I am working with.
Yes, this is exactly the type of workflow dataset we are looking for. It includes patient registration, orders, specimens, test catalogues, results, units, reference ranges, and both coded and free-text observations, as you mentioned above.
