ohdsi / thebookofohdsi Goto Github PK

the ETL chapter may discuss some relevant METADATA that should be created.

e.g., the CDM_SOURCE table
what version of vocab was used
short name for the dataset
how many patients were deleted (missing year of birth)

In the line 432 of PatientLevelPrediction chapter,

• Measurement: Construct covariates for each measurement concept ID and time interval selected and if a patient has the concept ID recorded during the specified time interval prior to the cohort start date in the measurement table, the covariate value is 1, otherwise 0.
• Measurement Value: Construct covariates for each measurement concept ID with a value and time interval selected and if a patient has the concept ID recorded during the specified time interval prior to the cohort start date in the measurement table, the covariate value is the measurement value, otherwise 0.

To my knowledge, the measurement value is 'continuous value' not a binary value. How do you think @PRijnbeek @jreps @schuemie ?

https://forums.ohdsi.org/t/questions-about-book-exercises-ch-4-and-5/13676

Chapter 5, exercise 5.3.
Meddra shouldn't be a part of the excercise as it's linence restricted vocabulary

The patient-level prediction chapter draft currently doesn't have any exercises . Do we think chapters should have those, for example to be used in classroom settings?

@PRijnbeek ?

"Lauren's story" link in section 4.3.1 now just redirects to the main Endometriosis UK front page. Seems it's no longer anywhere on their website.

For the mono-therapy query in the cohort query, this is using the drug_exposure table rather than the drug_era table. The problem with using the drug exposure table directly is that it will exclude individuals who happen to have 2 records that provide exact same drug. It seems like this would need to be collapsed, and that's what the drug_era table does. The generated SQL uses the drug_era table when computing this particular condition.

We've decided to rename the Methods Library, and this is referenced throughout the book.

I suggest to add json files (or link to json files) to help with the ATLAS examples (cohorts, characterization, pathways, incidence and more).
In the current status, if I want to reproduce the pathway analysis examples of first line treatment for hypertension that is given in the book (Chapter 11.9), I need to define many concept sets and cohorts. Or I need to look for one that was created in the ATLAS-demo and make sure that it corresponds the description which is not a trivial task.

I would like to contribute, but I'm not sure what would be the best option. I thought of severals:

1. Link to (or give the id of) the example in ATLAS-demo. The limitation - If someone change the example on the web if it is not locked.
2. Create a json file and add as plain text to the book of OHDSI
3. Create a json file and put a link in the Book. Q: Where to store the link? Under books's files (e.g. extras folder) or external location (personal repo?).
4. Create a script that load a json file to the ATLAS using WebAPI. Limitation - I'm not sure if it's fully implemented for characterization, PLP etc., or it is only support cohort and concept sets upload.

Any suggestions?

Am using Safari. Does this happen on other systems?

It would be super cool to have a platform, where book readers can annotate book sections with

1. comments
2. questions that arise

That would allow improving the books.
They can file an issue in github but that is a lot of steps.

Or, OK, use github for it but have tags for each chapter or chapter section so that they are easy to find when refresh of chapter is being authored.

I am unsure how to fix this issue. Maybe @schuemie or @PRijnbeek have some ideas?

The index is created by xelatex. Perhaps related to issue #24

Currently some citations in PatientLevelPrediction.Rmd have DOIs and many do not (although DOIs exist for these papers).

What should be our standard across chapters?

http://howoften.org is redirected to http://www.ohdsi.org/web/howoften/

config: Object { method: "GET", jsonpCallbackParam: "callback", url: "/seir_api/drug_list", … } ​data: "<html><body><h1>504 Gateway Time-out</h1>\nThe server didn't respond in time.\n</body></html>\n\n" ​headers: function xd(d) ​status: 504 ​statusText: "Gateway Time-out" ​xhrStatus: "complete" seir.js:18621:29

Hello. I was just scanning the chapter on SQL and was looking at 10.7.1 Exposure cohort. There are two discrepancies.

First, the text below says We take the first drug exposure per person but in fact, the SQL does not do exactly this -- it constructs a synthetic structure having the minimal begin and minimal dates for the given person that match the concept criteria. Now, this might be a case if exposures do not intersect.

Second, the SQL here doesn't do what the corresponding auto-generated SQL does. The auto-generated SQL for drug exposure criteria handles the possibility of a NULL end-date,
COALESCE(C.drug_exposure_end_date, (C.drug_exposure_start_date + 1*INTERVAL'1 day')), it also has slightly different logic, it ensures the end_date is within the observation period. This may not be relevant.

@schuemie

In the chapter 12. PLE, the example shows the conditioned Cox regression after PS matching
(PS matching in Figure 12.14 and Conditioned Cox regression in Fig 12.15)
Wouldn't it better to show 'Unconditioned Cox regression after PS matching' or 'Conditioned Cox regression after PS stratification'?

I know current ATLAS doesn't support 'unconditioned Cox regression' setting (I don't know the reason why I cannot set 'unconditioned Cox' in current ATLAS)

In the Figure 5.6, the caption denotes that "Atrial fibrillation" is the main concept to be illustrate. However, "Atrial fibrillation" is denoted as [Descendant] and "Fibrillation" as [Concepts] in the figure.

