OHDSI

A survey of existing tools and approaches for de-identifying OMOP data. Why De-identification Matters De-identification is the process of removing or transforming data elements that could identify individuals. In healthcare, this typically means addressing the 18 identifiers specified under HIPAA’s Safe Harbor provision, or demonstrating through Expert Determination that re-identification risk is “very small.” The practical payoff: properly de-identified data is no longer considered PHI under HIPAA. That means: ...

Repository: github.com/srodriguezloya/omop-development-environment Introduction In my previous post, I covered the OHDSI ecosystem explaining what each tool does, when you need it, and how the components work together. That guide focused on understanding the architecture and making informed deployment decisions for production environments. This post tackles a different but equally important challenge: how do you actually learn and experiment with the OHDSI stack without breaking the bank? The OHDSI community provides an excellent quick-start solution called OHDSI-in-a-Box, designed for rapid deployment on AWS. It’s purpose-built for personal learning and training environments—you can have a complete OHDSI stack running in minutes. ...

Introduction If you’re implementing OMOP CDM for your organization, you’ve likely asked: Do we need to deploy the full OHDSI stack, or just transform our data to OMOP CDM? The OMOP Common Data Model is a data standard—a specification for how to structure observational healthcare data. The OHDSI stack (Achilles, Data Quality Dashboard, WebAPI, Atlas, ARES) consists of tools built to work with that standardized data. Understanding what each tool provides helps you decide which ones your use case requires. ...