Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Differences in mimic-iv definition #46

Closed
wants to merge 1 commit into from

Conversation

mlondschien
Copy link
Contributor

Thanks @dplecko for adding mimic-iv and adding sicdb.

See below for the diff between my definition of mimic-iv 2.2 and yours. In particular

  • I have included some more variables, including caregiver_id, admit_provider_id, order_provider_id, formulary_drug_cd, and provider_id. Any reasons you excluded those? They are relevant for me (and the only reason I updated to 2.2 in the first place).
  • I am getting the caregiver from the icu directory. See https://mimic.mit.edu/docs/iv/modules/icu/caregiver/.

@dplecko
Copy link
Member

dplecko commented Mar 7, 2024

Thanks @mlondschien. These are indeed mistakes on my side.

In the current setup of ricu, we use the R files in inst/extdata/config/ to generate the concept dictionaries and the data sources specification. Even though it duplicates information, I am hoping that soon we will be moving into a source-specific setup for the configs, and then having the R files will be easier to generate the new setup, instead of copying and pasting huge jsons.

Could I ask you to edit the data-sources.R for this one, and add this to your PR? I am happy to accept after this. Otherwise, I can also do it myself based on what you suggested.

@dplecko
Copy link
Member

dplecko commented Jun 4, 2024

Hi @mlondschien,

These edits were quite helpful. I included them in ricu 0.6.1. However, as you will see, I edited the data-sources.R instead of data-sources.json. Handling json files with 10k lines is quite annoying (and causes errors, including in your pull request), so for the time being, editing the R files is the preferred solution (in case you need to make a pull request in the future).

@dplecko dplecko closed this Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants