Connect an existing OMOP CDM database
Connect directly to an external PostgreSQL OMOP CDM database and import its clinical data, so the vocabulary mappings and cohort definitions your team already validated stay intact. No file export, no re-ingestion.
Import an External PostgreSQL OMOP CDM Database
Who this is for
Real-world evidence and data science teams that already maintain an OMOP CDM repository, including OHDSI network sites, and want Patient Journey Intelligence workflows on top of it without rebuilding the warehouse.
Why it matters
A team that has spent years building an OMOP CDM owns more than a database. Its vocabulary mappings have been reviewed, its cohort definitions have been published and reused, and its analysts know the schema well enough to write against it without looking things up.
What that CDM does not hold is anything the source systems never structured: recurrence dates, performance status, biomarker results. Those live in notes, and getting them means running document workflows over the same patients.
Exporting files and re-ingesting them elsewhere gives up the mapping decisions the team already validated and asks their analysts to re-verify cohorts they already trust.
What you gain
A direct database connection instead of a file transfer. Your existing vocabulary mappings and analyst SQL survive. ID remapping reconciles external patient identifiers against local records before the import lands, which is what keeps the same patient from appearing twice under two identifier schemes and quietly doubling a denominator.
Before you start
- The external PostgreSQL OMOP database reachable from the Patient Journey Intelligence deployment environment, with network paths and firewall rules confirmed
- Read permissions on the OMOP schemas and tables to be imported
- A patient ID remapping plan reviewed before execution. Getting this wrong creates duplicate patients that are expensive to unwind after downstream cohorts are built on them
Step 1: Register the external OMOP source
- In the left navigation, go to Data Integration > Source Registry or the configured ingestion source setup page.
- Create a new database source.
- Select PostgreSQL Connection as the source type.
- Enter the connection details for the external OMOP CDM database.
- Confirm that the source database contains the required OMOP CDM schemas and tables.
Step 2: Test the connection and preview OMOP tables
- Run the connection test before starting ingestion.
- Confirm that the database is reachable from the Patient Journey Intelligence deployment.
- Preview which OMOP tables will be imported.
- Review patient, demographic, condition, drug, procedure, observation, visit, and era-related tables where available.
- Resolve connection, permission, schema, or table-visibility issues before continuing.
Step 3: Configure patient ID remapping
- Review how patient identifiers from the external OMOP database map to existing Patient Journey records.
- Enable auto-remap when imported patient IDs should be reconciled with local target identifiers.
- Confirm that ID remapping will not overwrite or duplicate existing patient records.
- Review any unmatched, duplicate, or ambiguous patient mappings before import.
Step 4: Import OMOP demographics and clinical data
- Select the OMOP domains that should be imported.
- Import demographics and clinical data into the Patient Journey Gold OMOP database.
- Monitor import progress, validation messages, skipped records, and failed rows.
- Confirm that imported records are merged safely with existing patient data.
Step 5: Generate condition and drug eras where needed
- Decide whether condition and drug eras should be generated during processing.
- Enable era generation if optimized longitudinal condition or medication timelines are needed.
- Review generated condition and drug eras after processing completes.
- Validate that eras align with imported source records and expected OMOP logic.
Step 6: Validate the imported Patient Journey
- Open imported patients in Patient Journey.
- Review demographics, visits, conditions, medications, observations, procedures, and eras.
- Use Database Explorer to confirm that imported OMOP records are queryable.
- Build a small cohort from imported facts to validate downstream usability.
- Confirm that imported data is available for Patient Journey, Cohort Builder, Database Explorer, and other OMOP-backed workflows.
Edge cases / limitations
- The external database must be reachable from the deployment environment.
- Database permissions must allow reading the required OMOP schemas and tables.
- Patient ID remapping should be reviewed carefully to avoid duplicate or incorrectly merged records.
- OMOP version, vocabulary alignment, and local extensions may affect import completeness.
- Era generation should be validated when source era tables are missing or regenerated during processing.
Related pages
Ingest FHIR R4 into OMOP CDM, with or without NLP for ingesting FHIR bundles into OMOP CDM.