To fix it,
Concepts to Atrial fibrillation; Descendant to Controlled atrial fibrillation ...

For the exposure cohort consider using drug_era rather than occurrence? I suggest this since a bulk of this query is focused on normalizing for overlapping medications, which is something that drug_era does already (it is some sort of calculated table, no?). In particular, even as written, with overlapping drug_exposures, this query is now going to grab which ever end_date happens to be first...

In book it says 1.6.6 while in Achilles repo the latest is 1.6.3

We are planning to add a chapter on NLP to the book of OHDSI. This is to start a discussion to know your thoughts in general, and comments on the content and specific topics to include.
[Posted on behalf of Hua Xu - OHDSI NLP WG lead]

Hypothes.is can add interactivity to a book created with Rmarkdown. Readers would be able to ask questions, suggest edits, and make comments all in their web browser.

Here are examples of Rmarkdown books that uses hypothesis.is:

• https://www.crumplab.com/ResearchMethods/
• https://jrnold.github.io/r4ds-exercise-solutions/

Here is some documentation about how to add this to a book: https://www.crumplab.com/OER_bookdown/hypothes-is-1.html

This functionality might make it easier for more people in the community who are not familiar with Github and Rmarkdown to comment and suggest edits or highlight places for clarification.

Hi

OHDSI newbie here. I am reading the doc and think there might be a mistake in table 4.6:

Unless I got everything wrong, shouldn't it be ADMITTED_FROM_ SOURCE_VALUE instead of CONCEPT_ID ?

Also I spotted this possible mistake because the example mixes "NULL" and "0" for fields that are supposed to be ID's. Is there a reason why the value given in the examples is sometimes NULL and sometimes 0 ?

thanks
Thomas

treatment patway has a great short video

here
https://www.youtube.com/watch?v=rdniIztguys

idea: link relevant short videos (by nice icon)
right after a subchapter heading

The Data Quality Dashboard has matured, and we’re about to launch the CohortDiagnostics package, which I’d like to describe here.

@clairblacketer , what do you think?

In fig 5.6, Fibrillation is represented as a child of Supraventricular arrhythmia

But, when you search for Fibrillation in ATLAS, you can find it is not.

Figure 4.1: CDM version 6.0:

With information about the new ohdsi-studies organization and app.

Add a chapter on Broadsea, to help new sites understand best practices around setting up OHDSI tool stack.

for example how to translate contents into chinese ,spanish?
is the best practise to fork another repo?
since the content is continuing to change

Hi all,

Was recently helping someone on the OHDSI forums with a question on Chapter 9.
Although Eunomia is mentioned later at the end of the chapter, for beginners, Eunomia should be mentioned earlier and leveraged in the examples throughout the chapter in my opinion.
What do you all think?

For example the "The cohort method design" section in the PLE chapter

The first sentence of the "CONDITION_STATUS_ CONCEPT_ID" description is incomplete : "If known, the this tells the circumstance and . "

add example from
https://github.com/cukarthik/IUDEstimationStudy/blob/master/R/AdditionalAnalysis.R#L27

Right now, we have a chapter about Usagi. That needs to be complemented with specific mapping processes we developed. Maybe like this:

Mapping and QA of codes to Standard Concepts

• Mapping codes locally versus through the OHDSI Standard Vocabularies
• Usagi
• Systematic mapping of Drug codes
• Systematic mapping of Condition codes
• Systematic mapping of Procedure codes
• Systematic mapping of other codes

Thoughts

There is an error of caption about Table B.5.

The title of the caption should be 'Acute myocardial Infarction'.

Thanks.

Just a couple of minor edits and suggestions as I read through the PLE chapter:

• Sub-chapters 13.3 and 13.4 should be titled 'Implementing....' or 'Implementation of.....'not just 'Implementation.....'

• I would be inclined to make the descriptive section (section 13.1) on propensity scores a sub-chapter (but beware that 13.4.4 is already a sub-header for propensity scores)

• Having been part of the PLE workgroup at the OHDSI F2F, I can honestly say that it was a great experience being part of this collaboration. Great use of the screenshots especially the little icons - they really help the viewer navigate through their cohort.

In the cohort exit section it talks about "magic". While the SQL's implementation may be magical and need not be further discussed, the exact logical algorithm that this query implements is not documented. This is quite important to understanding what it means to generate an exit cohort in OHDSI. The algorithm could be discussed informally, but it should express what considerations and/or cases are accounted for.

Consider refactoring this code so that previous queries populate a temporary cohort era table, with subject, begin/end. Then, a separate SQL fragment that might be more digestible could be written that collapses these eras. Doing both the era extraction and the collapse at the same time make the logic hard to follow. If these two operations were separated, perhaps both could be more easily explained.

In the CDM workgroup the convention has changed: field names now must be written in UPPER CASE. We want to be consistent in the book, but so far we've followed the old convention.

The figure lists "False Negative" in the upper right-hand square when it should list "False Positive"

https://forums.ohdsi.org/t/questions-about-book-exercises-ch-4-and-5/13676

There are still an old Type concepts, while we got a new set of Type concepts after their refactoring.
So these should be replaced