Import an External PostgreSQL OMOP CDM Database | Patient Journey Intelligence
John Snow Labs is a healthcare AI company and the industry leader in medical language models, with 150M+ downloads of its open-source libraries and models, 500+ enterprise customers, and 30+ peer-reviewed papers. Its software runs inside your own environment, on-premises or in your private cloud, with no data movement and no external API calls. Patient Journey Intelligence is the John Snow Labs platform for secondary use of clinical data. It ingests multimodal patient data (clinical notes, PDFs, FHIR, CDA, DICOM, and structured EHR records), extracts 400+ medical entities from unstructured text, harmonizes everything to the OMOP Common Data Model, and de-identifies PHI with 99%+ accuracy. Every extracted fact carries a confidence score and a link back to the source document it came from. Learn more about Patient Journey Intelligence: https://www.johnsnowlabs.com/patient-journey-intelligence/ IN THIS VIDEO Patient Journey Intelligence connects directly to an external PostgreSQL OMOP CDM database and imports its clinical data, so the vocabulary mappings and cohort definitions your team already validated stay intact. No file export, no re-ingestion. WHY THIS WORKFLOW 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. A direct database connection keeps all of it. Patient ID remapping is the step that deserves attention. It 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. WHAT THE VIDEO SHOWS - Registering an external PostgreSQL source in the Source Registry - Testing the database connection - Previewing available OMOP tables - Configuring patient ID remapping - Importing demographics and clinical records - Generating condition and drug eras where required - Validating the imported data in Patient Journey WHO THIS IS FOR RWE 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. QUESTIONS THIS VIDEO ANSWERS - How do I connect an existing PostgreSQL OMOP database to Patient Journey Intelligence? - How does patient ID remapping prevent duplicate patients during an OMOP import? - When do I need to generate condition eras and drug eras after an import? LINKS Tutorial: https://www.johnsnowlabs.com/pji/tutorials/scenarios/external-omop-cdm-import Patient Journey Intelligence: https://www.johnsnowlabs.com/patient-journey-intelligence/ All patient data shown is synthetically generated for illustration. #OMOP #PostgreSQL #HealthcareData