The data in the prescription table but not in the emar table, and the opposite case
Nobody has claimed this yet.
- Dominant language
- Jupyter Notebook
- Stars
- 3.4k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
Prerequisites
- Put an X between the brackets on this line if you have done all of the following:
- Checked the online documentation: https://mimic.mit.edu/
- Checked that your issue isn't already addressed: https://github.com/MIT-LCP/mimic-code/issues?utf8=%E2%9C%93&q=
Hi! First of all thank you for creating and maintaining this useful dataset.
As far as I know, prescription table and emar table can be linked to each other via 'pharmacy_id' columns.
And what I've tried is investigating the relationship b.w them using 'pharmacy_id' columns as a key.
I've wondered about
- the data in the prescription table but not in the emar table,
- and the opposite case (the data in the emar table but not in the prescription table,
In what situations does each type of data come from?
I guessed a few things.
for the first case,
If prescription can be cancelled after prescription is issued, then
for the second case,
There could be some drugs that can be administered to patients without corresponding prescriptions from doctor
Or emar can contain the drug administration data after the patient leave the hospital
Anyway, the reason is still unclear.
Maybe you can understand my question more easily with the code below I wrote .

Thank you!!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the MIMIC online documentation and the prescription and emar table definitions, focusing on how pharmacy_id is assigned and used. Compare the two cases described in the issue and document the situations that explain each mismatch; done means the relationship and exceptions are clearly documented.
Written by the indexing model from the issue text.
Assessment
- Domain
- data, databases
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100