OHDSI Home | Forums | Wiki | Github

New WG - Book of OHDSI


(Seng Chan You) #21

We can translate English book into Korean. :wink:


(Christian Reich) #22

I’d say the former, with some references to the latter. This is to enable the community. Not to teach a college class.


(Roger Carlson) #23

In that case, I’ve got a few suggestions:

  1. The Purpose of OMOP, with particular emphasis on the “observational” part. Or as Christian said in another thread:

    We are doing observational research, not running an insurance company or hospital.

  2. The implications of #1, i.e.

    • Data doesn’t have to be perfect to be useful

    • Although you should try to remove as many as possible, duplicate records are not the end of the world.

    • Fine distinctions of gender, race, and ethnicity are not useful.

    • Positive data vs. Negative data

  3. Discuss the differences between _concept_id, _source_concept_id, and _source_value. I know there are sentences in each of the domain table specifications, but it’s confusing and could be expanded with examples from several different domains. Also discuss the purpose of each of these and when it is okay to leave it unknown (eg. zero).

  4. Discuss each of the domains (measurement, drug_exposure, observation, device_exposure, etc.) with particular emphasis on the implications and purpose of each. Again, the paragraph for each in the OMOP spec is not nearly enough. For instance:

    • When is something a measurement and when is it an observation? Or procedure vs. observation. And how might each be used in a study? Sometimes knowing how it will be used makes it easier to understand.

    • What is a device? What devices are important? How might device information be used for research? I a blood pressure cuff a device? Is sunscreen?

    • What’s the difference between a drug_exposure and a drug_era? Observation and Observation_period?

    • What’s the difference between a note_type and a note_class?

I’m fairly new to OHDSI and OMOP. These are issues I’ve struggled finding answers for, and I see similar questions on the forums.


(Roger Carlson) #24

Hi Christian,

I guess my use of textbook vs. trade-press was more of a metaphor for intent and style. We obviously want to enable the community, but the community is made up a lot of different roles. What I have seen of the outline so far seems directed to higher level approaches like management, architects, and yes, academics, and less geared toward in-the-weeds developers.

For instance, Measurement seems fairly straight forward. I know lab tests are measurements. I also know that vitals are measurements. However, as a developer, I need to find these in different places in my source database. But what other measurements might I be missing? Are there measurements for oncology or transplants (for instance) that may be low volume but important for research? I don’t know, but it’s my job to find them. That being the case, the definition of a measurement, how it might be used in research studies, and some illustrative examples, take on added importance.

Perhaps a better example is device.

  • Epic’s definition of a device is something that records a measurement, like a blood pressure cuff. Is that an important device for OMOP? I’m guessing not.

  • There are NDC codes in the device domain (a lot of them are sunscreens). Are those important? Possibly.

  • It turns out blood and blood products are also devices (biological), so I am inferring the device (blood) by the procedure (transfusion). Are there other such devices which I can infer? Highly likely.

Without a deeper understanding of what a device is, I’ve got little chance of finding all the devices I need to find.

So my suggestions in the other post are requests for additional details, examples, and just plain advice, for how to develop an OMOP structured database.


(Mui Van Zandt) #25

Count me in. As Qiongwang stated, we are talking to a university in China about creating a class regarding RWE analytics and want to include OHDSI and OMOP into the curriculum so this would be a great way to help with that.


(Martijn Schuemie) #26

Thanks all for your great input. Tomorrow we’ll have our first workgroup meeting. Here’s a draft agenda (we can change at the time of the meeting if there are other ideas):

  • What type of book should it be? Text book? Trade book? Who is the intended audience?
  • What (roughly) topics do we want to cover?
  • To @Andrew’s point: how do we want to organize that content?
  • How do we want to divide the work?
  • What should be the title of the book? (‘Book of OHDSI’ is just a working title)

(Martijn Schuemie) #27

The meeting details can be found in this new forum thread.


(Andrew Williams) #28

Here is a link to the web resource that brings together a fairly comprehensive set of resources and guidance on best practices for CER: https://docs.google.com/presentation/d/1LE2DttKDhS7-bzVFHWsClK4dFLF0bcuosXnv2kuRM-0/edit#slide=id.p
It is worth knowing about in general because it is a thoughtful attempt at a more or less impossible goal.

Here is a less ambitious but very useful living textbook chapter on phenotyping: http://rethinkingclinicaltrials.org/resources/ehr-phenotyping/

I’m sure there are other relevant examples that aren’t on the top of my head.

With respect to the Book of OHDSI these cover or link to material that complements OHDSI-specific best practices. Chapters in TBoO, might seek out similar existing efforts to leverage in the appropriate area.

One value of including links to lots of existing material that covers agreed upon best practices might be to enable chapters to focus more on OHDSI-specific methods, conventions, tools etc. This could be useful because the OHDSI approach will often have roots in a larger literature that will be challenging to cover in sufficient depth. The proper execution of studies is challenging. Misuse of good tools may be common because of a lack of understanding of assumptions and rationales. From that perspective, the more guidance we give people on how to do things and why to do them a specific way, the better.

A potential downside is that the field of observational research on large data sources is advancing rapidly. Links to non-OHDSI material that becomes outdated will require additional ongoing effort to remain up to date.


(Martijn Schuemie) #29

I’ve created a workgroup Wiki page here.


(Andrew Williams) #30

If you (@schuemie and @David_Madigan) are looking for a Greek name for the WG, I offer kybernētēs which meant steersman in ancient Greek - i.e. the person who steered the ship. That fits with the idea of the book being a guide. It is also the origin of the modern word cybernetics, which is cool.


(Christian Reich) #31

@roger.carlson: Head on. You just laid out one chapter of the Book of OHDSI.


(Martijn Schuemie) #32

Great news everyone! @msuchard has set up TheBookOfOhdsi GitHub repo and has set up the whole bookdown apparatus. Any changes that are pushed to the repo are automatically pushed to book.ohdsi.org.

As promised, I’ll give an overview of how to use it at the next workgroup meeting (December 11).

Cheers,
Martijn


(Don O'Hara) #33

Would like to help on this WG - Don


(David Madigan) #34

Reminder - no Book of OHDSI call this week. Next call 11am Eastern, December 11th.


(Hamed Abedtash) #35

@David_Madigan Hi, ATC WG would also like to contribute to the OHDSI Book. We are preparing a “Cook Book” for the new drug-source-code to ATC crosswalks that provides the conventions and methods to do the mapping correctly.

Hamed


(Melanie Philofsky) #36

@David_Madigan,

The nuances of EHR data need to be exposed in a centralized repository. More standardization and lower hurdles! Count me in :slight_smile:


(Rae Woong Park) #37

Repeated question what I’ve asked hundreds times was the differences between CDMs including OMOP, Sentinel, PCORnet, STDM, i2b2 and HL7.
It would be great if the “The Common Data Model” chapter deals the philosophy, ecosystem, strength, weakness etc. of each model.
One good paper on that is " Evaluating common data models for use with a longitudinal community registry":


(Martijn Schuemie) #38

Just to remind everyone that next week we’ll have a book WG meeting on Tuesday. Last week we decided that we’d discuss the following:

  • @schuemie will show how the bookdown system works, how to write markdown for the book.
  • A review and discussion of the outlines created for 3 chapters:

To see the details for joining the meeting, or read the notes of the last meeting, see the Workgroup Wiki.


(Martijn Schuemie) #39

The notes, slides, and recording of yesterday’s meeting are available in the workgroup wiki.


t