| OHDSI Home | Forums | Wiki | Github |
Hi all,
I am in the process of writing a Manual of Operation(MOP) of Samsung Medical Center’s CDM. I am trying to write as much information as possible, such as a description of the data source, CDM building process, management of database and ATLAS, and I would like to try this more systematically.
If you have experience writing a MOP, can you please share your story? or If you know any sample MOP of CDM, please let me know. Thank you in advance.
Hi @minakim,
I just started writing an end user manual for the University of Colorado. My target audience are researchers/investigators that will be using the CDM. I started last week, so I have a general outline and a bunch of notes. I am basing my document on the OMOP conventions. And I plan to add information on how the source EHR differs from the CDM, what data are not in the CDM, what data are in the CDM, information regarding conventions that are specific for our instance of the CDM, Atlas for cohort building, and Athena for ease of navigation through the vocabularies.
Since I just started this process, I would appreciate any guidance from anyone else that is attempting, has attempted, or has completed this task. I’m particularly interested in academic institutions that have “customized” the CDM for researchers with a healthcare provider or healthcare research background, but welcome all feedback!
Rather than using OMOP Conventions as a starting point, I suggest using a document that describes the ETL process from the source to OMOP. The assumption is that most of your audience will already be familiar with the source data and an explanation of where and how data they are used to using has been moved into OMOP will make it easier for them to understand the OMOP data model. Good examples of source to OMOP documents are in the OHDSI ETL-CDMBuilder github repository.
Good point, @DTorok! The approach definitely depends on the audience.
At Colorado, < 5% of our requestors have any knowledge about Caboodle or Clarity. Many come to us with with ICD code lists, “ideas”, or screenshots from the UI of the data they seek. Educating our requestors on Epic and then OMOP would be prohibitively time consuming and isn’t necessary. I’m taking the interface to OMOP approach.
For users that are already pulling data from the backend of the EHR, field mappings from source to target would be a better starting point.